I have a mikrotik AP and I am trying to multicast UDP stream from the a server connected on the ethernet port of the AP to STAs connected to the wireless interface of the AP. As soon as one STA is in power save mode (PSM), the bitrate I can get is very low. Analyzing details with a Kismet probe I found that Mikrotik AP is setting the "More Data" bit to 1 for the last frame of a burst in a beacon period while NOT sending more packets. It starts the transmission again after the next beacon. And I am sure there are packets in the queues because when I put a queue large enough, I got memory full and a crash.

The figure below is a trace showing one beacon interval with very few packets compared to what I am expecting (16Mbps).
And indeed in the next figure we can see that the last frame of the beacon period has its More Data bit to 1, but the AP is not sending more frames. The interval is very large between the last frame and the beacon. There is plenty of time to send many more frames. Why is the AP not sending them? This is happening for every single beacon period.
Note that if all STA are not is PSM, I can achieve the 16Mbps without any problem. Also I have a DTIM interval to 1.

Does anybody have any idea why the AP is not sending the stored packets? Am I doing any mistake?

Thank you very much in advance for your suggestion.

To be more accurate on the problem and to my opinion there are two possible problems:

1) (highest probability) the AP has more packets buffered, set the More Data bit to one all the time, BUT does not send all the buffered packets during the beacon interval

2) (lowest probability), there is indeed no more buffered packets and this is why there is nothing transmitted until next beacon, BUT the AP fails to set the More Data bit to 0.

In both cases I have the feeling that the AP is not compliant with 802.11 multicast in PSM. Am I right?

I suspect this is due to the listen interval of the power save client. Your trace is not complete,

1. Is it always 10 frames between beacons?
2. What is the listen interval in the association request for the power save client when it comes online?

For my Samsung tablet:
Listen Interval: 0x000a

Depending on how many devices you have, try multicast helper to have multicast-to-unicast conversion at 802.11 layer 2 - so the multicast frames will be unicast to each wireless client. This will not scale, obviously.

Here are the answers to your questions.

1. No I just choose one of the shortest burst of frames. Usually there are many more frames during the beacon interval.
2. The listen interval of a Samsung Android is 0x000a and I have no problem with this device. As soon as the iphone device register I have this behavior with very limited bandwidth. The listen interval of the Iphone is 0x0014. So twice longer.

The listen interval may impact the duration the AP will keep frames for devices? But why the AP doesn't send more frames within the beacon interval although the More Data bit telling there are more frames in the queues is set to 1.

I tried the multicast helper but as I am looking for an solution with quite a large number of clients this is not appropriate.

Below are two figures showing the situation with the android only (no PSM) and with the iphone (PSM). Horizontal is the time in seconds and vertically is the cumulative byte count. Each circle is a beacon and the points (cross) in between are the frames. The second figure is a zoom of the first one. You can see that when the Iphone PSM is in, the number of frames for each beacon is quite smaller. But there are no special pattern. Just that for a reason that I cannot find less frames are sent.

What is the Apple device doing during these periods? In between beacons, is it issuing a frame with P (power mgt) bit set?

When you say Android and/or Apple is PSM, exactly what do you mean? There are multiple power save mechanisms - why would an Android not do powersave mode? What is the specific behavior that indicates to you a difference in behavior? I have not seen modern smart devices do classical powersave with PS-Poll, etc., but they usually use Null frames with and without P bit set to indicate sleep/active to the AP. What are your devices doing?

I am looking at our IOS devices with Mikrotik and see plenty of *m* bits set, but I am nearly all unicast, not multicast. And my kids are not complaining about youtube throughput, so I guess I am not replicating your issue.

Is there an IOS app you are using that is consuming your multicast? I have iperf for Android, what other apps do you have to replicate this issue? Or are the IOS devices not consuming the multicast?

Thank you for your reply.

Yes both mobiles are sending null frames with P bit set to indicate they enter sleep mode. No PS-poll. The AP keep sending the multicast frames after one STA device sent a null frame with P bit.

Regarding my Android Samsung galaxy S2 (not too new), you are right that I am not totally sure because I have no control at all. But I did en interesting experiment with a linux laptop. As long as I have power save mode off using the command

iw dev wlan0 set power_mode off

I can see one video stream with vlc player on my Android mobile (8x stream UDP multicast for a total of 16mbps).

Now as soon as I set my laptop to power_mode on, the AP starts to send less multicast packets and my video player is not playing smoothly at all. I have the same behavior with the Iphone. This is why I am focusing on the power_save mode.

Do you know what should happen when an AP has multicast frames in its queues and one STA is sending a null frame with P bit set telling it is going into sleep? If there is the multicast bit set in the beacon frame and all frames have the more data bit set to one, all devices should keep listening, no?

Interesting experiment.

I am using iperf -u -c 239.255.12.50 -ttl 5 -t 50 -b 16M on a desktop and checking on my Android the result. I get the 16mbps more or less with 0.2-0.3% packet loss which I think is ok.

Now I connecting my laptop with power_save mode off to the wireless lan and still get the 16mbps. As soon as I set the power_save mode on on my laptop, the bitrate displayed by iperf on my android mobile drop to about 7Mbps with more than 50% packet loss.

Same behavior as with the UDP video and vlc.

Can you deduce, from the trace, that a power-save indication triggers the multicast frames to stop? Can you post a short trace of the whole channel where iperf is coming in and out?

Have you tried enabled/disabling uapsd, if it is an option on the Mikrotik? I recall they recently added this.

>>iw dev wlan0 set power_mode off

What wireless chipset are you using on the Linux box? I don't have much luck with this command - what does the device do when you enable this? I know it has an effect, but is it using PS-Poll or Null frames? Or UAPSD?

I don't know what devices are supposed to do with multicast. I assumed the buffer would drain each period. I see the use of the more bit set in my tests:
This is what my results look like for unciast with the Tik device. I see the m bit set with rapid data delivery, then m bit is cleared (presumably due to empty buffer), then a short delay. But this is for unicast, not exactly sure how they handle the buffer.

I guess I would try to isolate the difference between power-save mode indication for the different clients and the effect on sending multicast frames. From your notes,

No effect
Android devices

Strong Effect
IOS
Linux Laptop with PS enabled

So what is the difference between the modes and these devices that might cause the AP to stop sending data? I assume the TIM map bit 0 is always set during your tests?

Hello,

Thank you for the ideas. We found few problems.

1) The Mikrotik has an issue with the wireless option multicast-buffering (no explanation in the RouterOS documentation). I need to desactivate to make my setup working.

2) Some devices like the Iphone6 is going into sleep eventhough there is the multicast bit in the beacon frame set to 1, telling there are multicast frame to be transmitted. Indeed I saw this because the Iphone was sending null rames telling, it is going into sleep on a regular basis.

Note that the initial problem of More Data bit for the last frame of a beacon period set to 1 and not sending them right away is still here but it is not creating any problem after 1) and 2) are solved.

Thanks for the update - what is this option?

multicast-buffering

I looked but could not find it. I see multicast helper, but not an option for buffering.

Edit -

Answer my own question - it came in 6.34:

winbox - added multicast-buffering & keepalive-frames settings to wireless interfaces;

So was it always there in CLI? I also saw there was no documentation. In the trace, what do you see different related to multicast handling behavior?