Enabling multimedia services on wireless networks is a great idea nowadays, especially given the user demand. But it takes more access points to install, proactive planning for application level performance requirements and multimedia aware RF management functions. Join us to learn about multimedia application behavior and how you can get your wireless network ready.
To learn more, visit us at http://www.arubanetworks.com/wlan. Join the discussion at https://community.arubanetworks.com
IGMP snooping uses the WLAN controller to monitor which clients are subscribed to multicast video groups, and only sends multicast traffic to access points when required and even then only on a per-group basis. IGMP proxy implements multicast routing by re-originating IGMP joins and leaves from the source of the controller. As an alternative to IGMP snooping, which works on a per-SSID tunnel basis and requires an external multicast router to generate the IGMP membership reports, IGMP proxy works on a per-client basis and does not require an external multicast router. DMO Over-the-air transmissions can benefit from unicast transmissions depending on the number of clients in use. If only a small number of clients are subscribed to a multicast group, it can be more efficient to convert over-the-wire multicast to over-the-air unicast due to the faster data rates and prioritization capabilities of unicast connections. As this number grows, multicast gains in efficiency over unicast. Aruba’s DMO technology dynamically selects the appropriate conversion based on real-time network and video usage information. The conversion takes place at the controller at the 802.11 layer, on a client-by-client basis, and is transparent to the higher-level client layers. - D-DMO With D-DMO, the multicast-to-unicast conversion happens at the AP instead of the controller. DMO is for VAPs in tunnel forwarding mode where the multicast-to-unicast conversion happens at the controller. For VAPs operating in decrypt-tunnel forwarding mode, the multicast-to-unicast conversion can be moved to the APs. So the VAPs that are operating in decrypt-tunnel forwarding mode implement D-DMO instead of DMO. The bandwidth consumption on the link between the controller and APs is lower with D-DMO than DMO. This is because in D-DMO the transmissions between the controller and the APs are still multicast and the actual multicast-to-unicast conversion occurs only on the AP. With D-DMO, the controller sends multicast packets to APs only through the GRE tunnels of decrypt-tunnel mode VAPs that have active subscribers. The number of multicast streams through the GRE tunnel of a decrypt-tunnel VAP on an AP is equal to the sum of the number of multicast groups with active subscribers on each VLAN on that VAP.
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
From here we get a sense of how loaded the top AP’s are from a UC call perspective. This can aid us in figuring out if we have AP’s that are never used for UC and those that potentially are over loaded. We have tested up to 20 voice and video calls with 140Mbps background per AP. The Call Quality tab shows the distribution of call quality. Note the large unknown block. That is Video. We currently don’t have a quality metric for video. The reason is that video is more sensitive to loss, this is because Video has two types of frames that are sent. I frames that contain the entire picture and P& B frames that only contain small differences. The loss of P or B frames can go unnoticed, but the loss of an I frame can cause the picture to go all blocky. We are working on detecting these I frames and doing packet loss analysis on just those frames to determine quality. If we click on the trend tab we can see how calls are trending over time
This shows us the call quality by device type, this is useful in debunking or proving issues with a particular device type. We can click on the AP tab to show AP’s with any poor quality calls on them
This is sort of like a magic quadrant. Each dot represents a single call. If it’s peer to peer it is each half of the call. You would expect most of the dots to be in the upper right side of the graph. Meaning high call quality and high wifi health. We can see here that we actually have a pretty decent distribution of calls all within tolerance. Actually Lync is pretty resilient as these clients actually can have pretty bad wifi health and still get good scores. We can dismiss this graph and look over at calls per device.
This screen has a LOT of data – pretty much everything you need to know about every call made on the system. Some basic info is the device mac address, client name (very nice to have) what kind of call (ALG) the direction, incoming or outgoing, called party, destination (Click to scroll over)
Start time, duration etc. Note the MOS score we get for calls, This comes from the OQE server if it’s not on the QOE server, it doesn’t get displayed. (click to scroll)
Here we can see the QOS tagging information, what the WMM from the client was, including the DCSP values and what we corrected them to. We also get jitter packet loss and delay. (click to scroll)
The last section shows us if there was a roam event and the BSSID and ap name. If we click on a client we can get the overview of not just that call but all calls the client was in.
This is a great screen. We can get here by searching in the search box as well, so if we had a user that was complaining they had all bad calls we can actually look to see what was happening. (I see you had 10 calls and only 2 were bad?) This can also tell us how healthy the client is, perhaps they are using a device that is damaged? By clicking on an individual call we can get more details.
From here we see the sampled health for call quality and client health every 30 sec.we can click on the graph to zoom in
Here we can see this client had some call quality issue, clicking on the client health graph we can see there was a problem with client health at that same time.
This is really powerful information that gives you deep insight into what happened during a call. This really shines a light into what used to be a black box of UC over WiFi. We can click back to the UC tab to review all the UC info