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

Publicly Available Specification (PAS); Intelligent Transport Systems (ITS); MirrorLink®; Part 21: High Speed Media Link (HSML)

RTS/ITS-98-21

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-21 V1.3.1 (2019-10)






TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS);
®
MirrorLink ;
Part 21: High Speed Media Link (HSML)
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-054 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-21 V1.3.1 (2019-10)



Reference
RTS/ITS-98-21
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-21 V1.3.1 (2019-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Introduction . 7
5 HSML USB Architecture . 8
5.1 General . 8
5.2 Functional Characteristics . 9
5.2.1 General . 9
5.2.2 Interface . 9
5.2.3 Endpoints . 9
5.2.3.1 General . 9
5.2.3.2 Default . 9
5.2.3.3 Framebuffer . 9
5.3 Vendor-Specific Codes . 9
5.4 Interface Descriptor . 9
5.5 Endpoint Descriptors . 10
5.6 HSML Requests . 10
5.6.1 General . 10
5.6.2 GetVersion . 11
5.6.3 GetParameters . 11
5.6.4 SetParameters . 12
5.6.5 StartFramebufferTransmission . 13
5.6.6 PauseFramebufferTransmission . 14
5.6.7 StopFramebufferTransmission . 14
5.6.8 SetMaxFrameRate . 14
5.6.9 GetIdentifier . 15
6 HSML Framebuffer Transmission Protocol . 15
6.1 General . 15
6.2 Managing an HSML Connection . 15
6.2.1 Identifying Remote Applications . 15
6.2.2 Establishing the HSML Connection . 15
6.2.3 Intentionally Terminating the HSML Connection . 16
6.2.4 Unintentionally Terminating the HSML Connection . 16
6.3 HSML Protocol Phases . 16
6.3.1 Initialization Phase . 16
6.3.2 Transmission Phase. 17
6.3.2.1 Handling Context Information . 17
6.3.2.2 Handling Display Data . 19
6.3.2.3 Handling Pausing and Resuming Data Transfer . 21
6.3.2.4 Handling Framebuffer Resolution Change . 21
6.3.2.5 Handling Framebuffer Format Change . 23
6.3.2.6 Handling Framerate Adjustment . 23
6.3.2.7 Handling Framebuffer Blocking Notification . 24
6.3.2.8 Handling Orientation Changes . 25
6.3.2.9 Handling Content Attestation . 26
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TS 103 544-21 V1.3.1 (2019-10)
6.3.3 HSML Protocol Finite State Machine . 27
Annex A (informative): Authors and Contributors . 28
History . 29


ETSI

---------------------- Page: 4 ----------------------
5 ETSI TS 103 544-21 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 21 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: 5 ----------------------
6 ETSI TS 103 544-21 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.
The present document describes the High-Speed Media Link, a video transmission mechanism that utilizes the USB to
project the screen of one device onto another device with a larger screen.
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-3 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 3: Audio".
[2] 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".
[3] USB IF: "Universal Serial Bus Specification", Revision 2.0, April 27, 2000.
NOTE: Available at http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf.
[4] IETF RFC 4122: "A Universally Unique Identifier (UUID) URN Namespace", July 2005.
NOTE: Available at http://www.ietf.org/rfc/rfc4122.txt.
[5] USB IF: "Universal Serial Bus, Communications Class, Subclass Specification for Ethernet
Control Model Devices", Revision 1.2, February 9, 2007.
NOTE: Available at https://usb.org/sites/default/files/CDC1.2_WMC1.1_012011.zip - File ECM120.pdf.
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".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TS 103 544-21 V1.3.1 (2019-10)
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:
ARGB Alpha-Red-Green-Blue
CCC Car Connectivity Consortium
HSML High Speed Media Link
IN INput
PC Personal Computer
RGB Red-Green-Blue
RLE (Scan-line based) Run Length Encoding
UI User Interface
UPnP Universal Plug and Play
USB Universal Serial Bus
UUID Universally Unique IDentifier
VNC Virtual Network Computing
XML eXtensible Markup Language
4 Introduction
High Speed Media Link (HSML) is a screen out technology. The main purpose is to let mobile users project their
phones' screens to a larger one, like the display inside a car infotainment system or PC, and users can control their
phones via an automotive head unit or PC. With bigger screens, users can have much better usage experience. Of
course, the present document does not limit the usage scenarios only on mobile phones and automotive head units. The
HSML can be applied to any device that conforms to the present document. As shown in Figure 1.

Figure 1: HSML Protocol Stack
There are two roles in the HSML architecture. The HSML source is the source of video data and the HSML sink is sink
side. On the other hand, the control data is sent from HSML sink to HSML source.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TS 103 544-21 V1.3.1 (2019-10)

Figure 2: HSML Overview
The audio and additional display control mechanisms are handled by MirrorLink requirements defined in [1] and [2].
Therefore, any device that wants to comply with the present document shall implement MirrorLink as well.
The MirrorLink Client, providing HSML functionality, shall implement the HSML sink functionality.
The MirrorLink Server, providing HSML functionality, shall implement the HSML source functionality.
5 HSML USB Architecture
5.1 General
HSML is a USB function that can transfer display data efficiently. The figure below shows the USB architecture of
HSML. Two pipes are established. The control pipe is used to send HSML specific requests. The framebuffer pipe is
established for transmitting the uncompressed or compressed display data.
The device and host will be used in this clause to refer to HSML source and HSML sink respectively because this
clause mainly describes HSML in the context of USB.
CE (HSML Server) HU (HSML Client)
USB Device USB Host
Vendor Specific Vendor Specific
Class Class
EP0 (Ctrl) EP0 (Ctrl)
EP In (Bulk) EP In (Bulk)

Figure 3: HSML USB Architecture
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TS 103 544-21 V1.3.1 (2019-10)
5.2 Functional Characteristics
5.2.1 General
The MirrorLink Server shall support at least two functions: one is HSML and the other is CDC/NCM which is
compliant with HSML. The MirrorLink Server shall include the HSML USB interface into the same USB configuration
as the CDC/NCM USB interface. The HSML function is used for video transmission and the CDC/NCM is used for
carrying MirrorLink traffic.
5.2.2 Interface
The HSML interface shall be one of several interfaces the MirrorLink Server has in order to conform to the present
document.
5.2.3 Endpoints
5.2.3.1 General
The device shall contain two endpoints: Ctrl (Default) and Bulk In (Framebuffer).
5.2.3.2 Default
The default endpoint uses the control transfers as defined in the USB specification [3]. All the standard and vendor-
specific requests are transmitted through this endpoint. The endpoint number shall be zero (0).
5.2.3.3 Framebuffer
This endpoint is used to receive the framebuffer data from the device. This endpoint shall use bulk transfers and the
direction shall be IN. The maximum packet size for USB 2.0 shall be 512 bytes and for USB 3.0 shall be 1 024 bytes.
5.3 Vendor-Specific Codes
Table 1 defines the interface class, subclass and protocol used in the HSML interface descriptor.
Table 1: Vendor-Specific Codes
Fields Code Description
Class 0xFF Vendor specific class
Subclass 0xCC CCC
Protocol 0x01 HSML

To comply with the present document, the device should not have another USB vendor-specific interface whose
subclass field is 0xCC and protocol field is 0x01. The detail of descriptor class definition rule is following USB
specification in [3].
5.4 Interface Descriptor
The HSML interface descriptor is just like a standard USB interface descriptor, except some fields are dedicated to
HSML as follows.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TS 103 544-21 V1.3.1 (2019-10)
Table 2: HSML Interface Descriptor
Offset Fields Size Value Description
(Bytes)
0 bLength 1 Number Size of this descriptor. (9 bytes)
1 bDescriptorType 1 Constant Interface descriptor (0x04)
2 bInterfaceNumber 1 Number Number of interface
3 bAlternateSetting 1 Number Value used to select alternative setting
Number of Endpoints. This number shall be 1 for a
4 bNumEndpoints 1 Number
Bulk IN.
5 bInterfaceClass 1 Class Interface Class Code. (0xFF)
6 bInterfaceSubClass 1 SubClass Interface Subclass Code. (0xCC)
7 bInterfaceProtocol 1 Protocol Interface Protocol Code. (0x01)
Index of a string descriptor that describes this
8 bInterface 1 Index
interface

Standard USB interface descriptor is defined in [3].
5.5 Endpoint Descriptors
The HSML interface requires 2 endpoints: one is default Control endpoint (endpoint 0), another is BULK IN endpoint
as follows.
Table 3: HSML Bulk IN Endpoint Descriptor
Offset Fields Size Value Description
0 bLength 1 Number Size of this descriptor. (7 bytes)
1 bDescriptorType 1 Constant Endpoint descriptor (0x05)
2 bEndpointAddress 1 Number Endpoint number and direction (The bit 7 should be 1 to
indicates its direction is IN)
3 bmAttributes 1 Constant Transfer type, Bulk. (0x02)
4 wMaxPacketSize 2 Number Maximum packet size supported (For USB 2.0, this value
shall be 512 and for USB 3.0, this value shall be 1 024)
6 bInterval 1 Number Service interval. (not used)

Standard endpoint descriptor is defined in [3].
5.6 HSML Requests
5.6.1 General
Table 4 lists all of the HSML specific requests that are valid for the HSML interface. Requests marked as "Yes" in the
mandatory field shall be implemented by any conforming HSML device.
Table 4: HSML Request List
Request Code Mandatory Description
GetVersion 0x40 Yes Get and provide HSML versions of the HSML source
and sink.
GetParameters 0x41 Yes Request the device to report its capabilities and
configurations.
SetParameters 0x42 Yes Configure the device according to the device's and
the host's capabilities.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TS 103 544-21 V1.3.1 (2019-10)
Request Code Mandatory Description
StartFramebufferTrans 0x43 Yes Request the device to start sending framebuffer via
mission the Bulk IN endpoint.
PauseFramebufferTran 0x44 Yes Request the device to pause the framebuffer
smission transmission if it's in streaming mode.
StopFramebufferTrans 0x45 Yes Request the device to stop sending framebuffer if it's
mission in streaming mode.
SetMaxFrameRate 0x46 Yes Request the device to set the maximum framebuffer
update rate. The device shall not send framebuffer
updates at a rate beyond the specified value.
GetIdentifier 0x47 Yes Request the device to return a unique identifier.

The request format is defined in [3], clause 9.
Based on [3], all HSML requests shall use little endian for any value 16-bit, 32-bit or 64-bit value.
5.6.2 GetVersion
This request retrieves the maximum version that the device can support and tells the device which version the host can
support at the same time.
Table 5: GetVersion Request
bmRequestType bRequestCode wValue wIndex wLength Data
11000001B 0x40 HSML Sink The 2 First byte: Major version of
version interface HSML source
number
Second byte: Minor version of
HSML source

The first byte of wValue field shall be HSML sink major version and the second byte of wValue field shall be HSML
sink minor version. The value of wValue field and Data field returned from the HSML source shall be both 0x0100 for
this version of the present document.
HSML source and HSML sink shall provide this function for backward compatibility.
5.6.3 GetParameters
This request is used by the host to get the capabilities and configuration of the device.
Table 6: GetParameters Request
bmRequestType bRequestCode wValue wIndex wLength Data
11000001B 0x41 0 The 16 HSML Parameter
interface structure (see Table 7)
number

ETSI

---------------------- Page: 11 ----------------------
12 ETSI TS 103 544-21 V1.3.1 (2019-10)
Below is the HSML parameter structure.
Table 7: HSML Parameter Structure
Offset Field Size Value Description
0 bmCapabilities 4 Bitmap Bit 0: BigEndian used
Bit 1: FBUpdateOnChange supported
Bit 2 to 31: Reserved. (it shall be all zeroes)
4 wWidth 2 Number The width of framebuffer that the device
wants to use.
6 wHeight 2 Number The height of framebuffer that the device
wants to use.
8 bmPixelFormatSupported 4 Bitmap Bit 0: 32-bit ARGB 888 (mandatory for HSML
source)
Bit 1: 24-bit RGB 888 (deprecated)
Bit 2: 16-bit RGB 565 (mandatory for HSML
source)
Bit 3: 16-bit RGB 555 (deprecated)
Bit 4: 16-bit RGB 444 (deprecated)
Bit 5: 16-bit RGB 343 (deprecated)
Bit 6 to 31: Reserved. (it shall be all zeroes)
12 bmEncodingSupported 4 Bitmap Bit 0: RAW data (Mandatory)
Bit 1: RLE (Run Length Encoding) as defined
in [2].
Bit 2 to 31: Reserved. (it shall be all zeros)

If the endianness of framebuffer data is big endian, the device shall set bit 0 of bmCapabilities field to 1. Otherwise, it
shall set this bit to 0 to indicate that its native framebuffer is in little endian. If the device supports sending the
framebuffer only when its display data changed, it shall set bit 1 of bmCapabilities field to 1.
The device shall set wWidth and wHeight according to its framebuffer resolution.
The device shall support ARGB 888 and RGB 565 pixel formats.
The wEncodingSupported field indicates encodings of framebuffer that the device supports. The device shall support
the RAW encoding, i.e. the bit 0 shall be set to 1.
5.6.4 SetParameters
This request is used to tell the device which configuration that the host wants to use.
Table 8: SetParameters Request
bmRequestType bRequestCode wValue wIndex wLength Data
01000001B 0x42 0 The 12 HSML Configuration
interface structure (see Table 9)
number

ETSI

---------------------- Page: 12 ----------------------
13 ETSI TS 103 544-21 V1.3.1 (2019-10)
Below is the HSML configuration structure.
Table 9: HSML Configuration Structure
Offset Field Size Value Description
0 bmCapabilities 4 Bitmap Bit 0: BigEndian used
Bit 1: FBUpdateOnChange used.
Bit 2 to 31: Reserved. (it shall be all zeroes)
4 bPixelFormat 1 Number 0: 32-bit ARGB 888
1: 24-bit RGB888 (deprecated)
2: 16-bit RGB 565
3: 16-bit RGB 555 (deprecated)
4: 16-bit RGB 444 (deprecated)
5: 16-bit RGB 343 (deprecated)
6 to 31: Reserved.
32 to 255: Undefined
5 bPadding 1 0 Padding
6 wPadding 2 0 Padding
8 bmEncodingSupporte 4 Bitmap Bit 0: RAW (Mandatory)
d
Bit 1: RLE (Run Length Encoding)
Bit 2 to 31: Reserved. (it shall be all zeroes)

The host shall set bit 0 of bmCapabilities field to 1, if the endianness of its framebuffer data is big endian. Otherwise, it
shall set this bit to 0 to indicate that its native framebuffer is in little endian. The device shall follow the host's capability
and send framebuffer data accordingly.
The host should set the FBUpdateOnChange bit to avoid unnecessary USB bandwidth usage if the device supports it.
The host shall select only colour formats supported from the server. The host may send SetParameters request any time
when the host wants to change the pixel format.
The host can use bmEncodingSupported field to indicate the device what encodings it supports. If both host and device
support multipl
...