Basic P2P Architecture Stack

          |  <---------- D-Bus Application API
+--------------------+
| connection manager |
| or p2p control app |
+--------------------+
          |  <---------- D-Bus supplicant API
          |              or socket control interface
+--------------------+
| wpa_supplicant     |
+--------------------+
          |  <---------- nl80211
+--------------------+
| cfg80211           |
+--------------------+
          |  <---------- struct API
+--------------------+
| mac80211           |
+--------------------+
          |  <---------- mac80211's driver API
+--------------------+
| driver             |
+--------------------+

Interfaces

D-Bus Application API

NOTE: This doesn't exist yet! There's no integration
      with connection managers or any other control
      application yet!

We're currently working on seeing if this is at all feasible to define, but it would be good if applications could use a standard API that the connection manager offers. There are multiple reasons for having the connection manager offer this, like the need for a coordinator of all wifi usage.

Since there are multiple connections managers, a good approach to defining this would be a freedesktop.org standard.

D-Bus supplicant API

WIP: Intel is working on defining this API, basically mirroring the socket control interface.

socket control interface

This interface offers basic P2P primitives like p2p_find, p2p_stop_find, p2p_connect, etc.

Here's a full list:

• p2p_find
• p2p_stop_find
• p2p_connect
• p2p_listen
• p2p_group_remove
• p2p_group_add
• p2p_prov_disc
• p2p_get_passphrase
• p2p_serv_disc_req
• p2p_serv_disc_cancel_req
• p2p_serv_disc_resp
• p2p_service_update
• p2p_serv_disc_external
• p2p_service_flush
• p2p_service_add
• p2p_service_del
• p2p_reject
• p2p_invite
• p2p_peers
• p2p_peer
• p2p_set
• p2p_flush
• p2p_presence_req
• p2p_ext_listen

This API can be used on dedicated/embedded systems like a printer, but applications that must play together with other applications can't really use it.

Both D-Bus and socket interfaces (will) also have events indicating when new P2P devices were found, etc.

nl80211

Currently, the P2P-related extensions are:

• NL80211_CMD_REMAIN_ON_CHANNEL
• NL80211_CMD_CANCEL_REMAIN_ON_CHANNEL
  • This indicates to the device that it should stay on a given channel for a given time, to implement a P2P listen phase. Can also be canceled, since it is also used to implement off-channel TX for group negotiation or invitation (but see below)
• NL80211_CMD_FRAME (previously NL80211_CMD_ACTION)
  • Transmit a management frame, with channel checking. This can be used during a remain-on-channel phase to transmit frames on that channel, or at other times to transmit on the operating channel. I'm working on allowing off-channel transmission, i.e. transmit on a given channel and wait for a response for a given time (including the ability to cancel the wait) which in a sense combines REMAIN_ON_CHANNEL and MGMT_TX into just a single MGMT_TX for some operations.
• NL80211_CMD_REGISTER_FRAME
  • Allow a userspace application to register for receiving a given type of (management) frame through nl80211, and also replying to it. Applications can also specify a filter so for example they don't have to handle all the different action frames but just a subset. For action frames, a side effect is that the kernel will not reply to unknown action frames when they are registered by userspace. Used by wpa_supplicant for P2P also for probe requests. Related events: NL80211_CMD_FRAME, NL80211_CMD_FRAME_TX_STATUS. Prior to some work, this was called NL80211_CMD_REGISTER_ACTION, NL80211_CMD_ACTION, NL80211_CMD_ACTION_TX_STATUS.
• (not a command) the ability to restrict the supported rates so
  • that the P2P requirement of not using 11b rates can be fulfilled.

WORK IN PROGRESS (Johannes has patches):

• NL80211_CMD_START_P2P_LISTEN, NL80211_CMD_STOP_P2P_LISTEN
  • Allows userspace to start an offloaded p2p-listen/find phase including scan parameters for the searches. This allows us to take advantage of iwlwifi microcode to schedule the offchannel periods. I currently do not have a matching wpa_supplicant patch as the state machine it has internally is quite complex and needs to be half avoided. I have test code for iw to test this feature.

cfg80211's struct API

This just mirrors nl80211 with function/method calls etc.

mac80211's driver API

Currently, no specific P2P extensions at all, because mac80211 handles all off-channel stuff etc. However, with the things that I'm working on, there is new API for the p2p start_listen, p2p_stop_listen offloads, and there will also be new API for offloading the off-channel transmissions that I'm working on.

Interface types

nl80211/cfg80211 currently define the P2P interface types P2P_CLIENT and P2P_GO, but wpa_supplicant doesn't use them, it still uses regular STA/AP interfaces. This is mostly because we haven't figured out a good way in the supplicant to distinguish between normal "STA" and P2P-client yet. The new P2P interface types will be needed later.

Driver considerations

Drivers must currently only support AP and STA modes, and must be able to function during off-channel periods. They must also be able to receive probe requests even while in station mode, as indicated by mac80211 by the FIF_PROBE_REQ filter flag.

With the patches that I'm working on, drivers may optionally implement the p2p_start_listen/stop_listen callback to allow offload to the device for these operations. Additionally, they will be able to implement off-channel TX callbacks (but this is still WIP).