WMM (Wi-Fi Multimedia) (Windows Embedded CE 6.0)

1/6/2010

Wi-Fi Multimedia (formerly known as Wireless Multimedia Extensions) refers to QoS (Quality of Service) over Wi-Fi. QoS enables Wi-Fi access points to prioritize traffic and optimizes the way shared network resources are allocated among different applications. Without QoS, all applications running on different devices have equal opportunity to transmit data frames. That works well for data traffic from applications such as web browsers, file transfers, or email, but is inadequate for multimedia applications. Voice over Internet Protocol , video streaming, and interactive gaming are highly sensitive to latency increases and throughput reductions, and require QoS networks. WMM prioritizes traffic demands from different applications and extends Wi-Fi's high quality end-user experience from data connectivity to voice, music, and video applications under a wide variety of environment and traffic conditions. WMM defines four access categories (voice, video, best effort, and background) that are used to prioritize traffic so that these applications have access to the necessary network resources.

WMM provides differentiated services for networking applications running over IPv4, by tagging the layer 3 and layer 2 protocol layer bit fields. This is to enable applications which need to have preference over other traffic on the network to work with minimal interference from other traffic running at lower network priority.

802.1p

802.1p is a traffic-handling mechanism for supporting QoS in local area networks (LANs). 802.1p2 defines a field in the layer-2 header of 802 packets that can carry one of eight priority values. Typically each transmitted packet will be marked with the appropriate priority value. Devices on the network, are expected to treat the packets accordingly (by making use of underlying queuing mechanisms). The scope of the 802.1p priority value is limited to the LAN. Once packets are carried off the LAN, through a layer-3 device, the 802.1p priority is removed.

Differentiated Services (Diffserv)

Diffserv3 is a layer-3 QoS mechanism. It defines a field in the layer-3 header of IP packets, called the diffserv codepoint (DSCP)4. Typically, hosts or routers sending traffic into a diffserv network will mark each transmitted packet with the appropriate DSCP. Routers within the diffserv network use the DSCP to classify packets and apply specific queuing or scheduling behavior (known as a per-hop behavior or PHB) based on the results of the classification.**

Implementation Details

Applications which require differential services can set their required differentiation on a per socket basis. The winsock network application can use setsockopt to differentiate the packets that are sent from that socket from other traffic. Accordingly the underlying network layers can set the appropriate flags in the protocol layer 2 and layer 3 to indicate the priority level of the packets.

An application can create a socket, call setsockopt with the level set to IPPROTO_IP and the optname IP_DSCP_TRAFFIC_TYPE to specify its requested traffic type and then connect and send data. All outgoing packets for that socket need to be appropriately marked for its requested traffic type at the time the packet is sent.

Similarly calls to getsockopt with the same level and option name can be used to obtain the current setting for the type of traffic requested on the given socket.

Afd and tcpstk will keep state as to what traffic type each socket is using. Based on the traffic type requested by the application, tcpstk will use the mapping table to set the appropriate IP DSCP bit flags in the ip header. The NDIS packet extension information is also set so that the underlying NDIS miniport can set the appropriate flags for the networking layer 2 header.

DSCP traffic types	IP DSCP fields (layer 3)	Layer 2 priority levels
DSCPBestEffort	0x00	BE(Bulk effort priority)
DSCPBackground	0x08	BK(Bulk priority)
DSCPExcellentEffort	0x18	BE(Bulk effort priority)
DSCPVideo	0x28	VI(Video priority)
DSCPAudio	0x38	VO(Voice priority)
DSCPControl	0x38	VO(Voice priority)

The registry HKEY_LOCAL_MACHINE\Comm\Tcpip\DSCPIPMappings can be modified to set each of the above defined values to any DSCP value.

The registry HKEY_LOCAL_MACHINE\Comm\Tcpip\DSCPNdisMappings can be used to set the value of the UserPriority field of the NDIS_PACKET_8021Q_INFO structure.

Similarly the UserPriority field for the underlying layer 2 miniport can be set by modifying six DWORD values with the same names under the registry key HKEY_LOCAL_MACHINE\Comm\Tcpip\DSCPNdisMappings.

For example the above registry settings would set DSCPExcellentEffort traffic to have an ip DSCP value of 0x28 and DSCPVideo traffic to0x38. The remainder of the traffic would follow the default mappings defined below.

Tcpstk will read the registry values at boot time and when setsockopt with IP_RELOAD_DSCP_MAPPINGS is called. It maintains an internal mapping for each of the traffic types. If one is specified in the registry,that value is used. If no mapping is found in the registry then the default values mentioned above will be used.

After reading the values the appropriate DSCP fields in the DS ip header field are filled. NDIS_PER_PACKET_INFO_FROM_PACKET which is associated with each NDIS packet. is set as follows:It would set the InfoType to be Ieee8021QInfo and the value would be the NDIS_PACKET_8021Q_INFO as defined here:

Tcpstk would set only the UserPriority field. After setting the ip header flags and the UserPriority fields in the 8021Q info ndis packet extension it would call NDIS to send the packet down.

Note

If the setsockopt for the Traffic type happens before the connect for a TCP socket, the packets are marked correctly. If the setsockopt is done after the connect, the packets are sent without any tags as if no DSCP Traffic type was set.

Example

An application would indicate for example that it will be sending packets which contain data of a voice-related application. The application would call setsockopt with the type of service it requires, in this case Voice. Since voice requires low latency, the underlying layers would look at the mapping table (if none exists it uses default mappings mentioned above) to appropriately mark all packets from that socket. The tcpstk.dll’s ip layer, would mark the appropriate DSCP fields in the ip header, and then call NDIS with the required ndis packet extension information set so that the underlying NDIS miniport driver can also mark the Layer 2 flags appropriately. **

See Also

Other Resources

Wi-Fi Standards
NDIS_PACKET_EXTENSION_FROM_PACKET
NDIS_PACKET_8021Q_INFO
setsockopt (Windows Sockets)
IPPROTO_IP
_DSCP_TRAFFIC_TYPE