Tuesday, 28 May 2013

Cisco ACS Policy Decisions Based on SSID Name

If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this.

In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note.


In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of the authentication handshake between the WLC and RADIUS server. One of the attributes that is sent forward to the RADIUS contains information about the source SSID. This attribute can be leveraged in the policy/decision process for authenticating users.

The attribute we are interested in is the DNIS (Dialed Number Identification Service). If we inspect this attribute in the ACS logs, we can see that the DNIS contains the MAC address of the RADIUS client (the WLC), together with the SSID name. Here is a screenshot that shows an authentication record for a client (the SSID is called "home-8021x")

Having the MAC address and SSID mixed together like this is not that useful, but by using a wildcard character to ignore the MAC address segment of the field, we can look at the SSID name. Luckily for us, the '*' character can be used to wildcard the leading part of the field (i.e. the MAC address) and allow us to just look at the SSID segment that we wish to use for our decision making process.

To be able to include the SSID in the decision making process, we have to create an End Station Filter within ACS that we can drop in to our policy rules. Here is the ACS page that we are interested in:

To match on our SSID of interest ("home-8021x"), we have to configure the end station filter as shown below (note the use of the "*" to act as a wildcard for the MAC address of RADIUS client):

Configuration Example

Once we have our End Station Filter in place, we can make some very granular decisions around authentication and authorisation of users trying to join the SSID. One area that this is very useful for is defining Service Policies. We can tie a service definition to a particular source SSID.

For reference, here is a screen-shot from the Cisco WLC GUI, showing the SSID name that we are using:

In the example below, we have a service policy called "Auth_Users_Select". You can see from the highlighted field that only authentication requests that are received from our sample SSID will hit this policy entry, as they must match the End Station Filter that contains the SSID information. 

If you are looking at your own copy of ACS whilst looking at the example shown above, you may not see all of the fields shown in this screen-shot. You may need to customize the fields shown by hitting the 'Customize' button shown at the bottom right of the screen-shot.


There are a couple of caveats to bear in mind:
  • SSID names are case sensitive. If you aren't hitting the policy line you expect, double check the case of the SSID name in your end station filter, compared to that on your WLC
  • Bear in mind that you are using a wild-card in the end station filter. If you have similar-named SSIDs, make sure you are not filtering out an important part of the SSID name inadvertently

Using End Station Filters in this way gives you a powerful way of making decisions around both authentication and authorization decisions.

Particularly when considering service policy decisions within ACS, being able to associate a service with a particular SSID is valuable - each service (e.g. Corporate-data, Corporate-voice etc.) may be authenticated by their own methods using this technique.

It's also worth noting that the same effect may be achieved using the WLAN-ID RADIUS attribute which provides the (numerical) index of the SSID (this is often suggested in other configuration examples I have seen). Although using the SSID index (via the WLAN-ID RADIUS attribute) is  a valid method, unless there has been a policy of assigning the same SSID to the same index on every WLC in the network, then this may not be a feasible approach.


The following documents provide some very valuable references, particularly if you are looking for the ACS 4.x version of this technique:

Wednesday, 22 May 2013

Aruba Tech Field Day - 802.11ac Product Announcement

Yesterday was the official launch of Aruba's journey in to the world of 802.11ac with their online (and real-world) Tech Field Day event where they presented their products and strategy for 11ac. I was a virtual participant, watching from over here in the UK. I have to say up-front that I do not currently supply or support Aruba products, but was very interested to hear more about their views on 802.11ac, together with their product offering. There was a lot of ground covered, but here a few (brief) notes of things that I found of particular interest for the sessions I managed to view.


There was a very informative and lengthy discussion around 802.11ac technology, together with the lessons learned by Aruba in their testing to date. I won't cover all points here, but the headlines that stuck in my mind were:

  • Smartphones/tablets will continue to be primarily single stream, capable of 80MHz bonded channel support
  • Although 11ac brings significant speed advances, it's not the speed itself which is the advantage, it's the increase in efficiency of the WLAN which is the big win. The faster a client can get on the WLAN, send its data, and then get off, the more clients will be able to use the WLAN (which remains a shared medium). This will help to meet the growing demand for WiFi capacity
  • The highest "headline" speeds of 802.11ac will only be achieved by clients being in close proximity to an AP. The more complex modulation and signal processing required means that excellent signal quality (e.g. through excellent SNR levels) to achieve the higher speeds.
  • Sticky clients continue to be an issue (see "ClientMatch" below), which can significantly impact the efficiency of a high density WLAN. As client speeds drop as they move away from an AP, causing a bottleneck for other clients on the same AP that they are "stuck" to.


A mentioned above, Aruba highlighted the ongoing issue with "sticky clients". These are clients that initially associate with an AP and then, despite 'better-choice' APs being available, remain associated as the client moves away from it. The issue with this is that the client speed will drop as the signal level falls, so that it is transmitting at lower speeds and impacting the efficiency of other clients using that same AP. If  clients can be made to prefer (and roam to) a more local AP, that will facilitate a better link speed and WLAN efficieincy, together with all of the efficiency gains that this will bring.

Aruba have a 'patented' technology, called ClientMatch which apparently looks at things from a client point of view and can 'steer' clients to better-choice APs. This technology can apparently work for all types of (legacy) client, but works best on more recent types of client that support newer 802.11 features such as 802.11k/v.

Reading between the lines, I think it analyses signal quality and signal levels from clients (at the AP end of things), together with 802.11k/v information to make some decisions about how things are looking from a client's point of view. Then, somehow (presumably through band steering and ignoring probes etc. from clients below pre-defined signal thresholds) it 'steers' them to a better AP.

We all know the types of information that are available to an AP from clients and the limited amounts of information that clients themselves will supply or act on. So, it's hard to see what there is here to actually patent. Unless there is some type of agent installed on the client (which there isn't in this case), what other unknown (patentable) mechanism could possibly be at work here? Apart from some 'secret sauce' decision making from the WLAN point of view, using known measurements and techniques, it's hard to understand what can be so unique about this. To be honest, without more information, I'm struggling with the concept of a unique offering here...

Access Points

Early on in the proceedings, Aruba presented their new 11ac access points: the AP220. There are two models, one with internal and one with external antennas. The units they had on display at the event were very impressive looking. They looked relatively light-weight (judging by the way they were being handled) and they appeared pretty sleek, as they have now dispensed with the usual air-vents to meet the 'wipe down' needs of the healthcare sector.

The AP has 2 Gigabit Ethernet ports to cater for the theoretical throughput speeds that can achieved by an AP with 2 radios (1 x 5GHz 11ac & and  1 x 2.4GHz 11n). I didn't quite get the information around the power requirements (i.e. 802.3af vs 802.3at), but looking at the datasheet, it looks like it can run in an 'Efficient Mode' with an 802.3af POE port and full funtionality mode with an 802.3at POE port. The detail on how the 2 gigabit Ethernet ports will be used (i.e. load balancing or a true trunk) was also unclear (this is still TBA on the datasheet I am looking at...).

The guys from Aruba pointed out that the AP uses less power than 'other solutions which require a plug in module' (i.e. Cisco). But, from what I see so far, both solutions require a full 3at POE port to operate with full functionality, so, I don't really see an advantage there..?

They also said that in their experience to date, you can pretty much do a one for one swap out of 11n APs for 11ac, as the general coverage patterns were broadly similar.


A Microsoft representative provided an excellent presentation around the Microsoft Lync product, which was fascinating for those of us (OK, maybe just me) who aren't that familiar with Lync. He described the challenges of trying to prioritise the different traffic flows that originate from a Lync client.  

The Lync client itself may be a number of form factors (laptop, tablet, phone), which may be the source of data, voice or video traffic. Trying to configure the QOS requirements for just those traffic types is a challenge, but throw in the fact that there is signalling traffic, some traffic is encrypted and some protocols do not use well known port ranges, and you have a whole heap of trouble.

He then went on to describe how Aruba have become a certified Microsoft Lync partner, allowing them to have access to an API that is made available from a Lync server. Having access to the API means that the Aruba wireless LAN controller can exchange information and drill down in to the detail of each Lync session, allowing decisions (such as QOS prioritisation) to be made as required. Apparently, Aruba and Microsoft have invested a lot of time in testing this exchange of information across the API, which allows better decisions to be made by the wireless network and provides much richer information to be made available on the wireless management platform.

This foray in to the Lync API was described as Aruba's move in the to brave new world of SDN: the application providing information for the network fabric to provision the resources required for an application. Exciting stuff!!! It certainly sounds like a good strategic move for both organisations. but I wonder if an open, standards-based API would be a better way to go long term (...imagine an unique API for every different application)? This (SDN) isn't an area of expertise for me, so please excuse any comments which seem mis-guided and please attribute them to my technical ignorance :)


Finally, I have to say thanks to Aruba, Microsoft and Gestalt IT for providing such open access to this event. The information presented was both valuable and fascinating. 

The event itself was very well organised (as you might expect from those Tech Field Day boys), with a great deal of both vendor material (from Aruba/Microsoft), together with the opportunity for some challenging questions from vendor-neutral folks as well. I think this open-forum approach really shows that Aruba is ready to listen, as well as very generously share, which really raises my opinion of them significantly (...not that it was low before, :) I've had no previous dealings with Aruba) .

I believe that Aruba are also going to make some of the material available from the presentations, in the form of videos and some of the slide decks - I particularly look forward to the recommended Lync QOS settings that were shared :)  I also strongly recommend that you review some of the great material that Aruba have made available about 802.11ac and their products.

This has been another very interesting and exciting chapter in the unfolding 802.11ac - thanks to Aruba, Microsoft & Gestalt IT.


Tuesday, 21 May 2013

Aerohive BR200-WP 3G/4G Backup Testing

This is just a quick note about some interesting things I found out about the Aerohive BR200-WP today when I was having a look at our demo kit for a possible customer solution. 

The BR200-WP is a great little branch router/switch/AP platform. It boasts a single AP radio (5GHz or 2.4GHz, 3x3:3!!!) and has 5 x 1Gbps switched Ethernet ports (one is the WAN uplink). If you throw-in in the fact that its cloud managed and has all of the usual powerful HiveOS features (VPN, firewall, AVC, airtime fairness...etc,. etc.), you've got a great branch-router platform. (Oh yes, I forgot to mention that it has 2 x POE ports too!)

But in addition to the mass of great features outlined above, the BR200-WP has one more trick up its sleeve: 3G/4G backup. The unit has a USB 2.0 port which can be used to attach a 3G/4G dongle to provide WAN backup in the event that the main WAN link should fail. This was the area I was interested in taking a look at in my testing.

You'll have to excuse my ignorance in the area of 3G/4G backup in this article. There are probably a few things in here which may be very obvious to most folks, but I hadn't really come across them before.

I connected my BR200-WP up to an ADSL connection and gave it a basic configuration (via HMOL). This gave me an SSID to attach to and some basic Internet connectivity via a test wireless client. I configured the interfaces to (hopefully) provide a resilient WAN link.

My first action (like most engineers) was to insert my existing 3G dongle in to the USB port of the BR200WP and see 'what would happen'. Unfortunately, not too much did happen. I got the standard WAN (ADSL) connection up and working, but when I failed it, the 3G backup didn't kick in - back to the drawing board (well, time to read the manual actually).

After checking the datasheet, I realised that not all 3G dongles are created equal. Only certain models of dongle are supported for use with the BR200-WP. Apparently, different dongles use different command sets, which makes universal support tricky. So, I got on to Amazon and bought myself an unliocked Huawei E220 3G dongle. There are a range of 3G and 4G dongles that are supported by the BR200-WP, but I'll leave you to check them out on the datasheet (as the range of supported dongles will no doubt extend over time).

Once I had my supported (E220) dongle, I switched my SIM card across to in to the E220 to try the 3G backup again. (Quick note: I didn't know you could switch SIMs around like this to put them in to a supported card. Prior to being told this, I spent a lonnnnnnng time looking at cell phone web sites trying to get a supported dongle-type to buy a new one - very embarrassing in retrospect

Unfortunately, I still didn't have any success when I failed the main WAN link and had to do a little more digging. Again, my ignorance of 3G backup shone through, and after a little Googling it became apparent that I had to configure the correct dial-up parameters in the BR200-WP for my 3G dongle provider. In my case, as I use Vodafone here in the UK, my parameters are:
  • APN: internet
  • Dialup number: ATD*99#
  • User ID: web
  • Password: web
These parameters will vary from provider to provider. If they aren't 100% correct, things won't work. I found a great site with the correct  strings for many 3G/4G providers and their various data plans here in the UK, which you may find useful if you are going through a similar exercise:


Now that I had the correct type of dongle and the correct dial strings etc., I was ready to roll! I'm pleased to report that things actually worked pretty smoothly once I had this all figured out. I fired up my test wireless client and connected to the Internet via my usual DSL connection. Then, I failed the DSL connection and after a few seconds, the 3G link kicked-in and I carried on working.

I took a screen shot of the AP configuration so that you can see how I had it all configured to provide the 3G WAN backup. I've highlighted the important areas with red boxes:

Just to run through the 5 highlighted areas:
  • WLAN interface: not really related to 3G backup at all (sorry), but still very interesting. I found out that the way you switch between 2.4GHz and 5GHz is by changing the radio profile - that isn't immediately obvious (I never even realised you could switch to 5GHz until I read the data sheet!)
  • Eth0 - Set this interface to a priority of primary (this is the default) - this will ensure that the WAN link connected via this port is used for all traffic during normal (non-failure) operation
  • USB - Set the priority to Backup1 (this is the default) - this will ensure that this interface is used when the main WAN link (Eth0) fails
  • Wireless USB Modem Settings - Connect As Needed: this will ensure that the 3G link only comes up when the WAN links fails, rather than being permanently dialled up.
  • USB Modem - ensure that the various 3G modem strings are entered as per your 3G provider requirements
One area that I struggled with was getting the 3G dialler parameters (APN, User ID etc.) correct. This was quite difficult and time-consuming to resolve by the usual method of making a change via HMOL and then pushing the change out. So, I improvised slightly and connected my console cable to the BR200-WP. I made a few small config changes to the BR200-WP configuration via the CLI to test the effect of various changes in real-time. I used the following CLI commands:

usbmodem modem-id huawei_e220 apn internet
usbmodem modem-id huawei_e220 dialup-number ATD*99#
usbmodem modem-id huawei_e220 dialup-password web
usbmodem modem-id huawei_e220 dialup-username web

Once I'd got them right via the CLI, I configured them on HMOL and pushed out the final, correct config. Making CLI changes isn't really generally recommended, but in this case, it saved me a lot of time!

One other area I became very familiar with when trying to get this going is the debugging available from the CLI of the AP. If you're trying to set this up and are having difficulties, it's well worth enabling some debugging to see what's going on. I used the following command (which gives you more information than you really need):

debug console all

This gave a log on my terminal screen of everything going on, but allowed me to see the BR200-WP attempting to dial up the 3G connection when the WAN link failed. Here is a partial dump of the log showing a successful fail-over to the 3G connection, which may be useful (I've changed a few IP addresses etc. for security reasons):

2013-05-21 16:49:42 info    registering with PM for pid=2576 name=[mod_name_pppd_mod_id_64] cmdline=[/sbin/pppd noaccomp nopcomp novj nobsdcomp noipdefault noauth defaultroute replacedefaultroute usepeerdns lock crtscts persist ah-pppousb linkname usb_modem0 ipparam 115200 /dev/ttyUSB0 user web password web connect  USE_DIALUP_NUM=ATD*99# USE_APN=internet /sbin/chat -t5 -v -E -f /etc/chatscripts/3g.chat]
2013-05-21 16:49:42 notice  pppd[2576]: pppd 2.4.3 started by root, uid 0
2013-05-21 16:49:43 info    chat[2583]: abort on (BUSY)
2013-05-21 16:49:43 info    chat[2583]: abort on (NO CARRIER)
2013-05-21 16:49:43 info    chat[2583]: abort on (ERROR)
2013-05-21 16:49:43 info    chat[2583]: report (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 5 seconds
2013-05-21 16:49:43 info    chat[2583]: send (AT&F^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: AT&F^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATE1^M)
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATE1^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (AT+CGDCONT=1,"IP","internet"^M)
2013-05-21 16:49:43 info    chat[2583]: timeout set to 10 seconds
2013-05-21 16:49:43 info    chat[2583]: expect (OK)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: AT+CGDCONT=1,"IP","internet"^M^M
2013-05-21 16:49:43 info    chat[2583]: OK
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send (ATD*99#^M)
2013-05-21 16:49:43 info    chat[2583]: expect (CONNECT)
2013-05-21 16:49:43 info    chat[2583]: ^M
2013-05-21 16:49:43 info    chat[2583]: ATD*99#^M^M
2013-05-21 16:49:43 info    chat[2583]: CONNECT
2013-05-21 16:49:43 info    chat[2583]: -- got it
2013-05-21 16:49:43 info    chat[2583]: send ( ^M)
2013-05-21 16:49:43 info    pppd[2576]: Serial connection established.
2013-05-21 16:49:43 warn    mDNSResponder: interface change, mdnsd refresh interface list and service!!!
2013-05-21 16:49:43 info    kernel: [systop]: initializing AH dev for ifp ppp0!
2013-05-21 16:49:43 info    kernel: [mpi]: drop unsupported event 0x5 from ppp0
2013-05-21 16:49:43 info    pppd[2576]: Using interface ppp0
2013-05-21 16:49:43 notice  pppd[2576]: Connect: ppp0 <--> /dev/ttyUSB0
2013-05-21 16:49:44 info    pppd[2576]: CHAP authentication succeeded
2013-05-21 16:49:44 notice  pppd[2576]: CHAP authentication succeeded

2013-05-21 16:49:44 warn    pppd[2576]: kernel does not support PPP filtering
2013-05-21 16:49:47 warn    pppd[2576]: Could not determine remote IP address: defaulting to 10.x.x.x
2013-05-21 16:49:47 info    amrp2: receive kevent KEVT_IF_CHG type IF_UP from ppp0 index 20
2013-05-21 16:49:47 warn    ah_dcd: Interface ppp0 is up.
2013-05-21 16:49:47 info    ah_dcd: access interface ppp0 is up now
2013-05-21 16:49:47 info    capwap: CAPWAP receive kevent KEVT_IF_CHG, eventid = 16, size = 36
2013-05-21 16:49:47 info    kernel: [mpi]: drop unsupported event 0xd from ppp0
2013-05-21 16:49:47 info    kernel: [mpi]: ppp0 notify kevent KEVT_IF_CHG, type IF_UP(1)
2013-05-21 16:49:47 info    capwap: receive event vpn report responce capwap: eventid = 103: length = 30
2013-05-21 16:49:47 info    capwap: CAPWAP: receive vpn report responce capwap event!, length:30
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4135), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters, ifname
2013-05-21 16:49:47 info    kernel: [mpi]: socket is closed, pid(-4136), protocol(0)
2013-05-21 16:49:47 info    ah_vpn: <IKE>  update share memory default gateway parameters, ifname
2013-05-21 16:49:47 debug   ah_brd: WANFO: Added event BACKUP_WAN_CONNECTED
2013-05-21 16:49:47 debug   ah_brd: WANFO WANFO SM Engine: @ state:NOWAN + event:BACKUP_WAN_CONNECTED [0x3]

So, there you have it, a quick look at setting up the 3G backup on the BR200-WP. 

It's worth bearing in the mind the limitations of 3G connectivity as a backup medium. You're realistically limited to downstream connectivity speeds of around 2 to 4 Mbps, depending on your signal strength, with upload speeds being just a few hundred kbps. It's not going to provide you lightning connectivity, but it will keep you going. It will be fascinating to see how a 4G connection performs, potentially providing several tens of mbps in each direction (providing you can get the coverage!). The possibilities for the BR200-WP certainly increase significantly if a good cellular WAN speed can be achieved.


Sunday, 19 May 2013

Top 10 Things a WiFi Installer Does Not Want To Hear...

Here are the top 10 things (IMO) you don't want to hear from a customer when you arrive on site to install a new WiFi network (I compiled this rather quickly in a flippant moment - please don't take it too seriously...):
  1. Our networking guy, who was going to be helping you today, isn't available, I'm afraid he's... (choose from the following):
    • On a late shift
    • Off sick
    • On leave
    • Over-slept
    • Double-booked
    • Left the company
    • Had a baby
    • Buying a radiation suit
  2. Oh, you wanted POE ports for those APs?
  3. Our goods-in department has definitely received the kit, they're just not sure which part of the hospital it went to...
  4. Oh, we thought you were bringing the kit with you. No, we haven't received anything.
  5. You know that 500-person call-center where you said we might have issue with personal hot-spots? The good news is, we've introduced a policy of 'no personal hot-spots' in that area! As a sweetener, we gave all of the operatives a bluetooth headset, mouse and keyboard each. We also threw in 5 new microwave ovens for their rest area, together with 10 new security cameras to monitor all that new gear.
  6. We've changed out minds. We'd really like to be able to run video and voice across the network as well. Can you squeeze that in whilst you're here?
  7. Our CEO has a new iPad and he'd really like to be able to use it on the wireless network. I know it wasn't in scope, but it's really important...
  8. Well, the salesman said it would support <insert unsupported feature here>.
  9. We've decided we would like a bit of coverage outside of the building after all (the CEO is a smoker). Can you move a couple of APs a bit closer to the windows near the smokers area?
  10. The cabling guy has assured us that you'll have no issues with 120 metre cable runs...
I'm sure there are plenty of others... :)


Tuesday, 7 May 2013

5GHz - 3 Missing Channels in Europe

Last year, I put up a posting which highlighted the fact that here in the UK (and I suspect all of Europe) we often have 3 channels missing from our allocation of unlicensed channels in the 5GHz band.  Looking at many manufacturer data sheets, channels 120, 124 and 128 are often shown as not being supported. This is despite the fact that they are allocated for use by local regulatory bodies (OFCOM here in the UK).

I recently posted a question about this on a partner forum of a major WiFi vendor that I deal with and finally got a definitive answer on this. In this post, I'll share my findings.

The reason that these particular channels (120 - 128) receive special treatment is that they occupy frequencies that are used by weather radar systems. WiFi systems have to be very careful not to interfere with those systems during their normal operation. Therefore, WiFi equipment has some additional checks and tests imposed on it to make sure that it does not inadvertently cause any interference.

In the ETSI region (Europe), the standard EN 301 893 dictates that any channels operating in the frequency range 5.6GHz to 5.65GHz must wait an additional period of time before using a channel. For most DFS-affected channels, a WiFi device must wait for 60 seconds to verify that no radar is present before commencing operation. However, on the channels in the 5.6GHz to 5.65GHz range, the device (i.e. Access Point) must wait 10 minutes! The table below (taken from Annex D of the standard) details this requirement:

Due to this 10 minute wait period, it seems that many manufacturers have chosen to withdraw support for the channels affected, which are 120, 124 and 128. This makes perfect sense now - who would want an AP to be allocated to a channel and then wait for 10 minutes before it can use it..?

I'm pleased to have finally got to the bottom of this particular grey area, but it seems like bad news for WiFi usage in Europe generally. With the anticipated sharp uptake in 5GHz usage around the globe, as 802.11ac starts to roll out, the loss of 3 channels is quite a chunk of spectrum to lose.

In the UK we have 19 unlicensed channels to use on 5GHz for WiFi. Losing 3 of those channels is a 15% loss in spectrum. This is at a time when we really need to be increasing spectrum availability to cope with the additional channel bonding opportunities that  802.11ac provides to increase WiFi speeds.

Hmmm....let's hope some additional spectrum turns up in the near future.

Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here

Saturday, 4 May 2013

Samsung Galaxy S4 WiFi Capabilities

With all of the excitement around 802.11ac that is currently unfolding, I was very interested to hear about the support for 11ac by the recently released  Saumsung Galaxy S4. Having a quick scan of the reviews across the web about the new handset, I was intrigued to see claims that it supports 802.11ac, allowing speeds up to 1.3Gbps! Feeling a little sceptical that it would support anything close to those speeds, I did a bit of digging to see what I could find.

My first port of call was a product tear-down over at TechInsights.com. They revealed that the WiFi chip in the S4 is the Broadcom BCM4335

A quick look around the Broadcom site soon revealed the product page for the BCM4335, with an overview of the chipset specification. In summary, it supports:

  • Single stream IEEE 802.11ac solution with data rates up to 433.3 Mbps
  • Full IEEE 802.11a/b/g/n legacy compatibility with enhanced performance
  • Supports 20, 40, and 80 MHz channels with optional SGI (256 QAM modulation)
  • The BCM4335 features advanced idle power consumption performance, which significantly extends mobile device's battery life
  • Broadcom's TurboQAM™ technology implements the highest data-rate 256-QAM mode in 2.4 GHz and enables devices equipped with the BCM4335 to deliver 10 percent faster throughputs than 802.11n speeds when communicating with other 5G WiFi devices
  • Key high-throughput mobility interfaces, including SDIO 3.0, PCIe and HSIC, make it suitable for smartphone, tablet and computing platforms
  • Advanced beamforming (IEEE 802.11ac/n), Low-Density Parity Check (LDPC) code and Space-Time Block Code (STBC) support for better coverage and more reliable connectivity
  • Built-in media processing to off-load host processor
  • Integrated support for Wi-Fi Direct™, Wi-Fi Certified Miracast™ and Wi-Fi Certified Passpoint™ technologies
Some very interesting facts and figures here, but this pretty much quashed the outlandish claims in some articles around the 1.3Gbps top speed, as the chipset cannot go beyond 433mbps.Even so, these potential performance gains over other non-11ac handsets are very impressive. 

Although the chipset itself may support up to 443.3 Mbps, primarily through the 80Mhz-width channel capability, this doesn't mean that the Samsung implementation has actually taken advantage of the full 80Mhz channel width. I still needed more information to find out what the S4 itself was actually capable of.
The next stop was the FCC web site (A3L/GTI9505 if you want to take a look yourself) to have a look to see if I could see what speeds and channel widths had been tested during the FCC approval testing process.  

The WLAN testing report shows that the handset was tested on both 2.4GHz (802.11b/g/n) and 5GHz (802.11a/n/ac). Interestingly, it was tested up to 433.3mbps, using an 80Mhz width channel! 

There were also some interesting power levels presented, which seem to suggest that the transmit power level of the device was averaging around 11-13dBm on 5GHz, depending on the data rate and channel. On 2.4GHz, it looks like it has a slightly higher power output, showing figures averaging 12-15dBm.

So, in summary, the S4 is a single stream device, supporting up to 80MHz channels (for 802.11ac ) and has a top speed of around 433Mbps. Don't forget
 these figures will assume ideal conditions (i.e. short guard interval, close proximity to AP, good SNR values etc.), and that these are connection speeds, not throughput speeds that you would see when transferring data. Actual throughput is likely to be a little over half of the top-speed of 433Mbps. 

Also, don't forget that 802.11ac is only supported on the 5GHz band. If you are using it on 2.4GHz, the best you are going to get is the top speed for a single stream 802.11n device  on a 20MHz channel (around 72Mbps connection speed).

All we need now are some 802.11ac APs to use the S4 with :)