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.
Knowledge of Cisco Unified Wireless LAN Solution.
VideoStream feature is available in Cisco Unified Wireless Network software version 7.0with enhancements in Cisco Unified Wireless Network software version 7.2. This feature is supported on all wireless LAN controllers (WLANs) and newer generation indoor access points (APs). This feature is not available on autonomous access points and outdoor access points.
Supported Wireless Hardware and Software
VideoStream is supported on all wireless LAN controllers. This includes the Cisco 5500 Controller, Cisco 4400 Controller, Cisco 2100 Controller and WiSMs. VideoStream is also supported on the Cisco 2504 standalone and Cisco WiSM-2 Controller. IGMPv2 is the supported version on all of the controllers.
VideoStream is supported on all access points. This includes all 802.11n models of access points consisting of Cisco Aironet 3600 series access point, Cisco Aironet 3500 series access point, Cisco Aironet 1260 series access point, Cisco Aironet 1250 series access points, Cisco Aironet Cisco Aironet 1140 series access points and Cisco Aironet 1040 series access points. VideoStream is also supported on Cisco Aironet 1240AG* series access points and Cisco Aironet 1130AG* series access points.
The VideoStream feature was introduced in the CUWN 7.0 version of controller code and supported on later versions of controller software with enhancements.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Before going into details about the VideoStream feature, some of the shortfalls in Wi-Fi multicast need to be understood. 802.11n is a prominently discussed wireless technology for indoor wireless deployments. Equally prominent requirement is seen in multimedia service on an enterprise wireless network, in particular, video. Multicast video streaming will be a cost effective solution in a huge enterprise network as unicast of video services will not scale in an enterprise wide streaming. Multicast does not provide any MAC layer recovery on multicast/broadcast frames. Multicast and broadcast packets do not have an Acknowledgement (ACK), and all packet delivery is best effort. Multicast over wireless with 802.11a/b/g/n does not provide any mechanism for reliable transmission.
Enterprise wireless deployments are prone to interference, high channel utilization, incompatible client, low SNR at the edge of the cell. 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 as seen below in the diagram.
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.
Even though the 802.11n adaptation has gained momentum both with the network and clients, wireless multicast has not been able to use the 802.11n data rates. This has also been one of the factors for an alternate mechanism for wireless multicast propagation.
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 deliver multicast 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.
VideoStream provides efficient bandwidth utilization by removing the need to broadcast multicast packets to all WLANs on the AP regardless if there is a client joined to a multicast group. In order to get around this limitation, the AP needs to be able to send multicast traffic to the host via Unicast forwarding, only on the WLAN that the client is joined and do so at the data rate the client is joined at. Before VideoStream is configured, you must understand at a high level how it differs from the normal Multicast deployment (Multicast/Broadcast).
VideoStream, for the first time in a wireless system, provides a seamless approach for engineers to design and implement a multicast solution without destroying the bandwidth between the controller and the upstream switch or router.
Cisco VideoStream technology is a new system wide set of features of the Cisco Unified Wireless Network that incorporates some of the key enhancements to deliver superior video quality. Cisco VideoStream showcases Cisco’s RF and video expertise for delivering a reliable, consistent platform for all different types of video. This takes the physical, MAC, and application layers of the wireless LAN into consideration. The next sections highlight some of the VideoStream features and how the features uniquely enhance the delivery of video over Wi-Fi and the quality of the end user experience. A simple network diagram for VideoStream is shown here to explain the concepts that are introduced.
Introduction to the process flow for VideoStream will make it easy to understand the next few sections of the feature description. The process flow will also introduce the modules such as Stream Admission, Stream Prioritization, Radio Reservation Control, Multicast-to-unicast, and AutoQoS.
VideoStream can be enabled globally on the controller. The feature can be enabled at the radio level (2.4 GHz and 5 GHz) and at the WLAN or SSID level, and provides more control to the administrator to identify specific video streams for preferential quality-of-service treatment.
As mentioned earlier while video is an efficient, high-impact means of communication, it is also very bandwidth intensive, and as is seen, not all video content is prioritized the same. From earlier discussion it is clear that organizations investing in video cannot afford to have network bandwidth consumed without any prioritization of business-critical media.
Stream admission will empower the network administrator to have control over all the multicast video streaming in the network. Stream admission will facilitate network administrator to use pre-defined templates for input multicast streams. There are few predefined templates for stream bandwidths of 300Kbps, 500Kbps, 1Mbps, 3Mbps and 5 Mbps. Network administrators with less experience of video can use the pre-defined templates.
It is necessary to have a basic understanding of streaming video characteristic before configuring. For example, consider the above two configurations. If the video bit rate is around 4Mbps you need to manually add the configurations instead of using any of the above two templates. If Stream-Less3Mbps is used, the quality of video will be bad due missing video frames. It is observed there is pixelation of video and constant freeze of video on a wireless client. If Stream-Less5Mbps is used, the number of video clients will be less as every wireless client is guaranteed of 5Mbps while the video bitrate is only 4 M bits. If you had ten wireless I clients the aggregate client bandwidth should be around 40Mbps. Using the Stream-Less5Mbps the controller will be using 50Mbps, hence depriving 3 wireless clients of video.
Stream Priority can configure the media stream with different priority based on importance within the enterprise network. RRC Priority comes to play only when there is a congestion or contention in the wireless access point.
When there is a congestion and there are too many video multicast streams and clients, Stream 4 takes precedence over the rest of the configured streams. The configured video stream will have lower priority than voice, and higher priority than best effort traffic. All the other multicast traffic will be admitted as best effort traffic even though they are marked for QoS for Video priority.
As more and more users begin to utilize video in the workplace on Wi-Fi endpoints, the ability to gracefully manage and scale a continuous, and high-quality experience for fluctuating groups of users at any given time or location is critical. The controller and access points have a crucial decision making algorithm, that is Resource Reservation Control (RRC) provides enhanced capabilities to manage admission and policy controls. Admission and policy decisions are made based on the radio resource measurements, statistics measurement of the traffic, and system configurations. The controller initiates RRC requests to the access points for the IGMP join. The access point will process the request for all the parameters listed in this diagram:
In the above response all the parameters passed the policy configuration on the controller. The IGMP join request from the client on that access point will be admitted. If the RRC request had a response as shown below, the join request will be investigated and the RRC algorithm will be checked for the policy configuration again. The client will be admitted but as a Best effort client. However, on several attempts of RRC check it will be admitted with a better QoS priority.
RRC is initiated on a client at IGMP join to a stream and can be configured for periodic check. Due to any changes in the wireless characteristic if the RRC metric reply varies considerably the client will be denied to the stream.
RRC provides bandwidth protection for the video client by denying requests that would cause over-subscription. Channel utilization is used as a metric to determine the capacity and perform admission control. Figure 4 illustrates how RRC works. Integration with Voice CAC guarantees video quality and voice priority.
By enabling 802.11n data rates and providing packet error correction, multicast-to-unicast capabilities of Cisco VideoStream enhance the reliability of delivering streaming video over Wi- Fi beyond best-effort features of traditional wireless networks.
A wireless client application subscribes to an IP multicast stream by sending an IGMP join message. With reliable multicast, this request is snooped by the infrastructure, which collects data from the IGMP messages. The system checks the stream subscription and configuration, then collects metrics and traffic policies for the requested stream. If the requested stream is allowed by the policies, a response is sent to the wireless client attached to the access point in order to initiate reliable multicast once the stream arrives. The system also looks for available bandwidth and configured stream metrics to determine if there is enough airtime to support the new subscription. In addition, the system considers the prevailing load on the radio and the health of the media before making the admission decision. After all the above criteria are met, a join response is sent to the access point. This is when the access point replicates the multicast frame and converts it to 802.11 unicast frames. Finally, a reliable multicast service delivers the video stream as unicast directly to the client.
Increases in the number of clients accessing video over Wi-Fi place increased pressure and demand on the network. This impacts both performance and quality. Higher video scaling is a measure of the number of clients supported per controller while optimizing the traffic flow from the wired to wireless network. With Cisco VideoStream technology, all of the replication is done at the edge (on the access point), thus utilizing the overall network efficiently.
At any point in time, there is only the configured media stream traversing the network, because the video stream is converted to unicast at the access points based on the IGMP requests initiated by the clients. Some other vendor implementations do a similar conversion of multicast to unicast, but do it inefficiently as evidenced by the load put on the wired network to support the stream.
Theoretically in a non-802.11n network with both 2.4GHz and 5GHz clients associated, there can be as many as 3 or 4 clients watching a 5M bit video stream. With any additional video clients, the channel utilization will be maxed out and the possibility of the clients dropping or losing connectivity is higher.
With 802.11n network the scalability of clients increases significantly due to the availability of bandwidth. The client scalability of clients with or without channel bonding also varies in the 802.11n network. This is non-existent in a legacy/non 802.11n network.
Now you should have an understanding on the infrastructure functionality when VideoStream is configured. It is also important to understand how the video applications, client devices, etc. contribute for a better synergy for the system to work. It has been observed in all wireless installation applications and clients have an equal role to play for a end-to-end delivery.
There are various video applications available today for streaming video over IP network. The video streaming source is common across wired and wireless networks. The controller is in the core or the distribution of the wired network in the path as the last reporter for multicast network. Some of the video applications that have been tested with VideoStream are discussed in the next sections.
Cisco Media Experience Engine
Cisco Content Delivery Applications
Windows Media Server/services
VBrick – H.264 Appliance
The Cisco Media Experience Engine (MXE) 3500 is an easily deployed appliance that integrates transparently into the network to deliver a rich set of media-processing capabilities. Designed as a core component of the Cisco Media-Ready Network, the Cisco MXE 3500 provides:
Comprehensive live and video on demand (VoD)-based transcoding services that allow you to share video content across your network to virtually any type of endpoint
Innovative postproduction features that transform ordinary video content into stunning studio-quality output
Cutting-edge speech-to-text transcription services
Innovative collaboration with other applications delivered by the Cisco suite of media products
The result is a powerful media-processing platform that allows IT administrators to significantly streamline operating costs associated with live media streaming, media production, and distribution.
Cisco Content Delivery Applications are the software elements of the CDS and implement content processes on top of Cisco Content Delivery Engines, which provides functions such as ingest, storage, caching, personalization, and streaming. TV streaming delivery applications include:
Cisco Vault Application
Cisco TV Streamer Application
Cisco TV Playout Application
Cisco Integrated Streamer-Vault Application
Cisco Content Delivery System Manager
Internet Streaming Content Delivery Applications include:
Cisco Internet Streamer Application
Cisco Content Acquirer Application
Cisco Service Router Application
Cisco Content Delivery System Manager
The Cisco Content Delivery System comprises one or more networked Cisco Content Delivery Engines, each optimized for one or more tasks such as content ingest, storage, caching, or streaming.
Windows Media server streams digital audio and video content to clients over the Internet or an intranet. These clients can be other computers or devices that play back the content using a player, such as Windows Media Player. Or, they can be other computers that are running Windows Media Services (called Windows Media servers) that proxy, cache, or redistribute the content.
The content that your Windows Media server streams to clients can be a live stream or a pre-recorded digital media file. Wireless companies that deliver wireless broadband entertainment services by using scalable and reliable Windows Media servers use media servers.
Internet broadcasters that deliver content for radio, television, cable, or satellite.
Film and music distributors that distribute audio and video content in a secure manner without excessive buffering or network congestion.
IPTV professionals that deliver a high-quality IPTV experience on local area networks (LANs).
Haivision’s Furnace provides a secure, easy to use, simple to deploy end-to-end system for encoding and distributing live video to computers and set top boxes, for creating scheduled playback channels for enterprise TV and signage, and for recording content and delivering video on demand.
The Furnace provides a complete IP video solution. The viewing experience to access live and recorded channels as well as on demand content is provided for the desktop through the “zero footprint” InStream player and to fixed monitors and displays through the Stingray™ set top box. With fine grain control of all viewers and displays, the Furnace is the ideal system for managing and distributing enterprise video securely, for establishing HD signage throughout a facility, for providing on-demand material, and for capturing, organizing, and reviewing events.
End-to-End H.264, the Furnace provides seamless end-to-end capabilities. The Furnace Portal Server controls the direct and secure distribution of SD and HD H.264 video and MPEG-1, MPEG-2, MPEG-4 SD video to both the InStream player and the Stingray set top box. The Furnace Playback Manager supports scheduled channels for both live and prerecorded IP video broadcasts and digital signage. The Furnace Media Server enables video-on-demand. Leveraging the efficiencies of H.264 video compression, high definition media is available to all users. Furthermore, the Furnace incorporates direct support for Haivision’s revolutionary Barracuda™ and Makito™ H.264 encoders delivering live SD and HD content at bit rates from 150 kbps to 15 Mbps.
Cell planning is a key aspect that needs to be considered for a video or voice deployment. Cell planning is not as simple as mounting an access point in an appropriate location and providing wireless connectivity. This has changed over the last few years as pervasive wireless coverage has become a requirement. There are several tools available today to perform a proper cell planning. Cisco Wireless Control System has a Planner tool that is very effective.
Besides normal wireless planning criteria there are a few more parameters that need to considered in the cell planning for video. These are the latency, jitter and packet loss. Highlighting the same in the table below and also categorizing the same with field realistic values, you can see that cell planning is very effective.
|HD Video Teleconferencing||High||High||High||High|
|Video on Demand||Low||Low||Medium||Low|
|Live Streaming Video||Medium||Medium||Medium||High|
In order to quantify the video application in terms of values, this table has been widely acknowledge for video applications:
|Metric||Video Collaboration||Digital Signage||TelePresence||Video Surveillance|
|Latency ( secs)||150||200||150||300|
|Packet Loss (%)||1%||.05%||.05%||.05%|
Consider a Cisco CAPWAP access point installed with the latest version of code in a clean test environment with no interference in a office environment. When the client association rate, signal strength and noise are measured at various points the data looks as follows. The measurements below are captured with channel bonding and without channel bonding. Observe the signal strength and the noise in all test scenarios. This will give you a basic understanding of the variation of signal and noise. The planning guidelines are not based on the two considered values, but also take into consideration the co-channel interference, client data rates, client transmit power, total channel capacity. These will be planning considerations when the access point density and client count increase.
|Distance from Access point (ft)||Client Association rate (Mbps)||Signal Strength (-dbm)||Noise (-dbm)|
|Distance from Access point||Client Association rate||Signal Strength||Noise|
|Distance from Access point||Client Association rate||Signal Strength||Noise|
The Call Admission Control (CAC) configuration stops the oversubscription of the channel and guarantees configured media bandwidth. The CAC configuration will also stop new media users, hence safe-guards the current users from being affected when oversubscribed.
The CAC configurations for VideoStream is a key tuning point that balances the voice, video and data users on a wireless media using Cisco Unified Wireless Network 7.0. This configuration is radio specific and can be enabled on both 2.4 GHz and 5 GHz radios. The CAC configuration can be enabled by clicking WIRELESS > 802.11a/n or 802.11b/g/n > Media.
By default both the Voice and Video CAC settings are disabled. Any configurations that are made here will directly apply to the voice and video configurations. In short, Media =Voice+Video. This is by default configured to a max of 85% of the total radio bandwidth. The remaining 15% of the radio bandwidth is best effort traffic (data).Depending on the usage of data, voice and video it is recommended to change these values. The media settings can be changed by clicking the Media tab. It is recommended to maintain default values until there is an absolute necessity to change these values.
The voice and video settings can be tuned based on the type of network services provided. If voice is the prime application in the network the CAC values can range from 5 - 85%. There is also a Reserved roaming bandwidth that is included in the above voice configuration. With a max CAC setting of 85% on a 5Ghz radio, the wireless system can accommodate about 21 voice calls. Similarly on a 2.4Ghz radio with a max CAC setting of 85%, the system can accommodate about 13 voice calls.
On a similar note if you switch to a video CAC, with a max of 85% the wireless system can accommodate about 22 clients on a 5Ghz radio. With a max CAC setting of 85% on a 2.4 Ghz radio, the wireless system can accommodate 10 clients. The table below will give an idea of the how the systems can act under different configurations. These values are with channel bonding on the 5Ghz radio and a video bit rate configuration of 3M bits.
|Video CAC Value||Video Clients||Voice Call||Voice CAC Value|
Note: These test results are documented for CUWN 7.2 after the improvement of aggregation, buffering and smart scheduling of video packets to client.
|Video CAC Value||Voice CAC Value||Video Bit rate||Clients|
|85||0||1.5 ~2 M||51|
Note: All the clients in test are similar in configuration with a 3X3 802.11a/b/g/n wireless adapter. The test environment is clear from all wireless interferences and also non-WiFi interferers.
The radios are capable of handling 255 associations. Because the wireless media is shared half-duplex media there will be contention by the clients. As clients move further away from the radio, the throughput decreases. Further down the edge of the cell the client data rates drops to the lowest, and hence introduced too many retries. Even though the radio can allow a higher number of associations, it is recommended to limit the clients to less than 60 per access point for normal data applications. However, when you have voice and video services on the access point it is recommended to plan the access point layout such that client adapter signal strength does not fall below -60db or equivalent client association rate. Also, consider providing a 15~20% cell overlapping to ensure there is smooth handoff of the video application from one access point to another when the clients are roaming.
Normally, all video hosting sources ensure that the DSCP marking is appropriately marked on the wired side. If the video server is located locally and does not have to traverse any router boundaries, DSCP marked packets are guaranteed to be the same. Sometimes when the video packets are traversing routed boundaries, the DSCP markings tend to be reset. CUWN ensures that video packets have the correct DSCP marking on the wireless side. This can be observed on the access point as the video queue counters will be incrementing. If there is no video traffic and only best-effort traffic, the respective counters will increment. All of the discussed operation will be effective only if the video profile on the controller is mapped to 802.1p protocol with a tagged value of 5.
VideoStream can be deployed on an existing enterprise wide wired and wireless network. The overall implementation and maintenance costs of a video over wireless network are greatly reduced. The assumption is that the wired network is multicast enabled. In order to verify that a distribution or access switch is part of the layer 3 network, connect a client machine to the switchport and verify if the client machine is able to join a multicast feed.
Show run | include multicast will display if multicast is enabled on the layer 3 switch. If not enabled for multicast you can enable multicast by adding the following command on the switch.
Depending on the type of Protocol Independent Routing (PIM) configuration on the wired network, the layer 3 switch is configured for either PIM Sparse mode or PIM dense mode. There is also a hybrid mode, PIM sparse-dense mode which is widely used.
Show ip igmp interfaces will display the SVI interfaces that are participating in the IGMP membership. This command will also show the version of IGMP configured on the switch or the router. The IGMP activity on the interface can also be verified in the form of joins and leaves by the clients.
The above configuration can be verified by running the show ip mroute command on the layer 3 switch.
The above capture has certain entries that need to be looked in to. The special notation of (Source, Group), pronounced “S, G” where the source “S” is the source IP address of the multicast server and “G” is the Multicast Group Address that a client has requested to join. If the network has many sources you will see in your routers an (S,G) for each of the source IP address and Multicast Group addresses. This capture also has information of the outgoing and incoming interfaces.
VideoStream is supported on all wireless LAN controllers. This includes the Cisco 5500 Controller, Cisco 4400 Controller, Cisco 2100 Controller and WiSMs. VideoStream is also supported on the Cisco 2504 standalone and Cisco WiSM-2 Controller. IGMPv2 is the supported version on all of the controllers.
VideoStream is supported on all newer access points. This includes models of Cisco Aironet 3500 series access point, Cisco Aironet 1260 series access point, Cisco Aironet 1250 series access points, Cisco Aironet 1240AG series access points, Cisco Aironet 1140 series access points, Cisco Aironet 1130AG series access points and Cisco Aironet 1040 series access points.
The VideoStream feature is introduced in the CUWN 7.0 version of controller code and supported on later versions of controller software.
VideoStream feature requires multicast enabled on the controller. Multicast on the controller can be enabled in two modes: multicast-unicast and multicast-multicast. When IP multicast is enabled, the controller delivered multicast packets to wireless LAN clients by making copies of the multicast packets, then forwarding the packets through a unicast Lightweight Access Point Protocol tunnel to each access point connected to the Controller. Unicast delivery places a heavy burden on the AP, as well as the Controller’s network processing unit, due to the deluge of packets that need to be replicated down to the access points.
Cisco Multicast-Unicast delivery method is commonly used by customers that “only” want to provide multicast over their wireless network, or the network does not support multicast. It is recommended for customers to avoid using the Multicast-Unicast method of delivery. This method is processor intensive depending on the number of multicast streams to be supported. In this mode every multicast packet must be replicated to all access points that have joined the controller regardless if there is a client requesting the multicast group address.
The multicast performance has been optimized with the introduction of Multicast-Multicast mode. Instead of using unicast to deliver each multicast packet over the CAPWAP tunnel to each access point, a CAPWAP multicast group is configured to deliver the multicast packet. This allows the routers in the network to use standard multicast techniques to replicate and deliver multicast packets to the access points. For the CAPWAP multicast group, the controller becomes the multicast source and the access points become the multicast receivers. The multicast performance is enhanced as the access points accept IGMP queries only from the router and multicast packets with a source IP address of the controller with which they are currently associated.
Note: IP multicast uses the Class D range of IP addresses 220.127.116.11 through 18.104.22.168. The reserved ranges of address, Link Local Multicast address (22.214.171.124 through 126.96.36.199) are for use by protocols and cannot be used. The rest of the Class D address, Administratively Scoped multicast address (188.8.131.52 through 184.108.40.206) can be used for configuring the IP networks for multicast.
The above configuration can also be configured using command lines in a couple of steps.
Note: It is recommended to use one unique multicast address/controller.
One more important configuration on the controller is to enable IGMP snooping. Enabling of IGMP snooping on the controller helps to collect IGMP reports from the hosts and sends each AP a list of hosts that are listening to any multicast group. The AP then forwards multicast packets only to those hosts.
IGMP timeout and IGMP Query interval help the IGMP snooping to be more effective. When the IGMP timeout expires, the controller sends a query on all SSIDs causing the clients that are listening to the multicast group to send a packet back to the controller. IGMP query interval is how often the controller sends a query to all SSIDs. If the IGMP timeout is set to 60 seconds and the IGMP query interval is configured to 20, there will be three queries.
The VideoStream feature can be enabled in three different places depending on the implementation of the feature. This helps network administrators control enabling VideoStream feature on the controller.
The feature must be enabled globally on the controller by checking the tab under Wireless > Media Stream > General. Enabling the feature here will populate some of the configuration parameters on the controller for VideoStream.
The VideoStream feature can also be enabled under the PHY type. The customer has the flexibility to enable VideoStream only on 5Ghz radio or 2.4Ghz radio or both.
The multicast direct button under WLAN > QoS appears on if the feature is enabled globally. This gives the flexibility to enable VideoStream feature per SSID.
The multicast feeds can be enabled to take part in RRC only if the multicast feed is configured on the controller. In order to add a multicast stream to the controller, click Streams under MediaStream.
As mentioned it is necessary that the administrator is aware of the video characteristic streaming through a controller. A true balance must be drawn when the streams configuration are added. For example, if the stream bit rate varies between 1200 kbps and 1500 kbps the stream must be configured for a bandwidth of 1500kbps. If the stream is configured for 3000 kbps then you will have lesser video client serviced by the access point. Similarly, configuring for 1000 kbps will cause pixelization, bad audio and bad user experience.
There are a few preconfigured templates on the stream configuration that can be used. It is necessary to apply the similar judgment when selecting them. Some of the configurations are already captured in the earlier part of the document (Stream Admission and Prioritization). If not using the templates, there are a few more configurations that can be used to enhance the user experience. The average packet size can be changed to match the streaming video. Resource reservation control can enabled for periodic update so that the systems can check for health very often. This can also be disabled to enable RRC to run only at admission. The priority of the stream can be also set to a high value for prioritization of the stream. A configured value of 8 will allow the stream to be prioritized and not bumping down to best effort.
On any violation of the previous policies, the stream can be downgraded to best-effort or can be dropped. It is recommended to downgrade to best-effort.
The multicast destination start IP address and end IP address can be the same address as shown above. One can also configure a range of multicast address on the controller. There is no limitation on the number of multicast addresses entries or the number of stream entries. The Start IP address can be 220.127.116.11 and the End IP address can be 18.104.22.168 .
VideoStream configs can be enabled on both the radios on the access points. The configs on the radio can be configured or modified only with the radios disabled. Some configurations will also require the WLANs /SSID to be disabled.
Note: It is recommended to make the all configuration required on the radios when disabled.
Click WIRELESS > 802.11 a/n > Media > Media to enable the VideoStream and add CAC/QOS configurations. Similar configurations might be required on the 802.11 b/g/n radio, depending on the type of service provided on the radio.
By default VideoStream is disabled on the radios. The feature can be enabled by checking the Multicast Direct Enable. The radio also can also be configured for the number of clients that can join a multicast stream by pulling down the Multicast Direct Max Number of Streams. This can be either set to Auto to allow all clients to join the multicast stream. The client count on the radio can also be controlled by configuring a value from 1-20.
The Unicast Video Redirect is enabled by default. This will allow unicast video traffic flow to wireless clients.
RRC will admit clients to join a stream after pass criteria (explained earlier) is achieved. The admitted clients will have a QoS priority of 4. The clients who do not pass the RRC criteria will be dropped and will not be allowed to join the stream. However, this can be overruled by enabling the Best Effort QoS Admission. Now all wireless clients requested to join a stream will be admitted to the multicast stream, but some of them will have a QoS priority of 0. The media bandwidth is currently set to 85% by default.
Media bandwidth is the sum of Voice and Video traffic on a radio interface. The lowest that a client can drop on the radio is 6000 kbps to join a streaming video. If there are clients that need to be restricted from joining a stream below a certain PHY rate this value can be changed. The value is 6000 by default. The maximum retry percent is, by default, set to 80%. The system keeps track of the retries on the radio. If the retries are greater than the configured value the client will not be allowed to join the stream.
Note: It is recommended to keep the default values.
Click WIRELESS > 802.11 a/n > Media > Video to enable CAC/Admission control. Enable Admission control for Video.
Depending on the type of service that needs to be enabled on the radio configure a value for Max RF Bandwidth. This value added here will decide the number of video clients to be allowed to join a configured multicast stream on the radio (refer to the Table Voice / Video CAC Value). For example, a maximum value of 80% will allow twenty wireless clients stream with a bit rate of 5M bits.
Click WIRELESS > 802.11 a/n > Media > Voice to enable Voice CAC/Admission control. Enable Admission control for Voice. This value added here will decide the number of voice calls that will be allowed on the radio (refer to the Table Voice / Video CAC Value).
The radio was disabled to add the VideoStream configurations. Enable the 802.11a radio.
The above configuration can be repeated on the 802.11b/g/n radio. Disable the 802.11b/g/n radio first before any changes are made.
Enabling the VideoStream feature on 802.11b/g/n needs closer attention as there will be a higher client density. It is necessary to allocate a sufficient amount of bandwidth for wireless clients to join the multicast stream. Balancing the data, voice and video clients on the 802.11b/g/n radio should be planned well in advance so the configurations, once applied, will not cause major issues.
Note: BandSelect and ClientLink are the two features that will service the wireless clients and reduce some of the clients on the 2.4 GHz radio.
Repeat the steps shown in the three screenshots above on 802.11b/g/n radio. The screenshots are shown below.
By default the VideoStream feature is disabled on the radios. Click WIRELESS > 802.11 b/g/n > Media > Media. Check the Multicast Direct Enable feature. Pull down Multicast Direct Max number of Stream to configure a value 1 to 20, or leave it at default.
The Unicast Video Redirect is enabled by default. This will allow unicast video traffic flow to wireless clients.
RRC will admit clients to join a stream after pass criteria (explained earlier) is achieved. The admitted clients will have a QoS priority of 4. The clients who do not pass the RRC criteria will be dropped and will not be allowed to join the stream. However, this can be overruled by enabling the Best Effort QoS Admission. Now all wireless clients requested to join a stream will be admitted to the multicast stream, but some of them will have a QoS priority of 0.
The media bandwidth is currently set to 85% by default. Media bandwidth is the sum of Voice and Video traffic on a radio interface. The lowest that a client can drop on the radio is 6000 kbps to join a streaming video. If there are clients that need to be restricted from joining a stream below a certain PHY rate this value can be changed. The value is 6000 by default. The maximum retry percent is by default set to 80%. The system keeps track of the retries on the radio and if the retries is greater than configured value the client will not be allowed to join the stream.
Click WIRELESS > 802.11 b/g/n > Media > Video to enable CAC/Admission control. Enable Admission control for Video.
Depending on the type of service that needs to be enabled on the radio, configure a value for Max RF Bandwidth. The value added here will decide the number of video client that will be allowed to join a configured multicast stream on the radio (refer to the Table Voice / Video CAC Value).
Click WIRELESS > 802.11 b/g/n > Media > Voice to enable Voice CAC/Admission control. Enable Admission control for Voice. The value added here will decide the number of voice calls to be allowed on the radio (refer to the Table Voice / Video CAC Value).
Enable the radio(s) to allow clients to associate.
One or all WLANs / SSIDs configured can be enabled for streaming video with VideoStream. This is another configuration step that can control the enabling of the VideoStream feature. Enabling or disabling of the VideoStream feature is non-disruptive. Click WLAN > <WLAN ID> > QoS.
Configure the Quality of Service to Gold(video) to stream video to wireless client at a QoS value of gold (4). This will only enable video quality of service to wireless clients joined to a configured stream on the controller. The rest of the clients will be enabled for appropriate QoS. Enable Multicast Direct on the WLAN by checking the feature as shown above. This will enable the WLAN to service wireless clients with the VideoStream feature.
All wireless clients requesting to join a stream will be assigned video QoS priority on admission. Wireless client streaming video prior to enabling the feature on the WLAN will be streaming using normal multicast. Enabling of the feature will switch the clients to multicast-direct automatically on the next IGMP snooping interval.
Legacy multicast can be enabled on the WLAN by not checking the Multicast Direct feature. This will show that wireless clients streaming video are in Normal Multicast mode.
Make sure the wireless clients are associated to the access point(s), and are configured for a correct interface. As seen in the capture below there are three clients associated to one access point. All three clients have an IP address from VLAN124 (testclients).
The associated clients have an IP address and good uplink connectivity to the access point.
There are no clients that have joined the multicast stream. There is only the controller entry with the configured multicast group address registered on the switch.
Switch14-1>en Password: Switch14-1#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD & Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 22.214.171.124), 01:23:52/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00 (10.10.10.10, 126.96.36.199), 00:01:45/00:01:15, flags: PT Incoming interface: Vlan122, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 188.8.131.52), 01:23:55/00:02:13, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan122, Forward/Sparse-Dense, 01:23:55/00:00:00
There is no video streaming on the wired network, hence no entries for the (S,G) source, group addresses. Enable streaming on the wired side by connecting a video server with a configured multicast address 184.108.40.206. The capture on the switch will be more than what was observed earlier.
Switch14-1#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD & Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 220.127.116.11), 01:23:52/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00 (10.10.10.10, 18.104.22.168), 00:01:45/00:01:15, flags: PT Incoming interface: Vlan122, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 22.214.171.124), 01:23:34/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (10.10.10.101, 126.96.36.199), 00:08:26/00:02:58, flags: PT Incoming interface: Vlan122, RPF nbr 0.0.0.0 Outgoing interface list: Null Switch14-1#
Join a wireless client to the multicast streaming video. Also, capture debug bcast all enable from the controller. The debug capture has information on the client request, group address, status of the request and the update.
*bcastReceiveTask: Sep 29 13:31:56.913: bcastProcessNPUMsg: received packet (rxTunType 1, dataLen 155) *bcastReceiveTask: Sep 29 13:31:56.913: bcastLwappRx: received lwapp packet from STA 0021.5dac.d898 *bcastReceiveTask: Sep 29 13:31:56.913: IGMP packet received over vlanid = 0 from client 00:21:5d:ac:d8:98 *bcastReceiveTask: Sep 29 13:31:56.913: Recieved Igmp v2 report packet from client 00:21:5d:ac:d8:98 *bcastReceiveTask: Sep 29 13:31:56.913: report packet recevied for group addr 188.8.131.52 *bcastReceiveTask: Sep 29 13:31:56.913: join group 184.108.40.206 and vlan = 0 is not there adding... *bcastReceiveTask: Sep 29 13:31:56.913: 00:21:5D:AC:D8:98 client joining the group: 220.127.116.11, with status = 1, qos=0 and valid = 1... *bcastReceiveTask: Sep 29 13:31:56.929: Received status Update for client: 00:21:5D:AC:D8:98 , status = 2, qos = 4 *bcastReceiveTask: Sep 29 13:31:56.929: 00:21:5D:AC:D8:98 client status is updated from 1 to ALLOWED state. *bcastReceiveTask: Sep 29 13:31:56.930: IGMP message send succeeded src 10.10.10.10 and dst 18.104.22.168, hdr len 32,message type 16 *bcastReceiveTask: Sep 29 13:31:56.930: update ap for status = 2
The wireless client with MAC address 00:21:5d:ac:d8:98 sent an IGMP v2 join in the form of a report to a stream address of 22.214.171.124. The client joined the group with a qos=4 and was changed to an ALLOWED state (refer to Flow diagram).
Click MONITOR > Multicast > and the MGID for the streaming address 126.96.36.199. It is observed that the MAC address of the wireless client is in a Multicast-Direct Allowed State. The QoS User priority is 4. This shows the client processing the video packets in the video queue.
The processing of a wireless client's request on a controller can be clearly understood by enabling debugs on the controller. The enabled debugs are also captured on the controller. There is a request 3646 created for client with MAC address 0021.5dac.d898. All of the data flow is wrt to the client with the MAC address 0021.5dac.d898 is shown in the debug below. The RRC kicks in to validate the resources for the associated radio. The validation is successful and the client is admitted based on the values validated. The stream is still in a blocked state until the stream is admitted and the client will not receive any video. The client will start streaming video once it receives a join response.
Any further requests from the same client will be validated. Because the client is already streaming the RRC engine will respond with an “Already admitted “message. This will not hinder the performance of the wireless client.
(Cisco Controller) >show debug MAC debugging .............................. disabled Debug Flags Enabled: Media-Stream Admission debug enabled. Media-Stream Config debug enabled. Media-Stream Errors debug enabled. Media-Stream Event debug enabled. Media-Stream Rrc debug enabled. (Cisco Controller) > *rrcEngineTask: Sep 29 15:37:13.181: rrcEngineProcessPurgeTimer: table expired *bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform test AP 1100 type *bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform not AP 1100 *bcastReceiveTask: Sep 29 15:37:18.599: mStreamWlanMc2ucAllowed allow *bcastReceiveTask: Sep 29 15:37:18.599: mStreamBand 1 allow mc2uc *bcastReceiveTask: Sep 29 15:37:18.599: stream policy allow mc2uc *bcastReceiveTask: Sep 29 15:37:18.605: mc2uc update client 0021.5dac.d898 radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124 *bcastReceiveTask: Sep 29 15:37:18.605: msPolicyGetRrcQosSupport 1 4 1 *bcastReceiveTask: Sep 29 15:37:18.605: mc2uc begin check policy *bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform test AP 1100 type *bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform not AP 1100 *bcastReceiveTask: Sep 29 15:37:18.605: mc2uc qos admit 1 qos 4 pri 1 *bcastReceiveTask: Sep 29 15:37:18.605: mc2uc submit client client 0021.5dac.d898 radio c47d.4f53.14f0 destIp ef040506 mgid 569 vapId 1 vlan 124 *bcastReceiveTask: Sep 29 15:37:18.605: start FindRequestByClient *bcastReceiveTask: Sep 29 15:37:18.605: FindRequestByClient not found dest ef040506 client 0021.5dac.d898 radio c47d.4f53.14f0 *bcastReceiveTask: Sep 29 15:37:18.605: Creating request 3646 *bcastReceiveTask: Sep 29 15:37:18.605: for radio c47d.4f53.14f0 *bcastReceiveTask: Sep 29 15:37:18.605: for client 0021.5dac.d898 *bcastReceiveTask: Sep 29 15:37:18.605: rrcEngineInsertAdmitRequest dest ef040506 mgid 569 request 3646 *bcastReceiveTask: Sep 29 15:37:18.606: rrcEngineSendMeasureMetricsRequest sent request 3646 to radio c47d.4f53.14f0, minRate = 6000, maxRetryPercent = 80 *rrcEngineTask: Sep 29 15:37:18.607: rrcEngineProcessRadioMetrics start radio c47d.4f53.14f0 request 3646 *rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest look for request 3646 *rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest found request 3646 *rrcEngineTask: Sep 29 15:37:18.607: done rrcEngineProcessRadioMetrics radio c47d.4f53.14f0 request 3646 *rrcEngineTask: Sep 29 15:37:18.613: rrcEngineProcessClientMetrics radio c47d.4f53.14f0 request 3646 *rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest look for request 3646 *rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest found request 3646 *rrcEngineTask: Sep 29 15:37:18.613: rrcEngineRemoveAdmitRequest request 3646 *rrcEngineTask: Sep 29 15:37:18.613: p_video = 0, p_voice = 0, pb = 198, video_qo = 0, video_l_r_ratio = 0, video_no = 0, video_delay_hist_severe = 0, video_pkt_loss_discard = 0, video_pkt_loss_fail = 0, *rrcEngineTask: Sep 29 15:37:18.613: radio_tx_q_max_size = 1, radio_tx_q_limit = 672, vi_tx_q_max_size = 0, current_rate = 234 *rrcEngineTask: Sep 29 15:37:18.613: msPolicyGetStreamParameters 1500 1200 *rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646 radio c47d.4f53.14f0, decision 1 *rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646 radio c47d.4f53.14f0, decision 1 *rrcEngineTask: Sep 29 15:37:18.613: mStreamBandMc2ucAdmit besteffort 0 *rrcEngineTask: Sep 29 15:37:18.613: Approve Admission on radio c47d.4f53.14f0 request 3646 vlan 124 destIp ef040506 decision 1 qos 4 admitBest 0 *rrcEngineTask: Sep 29 15:37:18.614: Recording request 3646 destIp ef040506 qos 4 vlan 124 violation-drop 0 priority 1 *rrcEngineTask: Sep 29 15:37:18.614: done rrcEngineProcessClientMetrics client 0021.5dac.d898 radio c47d.4f53.14f0 request 3646 *bcastReceiveTask: Sep 29 15:37:19.553: mc2uc update client 0021.5dac.d898 radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124 *bcastReceiveTask: Sep 29 15:37:19.553: Already admitted, mc2uc Update the last IGMP timestamp *bcastReceiveTask: Sep 29 15:37:20.553: mc2uc update client 0021.5dac.d898 radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124 (Cisco Controller) >
Some of the show commands were captured earlier in this document. This section of the capture is only for reference. For more details on the commands, refer to the CUWN Release 7.0 Commands Reference Guide.
(Cisco Controller) >show ap summary Number of APs.................................... 1 Global AP User Name.............................. Not Configured Global AP Dot1x User Name.................... Not Configured AP Name Slots AP Model Ethernet MAC Location Port Country Priority ------------- ----- -------------------- ----------------- ---------------- CAP3502E 2 AIR-CAP3502E-A-K9 c4:7d:4f:3a:06:86 default location LAG US 1 (Cisco Controller) > (Cisco Controller) >show client summary Number of Clients................................ 2 MAC Address AP Name Status WLAN Auth Protocol Port Wired ----------------- - ---------------- ------------- ---------- ---- 00:1d:e0:00:ab:c7 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No 00:21:5d:ac:d8:98 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No (Cisco Controller) > (Cisco Controller) >show media-stream multicast-direct state Multicast-direct State........................... enable Allowed WLANs.................................... 1 (Cisco Controller) > (Cisco Controller) >show media-stream group summary Stream Name Start IP End IP Operation Status ------------- -------------- -------------- ---------------- test1.5K 188.8.131.52 184.108.40.206 Multicast-direct (Cisco Controller) > (Cisco Controller) >show media-stream group detail test1.5K Media Stream Name................................ test1.5K Start IP Address....................................... 220.127.116.11 End IP Address........................................ 18.104.22.168 RRC Parmmeters Avg Packet Size(Bytes)............................... 1200 Expected Bandwidth(Kbps)........................ 1500 Policy......................................................... Admit RRC re-evaluation....................................... periodic QoS............................................. Video Status................................... ...... Multicast-direct Usage Priority.............................. 1 Violation...................................... fallback (Cisco Controller) > (Cisco Controller) >show network multicast mgid summary Layer2 MGID Mapping: ------------------- InterfaceName vlanId MGID ------------------------ ------ ---- data 123 11 management 0 0 testclients 124 12 Layer3 MGID Mapping: ------------------- Number of Layer3 MGIDs........................... 7 Group address Vlan MGID --------------- --- ---- 22.214.171.124 0 550 126.96.36.199 0 555 188.8.131.52 0 552 184.108.40.206 0 556 220.127.116.11 0 553 18.104.22.168 0 551 22.214.171.124 0 554 (Cisco Controller) >show 802.11b media-stream rrc Multicast-direct................................. Enabled Best Effort.......................................... Disabled Video Re-Direct................................. Enabled Max Allowed Streams........................ Auto Max Video Bandwidth....................... 30 Max Voice Bandwidth........................ 55 Max Media Bandwidth....................... 85 Min PHY Rate..................................... 6000 Max Retry Percentage........................ 80 (Cisco Controller) >
CUWN 7.2 software supports VideoStream feature on the newer controller hardware. This includes:
Cisco 5500 series controllers
Wireless Service Module - 2
Cisco 2500 series controllers*
Cisco ISR-G2 with SRE module*
Note: *—The performance numbers differ on the non-802.11n access points.
CUWN 7.0 software supports VideoStream feature on the newer controller hardware. This includes:
Cisco 5500 series controllers
Cisco 4400 series controllers
Cisco 2100 series controllers
Wireless Service Module
VideoStream is also supported on the Cisco 2504 standalone and Cisco WiSM-2 controller.
CUWN 7.2 software supports VideoStream feature on all newer 802.11n access points and a few legacy access points. This includes:
Cisco Aironet 3600 series access points
Cisco Aironet 3500 series access points
Cisco Aironet 1260 series access points
Cisco Aironet 1250 series access points
Cisco Aironet 1240AG series access points**
Cisco Aironet 1140 series access points
Cisco Aironet 1130AG series access points**
Cisco Aironet 1040 series access points
Note: **—Client capacity varies on the low end controllers.
The VideoStream feature can stream video over Cisco Unified Wireless hardware and provide a superior quality. Static CAC configuration will provide wireless client control on the radios. The feature enables multicast streaming over wireless in par with multicast streaming on wired clients. Multicast streaming to wireless clients with IGMP join request only and replication is done only at the access points thus conserving bandwidth on the uplink ports of the distribution and access switches.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.