Archive

Author Archive

Peek Inside 802.11ac Access Point Hardware Designs

March 25th, 2014

There is large and ever increasing assortment of enterprise access points offered by wireless vendors today.  APs have different number of radios, number of streams, 11n/11ac, POE compatibility, peripherals, price, etc. While this diversity is overwhelming, have you wondered what lies in the hardware guts of these APs? What are the hardware design concepts that are responsible for rendering feature personality to the AP? How does the hardware ecosystem work among chip vendors, ODMs and AP vendors? What are state of the art hardware architectures for the 802.11ac APs? This blog post discusses key hardware concepts, such as SoC, dedicated CPU and offload architectures that are commonly found inside the APs, along with the ODM sourcing model for the Wi-Fi APs and its implications for product offerings.

At a high level, the AP hardware has to perform three types of processing: RF, baseband, MAC/L2/packet. The first two are mainly concerned with the signal modulation/demodulation related tasks; while the third takes care of the 802.11 MAC and L2 protocol implementation and provides the hooks into the packet processing to build various features like QoS, firewalls, bandwidth limiting, etc. The RF and baseband processing are done by the “radio module”. The radio module also performs certain time sensitive MAC/L2 functions such as ACKs, RTS/CTS, time stamping, etc.  The bulk of MAC/L2/packet processing is performed by the “host CPU module”.

SoC (System on Chip) Architecture

In this architecture, there is a single chip which can do the job of the host CPU module and also one radio module. A dual radio AP can be implemented with the SoC architecture with two chips: The main chip includes the host CPU (usually MIPS or ARM core) and one radio module (a/b/g/n), and the second separate chip is for the second radio module (a/b/g/n or ac/b/g/n). The second chip is fixed to the board or provided on a PCI Express (PCIe) card that plugs into the PCI slot on the board that interfaces with the CPU chip. The PCIe form factor for the radio module allows for changing the radio module to more easily launch the updated hardware versions of the AP at a later point in time. In the SoC designs, both the chips usually come from the Wi-Fi chip manufacturers such as Qualcomm (Atheros), Broadcom etc. The radio modules are usually dual band tunable, but locked to one band – usually the SoC radio is locked to 2.4 GHz and the separate radio is locked to 5 GHz.

SoC designs are cost efficient because of the reduced BoM of the board. They also draw less power making them attractive for designing APs meant to operate within the 802.3af power budget.

Sample layout of dual radio SoC design

Sample layout of dual radio SoC design

 

 

 

 

 

 

 

 

 

Dedicated CPU Chip Architecture

Unlike the SoC design, in this architecture, there is a separate host CPU chip. So, a dual radio AP in this architecture requires three chips – one chip for the host CPU and two additional chips (fixed to the board or provided on the PCIe cards) for the two radio modules which can be 11n or 11ac. The CPU chip typically comes from the embedded microprocessor vendor such as Freescale, Cavium etc., while the radio chips come from the Wi-Fi chip vendor. However, this year we should see designs with the host CPU chip also coming from the Wi-Fi chip vendor since some of them possess powerful embedded microprocessor technology from their other product lines.

Due to the three-chip design, these APs usually cost more and can have difficulty operating at full function within the 802.3af power budget. On the flip side, dedicated CPU provides more processing capacity and may also provide hardware assist features for the IPSec encryption, DPI (deep packet inspection), etc.

Sample layout for dual radio dedicated CPU design

Sample layout for dual radio dedicated CPU design

 

 

 

 

 

 

 

Offload Architecture for 802.11ac APs (Second Microprocessor to Assist the Host CPU)

Until and including 11n, the de facto way of implementing bulk of MAC/L2/packet processing was entirely within the host CPU. With increasing speeds in 11ac, new concept of “offload processing” has emerged. In the offload processing concept, there is a second microprocessor (in addition to the host CPU) that is embedded in the radio chip (that is separate from the CPU chip). This second microprocessor handles close to 75% MAC/L2/packet processing tasks on the radio chip itself, leaving only about remaining 25% to be done inside the host CPU.

The offload architecture significantly reduces the load on the host CPU at high speeds as in 802.11ac and thus makes it possible to build full function 11ac AP using the SoC design. With the offload concept and SoC design, a dual radio 11ac AP can use one chip for the host CPU and the b/g/n radio module, and a second chip that includes both the ac radio module and the second microprocessor that handles the offload processing.

The flip side of the offload architecture is higher sophistication required for the software running on the host CPU to perform some special packet handling functions such as raw packet injection. This is because, in the offload design, lot of MAC/L2/packet processing happens in the radio chip itself. So, the host CPU needs to interact with the second microprocessor on the radio chip via API and communication calls to implement special processing tasks.

Original Design Manufacturer (ODM)

ODM vendors (which operate from the manufacturing hubs in East Asia) design AP hardware from the reference designs provided by the chip vendors based on the architectures described above and then offer these hardware platforms to the AP vendors. ODMs often also do some modifications of their own to the reference designs to improve their characteristics, such as fitting better antenna on the board.

The AP vendors choose hardware platforms from the ODM offerings for different products as appropriate for specific market verticals. AP vendors can choose enclosures designed by the ODMs and have then branded with their company logos. That is why, we sometimes see similar looking APs offered by different vendors. AP vendors can also have ODMs design special enclosures for them. In this case, even if the APs may not be similar looking, you can encounter common hardware layouts when you pry them open if they have the same ODM board genesis.

ODMs also assist vendors in platform certifications for the regulatory compliances. Due to easy availability of the validated hardware cores and maturity of the ODM model, AP vendors can now deliver new hardware platforms relatively quickly. Though ODM vendors typically accommodate some platform customization such as changing power amplifier rating or amplifier quality, adding extra Ethernet port(s), providing USB port, adding third radio etc., in general the core hardware differences between the APs will be marginal in the future (barring some highly specialized hardware designs). Couple that with the scenario that Wi-Fi application verticals and deployment use cases expand and become more diverse. Then, the bulk of value needs to come from the software that the AP vendors add on top of these cores in the areas of performance, network services, application enablement, security, manageability and others.

/Images via openwrt wiki

802.11ac , , ,

Healthcare, Wi-Fi and HIPAA – A Tricky Combination

February 12th, 2014

What a great start to year on the industry events front – we started with NRF in January, looking forward to HIMSS and our ACTS event in February, and MURTEC in March. In NRF, high points of discussion were around Social Wi-Fi and analytics. That said, topics of security and PCI compliance were also high on the agenda prompted by the Target credit card breach that occurred just before NRF. I expect to there will be a lot of security discussions at HIMSS too.

Healthcare, Wi-Fi and HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) was passed by Congress in 1996. It is enforced by the Department of Health and Human Services (HHS), and implemented by regulations of 45 CFR. Among other provisions it has rules mandating that healthcare organizations safeguard the privacy and security of patient health information. These privacy rules apply to patient information in all forms and the security rules apply to patient information in electronic form called as Electronic Protected Health Information (EPHI). EPHI is any patient information transmitted over a network and stored on a computer.

HIPAA states privacy and security guidelines at high level. They do not require specific technology solutions, but are clear that reasonable and appropriate security measures must be implemented. For example, Section 164.312 has clauses requiring technical policies and procedures to allow access to EPHI only to authorized persons or software programs, to prevent improper alteration or destruction of EPHI and to protect health information transmitted over electronic communication network. Section 164.308 requires among other things identifying, responding, mitigating and documenting suspected or known security incidents.

AirTight WIPS

Protection from vulnerabilities for wireless access layer

What does all this mean to Wi-Fi? Today, healthcare is seeing a flood of wireless enabled devices in day to day operation.  Hospitals are increasingly providing Wi-Fi for doctors to access medical records and VoIP for staff communication. Healthcare facilities are increasingly using Wi-Fi-enabled medical devices. This makes Wi-Fi a dominant EPHI access layer in the healthcare environment. Hence, Wi-Fi security controls built into access points (APs) and covered by intrusion prevention system (WIPS) become relevant to satisfy HIPAA security rules as applied to the access to EPHI over Wi-Fi. For example, just as it is important to enforce strong authentication and encryption on managed APs and to control BYOD, it is important to ensure that unmanaged rogue APs do not open holes into healthcare networks that store and transmit EPHI or to ensure that doctors’ tablets do not connect to Evil Twins or neighborhood APs. Comprehensive reporting and forensic capabilities are also required to satisfy the auditing requirements of HIPAA.

How our customers are addressing security and compliance for EPHI

Over last many years, we have worked with several healthcare organizations to satisfy HIPAA requirements pertaining to Wi-Fi using AirTight’s overlay WIPS and using AirTight’s software configured access point/WIPS combos. Below are some examples.

  • Overlay WIPS in large hospital complex – Maine Medical Center (MMC) is 10-building, 68-floor, 2-million square feet healthcare complex in Portland, Maine. As an early adopter of Wi-Fi technology in healthcare information systems, the MMC has large deployment of Cisco WLC Wi-Fi. However, MMC is also security conscious and performed deep down analysis of security offered by various wireless security solutions. MMC chose to overlay AirTight WIPS on top of Cisco WLC.

AirTight has integration APIs for an easy overlay on Cisco WLC Wi-Fi. Moreover, AirTight WIPS comes out to be more cost efficient from both Capex (as it does not require controllers and MSE) and Opex perspective (due to freedom from false alarms and configuration overhead) than Cisco wireless security.

  • Access Points/WIPS for distributed clinics – CHS Health Services operates onsite clinics delivering full-service solutions for a broad spectrum of industries. Due to highly distributed nature, CHS is concerned about security as well as management of it Wi-Fi infrastructure. Faced with those challenges, AirTight cloud managed Wi-Fi which has WIPS built into it at no extra cost fit the bill. In addition, AirTight’s software configurable dual radio APs provide CHS the flexibility of choosing the right balance of access and security scanning radios to fit nature of each facility.

Overall, Wi-Fi can contribute greatly to enhance the quality of healthcare by providing easy access to information and mobility of healthcare staff. With Wi-Fi however comes risk of new and evolving security threats and compliance violations. As a result, choosing right security solution becomes imperative to be able to reap full benefits of Wi-Fi for the betterment of patient care! Visit AirTight booth at HIMSS to find out more.

Compliance, Healthcare, WiFi Access

5 Reasons Why Facebook Wi-Fi is for Local Biz, but Not for Retail Enterprises

January 23rd, 2014

Netgear recently announced integration with Facebook on their APs using Facebook Wi-Fi API. Meraki and Cisco have also announced the same capability on their APs. Facebook Wi-Fi franchise is growing. It is easy to configure and get working (except when used on Cisco APs, which requires running separate CMX VM and per-AP license). That is good news for local businesses. However, does this architecture meet the requirements of mid-size to big retail enterprises? Not so fast! Let me explain.

Retail enterprises operate multiple stores across regions, states or countries. They run targeted marketing campaigns for customer engagement. This puts certain requirements on Social/Wi-Fi integration for retail enterprises, which are currently unmet with Facebook Wi-Fi integration.

1) Omni-channel marketing is essential for maximum reach

Facebook Wi-Fi allows only Facebook logins, obviously. So merchants miss out on other social channels like Twitter, Google+, Linkedin, Foursquare, etc. In addition to social logins, enterprises also want to promote brand loyalty programs when users access guest Wi-Fi. Facebook Wi-Fi does not allow this as well.

2) In the absence of social handles, there is no direct touch with the customers

In Facebook Wi-Fi, the update about the user being present on that Facebook page is automatically distributed when the user logs into Wi-Fi with Facebook credentials (hence, they call it check-in instead of login). However, the merchant does not get the social handles of these users. Note that this is despite the fact that these social handles are public information and the user discloses via check-in (whose default setting is “public”) the presence at that location. Without social handles, merchant cannot have direct touch with the customers. Retail enterprises thus require provision to obtain opt-in social handles of customers, which is not possible with Facebook Wi-Fi integration.

3) Need for customizable incentives to fuel social engagement

Retail enterprises want to provide incentives for using social logins – coupons or other ways to engage with the brand like premium status in the loyalty program. They may also want to provide additional incentives to user for taking a further step to Like or Follow the brand, or joining a loyalty program. Like or Follow has the benefit that the merchant can then reach out to the user with one on one messaging (much like email). Facebook Wi-Fi has only one simple incentive built in it – if you don’t use Facebook login, you may not get free Wi-Fi, though merchants do not have to enforce this as there are provisions in the configuration to bypass it or use a code in lieu of a Facebook login. In any case, the Facebook Wi-Fi check-in does not facilitate customizable incentive programs to encourage social engagement.

4) Comprehensive analytics and data ownership are important

Social Wi-Fi can provide retailers with rich analytics and user demographics. Retailers also want to own the analytics data. They want the analytics data available in standard format for integration with their existing marketing platforms. However, with Facebook Wi-Fi, engagement data is within Facebook and mixed up with all the other Facebook interactions.

5) No scaling for multi-store environment

This one is a bummer! The automatic update that is posted to user’s Facebook timeline subsequent to a login includes location address configured in the Facebook page. So, if you operate 50, 500 or 5000 stores, each location needs to have its own Facebook page. If you use single page for all those locations, the user location update will go with address configured in that page which may be inconsistent with the actual location where user checks in. This is just an example of how Facebook Wi-Fi is not designed with multi-unit retail enterprise in mind.

Facebook-Wi-Fi-for-multi-site

If you’re an IT or a marketing manager for a retail chain, imagine setting up dozens or hundreds of Facebook pages for your branches

AirTight Social Wi-Fi integration with Facebook, Twitter and others

In contrast, AirTight Networks’ social Wi-Fi is designed with multi-unit retail enterprises in mind. It uses a cloud-hosted captive portal that interacts with users on one side and multiple social media apps including Facebook, Twitter, LinkedIn, Google+ etc. on the other. The portal provides all the knobs to customize the campaigns including incentives, landing pages and updates. The captive portal securely stores social engagement information including social handles and demographics that user has chosen to share. The portal provides cleanly segregated and rich Wi-Fi analytics and also makes analytics data available to merchants in standard formats.

For more information:

Learn more about AirTight Social Wi-Fi + Analytics.

Watch a 5-min video on best practices in retail analytics.

Read our blog post on analytics data ownership (hint: in many cases, you don’t own the analytics data your Wi-Fi system generates)

 /Image via Facebook.

Retail, WiFi Access

Will Target Breach Prompt Retailers to Raise the Security Bar?

January 8th, 2014

Did 2013 have to end with the somber news of a big credit card security breach? But it did! It is reported that 40 million credit cards were compromised in the security breach in stores of a major U.S. retailer Target. This is only a shade second to the earlier TJX breach in which 45 million credit cards were compromised. (After this blog was published, it was reported that the number of affected accounts in the Target breach is as high as 110 million, which would make it more that double the TJX breach!)

After any breach, and surely after the breach of such dimension, discussion on the data security issues at the retailers escalates. Earlier, the TJX breach resulted in stricter wireless PCI (Payment Card Industry) compliance requirements. The current Target breach can also trigger tightening of the compliance requirements. This breach may also prompt IT, security and compliance managers at major retailers to take a hard look at the information security aspects of the various technologies that they have deployed. Add to it the fact that retailers are aggressively deploying mobile and wireless technologies like POS, kiosks and tablets in stores. What are some of the core issues they should be looking at?

Don’t be content with “compliance”, demand “security”!

Retailers in these types of breaches often pass the security audits like PCI with flying colors. That exposes the harsh reality that security is distinct from compliance. 2014 is the year of the world cup soccer (football). So let us use soccer analogy to understand this distinction.

Compliance vs security, wireless PCIWhen you are defending a free kick in soccer, you make a wall and your goalkeeper is on alert to block the ball that could go through or around the wall. No soccer team would be comfortable with a sole reliance on the wall and allowing the goalkeeper a break during the free kick. The wall is like “compliance” – it’s one line of defense.

Retailers work hard to get check marks from auditors on their PCI compliance. Vendor marketing does a good job of selling features that help get those coveted check marks. Compliance does help improve the security posture, but is it adequate? Every now and then, this line of defense is breached and if the goalkeeper isn’t standing behind the wall, you are toast! However, if you demand security in addition to the compliance check marks, you can build that inner line of defense.

How will you know if you have the inner line of defense or not?

That is a hard question. One way to answer it is that whether you have it or not depends on the compliance solution you have chosen. If you are using a solution which has compliance reporting bolted on to meet the compliance standard in letter, you probably lack the inner line of defense. On the other hand, if your solution offers PCI compliance as a natural outcome of the strong security fundamentals, you automatically get the inner line of defense.

I can testify to this dichotomy from my experiences with the wireless PCI compliance standard and solutions that are touted to facilitate meeting that standard. Many Wi-Fi vendors have come up with bolt-on WIPS (Wireless Intrusion Prevention System) features with check mark PCI reporting. The real question to ask is: While these systems generate PCI reports in letter and may please your auditor, will they pass the security scrutiny in spirit? So, what are some of the questions you should be asking when scrutinizing the wireless PCI solution to ensure that you are getting the security in addition to the compliance?

  • How much of the security information that the PCI report contains is based on actual scanning of the environment? I have seen many PCI reports based mostly or even entirely on the Q&A type documentation or PASS/FAIL check marks merely based on what feature configuration in enabled in the system. That is fail on security.
  • Is threat scanning 24×7 or is it only occasional spot scanning? PCI does not require 24×7 scanning. It only requires quarterly scanning, but didn’t we just say that we are not interested in mere PCI check marks, we want security. Notably, entire Target breach occurred only over 3 weeks – that is much smaller period than a quarter!
  • Does the scan merely throw raw data at you or does it filter out genuine threats so you can actually act to mitigate them? All too often, I have seen wireless PCI reports simply document all APs seen across all locations to satisfy the so called rogue AP scanning requirement. So, if the report shows 10,000 APs found in of the scan of 100 remote retail locations or 100,000 APs found across 1000 remote retail locations, how in the world are you going to distinguish threat posing APs from this list? If you can’t, this report will meet the PCI clause in letter, but fail miserably on improving the security posture.
  • Is the solution capable of detecting all types of vulnerabilities? For example, can it identify various types of rogue APs? If it only can identify a few types of rogues (such as rogues with correlation between their wired and wireless MAC addresses – so called MAC adjacency), how can you trust that report since there could be unidentified rogue APs connected to your CDE (Cardholder Data Environment) among the large number of APs detected during the scan?
  • Is the solution capable of automatically containing the identified vulnerabilities? Although automatic mitigation is not a PCI requirement, in large nationwide deployments, automatic containment is a requirement for security. Automatic containment reduces the window of vulnerability. Moreover, automatic containment has to occur without  false alarms which can disrupt your  and neighbors’ legitimate operations.
  • Is the solution certified against security standards other than PCI? Again, this is not a PCI requirement, but it meets the litmus test of strong security fundamentals of the solution.
  • Is the solution capable of full security operation at the store level without critical dependence on WAN links?

Does security have to cost more than compliance?

Again, the answer depends on the compliance solution you have chosen. If the solution has PCI compliance reporting bolted on to check against clauses in the standard, you will probably have to add security on top of it, paying considerably more from a total cost of ownership perspective or continue to carry the risk of a breach. On the other hand, if the solution offers PCI compliance as a natural outcome of the strong security fundamentals, you can get security without the extra effort or cost.

With Airtight, there isn’t a chasm between compliance and security

AirTight provides a wireless PCI compliance solution that also meets the critical security criteria. Central to AirTight’s solution is its best in class wireless intrusion prevention engine, the only one today to earn the highest industry ranking. It excels both in the depth of security and the ease of use at the same time – due to core innovations and patented technology. So with this PCI solution, retailers can enjoy the same level of security that financials, governments and defense organizations demand without the additional complexity and cost.

In order to simplify the deployment and management across 100’s or across 100’000’s locations, AirTight provides cloud managed PCI solution with its plug & play APs/scanners in stores and centralized management console in the cloud. In fact, it was the first to launch such a solution when wireless scanning was added in the PCI standard after the TJX breach in the past.

24×7 wireless PCI scanning and WIPS are an intrinsic part of AirTight’s Secure Wi-Fi offering and is provided at no extra licensing cost. It also offers pure OPEX pricing model for its solution to further alleviate the cost burden. Moreover, retailers can also leverage AirTight’s social Wi-Fi and business analytics built into its retail Wi-Fi offering to increase brand following, recruit into brand loyalty programs and offer secure guest Wi-Fi services in stores. It can’t get better than that!

Wishing you a happy and SECURE 2014!

Upcoming events

Meet AirTight at NRF14 on Jan 13-14 and at ACTS event on Jan 15.

Tune in to AirTight’s technology sessions at WFD6.

 

Best practices, Compliance, PCI, Retail, Wireless security , , , , , , , ,

Network troubleshooting in distributed Wi-Fi environments

November 20th, 2013

Wi-Fi is installed after everything else in the network is already set up – switches, routers, servers, firewalls, VPNs etc. Naturally, customers rely on their Wi-Fi solution provider to alleviate any network problems that arise during the Wi-Fi deployments, even though the problems are not necessarily Wi-Fi specific.

Network issues aren’t something new in any project. However, the troubleshooting task becomes challenging when it needs to be done remotely and when there isn’t much onsite IT help. This is often the case with the distributed Wi-Fi deployments. Also, due to the heterogeneity of the network infrastructure in many environments in the distributed vertical, sometimes very stealthy network problems are encountered. Take these recent troubleshooting examples which underscore these points.

Number Jumble in DNS Forwarding

In a recent distributed Wi-Fi installs that we were involved in, the AP would fail to connect to the cloud. After eliminating a few obvious possibilities, we found that the AP was failing to perform a DNS resolution. The customer was using Google DNS. So, we put the DNS request packet from the AP under the microscope and found it to be properly formatted. We did not have access to many parts of the customer’s network to view the logs. Then, one of us made an interesting observation – when the AP pinged something in the Internet, the AP would briefly succeed in performing the DNS resolution. Upon pursuing that lead, we found out that when there was no ping, the DNS request used source port 1024 and failed, but when there was a concurrent ping, it used source port higher than 1024 (since 1024 was taken up by ping) and succeeded.

Need Wi-Fi troubleshooting? Call up a networking Jedi!

Need Wi-Fi troubleshooting? Call up a networking Jedi!

That meant some network element in the packet path was blocking the DNS request with the source port 1024. There is no restriction like this in the DNS protocol on the source port number. Linux implementations have been known to follow the convention to use low ports only for Kernel privilege processes. Some network element in the packet path seemed to have incorrectly adapted that convention to some packet filter rule on the interface. Even then, it seemed the implementation glossed over the detail, since Linux privileged ports are below 1024, not including 1024. Patching the AP software to exclude port numbers below 1025 in the DNS requests solved the problem (though we and even the customer still do not know what was blocking the original DNS requests).

Grumpy RADIUS

In another case, we got panic call from a customer saying that putting an AP in their network disrupted the network. Everyone thought there must be some malformed packet coming out of the AP that some switch or router did not like. We examined several packets from the AP to ensure there was no rogue packet in there. Then the investigation moved to network servers, starting with DHCP and DNS, and we found them to be in good health. Then came the turn of the RADIUS server, which is where unusual activity was spotted. After the AP deployment, the RADIUS process showed frequent restarts. But why would that happen? After all, RADIUS requests from the AP were well formatted. Digging further, we discovered that the contractor had put in an incorrect RADIUS secret in the AP. Instead of gracefully rejecting requests coming from the AP, the RADIUS server process used to restart upon seeing the incorrect secret (and without writing any logs). Entering the correct RADIUS secret in the AP fixed the issue. Hopefully, the customer will now maintain or upgrade their RADIUS infrastructure.

Toast to Network Jedi

I have many such stories to tell and I am sure many of you too. The real heroes in troubleshooting stories like these are the engineers who jump in to resolve insidious problems during Wi-Fi installs. What is also impressive is that they do this in the networks that are completely new to them and often only remotely and partially accessible. My shout-out to all the networking Jedi for making Wi-Fi work in more networks every day!

 

 

WiFi Access, WLAN planning

Bang for the buck with explicit beam forming in 802.11ac

October 16th, 2013

 

Bang for the buck with explicit beam forming in 802.11ac

802.11ac has brought with it MIMO alphabet soup … spatial streams, space-time streams, explicit beam forming, CSD, MU-MIMO. Alphabet soup triggers questions to which curious mind seeks answers. This post is an attempt to explore some questions surrounding explicit beam forming (E-BF) that is available in Wave-1 of 802.11ac. E-BF is a mechanism to manipulate transmissions on multiple antennas to facilitate SNR boosting at the target client.

How is E-BF related to spatial streams?

E-BF is a technique different from spatial streams. E-BF can be used whenever there are multiple antennas on the transmitter, irrespective of the number of spatial streams used for transmission.

In the transmission using multiple spatial streams, distinct data streams are modulated on signals transmitted from distinct antennas. The signals from different antennas get mixed up in the wireless medium after they are transmitted from the antennas. The receiver uses signal processing techniques to segregate distinct data streams from the mixture. The ability to separate these distinct data streams from the mixture is dependent on the channel conditions between the transmitter and the receiver (to be able to isolate `S’ streams at the receiver, the channel matrix needs to have rank of `S’ or more). There is no channel dependent processing of signal at the transmitter. Receiver performance is channel dependent. Some key points regarding multiple spatial streams (spatial multiplexing) are:

  • To support `S’-stream transmission, both AP and client must have at least`S’ antennas
  • Rich scattering environment (e.g., indoor) is conducive to give high ranked channel matrix
  • There is no need to send channel feedback from the receiver to the transmitter.

In the transmission using E-BF, the spatial streams are pre-processed (and pre-mixed) to match them to the channel characteristics from the transmitter to the receiver and the output of the pre-processor is transmitted from different antennas. Feedback from the receiver about the  channel characteristics is used in pre-processing. For practical implementation called ZF (Zero Forcing) receiver, E-BF causes SNR boosting for the spatial streams at the receiver. Some key points regarding E-BF are:

  • Feasible with multiple antennas on the AP, irrespective of the number of spatial streams
  • Affects SNR of spatial streams at the receiver
  • Requires channel dependent pre-processing of signal at the transmitter
  • Requires feedback on channel characteristics from the receiver to the transmitter
  • Does not require multiple antennas at the receiver.
When is E-BF truly beneficial?

In general, E-BF is truly beneficial when the number of spatial streams in use is less than the number of antennas on the AP. In Wi-Fi, this most commonly happens when the client has less number of antennas than the AP. For example, most smartphones and tablets have only 1 antenna on them.

Stream vs beam tradeoff:

For the example of 3-stream AP and 3-stream client, adding E-BF on top of 3-stream transmission may not give significant benefit. This is because, with E-BF different spatial streams typically experience unequal boost in SNR. The SNR can be significantly boosted for some spatial streams with E-BF. On the flip side, there will usually also be some spatial streams for which the SNR boost is not significant. Or, it could even be degradation of SNR for some spatial streams compared to the case when E-BF is not used. To be precise, the SNR boost for each spatial stream is dictated by the corresponding singular value of the channel matrix and the singular values of the channel matrix range from high to low for practical channels (E-BF is based on technique called Singular Value Decomposition or SVD). Couple this with the fact that practical implementations use the same MCS on all spatial streams. So, this means either using the MCS supportable by the weakest SNR spatial stream for all spatial streams or using high MCS for the strong streams and dropping the weak streams. There is excellent explanation of this tradeoff  in the book by Perahia and Stacey in Chapter 13 (if you are up for reading some math!).

However, if 3-stream AP can support only 1-stream transmission to the client, E-BF can give significant gain. This is commonly the case with smart devices which have only 1 antenna on them. In this case, the single stream will most likely get boosted in SNR and there isn’t another stream to counter the SNR boost.

How much overhead does E-BF feedback cause on wireless bandwidth?

E-BF requires feedback from the receiver to the transmitter about the channel characteristics. In order to trigger this feedback, the transmitter sends sounding packet to the client. Client performs channel measurements on the sounding packet and responds to the AP with the channel feedback. A question that often comes up in E-BF is how much of a wireless link overhead the E-BF feedback report would cause. To answer that question, take a look at this spreadsheet. From this spreadsheet, it appears that the feedback overhead is relatively small (only about 0.1% of airtime), particularly for the case where E-BF is going to be most beneficial, e.g., 3 or 4-antenna AP talking to 1-antenna client.

All factors considered, E-BF appears to provide benefits for smartphones and tablets, which typically have only 1 antenna and hence cannot support multiple spatial streams when connected to the 3 or 4-stream AP. On the other hand, when there are multiple antennas on both sides of the link (such as a 3 or 4-stream laptop connected to the 3 or 4-stream AP), spatial multiplexing without E-BF can be as good as one with E-BF. These are the inferences drawn from MIMO principles and it would be interesting to see if they match up with measurements from the practical Wave-1 environments.

Earlier Posts in 802.11 Network Engineering Series:

 

802.11ac, 802.11n, WiFi Access , , ,

Hunting down the cost factors in the cloud Wi-Fi management plane

October 3rd, 2013

 

Mature cloud Wi-Fi offerings have gone through few phases already. They started with bare-bones device configuration from the cloud console and over the years matured into meaty management plane for complete Wi-Fi access, security and complementary services in the cloud.

CostAlongside these phases of evolution, optimizing the cost of operation of the cloud backend has always been important consideration. It is critical for cloud operators and Managed Service Providers (MSPs). This cost dictates what end users pay for cloud Wi-Fi services and whether attractive pricing models (like AirTight’s Opex-only model) can be viable in the long run. It is also important to the bottom line of the cloud operator/MSP.

Posed with the cost question, one would impulsively say that cost is driven by the capacity in terms of number of APs that can be managed from a staple of compute resource in the cloud. That is an important cost contributor, but not the only one!

 

What do the cost models from cloud operation reveal?

 

We have monitored cloud backend operation costs for past several years. Based on that data, we have built some cost models. These models have led to the discovery of factors that are significant cost contributors. Identifying the cost component is a major step towards reducing it. The cost reduction is often implemented by the combination of technology and process innovations.

 

Draining the cost out of cloud

 

Scalability

This one is no brainer for anyone with head in the cloud. Scalability generally refers to number of APs that can be managed with a unit of compute resource. Higher scalability helps reduce the cost. Enough said.

Provisioning

As the customers of diverse scales (10 APs to 10,000 APs) are deployed in the cloud and at diverse paces, it often results into unused capacity holes in the provisioned compute resources. The capacity holes are undesirable, because the cloud operator or MSP has to pay for them, but they don’t get utilized towards managing end user devices.

The unused capacity problem needs to be solved at two points in time: Initial provisioning and re-provisioning. Clearly, when new customers are deployed, you try to fit them in the right sized capacity buckets. Assuming they love your product, they will then deploy more and start to outgrow their capacity buckets (but you also cannot over-provision, else there will be capacity hole from the beginning). This is the re-provisioning time. At that time, the cloud architecture and processes need to be able to seamlessly migrate customers to bigger capacity buckets.

Personnel

The very reason customers have chosen to go with cloud is because they want plug-n-play experience. As such, the patience level of the cloud customer is often lower than the one choosing the onsite deployment option. This necessitates higher level of plug-n-play experience to avoid support calls.

There are various points in the life cycle that have high tendency to generate support calls.  One point in time is when devices connect to the cloud, or let’s say, not able to connect to cloud. Another critical time is during software upgrades. The issues also often arise during re-provisioning as discussed above when customers are migrated between compute resources. The cost of attending to support calls can be a significant factor if these experiences are not super smooth. Additional complexities arise when APs are sold through channel, but cloud is operated by vendor or another MSP.

The pricing logic behind reducing personnel cost at MSP is as follows. The end user is eliminating the onsite personnel cost by migrating to cloud, and hence paying less on TCO basis. When the experience is not smooth, this cost is transferred to the personnel at the cloud operator or MSP. The cloud operator and MSP cannot make money if they pick up significant part of this cost on their head.

Latent Resources

Certain features such as high availability and disaster recovery have potential to give rise to latent resources. Latent resources are different from capacity holes discussed before. Latent resources are like insurance in that they don’t get utilized most of the time, but they need to be maintained in great shape. Brute force implementation of these redundancy features has been found to be significant cost contributor to cloud operation.

For any cloud services platform, the above pain points are exposed after years of operational experience and teething pain with diverse customer deployments. That is why, it would be appropriate to say that there are two parts to the viable cloud operation – one is the computing technology that enables complete management features and the other is operational maturity. You overlook any one of them and the cloud can become unviable for operator/MSP and customers in the long term.

 

Additional references:

Wireless Field Day 5, AirTight Cloud Architecture video

Aruba Debuts Bare-Bones Cloud WLAN at Network Computing by Lee Badman

Next generation cloud-based Wi-Fi management plane

Controller Wi-Fi, controller-less Wi-Fi, cloud Wi-Fi: What does it mean to the end user?

AirTight is Making Enterprise Wi-Fi Fun Again

Different Shades of Cloud Wi-Fi: Rebranded, Activated, Managed

 

802.11ac, 802.11n, Cloud computing, WLAN networks , , , , , ,

MU-MIMO: How may the path look like from standardization to implementation?

September 26th, 2013

In earlier blog posts on 802.11ac practical considerations, we reviewed 80 MHz channels, 256 QAM and 5 GHz migration. Continuing the 802.11ac insights series, in this post we will look at some practical aspects of MU-MIMO, which is the star attraction of the impending Wave-2 of 802.11ac.

 

MU-MIMO mechanics and 802.11ac standard

 

Illustration of 802.11ac MU-MIMO

Illustration of 802.11ac MU-MIMO

At a high level, MU-MIMO allows AP with multiple antennas to concurrently transmit frames to multiple clients, when each of the multiple clients has lesser antennas than AP. For example, AP with 4 antennas can use 2-stream transmission to a client which has 2 antennas and 1-stream transmission to a client which has 1 antenna, simultaneously. Implicit requirement to attain such concurrent transmission is beamforming, which has to ensure that bits of the first client coherently combine at its location, while bits of the second client do the same at the second client location. It is also important to ensure that bits of the first client form null beam at the location of the second client and vice versa.

 

What does 802.11ac standard offer for implementing MU-MIMO

  •  The standard provides Group ID Management procedure to form client groups. Clients in a given group can be considered together for co-scheduling of transmissions using the MU-MIMO beamforming.
  • To be able to perform peak/null adjustments in MU-MIMO beamforming as described above, the AP needs to have knowledge of Tx to Rx antennas channel matrix to each client in the group. For this, the standard provides well defined process for channel learning wherein AP transmits sounding packet called as NDP (Null Data Packet) to which clients respond with channel feedback frames (this is called explicit feedback mechanism).

 

 What the standard does not specify

 

There is more to MU-MIMO implementation that is outside of the scope of the standard. The true promise of MU-MIMO is also dependent on these additional implementation factors:

  •  AP has to identify clients that can be co-scheduled in a group. How to form these groups is implementation specific. It is dependent on prevalent channel conditions to different clients. AP will have to make smart decisions on group formation.
  • AP has to keep track of channel conditions for clients in different groups by sending regular sounding packets and receiving explicit feedback to the sounding packets from the clients.  Various implementations may differ based on how frequent channel learning is required in them. Frequent learning increases channel overhead, but may result into cleaner (non-interfering) MU-MIMO beams. Slow learning can result in stale information thereby causing inter-beam interference during concurrent transmissions.
  • When channel conditions change, re-grouping of clients is required. Implementations can differ based on re-grouping triggers and method of re-grouping.
  • Implementations can also differ based on how total antennas on AP are used for beamforming within any given group.
  • The performance of MU-MIMO also depends to some degree on the client side implementation. For demodulating the MU-MIMO signal, clients can implement additional techniques such as interference cancellation to eliminate inter-beam interference.
  • The formation of MU-MIMO groups at physical/MAC layer has to also coincide with traffic and QoS requirements of the clients at higher protocol level.

Practical impact

Practical implementation aspects of MU-MIMOThe above considerations are at practical implementation level. Many of them are in the domain of chip design. How well different chip vendors address them could differentiate them from one another in the MU-MIMO era.

They can also impact Wi-Fi chip design paradigm, which traditionally used similar designs for AP and client radios. With MU-MIMO, there will be bulk of tasks that will be performed at AP, resulting in significant design differences between AP side chipset and client side chipset.

Due to all the nuances of implementation and sensitivity to channel conditions, comparing different MU-MIMO implementations in practical network is difficult task. Notwithstanding, I can imagine MU-MIMO becoming table stake in RFPs after Wave-2 arrives, to which everyone will answer “yes” without heed to the exact implementation details. :-)

One radical thought

Given the cost and complexity of chip level tasks required in MU-MIMO, could there be some chip family which may just use all antennas on the AP to form beam to single client at a time. That is, sequential SU-MIMO, instead of parallel MU-MIMO. What will be pros and cons? Will MU-MIMO be only incrementally or significantly better than sequential SU-MIMO? Time will tell.

Devil is in Detail!

 

Addition Information:

 

802.11ac, Best practices, WiFi Access, WLAN networks , ,

Blackhat 13 Wi-Fi Security Reports and Nuances of Detection Methods

September 12th, 2013

|

blackhat USA 13Shortly following the conclusion of Blackhat’13, a few articles came out reporting wireless scanning data from the venue.

  Inside the Black Hat 2013 Wi-Fi Network

  Karma is a …Errr, What We Learned at BlackHat 2013 

 

Both reports state that many security relevant events were detected in the Wi-Fi traffic during the conference. Given that Blackhat is attended by security experts, ethical hackers and just plain security geeks, finding security signatures in the traffic is not uncommon. Nonetheless, I think a few things still need to be matched up in these stats before arriving at sound conclusions.

|

1190 rogue devices detected compared to 1300 legitimate devices in 24 hours:

|

One of the articles states that: “It’s rather interesting to see an almost equal amount of rogue devices to real ones, and that is very unique”. What would be good to know is how they define ”rogue”. Depending on how you define rogue, you can call anything from a normal friendly device to a real threat posing device as a rogue.

I suspect that the definition for rogue used in the context of this report is so broad that it is classifying just about every wireless device unknown to the scanning system and seen in the airspace as rogue. But then, it is not clear why such an observation is considered “unique”. This is because, almost everyone attending Blackhat carries multiple Wi-Fi enabled devices and we cannot expect them to register each of their devices with the scanning system.

From the security perspective however, it is important not to get lost in definition of rogues, but be able to detect straight up genuine rogues (aka security threats) and not raise false alarms on normal wireless activity.

 

Fast WEP Crack (ARP Replay) Detected

|

The report also cites “most likely a security vendor demonstrating a tool”. What is perplexing is why Blackhat attendees still have interest in WEP crack tools or their antidotes, especially given that WEP has been beaten to nail and is now mostly irrelevant.

Or, it could point in the direction that the Wi-Fi community has done such solid job with security and WPA2 that hackers still think that they have to make hay out of WEP.

There is also a third possibility; that these ARPs are just part of normal Wi-Fi traffic that correlates with the signature of WEP cracking detection.

|

Spoofed MAC Address

|

Both reports state several occurrences of MAC spoofing. I suspect that these inferences are based on sequence number anomalies that were detected in the traffic. In fact, the video in one of the reports explicitly calls out sequence number anomalies. However, it’s important to note that sequence number anomaly also routinely happens due to normal traffic patterns.

Common reasons include :

  • sequence numbers fall in range 0-4096, so they wrap around very quickly making the wrap around appear like sequence number anomaly,
  • radios routinely skip sequence numbers due to implementation nuances,
  • intermediate frames may be missed because of device coming and going out of coverage making it look like a sequence number anomaly.

MAC spoofing should only be concluded after all these possibilities are eliminated.

|

Signatures and Anomaly Detection

|

Similar analysis can be performed for other anomalies detected in Blackhat traffic. In fact, this kind of analysis can be performed for several security alerts in many scanning tools and wireless security systems (may be another blog some day, I have many amusing stories to tell about these alerts :-)). The key take-away is that many times there is a leap from signatures and anomalies detected to inferring the presence of a genuine security relevant event.

Bubbleman path optionsWhose job is it to make this leap: system or admin? The need to make the leap gives rise to false alarm problem. Imagine how difficult the job of the security admins becomes when this happens in the enterprise setting! All of a sudden, the alerts also need to be chased and mitigated, not just documented in reports! These admins are also presented with the challenge of defining and tuning thresholds that are right for their environments. If admins are unable to filter false alarms and/or not get to the root causes of steady stream of alerts, it eventually leads to frustration and turning off the security system.

|

Policy Enforcing WIPS

 |

An alternative to signature and anomaly based system is policy enforcing WIPS. By de-emphasizing signature and threshold anomalies, and instead focusing on auto-classification and intrusion prevention, the policy enforcing WIPS offers strong security without overheads of threshold configuration, signature maintenance, false alarms and manual intervention.

So, to reiterate the meta level point about Wi-Fi security: “Intelligent security algorithms tall pole for effective WIPS. Dedicated scan radios otherwise only overwhelm admins with data”.

|

Hemant tall poll tweet

Wireless security , , , , , , ,

11 Commandments of Wi-Fi Decision Making

September 4th, 2013

|

Are you considering new Wi-Fi deployment or upgrade of legacy system? Then you should be prepared to navigate the maze of multiple decision factors given that Wi-Fi bake-offs increasingly require multi-faceted evaluation.

|

Follow these 11 “C”ommandments to navigate the Wi-Fi decision tree:

|

  1. Cost

  2. Wi-Fi CommandmentsComplexity

  3. Coverage

  4. Capacity

  5. Capabilities

  6. Channels

  7. Clients

  8. Cloud

  9. Controller

  10. 11aC, and last but not least …

  11. seCurity!

 

|hemant C tweet

 

1) Cost:

|

Cost consideration entails both “price and pricing” nuances. Price is the size of the dent to the budget and everyone likes it to be as small as possible. Pricing is the manner in which that dent is made – painful or less painful (I don’t think it can ever be painless!). One aspect of pricing is the CAPEX/OPEX angle. Other aspects such as licensing, front loaded versus back loaded, maintenance fees etc. have been around for a long time, so I won’t drill into details of those other than to say that they exist and need to be considered. Enough said on cost.

|

2) Complexity:

|

Complexity consideration spans deployment, configuration and ongoing maintenance. One pitfall to avoid is to “like complexity in the lab and then repent it in the production”. Too many knobs to turn and tune, excessive configuration flexibility and exotic features are some of the things that can add to complexity. That said, complexity considerations cannot swing to the point of being simplistic. Rather, the balanced approach is to look for solutions that have mastered complexity to extract simplicity to meet your needs (borrowing from Don Norman’s terminology here).

 |

3) Coverage:

|

When you hear terms like neg 55, neg 60, neg 65, you know people are reconciling coverage expectations to the number of access points. There’s no explanation needed for how important the coverage is for your wireless network, but the important factor is that the coverage determines the number of access points needed to cover the physical area. At the planning stage, RF predictive planning comes in handy to estimate the coverage BOM (a site survey can complement it for sample areas during the evaluation stage).

|

4) Capacity:

|

While coverage determines how far, capacity determines how many or how much. Capacity determines how small or large cells can be. Using practical models for Wi-Fi usage, capacity objectives can be set and network design can be evaluated against these factors. Capacity also determines the number of access points needed to provide the desired capacity in the physical area. RF predictive planning tools can be invaluable during the evaluation phase for capacity estimation.

|

5) Capabilities:

|

By capabilities, I mean feature set. This is one of the most important aspects because this is where you ask the question: “Will the Wi-Fi serve the needs of the business?” This is very industry specific. Some features are extremely critical for one vertical, but won’t even be noticed in others. So, it’s important to identify both the features you care about and also those for which you don’t.  Once identified, you move on to thoroughly evaluate the ones you care about.

|

6) Channels:

|

One aspect of channels is making decision on how the RF network will be provisioned along the lines of 2.4 GHz and 5 GHz operation. There are advantages to 5 GHz operation, but 2.4 GHz is not EOL yet. How applications are split between the two bands determines the number and type of radios required in the design. Tools and techniques that are needed to plan, monitor and adapt to the dynamic RF environment are also an important consideration.

|

7) Clients:

|

Much of what is achievable in Wi-Fi network depends upon the capabilities of the client devices that will access the wireless network. One set of considerations is mainly around the radio capabilities of clients such as 2.4 GHz/5 GHz operation, number of radio streams, implementation of newer standards in clients etc. Another set of considerations revolves around the applications they run and the traffic profile these applications generate. Yet another set of considerations centers around the level of mobility of the clients. BYOD is another consideration that has become important in the the clients arena.

|

8) Cloud or 9) Controller:

|

Today, we see pure cloud architecture, pure controller architecture and also architectures confused between the two concepts. While vendors and experts spar over which is the right architecture for today’s and tomorrow’s Wi-Fi, evaluators should focus on comparing them based on their derived value. It is also important to understand what cloud and controller concepts actually mean from the data, control and management plane perspective. Cloud and controller are distinct ways of organizing overall Wi-Fi solution functionality.

|

10) 11aC:

|

Making judicious decisions on “what to deploy today or whether to upgrade now” is a tricky one. There are many views around it. One reason is because of how the features of 802.11ac are split between Wave-1 and Wave-2. It is also important to note that immediate 802.11ac benefits are application and vertical specific. Several practical network engineering considerations exist beyond the casual description of the new 802.11ac speeds that are often marketed. So, listen to vendors, listen to business needs, listen to experts, analyze yourself, and in the end, do what is the best for your environment and situation. Speed is nice IF it can be leveraged in practice!

 |

11) SeCurity:

|

Any information system sans security is worse than worthless – especially today. That said, level of security required by the wireless environment depends on factors such as the value of information at risk, compliance requirements and enterprise security policies. Desired security level determines the right mix of data inline security (encryption, authentication) and security from unmanaged devices (WIPS). Talking of WIPS, the biggest red flags to watch for are trigger happy solutions that generate false alarms, boast long list of ”popcorn” alerts and require excessive manual involvement in the security process.

letter spoonfull|

My hope is that these “C”ommandments will help serve as guidelines in your Wi-Fi decision making process. You can follow them in any order you like to ensure holistic evaluation of options before you. Every vendor, big or small, has sweet spots on some dimensions and not so sweet spots on others. So, despite what they tell you, nobody scores all A’s on all C’s. Hence one has to work on the evaluation criteria until the palatable scorecard is achieved consistent with requirements and budget.

 |

Additional References:

 

802.11ac, 802.11n, Best practices, WiFi Access, WLAN networks, WLAN planning , , , , ,