Cisco Unified Wireless Network (CUWN) introduced a new feature, VideoStream, for enterprise wide deployments. This feature enables the wireless architecture to deploy multicast video streaming across the enterprise to wireless clients.

 

This feature recompenses the drawbacks that degrade the video delivery as the streams and clients scale
in an enterprise network. VideoStream makes video multicast to wireless clients more reliable and using the bandwidth/spectrum more efficiently. In a multi-streaming enterprise network, the feature assigns priority to the stream and provides more weight age to preferred streams.

 

This feature also guarantees delivery of video to wireless clients and denies video to new client subscription under heavy channel utilization.

 

Video delivery to wireless clients is at the highest mandatory data rates on the respective channel. There are also many clients sharing the same channel but have different channel conditions, power limitations and client processing capabilities. Therefore, multicast will not be a reliable transmission protocol to all the clients in the same channel as each client has different channel conditions.

Wireless multicast does not prioritize the video traffic even though it is Differentiated Service Code Point (DSCP) marked by the video server. The application will see a loss of packets with no ACK, and retries to the delivery will be bad.

In order to provide reliable transmissions of multicast packet, it is necessary that the network classifies queues
and provisions by means of Quality of Service (QoS). This will virtually remove the issue of unreliability by eliminating drop packets and delay of the packets to the host by marking the packets and sorting them to the appropriate queue.

Legacy Multicast

The implementation of multicast has evolved over releases on CUWN. Before CUWN 7.0 code the multicast performance was optimized and an efficient way to delivermulticast traffic from the controller to the access point was introduced.

In this process a multicast group is configured on the controller to register the access points and deliver multicast packet. This implementation dropped the process of the controller using unicast to deliver multicast packets to each access point over a Lightweight Access Point Protocol (LWAPP) tunnel.

In this configuration the underlying network components are used by the controller to replicate and deliver multicast packet to the access point. The controller becomes the multicast source for the configured LWAPP/CAPWAP group and the access points are the multicast receivers. The access point accepts Internet Group Management Protocol (IGMP) queries from the upstream router and multicast packets with a source IP address of the associated controller.

This enhances the multicast performance considerably. The IGMP query is sent to its members and clients, thus keeps updating the database.

IGMP snooping configuration also introduced a better multicast delivery of packets. The queries from an upstream multicast router/ neighbor are replied with a IGMP report based on the group configuration on the controller. A unique multicast group ID (MGIDs) is created by the controller from the IGMP reports after checking the L3 multicast addresses and the VLAN number, and updates an IGMP report to the upstream L3 switch or neighbor.

 

The controller sends the reports with the source address as the interface address on which the reports are received from the clients. A MGID table is created or updated on the access point with the client MAC addresses. When the controller receives a multicast join reply for a particular group it forwards to all the access points in the group.

However, only those access points that have active clients subscribed to that multicast group send multicast traffic. The multicast traffic flows to the client at the highest mandatory data rate as seen in the capture. The client
has associated to the access point at 802.11n rate on a 5GHz radio.