| Description |
This article describes the challenge that real-time applications, such as Microsoft Teams and Google Meeting, can impose for the user experience over WiFi due to the fact that wireless is a shared medium. Therefore, besides a good capacity planning to meet the application bandwidth requirements, understanding which traffic should have a better priority over others is critical, especially for sensitive traffic such as audio and video.
WiFi is based on a 'listen before talking' approach to simplify the understanding, so a device must wait for its transmit opportunity to access the medium. But to prioritize some strategic traffic over WiFi, the solution is to use the standard WMM (Wireless Multi Media) to provide more transmitting opportunity for higher priority traffic.
When analyzing a beacon frame, it is possible to see the following four WMM access classes:
It is important to note the contention window for each corresponding class. Video and voice have a shorter contention window, which translates to better transmitting opportunity and less waiting time.
 |
| Scope |
FortiGate, FortiAP. |
| Solution |
To start, it is necessary to define QoS for client stations, as the solution will trust the QoS sent by the client station to FortiAP. Refer to the following diagram to better understand the packet flow.
Microsoft has an article available here explaining how to 'Set QoS on windows clients' via GPO, Intune or even manually using PowerShell commands. Note that Microsoft uses source ports as a filter.
Google also has an article available here describing how to 'Add QoS on Meet clients'.
Below is an example of how it is possible to manually create a new policy for Google Meeting via PowerShell commands (refer to the Google website, as the following destination ports can change anytime):
new-NetQosPolicy -Name "GoogleMeet" -IPDstPortStart 3478 -IPDstPortEnd 3478 -DSCPAction 46 -NetworkProfile All new-NetQosPolicy -Name "GoogleMeetRange" -IPDstPortStart 19302 -IPDstPortEnd 19309 -DSCPAction 46 -NetworkProfile All
Using PowerShell from a windows client, run 'Get-NetQoSPolicy' to validate that some QoS policies are indeed in place.
Note: Do not forget to apply them by running 'gpupdate'.
Once this is all set from the client perspective, the first step is to define the same settings in our Wireless Controller under 'WiFi & Switch Controller - Operation Profiles - QoS Profiles'. If this option is not available in the WLAN controller, enable 'Advanced Wireless Features' under 'System - Feature Visibility'.
It is worth mentioning that in the following settings, it is also possible to configure DSCP marking in which FortiAP will also apply DSCP marking while forwarding the frames, thus in this case any Switch, such as FortiSwitch, can trust the DSCP in the wired side as well.
The same settings can be achieved via CLI:
config wireless-controller qos-profile edit "WMM-Profile" set wmm-uapsd disable set dscp-wmm-mapping enable set dscp-wmm-vo 46 48 56 set dscp-wmm-vi 24 26 28 30 32 34 36 38 40 set dscp-wmm-be 0 16 18 20 22 set dscp-wmm-bk 8 10 12 14 set wmm-dscp-marking enable set wmm-vo-dscp 46 set wmm-vi-dscp 34 next end
Moving forward, the second step is to associate this QoS Profile with the SSID under 'WiFi & Switch Controller - SSIDs - Advanced Settings - QoS Profile'.
It is also possible to define this second step via CLI:
config wireless-controller vap edit "Fortinet" set qos-profile "WMM-Profile"
Finally, it is time to check the results. In order to analyze the results, it is recommended to perform a wireless packet capture using FortiAP or any other solution, such as Wireless Diagnostics from a MacBook.
Client station sending traffic towards FortiAP with Voice QoS:
Client station sending traffic towards FortiAP with Video QoS:
Related Fortinet Documentation: |
