Wi-Fi Direct – Overview and Features

Overview

Technical Overview

In a typical Wi-Fi network, client scans and associate to wireless networks available, which are created and announced by Access Points (AP). Each of these devices has roles involving a different set of functionality. A major novelty of Wi-Fi Direct is that these roles are specified as dynamic, and hence a Wi-Fi Direct device has to implement both the role of a client and the role of an AP (sometimes referred to as Soft AP). These roles are therefore logical roles that could even be executed simultaneously by the same device, this type of operation is called Concurrent mode.

In order to establish a communication, P2P devices have to agree on the role that each device will assume at the time of negotiation. In the following we describe how this communication is configured using specified procedures, namely device discovery, role negotiation, service discovery, security provisioning and power saving.

Architecture

Wi-Fi Direct devices, formally known as P2P Devices, communicate by establishing P2P Groups, which are functionally equivalent to traditional Wi-Fi infrastructure networks. The device implementing AP-like functionality in the P2P Group is called the P2P Group Owner (P2P GO), and devices acting as clients are known as P2P Clients.

This GO and client functionality is dynamic and is negotiated at the time of initial network setup. Two P2P devices discover each other; they negotiate their roles (P2P Client and P2P GO) to establish a P2P Group. Once the P2P Group is established, other P2P Clients can join the group as in a traditional Wi-Fi network. Legacy clients can also communicate with the P2P GO if they support the required security mechanisms. By default Wi-Fi, Direct uses WPA2PSK as a security standard. In this way legacy devices do not formally belong to the P2P Group and do not support the enhanced functionalities defined in Wi-Fi Direct, but they simply “see” the P2P GO as a traditional AP.

The logical nature of the P2P roles supports different architectural deployments; one of these is illustrated in Fig 1 represents a scenario with two P2P groups. The first scenario is a mobile phone sharing its 3G connection with two laptops; in this first scenario, the three devices form a group, the phone is acting as P2P GO while the two laptops behave as P2P Clients. In order to extend the network, one of the laptops establishes a second P2P Group with a printer; for this second group, the laptop acts as P2P GO. In order to act both as P2P Client and as P2P GO the laptop will typically alternate between the two roles by time-sharing the Wi-Fi interface.

Fig.1 Wi-Fi Direct supported topologies

Source: P2P Technical Specification

Like a traditional AP, a P2P GO announces itself through beacons containing additional P2P Information Element. P2P IE is included in all management frames. Legacy devices ignore these information elements and action frames. The Wi-Fi Direct Specification requires that the P2P device which becomes the group owner should also provide the DHCP server application in their system [3] to provide P2P Clients with IP addresses. In addition, only the P2P GO can cross-connect the devices in its P2P group to an external network. Finally, Wi-Fi Direct does not allow transferring the role of P2P GO within a P2P Group. In this way, if the P2P GO leaves the P2P Group then the group is torn down, and has to be re-established using some of the specified procedures.

Group Formation

There are several ways in which two devices can establish a P2P Group. Three types of group formation techniques are Standard, Autonomous and Persistent cases. An example of group formation case is illustrated in Fig 2.

Group Formation procedure involves two phases-

• Determination of P2P Group owner
  • Negotiated – Two P2P devices negotiate for P2P group owner based on desire/capabilities to be a P2P GO.
  • Selected – P2P group Owner role established at formation or at an application level
• Provisioning of P2P Group
  • Establishment of P2P group session using appropriate credentials
  • Using Wi-Fi simple configuration to exchange credentials.

Fig.2. Wi-Fi Direct GO Negotiation and Group Formation Sequence

Source: P2P Technical Specification

• Standard: In this case the P2P devices have first to discover each other, and then negotiate which device will act as P2P GO. Wi-Fi Direct devices usually start by performing traditional Wi-Fi scan (active or passive), by means of which they can discover existent P2P Groups and Wi-Fi networks. After this scan, a new Discovery algorithm is executed. First, a P2P Device selects one of the Social channels, namely channels 1, 6 or 11 in the 2.4 GHz band, as its Listen channel. Then, it alternates between two states: a search state, in which the device performs active scanning by sending Probe Requests in each of the social channels; and a listen state, in which the device listens for Probe Requests in its listen channel to respond with Probe Responses. Once the two P2P Devices have found each other, they start the GO Negotiation phase. This is implemented using a three-way handshake, namely GO Negotiation Request/ Response/ Confirmation, where by the two devices agree on which device will act as P2P GO and on the channel where the group will operate, which can be in the 2.4 GHz or 5GHz bands. In order to agree on the device that will act as P2P GO, P2P devices send a numerical parameter, the GO Intent value, within the three-way hand-shake, and the device declaring the highest value becomes the P2P GO. To prevent conflicts when two devices declare the same GO Intent, a tie-breaker bit is included in the GO Negotiation Request, which is randomly set every time a GO Negotiation Request is sent.
• Persistent: During the formation process, P2P devices can declare a group as persistent, by using a flag in the P2P Capabilities attribute present in Beacon frames, Probe Responses and GO negotiation frames. In this way, the devices forming the group store network credentials and the assigned P2P GO and Client roles for subsequent re-instantiations of the P2P group. Specifically, after the Discovery phase, if a P2P Device recognizes to have formed a persistent group with the corresponding peer in the past, any of the two P2P devices can use the Invitation Procedure (a two-way handshake) to quickly re-instantiate the group. This is shown in Fig 2, where the Standard case is assumed as baseline, and the GO Negotiation phase is replaced by the invitation exchange, and the WPS Provisioning phase is significantly reduced because the stored network credentials can be reused.

Fig.3  GO Negotiation Flow Diagram

Source: P2P Technical Specification

P2P Invitation procedure: The P2P Invitation Procedure is an optional procedure used for the following:

• A P2P Group Owner invites a P2P Device to become a P2P Client in its P2P Group.
• Requesting to invoke a Persistent P2P Group for which both P2P Devices have previously been provisioned and one of the Devices is P2P Group Owner for the Persistent P2P Group.
• A P2P Device that is invited to join an operational P2P Group through successful completion of the P2P Invitation Procedure, Use Wi-Fi Simple Configuration to obtain Credentials. Provision Discovery and Wi-Fi Simple Configuration will take place on the Operating Channel of the P2P Group Owner.

P2P Invitation Request:  A P2P Invitation Request frame may be transmitted by:

• A P2P Device that is a member of a P2P Group (i.e. P2P Group Owner or P2P Client) to another P2P Device that supports P2P Invitation Procedure and is currently not a member of the P2P Group to invite that P2P Device to join the P2P Group. When used for this purpose, the invitation Type in the Invitation Flags attribute in the P2P Invitation Request frame set to 0.
• A P2P Device that is a member of a Persistent P2P Group to another member of that P2P Group and one of the Devices is the P2P Group Owner, to request that the P2P Group be invoked. When used for this purpose, the Invitation Type in the Invitation Flags attribute included in the P2P Invitation Request frame shall be set to 1.

P2P Invitation Response: A P2P Invitation Response frame (with the Status attribute set to Success) transmitted by the P2P Group Owner of a Persistent P2P Group in response to a request to invoke that P2P Group, include the P2P Group BSSID, Channel List, Operating Channel and Configuration Timeout attributes to indicate the Group BSSID, potential Operating Channels, intended Operating Channel and any GO Configuration Time.

Service Discovery

Source: P2P Technical Specification

WFD State Machine

Source: P2P Technical Specification

Security

Security provisioning starts after discovery has taken place and, if required, the respective roles have been negotiated. Wi-Fi Direct devices are required to implement Wi-Fi Protected Setup (WPS) to support a secure connection with minimal user intervention. In particular, WPS allows establishing a secure connection by introducing a PIN in the P2P Client, or pushing a button in the two P2P Devices. Following WPS terminology, the P2P GO is required to implement an internal Registrar, and the P2P Client is required to implement an Enrollee. The operation of WPS is composed of two parts. In the first part, the internal Registrar is in charge of generating and issuing the network credentials, i.e., security keys, to the Enrollee. WPS is based on WPA-2 security and uses Advanced Encryption Standard (AES)-CCMP as cipher, and a randomly generated Pre-Shared Key (PSK) for mutual authentication. In the second part, the Enrollee (P2P Client) disassociates and reconnects using its new authentication credentials. In this way, if two devices already have the required network credentials (this is the case in the Persistent group formation), there is no need to trigger the first phase, and they can directly perform the authentication.

Power Saving

Power saving mechanisms, in current Wi-Fi networks is not defined for APs but only for clients. Wi-Fi Direct defines two new power saving mechanisms: the Opportunistic Power Save protocol and the Notice of Absence (NoA) protocol. According to rules Of P2P power management, It allow P2P GO to be

“absent” for defined periods. A legacy client expects the P2P GO to be always on to prevent use of P2P power saving in a P2P Group which contains a legacy client. The P2P GO is always in the awake power state, during the CTWindow that is necessary for discoverability & starts at TBTT. CTWindow start time and duration is advertised in beacon and probe response frames.

• Notice of Absence: The Notice of Absence (NoA) protocol allows a P2P GO to announce time intervals, referred to as absence periods, where P2P Clients are not allowed to access the channel, regardless of whether they are in power save or inactive mode. In this way, a P2P GO can autonomously decide to power down its radio to save energy. Like in the Opportunistic Power Save protocol, in the case of NoA the P2P GO defines absence periods with a signaling element included in Beacon frames and Probe Responses.

In particular, a P2P GO defines a NoA schedule using four parameters:

• Duration that specifies the length of each absence period
• Interval that specifies the time between consecutive absence periods
• Time that specifies the start time of the first absence period after the current Beacon frame
• Count that specifies how many absence periods will be scheduled during the current NoA schedule

A P2P GO can either cancel or update the current NoA schedule at anytime by respectively omitting or modifying the signaling element. P2P Clients always adhere to the most recently received NoA schedule. Fig 6 depicts an example operation of the NoA protocol.

Fig.6. Notice of Absence Powersave Operation

Source: P2P Technical Specification

Packet Analysis

Wi-Fi Direct IE: The format of the P2P IE is shown in Fig 7. The P2P attributes are defined to have a common general format consisting of a 1 octet P2P Attribute ID field, a 2 octet Length field and variable-length attribute-specific information fields, shown in fig 8.

A P2P Device that encounters an unknown or reserved Attribute ID value in a P2P IE received without error shall ignore that P2P attribute and parse any remaining fields for additional P2P attributes with recognizable Attribute ID values. A P2P Device that encounters a recognizable but unexpected Attribute ID value in the received P2P IE may ignore that P2P attribute. More than one P2P IE may be included in a single frame. If multiple P2P IEs are present, the complete P2P attribute data consists of the concatenation of the P2P Attribute fields of the P2P IEs. The P2P Attributes field of each P2P IE may be any length up to the maximum (251 octets).

Fig.7. P2P IE Format

Source: P2P Technical Specification

Fig.8. General Format of P2P attributes

Source: P2P Technical Specification

The P2P Capability attribute contains a set of parameters that can be used to establish a P2P connection. The format of the P2P Capability attribute is shown Fig 9.

Fig.9. P2P Capability attribute format

Source: P2P Technical Specification

The Public Action frame format (as defined in IEEE 802.11k) is used to define the P2P public action frames. The general format of the P2P public action frames is shown in Fig 10.

Fig.10. General Format of P2P Public Action Frame

Source: P2P Technical Specification

The Wi-Fi Direct sniffer capture is shown below. Various tools are available to capture the air packets like wireshark and omnipeek. The format of the P2P Information Element is shown Fig 11 and Fig 12.

Fig.11. P2P Information Element shown from a captured Packet

Fig.12. P2P Packet Captured with detail view as shown in Omnipeek

Testing Techniques

Testing for P2P devices involves testing of both P2P client and P2P GO. For testing of P2P client DUT is either not associated to a P2P Group Owner (GO) or if the device is already a P2P Client in a Group it uses its P2P Device Address to communicate with another P2P device.

For P2P GO testing, the device under test is acting as a P2P Group Owner of a Group. In this mode the device may have none, one or more P2P Clients or legacy STAs attached.

The WFA Sigma Automation Suite is used for the WFD Certification. This tool suite provides configuration, test control, traffic generation, and results analysis services.

Sigma Testbed Setup

P2P Device can be tested for conformance, stability and performance. Tools like Ixia Chariot are used to analyzing and measure the throughput of devices.

Fig.13. P2P Certification Test Configuration System