Subject: [Efficientnd-dt] APs from the 29th May telco

From: Jouni Korhonen <[email-masked]>
Date: Fri, 06 Jun 2014 13:00:37 +0300

Folks,

we had a discussion whether it is possible to filter multicast frames on 
the Wi-Fi interface without bothering the main CPU..

I said to check this from broadcom chips point of view. Normally, this 
filtering is done by the driver, and support exists for Broadcom chips 
about 32 L2 MCAST addresses, that is up to 32 48-bit 802.1 group  (i.e. 
multicast) MAC addresses. In some products (dongles) which comprise, for 
example, a fully contained WLAN device plus driver operating within a 
portable system which is attached to a larger system via a USB 
connector, the same filtering is performed in the firmware.

Another thing we discussed was whether the unicast is more costly than 
multicast power save modes and power consumption point of view. Some 
mumble from our Wi-Fi folks. You probably know this already but just to 
write it down somewhere.. it at least helped me to understand things 
better :) Comments are welcome..

FOR UNICAST:

The standard power save mechanism in 802.11 uses a system wherein the 
STA wakes from time to time to check to see if the AP has anything 
buffered for delivery to that STA. Typical the wake pattern is some 
integer multiple of the Beacon interval, and often the integer is 3.

When the STA receives the Beacon, it checks for a bit in the Beacon 
which has been assigned for communicating its specific buffer status at 
the AP - each associated STA is given one bit location for this purpose. 
If the STA sees its bit set, then the STA will remain awake and then 
attempt to gain access to the medium to tell the AP that the STA is 
awake and wants its packet(s).

There are various packet delivery schemes, some of which are more 
efficient than others, but the basic nature is the same - the STA has to 
wait for a turn on the medium and when it gets its turn it sends a 
request to the AP and the AP acknowledges the request and then fetches 
the data from storage and then waits for its turn to get access to the 
medium and possibly has other frames already in a transmission queue 
ahead of the one that it just fetched - so a sum total of N msec can 
elapse between the time when the STA wakes to listen for the beacon, 
send the request and then wait for the frame(s) to be transmitted by the AP.

Note also, that depending on the particulars of the power save  buffered 
frame retrieval scheme - and there are at least four or five to choose 
from - the STA might only get one buffered frame and then have to ask 
for the next one, etc.

Or it can get two each time, or four or six, or get all at once after a 
single request.

Other schemes have the STA wake completely instead of requesting - but 
in such a case, the timing is still the same.

FOR MULTICAST:

The AP sends all multicast frames immediately after a beacon which is 
called a DTIM beacon. A DTIM beacon is typically every 3rd beacon, but 
there is no specific requirement with respect to how often this happens.

So - if a STA receives MCAST traffic, it only needs to wake for the DTIM 
beacon and then continue to listen because the AP will transmit all 
MCAST frames IMMEDIATELY after the DTIM beacon.

In the MCAST case, there is no waiting for MAC access to the medium on 
the part of the STA, and the AP sends the MCAST without waiting either - 
they just follow the DTIM beacon.

- Jouni

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 12 Jun 2014 14:54:48 +0000

Hi Jouni,

Thanks for the write-up on the power-save behavior of unicast and multicast messages for the 802.11 devices.
I think that it is worth documenting. However, from the description below it is not  clear to me which mode consumes more power.  It seems that one can tune the STA wakeup timing and requsts for buffering in order to save power. But MCAST messages are transmitted with DTIM beacon.

Can you provide a bit analysis on powersaving on both modes ? As for multicast, the messages are sent on every ports -- right?

Thanks,
-Samita

-----Original Message-----
From: Efficientnd-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, June 06, 2014 3:01 AM
To: [email-masked]
Subject: [Efficientnd-dt] APs from the 29th May telco

Folks,

we had a discussion whether it is possible to filter multicast frames on the Wi-Fi interface without bothering the main CPU..

I said to check this from broadcom chips point of view. Normally, this filtering is done by the driver, and support exists for Broadcom chips about 32 L2 MCAST addresses, that is up to 32 48-bit 802.1 group  (i.e. 
multicast) MAC addresses. In some products (dongles) which comprise, for example, a fully contained WLAN device plus driver operating within a portable system which is attached to a larger system via a USB connector, the same filtering is performed in the firmware.

Another thing we discussed was whether the unicast is more costly than multicast power save modes and power consumption point of view. Some mumble from our Wi-Fi folks. You probably know this already but just to write it down somewhere.. it at least helped me to understand things better :) Comments are welcome..

FOR UNICAST:

The standard power save mechanism in 802.11 uses a system wherein the STA wakes from time to time to check to see if the AP has anything buffered for delivery to that STA. Typical the wake pattern is some integer multiple of the Beacon interval, and often the integer is 3.

When the STA receives the Beacon, it checks for a bit in the Beacon which has been assigned for communicating its specific buffer status at the AP - each associated STA is given one bit location for this purpose. 
If the STA sees its bit set, then the STA will remain awake and then attempt to gain access to the medium to tell the AP that the STA is awake and wants its packet(s).

There are various packet delivery schemes, some of which are more efficient than others, but the basic nature is the same - the STA has to wait for a turn on the medium and when it gets its turn it sends a request to the AP and the AP acknowledges the request and then fetches the data from storage and then waits for its turn to get access to the medium and possibly has other frames already in a transmission queue ahead of the one that it just fetched - so a sum total of N msec can elapse between the time when the STA wakes to listen for the beacon, send the request and then wait for the frame(s) to be transmitted by the AP.

Note also, that depending on the particulars of the power save  buffered frame retrieval scheme - and there are at least four or five to choose from - the STA might only get one buffered frame and then have to ask for the next one, etc.

Or it can get two each time, or four or six, or get all at once after a single request.

Other schemes have the STA wake completely instead of requesting - but in such a case, the timing is still the same.

FOR MULTICAST:

The AP sends all multicast frames immediately after a beacon which is called a DTIM beacon. A DTIM beacon is typically every 3rd beacon, but there is no specific requirement with respect to how often this happens.

So - if a STA receives MCAST traffic, it only needs to wake for the DTIM beacon and then continue to listen because the AP will transmit all MCAST frames IMMEDIATELY after the DTIM beacon.

In the MCAST case, there is no waiting for MAC access to the medium on the part of the STA, and the AP sends the MCAST without waiting either - they just follow the DTIM beacon.

- Jouni

_______________________________________________
Efficientnd-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/efficientnd-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 12 Jun 2014 20:19:16 +0300

Hi Samita,

Unicast does consume more since it follows the "normal" AP-STA delivery 
when active (with ACKs).. and also the STA polls AP etc i.e., much more 
message exchanges both up- and downlink. In multicast case, after a 
beacon the STA just receives multicast messages.

- Jouni