This fall your wireless networks will experience many devices upgrading to the new Android 5.0(L-release) and Apple iOS 8 releases (cue: IT managers groan). There have now been many blogs attempting to capture the enhancements expected with these releases. Today I am going to focus on describing how Android L and iOS 8 may affect customers deploying Cisco enterprise grade Wi-Fi networks based upon our research and testing of the Apple seed. Our verdict: Carry on with business as usual.
Here are four features we predict will have the most impact your networks:
1. Chromecast and Google Cast Enhancements (Android L)
Rishi Chandra, the Director of Chromecast Product Management announced that, starting with the Android L release, users have the ability to cast to your neighboring devices such as a TV without having to connect to your Wi-Fi network. In the demo, a phone used the cellular connection to connect to chromecast through the cloud. A variety of techniques are used to authenticate the users in the same room OR use a pin-code as an alternative. Users can Google Cast an ecosystem of applications or even their own applications over any Android or iOS device as well as Cloud based apps on Chrome.
Predicted Impact: Given that this feature works transparently to the Wi-Fi, it is expected that there is no impact on the WLAN in your classrooms or dorm rooms or auditoriums where this will most likely be used.
2. Peer-to-peer AirPlay discovery and playback (iOS 8)
Starting with the iOS 7.1 release, AirPlay devices will discover an AppleTV via the bluetooth network. Users could also secure their AppleTV via a 4 digit pin-code. With the iOS 8 release, Airplay devices can also mirror their content via Airdrop. This feature offers an alternative method for customers to discover and mirroring of Bonjour traffic without accessing the corporate Wi-Fi network.
Predicted Impact: Again this feature operates transparent to the Wi-Fi and therefore customers using this feature should not see any impact on the WLAN. Cisco wireless customers also have the ability to use the Service Discovery Gateway on Cisco IOS based switches, routers or wireless LAN controllers or the Bonjour Services Directory on AireOS controllers. Read More »
Johns Hopkins Medicine is one of the leading health-care providers in the US. The Johns Hopkins University School of Medicine is consistently ranked as one of the top Medical Schools in the US and the Johns Hopkins Hospital is consistently ranked #1 in the US for 21 years in a row! In a previous blog in 2012, we described how the Cisco Wireless LAN controller 7.5 release enables wireless networks to recover with no client re-authentication in the event of a primarily controller failure. In this blog, I will share more details about unified access deployment at the Johns Hopkins Hospital with particular focus on the High Availability design.
Patients are the focus at Johns Hopkins Hospital. Johns Hopkins uses state-of-the-art technology in their hospitals to ensure that patients get the latest advances from surgical tools, radiologic imaging suites with the best diagnostic capabilities to something as humane as sound-absorbing private rooms for each patient. Read More »
Wi-Fi roaming is often a tumultuous subject. The crux of the issue is, with Wi-Fi the roaming decision is left to the client.
In the recent years, there have been great strides in improving Wi-Fi roaming with the creation of standards-based roaming technologies. Cisco first pioneered fast roaming many years ago with CCKM (Cisco Centralized Key Management), which was the foundation for 802.11r. 11r which was ratified by the IEEE in 2008, allows for fast roaming, even on a secure 802.1X SSID. With 802.11r it is possible to roam without disruption during a voice or video call.
While client support of 802.11r is largely lacking in the laptop space, there is large support in the smartphone realm. Apple iOS devices have supported 11r since iOS 6 (http://support.apple.com/kb/HT5535). The recent Samsung smartphones, such as the Galaxy S4, S5, and Note 3, also support 11r.
Note: Some non-802.11r clients can react adversely when connected to an 11r WLAN. The current recommendation from Cisco is to have a separate WLAN for 802.11r clients.
802.11k is another amendment from the IEEE that helps to improve roaming. 802.11k provides a whole slew of information to the client, which allows the client to understand the RF environment and make an informed roaming decision. This information can include channel load and AP neighbor lists.
11r and 11k help, however, that does not mean the infrastructure is irrelevant in the roaming picture. With the help of a model train, we did some testing to figure out just how much impact the infrastructure could have. We compared Cisco to one of our competitors, whom we will call Vendor A.
This video summarizes the results and shows the train in action, or continue reading for more details: Read More »
What do WebEx QoS and Phone Troubleshooting have in Common?
If you read my previous blog then you’ll already know that the answer is Medianet. In Part 1 of this 2 Part blog series I discussed the new reverse Metadata capability, provided by a Cisco network, that allows an Enterprise to enable granular QoS marking for all the different media streams that make up a WebEx meeting. In this 2nd instalment, we’re going to take a look at how we can extend Medianet’s Mediatrace capability to Cisco’s 79XX, 89XX and 99XX IP Phone portfolio.
The other recent innovation for Medianet is Prime Collaboration’s ability to now invoke a Mediatrace for a number of IP Phones models that don’t support the MSI (Media Services Interface). As these devices cannot originate Metadata, it has been previously impossible start a Mediatrace through end point selection for telephones in Prime Collaboration. It is now possible, reactively and proactively, to troubleshoot voice quality issues on 79XX, 89XX and 99XX devices, using the same combination of Medianet and Prime Collaboration tools that have previously only been applicable to personal and room based video systems. Take a look at one of my previous blogs, “Medianet in Action”, for some additional background material on video troubleshooting. The demonstration below shows how to start a Mediatrace for a pair of phones.
What do WebEx QoS and Phone Troubleshooting have in Common?
The answer is Medianet, which in conjunction with a Cisco network can provide an innovative solution for two very different real life problems. In Part 1 of this 2 Part blog we’re going to discuss how customers can use Medianet Metadata to provide a robust QoS mechanism for the WebEx cloud service within their Enterprise Networks. Keep an eye out for Part 2 where we’re going to take a look at how we can extend Medianet’s Mediatrace capability to Cisco’s 79XX, 89XX and 99XX IP Phone portfolio. I’ll also point out the benefits for each of these completely different Medianet use cases.
WebEx is a SaaS Conferencing service providing web based data, audio and video conferencing for millions of users. As it’s a cloud service, it’s inherently secure and in a lot of use cases it will tunnel all its media streams within HTTPS. That’s great for secure transport, but it’s resultantly challenging to map the constituent parts of the WebEx application into a granular Enterprise QoS policy. Why would we want to do that anyway? Isn’t it good enough to mark all the WebEx traffic the same? As the saying goes, there is a method to our madness.The tunnelled WebEx traffic contains control packets, data-sharing traffic and possibly VoIP, which are relatively low bandwidth media streams. On the flip side any tunnelled video traffic will likely be bandwidth hungry by nature. The challenge we want to circumvent is how to ensure the WebEx video traffic does not “swamp” the other types of meeting traffic. Ultimately, we want to allow end users to enable the video service they have paid for, without the risk of video having a negative impact on the overall quality of the online conference. We do everything with the end user in mind to make sure you have the best possible experience.
For those of you that don’t know, a WebEx client can generate Medianet Metadata. In simple terms, Metadata is a way for a Cisco application to announce itself to a Cisco network. In the case of WebEx, different Metadata packets are transmitted onto the network, uniquely identifying all the component media streams (including video) that comprise a WebEx conference. This allows a Cisco network to useWebEx Metadata to differentiate between any WebEx traffic types, even when securely tunnelled over a HTTPS connection. The figure below provides an illustration of the different Metadata packets that will be generated for different types of WebEx traffic.
Figure 1 – Identifying Different Flows using Metadata