Wi-Fi Direct™ is an Wi-Fi Alliance technical specification called “Wi-Fi Peer-to-Peer (P2P) Specification. It is not an IEEE standard. Wi-Fi Direct (initially called Wi-Fi P2P) allow devices to connect directly to each other in a peer-to-peer way, without the use of a traditional Access Point. This means that you can be sure that any Wi-Fi Direct enabled technology has been set to work with all the others without the need for special hardware.

1) Device discovery
Before any connection can be formed, Wi-Fi devices have to find each other. For this they alternately send probe requests (and alternately listen for potential replies) with additional P2P information on so-called social channels(1, 6 and 11 in the 2.4GHz band).

Device characteristics include, User-defined device name and Device type.
2) Service discovery
After a Wi-Fi device has been discovered, and before establishing a group with it, it can be asked to describe the services it provides. This is an optional frame exchange which supports different service description protocols, such as “Bonjour” (DNS-SD), UPnP or WS-Discovery. After that, the application or user may choose to connect to a device based on its name or provided services.

3) Group formation
If a device wants to connect to another, it can send a P2P Invitation request to a device which is already connected to ask it to join a new group, or it can directly start the formation of a group with an otherwise unconnected device by sending a GO Negotiation request.

Any P2P device can take the role of P2P Group Owner (GO) or P2P Client but the roles in the group are negotiated. The main purpose of this negotiation is to determine which of the two participating devices will become the GO and to exchange some characteristics of the group, like the operating channel, the WPS configuration method, and whether the group is a persistent group. Devices can communicate their willingness to become group owner with the GO Intent attribute (0-15) of the GO Negotiation request/response frames, and may refuse to form a group if the parameters of the group are not acceptable. By specification, group formation should be completed in less than 15 seconds, but since normally the user is required to enter a PIN code, or push a button, it can take more time.

After the decision has been made which device will become the Group Owner, a GO Negotiation confirmation is sent and both devices move to the negotiated operating channel. The GO starts to operate in Access Point mode, sending beacons with the negotiated SSID and a group formation bit set to 1, because the group formation has not yet been completed. The SSID is standardized to be “DIRECT-xy…” with xy being random characters/numbers and any postfix.

4) Provisioning and Encryption
Now the provisioning phase begins, where the client connects to the GO to exchange credentials with the WPS protocol, which is an exchange of eight EAP messages. To allow the connection, the user normally has to enter a PIN code or push a button on the device.

When joining an existing group, or to speed up the provisioning phase later, devices can send Provision Discovery request/response frames before starting the group negotiation. If not, the GO Negotiation may fail and have to be restarted when the user has taken more time than expected.

After that, the normal RSN (WPA2) 4-way handshake begins to exchange the encryption keys, where the GO assumes the role of authenticator and the client is the supplicant. Then the client will request a IPv4 address from the GO, which is required to implement an DHCP server, and finally actual data transfer can happen.

To avoid users having to enter a PIN code every time when a group is formed regularly between some devices, the group can be made persistent, in which case the devices store the credentials and can automatically re-connect when required. A persistent group may use a different channel and device MAC addresses for each session.

4) Power Management

The challenge directly related to energy management is attributed to the fact
that the process of device discovery and communication introduces inherent overheads plus access point (AP) behavior and the network/cloud/server performance.
Wi-Fi Direct also describes some extensions to the 802.11 and WME power management: Opportunistic Power Save (OppPS) allows the GO to sleep in periods where all clients are in Power Save mode. Also the GO may send a Notice of Absence (NoA) in its beacons or in direct action frames to announce the fact that it will be absent for some period of time because it is sleeping or doing some work on another channel. Clients which have important traffic or specific delay requirements can send a P2P Presence Request to its GO which may or may not adapt its power save behavior.

5) Optional features: Concurrent operation and Manageability
The P2P specification mentions that P2P devices may support concurrent operation as multiple MAC entities, possibly on different channels, and thus could be part of more than one P2P group or WLAN simultaneously, but it does not further describe this option. We assume that current (2013) Wi-Fi chipsets may support two concurrent connections at the time, possibly more later.

Another optional feature of Wi-Fi Direct is the manageability of P2P devices in enterprise environments. The managed enterprise AP has the possibility to restrict P2P devices in its vicinity by limiting their allowed channels or transmit power and it can also disallow them to provide cross-connections into the corporate WLAN.

6) Frame exchange sequence
Now, let’s look at an example frame exchange, where two Wi-Fi Direct devices “A” and “B” are discovering each other and form a group… Wi-Fi Direct supports many different scenarios, but we assume that this is the most common case.

At first both devices will enter the scan phase, and send

A arrow-right B (1) Probe requests with P2P IE on all channels.

After a random time one of them will start to listen on one of the social channels (1, 6 or 11) and finally receive a probe request from the other station. It will reply with:

A arrow-left B (2) Probe response with P2P IE

Device A reports “Another device found” to the user or managing application. Now an optional service discovery exchange can happen:

A arrow-right B (a) Service Discovery query
A arrow-left B (b) Service Discovery response

We don’t count this optional frame exchange to have a fair comparison to Ad-hoc mode later.

Then group formation begins:

A arrow-right B (3) GO Negotiation request

B reports this to the user and will wait for the input, which we assume to timeout in this case.

A arrow-left B (4) GO Negotiation response (fail)

Optionally, instead of having the first GO Negotiation fail, the devices could have used Provision Discovery before group formation, but this does not change the number of total frames exchanged:

A arrow-right B (3) Provision Discovery request
A arrow-left B (4) Provision Discovery response

A arrow-right B (5) GO Negotiation request

In the end we suppose the user on B has allowed the connection.

A arrow-left B (6) GO Negotiation response (success)
A arrow-right B (7) GO Negotiation confirmation

Now one device becomes GO and the other client, Let’s assume B is the GO

A arrow-left B (8) GO sends beacons (formation bit = 1)
A arrow-right B (9) Authentication 1
A arrow-left B (10) Authentication 2
A arrow-right B (11) Association request
A arrow-left B (12) Association response

Now the “provisioning” phase begins, which is a WPS exchange of usually 8 frames. We don’t go into the details of the WPS protocol here.

(13) (14) (15) (16) (17) (18) (19) (20)

Next the GO starts to send beacons with the formation bit set to 0.

A arrow-left B (21) GO beacon (formation bit = 0)

The client re-authenticates and re-associates with the new credentials:

A arrow-right B (22) Authentication 1
A arrow-left B (23) Authentication 2
A arrow-right B (24) Association request
A arrow-left B (25) Association response

Now the RSN 4-way handshake begins, and again we don’t go into the details of RSN:

A arrow-left B (26) ANonce
A arrow-right B (27) SNonce + MIC
A arrow-left B (28) GTK + MIC
A arrow-right B (29) ACK

After that we can exchange data frames in the group, but usually the DHCP protocol will be used first to provide the client with an IP address. Again, we don’t count these frames to have a better comparison to Ad-hoc mode.

At least 29 frames had to be exchanged before the first data transmission. In the case of two devices re-invoking a persistent group, we need at least 18 frames.


Leave a Reply