Once the host and device have completed mutual authentication, each has the proper session key for encrypting/decrypting protocol data and handshake packets. The host completes the connection process with two final steps. First, it uses SetKey() to give the device a copy of the Wireless USB cluster group key. The device requires this key in order to authenticate MMCs packets. At this point, the device and host have a secure relationship established. The final step in the connection process is the host uses SetAddress() to set the device’s device address to zero, which transitions the device into the USB 2.0 equivalent of the Default device state.

A device that has no valid Connection Context but is capable of being provisioned via the Default Control Pipe may request a connection with a host provided the host indicates that it is accepting connections from unknown devices. This advertisement is further described in Section 7.5.2. When the device locates a host making such an advertisement, the device makes an attempt to connect as described above, indicating the connect request is for a New connection. Such a device must also create a temporary CDID value to use in the connect request.

This is covered in more detail in Section 6.2.10.3.

The connection process proceeds as described above and the device transitions to the UnAuthenticated device state. While in this state, the host will determine the provisioning capabilities of the device and attempt to provision the device with a valid Connection Context. This provisioning involves establishing a common security mechanism, e.g. public key cryptography to protect the Connection Context. Once the Connection Context has been delivered to the device, the host will initiate the mutual authentication 4-way handshake. When the 4-way handshake is successfully completed, the host and device complete the establishment of the connection as described above.

4.13.1 Reconnection Process

A device may lose contact with its host (i.e. not receive any valid host packets) for a period of time longer than the TrustTimeout (see Section 6.2.10.2). Whenever a TrustTimeout occurs, the device begins listening for its host (as it does from the UnConnected state). When it reacquires its host’s Wireless USB channel, the device makes a reconnect request to the host. A reconnect request is simply an encrypted DN_Connect device notification with the Previous Address field set to the device’s current USB address. This notification is simply asking the host to be allowed to resume operation at that address. If the host does not remember the device (cannot decrypt the notification), it will not respond to the connect notification and the device should then try to re-connect from the UnConnected device state (i.e. unencrypted DN_Connect). The host may acknowledge the DN_Connect with either the device’s previous address or a device address in the UnAuthenticated device address range. The host will then initiate the authentication process. If this completes successfully, the device returns to its previous operational state (i.e. before the TrustTimeout). Note the host may need to restore the device’s previous address via a SetAddress(previous address) command before the device is restored to its previous operational state. Note, Section 7.1 provides a detailed device state diagram and summary description of all the device states.

Note that a host has the option of not being available for connections as represented in the Host Information IE (see Section 7.5.2). When a host is reporting that it is not available for connect requests, it must remain available for reconnect requests, as defined above.

4.14Disconnect

Wireless USB supports two disconnect models: explicit and implicit, however neither is equivalent to the USB 2.0 disconnect model. The explicit disconnect model allows the host or device to initiate a disconnect event. When the host initiates a disconnect event, it is essentially removing the device from its Wireless USB cluster (i.e. tears down the secure relationship, frees up internal resources for tracking the device, etc). When the device initiates a disconnect event, it is simply notifying the host that it is leaving the cluster so that the host can explicitly ‘forget’ the secure relationship, etc. Disconnected devices may attempt to reconnect at any time. A host initiated disconnect event has the following process:

•The host sends three consecutive WDEV_Disconnect_IEs or WHOST_Disconnect_IEs (to disconnect all devices in cluster).

•The device disconnects immediately and enters the Un-Connected state.

A device initiated disconnect event has the following process:

78

•A device sends a DN_Disconnect notification during a DNTS period to notify the host (see Section 7.6.2). This notification tells the host that the device is going to disconnect. The device should wait for a response from the host before disconnecting and should retry at least twice before disconnecting if no host response is observed.

•The host responds to the device DN_Disconnect notification in a subsequent MMC with a WDEV_Disconnect_IE, targeting the requesting device. The device disconnects immediately and enters the Un-Connected state when it sees the host response.

In wired USB, a disconnect event has significant impact on both the host and device state. The host releases buffers and the device address because it knows the device is gone and relies on the wired connect and device enumeration events to occur to return the device to operation. There are many scenarios for the wireless environment (interference, distance change, security, etc.) where it is desirable to be flexible about when to detect an actual disconnect event and trigger release of resources and force a full re-enumeration and initialization. The implicit disconnect model embodies this flexibility.

The basic model of the implicit disconnect is tied to the TrustTimeout threshold. In general, Wireless USB requires the host and device to keep its notion of TrustTimeout intact. This leads to a consistent user experience because when they attempt to use an idle device, chances are good that the device is available (or will be available in a reasonable amount of time). A host may implement a policy where a device is ‘disconnected’ whenever the host observes a TrustTimeout for that device.

The mechanisms defined to accommodate refresh of the Trust relationship are different, depending on the operational state or communications load on the device (device scenario). The mechanisms are described below, based on the individual device scenarios. Note, the host and device views are described as appropriate.

•Active. In this scenario, the host is actively communicating with the device. When data is flowing, both the host and device are seeing packet transmissions from each other within the TrustTimeout threshold.

•Idle. In this scenario, the host is not actively communicating with the device (i.e. the owning device driver is not actively attempting to move data to/from the device, or all active function endpoints are flow controlled). The device however, won’t experience a TrustTimeout as long as it can successfully track the Wireless USB channel (i.e. MMCs). However, since the host is not actively scheduling transactions to any function endpoints, the host observes no encrypted packets from the device. In this situation, the host will activate a ‘keep alive’ poll by use of the Keepalive IE/DN_Alive mechanism (see Sections 7.5.9 and 7.6.7). This mechanism allows the host to specifically request one or more devices to send a DN_Alive or equivalent notification to the host. The successful reception of a notification from the device will restart the TrustTimeout period for the associated device. Note that once the host includes a device’s address in a Keepalive IE, it will remain there until it either successfully receives a notification packet from the device, or it encounters a TrustTimeout. Similarly, a device will continue to transmit DN_Alive or equivalent notifications until the host removes the device address from subsequent Keepalive IEs or it experiences a

TrustTimeout.

•Sleep. This scenario is described in detail in Section 4.16.1.1.

Loss of Activity is the scenario that all other scenarios degrade to when the host and device are unable to successfully receive each other’s packets for at least a TrustTimeout period. When an active device loses an MMC, it should go into an ‘open scan’ mode (continuous listening) looking for an MMC transmission from its host. Looking for an MMC from a host in this context can be as simple as matching on a transmission addressed to the cluster, which includes the correct Cluster ID and Stream Index value in the MAC header, in addition to the correct frame type, etc. If the device fails to observe host activity (MMCs) for 500 milliseconds it should initiate its host detection process.4 If the device re-acquires the Wireless USB channel before a TrustTimeout occurs, then the device may continue normal operations. After a TrustTimeout event, the device must transition to the Reconnecting device state and continue looking for the Wireless USB channel of its host. Looking for a host in this context includes finding an MMC with a Host Information_IE that has the correct CHID value. On subsequent host Wireless USB channel acquisition, the device will attempt to re-connect for at least 100 ms. If

4 A host detection process can involve scanning other PHY channels for the host, perform a continuous open scan, etc.

79