We have learnt about opportunistic power save mode in the previous post and you can read about it from the link P2P Opps Mode. And we will learn about Notice of Absence Power saving mechanism in WiFi Direct. In OPS mode GO getting into the DOZE state depends on the clients transmissions. But in NoA power save mode , GO will decide when it goes to sleep mode and all the connected clients will follow that.

Notice of Absence schedule shall include a P2P Notice of Absence attribute describing the planned absence timing within transmitted Beacon and Probe Response frames. We can see the sniffer captures later in the post. This NoA timing can also be notified by GO by the Notice of Absence action frame directly.

The timing synchronization between the GO and GC will be determined by the TSF (timing synchronization function). So the all the devices will know when exactly to be awake.

P2P Group owner defines NoA schedule using four parameters:

1. Duration: It specifies the length of each absence period.
2. Interval: It specifies the time between consecutive absence periods
3. Start Time: It specifies the start time of the first absence period after the current Beacon frame
4. Count: It specifies how many absence periods will be scheduled during the current NoA schedule. If the Count value is equal to 255, the cycle shall repeat until cancelled.

See the below diagram to know the P2P NoA Power save method. Observe the below shows that we have count value as 7. So total we will have 7 absent periods after that NoA power save will be disabled. In the below figure observe that communication between GO and GC happens only on the presence periods. GO and GCs goes to DOZE when the GO is in the absent period. Here GO decides when to sleep, where as in OPS mode based on the Clients transmissions GO goes to sleep.

A P2P GO can either cancel or update the current NoA schedule at anytime.

Check the below sniffer capture with the count value as 255. If the count value is 255 it means that the cycle shall repeat until cancelled.

Observe the Frame Number 132 in the below sniffer capture.Here we have duration and Interval will be micro seconds. And the count value is 255, meaning the NoA procedure will be keep on repeating until canceled. Start time will be calculated based on the TSF timer. So that all the clients will be synchronized.

In the below capture we have CTW and Opps parameters set as 0. because we are not using that Opps Power save mode. We can see the combination of Opps and NoA later in the post, there we see these bits will enabled.

For any reason if the GO disables the NoA power save then there will not be NoA seen in the beacon or probe response frames. Observe the below frame number 135 to check that GO immediately stops sending NoA Attribute in the Beacon. Cancellation applies immediately that a Beacon frame is transmitted by the P2P Group Owner without a Notice of Absence attribute.

The NoA will be cleared based on the count value as well. As we have discussed earlier if the count is 255, NoA Power save will be running until cancelled. If the count value is given some integer value, then it will be running for specific number of absence periods and then the NoA will be cleared. Observe the below sniffer capture frame number 249.

Once all the 100 absence period are finished, then the NoA will be cleared and we will see that immediately GO stops sending this NoA in the Beacon or probe response frames. Observe the below capture and check the frame number 257 where we dont see any NoA attribute.

The initial value for the Index field shall be arbitrarily chosen by the P2P Group Owner in the NoA Attribute. The P2P Group Owner shall increment the Index value each time a new Notice of Absence schedule is announced, or whenever any field within the Notice of Absence attribute is changed.

In the below capture observe that Index value is 4, and if there is any change in the NoA Parameters or NoA attributes getting cleared and starting again, the index value will be incremented immediately and values can be seen from the next beacon or probe response.

As an example check the below figure to see the index value as 4.

If there is restart on the NoA Power save or of there is any change in the NoA parameters then the Index value will be incremented. Observe the below capture to check the index value getting incremented.

Note

Where Notice of Absence is used in connection with concurrent operation, operational parameters should be chosen, as far as is practical, to balance the needs of both the WLAN and P2P Group. There has to be a proper balance between both the stand alone WiFi interface and P2P interface.

Signaling of Client service requirements

P2P Presence Request and Response

P2P Clients may submit a P2P Presence Request to the P2P Group Owner to influence P2P Group Owner power management timing. On receipt of a P2P Presence Request, the P2P Group Owner shall determine whether to accept the request. If the P2P Group Owner accepts the P2P Presence Request, it shall respond with a P2P Presence Response action frame containing a Status attribute indicating success and a Notice of Absence attribute describing the Notice of Absence timing that it will use in response to the request.

If the P2P Group Owner cannot accommodate a P2P Presence Request, it may deny the request. In this case, the P2P Group Owner shall respond with a P2 Presence Response action frame with a Status attribute indicating the failure status code ‘Unable to accommodate request’ and a Notice of Absence attribute.

Observe the below frame exchange between GC and GO. Clients will initiate the Presence request.

The P2P Presence Request action frame shall contain a single P2P NoA attribute. The Index field shall be set to 0 on transmission by the P2P Client and ignored on reception by the P2P Group Owner. The CTWindow field is unused and shall be set to 0 on transmission by the P2P Client and ignored on reception by the P2P Group Owner.

Observe the below P2P Presence request frame from the sniffer capture.

Observe the below capture to check the P2P Presence Response frame from the GO.

The requested P2P Group Owner presence shall be specified by the Duration and Interval fields in up to two NoA descriptors; one indicating the preferred duration and interval timing and one indicating the maximum interval, and minimum duration acceptable to the P2P Client. Observe the below capture to see this kind of P2P presence request as an example.

Observe the P2P Presence response for the request above.

A P2P Client that no longer has presence requirements should indicate this to the P2P Group Owner by sending a P2P Presence Request Action frame containing no NoA descriptors. A P2P Group Owner may assume that a P2P Client no longer has presence requirements upon determining that the P2P Client has left the P2P Group. Observe the below frame capture to see this kind of P2P Presence Request.

Observe the P2P Presence response for the request above

If the Status element in the P2P Presence Response indicates failure, or if the Status element indicates success, but the timing indicated in the returned Notice of Absence attribute does not meet the requirements of the P2P Client, the P2P Client may:

1. send a new P2P Presence Request with revised timing
2. use the timing indicated in the returned Notice of Absence attribute, or
3. disconnect from the P2P Group.

The P2P Group Owner may alter NoA timing at any time. The P2P Client shall adopt the most recently obtained NoA timing.

This is all about P2P Notice of absence power save method. In the next post we will learn about the few more power saving concepts.