Tuesday 20 November 2012

Cisco acquires Meraki

Cisco's acquisition of Meraki is an interesting prospect for customers, partners and competitors.  Meraki are an unknown quantity to many, so I thought I would share my opinion on what this means to the WLAN industry.

As a WLAN engineer that has been working with Cisco for 10 years I'm pretty happy about it.  I have been looking at Meraki for a while and picked up one of their AP's a few weeks ago.  If you read my blog about BYOD you'll see I have a lot of love for the Meraki product.

Meraki have taken the controller to the cloud, they look after it.  You choose upgrade windows and never have to pay for resiliency, new hardware, software upgrades or power bills.  You can also buy switches and security gateways for the full feature set.  All are cloud managed through a clean and simple web GUI.  The main selling points of the solution are as follows:
  • Plug and play access points (DHCP to Internet is all you need)
  • Switch and security gateway appliances for additional features
  • Feature-rich WLAN services - URL filtering, firewall, VPN
  • Slick cloud-based management GUI
  • BYOD out of the box - including the illusive trusted CA (see Building BYOD blog part 2)
  • Free MDM for iPhone, Android, Windows, OS X
  • Layer 2-7 stats and reporting

Cisco's ageing WLC-centric infrastructure has been struggling to compete in the SMB channel for a while now.   For the last few years companies like Aruba, Aerohive and Ruckus have been turning heads.  However, they will now lose many of their (compelling) arguments against Cisco's previously appliance-heavy infrastructure.

The $1.2bn price tag will be questioned, but I feel that this acquisition is vital to Cisco's strong position in the WLAN industry - and worth the investment.  By acquiring Meraki, Cisco will be able to wade back into the SMB market.  I can only see them expanding their customer base.

Cisco partners will be saying "Awesome, now we can offer BYOD and MDM at low cost".
Cisco competitors will be saying "Damn... We had them on the ropes...".
Meraki partners may be saying "Meh… Now we're going to lose out to Cisco Gold partners"

What does it mean for Meraki products and customers?

Anyone who has recently bought into the Meraki revolution might be worrying about what this acquisition means to them.  If it is anything like the Airespace acquisition it will go like this:
  • Cisco will rebadge the Meraki products and maintain current pricing.
  • Cisco will honour all current support contracts.  Support will be migrated to Cisco TAC.
  • Cisco will phase out the Meraki hardware for Cisco hardware, then offer migration deals.

We're all trying to envisage what Cisco will attempt to do with Meraki.  They may leave them to operate in isolation.  As is stated by Meraki here http://www.meraki.com/company/cisco-acquisition-faq

I don't think cloud networking will extend into the Cisco product set quickly.  However, there is nothing to stop network appliances being offered with 'local' or 'cloud' firmware.  Much the same as autonomous or lightweight AP's today.  However, Cisco will need carefully manage how they offer these products  to customers.

The shift from where Cisco are now with their 'tin' approach to where Cisco could be with an 'IaaS' approach is huge.  This conversation goes way beyond my WLAN blog....

Final word... I'm fortunate enough to be a member of the Cisco Mobility PVT.  So I hope to be able to report back about the good things are going to emerge from Cisco in the near future.  Watch this space...

Mental note! Get CCIE before Meraki technology is added to the exam...

Thursday 15 November 2012

Building BYOD part 4 - Choosing the right vendor

A Little History… 

2005 - Aruba and Cisco hit the market with "captive portal" technology that is prevalent in hotspots today.  Aruba's product was better.

2009 - iPhone arrives… Amigopod (soon to be acquired by Aruba) are the first company to market with a BYOD gateway with PKI integration, but it only supports iOS devices and requires SSID switching for client on-boarding.

2010 - Mobile Device Management solutions arrive offering alternative to WLAN vendor solutions for mobile devices.  Smooth profile delivery mechanisms. MobileIron, Airwatch, Good, Zenprise.

2011 - Cisco release Identity Services Engine, but are still behind Amigopod on development.  Other vendors introduce MDM through partnerships.  PPSK was been introduced as a better alternative to web login by Aerohive and Ruckus.

In 2009 vendors succumbed to the fact that there is a world beyond Windows.  The behaviour of mobile devices also made WLAN vendors realise they needed to find an alternative to web login… A raft of new MDM vendors also emerged.  The recent challenge has been to develop web-login portals that integrate with MDM agents to support multiple device types, operating systems and user databases.  The goal for all vendors it to be able to push EAP-TLS profiles and certificates to a wide range of OS - Windows, OS X, iOS, Android, Windows phone, etc.  But also to be able to support traditional web-login or PPSK solution for non-compliant devices and users.

BYOD portal technology is a logical progression from the basic web-login solutions of 2005.  The ideal BYOD portal product offers the following:
  • Single point of entry for all users
  • Highly customisable walled garden website
  • Traditional web-login for visitors
  • BYOD on-boarding options for employees
  • Client agents for profile delivery
  • Support for multiple OS
One thing I feel that is lacking in most vendor offerings is the ability to customise the portal for corporate branding and content delivery.  This is an important part of corporate identity that vendors haven't made enough effort to accommodate.  This may be explained by the aggressive recent development of BYOD.  In reality, vendors have struggled to develop their own BYOD solutions.  Several have partnered with BYOD solution vendors, or simply referred customers who want BYOD to MDM solutions.  

BYOD Vendor Options

Product maturity is the big question.  Not just in terms of the breadth of device OS support, but also through software development.  As you can see from the timeline, Aruba have a mature product with PKI integration.  Cisco have invested heavily in the ISE product and only in recent releases has the feature set and functionality become comparable to Amigopod.  

Both Aruba and Cisco offer BYOD focused security appliances with a multi-purpose captive portal with BYOD integration for IOS and Android.  Aerohive have also recently developed their own portal that offers MDM integration via the JAMF solution for Apple devices.  Meraki have stormed into the BYOD market with a multi-OS BYOD solution that offers an MDM/client app covering all major platforms (Win, OS X, iOS, Android).  This cloud-based "free MDM" approach is so easy to setup in comparison to all other vendors that the cost-savings are huge, not just in MDM costs.  My concern here is that traditionally WLAN vendors aren't focused on MDM.  Will they stay on top of development around bugs, security alerts, OS updates, etc?  Will their support teams be on-par with an MDM vendor?

A note on PPSK - Both Aerohive and Ruckus offer PPSK which is a big improvement over web-login.  This is going to be a great solution for most companies.  Though if tight security is a concern, I would be interested to know if they are able to tie a user to the client session for litigation against Internet misuse.

In Summary

For the last few years Aruba Amigopod and MDM have been the leading BYOD options.  There has also been an IOS exclusivity in the WLAN vendor space until recently.  Cisco have caught up somewhat with Aruba and other vendors are offering well-rounded solutions with less painful deployments. 

Finding the right solution for an organisation will be about taking all the info on board from this and previous blogs, putting it all together and cross referencing agains the vendor solutions.  Not an easy task... 

I do think that SME customers will quickly move away from vendors with appliance-heavy architecture.  Cisco and Aruba should be worried about innovative and agile vendors like Aerohive, Meraki and Ruckus coming in cheaper and winning customers.

Wednesday 3 October 2012

Building BYOD pt 3 - User Experience & Productivity

In part 1 we looked at BYOD requirements, then part 2 addressed the security of BYOD service as a whole.  In this blog I'm going to cover User Experience & Productivity.

User experience is generally defined by 'BYOD groups'.  Group membership will be dictated by both the user role and device support.  Users are generally split into two parent BYOD groups; domain users and non-domain users.

Domain users - Domain users should get a smooth process that automates the delivery of the WLAN profile.  This may require agreement to T&Cs regarding use and disk encryption, strong password, remote-wipe, etc.

Non-domain users - Non-domain users will accept that they need to be authorised by a sponsor before being on-boarded.  So they will wait for that to be done, or if arriving for an event would hope it was done in advance by the organiser.  In most security conscious businesses the trade-off is to get some contact details for the user.  Ideally their credentials are sent to them via SMS, guaranteeing a valid contact number.  Alternatively, and more commonly the credentials are emailed or printed.  An important note for non-domain users is that their account should be time-limited.

Perfect BYOD
  • Use a captive portal landing page for new users.
  • Use device profiling to define the user's device.
  • Use Active Directory to validate domain users. 
  • Use an MDM client-side app to auto-configure profiles and manage device security.
  • Use 'non-domain' Certificate Services for WLAN security.
  • Assign employees to VLANs by AD security groups.
  • Use a single SSID and Change of Authorisation (CoA) to apply VLAN ID.
  • Apply QoS using WMM, DSCP and L7 application awareness.

The above approach is a 'perfect world' scenario.  However, not many WLAN vendors offer ALL of this and you will need to review both your WLAN and MDM vendor before finding the right solution and price for your chosen BYOD model.  Pen-testing is also likely to be a prerequisite for selection in high-security organisations.

As I'm writing this I have realised that I should really write another blog on the different WLAN vendor approaches, look out for BYOD blog part.... 4!


"BYOD improves productivity" we see this mantra everywhere in Wi-Fi.  However, BYOD doesn't necessarily improve productivity.  Many organisations have introduced better workflows through mobile apps and systems that work just fine over 3G/4G.  

The question sometimes becomes "How will BYOD improve upon existing 3G/4G productivity?".  Well, BYOD improves productivity over 3G/4G in these scenarios:
  • My signal is terrible, there isn't enough throughput in areas where signal actually exists.
  • Most of our BYOD users have Wi-Fi only.
  • I want to use voice or video apps, I have a local VoIP gateway that supports SIP clients.
  • I want to use Bonjour services - AppleTV in meeting rooms.
  • I want my trusted WLAN devices to access local file and print servers.
Many organisations see BYOD as a logical next step up from guest services, and often use the same DMZ for BYOD - pushing traffic directly to the Internet.  In my opinion, BYOD must offer LAN access to maximise productivity and truly differentiate from 3G/4G.  3 out of the 4 scenarios require LAN access.

The key takeaway here is that access to local networks is a game changer.  For employees, having access to printing, file shares and media services is where BYOD makes headlines.  So, it's important to get the blend of usability and security right… remember, execs want Apple TV in the boardroom - just make it happen.

Here are a few tips for a productive BYOD design:
  • Consider traffic flows.
  • Decentralise WLAN architecture for trusted devices.
  • Don't over-engineer device security.
  • Develop tablet optimised corporate apps.
  • Develop a secure cloud service for mobile focused apps.

The Social Media Meltdown

Finally, the elephant in the corner…. Social media.  Is it a threat to productivity?  I hear mixed opinions on this… 

Access to social media via the corporate network depends on the culture of the business, and many businesses encourage the use of Twitter and Facebook.  Though I do think it's fair to say that many employees will see BYOD as an avenue to their 'personal' digital lifestyle.  This could result in the loss of a fair few hours of productivity if staff begin spending an inordinate amount of time in the toilet... Which is why I have patented the 'Simkins Faraday Cubicle' in 65 countries :)

Joking aside, using a L7 aware security appliance and profiling you could create profiles based on security groups for approved Twitter and Facebook users.  Then limit standard users to say 30 minutes per day.  But is that really necessary?

Thanks for reading!  Next blog will cover the WLAN and MDM vendor options for BYOD.

Friday 20 July 2012

Building BYOD pt 2 - Secure Design

After picking up the business requirements it's time to baseline the BYOD security requirement.  Ask the security decision maker these questions:

  • Will internal systems be accessible via BYOD?
  • Can the endpoints be trusted?
  • Is data loss prevention of significant importance? 
  • Is legislation against criminal activity a concern?
  • Do you have a DMZ or content filtering capability?

The answers to these questions will indicate the need for the design to include perimeter network security, mobile device management, data loss prevention and logging.

There is clearly a spectrum of options here.   At one end you have a self-served 'home user experience' using basic PSK security for Internet-only access using a DSL router, with no consideration to endpoint security or criminal Internet activity.  At the other end you have  account request, authorisation and revocation processes, 802.1X, endpoint security, firewall, web filtering, monitoring, alerting, administrator audits, session logging, etc..

Each organisation is different.  So you'll need to take the customer requirements, then cross-examine them against what is considered to be acceptable operational risk with regards to security.  Let's examine the likely baseline for security in a 'secure enterprise' where you expect to support P2P and LAN traffic.

Step 1 - Wi-Fi Security

For a secure design we're looking at WPA2 with AES encryption and 802.1X authentication.  Choosing the right EAP protocol is important, so here is a simple comparison the two most popular inner EAP protocols - MS-CHAP-V2 and TLS.

User Experience
The user enters their Windows username and password at first connection.  This may need to change regularly, which is annoying for users.
No.  A MITM attack using fake AP and RADIUS server can result in lost user credentials.
Certificate is installed on the device and can be valid for 1, 2 or even 5 years.  Better user experience.
Yes.  Client and server certs from the same PKI provide a trust chain.  The clients cert(s) are not usable by MITM attackers.

The point I'm making is that PEAP (MS-CHAP-V2) is the easy way to enable BYOD but it isn't fully secure and can be annoying for the end user.  Many organisations are using this method for BYOD without being aware of the MITM attack risk.

The bottom line is that to be bulletproof certificate chains need to be trusted between the client and server, and private keys should be non-exportable.  That said, most security conscious organisations baulk at the idea of putting private PKI certs onto BYOD clients.  If this is the case you may want to look at a third-party CA.

Step 2 - Device Security

Specific concerns over BYOD are around disk encryption, OS security, private data and certificate/credential storage, malware, viruses, hack tools, etc.  Therefore, consider identifying a BYOD approved set of devices and operating systems that meet your requirements.  If device security is important then you'll need a Mobile Device Management platform to manage the device and applications.  Good For Enterprise is an example of a sandboxed Exchange application that encrypts mail, contacts and calendar.

There are lots of variables in terms of devices and operating systems.  Supporting multi-OS can be complex and many organisations choose to simplify this by drawing the line at Apple iOS.  Which supports SCEP, has less weaknesses and is easier to integrate with business.

Of course this is a fairly exclusive approach and the customer may want to consider building some differentiated BYOD services.  Perhaps offering a limited service to users who don't have a supported device or prefer not to sign up to MDM.

Step 3 - Network Security

Your Wi-Fi client VLANs will require different LAN firewall policies, so consider using CoA (Change of Authorisation) as a way of segmenting clients to offer diverse services.  CoA requires an element of client profiling or posture validation, allowing clients to be assigned to a specific VLAN.  CoA also benefits from allowing a single SSID to host multiple services, which avoids the 802.11 overheads of multiple SSIDs in the air.

You'll also need to consider where you allow these untrusted client VLANs to exist, and how you'll firewall their network access.  This will usually be an 'edge versus DMZ' policing decision (decentralised or centralised firewall policy).  Both options are viable given the right WLAN vendor and LAN design, and there are wider discussions to be had on this topic.

Finally, network security isn't complete without logging and audit trails.  If you offer a BYOD or guest service you really ought to consider the impact of criminal activity.  The important things to track are client usernames against Internet activity - logging from two platforms.  A service like Splunk is ideal to gather syslogs, traps, log files, etc.  

The message for part 2 of Building BYOD…

To be bulletproof you'll need a PKI for certificate delivery to your trusted devices.  You can also consider using posture assessment and CoA for a layered BYOD security policy that offers differentiated services to lesser trusted (or capable) devices.

When discussing BYOD, make sure you think about the wider picture, it's not just a decision over which MDM platform you prefer.  Consider every layer of security - the device, applications, wired and wireless infrastructure and Internet service.

That's it for Secure Design.  In the final part we'll move onto User Experience and Productivity.

Wednesday 20 June 2012

Building BYOD pt 1 - Requirements

We've used hotspot style Wi-Fi 'guest' services for years, but they aren't exactly slick for the business or the end user.  It also means that the device will be outside of the corporate firewall.  This type of service will always have it's place, however, you're going to put untrusted devices directly in touch with business systems at some point.

With that in mind, the decision to move to BYOD will be significant for any organisation.  Taking business systems from Windows to a multi-OS mobile environment is a massive challenge in terms of security, user experience, infrastructure readiness and support.  

This blog will be delivered in a few parts.  The idea to is to highlight the design decisions that will help build the right BYOD service for your organisation.

Step 1 - Gather the requirements, here are some examples;

  • Connecting & Profiling Users - We need to...
    • provide a quick and simple on-boarding process.
    • offer self-registration for staff, but not all staff.
    • offer long-term accounts for employees and contractors but not visitors. 
    • pre-authorise third-party users.
    • support any device type, but restrict devices that can't be trusted. 
    • deliver WLAN profiles to devices automatically.
    • use domain credentials to authorise our employees.
    • support VPN for teleworkers.

  • User Authorisation & Auditing  - We need to...
    • use AD security groups to authorise employees.
    • use certificates, but not our internal Root CA.
    • know who has authorised our third-party users.
    • prevent visitor accounts being created using dummy names.
    • be able to audit user sessions by IP address for 12 months.

  • Filtering & Prioritisation - We need to...
    • allow social media and personal mail
    • filter traffic without configuring a proxy server on the device.
    • enable multicast services for our business media services.
    • allow Facetime and Skype but not Internet TV.
    • enable VoWLAN for our SIP solution.
    • allocate better QoS and bandwidth profiles to our priority users. 
    • use Apple TV in meeting rooms and the conference centre.

  • Infrastructure & Endpoint Security  -  We need to... 
    • make sure the execs get guaranteed bandwidth for video streaming.
    • ensure our Internet uplink isn't saturated at peak times.
    • de-prioritise third-party user bandwidth.
    • perform antivirus and OS checks.
    • offer the ability to install AV software and upgrades.
    • block P2P connections unless the device passes posture validation.
    • use a DMZ for all of our BYOD devices

There are some design decisions that add significant cost and will need to be validated by strategy and backed by funding.  It may also dictate which vendor solution you choose.

Some requirements will conflict or be unachievable within budgets.  So be sure to set expectations on which requirements are more expensive to deliver than others.  Media based services will almost always add complexity and cost to the design.

A great example of an awkward media solution is Apple TV - execs want this in meeting rooms.  You'll need to support the Bonjour protocol which is peer-to-peer multicast via a L3 gateway.  Not all vendors can support this, and it can be a challenge for security and infrastructure design.

In the current environment some devices are more enterprise ready than others.  A wide variety of users and devices will mean different levels of authorisation and policing.   So the BYOD strategy may need to include several service types which are dictated by the security capabilities of the device (or the MDM vendor).  Consider that creating a 'preferred device' service for Apple iOS devices will potentially cause discontent with the owners of other devices who can't subscribe to the same level of service.

The message for part 1 of Building BYOD…
Spend some time gathering all of the requirements.  Understand what the possibilities are and which services and device types you want to support.

Part 2 - Secure Design

Thursday 19 April 2012

Do you need 802.11ac?

802.11ac Intro

It's a new standard from the Wi-Fi Alliance, requiring new radio hardware - new access points, new client chipsets.  802.11ac products are faster and more reliable than the old 802.11a/g/n products.  

802.11ac will remain backwards compatible with 802.11a/n devices. So your new 802.11ac clients will be able to use any current 802.11a/n wireless networks. 

The two main benefits for enterprise are speed and reliability:

  • 5GHz only and operates in cleaner airspace.
  • New modulation typically supporting up to 200 Mbps*.

* Common use with single-antenna, single-stream mobile devices in a 40MHz enterprise environment.

Real Throughput

802.11ac will offer higher bandwidth and more spatial streams. Access points will support up to 8 spatial streams (double what 802.11n can achieve) and 256-QAM modulation (four times .11n).  So the theoretical maximum goes up from 600Mbps to nearly 7Gbps.

Before you get too excited, the theoretical maximums aren't realistic.  These headline 8-channel/8-spatial stream figures aren't going to be supported in the enterprise.  Here's why:

  • Spectrum is limited, there isn't enough frequency to allow radios to bond 8 channels (160MHz) in a multi-AP environment.  Designing for 2 channel bonding (40MHz) is the de-facto.
  • Devices don't support 8 spatial streams as that would need 8 antennas (read on...).

Further reading on Wikipedia 802.11ac

802.11ac Deployment

AP Placement
802.11ac range is no different to 802.11an so you are likely to swap-out your 802.11n models for 802.11ac when the time is right, or simply add an 802.11ac module.  

You'll need Gigabit switches to support the speeds achieved by 802.11ac access points.  The access points also draw more power to run the additional radios.  So your access switches will ideally support PoE+ or 802.11at with power up to 20Watts per port. However, the AP can reduce it's capability to run on standard PoE at 15.4Watts.


Using MIMO you can add more radio-chains or 'spatial streams' to an access point.  This effectively multiplies maximum bandwidth. You'll see the MIMO and spatial stream support written as axb:c where a = transmit antenna, b = receive antenna and c = spatial streams.  802.11n access points are labelled as 2x2:2, 2x3:2, 3x3:3, 3x4:3, 4x4:4 (or simply 2SS, 3SS, 4SS).  The headline 802.11n figure of 600Mbps comes from a 4SS configuration where both the access point and client support 4SS and achieve 4 x 150Mbps.  In reality the majority of 802.11 clients are 1SS phones, tablets and netbooks. Laptops offer 2SS and 3SS, there are no 4SS clients! 
The reason there are no 4SS 802.11n devices out there is to do with throughput requirements, power requirements and antenna spacing.

802.11ac takes the MIMO theory applied to 802.11n and grows it up to 8SS.  We can assume 8SS clients will be scarce for the same reasons there are no 4SS clients.  So to make use of the extra radio streams the vendors are going to have to develop ways of maximising the AP performance.

I am interested to see how vendors will approach the MU-MIMO capability of 802.11ac Wave 2.  The idea here is that your bandwidth can be split between clients, which will be a first for Wi-Fi.  I like to think of this as the wireless hub becoming more like a switch.

Why Invest in 802.11ac?

If your 802.11an network is meeting expectations then you may not NEED to adopt 802.11ac infrastructure.  
Reasons why organisations would consider migrating to 802.11ac:
  • The access points cost the same as previous 802.11n models
  • They have high bandwidth requirements for LAN based services.
  • They want to future proof their WLAN. 
  • They have Gigabit LAN infrastructure.
  • They have PoE+ or 802.11at support on their switches.
  • They are migrating from legacy 802.11ag infrastructure.

Reasons why organisations may prefer to put 802.11ac on the back-burner:
  • They have 802.11n infrastructure which meets their current requirements.
  • They don't have Gigabit LAN infrastructure.
  • The cost of hardware refresh is prohibitive.

Final Thoughts

MU-MIMO will speed up the network in general and in busy environments will bring RF utilisation levels down - because devices spend less time transmitting and receiving.  So it's all good and hopefully those 802.11ac clients will proliferate the environment to achieve that goal.

Since Cisco decided to bring out the 3700 AP at the same price as the 3600 AP the decision around 802.11ac adoption is simple for top-end customers.  Lower-end customers may not want to deploy it based on the cost.  However, current 802.11n clients will achieve throughput speeds of over 20Mbps at the cell edge (16-QAM at around -71dBm).  So realistically, the 802.11n infrastructure will support 99% of customer needs.

Thanks for reading and feel free comment!


Some further info on 802.11ac:

  • 802.11 foundations and 802.11ac review by WildPackets. 
  • Network World article on 802.11ac by GT Hill from Ruckus.

Wednesday 21 March 2012

Wi-Fi Location Services for Healthcare

It's fairly common for customers to be unaware of what can be achieved with Wi-Fi location services.  I've designed and deployed several large-scale Cisco / AeroScout solutions for UK healthcare in the last few years.  So I thought I would elaborate on the technology behind these types of solution.

I refer to this technology as 'Wi-Fi location services' although you will also hear it described as Wireless Tracking, RF Identification (RFID), Real Time Location Services (RTLS), Asset Management and Context-Aware Services.

There are several vendors in this space, so I apologise if this blog doesn't cover all the options.  However I've researched this field in depth and am confident that I'm covering the front-runners (Ekahau might like to argue that point).

Architecture Overview

There are three general layers to be considered for the deployment of your Wi-Fi location service.
  • Devices - RFID tags, Wi-Fi clients.
  • Network Infrastructure - Access points, WLAN controllers, chokepoints, positioning engines and management platform.
  • Asset Management and Context-Aware Services - Clever server applications....

The diagram below is a good representation of the interaction between components.

Radio Frequency Identification (RFID) Technology

In simple terms RFID is like a barcode whereby a unique ID is used to define an object.  However, RFID is effectively two technologies and "Which type of RFID is right for me?" is usually the question I'm asked.

There are two types of RFID, 'Active' RFID is different to 'Passive' RFID:
  • Active RFID uses larger more expensive tags which transmit 802.11 beacons over several metres and make use of the WLAN infrastructure.  Devices are located by triangulation, think of Google maps with 3G phones being located using signal readings from several nearby masts.  You can get accuracy to a couple of metres if you design the WLAN correctly.  Active RFID tags require 802.11 transmitters and a battery, so at smallest they are the size of a matchbox or  a 10mm thick credit card.  Depending on the tag configuration the battery will last between 3 and 4 years if the tag is set to be fairly idle whilst out-of-motion (yes they also have motion sensors).   
  • Passive RFID uses low cost tags which are detected using short-range, low-frequency scanners.   Passive tags are battery-free and attached to the object like a sticker, they are flat and inconspicuous.  Note that passive RFID doesn't work on a WLAN, it requires it's own 'reader' infrastructure.  Think of this technology like security tags in clothes stores using security scanners in the doorway.  You can get accuracy to the nearest reader point or to an area you have define by reader 'gateways'.
Active RFID makes most sense for organisations who want an infrastructure that offers multiple services, e.g. a location system with Wi-Fi data and/or voice.  Passive RFID usually comes as a complimentary solution for objects that pass a given point, such as bed-space or a storage area.  For healthcare I found that the short-range nature of passive RFID didn't meet the requirements to track objects to within a few metres anywhere in the hospital in a cost-effective manner.  To do this with passive readers would mean readers on every doorway - too expensive.  Passive RFID is more in competition with barcode technology for things like patient and blood bag tracking (think NFC).

Network Infrastructure

So let's assume you have chosen Wi-Fi for your location tracking solution, how do you begin to make this location data work for you?
  • Tracking the position of a Wi-Fi device requires a location-ready WLAN and a positioning engine with some scaled floor plan images.
  • The WLAN access points then need to report the RSSI of the beacons received from the 802.11 device to the positioning engine.
  • You need to calibrate the positioning engine through fingerprinting exercises to get those extra few metres of accuracy.
  • The positioning engine uses the client RSSI data from a minimum of 3 surrounding access points to produce the coordinates of the object.  Which can then be displayed on the map by the management server.  See below for an example of how the triangulation works.

Key Fact! You don't need RFID technology for RTLS.  All Wi-Fi adaptors can be tracked by their radio MAC address.

Key Fact! The positioning engine isn't responsible for accuracy the site surveyor is!  High accuracy is achieved through careful WLAN design and implementation.  Map segmentation, site survey methodology, scaling of maps, access points placement, map calibration of both frequencies.  If you don't get all of this right you won't get the high accuracy you are looking for.

Asset Management

The positioning engines usually have an API which allows the Asset Management solution to draw information from the system.  The Wi-Fi MAC address of the client is used as the unique ID for the asset database.  Essentially Asset Management is achieved through the addition of meaningful information to the object, for example:
  • MAC: 'aa:bb:cc:dd:ee:ff'
  • Serial: 'S247462'
  • Tag type: 'T2000'
  • Asset ID: '0012346'
  • Category: 'Wheelchair'
  • Sub-category: 'Type 4 Child Buggy'
  • Department: 'Paediatric'
  • Asset Description: 'Sunshine buggy aged 6-10'
Before you add assets you must configure the system with zones, categories, departments and users.  This will enable asset logic.

The asset logic depends upon the features and functionality of the asset management solution. Within AeroScout MobileView you have things like location of devices by name, category, description, current location and status.  You can also generate events like zone entry/exit, status change, par-level by area, proximity, dwell, out-of-sight and low battery.  These events can in turn trigger alerts such as system notifications and messaging.  'Context-awareness' is the term used to describe the ability to be aware of the assets behaviour and state.  Some examples:

  • Location
  • Status
  • Temperature/humidity
  • Motion
  • Directional motion
The screenshot below shows context-awareness using an RFID tag with MobileView.

The Cisco/AeroScout solution is impressive and has the ability to offer huge benefits to healthcare.  I've written business case justifications and these type of systems can pay for themselves within a couple of years with even the most basic deployment model.  Primarily it saves staff search time, it allows assets to be maintained on time and avoids loan costs or fines for missing maintenance targets. 

Context-Aware-Services (CAS)

Some asset management solutions provide a basic service around the information they gather.  However if you want an advanced business system that is tailored to your requirements you will usually need to find a third-party vendor who integrates with the API of the asset management solution.

One great example I came across was Nervecentre, which is able to integrate the location of assets with portering systems, nurse call, bleep systems, etc.  This is mostly achieved through CUCM, whereby the Cisco 7925 or smartphone running Cisco Mobile has further asset info.  Using this approach the user's phone becomes their location tracker and can also be used for process management apps.

The following scenario is for a 'porter call' system using a voice and location capable WLAN with Contect-Aware Services.

A nurse raises a porter request for a Sunshine buggy from an app on her smartphone.  The system will locate the closest available sunshine buggy to the nurse and send the nearest 5 porters to the buggy a smartphone notification for a 'porter call', when a porter accepts the job he can use the app to track down the buggy.  Once he confirms he has picked up the buggy he will be given the location and phone number of the requesting nurse.  If he likes he can initiate a call to the nurse to make sure he has the right item and where it should be delivered.

The cost savings that the above scenario delivers are difficult to quantify.  There are certainly time savings for staff.  More importantly, there are cases where 'clinical incidents' occur because equipment can't be found in a timely manner - they incur large fines that could be avoided.  You also need to consider the happiness of staff and patients who can become demoralised when vital pieces of equipment can't be located for extended periods of time.  In some cases staff begin 'hoarding' equipment to ensure they can use it when they need it, this is costly behaviour that we've proven can be reversed.

In Summary

The scenario I described above is achievable and is very close to production in a leading UK hospital I have designed for.  The technology gap is currently the Workforce Management applications that integrate the   Context-Aware-Services with things like porter systems, patient systems, nursing systems and VoIP telephony systems.  There is a huge demand for mobile applications in healthcare that improve efficiency.  Nervecentre are one of the early adopters in the UK for this area and I wish them well as they are a great company.

My final thought here is that some customers will be put off by the technical complexity of the solution and the fact that it isn't cheap.  But I have evidence that the cost-benefits far outstrip the TCO... so why not invest in a futuristic and efficient 'context-aware' hospital?

Sorry! Final, final thought for customers out there... Don't try and save money on the site survey it's the most important part of the design.  Find a professional outfit with experienced engineers and expect them to want to perform their own site surveys.  This has bitten many customers before!

Wednesday 14 March 2012

Hotspot 2.0

First generation Wi-Fi hotspots haven't been popular.  They are generally used in an emergency only.  Users dont want to make credit card payments to multiple providers as they move around.  The Pay-As-You-Go billing model never matched up with 3G which uses Mobile Operator contracts to make payment, and roaming easy.  With the introduction of 4G (LTE) offering Wi-Fi speeds the Mobile Operators had pushed PAYG Wi-Fi into a corner.

In addition to the introduction of LTE, many Mobile Operators are looking to provide 'small cell' 4G which effectively works like a Wi-Fi access point. It's an OFDM radio offering data connectivity to the Evolved Packet Core.  These "pico cell" access points are being installed to high streets and they have the benefit that interference is unlikely as each installation must be registered with the RF regulator.

Consumers are much more likely to add a 4G package to their contract than use PAYG Wi-Fi.  This change in consumer behaviour means that Wi-FI will be used where there is no mobile coverage.  Or where the user density was too great for the cellular mast to meet demand.

So, lets talk about Hotspot 2.0

What is Hotspot 2.0?
Also known as Wi-Fi Certified Passpoint, Hotspot 2.0 is a new approach to public access Wi-Fi.  The idea is for mobile devices to automatically join a Wi-Fi subscriber service whenever the user enters a Hotspot 2.0 area.  The intention is to provide better bandwidth and services-on-demand to end-users, whilst also alleviating mobile carrier infrastructure of traffic overheads.

How will it work?
Hotspot 2.0 is based on the IEEE 802.11u standard.  Which is a new set of protocols to enable cellular-like roaming.  If your device supports 802.11u and you are subscribed to a Hotspot 2.0 service you will automatically connect and roam.

Where will I get it?
I would expect early adopters will be the current Wireless ISP's (BT Openzone, the Cloud, etc) and mobile carriers (T-Mobile, Vodafone, etc).  There is already a significant footprint for WISP services in event venues, hospitality, etc.  So for example, if I am a T-Mobile subscriber and they have a partnership with BT Openzone my handset will automatically join BT Openzone HS2 locations.  The consumer contracts are held by the mobile carrier, so I would assume that the data offload would be cross charged to T-Mobile.

When will it arrive?
The word on the street is of late 2012 for Wi-Fi Alliance ratification and device support and early 2013 for usable services.
  There is certainly a demand from Wi-Fi owners (who will generate income) and end-users (who get better bandwidth and services).

How is it setup?
It's a bit too early to tell, but I would speculate that the Wi-Fi Internet Service Providers (WISP) will need a Hotspot 2.0 'integrator' to audit the WLAN for readiness.  Once everyone is happy that the WLAN meets minimum standards the integrator will configure the WLAN edge infrastructure for a single service which uses cloud-based AAA to authorise the client.  The best thing about 802.11u is that a single SSID is broadcast and carries information for multiple subscription services, so the airspace remains clean.  The client devices will be authorised using 802.1X with EAP (TLS, TTLS or SIM).  This is likely to need an app on the client side to act as a dot1x supplicant.  A key feature within 802.11u is the ability to pre-associate and test Internet availability.  This should avoid 'stranded clients' when faults exist.

Hotspot 2.0 is great in concept, a secure 'turnkey' guest service is what customers want.  They also want to revert to a third party for the 'onboarding' of user accounts.  This solution also offers revenue for the Wi-Fi owner and a free service for visitors. 'Everyones a winner' as they say.... 

The technology champions have a big task ahead to get this kind of collaborative service into production.  However, there seems to be a strong appetite and early trials are under way.  So we can assume that there are few core organisations driving progress.  Hopefully we'll see a 'Hotspot 2.0 forum' of top-level SP's who offer roaming services, with international agreements for roaming abroad.

We can also assume that there will be a minimum requirements spec for WISPs to adhere to.  From an RF design perspective the goal will be to support high-density client counts.  However this will be difficult to define, for example a football stadium is vastly different to a hotel.  So from layer 1 up there will be challenges to ensure Hotspot 2.0 services meet expectations.

I'd be interested to see how Hotspot 2.0 competes with 4G/LTE for HD environments like outdoor sports and event venues?  If anyone has compared these two technologies please feel free to comment!

Marcus Burton from CWNP has also written a great blog on this topic

Friday 6 January 2012

Blog Background

A little background on the blog...

Who am I?
I'm a network architect / engineer / consultant from the UK. After writing a paper on WLAN security for my dissertation in 2003 my career in WLAN began.  I've progressed from autonomous access points to large-scale enterprise WLAN solutions.

Why am I blogging?
My intention is to feed into the already excellent Wi-Fi professionals blogging community that exists.  I will be sharing my experiences on WLAN design, deployment and support.  This will mostly be Cisco from a vendor perspective and hopefully some cool emerging technologies.

I hope you find the blog useful :)