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

Publicly Available Specification (PAS); Intelligent Transport Systems (ITS); MirrorLink®; Part 12: UPnP Server Device

RTS/ITS-98-12

General Information

• Status: Published
• Publication Date: 08-Oct-2019
• Technical Committee: ITS - Intelligent Transport Systems
• Current Stage: 12 - Completion
• Due Date: 30-Sep-2019
• Completion Date: 09-Oct-2019

Standards Content (Sample)

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






TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS);
MirrorLink®;
Part 12: UPnP Server Device
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-030 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.

---------------------- Page: 1 ----------------------
2 ETSI TS 103 544-12 V1.3.1 (2019-10)



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

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

Tel.: [phone]  Fax: [phone]

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

---------------------- Page: 2 ----------------------
3 ETSI TS 103 544-12 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 Device Definitions . 6
4.1 Device Type . 6
4.2 Device Model . 6
4.2.1 General . 6
4.2.2 Relationship Between Services . 7
4.3 Theory of Operation . 8
4.3.1 General . 8
4.3.2 XML Signature Minimum Set . 12
5 XML Device Description . 12
6 Test . 14
Annex A (normative): XSD Schema . 15
A.1 XSD Schema for UDA 1.1 . 15
A.2 ml1-0.xsd . 19
A.3 ml1-1.xsd . 20
A.4 ml1-2.xsd (MirrorLink 1.2) . 20
A.5 ml1-3.xsd (MirrorLink 1.3) . 21
Annex B (informative): Authors and Contributors . 22
History . 23


ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 103 544-12 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 12 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

---------------------- Page: 4 ----------------------
5 ETSI TS 103 544-12 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 color display, audio
input/output and user input mechanisms.
The present document defines the device:
urn:schemas-upnp-org:device:TmServerDevice:1.
This device can be a UPnP root device or embedded within a different device.
The TmServerDevice encapsulates all services for the MirrorLink UPnP Server Device Control Protocol (DCP).
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.
TM TM
[1] UPnP Forum: "UPnP Device Architecture 1.1", 15 October 2008.
NOTE: Available at http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf.
[2] ETSI TS 103 544-26 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 26: Consumer Experience Principles and Basic Features".
[3] W3C Recommendation 11 April 2013: "XML Signature Syntax and Processing Version 1.1".
NOTE: Available at http://www.w3.org/TR/xmldsig-core/.
[4] Unicode Consortium: "Unicode 12.1 Character Code Charts".
NOTE: Available at http://www.unicode.org/charts/.
[5] ETSI TS 103 544-4 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 4: Device Attestation Protocol (DAP)".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TS 103 544-12 V1.3.1 (2019-10)
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
Void.
4 Device Definitions
4.1 Device Type
The following device type identifies a device that is compliant with this template:
urn:schemas-upnp-org:device:TmServerDevice:1
We herein refer to this device in the present document as TmServerDevice. The TmServerDevice device shall follow
defined UPnP behaviour within the UPnP Device Architecture 1.1 [1].
4.2 Device Model
4.2.1 General
Table 1 briefly describes the services used in TmServerDevice.
Table 1: TmServerDevice Service Descriptions
Service Name Service Description
TmApplicationServer Allows for discovery and remote control of applications.
TmClientProfile Allows MirrorLink UPnP Control Point to specify its preferences, settings
and capabilities.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 103 544-12 V1.3.1 (2019-10)
Service Name Service Description
TmNotificationServer Allows MirrorLink UPnP Server to send notification events.

Products that expose devices of the type urn:schemas-upnp-org:device:TmServerDevice:1 shall implement minimum
version numbers of all required embedded devices and services specified in Table 2.
Table 2: Device Requirements for TmServerDevice
DeviceType Root Req. or ServiceType Req. or Service ID (note 2)
Opt. Opt.
(note 1)
(note 1)
TmServerDevice:1 Yes R TmApplicationServer:1 R TmApplicationServer
  TmClientProfile:1 R TmClientProfile
  TmNotificationServer:1 O TmNotificationServer
NOTE 1: R = Required, O = Optional.
NOTE 2: Prefixed by urn:upnp-org:service:.

4.2.2 Relationship Between Services
Figure 1 shows the logical structure of the device and the encapsulated services which provide MirrorLink capabilities.
The TmClientProfile service provides a way for the MirrorLink UPnP Control Point to notify the MirrorLink Server
device about its preferences, capabilities and desired settings (i.e. client profile). This information can then be utilized
by other services hosted by the MirrorLink Server device such as the TmApplicationServer service.
The TmApplicationServer service provides a way for the MirrorLink UPnP Control Point to remotely control and access
applications on the MirrorLink Server device.
The TmNotificationServer service provides a way for the MirrorLink UPnP Server to notify the MirrorLink UPnP
Control Point on application notification events.

Figure 1: Relationship between TmServerDevice and Services
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 103 544-12 V1.3.1 (2019-10)
4.3 Theory of Operation
4.3.1 General
TmServerDevice provides mechanisms which enable MirrorLink UPnP Control Points to discover and access
MirrorLink services.
Table 3 lists the attributes which are part of the TmServerDevice and specified as extensions to the standard UPnP
Device XML schema.
Table 3: Extended Attributes for TmServerDevice
Element Description Parent Availability
MirrorLink Server Version
X_mirrorLink
Note: If the version information is missing, the
device Mandatory
Version
MirrorLink Client shall assume a version 1.0
MirrorLink Server.
MirrorLink Server Major Version
X_mirrorLink
majorVersion Mandatory
Version
A_ARG_TYPE_Int
MirrorLink Server Minor Version
X_mirrorLink
minorVersion Mandatory
Version
A_ARG_TYPE_Int
X_connectivity Connectivity settings device Conditional
bluetooth Bluetooth settings of device X_connectivity Conditional
Bluetooth MAC address (BD_ADDR). Indicates
device support for Bluetooth on the device.
bdAddr bluetooth Conditional
(A UTF-8 encoded string representing an unsigned
48-bit integer in hexadecimal format (without any ‘0x'
prefix).)
A_ARG_TYPE_Bool
startConnectio
Bluetooth Connection will be initiated from device.
bluetooth Optional
n
Default: true
Bluetooth MAC address (BD_ADDR) of the
connected Bluetooth device.
(A UTF-8 encoded string representing an unsigned
clientBdAddr 48-bit integer in hexadecimal format (without any ‘0x' bluetooth Conditional
prefix).)
Shall be included, if bdAddr is not provided and a
Bluetooth connection exists.
wifi WiFi settings of the device X_connectivity Optional
WiFi MAC address
(A UTF-8 encoded string representing an unsigned
macAddr wifi Mandatory
48-bit integer in hexadecimal format (without any
"0x" prefix, and without any grouping using ":",
"." or "-")
Service Set Identifier (SSID), Base64 encoded
ssid wifi Optional
(A_ARG_TYPE_String)
Comma separated list of supported roles.
Allowed values are
• AP (Access Point role)
roles • Client (Client role) wifi Optional
• P2P (Infrastructure-less)
(A_ARG_TYPE_String)
Default: AP,Client,P2P
protectionList List of WiFi access protection wifi Optional
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 103 544-12 V1.3.1 (2019-10)
Element Description Parent Availability
protection* Access protection protectionList Optional
Security protocol used to protect WiFi access.
Allowed values are
• WEP
• WPA
protocol • WPA2 protection Mandatory
• WPS
NOTE: WEP/WPA is listed for legacy reasons, and
should not be used
(A_ARG_TYPE_String)
Passkey/Shared key, Base64 encoded
Shall be left empty, if transmitted over an unprotected
passkey protection Mandatory
or shared transport channel (e.g. WiFi)
(A_ARG_TYPE_String)
Device specific physical hard keys
X_deviceKeys device Deprecated
Deprecated
Defines a device specific key
key* X_deviceKeys Deprecated
Deprecated
Short name (A_ARG_TYPE_String)
name key Deprecated
Deprecated
Flag (A_ARG_TYPE_Bool)
mandatory key Deprecated
Deprecated
Key's symbol hexadecimal value
symbolValue key Deprecated
Deprecated
Describes an icon representing the key
icon* key Deprecated
Deprecated
Type of icon image
mimetype icon Deprecated
Deprecated
Width of icon (A_ARG_TYPE_INT)
width icon Deprecated
Deprecated
Height of icon (A_ARG_TYPE_INT)
height icon Deprecated
Deprecated
Icon color depth (A_ARG_TYPE_INT)
depth icon Deprecated
Deprecated
Url to icon (A_ARG_TYPE_URI)
url icon Deprecated
Deprecated
XML signature over entire contents of the root
element. This is done as specified in [3].
The key used in calculating the signature shall be the
private part of the application-specific key which
public part was bound to the attestation of UPnP-
Server component. (The public part can be used to
X_Signature device Mandatory
verify the signature.) The Reference element of the
XML signature shall be empty.
The SignatureMethod shall be RSA with SHA1. The
KeyInfo element may be omitted. The mechanism for
generation, exchange and maintenance of keys is out
of scope for the present document.
Presentation protocols supported from the MirrorLink
Server.
X_presentation
MirrorLink Server shall include this element if it device Mandatory
s
supports presentation protocols other than "vncu".
(MirrorLink 1.2)
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 103 544-12 V1.3.1 (2019-10)
Element Description Parent Availability
Comma-separated list of presentation protocols
supported from the MirrorLink Server.
• hsml
• wfd
presentation X_presentations Mandatory
• vncu
• vncw
(A_ARG_TYPE_String)
Provide information about the localization support
X_localization device Optional
from the MirrorLink Server.
Comma-separated list of entry points into the
UniCode Character Code Charts, which are
supported from the MirrorLink Server device.
characterSet X_localization Mandatory
(UTF-8 encoded string; each entry point is given in
hexadecimal format (with "0x" prefix).
Supported MirrorLink modes from the MirrorLink
X_mlUiMode
device Mandatory
Server. Introduced in MirrorLink 1.3.
Supported MirrorLink mode from the MirrorLink
Server. Allowed values are
• immersive
mode* mlUiMode Mandatory
• classic
(A_ARG_TYPE_String)

The elements marked with an (*) can have multiple instances.
For deprecated values, the MirrorLink Server shall not include them into the UPnP Device XML. The MirrorLink
Client shall ignore any content provided in deprecated elements.
The modelNumber element within the Device XML is a unique number identifying a family of devices, which expose
identical MirrorLink related behavior, from the device manufacturer given in the manufacturer element. The model
number format is vendor specific. It shall be smaller than 32 bytes. The modelNumber values are recorded by the CCC
Certification Body.
Implementation Note
Some older MirrorLink Server devices need not provide a (unique) model number or a manufacturer element.
The MirrorLink Client shall validate the received X_Signature. A failure to successfully validate the X_Signature shall
terminate the MirrorLink session.
NOTE: The public key needed to validate the received X_Signature is provided through the Device Attestation
Protocol, bound to the TerminalMode:UPnP-Server component [5]. Therefore, the MirrorLink Client will
either store (parts of) the received Device XML or retrieve it again.
If the MirrorLink Server has a Bluetooth module, the MirrorLink Server shall provide a Bluetooth MAC address
(bdAddr), even if that module is not used within a potential MirrorLink connection.
Implementation Note
In case the underlying platform prevents access to the Bluetooth MAC address, as defined in the platform
specific specification, the MirrorLink Server will need to handle some functionality on behalf of the
MirrorLink Client. In this case, the MirrorLink Server shall disconnect BT A2DP, as soon as the MirrorLink
Client is establishing an RTP forward or RTSP session.
A MirrorLink Server failing to include its Bluetooth MAC address may lead to the MirrorLink Client
connecting to the wrong device, which is not the connected MirrorLink Server device. This may need to be
resolved from the user, manually reconnecting to the correct device.
In case the MirrorLink Client only uses the MirrorLink Server's Bluetooth MAC address to determine, whether
to use the MirrorLink Server's or the MirrorLink Client' s local in-Call UI, in case a phone call is established
via Bluetooth HFP, the MirrorLink Client should default to its local in-Call UI.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 103 544-12 V1.3.1 (2019-10)
The MirrorLink Server shall not use any default, wrong or non-existing Bluetooth MAC address, like
"02:00:00:00:00:00". This would otherwise lead the MirrorLink Client to a failing connection attempt.
XSD format descriptions shall be as given in Annex A.
The following applies to MirrorLink 1.2 and beyond.
The MirrorLink Server should provide information about its localization support with respect to the support of
foreign language character sets. In case the information is provided, the MirrorLink Server shall include all
supported character sets, as defined by the UniCode Character Code Chart given by the provided entry point,
specified in [4].
NOTE: The Unicode code charts define a range for the respective code. The entry point is defined as the first
value within that given range. E.g. Basic Latin (ASCII) has a range of 0x0000 - 0x007F. Therefore, its
entry point is 0x0000.
A MirrorLink Server shall support all characters from a listed Code Chart. A MirrorLink Server shall support
at least Basic Latin (ASCII), which is defined by the Character Code Chart entry 0x0000.
The following applies from MirrorLink 1.3 onwards.
The MirrorLink Server shall provide the Bluetooth MAC address (bdAddr) of the connected Bluetooth device
within the clientBdAddr element. In case that address is not accessible, the element shall be available, but left
empty, e.g. "". In case the MirrorLink Server is not connected via Bluetooth, the
element shall be omitted. The MirrorLink Client should use this information to detect the device, it is
connected to via Bluetooth, and whether to display its local in-Call UI.
Table 4 shows the use of the bdAddr and clientBdAddr elements, dependent of the MirrorLink Server status.
Status includes state of the Bluetooth connection as well as ability of the MirrorLink Server implementation to
access the respective information.
Table 4: Announcement of MirrorLink Server and Client Bluetooth MAC Addresses
MirrorLink Server Status bluetooth bdAddr clientBdAddr
No Bluetooth radio. Shall be omitted. N/A N/A
Bluetooth radio. Shall be included. Shall be Included. Shall be omitted.
Access to bdAddr. Shall be Valid, non-
empty MAC
Bluetooth not connected.
address.
Bluetooth radio. May be included.
Access to bdAddr. If included, shall be valid,
non-empty MAC address.
Bluetooth connected.
Access to clientBdAddr.
Bluetooth radio. May be included.
Access to bdAddr. If included, shall be
empty, e.g.
Bluetooth connected.
.
No access to clientBdAddr.
Bluetooth radio. Shall be included. Shall be included. Shall be omitted.
No access to bdAddr. Shall be empty,
e.g. .
Bluetooth not connected.
Bluetooth radio. Shall be included.
No access to bdAddr. Shall be valid, non-empty
MAC address.
Bluetooth connected.
Access to clientBdAddr.
Bluetooth radio. Shall be included.
No access to bdAddr. Shall be empty, e.g.
.
Bluetooth connected.
No access to clientBdAddr.

ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 103 544-12 V1.3.1 (2019-10)
The Device XML is expected to be static. Therefore, the clientBdAddr shall represent the information at the time of the
initial SSDP:alive advertisements.
The MirrorLink Server shall provide information about its supported MirrorLink Modes, as defined in [2]. The
MirrorLink Server shall include all supported modes:
- "immersive" - support for Immersive MirrorLink Mode.
- "classic" - support for Classic MirrorLink Mode.
MirrorLink 1.1 and 1.2 Servers will not provide any MirrorLink Mode information. Those devices implement
Legacy MirrorLink Mode. MirrorLink 1.3 Server devices shall support Classic MirrorLink Mode. Immersive
MirrorLink Mode should be supported from the MirrorLink Server. More details are defined in [2].
4.3.2 XML Signature Minimum Set
The MirrorLink Server shall sign the Device XML.
Signatures shall follow W3C's recommendation on XML signing, as specified in [3]. The W3C recommendation
contains many optional elements for handling the different aspects of the XML signing. In order to reduce the
complexity, the following requirements shall be followed for MirrorLink Server and Client devices:
• The Reference URI shall be empty.
• MirrorLink Server shall not use XPath or XSLT XML transformations.
• The MirrorLink Server shall use Canonical method XML version 1.0 (xml-c14n or xml-exc-c14n) or
1.1 (xml-c14n11); Canonical XML version 2.0 or later shall not be used.
• The MirrorLink Server shall use SHA-1 digest method; other digest methods shall not be used.
• The MirrorLink Server shall use RSA-SHA1 signature method; other signature methods, like HMAC-SHA1
or DSA-SHA1, shall not be used.
• The MirrorLink Client shall not use the KeyInfo element to identify a public key to verify the signature; it
shall use the applicationPublicKey element obtained from the DAP attestationResponse, for the
TerminalMode:UPnP-Server component instead.
5 XML Device Description
When processing XML, MirrorLink Clients shall ignore any unknown elements and their sub elements or content and
any unknown attributes and their values. MirrorLink Clients shall not expect any particular order of XML elements
located at the same level of the XML tree, unless specifically mandated (e.g. via xs:sequence). MirrorLink Client shall
understand xml namespace as specified in W3C "Namespaces in XML 1.0".
The MirrorLink Server shall provide a well-formed XML and a correct parent children relationship of xml elements and
correct xml namespaces URI for each element. If the MirrorLink Server provides MirrorLink extension elements (X_.)
then those elements shall be valid according their XSD provided in Annex A. The MirrorLink Server shall provide
XML Device Description that is valid according to XSD presented in Annex A.
The MirrorLink Client should be as permissive as possible when consuming XML.
As a general recommendation for better interoperability, the Mirror
...