U-APSD

Unscheduled Automatic Power Save Delivery (U-APSD)

The uplink data frames sent by stations (STA → AP) are used as indications (triggers) to AP that the power saving stations are awake. Here is a nice article on NULL frame which is being sent from STA to AP to inform that it is planning to switch to power save mode: http://www.my80211.com/home/2009/12/5/80211-null-data-frames.html.

AP then sends the buffered data frames (buffered when the stations where in doze mode).

In APSD a station is awake during a Service Period (SP). An unscheduled SP begins when the AP receives a trigger frame from a station and ends when the station receives a QoS Data or QoS Null frame indicating the end of the service period (EOSP).

QOS Info Field when sent from AP(beacon)

AP needs inform to stations whether it supports the 

1.  U-APSD(UN-scheduled) or 
2. Scheduled power save mode 

by setting and resetting U-APSD flag bit in QoS info field. If U-APSD bit is 1, then it supports U-APSD and if U-APSD =0 then it does not supports U-APSD

QOS Info Field when sent from STA ((re)association request frame)

Max SP length (2 bit field) indicates max number of total buffered MSDUs and MMPDUs the WMM AP may deliver to WMM STA during the service period triggered by WMM STA.

  Max SP length

Setting 0 in AC (BE, BK, VI and VO) indicate that the corresponding AC is neither trigger-enabled nor delivery-enabled.

 TIM in the Beacon might not indicate whether frames are buffered at the AP, it requires to periodically send QoS Null frames if no other triggers are sent in order to learn the actual buffer status of the AP.

If U-APSD is configured through ADDTSs each time a new application starts which requires its usage, then the stations can rely on the TIM information of the Beacons to be informed about new traffic at the AP, enter into U-APSD mode through ADDTS when a communication starts and revert back to legacy
power save mode when it ends.

rfkill

Some devices come with a hard switch that lets you kill different types of RF radios: 802.11 / Bluetooth. Some times these buttons may kill more than one RF type. The Linux kernel rfkill subsystem exposes these hardware buttons and lets userspace query its status and set its status through a /dev/rfkill.

 To get the current rfkill status, use rfkill list:

 

Note that an index (3) is assigned  for wireless LAN interface.

To turn off the interface, use the command rfkill block <index> and to turn on the interface again, use rfkill unblock <index>

Part 3: P2P Group Owner Negotiation

Once the two P2P Devices have found each other, they start the Group Owner(GO) Negotiation phase. This is implemented using a three-way handshake, namely GO negotiation.Request/Response/Confirmation,  whereby 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 5 Ghz 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.

P2P GO Negotiation Request from device 1:

 

If operating channel is not available, it will use another channel from the Channel List.Configuration time is Time needed by the device to get configured an function as a GO in units of 10 milliseconds.

 WPS IE in GO negotiation request:

GO negotiation response from device 2:

WPS IE in GO negotiation response:

                

When using PIN based WSC, the selected PIN (from the display of either the

P2P Client or P2P Group Owner) is indicated using Device Password ID
attribute. For example for devices using pushbutton authentication,

A P2P Device may decline Group Owner Negotiation if the Device Password ID

in the GO Negotiation Response is incompatible with the Provisioning
information it shall use to execute Provisioning.

P2P GO Negotiation confirmation from device 1:

Group Owner determination is depicted below.

Once the devices have discovered each other and agreed on the respective roles, the next phase is the establishment of a secure communication using Wi-Fi Protected Setup.