Wi-Fi Direct Protocol Implementation

Wi-Fi Direct Action Frames

Windows uses OIDs to request the miniport driver to send certain Wi-Fi Direct related action frames. These transmission requests can be for frames that would receive a response from another device, or can be responses to requests from other Wi-Fi Direct devices and the miniport driver's behavior would be slightly different depending on the request. The table below shows the frames that Windows is involved in exchanging with the peer device. Windows does not initiate transmission of or process reception of any Wi-Fi Direct actions frames not listed in the table below (including Device/GO Discoverability and Service Discovery frames)

Action Frame

Send Triggered by OS

Port Remains Available After Successful Transmission For Receiving Replies

Receive Indicated to OS

GO Negotiation Request

Yes

Yes

Yes

GO Negotiation Response

Yes

Yes if OID_DOT11_WFD_SEND_GO_NEGOTIATION_RESPONSE. Status = DOT11_WFD_STATUS_SUCCESS

No Otherwise

Yes

GO Negotiation Confirmation

Yes

No

Yes

P2P Invitation Request

Yes

Yes

Yes

P2P Invitation Response

Yes

No

Yes

Provision Discovery Request

Yes

Yes

Yes

Provision Discovery Response

Yes

No

Yes

 

Prior to issuing an OID to send a GO Negotiation request, a P2P invitation request, or a Provision Discovery request, Windows queries the miniport driver for the Dialog Token to use in the send request. When Windows submits an OID request to a port to send one of the action frames in the table above, the miniport driver should:

  1. Use the specified dialog token for sending the action frame.
  2. Complete the OID request.
  3. Sync with the Wi-Fi Direct device to which the frame is targeted. Depending on the implementation, if the send is in response to a received request (eg. Invitation Response sent on reception of an invitation request), this may not be necessary.
  4. Send the frame & wait for an ACK.
  5. Once the ACK for the frame is received or if none of the retry attempts get an ACK, send a NDIS_STATUS indication to Windows to notify about the transmission status of the action frame. This indication must include the IEs from the packet.
  6. If the send was for a frame that would receive a reply from the peer device and the transmission was successful, the port must remain available for the peer device to send reply action frames to the miniport driver. The timeout and mechanism of being available should follow the Wi-Fi Peer-To-Peer Technical Specification.

The miniport driver is not required to maintain a state machine for each of the Wi-Fi Direct action frames.

When a port is in one of the Wi-Fi Direct operation mode and it receives certain Wi-Fi Direct related action frames, after validation of the header fields, it must send a NDIS_STATUS Indication to the OS. It must not drop packets because of internal state machines or because it is currently waiting for a response to a different request (for example dropping GO Negotiation Requests, while it is waiting for GO Negotiation Responses).

If the received Wi-Fi Direct action frame is a request that expects a response, Windows may submit a Direct OID to the miniport driver to send a response. This direct OID will be submitted before the call to NdisMIndicateStatusEx function to indicate the status has returned. If the direct OID is not sent to the miniport driver, it must not send a response to the received packet.

In the NDIS_STATUS indication for received Wi-Fi Direct action the miniport driver can optionally include a PVOID to hold context information for the received packet. Windows will forward this context value to the miniport driver when the direct OID is submitted to the miniport driver. If included in the indication, the context must remain valid until the NdisMIndicateStatusEx function for the indication returns.

When indicating NDIS_STATUS notifications, the miniport driver must perform de-multiplexing of the received frame to the appropriate Wi-Fi Direct port. Public action frames must only be indicated on the NDIS_PORT configured in Wi-Fi Direct Device mode.

Device Address and Interface Address

The miniport driver is required to support one P2P Device Address and as many P2P Interface Addresses as the number of Wi-Fi Direct Groups it can support simultaneously. The Device and supported Interface addresses are reported during initialization. The miniport driver is expected to send and receive packets using its Device Address only on the NDIS PORT that is configured in Wi-Fi Direct Device Mode. It is expected to support sending and receiving of packets using an Interface Address on the other Wi-Fi Direct role ports.

If the miniport driver only supports one Wi-Fi Direct group, it may use the same address as both its Device Address and Interface Address. In this case, it is responsible for doing appropriate filtering and de-multiplexing of received packets to NDIS_PORTs when indicating the packets to Windows.

The miniport driver must use the appropriate interface address for each of the Wi-Fi Direct Role port. This address should match the MAC address reported by the miniport during port creation (DOT11_MAC_INFO structure of OID_DOT11_CREATE_MAC).

IE Creation And Parsing

The miniport driver is responsible for creating the P2P Attributes and P2P Information Elements for inclusion in transmitted packets. Windows will provide the miniport driver the WPS IEs that it should include in the transmitted packets. Windows may include other IEs that the miniport driver should add in the packet. However, Windows will never pass P2P IEs in this list of IEs.

When the miniport driver receives certain types of packets, it needs to inform Windows about the reception. In the notification (which can be a NDIS_STATUS indication or completion of an OID), it would pass all the information elements from the received packets to Windows. It need not parse the P2P or WPS IEs to pass the information to Windows. However, it can parse the IEs to collect any P2P parameters that it is interested in.

The miniport driver should never need to create the Wi-Fi Protected Setup (WPS) IEs in Wi-Fi Direct packets. Windows provides the miniport driver with the WPS IEs it needs to add to specific packets and will parse the WPS IEs in received packets. When responding to probe requests, the miniport driver may need to parse the WPS IEs to match any Request Device Type attributes against programmed primary and secondary device types.

P2P Capability bitmask

The miniport driver is responsible for populating the P2P Capability bitmask in the P2P Capability attributes. Windows uses OIDs to specify the criteria for settings the bits. The criteria are based on the capability reported by the miniport via the DOT11_WFD_ATTRIBUTES structure.

The logic for setting specific bits is described below.

P2P DEVICE CAPABILITY BITMASK

Bit

Information

Criterion to set the bit

0

Service Discovery

OID_DOT11_WFD_DEVICE_CAPABILITY. bServiceDiscoveryEnabled

1

P2P Client Discoverability

OID_DOT11_WFD_DEVICE_CAPABILITY. bClientDiscoverabilityEnabled

2

Concurrent Operation

OID_DOT11_WFD_DEVICE_CAPABILITY. bConcurrentOperationSupported

3

P2P Infrastructure Managed

OID_DOT11_WFD_DEVICE_CAPABILITY. bInfrastructureManagementEnabled

4

P2P Device Limit

OID_DOT11_WFD_DEVICE_CAPABILITY. bDeviceLimitReached

5

P2P Invitation Procedure

OID_DOT11_WFD_DEVICE_CAPABILITY. bInvitationProcedureEnabled

 

When a port is configured to enable a particular capability, it must set the corresponding bit. If Windows disables a specific capability, the port must clear the related bit and disable the capability.

P2P GROUP CAPABILITY BITMASK

WI-FI DIRECT DEVICE PORT - The Wi-Fi Direct Device Port uses the DOT11_WFD_GROUP_CAPABILITY field passed in the action frame send OID for populating the P2P Group Capability Bitmask of the packet. For OIDs which do not specify this field, the Device Port will use the behavior as required by the Wi-Fi Peer To Peer Technical Specification for Wi-Fi Direct Device that is not a Group Owner.

WI-FI DIRECT ROLE PORT IN GROUP OWNER OPERATION MODE - The Wi-Fi Direct Port in Group Owner operation mode must use the settings from OID_DOT11_WFD_GROUP_OWNER_CAPABILITY to configure its Group Capability bitmask. The following table describes the criteria for setting each bit.

Bit

Information

Criterion to set the bit

0

P2P Group Owner

This bit is set to 1 by the driver on the Wi-Fi Direct ports that are currently operating as a Group Owner.

1

Persistent P2P Group

OID_DOT11_WFD_GROUP_OWNER_CAPABILITY. bPersistentGroupEnabled

2

P2P Group Limit

The value of this bit is set by the driver when it has reached its Group Limit. The default Group Limit of the driver is reported by the uGORoleClientTableSize field of DOT11_WFD_ATTRIBUTES. Windows can specify a smaller group limit using OID_DOT11_WFD_GROUP_OWNER_CAPABILITY. uMaximumGroupLimit

3

Intra-BSS Distribution

OID_DOT11_WFD_GROUP_OWNER_CAPABILITY.bIntraBSSDistributionSupported

4

Cross Connection

OID_DOT11_WFD_GROUP_OWNER_CAPABILITY.bCrossConnectionSupported

5

Persistent Reconnect

OID_DOT11_WFD_GROUP_OWNER_CAPABILITY.bPersistenReconnectSupported

6

Group Formation

OID_DOT11_WFD_GROUP_OWNER_CAPABILITY.bGroupFormationEnabled

 

Managed Device

Windows does not provide support for Managed P2P Device operations. The miniport driver may choose to implement this functionality on its Wi-Fi Direct and its ExtSTA ports. If it supports Managed Device operations, it must set the bInfrastructureManagementSupported bit in DOT11_WFD_ATTRIBUTES structure.

 

 

Send comments about this topic to Microsoft

Show:
© 2015 Microsoft