Whenever a host detects an under-budget scenario, it can either keep the current MAC Layer channel reservation (and endure the performance (throughput) impact), or it may grow its MAC Layer channel reservation appropriately in order to provide better service for the duration of the increased Wireless USB Channel communication load. Modifications to the overall MAC Layer channel reservation are accomplished via changing the DRP IE information for the Wireless USB Channel in both the host’s and Cluster device’s Beacons.

4.3.5Device Endpoints

Wireless USB preserves the device Endpoint as the terminus of a communication flow between a host and a device. Wireless USB Endpoint characteristics are extended from the wired counterparts, in particular to support security and efficiency. As with USB 2.0, all Wireless USB devices must implement at least the Default Control Pipe (Endpoint zero). The Default Control Pipe is a Control pipe as defined in the USB 2.0 specification and is available once a device has completed the initial connection data exchange (see Sections

4.3.8and 4.3.7).

4.3.6Wireless USB Information Exchange Methods

The types of information exchanges between a host and its associated devices via the Wireless USB Channel are characterized by three basic functional buckets: host transmitted control information, asynchronous device transmitted control information and Wireless USB transaction protocol (between a host and function endpoints). Wireless USB defines the following methods of information exchange:

•Wireless USB Device Notification Time Slots. Wireless USB allocates specific ‘management’ channel time (Device Notification Time Slots (DNTSs)) for asynchronous, device initiated communications. This asynchronous upstream (i.e. Device to Host) communication is used for signaling connect, remote-wake and other events that are analogous to the wired signaling events that occur in wired USB. It is also used as a general purpose device-to-host notification mechanism through which devices can transmit asynchronous command, status and request messages to host. This channel time may only be used for Wireless USB Device Notification Messages as defined in Sections 5.5.3 and 7.6.

•Broadcast Control Information. All Wireless USB data communications occur within the Wireless USB Channel using a host-scheduled protocol. A host transmits control packets called Micro-schedule Management Commands (see Section 7.5 for the definition of MMCs), which contain control information to devices, including acknowledgements to Device Notifications and general purpose Wireless USB Cluster management.

•Wireless USB Transactions. Wireless USB data communications between the host and function endpoints utilize a transaction-based communication protocol similar to the USB 2.0 transaction protocol.

Most packets transmitted between a host and devices in the Wireless USB cluster are encapsulated in MAC Layer secure packets. The only exceptions to this rule pertain to those data exchanges required to establish initial association (i.e. before a secure relationship is established).

4.3.7Device Perspective

A Wireless USB Device must implement all of the required features of the Wireless USB protocol (see Chapter 5) in order to communicate via a Wireless USB Channel. The Wireless USB Channel is encapsulated by the MAC Layer channel, so it is possible that Wireless USB devices can be implemented that don’t know about the MAC Layer channel. It is also possible to add MAC Layer compliant device capability to a Wireless USB Device. A device always uses the Wireless USB Channel and the communication protocol defined in this specification to connect and communicate within a particular Wireless USB Cluster. A host can request a device’s MAC-layer channel capabilities so that the host will know whether it needs to manage MAC Layer mechanisms for the device (see section 4.3.8.4).

Section 4.13 details a device’s requirements to participate in the Wireless USB Cluster Connection process.

27

A device that implements the full MAC Layer protocol is called a ‘Self Beaconing’ device. A device that is not aware of the MAC Layer channel and instead relies on the host to help it be a good MAC Layer citizen is called a Directed Beaconing Device. Devices that are unaware of the MAC Layer channel and have restricted transmit and receive capabilities such that they don’t need to beacon are called Non Beaconing Devices. Hosts identify the class of a device from the Beacon Behavior field of the Wireless USB Device Capabilities – UWB descriptor (see Section 7.4.1.1). These three classes of devices are described in more detail below.

4.3.7.1Self Beaconing Devices

A device that implements the full MAC Layer protocol is called a ‘Self Beaconing’ device and it knows how to manage the MAC Layer channel including synchronization and maintenance of MAC Layer Beacon periods. A Self Beaconing device must support several Wireless USB device requests in order to allow the host to manage DRP reservations.

Self Beaconing devices must be able to determine which MAS slots are available for communication with the host. All DRP reservations seen by the device, except the reservations that comprise the Wireless USB channel reservation, must be excluded from the devices MAS availability information. Section 7.7 summarizes the value settings for DRP IEs for the host and cluster members that are beaconing. The device identifies the host’s DRP IE based on the following keys:

•Reservation Type field is Private

•Stream Index field has the value of the Wireless USB channel’s stream index. This is derived from the MAC Header Delivery ID field.

•DevAddr field set to the channel’s Broadcast Cluster ID.

The device identifies a cluster member’s DRP IE based on the following keys:

•Reservation Type field is Private

•Stream Index field has the value of the Wireless USB channel’s stream index. This is derived from the from the MAC Header Delivery ID field.

•DevAddr field set to the host’s DevAddr.

A host uses the GetStatus(MASAvailability) request to retrieve a device’s MAS availability information. A host uses the SetWUSBData(DRPIEInfo) request to provide the device with the appropriate DRP IE to include in the device beacon. The host uses a SetFeature(TX_DRPIE) request to instruct the device to start including the provided DRP IE in its beacon. A Self-beaconing device may detect reservation collisions (as defined in the MAC Layer specification) and can notify the host of a MAS Availability information change using the DN_MASAvailChanged notification. A host uses a ClearFeature(TX_DRPIE) request to instruct a device to cease transmitting the DRP IE in its beacon. Details on all of these requests can be found in Section 7.3.

4.3.7.2Directed Beaconing Devices

A device that only implements the Wireless USB channel must support Wireless USB defined capabilities that allow a host to learn about neighbors of the device that are out of range from the host, but in range of the device (called hidden neighbors), and to have the device transmit a beacon defined by the host. These capabilities are required for several reasons, including ensuring the MAC Layer reservations (DRPs) are observable to hidden neighbors so they can be respected. Devices that support these capabilities are called ‘Directed Beaconing’ devices.

Directed beaconing devices must support three functions: Transmit Packet, Count Packets, and Capture Packet. Hosts must ensure that devices are never enabled for more than one of these functions at a time.

28

4.3.7.2.1Transmit Packet Function

The Transmit Packet function is typically used to have the directed beaconing device transmit a beacon packet at regular intervals. In order to do this, the device needs to know what packet data to transmit and when to transmit that packet.

The host provides the complete packet data that the device transmits using the SetWUSBData(Transmit Data) standard device request (see Section 7.3.1.5). The information provided to the device is the complete MAC header and payload (without FCS). The device is responsible for building a properly constructed packet with the provided MAC header and payload. Directed beaconing devices must have 200 bytes of buffering to store the transmit packet data.

To tell the device when to transmit the packet, the host provides two values to the device. The first value is a 24-bit Transmit Time. The second value is an 8-bit Transmit Adjustment. When enabled for directed packet transmission, the device will first send the transmit packet when USB channel time matches the host provided Transmit Time. After transmitting the first packet, the device will continue to transmit the packet every 64K (216) + Transmit Adjustment microseconds as long as it is enabled for directed packet transmission. The host provides the necessary time values using the SetWUSBData(Transmit Params) standard device request (see Section 7.3.1.5). A host must not send a SetWUSBData(TransmitParams) command to a device that is already enabled for directed packet transmission. A host can change the transmit adjustment value to all devices currently enabled for directed packet transmission by adding a Transmit Packet Adjustment IE to transmitted MMCs. When a device receives a Transmit Packet Adjustment IE, it will use the new Transmit Adjustment value for all intervals after the next Transmit Time occurs.

A host enables a device for directed packet transmission by sending the device a SetFeature (DEV_XMIT_PACKET) request. Hosts are responsible for initializing the transmit packet data and time values before enabling a device for directed packet transmission. Devices are disabled for directed packet transmission after reset and when they receive a ClearFeature (DEV_XMIT_PACKET) request. See the Section 7.3.1 for complete descriptions of these requests. Devices are also disabled for directed packet transmission anytime the device goes to sleep (see Section 4.16.1.1) or exits the Authenticated device state.

4.3.7.2.2Count Packets Function

The Count Packets function causes the directed beaconing device to receive for a period of time and have the device record how many packets were received, store some basic packet information, and record when the packets were received. Hosts can use this functionality to have the device scan other PHY channels to see if the device sees any activity on that channel, or to scan during a beacon period to see if the device sees any beacons that the host doesn’t see.

The host uses SetWUSBData(Receive Params) standard request to provide the device with the USB channel time window, bounded by Receive Start Time and Receive End Time, during which the device should receive. The host also provides a PHY channel parameter telling the device which channel to receive on, and a packet filter parameter, Receive Filter, that the device uses to match and record particular packets. See Section 7.3.1.5 for details on this standard request and its parameters.

A host enables a device for counting packets by sending the device a SetFeature (COUNT_PACKETS) request. Hosts are responsible for appropriately initializing the device with a SetWUSBData(Receive Params) request before enabling a device for directed packet transmission. Devices are disabled for counting packets after reset, when they have completed a count packet function, when the capture buffer is full, or when they receive a ClearFeature (COUNT PACKETS) request. See the 7.3 for complete descriptions of these requests.

When enabled for counting packets, the device will logically go through the following steps:

•When USB channel time matches Receive Start Time, the device begins trying to receive packets. The device will continue to try to receive packets until the USB channel time matches Receive End Time, at which time the device will disable itself for counting packets.

•For every correctly received header, the device will extract the Frame Type field from the Frame Control field of the MAC header and generate an 8-bit value with one set bit that corresponds to the

29

value of the Frame Type field. For example, if the Frame Type field has a value of three, then bit 3 of the generated value will be set. The device then does a logical AND of this generated value with its Receive Filter value and if the result is non-zero then the device proceeds to the following steps. If the logical AND of those fields is zero, then the device waits for the next packet.

•For packets that pass the filter, the device records the channel time when the packet was received (time marker is the beginning of the preamble), the first six bytes of the MAC header (Frame Control, DestAddr, SrcAddr), and the LQI of the received packet.

Devices must have 512 bytes of receive data buffer space to store count packet information. Note that this buffer can be the same buffer used for the Capture Packet function. This buffer cannot be the same as the transmit packet buffer.

A host can retrieve the recorded information by sending the device a GetStatus (Received Data) request. In addition to the recorded information, the device will indicate how many packets were recorded and if the receive data buffer space was filled before the count packet function was complete. The device will return the recorded information in the format described in Section 7.3.1.2.

4.3.7.2.3Capture Packet Function

The Capture Packet function causes the directed beaconing device to try to receive and store a single packet during a specified period of time. The common host usage for this is to have a device try to receive and store a packet during a particular MAC Layer beacon slot so that the host can see the full beacon contents.

The host uses SetWUSBData(Receive Params) standard request to provide the device with the USB channel time window, bounded by Receive Start Time and Receive End Time, during which the device should receive. The host also provides a PHY channel parameter telling the device which channel to receive on, and a packet filter parameter, Receive Filter, that the device uses to match and record particular packets. See Section 7.3.1.5 for details on this standard request and its parameters. Note that this interaction is identical to that done when counting packets.

A host enables a device for capturing a packet by sending the device a SetFeature (CAPTURE_PACKET) request. Hosts are responsible for appropriately initializing the device with a SetWUSBData(Receive Params) request before enabling a device to capture a packet. Devices are disabled for capturing a packet after reset, when they have captured a packet that matches the filter criteria, when the receive period has terminated, or when they receive a ClearFeature (CAPTURE PACKET) request. See Section 7.3 for complete descriptions of these requests.

When enabled for capturing a packet, the device will logically go through the following steps:

•When USB channel time matches Receive Start Time, the device begins trying to capture a packet. The device will continue to try to capture a packet until the USB channel time matches Receive End Time or a packet is captured. After USB channel time matches Receive End Time or capturing a packet that matches the specified filter criteria, the device will disable itself for capturing packets.

•For every correctly received header, the device will extract the Frame Type field from the Frame Control field of the MAC header and generate an 8-bit value with one set bit that corresponds to the value of the Frame Type field. For example, if the Frame Type field has a value of three, then bit 3 of the generated value will be set. The device then does a logical AND of this generated value with its Receive Filter value and if the result is non-zero then the device proceeds to the following steps. If the logical AND of those fields is zero, then the device waits for the next packet.

•For a packet that passes the filter, the device records the channel time when the packet was received (time marker is the beginning of the preamble), stores the MAC header and payload of the packet, and stores the LQI of the received packet.

Devices must have 512 bytes of receive data buffer space to store capture packet information. Note that this buffer can be the same buffer used for the Count Packets function. This buffer cannot be the same as the transmit packet buffer.

30