options that can be utilized by the host or endpoint to attempt to prevent discards from occurring. These options are described in Section 4.10.

4.12Device Reset

Wired USB uses specific electrical signaling on the D+ and D- lines to signal a USB reset to the device. Upon receipt of reset signaling, the device enters the USB Default state and sets its USB address to the Default Address (0).

Wireless USB does not have the option of using specific electrical signaling to signal a reset to the device. Instead, the action must be initiated by sending a ResetDevice_IE which targets a particular device (see Section 7.5.11). This IE is targeted to a particular device via that device’s CDID value. The device that decodes the ResetDev_ID that matches the CDID must perform an effective ‘hard’ or ‘power-on’ reset and return to the UnConnected device state (see Section 7.1 for definition of all device states). The intent of this form is to provide the host some mechanism to quickly reset a device when there may be some ambiguity about what state the device is in or what device address it is at.

Wireless USB also provides for a lighter form of device reset, via SetAddress (zero). For Wired USB devices, device response to Set Address with a value of 0 is undefined. For Wireless USB devices, a device receiving a Set Address with a value of 0 resets its address to the Default Address and enters the Default state. Any existing endpoint state is lost. Connection state is not reset. The intent of this form is to reset the function on the device without completely removing the device from the cluster.

4.13Connection Process

USB 2.0 association is based on a device-initiated model, e.g. the device detects power on its upstream port and signals a Connect by asserting D+ (or D-), which is detected by the associated port and eventually responded to by the host with a Port Reset and subsequent information exchange over the Default Endpoint. Wireless USB implements a similar device-initiated connection model, i.e. the device finds and initiates a connection with its host. The general model of the connection process and roles each device plays are described in the remainder of this section. Details of the mechanisms used to implement this process are defined in the Protocol (Chapter 5) and Framework (Chapter 7).

Hosts include a Host Information IE in selected MMCs. The host also (via the MMCs) makes available DNTS opportunities which may be used by devices to transmit connect requests to the host.

The host reserves MAC Layer channel time across the super frame for the Wireless USB Channel, and will then randomly move the location of the DNTS window(s) for connect opportunities within the Wireless USB Channel, so that they overlay different MAS slots over time, see Figure 4-44.

76

Figure 4-44. Example Connection ‘Random Hop’ DNTS Placement over Time

The security framework (see Section 6.2.8) requires that devices retain information about the host it was previously connected to (Connection Context). The Connection Context may be initialized for ‘new’ devices via out-of-band ‘provisioning’ methods which establish on a device, information about its intended host including the host’s name (Connection Host ID - CHID) and a secret shared with for that host. A ‘new’ device may also support being provisioned via the Default Control Pipe. This is referred to as in-band provisioning. For most scenarios, whether by out-of-band provisioning or simply residual information from a previous connection, the host’s identity is usually known before the device attempts to connect. See below for details on the connection process when a CHID is not known by the device prior to an association attempt.

An unconnected “provisioned” device that is looking to establish a connection with a known host locates a MAC Layer channel which encapsulates the Wireless USB Channel being maintained by its intended host. The device locates the correct Wireless USB Channel by capturing and processing MMCs in each observable Wireless USB channel looking for an MMC that contains a Host Information IE with a CHID value that matches the CHID in the device’s local host context. When a match is found it then follows the MMC control stream in the Wireless USB Channel looking for a DNTS opportunity during which it will attempt to transmit a DN_Connect notification. A device making a connection always uses the UnConnected_Device_Address when transmitting a DN_Connect notification to the host (see Section 7.6.1). The payload of this request includes (at least) the device’s name (Connect Device ID, e.g. CDID) which is 16 bytes of device unique information. The device then waits for a Connect Acknowledge response (see Section 7.5.1) which includes the device’s name (i.e. CDID) from its DN_Connect notification and a Wireless USB channel device address. The device must retransmit the connect notification until it successfully receives a connect acknowledge from the host (see below). Retransmissions are implementation-specific, but should occur no more frequently than three times per 100 milliseconds. A device attempting to connect should check all Host Information IEs it encounters to ensure that the host remains open for connection requests.

When a host receives a connect notification, it allocates a Device Address from the UnAuthenticated_Device_Address_Range and then includes a Connect Acknowledge IE in a subsequent MMC. The host must retransmit the connect acknowledgement until it observes the device responding to control transfers to its Default Control Pipe at the assigned Wireless USB channel address. The rate of retransmission is host-implementation specific.

On reception of the connect acknowledgement, the device updates its Wireless USB channel device address and then begins listening on the Wireless USB Channel for host transactions directed to its Default Control Pipe at the new device address. If the device is a Self-beaconing device (as identified in the DN_Connect notification), the host can quickly determine the devices’ optimal MAC Layer channel time to accomplish data communications via its MAS Availability information. The device then proceeds through the Authentication process which is driven by the host using control transfer requests over the device’s Default Control Pipe.

77