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

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS); ®
MirrorLink ; ®
Part 17: MirrorLink over Wi-Fi Display (WFD)
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-049 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-17 V1.3.1 (2019-10)

Reference
RTS/ITS-98-17
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-17 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 Introduction . 7
5 MirrorLink over WFD Procedure . 9
5.1 General . 9
5.2 Phase 1: WFD Connection Setup . 9
5.3 Phase 2: UPnP Setup . 11
5.4 Phase 3: WFD Session Setup . 12
5.5 Phase 4: WFD Operation . 14
5.6 Terminating a MirrorLink over WFD Session . 16
6 WFD Audio . 16
6.1 Audio Links . 16
6.2 WFD Audio Forward Channel . 17
6.3 WFD Audio Back Channel . 17
6.4 Telephony over WFD . 17
7 WFD User Input . 17
7.1 General . 17
7.2 UIBC Input Body Format for MirrorLink . 18
7.2.1 General . 18
7.2.2 Key Event . 19
7.2.3 Pointer Event . 19
7.2.4 Touch Event . 19
7.2.5 Sink & Source Status Events . 20
7.2.6 UI Context Event . 20
7.2.7 UI Blocking Event . 21
7.2.8 Audio Context Event . 22
7.2.9 Audio Blocking Event . 22
7.2.10 Sink& Source Cut Text Events . 23
7.3 MirrorLink Specific RTSP Data Struct ures . 23
7.3.1 General . 23
7.3.2 wfd-uibc-capability parameter . 23
7.3.3 wfd-uibc-setting parameter . 25
8 WFD Content Protection . 25
Annex A (normative): Key Event Table . 26
Annex B (informative): Authors and Contributors . 28
History . 29

ETSI
4 ETSI TS 103 544-17 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 17 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-17 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 specification describes the integration of Wi-Fi Display to MirrorLink.
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-3 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 3: Audio".
[3] ETSI TS 103 544-18 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 18: IEEE 802.11TM Car Connectivity Consortium (CCC)
Information Element".
[4] ETSI TS 103 544-12 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 12: UPnP Server Device".
[5] Wi-Fi Alliance® Technical Committee, Wi-Fi Display Technical Task Group: "Wi-Fi Display
Technical Specification" Version 1.0.0, September 2012.
NOTE: Available at https://www.scribd.com/doc/250439511/Wi-Fi-Display-Technical-Specification-v1-0-0.
[6] ETSI TS 103 544-9 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 9: UPnP Application Server Service".
[7] ETSI TS 103 544-13 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 13: Core Architecture".
[8] IETF RFC 6143: "The Remote Framebuffer Protocol", March 2011.
NOTE: Available at https://tools.ietf.org/html/rfc6143.
[9] IETF RFC 2131: "Dynamic Host Configuration Protocol", March 1997.
NOTE: Available at https://tools.ietf.org/html/rfc2131.
[10] IETF RFC 2132: "DHCP Options and BOOTP Vendor Extensions", March 1997.
NOTE: Available at https://tools.ietf.org/html/rfc2132.
ETSI
6 ETSI TS 103 544-17 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".
[i.2] Wi-Fi Alliance®: "Best Practices Document for Wi-Fi CERTIFIED Miracast™ Devices",
Version 1.0, September 2014.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
sink device: device that receives multimedia content from a WFD source over a Wi-Fi link and renders it
source device: device that supports streaming multimedia content to a WFD sink(s) over a Wi-Fi link
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Access Point
AV Audio-Video
BSS Basic Service Sets
BT Bluetooth
BVRA Bluetooth Voice Recognition Activation
CCC Car Connectivity Consortium
CDB Common Data Bus
CRLF Carrige-Return, Line Feed
DAP Device Attestation Protocol
DHCP Dynamic Host Configuration Protocol
HDCP High-bandwidth Digital Content Protection
HFP Hands-Free Profile
HIDC Human Interface Device Class
IE Information Element
IEEE Institute of Electrical and Electronics Engineers
IOP InterOPerability
IP Internet Protocol
Miracast Commercial denomination of WFD
ML MirrorLink
OUI Organizationally Unique Identifier
RFB Remote FrameBuffer
RTP Real-Time Protocol
ETSI
7 ETSI TS 103 544-17 V1.3.1 (2019-10)
RTSP Real Time Streaming Protocol
SP SPace
STA STAtion
TCP Transmission Control Protocol
TDLS Tunneled Data Link Service
UI User Interface
UIBC User Input Back Channel
UPnP Universal Plug and Play
URL Universal Resource Locator
USB Universal Serial Bus
VNC Virtual Network Computing
WFD Wi-Fi Display
NOTE: Which is the technology and specification being officially called "Wi-Fi Alliance Wi-Fi Display
specification".
WLAN Wi-Fi Local Area Network
XML eXtensible Markup Language
4 Introduction
Wi-Fi Display, also known as Miracast, is a peer-to-peer wireless screen replication standard created by the Wi-Fi
Alliance. Its main purpose is to let the source device project its screen to the sink device screen, and to provide the sink
device with the method to control the source device.
Figure 1 shows the typical Client/Server topology for the MirrorLink over Wi-Fi Display.

Figure 1: High Level Topology
The present document specifies the integration of Wi-Fi Display into MirrorLink, providing an alternative video link to
VNC. The specification of the other MirrorLink components, like UPnP, CDB, DAP etc. is done in their respective
documents.
The MirrorLink Client, providing WFD functionality, shall implement the WFD Sink functionality.
The MirrorLink Server, providing WFD functionality, shall implement the WFD Source functionality.
NOTE: The term "Sink" used in the present document refers to a WFD Primary Sink device as defined in [5].
Figure 2 displays the layered architecture diagram for the integration of WFD into MirrorLink. WFD stack is added to
MirrorLink stack. The diagram applies to both Client and Server devices, which shall apply it according to their roles.
ETSI
8 ETSI TS 103 544-17 V1.3.1 (2019-10)

Figure 2: MirrorLink over Wi-Fi Display Architecture
Through Wi-Fi Display, MirrorLink Server and Client discover each other with the Wi-Fi Device Discovery procedure,
which exchange the Information Element. WFD UIBC is integrated into MirrorLink stack for User Input.
MirrorLink Client and Server shall support all Wi-Fi Display mandatory functions and services, as described in [5],
Table 3-1. This includes the following functions and services:
• WFD Device Discovery with IE for CCC
• WFD Connection Setup
• WFD Capability negotiation
• WFD Session establishment
• Encoding and packetization of the captured Display
• Transport of multiplexed audio and video payload
• De-multiplex, de-packetization and decode of received audio and video payload
• Rendering of decoded video on local display panel
• Power Save mechanisms
• Session termination
• Encode and packetization of captured audio
• Multiplex video and audio payload
• Rendering of decoded audio on local speakers
• AV Stream Control using RTSP
The MirrorLink Client and Server shall support the following optional Wi-Fi Display functions:
• User Input Back Channel (UIBC)
Use of BT HFP in accordance with the MirrorLink Audio Specification [2] shall be possible for the MirrorLink over
WFD implementation as well.
ETSI
9 ETSI TS 103 544-17 V1.3.1 (2019-10)
5 MirrorLink over WFD Procedure
5.1 General
MirrorLink over Wi-Fi Display (WFD) connection between MirrorLink Server acting as WFD source device and
MirrorLink Client acting as WFD sink device shall take place in the 4 following phases, as depicted in Figure 3.

Figure 3: MirrorLink over Wi-Fi Display Diagram
5.2 Phase 1: WFD Connection Setup
Phase 1 shall start when MirrorLink over Wi-Fi Display is switched on. In addition, if persistent WFD Group for
MirrorLink exists, it is recommended that WFD Connection setup proceeds automatically without user interaction such
as re-selection of WFD & CCC capable device.
The following requirements apply to the phase 1:
WFD Device Discovery:
To establish a MirrorLink over Wi-Fi Display connection, Wi-Fi P2P device discovery with WFD IE
(Information Element) shall be used. Wi-Fi Display devices shall advertise the WFD IEs defined in Wi-Fi
Display specification.
In addition to the WFD IEs, the MirrorLink devices shall include the CCC Information Element that shall
contain the MirrorLink UPnP Device Information sub-element and may contain the Internet Accessibility sub-
element, as specified in [3], into all beacon, probe request and probe response frames. The MirrorLink devices
shall detect other MirrorLink devices through CCC IE.
Detection of the CCC Information Element, together with the WFD Information Element, is sufficient for a
Wi-Fi P2P device to determine that the sending Wi-Fi P2P device is supporting MirrorLink over WFD. In case
Tunneled Data Link Service (TDLS) is used, the CCC Information shall also be tunneled through the Wi-Fi
Access Point.
In case a MirrorLink Server is a Wi-Fi P2P concurrent device, i.e. connected to the MirrorLink Client's Access
Point as a WLAN STA and implements a Wi-Fi P2P device, both interfaces will belong to different Basic
Service Sets (BSS). In this case the MirrorLink Client and Server should use regular Wi-Fi P2P connection
setup to establish the WFD session.
ETSI
10 ETSI TS 103 544-17 V1.3.1 (2019-10)
Wi-Fi P2P defines 2 phases for device discovery (refer to [5] for details). In the Scan phase, P2P devices
collect information about surrounding devices or networks by scanning all supported channels. Devices may
actively send Probe Request frames to look for Legacy AP or P2P Group Owners. The Find phase has two
states, a Search and a Listen state. Within the Search state, P2P devices go through a fixed set of channels and
send Probe Requests. Within the Listen state, P2P devices wait on a fixed channel and respond to received
Probe Requests.
In case of an existing P2P Group, an existing P2P GO, or an existing Legacy AP (using TDLS), successful
discovery is possible in Scan phase, assuming that all devices are operational. In case no P2P Group exists,
one device has to be in Find/Search state, while the other device has to be in Find/Listen state to ensure
successful device discovery.
Typically, most MirrorLink Servers will only be in Scan phase in regular intervals. Additionally, a MirrorLink
Server may only go into Scan phase after a user interaction. Therefore, establishment of a MirrorLink over
WFD connection may need manual interaction from the consumer, at least for the initial connection setup.
The MirrorLink Client, supporting MirrorLink over WFD, should switch on Wi-Fi P2P and start the WFD
Device Discovery, latest when the MirrorLink Client gets powered on, otherwise the MirrorLink Client shall
provide a consumer accessible mechanism, which will enable WFD Device Discovery.
The MirrorLink Server, supporting MirrorLink over WFD, shall provide a consumer accessible mechanism,
which will enable the Wi-Fi P2P Device Discovery. This mechanism may only be usable, after the consumer
has switched on the Wi-Fi radio.
The mechanism to enable WFD Device Discovery will only ensure the Wi-Fi P2P connection setup. This
should not automatically start the WFD stream.
WFD Connection Setup
A WFD connection setup using Wi-Fi P2P shall be supported. A WFD connection setup using TDLS should
not be used.
The MirrorLink devices shall follow the process of Wi-Fi P2P/WFD as specified in [5].
The MirrorLink devices shall connect to a device, which includes a WFD IE and a CCC IE. To establish a P2P
connection for a WFD connection setup, the MirrorLink devices shall also include the CCC Information
Element that shall contain the MirrorLink UPnP Device Information sub-element and may contain the Internet
Accessibility sub-element, as specified in [3], when transmitting the P2P Invitation Request, P2P Invitation
Response, GO Negotiation Request, GO Negotiation Response, GO Confirmation, Association/Reassociation
Request and Association/Reassociation Response frames.
The Persistence WFD Group allows automatic WFD connection through caching the information for the
Group. To establish a Persistence WFD Group, the MirrorLink devices should follow the process of WFD as
specified in [5].
WFD Automatic Re-Connection
The MirrorLink Server and Client should allow for automatic reconnection, in case the devices are known, and
known to have used MirrorLink over WFD recently.
In case automatic reconnection is supported, the MirrorLink Client shall either automatically switch on Wi-Fi
P2P and start the WFD Device Discovery or shall automatically switch on Bluetooth. In case it recognizes a
known MirrorLink Server to which it had previously connected via MirrorLink over WFD, it shall
automatically attempt to reconnect, unless automatic reconnection is disabled from the consumer.
In case automatic reconnection is supported, the MirrorLink Server shall either automatically switch on Wi-Fi
P2P and start the WFD Device Discover or shall automatically switch on Bluetooth. In case it recognizes a
known MirrorLink Client to which it had previously connected via Mirror MirrorLink over WFD, it shall
automatically attempt to reconnect, unless automatic reconnection is disabled from the consumer.
MirrorLink Clients and Servers supporting automatic reconnection should implement Persistent WFD Group
over P2P.
ETSI
11 ETSI TS 103 544-17 V1.3.1 (2019-10)
Testing Considerations
MirrorLink devices may refuse to establish a Wi-Fi P2P connection to devices not capable of supporting
MirrorLink. In order to undergo Miracast conformance and IOP testing, those devices may implement a
specific test mode in which a Wi-Fi P2P session with non-MirrorLink devices is possible, which may be
disabled afterwards for MirrorLink operation.
5.3 Phase 2: UPnP Setup
Phase 1 shall be completed, before phase 2 can start.

Figure 4: UPnP Setup Sequence Diagram
UPnP Operation Start
Based on the information within the CCC IE from the WFD device discovery and WFD connection setup
stages, the MirrorLink device activates the respective UPnP components (i.e. TmServer Control Point or
TmServerServer) in the device.
The MirrorLink Client shall immediately activate its UPnP TmServerDevice:1 Control Point if it connects to a
MirrorLink device with a UPnP TmServerDevice:1 Server.
The MirrorLink Server shall immediately activate its UPnP TmServerDevice:1 Server, if it connects to a
MirrorLink device with a UPnP TmServerDevice:1 Control Point.
The MirrorLink Client shall follow the UPnP Operation Start sequence defined in the MirrorLink Core
Architecture specification [7].
UPnP Device Description
The MirrorLink Client devices shall either use the CCC Information Element, defined in [3], or shall
send an SSDP:discover message to determine the location of the MirrorLink Server's UPnP Server
Device XML. The MirrorLink Client shall not wait for an SSDP:alive messages for initial UPnP
Setup.
The structure of the UPnP Server Device XML is specified in [4]. The UPnP Server Device XML
description shall be accessible at the following URL via HTTP-GET.
http://:/
The MirrorLink Client shall form the UPnP Device Description URL with the following elements, when
using the CCC Information Element:
 IP Address: IP address of the MirrorLink Server, as retrieved with in the DHCP negotiation
with the WFD connection setup process. The DHCPOFFER message includes both, the DHCP
Server and Client IP address. The IP address of the DHCP Server can be determined during the
DHCP negotiation, according to IETF RFC 2131 [9]. A DHCP server always returns its own
address in the 'server identifier' option, as defined in IETF RFC 2132 [10].
 Port Number: Port number of the MirrorLink UPnP Server, as provided in the MirrorLink UPnP
Device Information sub-elements of the CCC Information Element as specified in [3].
 Path: Static path "TmServerDevice/TmServerDevice:1.xml".
ETSI
12 ETSI TS 103 544-17 V1.3.1 (2019-10)
EXAMPLE:
http://192.168.3.15:2869/TmServerDevice/TmServerDevice:1.xml
The MirrorLink Server shall provide the same URL to its Device XML via the CCC Information
Element and in response to the SSDP:discover message. Latest after the MirrorLink Client has
accessed the Device XML, the MirrorLink Server shall start the SSDP:alive advertisements. In
case the MirrorLink Server goes temporarily offline, it shall send an SSDP:byebye message
followed by a SSDP:alive message, when becoming online again.
UPnP Service Description
The MirrorLink Client shall follow the Core Specification [7].
MirrorLink Session Setup:
The MirrorLink Client shall follow the MirrorLink Session Setup sequence defined in the MirrorLink Core
Architecture specification [7].
The MirrorLink Client shall set its Client Profile using UPnP SetClientProfile action over the established
Wi-Fi connection.
Testing Considerations:
In order to undergo Miracast conformance and IOP testing, MirrorLink devices may implement a specific test
mode in which the UPnP Setup is bypassed. The test mode may include bypassing the setup of DAP, CDB,
and RTP connections.
5.4 Phase 3: WFD Session Setup
Phase 3 may start in parallel to the Phase 2, unless the WFD session has been setup outside the MirrorLink session.
WFD TCP connection shall be established for the purpose of WFD RTSP procedures within the time limit specified in
[5]. Similarly, the WFD session setup shall start after the establishment of TCP connection to ensure that the WFD
RTSP timeout requirements in [5] are met.
After successful exchange of RTSP M7 request/response, as shown in Figure 5, the WFD Sink may immediately send a
RTSP M9 request (PAUSE) to pause the streaming of audio and/or video content from the WFD Source to the WFD
Sink. The application launch is typically triggered from the user. The WFD Sink shall send the M7 request (PLAY) to
st
resume A/V streaming once the 1 application over WFD is launched if AV streaming has been previously paused.
Phase 3 shall not be executed, if the WFD session is already setup, e.g. triggered from a previous UPnP Application
Launch action.
Testing Considerations
MirrorLink devices may refuse to establish a WFD session to devices not capable of supporting MirrorLink
over WFD. In order to undergo Miracast conformance and IOP testing, those devices may implement a
specific test mode in which a WFD session with non-MirrorLink WFD devices is possible, which may be
disabled afterwards for MirrorLink operation.
ETSI
13 ETSI TS 103 544-17 V1.3.1 (2019-10)

Figure 5: WFD Session Setup Procedure
The following is assumed before A/V streaming in a WFD Session can start:
• WFD connection has been established between the MirrorLink Server and MirrorLink Client.
• UPnP Session has been established.
• MirrorLink Server device has been attested.
• WFD session has been setup.
• UIBC has been established and enabled.
The A/V streaming in WFD session shall be started only after the launch of the first application via UPnP, which has a
protocol identifier (protocolID) value of "WFD".
NOTE: There is no specific "WFD application", which is advertised separately via UPnP and which has to be
launched prior being able to use any user application over WFD.
The WFD Session Setup shall follow the process of WFD Display Specification as described in [5], and consist of a
number of M1, M2, M3, M4, M5, M6 and M7 messages exchanges.
ETSI
14 ETSI TS 103 544-17 V1.3.1 (2019-10)
NOTE: For further information of the messages flow of WFD Session Setup, clauses 4.6 and 4.8 in [5] can give
detail process and description.
NOTE: For further information of the WFD messages used in messages flow, clause 6 in [5] can give detail
information of format and description.
For the specific UIBC for the car usage, M3/M4 messages shall contain wfd-uibc-capability parameter. The wfd-uibc-
setting parameter shall be included in the first RTSP M4 request message during the WFD Capability Negotiation.
WFD Source shall not set any capability in the RTSP M4 Request which are not indicated to be supported by the WFD
Sink in its RTSP M3 Response.
Once the WFD session has been successfully established with the UIBC enabled, the MirrorLink Server or MirrorLink
Client shall not send any M15 Request (RTSP SET_PARAMETER) message to disable the UIBC.
The MirrorLink Server starts Audio/Video streaming to the MirrorLink Client after receiving the RTSP PLAY message
from the MirrorLink Client.
The MirrorLink Server and Client shall support 800x480p30 as the baseline configuration. Additionally, both WFD
Sink and Source should support a resolution, which is close to their native framebuffer resolution. The MirrorLink
Server should select a resolution, which is closest to the MirrorLink Client's native resolution, as provided in its M3
message (ccc-resolution-info). The WFD Source shall select a resolution, which is equal or exceeding the MirrorLink
Reference Screen resolution (800x480p30). The WFD Sink shall scale the received WFD framebuffer to the WFD Sink
device's native resolution.
Applications shall render using the highest resolution supported by the MirrorLink Client and Server as determined
during the WFD capability negotiation. They shall preserve the aspect ratio of the negotiated resolution, while not
clipping. The MirrorLink Server shall add padding if required. The MirrorLink Server shall not stretch its framebuffer
to compensate for any difference in the framebuffer aspect ratio.
The ML Server shall not send the display content if the application does not support landscape and only launches in
Portrait orientation when the ML Client is in drive mode. When the ML Client is in park mode, the ML Server may
transmit the framebuffer in Landscape even if the application launches in Portrait orientation.
5.5 Phase 4: WFD Operation
Phase 2 and 3 shall be completed, before phase 4 can start.
During the WFD Operation phase, the WFD session is controlled from the MirrorLink Client, using RTSP commands
and UIBC events. This allows the MirrorLink Client to start or pause the streaming of the MirrorLink Server's
framebuffer. In case the MirrorLink Client does not need the WFD session anymore, it can tear-down the session.
The MirrorLink Client is capable of controlling the MirrorLink Server Audio/Video streaming.
Pause Video, while Audio Continues
The sequence to pause the RTP video streaming, while audio is still being played is shown in Figure 6.
ETSI
15 ETSI TS 103 544-17 V1.3.1 (2019-10)

Figure 6: WFD Operation - Video-only Pause Sequence Diagram
In this case, WFD capability needs to negotiate for video frame skipping to be supported with video frame
skipping interval set to infinite. Refer to Wi-Fi Display Specification [5], clause 4.10.3.1 for details about
video frame skipping feature in WFD.
The MirrorLink Client shall send a UI blocking message over the WFD UIBC channel with the reason flag
"UI not visible on remote display" enabled, when it intends to pause the RTP video streaming,
while audio is still being needed.
The MirrorLink Client shall support the video frame skipping feature, specified in Wi-Fi Display Specification
[5], clause 4.10.3.1. The MirrorLink Client shall set the Max Skip Interval bits (B3:B1) in the frame-rate-
control-bitmap included in the wfd-video-formats parameter in the RTSP M3 response message to all zeros,
indicating that the maximum allowable time interval is unspecified.
The MirrorLink Server may use the video frame skipping feature to start skipping video frames. Audio will
continue to be streamed.
The MirrorLink Client shall send a UI blocking message with all reason flags set to zeros over WFD UIBC
channel, if it intends to resume the RTP video streaming. The MirrorLink Server shall stop using the video
frame skipping feature and continue to stream audio and video at the negotiated rates, if the MirrorLink Server
had enabled framebuffer skipping.
Pause Audio/Video
The sequence to pause the RTP Audio/Video streaming is shown in Figure 7.
ETSI
16 ETSI TS 103 544-17 V1.3.1 (2019-10)

Figure 7: WFD Operation - Audio/Video Pause Sequence Diagram
The MirrorLink Client shall send a WFD M9 message (RTSP PAUSE) if it intends to pause the RTP
audio/video stream. The MirrorLink Server shall acknowledge the RTSP PAUSE message and stop AV
streaming.
The MirrorLink Client shall send a WFD M7 message (RTSP PLAY), if it intends to resume the RTP
audio/video stream. The MirrorLink Server shall acknowledge the RTSP PLAY message and resume AV
streaming.
Teardown
The MirrorLink Client shall not issue an RTSP TEARDOWN command, unless the MirrorLink session ends
or the MirrorLink Client is switching to another remote UI mechanism.
Otherwise, the MirrorLink Server/Client can reconfigure the WFD session within the limits of the WFD specification.
5.6 Terminating a MirrorLink over WFD Session
MirrorLink Server and Client shall follow the procedures defined in the Core Specification [7] to disconnect a
MirrorLink over WFD session. To avoid that graceful disconnection is leading to long response timeout, if the WFD
peer is already disconnected or not responding anymore, the following behavior should be implemented:
• A terminating MirrorLink Client shall send a Set Client Profile message with an empty Client Profile, as
defined, but may disconnect prior receiving the UPnP response.
• A terminating MirrorLink Server shall send SSDP::byebye messages.
• In any case, immediate loss of Wi-Fi P2P connectivity shall be considered a termination of the ML Session,
and shall not lead to an unresponsive behavior.
6 WFD Audio
6.1 Audio Links
The selection of Audio links is specified in the respective Audio Specification [2].
ETSI
17 ETSI TS 103 544-17 V1.3.1 (2019-10)
6.2 WFD Audio Forward Channel
A MirrorLink Server shall use WFD's AV transport to provide media audio to the MirrorLink Client. The MirrorLink
Client shall not launch the MirrorLink Server's RTP Server.
BT A2DP shall not be used together with WFD. An existing BT A2DP connection to the MirrorLink Client shall be
disconnected by the MirrorLink Client. After a WFD session termination, the MirrorLink Client and Server should not
automatically reconnect the BT A2DP connection.
6.3 WFD Audio Back Channel
WFD does not provide an Audio Back Channel.
In case the MirrorLink Client intends to setup an Audio Back Channel, it shall follow the regular MirrorLink
mechanism, as specified in the Audio Specification [2]. In case the MirrorLink Client intends to use RTP, it shall launch
the MirrorLink Server's RTP Client. In case the MirrorLink Client intends to use BT BVRA, it shall launch the
MirrorLink Server's BT HFP endpoint.
The Audio Back Channel should be established before the first WFD Application is launched from the MirrorLink
Client.
6.4 Telephony over WFD
BT HFP should be used to implemented telephony functionality over WFD. In this case, the MirrorLink Client shall
launch the MirrorLink Server's BT HFP endpoint. The MirrorLink Client may use RTP based telephony audio, if
supported from the MirrorLink Server. In this case, the MirrorLink Client shall launch the MirrorLink Server's RTP
Client.
7 WFD User Input
7.1 General
MirrorLink Server and MirrorLink Client shall support User Input Back Channel as a mandatory feature of MirrorLink,
through which the user input from user interface displayed at MirrorLink Client could be communicated back to
MirrorLink Server. In addition, user interface related output and status events are exchanged through the User Input
Back Channel.
The User Input Back Channel will also be used for certain messages in the forward direction (MirrorLink Server/WFD
Source to MirrorLink Client/WFD Sink). Traditionally, the UIBC channel is used for messages going from the WFD
Sink to the WFD Source but in MirrorLink, this channel will be used for messages going in both directions.
Messages from MirrorLink Client to MirrorLink Server include the following types:
• Key event;
• Pointer event;
• Touch event;
• Sink Status event;
• UI Blocking event;
• Audio Blocking event;
• Sink Cut Text event.
ETSI
18 ETSI TS 103 544-17 V1.3.1 (2019-10)
Messages from MirrorLink Server to MirrorLink Client include the following types:
• Source Status event;
• UI Context event;
• Audio Context event;
• Source Cut Text event.
All UIBC user input & output shall be supported by using an Input Category set to a value 15 (defined in [5] as a
Reserved input category, the Generic and HIDC categories may not be supported in MirrorLink setup). The Input
Category value 15 is used as a Vendor-Specific category for MirrorLink. The Vendor Specific input body format for
MirrorLink is described in clause 7.2.
7.2 UIBC Input Body Format for MirrorLink
7.2.1 General
The payload structure for packetizing UIBC user inputs are specified in clause 4.11.1 (UIBC Data Encapsulation) of
[5].
NOTE: The UIBC input body field should be padded up to an integer multiple of 16 bits to have an even integer
number in the Length field as recommended in the WFD specification [5].
All MirrorLink specific UIBC inputs shall use the Input Category field set to Vendor-Specific input category (value set
to 15), and the format for the UIBC Input Body field is as shown in Table 1.
Table 1: UIBC Input Message Format for MirrorLink
Field Size (Octet) Value
OUI 3 04-DF-69 (CCC specific OUI)
Type ID 1 User Input type event ID as listed in Table 2
Length 2 Length of the following fields in octets
Descriptor Variable The details of the user inputs

The specified input type events are listed below in Table 2 together with their obligation for the MirrorLink Server and
Client. The support and capabilities of some input events are available from the provided field within the wfd-uibc-
capability parameter (specified later in clause 7.3.2). If the parameter field is provided as "None", the input event does
not have a corresponding field in the wfd-uibc-capability parameter.
Table 2: Type IDs for Vendor-Specific UIBC Category for MirrorLink
wfd-uibc-capability
Type ID Notes Origin Obligation
parame
...