ETSI TS 103 544-26 V1.3.1 (2019-10)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS); ®
MirrorLink ;
Part 26: Consumer Experience Principles and Basic Features
CAUTION
The present document has been submitted to ETSI as a PAS produced by CCC and
approved by the ETSI Technical Committee Intelligent Transport Systems (ITS).
CCC is owner of the copyright of the document CCC-TS-087 and/or had all relevant rights and had assigned said rights to
ETSI on an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties whether express,
implied, statutory or otherwise including but not limited to merchantability, non-infringement of any intellectual property rights of
third parties. No warranty is given about the accuracy and the completeness of the content of the present document.

2 ETSI TS 103 544-26 V1.3.1 (2019-10)

Reference
RTS/ITS-98-26
Keywords
interface, ITS, PAS, smartphone

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm
except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
©ETSI 2019.
© Car Connectivity Consortium 2011-2019.
All rights reserved.
ETSI logo is a Trade Mark of ETSI registered for the benefit of its Members.
MirrorLink® is a registered trademark of Car Connectivity Consortium LLC.
RFB® and VNC® are registered trademarks of RealVNC Ltd.
UPnP® is a registered trademark of Open Connectivity Foundation, Inc.
Other names or abbreviations used in the present document may be trademarks of their respective owners.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 544-26 V1.3.1 (2019-10)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Consumer Experience Principles . 7
5 Basic MirrorLink Features . 7
5.1 Introduction . 7
5.2 First-Use Experience . 7
5.3 Download, Installation and Update of Applications . 8
5.4 Listing of MirrorLink Applications . 8
5.5 Management of Certified Applications . 9
5.6 Interacting with MirrorLink Applications . 9
5.7 Listening to Entertainment and Navigation Audio . 10
5.8 Transferring Audio to and from a MirrorLink Session . 11
5.9 MirrorLink Consistency, Robustness & Ease of Use . 12
5.10 Phone Call Functionality . 12
5.11 MirrorLink Logo Use . 13
5.12 Classic, Immersive and Legacy MirrorLink Mode . 13
6 Minimum Baseline Performance . 20
6.1 General . 20
6.2 User Interface Performance . 20
6.2.1 VNC RAW/RLE Performance . 20
6.2.2 HSML Performance . 20
6.2.3 VNC VA H.264 Performance . 21
6.3 Round Trip Latency. 21
6.4 Setting Up and Managing the MirrorLink Session . 21
7 MirrorLink Application . 21
7.1 Introduction . 21
7.2 Immersive & Classic Home Screen Application . 22
7.3 Immersive & Classic Phone Call Application . 23
Annex A (informative): Authors and Contributors . 24
History . 25

ETSI
4 ETSI TS 103 544-26 V1.3.1 (2019-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document is part 26 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
5 ETSI TS 103 544-26 V1.3.1 (2019-10)
1 Scope ®
The present document is part of the MirrorLink specification which specifies an interface for enabling remote user
interaction of a mobile device via another device. The present document is written having a vehicle head-unit to interact
with the mobile device in mind, but it will similarly apply for other devices, which provide a colour display, audio
input/output and user input mechanisms.
MirrorLink is a single protocol that defines how a MirrorLink enabled Client device (typically the consumer's in-vehicle
infotainment system) and a MirrorLink enabled Server device (typically the consumer's mobile device) communicate
and provide an integrated consumer experience, where the MirrorLink Server is creating the consumer experience,
running MirrorLink applications, whose user interfaces are presented via the MirrorLink Client. Consumers will only
interact with the MirrorLink Client device, leaving the MirrorLink Server device stored away, allowing for responsible
interactions, while the vehicle is in motion.
The MirrorLink protocol enables mobile device's consumer experience to be projected on the in-vehicle infotainment
system. It enables the consumer to use the controls of the infotainment system to manipulate the mobile device. By
using applications, following application-level requirements, either for use in drive or non-drive situations, consumers
will see an experience optimized for the current situation.
Whereas the MirrorLink protocol specifies a consumer experience, it is open to implementation specific decisions and
variations from Client and Server manufacturers. Differentiation in the consumer experience and supported features is
encouraged. However, MirrorLink does need to be predictable and recognizable to the consumer. It is also critical for a
MirrorLink brand recognition.
The present document specifies the basic consumer experience, for which MirrorLink stands for and many of the
features MirrorLink enables. The present document intends to focus on the consumer experience level and does not
intend to replace any requirements of the other technical specifications. Whether or not a MirrorLink Client or Server
device follow the requirements defined within the present document will be mainly evaluated and tested through IOP
testing.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 544-2 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 2: Virtual Network Computing (VNC) based Display and
Control".
[2] ETSI TS 103 544-9 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 9: UPnP Application Server Service".
[3] ETSI TS 103 544-10 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 10: UPnP Client Profile Service".
[4] ETSI TS 103 544-12 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 12: UPnP Server Device".
ETSI
6 ETSI TS 103 544-26 V1.3.1 (2019-10)
[5] Car Connectivity Consortium CCC-RQ-005: "Application Requirements for Drive Certification".
NOTE: Available at https://carconnectivity.org/wp-content/uploads/2019/09/CCC-RQ-005-MirrorLink-
_ApplicationRequirements_2.0.8.pdf.
[6] Bluetooth Specification: "Hands-free Profile", Audio, Telephony, and Automotive Working
Group, Revision 1.7.2, January 21, 2019.
NOTE: Available at https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457090.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 544-1 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 1: Connectivity".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
BT Bluetooth
CCC Car Connectivity Consortium
FB FrameBuffer
FM Frequency Modulation
HFP Bluetooth Hands-Free Profile
HSML High Speed Media Link
IOP InterOPerability
ML MirrorLink
RFB Remote Framebuffer
RTP Real-Time Protocol
SCO Synchronous Connection-Oriented
UI User Interface
UPnP Universal Plug and Play
USB Universal Serial Bus
VA Video Audio
VNC Virtual Network Computing
WFD Wi-Fi Display
ETSI
7 ETSI TS 103 544-26 V1.3.1 (2019-10)
4 Consumer Experience Principles
The MirrorLink consumer experience is guided by a set of principles. Those principles are not strictly enforceable, as
they are described on a high-level. Therefore, no obligation language is used in their description. But devices failing
those principles will typically violate one or more of the MirrorLink technical requirements, as defined in the separate
functional specification, or of the basic feature requirements as outlined in clause 5.
The MirrorLink set of consumer experience principles are:
1) Starting MirrorLink is simple.
2) Paired MirrorLink certified devices just work.
3) Consumers are provided with a consistent and predictable MirrorLink consumer experience.
4) Consumers are at no time expected to interact with the MirrorLink Server device, after initial MirrorLink
connectivity has been established.
5) Consumers are only provided with visual and audio content appropriate for the driving mode and local region,
the MirrorLink Client device is currently in.
6) Consumers are provided with a responsive MirrorLink consumer experience.
7) Consumers are provided with a clear visual user interfaces, with minimal or no stretching and distortion,
showing legible graphics and text.
8) Consumers are provided with a clear audio playback experience, free from pops, crackles and hisses on the
MirrorLink Client's speakers. Latencies in controlling the audio stream are minimal.
9) Consumers are provided with consumer-friendly prompts, only when necessary.
10) Consumers are provided with appropriate notifications in case something goes wrong or a consumer's action
cannot be completed as expected ("No Silent Failure").
11) Consumers are provided with an uninterrupted MirrorLink experience until MirrorLink is ended.
12) Ending MirrorLink is simple and does not lead to unresponsive devices.
13) The use of MirrorLink functionality is described in respective consumer documentation or made available
otherwise.
14) The consumer can easily recognize whether MirrorLink functionality is available.
5 Basic MirrorLink Features
5.1 Introduction
This clause summarizes the consumer experience related requirements for the various MirrorLink features, which are
available using the MirrorLink protocol. Requirements provided within this clause are complementary to requirements
in the detailed MirrorLink protocol specifications. Nevertheless, in case of a contradicting requirement or a
contradicting obligation, the device vendor should apply the MirrorLink consumer experience principles as guidance as
to which requirement to use.
The following clauses address features, which are either relevant to the consumer or which will message with the
consumer.
5.2 First-Use Experience
The consumer installing MirrorLink on a supported mobile device is expecting an immediate first use experience, when
connecting the device to a MirrorLink enabled in-vehicle infotainment system.
ETSI
8 ETSI TS 103 544-26 V1.3.1 (2019-10)
The following consumer experience requirements are defined:
• If no MirrorLink certified application, installed on the MirrorLink Server, can be presented on the MirrorLink
Client, the MirrorLink Client shall inform the consumer about this fact. The MirrorLink Client should point to
a location from where MirrorLink enabled compatible applications can be downloaded.
• If installed MirrorLink enabled applications are missing certificates, preventing their usage within MirrorLink,
the requirements in clause 5.3 shall apply.
5.3 Download, Installation and Update of Applications
The consumer is able to download, install and update a suitable CCC or Member-certified application from any
available application marketplace or via side-loading. In order to enable the consumer to use the application, e.g. while
driving, the MirrorLink Server will need to evaluate the certification status prior first use. This validation requires the
consumer to have the device connected to the Internet.
Failing to validate the certification status will not allow the consumer to use the application.
NOTE: Usability of an application refers to the application's expected use, as recorded in the certificate of the
application. E.g. while a drive certified application may still be usable in park-mode, after the certificate
cannot be validated for drive anymore, the application is not usable as expected in drive-mode.
Therefore, the following consumer experience requirements are defined:
• The consumer shall be able to install and update a MirrorLink application via the same mechanisms, as with
any other regular non-MirrorLink application. Potential mechanisms include the download and installation
from an application store or via side-loading.
• The consumer shall be able to install and update a MirrorLink application outside a MirrorLink session. The
consumer shall be able to install and update a MirrorLink application inside a MirrorLink session, unless
driving mode and/or geographic limitations apply (e.g. of the App Store application).
• The consumer shall be able to use a newly installed or updated MirrorLink application as expected, within a
few seconds, unless the validation of the application certificate is not possible.
• The consumer shall be notified, when an installed or updated application cannot be used as expected, within
MirrorLink within a few seconds. The consumer should not be notified, when the application can be used as
expected. The notification should point out that internet connectivity is required to resolve the issue.
• A MirrorLink application, which is uninstalled from a MirrorLink Server device shall be immediately removed
from the MirrorLink Server's application listings.
• Download, installation and update behaviour shall be independent of whether the device is new (i.e. after a
factory reset) or used.
5.4 Listing of MirrorLink Applications
The consumer is able to launch application via listings of MirrorLink applications. Application listings are provided
from the MirrorLink Client, via native MirrorLink Client user-interfaces or from the MirrorLink Server, via dedicated
Home Screen applications. Latter one is accessible only via a MirrorLink session.
The following consumer experience requirements are defined:
• The order of the MirrorLink application list shall be consistent across multiple MirrorLink sessions.
• The MirrorLink Server's home screen application (if available), shall be listed first.
• The MirrorLink Server shall advertise drive-certified applications first in its application listing.
• The MirrorLink Client should show drive certified applications first in its application listing.
• The MirrorLink Server and the MirrorLink Server's home screen application shall not reorder the application
list without explicit consumer interaction.
ETSI
9 ETSI TS 103 544-26 V1.3.1 (2019-10)
• The MirrorLink Server shall not change the order of the application listings within a MirrorLink session.
• The MirrorLink Server may offer an easily accessible mechanism that allows the consumer to control the
sorting of the application listed. This mechanism should allow the consumer to sort the application list by
frequency of use, name, install date, or other properties and to manually reorder the list.
• If a MirrorLink Client lists MirrorLink base certified applications in drive mode, those applications shall be
clearly identifiable by the consumer (in drive mode) as not being available, e.g. graying them out. The
consumer shall be able to distinguish a drive-certified application from a non-drive-certified application
without any consumer interaction or launching the application. This requirement applies to drive and park
mode. The MirrorLink Client may only list drive-certified applications in drive mode.
5.5 Management of Certified Applications
In order to enable the consumer to use the application, e.g. while driving, the MirrorLink Server will need to
continuously evaluate the certification status on a regular basis. This validation requires the consumer to have the
device connected to the Internet:
• The consumer shall have access to certified applications as long as the application is installed on the
MirrorLink Server device and the certification status can be regularly validated by the MirrorLink Server.
• The consumer should not be notified, when the certification status of a MirrorLink application can be regularly
validated.
• The consumer should not be notified, when the certification status of a MirrorLink application cannot be
regularly validated, while the application is still usable as expected within MirrorLink.
• The consumer should be notified, when an application will soon become unusable as expected within
MirrorLink. Advanced notice should be given at least 24 h prior.
• The consumer shall be notified, when a MirrorLink certified application became unusable within MirrorLink,
for certification related reason. The notification should point out that internet connectivity may be required to
resolve the issue.
In case the consumer has to be notified, the MirrorLink Server shall provide the notification.
Notifications should be provided outside a MirrorLink session or via separate notification/setting pages. Notification
may be deferred, if needed (e.g. as the device is currently in drive mode and visual notification is not possible).
Notification should be provided outside a MirrorLink session as well, when applicable (e.g. expiration of a certificate).
The MirrorLink Server should provide a "Certificate dashboard" application, which displays a list of all installed
MirrorLink application. The application should allow the consumer to trigger the validation of the application
certificates. This application may be not-MirrorLink enabled.
The MirrorLink Server should allow MirrorLink drive-certified applications, to call other driver certified applications,
implementing a specific intend, e.g. to launch navigation or phone call functionality. This shall not cause uncertified
content to become visible in the foreground of the MirrorLink screen.
5.6 Interacting with MirrorLink Applications
The consumer is able to interact with MirrorLink applications via Voice or Physical interaction with the Client devices
user input controls, like the Client's touch screen, soft or hard buttons around the Client's screen or on the steering
wheel.
The following consumer experience requirements are defined:
• All soft buttons, rendered by the MirrorLink Client around the MirrorLink Application's user interface, shall
be usable and shall be consistent with the user's expectation of the underlying control event. I.e. a home button
shall have home functionality.
ETSI
10 ETSI TS 103 544-26 V1.3.1 (2019-10)
• All soft buttons, rendered by the MirrorLink Server around the MirrorLink Application's user interface, shall
be usable and shall be consistent with the user's expectation of the underlying control event. I.e. a home button
shall have home functionality.
• All device key events, the MirrorLink Server is advertising in its Key Event Configuration message, shall be
supported from the MirrorLink Server and/or respective MirrorLink applications.
• All hard buttons, supported by the MirrorLink Client within MirrorLink, shall be usable and shall be
consistent with the user's expectation of the underlying control event. I.e. a home button shall have home
functionality.
• Dedicated buttons, available within MirrorLink, it shall have the same semantics within MirrorLink as in the
native context outside of MirrorLink.
5.7 Listening to Entertainment and Navigation Audio
The consumer has access to his/her favourite entertainment and navigation applications, either run remotely from the
MirrorLink Server or locally from the MirrorLink Client. The MirrorLink Server is responsible for mixing all remote
audio sources into a single audio stream, which is streamed to the MirrorLink Client. The MirrorLink Client is
responsible for mixing the MirrorLink audio stream with other local audio streams, and output the mixed audio stream
via its speaker system.
NOTE: Local audio in the context of the MirrorLink Client is referring to audio sources, which are handled
outside of MirrorLink, like FM radio.
Within the scope of the present document, the mixing of two or more audio streams will result in either one audio
stream being in the foreground and the others being in background, or one audio stream being heard and the others
being silenced. The audio source of a silenced audio stream may be muted, paused or stopped, dependent on the type of
audio source (application specific).
The following consumer experience requirements are defined:
• The MirrorLink Server shall give the same priority for its entertainment and navigation audio sources within
MirrorLink as it gives outside a MirrorLink session.
• The MirrorLink Client shall give MirrorLink navigation audio a higher priority than local entertainment audio.
The MirrorLink Client shall automatically switch back to local entertainment audio, after the MirrorLink
navigation audio completes. The MirrorLink Client shall automatically resume local entertainment audio
playback in this case, unless higher-priority activities are preventing this for the MirrorLink Client.
• The MirrorLink Client shall give local navigation audio a higher priority than MirrorLink entertainment audio.
The MirrorLink Client shall automatically switch back to MirrorLink entertainment audio, after the local
navigation audio completes, unless higher-priority activities are preventing this for the MirrorLink Client. The
MirrorLink application should automatically resume MirrorLink entertainment audio playback in this case.
NOTE: CCC's application certification program may add specific requirements regarding automatic resume after
audio unblocking.
• The MirrorLink Client shall give the MirrorLink entertainment or the local entertainment audio source, which
had been selected by the user last, a higher priority. Switch back to the other entertainment source shall happen
only based on consumer action.
• The MirrorLink Client may give unknown MirrorLink audio, while MirrorLink is in the foreground on the
MirrorLink Client, a higher priority than local entertainment audio. The MirrorLink Client may then
automatically resume local entertainment audio playback, once the unknown MirrorLink audio finishes.
NOTE: Within the present document unknown audio refers to the audio stream, for which the audio context is
either missing or the application category is set to 0x00.
• The MirrorLink Client may treat unknown MirrorLink audio differently, depending on whether MirrorLink is
in the foreground or in the background on the MirrorLink Client.
ETSI
11 ETSI TS 103 544-26 V1.3.1 (2019-10)
• The MirrorLink Client shall playback MirrorLink audio, if no local audio is playing, unless the consumer has
specifically muted MirrorLink audio.
• The MirrorLink Client shall not stop playback of local audio, just because MirrorLink audio is getting blocked.
EXAMPLE: A MirrorLink Client is playing local FM radio while it suddenly receives uncertified/unknown
audio content from the MirrorLink Server. If the MirrorLink Client does not support unknown
audio content, it will be blocked. In this case, the MirrorLink Client is not expected to stop or
pause the local FM radio playback, leaving the consumer with a sudden disappearance of the audio
experience for no obvious reason.
• The MirrorLink Client should give local driver safety related audio, higher priority than MirrorLink audio.
• The MirrorLink Client shall prioritize remote and local audio sources, independent of whether the respective
application is in the foreground or in the background on the MirrorLink Server or Client.
• The MirrorLink Server shall provide an entertainment audio stream free of crackles, distortions or other
artefacts over a long period of time (> 1 h), while a VNC session is ongoing.
• The MirrorLink Client shall playback the received entertainment audio stream free of cackles, distortions or
other artefacts over a long period of time (> 1 h), while a VNC session is ongoing.
5.8 Transferring Audio to and from a MirrorLink Session
The consumer is using the mobile device with different audio accessories, like a Bluetooth or analogue audio connector.
When connecting an audio accessory, entertainment audio is typically automatically transferred to the accessory and
continues playing. When disconnecting the accessory, the entertainment audio is typically automatically stopped.
Navigation audio is typically automatically routed to the accessory on connection and back to the mobile on
disconnection, so that no turn-by-turn guidance is missed. Phone call behaviour is typically similar.
In case of MirrorLink, the consumer will expect a similar known behaviour. On the one hand the consumer will expect
the connected MirrorLink enabled head-unit to behave like any other audio accessory, while not disrupting the
preference for the local head-set.
The following consumer experience requirements are defined:
• When the consumer starts a MirrorLink session, the MirrorLink Server shall transition the audio connection to
the MirrorLink Client. The MirrorLink Client shall establish an audio connection to the MirrorLink Server,
when the MirrorLink session is established. The MirrorLink Server shall inform MirrorLink audio applications
about the connection.
• When the consumer ends a MirrorLink session, while MirrorLink entertainment audio is playing, the
MirrorLink application shall transition the audio stream back to the MirrorLink Server's speaker. The
MirrorLink Server shall inform MirrorLink audio application about the disconnection.
• When the consumer connects a Bluetooth or an analogue headset to the MirrorLink Server device, while
MirrorLink audio is playing, the MirrorLink Server shall transition the audio stream to the newly connected
accessory, if this is consistent with connecting the same audio accessory outside a MirrorLink session.
• When the consumer disconnects a Bluetooth or an analogue headset from the MirrorLink Server device, while
MirrorLink audio is playing, the MirrorLink Server shall transition the audio stream back to the MirrorLink
session, if this is consistent with disconnecting the same audio accessory outside a MirrorLink session.
• Consistency in above statements shall be achieved across various MirrorLink sessions. The behaviour is
platform specific, but it should be in line with other projected experiences on that platform.
• Entertainment audio applications should not pause, when transitioning audio to an audio accessory, while in a
MirrorLink session or to a MirrorLink session, without a connected audio accessory.
• Entertainment audio applications should pause, when transitioning audio from an audio accessory, while in a
MirrorLink session or from a MirrorLink session, without a connected audio accessory.
ETSI
12 ETSI TS 103 544-26 V1.3.1 (2019-10)
• Telephony and navigation audio applications shall not pause, when transitioning audio to and from an audio
accessory, while in a MirrorLink session, or to and from a MirrorLink session without a connected audio
accessory.
5.9 MirrorLink Consistency, Robustness & Ease of Use
The consumer is using the mobile device within a MirrorLink session, it expects that whenever a connection is
established, he/she has the same consistent experience as within the last session.
The following consumer requirements are defined:
• The application icons, presented to the consumer shall match the application, in particular after a reconnect or
an application install. In particular, potential caching of the application's icon on the MirrorLink Client side,
shall maintain the match.
• Powering on & off the MirrorLink Client, even repeatable, shall be consistent and shall provide repeatable
experience. It shall not cause the MirrorLink Server or Applications to crash, reboot or otherwise misbehave.
This includes any visible or audible glitch.
• Connecting and disconnecting the MirrorLink Server, even repeatable, shall be consistent and shall provide
repeatable experience. It shall not cause the MirrorLink Client or Applications to crash, reboot or otherwise
misbehave. This includes any visible or audible glitch.
• Switching the MirrorLink Client from park into drive mode and back to park mode shall provide consistent
consumer experience, where the drive/park mode setting, is in line with MirrorLink application settings.
5.10 Phone Call Functionality
Consumers with MirrorLink enabled Server devices supporting phone call functionality, are expecting the same to be
available via MirrorLink. Specifically, in coming phone calls, which may come in at any point in time during a
MirrorLink session, need to be gracefully handled from the MirrorLink Server.
The following consumer requirements are defined:
• The consumer shall be able to receive and accept or reject a phone call, while being in a MirrorLink session.
• A MirrorLink Server shall support telephony functionality over Bluetooth HFP [6] alongside MirrorLink, if
telephony is supported.
• A driver-facing MirrorLink Client shall support telephony functionality over Bluetooth HFP alongside
MirrorLink.
• The Bluetooth HFP connection shall be offered or automatically reconnected when the consumer establishes
the MirrorLink session within park and drive mode. Initial Bluetooth pairing may require manual steps from
the consumer.
• The MirrorLink Server should maintain an existing Bluetooth HFP connection, when a MirrorLink session is
being established.
The control of the Phone Call experience can be provided natively from the MirrorLink Client as well as from the
MirrorLink Server via a dedicated (Immersive) Phone Call application. On an incoming phone call, i.e. when receiving
HFP Ring SCO, the MirrorLink Client has to decide, whether to launch its own phone call UI (Classic MirrorLink), or
whether to use the MirrorLink Server's phone call UI (Immersive MirrorLink).
The following consumer requirements are defined:
• A MirrorLink Client shall use its native call UI to handle HFP/telephony functionality in case the MirrorLink
Server is not connected via BT HFP.
NOTE: This applies, when a non-MirrorLink device is connected to the MirrorLink Client via BT HFP.
• A MirrorLink Client in Classic Mode shall use its native phone call UI to handle HFP/telephony functionality.
ETSI
13 ETSI TS 103 544-26 V1.3.1 (2019-10)
• A MirrorLink Client shall not overlay the MirrorLink Link Server's Immersive Phone application with its
native call UI.
NOTE: Overlay in this regard means, that the MirrorLink Client's native call UI is partially or fully overlaying the
MirrorLink Server's remote framebuffer.
• A MirrorLink Server in Immersive MirrorLink Mode shall bring the Immersive Phone Call application into
foreground, and announce it to the MirrorLink Client, updating the Context Information, not later than
1 000 ms after sending HFP Ring SCO.
5.11 MirrorLink Logo Use
Consumers with MirrorLink enabled devices, need to be aware that MirrorLink is available. The Car Connectivity
Consortium has trademarked a MirrorLink logo and a MirrorLink Design-only icon for this purpose.
The following consumer requirements are defined:
• If the consumer is able to manually activate MirrorLink functionality (e.g. when MirrorLink functionality can
be switched on using a button) the UI element should bear the MirrorLink logo or the MirrorLink Design-only
icon.
• When connecting a MirrorLink Client and Server, both product should announce to the consumer that
MirrorLink capability is available or automatically establish the MirrorLink session.
• If the MirrorLink Server is displaying a static screen, while being in a MirrorLink session, it should contain the
MirrorLink logo or the MirrorLink Design-only icon.
CCC has a dedicated trademark and logo usage guidelines. Use of the MirrorLink Logo and the Design-only icon are
limited to certified products.
To increase consumer awareness of MirrorLink support within MirrorLink enabled devices, the following
recommendations are provided:
• The MirrorLink product should bear the MirrorLink logo or the MirrorLink Design-only icon on the
packaging.
• The MirrorLink product should describe the MirrorLink functionality in the user manual.
• The MirrorLink functionality should be advertised under the brand name MirrorLink as opposed to a
self-defined brand name.
5.12 Classic, Immersive and Legacy MirrorLink Mode
The consumer is expecting a seamless experience, when interacting with individual MirrorLink applications, switching
between those and allowing to go back and forth to a native MirrorLink Client experience.
MirrorLink aims to provide a user experience, where navigation mechanisms (e.g. buttons to switch between
applications) are not redundant, e.g. rendered from both Clients and Servers as part of the user interface. Yet all
functionality to interact with applications, to navigate between applications and to leave the MirrorLink experience is
available to consumers at all time.
The MirrorLink experience is referring to three main events, which need to be either handled from the MirrorLink, the
MirrorLink Server and/or MirrorLink Client, as specified in later in this clause:
• The Device_Backward, or Back event allows the consumer to navigate within applications. The behaviour is
platform specific. Application may ignore the event, or consume it with or without responding to the event.
MirrorLink applications, requiring support for a Back event, shall provide their own mechanisms within the
application, in case the event is not available from the MirrorLink Server or Client.
NOTE: This information is available through the MirrorLink API.
ETSI
14 ETSI TS 103 544-26 V1.3.1 (2019-10)
• The Device_Home or AppList event allows the consumer to switch back to the application listing, either on the
MirrorLink Server's Home Screen application or on the MirrorLink Client. Dependent on the MirrorLink
Mode, the MirrorLink Server or MirrorLink Client shall provide a mechanism for the consumer to trigger this
event.
• The Switch to Native UI event allows the consumer to leave the MirrorLink experience and switch to a
MirrorLink Client native experience. The MirrorLink Client shall provide a mechanism for the consumer to
trigger this event, in case the MirrorLink Client has a native experience.
MirrorLink defines two ta
...