4.17Dual Role Devices (DRD)

Wireless USB allows a device to simultaneously function as both a host and Wireless USB Device[s] on a single transceiver. Any numbers of scenarios are possible including ‘combination’ and ‘point-to-point’ scenarios. A combination scenario is one where a device is connected ‘upstream’ to one or more separate Wireless USB Channels as a device and at the same time manages its own Wireless USB Channel as a host. An example of a combination scenario is a Wireless USB printer which could be connected as a device on one or more Wireless USB Channels and at the same time provides a Wireless USB channel for connecting cameras. A point-to-point scenario is one where two Wireless USB DRD devices connect as both a host and Wireless USB device to each other.

In the “combination” scenario, Wireless USB DRD-Host and Wireless USB DRD-Device[s] are logically independent. They just operate as a Wireless USB host and Wireless USB device[s] respectively.

In the “point-to-point” scenario, two Wireless USB DRDs linking to each other by one upstream and one downstream Wireless USB link, are called paired P2P-DRDs. The Wireless USB link that is established first is called the default link; the link that is established later is called the reverse link. Paired P2P-DRDs must co-exist on the same MAC Layer channel. The pairing process between two P2P-DRDs is a two-stage establishment of the default link and the reverse link.

Both default link and reverse link share the same connection context [CHID, CDID and CK] and session context [SFC, data keys and management keys]. Therefore, P2P-DRD’s CHID on the default link is the same as P2P-DRD’s CDID on the reverse link. Only the DRD-Host of the default link can modify these contexts.

A two stage establishment process is described in the following sub-sections:

•Discover P2P-DRD Host to establish default link

•Pair P2P-DRD to establish reverse link

4.17.1Discover P2P-DRD Host to establish default link

There are two kinds of P2P-DRD discovery processes:

•User-instructed discovery process for the first time connection

•Self-discovery process for re-connections.

During first time connection, the P2P-DRD that is powered-up first will be the DRD-Host. The second P2PDRD will scan the medium and finds its corresponding P2P-DRD Host. It will connect to this P2P-DRD Host as a P2P-DRD Device.

A P2P-DRD capable host shall set the P2P-DRD capable bit to one in the Host Information Element in its MMCs. This allows a P2P-DRD capable device to scan its proximity and locate a P2P-DRD Host.

After both P2P-DRDs complete the connection process, they have their connection context and the default link. Then the host enumerates the device. The P2P-DRD device shall return a Device Capability Descriptor with P2P-DRD capability set to 1. Once the DRD-Host finds the device is a P2P-DRD device, it goes to establish a reverse link as specified in Section 4.17.2.

For the re-connection case, paired P2P-DRDs in the previous session keep their role as before, and re-establish the default link through the re-connection process. User intervention may be necessary if the P2P-DRDs cannot reconnect to each other within an acceptable period of time.

4.17.2 Pairing P2P-DRD to establish reverse link

After the default link succeeds in the authentication phase of the connection process, the P2P-DRD host on the reverse link shall allocate its beacon slot and wireless USB cluster on the same MAC channel, set P2P-DRD capable bit to one in the Host Information IE of its MMCs and open to re-connection.

85

After the P2P-DRD host on the default link finds the wireless USB device is a P2P-DRD device, as a device on the reverse link, it starts to locate the host on the reverse link whose CHID value is the same as its CDID value on the default link.

P2P-DRDs on the reverse link use the same connection context on the default link to re-connect each other; and skip the authentication phase of the connection process. They authenticate each other by using secure USB control transfer – SetAddress(0).

During enumeration phase, the P2P-DRD device on the reverse link shall return a Device Capability Descriptor with P2P-DRD capability clear to 0.

In order to self-establish the default link in the future, both successfully paired P2P-DRDs shall remember their connection context and respective roles on the default link.

86

Chapter 5

Protocol Layer

This chapter presents a bottom-up view of the Wireless USB protocol starting at packet format definitions inherited from the MAC Layer standard and the application-defined extension required for Wireless USB. This is followed by a detailed description of Transaction Groups and basic transaction formats followed by detailed Transaction Group timing requirements. The next section provides a detailed description of data bursting, transaction level fault recovery, link-layer data flow for each transfer type and a summary of the flow-control protocol. The last section contains PHY and MAC-specific timing and header information.

5.1Packet Formats

Wireless USB uses the packet (Frame) formats defined in the MAC Layer standard. The general structure of a packet is that it contains a PHY Preamble, PHY Header and MAC Header followed by a data payload (MAC frame body) which can be transmitted at a signaling rate different than that of the PHY and MAC Header (see top of Figure 5-1). The PHY layer provides standard support for error correction for all bits in the logical packet (PHY/MAC Header plus frame body). The PHY also CRC checks the PHY and MAC Header. The Frame Check Sequence field, which is the CRC value for the frame body payload is managed by the MAC layer. See the MAC Layer standard for implementation requirements. Note that when the Security bit component of the Frame Control field is set to zero (0), the security-related fields are not present in the packet. These fields are TKID, Rsrvd, Encryption Offset, SFN, and MIC. These fields are present if the Security bit is set to one (1).

Section 5.6 summarizes the MAC Layer packet types (MAC Header field) used in the Wireless USB protocol. Wireless USB uses both the secure and non-secure packet formats defined in the MAC Layer standard.

Cypher Text

(Encrypted Data)

Figure 5-1. General Format of a Wireless USB Application Packet

The terminus of data communication flows on a Wireless USB device is the same as that of a wired USB device; i.e. an Endpoint. Wireless USB addressing has three basic parts:

1.All packet transmissions (using a MAC frame type of Data Frame) during a Wireless USB DRP use the same stream index value in the stream index field of the MAC Layer Header. The stream index

87

value is allocated by the host when establishing a Wireless USB Cluster. Devices learn this value from the Host Information IE.

2.Every device in the Wireless USB Cluster is assigned a unique device address (relative to the cluster) during the enumeration process. The assigned device address is equivalent to the wired USB device address. Note that the host has an effective device address which is the generated DevAddr value necessary to conform to MAC Layer addressing requirements. Every packet transmission includes the transmitter’s device address in the MAC Layer MAC Header SrcAddr field and the targeted devices’ device address in the MAC Layer MAC Header DestAddr field. The exception to this is the MMC packet which uses the Broadcast Cluster ID in the DestAddr field.

Due to artifacts of the MAC Layer operation, the host may need to change its MAC Layer device address (i.e. the value it uses in the SrcAddr field of any host-to-device or host to Cluster Broadcast Address transmission). When devices transmit packets to the host, they must use the MAC Layer device address from the MMC’s SrcAddr field in the device’s DestAddr field.

3.Wireless USB packets which originate or terminate on a function endpoint must include a Wireless USB Application header (see below for details). The Wireless USB Application Header serves several purposes one of which is to carry Endpoint Number addressing information.

In summary, the DestAddr field in the MAC Header is used by host and device MACs to determine whether received packets should be ignored. The Stream Index and SrcAddr fields in the MAC Header are used by the host and device to deliver received packets to the Wireless USB application (one of possibly several distinct applications simultaneously using the radio resource). The device uses the Endpoint Number field in the Wireless USB Application Header to deliver the data to the correct endpoint buffer. The host uses Endpoint Number and SrcAddr field (from the MAC Header) to deliver the data to the appropriate endpoint buffer.

The Wireless USB Application Header is located immediately after the security header fields and is included in all packets originating or terminating at an Endpoint. The format of the Wireless USB Header is detailed in Table 5-1. The length of the Wireless USB Header is different, depending on the value of the PID field. The shaded portion of the table indicates the fixed or common portion of the Header, which must be present, regardless of the value of the PID field. Isochronous data phase data packets use the IDATA PID and have an additional variable length header section following the common Wireless USB header. The additional information for headers with the IDATA PID must contain the fields for at least one data segment as shown in white in Table 5-2. Additional fields for additional data segments are optional and shown in grey in Table 5-2.

Table 5-1. Wireless USB Data Packet Header Format Details (rWUSBHeader)

88

Table 5-1. Wireless USB Data Packet Header Format Details (rWUSBHeader) (cont.)

Refer to Section 4.10.2 for details on the use of the bmStatus.Flags.LastPacket field.

89

The Isochronous packet header, when present is always concatenated to the standard Wireless USB packet header. Therefore, the Offsets in Table 5-2 are relative to the position of the standard Wireless USB packet header.

Table 5-2. Wireless USB Data Packet Header Details for Isochronous Packets

90

Table 5-3. Wireless USB PID Types

On reception of a data packet the receiver will strip the Security, Wireless USB Headers, the Security Checksum, and Isochronous Headers (when appropriate) before delivering the data to the appropriate application buffer (on the host or device). Note that all checksums and decryption checks must complete successfully before the receiver is allowed to commit any action related to the packet, including generating a handshake, notifying an application that data is available, etc. The application payload bytes illustrated in Figure 5-1 are the Wireless USB equivalent to the data field of a wired USB data packet. For asynchronous data streams, the rules for sending data between a Wireless USB host and device are the same as for the wired case (e.g. a multi-packet data request by a client application is expected to be delivered with data packet payloads of maximum packet size until the last data payload which may be less than a maximum packet size). This allows short-packet semantics to be used for Wireless USB data streams.

There are four basic packet types used to communicate information in the Wireless USB protocol. The use of secure or non-secure packet encapsulation depends on the context of use unless specified otherwise. The MAC Layer may provide a programmable AcK mechanism where each data packet can be marked by the transmitter by a code indicating the AcK policy. The Wireless USB protocol described here exclusively utilizes a MAC Layer no-AcK policy (e.g. no immediate MAC Layer defined AcKs used). Whenever the host is expecting any

cluster device to transmit, it must be listening at least two maximum drift times (2*tMAXDRIFT) before the Wireless USB channel time it determines when the device should start transmitting, based on its local clock.

•The MMC (Micro-scheduled Management Command) packet (see Section 5.2). MMC packets use the Application-defined Control Frame format defined in the MAC Layer standard. MMC packets are a Cluster broadcast control packet, effectively addressing all devices in the Wireless USB Cluster, and therefore do not include a Wireless USB Header (see Table 5-1). MMC packets are the management thread for the Wireless USB Channel, so must be transmitted at the most reliable bit transfer rate (i.e. PHY Base signaling rate). MMC packets are always transmitted using secure packet encapsulation with the Encryption Offset field in the Security Header set to the length of the MMC payload. Note that the host uses the Wireless USB Group Key to generate the MIC for MMC packets.

•A protocol data packet. Protocol data packets are encoded as Data Frame in the MAC Header. Protocol data packets can be transmitted by either a host or a device and can only be transmitted during

a WDRCTA or WDTCTA time slot (see Section 5.2.1). Protocol data packets must include the Wireless USB Header. In addition they must be transmitted using secure packet encapsulation unless explicitly specified otherwise. When secure packet encapsulation is present, the Encryption Offset field in the Security Header is set to a value of 2, so that the Wireless USB Header is transmitted in plain text. The entire body of the application payload is encrypted. Protocol data packets have the Wireless USB Header bmAttributes.PID field set to DATA or IDATA and the bmAttributes.EndpointDirection field

91