3.2.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model, provided their external behavior is consistent with that described in this document.

Source ID: A Source ID TLV (section is maintained throughout the lifetime of the Miracast session. It is included in all Miracast messages (section 2.2) to identify the Miracast Source.

Sink Capabilities: The data within a Capability attribute (section received from a Sink is maintained from the discovery phase until the connection setup is complete. It is used to determine what connection features the Sink supports.

Selected Sink Capabilities: For each Sink Capability, the Source stores whether it is using that capability for this connection.

PIN: In case the connection is using a PIN display on the Sink, the Source may request the user to enter the PIN asynchronously while performing the connection setup steps. The Source stores this PIN until after the DTLS handshake is complete and it needs to send the PIN Challenge message (section 2.2.5). Defaults to null.

DTLS Encryption Key: The key that is derived from the DTLS handshake. Defaults to none.

Connection Sequence

Figure 5: Connection Sequence