Anyfi

Free SDWN Data Plane for IEEE 802.11

Want to know more about the Software-Defined Wireless Networking (SDWN) architecture or

better understand the security model? Grab a big cup of coffee and dig in.

 

Table of Contents

  1. 1. INTRODUCTION Chapter 1
    1. 1.1.  TERMS AND DEFINITIONS Section 1.1
    2. 1.2.  USER EXPERIENCE Section 1.2
      1. 1.2.1.   SEAMLESS Section 1.2.1
        1. 1.2.1.1.    NO CLIENT-SIDE SOFTWARE Section 1.2.1.1
        2. 1.2.1.2.    NO MANUAL REGISTRATION PROCESS Section 1.2.1.2
        3. 1.2.1.3.    "NO TOUCH" AUTHENTICATION Section 1.2.1.3
      2. 1.2.2.   TRUSTWORTHY Section 1.2.2
      3. 1.2.3.   HIGH QUALITY Section 1.2.3
      4. 1.2.4.   LOW-COST Section 1.2.4
    3. 1.3.  SECURITY MODEL Section 1.3
      1. 1.3.1.   STRONG MUTUAL AUTHENTICATION Section 1.3.1
      2. 1.3.2.   END-TO-END ENCRYPTION Section 1.3.2
      3. 1.3.3.   SPECIAL CONSIDERATIONS Section 1.3.3
    4. 1.4.  REGULATORY AND LEGAL CONSIDERATIONS Section 1.4
  2. 2. ARCHITECTURE Chapter 2
    1. 2.1.  THE RADIO Section 2.1
    2. 2.2.  THE SERVICE Section 2.2
    3. 2.3.  THE CONTROLLER Section 2.3
    4. 2.4.  HOW IT ALL FITS TOGETHER Section 2.4
    5. 2.5.  THE CONTROL PLANE Section 2.5
      1. 2.5.1.   RADIO POLICY CONTROL Section 2.5.1
      2. 2.5.2.   JUST-IN-TIME RESOURCE ALLOCATION Section 2.5.2
      3. 2.5.3.   LOAD BALANCING Section 2.5.3
      4. 2.5.4.   AUTOMATIC FAILOVER Section 2.5.4
      5. 2.5.5.   LINK LEVEL ACCOUNTING Section 2.5.5
      6. 2.5.6.   NAT TRAVERSAL Section 2.5.6
    6. 2.6.  THE USER DATA PLANE Section 2.6
      1. 2.6.1.   SPECTRUM AWARE TRAFFIC PRIORITIZATION Section 2.6.1
      2. 2.6.2.   SEAMLESS HANDOVER Section 2.6.2
    7. 2.7.  TRAFFIC ENGINEERING CONSIDERATIONS Section 2.7
  3. 3. SOFTWARE INTEGRATION Chapter 3
    1. 3.1.  RADIO SOFTWARE Section 3.1
      1. 3.1.1.   WI-FI CHIPSET AND DRIVER REQUIREMENTS Section 3.1.1
      2. 3.1.2.   MEMORY REQUIREMENTS AND IMPACT Section 3.1.2
      3. 3.1.3.   CPU REQUIREMENTS AND IMPACT Section 3.1.3
      4. 3.1.4.   SYSTEM SOFTWARE DEPENDENCIES Section 3.1.4
      5. 3.1.5.   CONFIGURATION PARAMETERS Section 3.1.5
      6. 3.1.6.   FIRMWARE INTEGRATION Section 3.1.6
    2. 3.2.  TUNNEL TERMINATION SOFTWARE Section 3.2
      1. 3.2.1.   MEMORY REQUIREMENTS AND IMPACT Section 3.2.1
      2. 3.2.2.   CPU REQUIREMENTS AND IMPACT Section 3.2.2
      3. 3.2.3.   SYSTEM SOFTWARE DEPENDENCIES Section 3.2.3
      4. 3.2.4.   CONFIGURATION PARAMETERS Section 3.2.4
      5. 3.2.5.   FIRMWARE INTEGRATION Section 3.2.5
    3. 3.3.  PUBLIC ACCESS POINT INTEGRATION Section 3.3
      1. 3.3.1.   LICENSING OPTIONS Section 3.3.1
      2. 3.3.2.   CONFIGURATION INTERFACE Section 3.3.2
      3. 3.3.3.   REMOTE FIRMWARE UPDATE Section 3.3.3
    4. 3.4.  RESIDENTIAL GATEWAY INTEGRATION Section 3.4
      1. 3.4.1.   LICENSING OPTIONS Section 3.4.1
      2. 3.4.2.   CONFIGURATION INTERFACE Section 3.4.2
      3. 3.4.3.   REMOTE FIRMWARE UPDATE Section 3.4.3
    5. 3.5.  CONSUMER WI-FI ROUTER INTEGRATION Section 3.5
      1. 3.5.1.   LICENSING OPTIONS Section 3.5.1
      2. 3.5.2.   CONFIGURATION INTERFACE Section 3.5.2
      3. 3.5.3.   REMOTE FIRMWARE UPDATE Section 3.5.3
    6. 3.6.  TUNNEL TERMINATION GATEWAY INTEGRATION Section 3.6
      1. 3.6.1.   HARDWARE CRYPTO ACCELERATION Section 3.6.1
      2. 3.6.2.   LICENSING OPTIONS Section 3.6.2
      3. 3.6.3.   CONFIGURATION INTERFACE Section 3.6.3
 
1. Introduction

There more than a billion Wi-Fi equipped devices in the world today, and hundreds of millions of access points. But each device can only get online through a small number of them. Anyfi.net is an access point software extension designed to address this problem, by enabling service providers to use the spare capacity of their existing Wi-Fi infrastructure to provide innovative mobile Wi-Fi services. Advanced spectrum aware traffic prioritization ensures that the primary user is not negatively impacted by this secondary use of their equipment. Radio policy control safeguards a positive user experience for mobile users.

Have no idea what Anyfi.net is? Watch this 90 second explainer!
Figure 1.1. Short introductory video explaining the basics of Anyfi.net technology.

Anyfi.net software is available to all vendors under a no-charge royalty-free license and can easily be integrated in any access point or residential gateway with a Wi-Fi chipset from Broadcom, Qualcomm Atheros, Ralink or Realtek. This prevents vendor lock-in and ensures that different types of access points (e.g. residential gateways and public APs) can be seamlessly integrated in a carrier Wi-Fi service. But in order to build such services the service provider also needs a Controller. We make a Community Edition of the Controller available free of charge, with the only limitation that it can be used with a maximum of one hundred Radios and one hundred Services.

Anyfi.net is designed around the networking concept known as Software-Defined Networking (SDN) [1]. The hallmark of an SDN technology is the separation of data plane and control plane. Anyfi.net however goes one step beyond this, by also clearly separating the Radio from the Service. This separation of concern has strong flexibility and security advantages. We stipulate that this separation of radio access from service definition is the second guiding principle underpinning a Software Defined Wireless Networking (SDWN) architecture, the first being the SDN principle of separation between data and control plane.

1.1. Terms and definitions permalink

Throughout this documentation we use a number of technical terms that may need a short introduction. To the largest extent possible we try to use the standard IEEE 802.11 terms and definitions.

1.1.1. Primary function

Anyfi.net technology lets you leverage existing infrastructure, e.g. residential gateways, to create mobile Wi-Fi services. But existing infrastructure is there for a reason — it has a primary function. For example a residential gateway has been designed to provide Internet access to a fixed-line subscriber in their home. We call this the primary function of the residential gateway.

Safeguarding the primary function of an access point is our first priority. The strong security model and advanced spectrum aware prioritization are designed to protect it at all cost.

1.1.2. Public access point

Public access point is our term for an IEEE 802.11 access point with the primary function of providing wireless Internet access in a public space.

Public access points are often owned and managed by a service provider, e.g. a fixed-broadband or mobile operator, but are sometimes operated by a venue or roaming aggregator directly.

1.1.3. Corporate access point

Corporate access point is our term for an IEEE 802.11 access point with the primary function of providing wireless access to a corporate LAN.

Corporate access points are often, as the term implies, owned and managed by a corporation.

1.1.4. Residential gateway

A residential gateway is for the purpose of this document an operator managed broadband gateway with an integrated IEEE 802.11 access point. Its primary function is to provide Internet access to a fixed-line broadband subscriber in their home.

In some contexts this term may be interpreted to also refer to similar equipment used to provide Internet access to a small business.

1.1.5. Consumer Wi-Fi router

A consumer Wi-Fi router is very similar to a residential gateway, except that it is not managed by the operator. The firmware in a consumer Wi-Fi router can only be updated by the consumer that owns it, or in some cases by the vendor.

1.1.6. Basic Service Set

Basic Service Set (BSS) is the IEEE 802.11 term for a wireless access point. Modern access points however often implement a multi-BSS (MBSS) feature allowing a single physical access point to imitate multiple access points. In IEEE 802.11 terminology such an access point supports multiple Basic Service Sets.

A BSS is identified by a BSSID, which is represented as a MAC address.

1.1.7. Extended Service Set

Extended Service Set is the IEEE 802.11 term for a Local Area Network (LAN) segment with Layer 2 connectivity. A number of wireless access points may provide wireless access to such a network. In IEEE 802.11 terminology we would say that the ESS consists of one or several Basic Service Sets. An ESS is identified by an ESSID, which is a 32 character string also known as an SSID. SSIDs are typically locally unique but not globally unique; on a global scale there can be multiple networks with the same SSID.

1.1.8. Wireless Termination Point

Wireless Termination Point (WTP) is used in this document to refer to an IEEE 802.11 access point providing radio access services to a mobile device. What distinguishes a WTP from an access point is that a WTP does not terminate the IEEE 802.11 protocol itself. It simply acts as a relay for raw IEEE 802.11 frames, receiving them through a Wi-Fi over IP tunnel and sending them out on the local radio — and wise-versa in the opposite direction.

A WTP can have several Radios and runs an instance of the Anyfi.net radio software for each of them.

1.1.9. Primary BSS

The Primary BSS of an access point is a Basic Service Set that is used for the primary function of the access point. A residential gateway typically only has one such BSS, the subscriber’s home Wi-Fi network, but may be configured with several. A corporate access point most often has several primary BSSes.

1.1.10. Primary user

A primary user is a user of the primary function, i.e. somebody using a device associated with a Primary BSS of a WTP.

1.1.11. Virtual BSS

A Virtual BSS is a Basic Service Set that provides access to a remote logical Wi-Fi network, through a Wi-Fi over IP tunnel. The Anyfi.net radio software is responsible for allocating Virtual BSSes to provide mobile devices in the vicinity with remote access to their preferred Wi-Fi networks.

A WTP can have several Radios, each of which can have multiple simultaneously active Virtual BSSes. Each of these is associated with at least one Wi-Fi over IP tunnel terminated in a TTP.

1.1.12. Tunnel Termination Point

Analogous to the term WTP we refer to the physical equipment where the Wi-Fi over IP tunnel is terminated as the Tunnel Termination Point (TTP).

A number of TTPs can provide access to the same Service, much in the same way that a number of access points can provide access to the same Extended Service Set. The difference is that a TTP sends and receives IEEE 802.11 over a wired network interface encapsulated in UDP/IP instead of over radio.

Just about type of networking equipment (e.g. a corporate access point, residential gateway or special purpose tunnel termination gateway) can be used as a TTP, by simply integrating the freely available tunnel termination software.

1.1.13. Tunnel termination gateway

A tunnel termination gateway is a network element installed in an operator's edge or core network for the purpose of providing remote secure access to the services of the operator, e.g. Internet access or other more valuable services.

A tunnel termination gateway typically consists of multiple logical TTPs, e.g. one per line card or even CPU core, all providing access to the same Service.

1.1.14. Man-in-the-middle

A man-in-the-middle (MITM) is an attack against a cryptographic system where the attacker inserts himself as a middle-man in the communication between two parties, with the ability to eavesdrop on and modify the communication [2].

The Anyfi.net security model is designed to detect and prevent MITM attacks.

1.1.15. Rogue access point

A rogue access point is a wireless access point that has either been installed on a secure company network without explicit authorization from a local network administrator, or has been created to allow an attacker to conduct a man-in-the-middle attack by mimicking a real access point and tricking a device into connecting [3].

The Anyfi.net security model is designed to prevent rogue access points of the latter kind.

1.2. User experience permalink

Anyfi.net can be used to build many types of mobile Wi-Fi services, e.g. seamless remote access to your favorite Wi-Fi networks, secure mobile offload with SIM authentication and quality of service (QoS) control or a traditional homespot or hotspot service. Most of these have a core user experience in common: they are seamless, trustworthy, high quality and low-cost.

1.2.1. Seamless

Single sign-on is commonly used to refer to an authentication process where the end-user installs some software on their mobile device so that they only have to provide their authentication credentials once, e.g. the first time they connect. Anyfi.net makes it possible to create ZERO sign-on services, i.e. services that require no special software on the device and no manual registration process, but still provides "no touch" authentication even the first time a user connects.

1.2.1.1. No client-side software

Services built on Anyfi.net technology typically require no additional software to be installed on the device. From the device's point of view it's all just Wi-Fi.

1.2.1.2. No manual registration process

With many mobile Wi-Fi solutions the end-user is often required to register an account on a website before they can access the wireless network. With Anyfi.net this manual registration step can be avoided since pre-existing credentials can be used for authentication.

1.2.1.3. "No touch" authentication

By tunneling the Wi-Fi over IP to where the mobile device can most easily be authenticated it is possible to implement "no touch" authentication that works even on the first connection attempt, using the SIM card or a previously entered WPA passphrase as credentials.

1.2.2. Trustworthy

The WPA and WPA2 security protocols are commonly used to secure the Wi-Fi air interface. Anyfi.net extends these protocol over the backhaul as well, terminating their encryption in a location trusted by the mobile user. This leads to a greatly simplified security model with strong and verifiable guarantees for user plane data integrity and privacy, even when there is no trust relationship between the mobile user and the operator of the WTP.

1.2.3. High quality

Wireless networks with spotty coverage tend to produce sessions of low average quality. The reason behind this is simple geometry: just like most of the area of a circle is close to the edge most of your spotty network coverage will be fringe coverage.

Anyfi.net provides a mechanism for the service provider to improve average session quality by cutting away bad sessions: radio policy control. This prevents the mobile device from even detecting the network when the radio link is too poor to support a high quality experience, thus reducing end-user frustration and ensuring a net positive effect of service roll-out.

1.2.4. Low-cost

An access point with Anyfi.net software often has another primary function: e.g. serving as the residential gateway for a fixed-line broadband subscriber. Anyfi.net software carefully measures and throttles mobile devices to ensure that traffic on a Primary BSS is always prioritized and that the fixed-line subscriber's user experience is not in any way impacted. Both backhaul bandwidth and radio spectrum are taken into account.

This advanced traffic prioritization makes it possible to use spare capacity of existing Wi-Fi assets such as residential gateways or corporate access points to provide a mobile Wi-Fi service. This in turn makes it possible to profitably deliver a service at a low (or even zero) price point.

1.3. Security model permalink

Security is important in all Wi-Fi networks but requirements vary depending on how the technology is deployed. We make a clear distinction between the following three security requirements.

  1. Authorization

    Access must be restricted so that only authorized users can access the network and its resources.

  2. Data privacy

    Once a device is connected to the network it must not be possible for a third party to eavesdrop on the communication between the device and the network.

  3. Data integrity

    Once a device is connected to the network it must not be possible for a third party to modify the communication between the device and the network.

In residential or enterprise Wi-Fi networks preventing unauthorized access is usually the focus of attention. Potential threats to data privacy and data integrity on the air interface are handled with WPA/WPA2 mutual authentication and encryption, but not so on the wireline side. It is assumed that anybody with physical access to network elements is prevented through other means (e.g. physical security, company policy, legal agreements and so on) from eavesdropping on or modifying the communication of other users.

Figure 1.3.1. The corporate WLAN environment.

When one enterprise or residense is viewed in isolation this key assumption often holds true, but not so in a mobility context. Visited access points and backhaul connections are more often than not under the physical control of somebody that cannot effectively be prevented from attempting to eavesdrop on or modify the communication of others. Not ensuring data privacy and data integrity through cryptographic means can lead to severe security problems in these use-cases.

Figure 1.3.2. The service provider environment is different because there is no trust between users.

Some vendors in the carrier Wi-Fi space try to mitigate such problems by separately encrypting backhaul connections with IPSec or similar VPN protocols. This however leaves a weak link: clear-text data can still be accessed and modified within the access point itself. There are examples of this weak link being successfully exploited in the field [4].

Figure 1.3.3. Some vendors attempt to patch up security with piecewise VPN tunnels. This adds complexity and reduces scalablity while failing to ensure security.

Anyfi.net technology in contrast has been designed from the ground up for carrier-grade security. User plane data privacy and data integrity is ensured, even when an attacker is in physical control of both the visited access point and the backhaul connection.

Figure 1.3.4. Anyfi.net ensures end-to-end security by extending the WPA/WPA2 security mechanism across the backhaul to a secure location.
1.3.1. Strong mutual authentication

Most WPA/WPA2 security mechanisms ensure strong mutual authentication, i.e. the device is authenticated to the network but the network is also authenticated to the device. This acts as a safeguard against man-in-the-middle attacks in the form of so-called rogue access points.

No chain is however stronger than it's weakest link; the authentication mechanism can only ensure that the counterparties have access to the authentication credentials they say they do. Therefore, if the surrounding system exposes the credentials to unauthorized third parties then the authentication is essentially null and void. In a WPA/WPA2 Personal context this means that an attacker with access to the passphrase can operate a rogue access point presenting itself as part of a trusted network. In a WPA/WPA2 Enterprise context an attacker with access to the RADIUS interface can do the same.

Anyfi.net software goes to great lengths to protect these authentication credentials: in the case of WPA/WPA2 Personal the passphrase never leaves the residential gateway or consumer Wi-Fi router and in the case of WPA/WPA2 Enterprise the RADIUS interface only needs to be accessible from the TTP which can be physically secured.

1.3.2. End-to-end encryption

In most Wi-Fi systems designed for residential or enterprise use user data is only encrypted over the air, or if it is encrypted over the backhaul connection then the backhaul is protected by a separate encryption tunnel, e.g. IPSec or other VPN. With Anyfi.net in contrast the connection is encrypted end-to-end, all the way from the mobile device to the TTP, using the standard IEEE 802.11i AES or TKIP encryption. The encryption keys are derived in the mobile device and at the TTP and are as a rule only available there.

But every rule has an exception. In order to optimize network traffic flow it is possible to adapt Anyfi.net software to send the Temporal Key (TK) into the operators network so that Internet-bound traffic can be broken out centrally. The standard software available under the standard license will however never expose encryption keys to the outside world. We only make software with this adaptation available for deployment in systems where a trust relationship between the end-subscriber and the operator is already established. For example, if the operator has the capability to remotely update the firmware in the subscriber's home gateway then the subscriber has placed his or her trust in the operator and the privacy and integrity of their communication is protected through other means than purely technical. In this context the Temporal Key (TK) can be transferred from the residential gateway to the operator's network without affecting the nature of the trust relationship between subscriber and operator. On the other hand, the same subscriber can reasonably expect the integrity of their network to be protected even from their operator if they are using a consumer Wi-Fi router. In this case a transfer of the Temporal Key (TK) is not acceptable.

1.3.3. Special considerations

Anyfi.net is not an authentication technology, it is a tunneling technology that simply brings raw Wi-Fi radio traffic to where it can be authenticated and decrypted. The security of Anyfi.net rests firmly on the tested and proven Wi-Fi security mechanisms. There are however some aspects that need careful consideration when employing these mechanisms in a different context.

The Internet is much larger than the coverage area of your average Wi-Fi network. Since we expose the IEEE 802.11 stack in the TTP to frames coming in over the network a security defect in this software is much more likely to be exploited and the potential consequences much more severe. We have therefore implemented some security measures intended to harden against such attacks.

Firstly, the tunnel termination software will not provide remote access to networks protected with WEP. We have also implemented protection against brute force attacks. The tunnel termination software will not allow a mobile device to authenticate until it has received an introduction message from the Controller. This prevents parallel "port scanning" type attacks. Once the introduction message is received the TTP will only allow the mobile device a certain number of WPA/WPA2 authentication attempts before disconnecting. The TTP also reports such authentication failures to the matchmaking service which can prevent the attacker from connecting to other TTPs.

Some man-in-the-middle (MITM) attacks may also be easier to exploit in a Wi-Fi over IP context than in a regular Wi-Fi context since IP packets, in contract to radio frames, can be intercepted in transit and prevented from reaching their intended recipient. There are however few known attacks against WPA or WPA2 that could be facilitated by this. The only one we are aware of at this time is Toshihiro Ohigashi and Masakatu Morii [5] and we do not consider that a significant threat in practice.

1.4. Regulatory and legal considerations permalink

Most jurisdictions have regulations mandating telecommunications providers to assist law enforcement in subscriber identification and lawful intercept. In the United States this is regulated in the Communications Assistance for Law Enforcement Act (CALEA) of 1994. In the European Union the European Council Resolution of 17 January 1995 on the Lawful Interception of Telecommunications (Official Journal C 329) mandates similar measures.

Anyfi.net technology aligns well with such legislation because a Radio never terminates traffic locally in the WTP but instead sends it through a Wi-Fi over IP tunnel to a TTP where traceability and lawful intercept capabilities are typically already in place as part of the Service. This architecture also effectively prevents cases of mistaken identity [6] or wrongful liability for third party copyright infringement [7].

 
2. Architecture

Anyfi.net partitions the IEEE 802.11 stack into three components: the Radio that handles the low level real-time aspects of the Wi-Fi protocol, a Service that implements the higher layers of the stack and a Controller that connects Radios and Services on demand. This architecture makes it possible to dynamically assemble complete Wi-Fi stacks that can provide exactly the network a mobile device is looking for.

Figure 2.1. Anyfi.net architecture overview.
2.1. The Radio permalink

A Radio has two main responsibilities: constantly monitoring the radio environment to detect when a mobile device comes within range and, when so instructed by the Controller, allocating Virtual BSSes for its preferred networks.

Figure 2.1.1. An Anyfi.net enabled access point serves as a remote radio head for mobile devices, while protecting the primary user's experience by prioritizing the local device.

The Radio handles the low level real-time critical aspects of the IEEE 802.11 protocol, e.g. sending acknowledgement frames and transmitting periodic beacons. The higher level MLME and data frames are instead encapsulated in UDP/IP datagrams and forwarded to the relevant Service. In this sense the Radio functions as a "dumb" radio relay — it simply forwards (often encrypted) IEEE 802.11 radio frames between its wired network interface and the Wi-Fi radio.

Adding Anyfi.net functionality to a public access point or residential gateway is a simple matter of a remote firmware update. The Anyfi.net radio software can of course also be factory installed e.g. in consumer Wi-Fi routers.

2.2. The Service permalink

The Service implements all the higher level functions of the IEEE 802.11 stack including authentication and encryption. This is essential for the Anyfi.net security model. All processing on Layer 3 and above also takes place here: IP address assignment, IP routing, etc. Essentially the Service defines every aspect of the end-user experience, except radio access.

Access to the Service is provided by a set of TTP, analogous to how a set of access points provide access to a physical network. But while APs send and receive IEEE 802.11 frames over a local radio a TTP sends and receives them on its wired network interface, encapsulated in UDP/IP datagrams.

Figure 2.2.1. Anyfi.net tunnel termination software embedded in an access point terminates Wi-Fi over IP tunnels coming in from multiple Radios.

Anyfi.net tunnel termination software can be deployed in residential gateways as a remote firmware update or pre-installed in consumer Wi-Fi routers. Once there it will allow mobile devices to connect to the local Wi-Fi network remotely, through any Radio. The software can also be integrated in special purpose tunnel termination gateways and service/access routers.

2.3. The Controller permalink

The Controller coordinates Radios and Services, connecting them to form complete IEEE 802.11 stacks on demand. It communicates with other network elements through a lightweight UDP/IP based control plane protocol in many ways similar to DNS.

In effect the user experience of mobile users is dictated by the instructions sent out to Radios and Services over the control plane; by simply configuring Anyfi.net software to use another Controller it's possible to create an entirely different user experience.

The Controller also collects accounting information, both from Radios and Services. This information can be used to clear roaming payments in some carrier Wi-Fi applications.

2.4. How it all fits together permalink

Let's go through a complete use-case and have a look at how the parts fit together.

For the purposes of this walk-through imagine you are a fixed-line broadband subscriber and your ISP has provided you with a Wi-Fi equipped residential gateway with integrated Anyfi.net software.

Figure 2.4.1. When a residential gateway with Anyfi.net software boots up it sends a registration message to the mobility control server.

When your residential gateway starts up the embedded tunnel termination software will send a registration message to the Controller containing a UUID identifying your home Wi-Fi network and a template that can be used to generate an IEEE 802.11 Beacon and Probe Response frames for this network. If this is the first time the mobility control server receives a registration message from your gateway it will create a database record to represent your network. It will also store the beacon template and make note of the source IP address and UDP port number of the registration message.

Figure 2.4.2. The first time a new device is connected to the residential gateway a message containing the MAC address of the device is sent to the Controller.

When you connect a new device to your home Wi-Fi network for the first time the tunnel termination software will send another message to the Controller, this time containing the MAC address of your device and the UUID identifying your home Wi-Fi Service. The Controller uses this information to create database records representing your device and your device's preference for your home Wi-Fi network.

Figure 2.4.3. When a Wi-Fi frame originating from that MAC address is detected elsewhere in the network the Controller will introduce the Radio to the relevant Service.

Now whenever you come close to a Radio, be it a public access point, residential gateway or consumer Wi-Fi router, your device will automatically connect to your home Wi-Fi exactly as if you were at home. To accomplish this feat the Radio must connect to the TTP in your home gateway to form a complete IEEE 802.11 stack, and the resulting Wi-Fi network must from your device's point of view be indistinguishable from your regular home Wi-Fi. Magical as it may sound it's really quite simple, and so quick that the device doesn't even notice.

First the Radio detects the presence of your device by intercepting a radio frame coming from it, most often a Probe Request frame. It then sends a small UDP/IP datagram to the Controller containing the MAC address of your device, in essence asking the server "do you know what network this device is looking for?" Since the mobility control server has a record of your device and its preference for your home Wi-Fi network it will reply with a message containing the IP address of your residential gateway, the UDP port number where the tunnel termination software can be reached and the beacon template that your residential gateway registered in the Controller. At the same time the Controller also sends an introduction message to your residential gateway.

Figure 2.4.4. Once the introduction has been made encrypted Wi-Fi over IP traffic flows directly between the client device and the tunnel termination software in your home gateway, using the visited Radio only as a relay.

The Radio uses the template to generate IEEE 802.11 Beacon and Probe Response frames that look similar to the ones normally coming from your residential gateway (only difference is that some radio specific Information Elements will instead describe the properties of the visited Radio). The moment your device detects the presence of your home Wi-Fi network it automatically connects, this time through a Wi-Fi over IP tunnel. Your device is authenticated using the standard WPA-PSK or WPA2-PSK security mechanism (depending on the settings on your residential gateway), in a 4-way handshake going all the way from your device to your residential gateway. The encryption keys for the connection are also derived only in these two places, ensuring that your communication is protected end-to-end all the way from your device to your own trusted residential gateway.

All this happens in a matter of milliseconds and the user experience is exactly what you are used to at home. You have full access to your local area network (LAN) in the home and if you access the Internet you do so using your own IP address.

The radio software in the visited access point and the tunnel termination software in your residential gateway will also send accounting information to the Controller.

2.5. The control plane permalink

The control plane connects Radios and (TTPs of) Services to the Controller through a light-weight UDP/IP protocol, in many ways similar to DNS. It is used to coordinate Radios and Services to form complete Wi-Fi stacks on demand.

2.5.1. Radio policy control

The control plane provides a mechanism for fine-grained radio policy control: each time the Controller sends message to a Radio instructing it to make a certain Wi-Fi network available to a certain mobile device it can also include a set of QoS requirements that must be met before the device is allowed to connect.

Requirements can refer to signal level as well as estimated available upstream/downstream bandwidth, taking both backhaul and spectrum into account. It is also possible to specify that the requirements must be met during a sufficiently long period of time (the "dwell time"), and that a mobile device should be disconnected if the quality of service falls below the required level after a connection has been established. Such radio policies can be controlled separately per mobile device, per Radio and per Wi-Fi network.

Some examples of functionality that can be implemented with the radio policy mechanism are provided below.

  1. Active QoE management

    It is possible to configure a minimum radio link quality that must be attained before a network is presented to the mobile device. This avoids the common problem of mobile devices switching over to a low quality Wi-Fi network when an alternative 3G or 4G connection is available.

    Since bandwidth estimates take traffic prioritization into account it also possible to avoid devices connecting to a WTP with insufficient spare backhaul or radio capacity. When the density of available WTPs is high this has the effect of guiding the devices network selection to where the most spare resources are available.

  2. Block service when close to the home Wi-Fi network

    There are cases when a device may roam onto a neighbouring WTP even though there is a direct radio link between the device and the TTP. The Controller can avoid this by sending out a radio policy requiring a very high quality signal to those Radios that are in the vicinity of the home Wi-Fi network.

  3. Block service when the device is highly mobile

    Wi-Fi is perfect for so-called nomadic use-cases, but less well adapted for truly mobile use-cases such as when the user is traveling in a car. The Controller can in these cases instruct the Radio to delay the presentation of highly mobile devices' preferred networks, in effect limiting service to more stationary use-cases.

  4. Band steering

    Band steering increases overall throughput by steering capable client devices from the 2.4 GHz band to the less crowded 5 GHz band. The Controller can trivially accomplish this by instructing Radios operating in the 2.4 GHz band to delay the presentation of the network when the request is coming from a 5 GHz capable device and there is a 5 GHz Radio within range.

  5. Graceful degradation under tunnel termination overload

    When many Wi-Fi over IP tunnels are terminated in a single location, e.g. a mobile network core, it is not uncommon that tunnel termination gateways and AAA-servers become overloaded. In a legacy Wi-Fi environment this would lead to long authentication delays and similar problems. With Anyfi.net it is possible to instead gradually increase minimum quality requirements until the back-end infrastructure is able to cope. This ensures the best use of network assets and maximizes quality of experience.

2.5.2. Just-in-time resource allocation

Anyfi.net protocols have been carefully designed to only allocate resources when they are actually needed. For example the Radio will delay the allocation of a new Virtual BSS until it is ready to send a Probe Response frame to a mobile device.

At this point the Wi-Fi over IP tunnel to the TTP is not yet established — tunnel setup is deferred until the device attempts to associate with the Virtual BSS. Resource deallocation follows a similar early release scheme.

This just-in-time resource allocation ensures that tunnel termination load scales with the number of mobile devices served, and not with the number of Radios in the network.

2.5.3. Load balancing

TTPs periodically send a load indication message to the Controller. When a single logical Wi-Fi network has multiple TTPs, as is common e.g. in mobile offload, the Controller can use this information to distribute the load equally between them. This makes it possible to scale tunnel termination to several hundred Gbps, and beyond.

2.5.4. Automatic failover

When multiple TTPs are used to the same Service this will also provide automatic failover. Should one TTP suffer a failure, the Radios connected to it will close the connection and deallocate their corresponding Virtual BSSes. When mobile devices reassociate to the network the Controller will introduce the Radio to another TTP. The end result is a glitch in connectivity that lasts less than a minute and only affects mobile devices that were served by the failing TTP at the time of the failure.

2.5.5. Link level accounting

One of the keys to improving the user experience in any radio access network is to understand what is happening on the radio link level. With Anyfi.net the Radio continuously sends accounting information to the Controller detailing all aspects of the radio link between the Radio and mobile devices. The table below lists some of the information collected.

Property Description
Signal Level The minimum, maximum and average received signal strength indication (RSSI) in dBm.
Data volume The number of bytes transferred downstream/upstream.
Actual Bandwidth The measured maximum downstream/upstream bandwidth actually attained.
Attainable Bandwidth The estimated maximum downstream/upstream attainable bandwidth, taking both spare backhaul and radio spectrum into account.
Packet Loss The average packet loss ratio on the Wi-Fi over IP connection from the TTP.
Diagnostics In the case of abnormal session termination accounting record will contain diagnostic information.
Table 2.5.5.1. Link properties estimated and reported by Radios.

In addition to this the tunnel termination software also reports some properties to the Controller. Some of this data is redundant, allowing the Controller to detect a WTP with modified radio software that is fraudulently reporting incorrect information. The table below details some of the properties reported by TTPs.

Property Description
Data volume The number of bytes transferred downstream/upstream.
Packet Loss The average packet loss ratio on the air interface and on the Wi-Fi over IP connection from the Radio.
Diagnostics In the case of abnormal session termination accounting record will contain diagnostic information.
Table 2.5.5.2. Link properties estimated and reported by TTPs.
2.5.6. NAT traversal

NAT traversal is an integral part of the design. Both Radios and TTPs can be deployed behind Network Address Translation (NAT) with so-called cone properties. In this configuration they will send periodic keep-alive messages to keep communication channels open and the Controller, acting as an introducer, will help them punch new holes through the NAT.

2.6. The user data plane permalink

The user data plane connects a Radio to a TTP of a Service through a Wi-Fi over IP tunnel.

Wi-Fi over IP in this case is not marketing speak — it describes the concrete implementation: IEEE 802.11 frames coming in on the radio are encapsulated in a thin UDP/IP header and sent out over the backhaul. In the opposite direction UDP/IP packets coming in over the backhaul connection carry IEEE 802.11 frames ready to be sent out over the radio.

Figure 2.6.1. Data plane when connected to a residential gateway or consumer Wi-Fi router.

When the tunnel termination software runs on a residential gateway or consumer Wi-Fi router the 4-way handshake goes all the way from the mobile device to the user's home, where the device is authenticated with the standard WPA/WPA2-PSK mechanism using the passphrase stored in the TTP. Since this passphrase was entered into the device (or transfered to the device using Wi-Fi Protected Setup) when it was first connected to the Wi-Fi network no user interaction is necessary for authentication, not even the first time a device connects through a Wi-Fi over IP tunnel. This is the property we refer to as ZERO sign-on. Also, since the passphrase is only available in the mobile device and at the TTP the mutual authentication property of the WPA-PSK security mechanism ensures that the end-user is in fact connected to their own network, and not to a rogue access point.

Figure 2.6.2. User data plane when connected to a tunnel termination gateway (TTG).

When the tunnel termination software runs on a tunnel termination gateway the standard WPA/WPA2 4-way handshake goes all the way from the mobile device to the tunnel termination gateway where the IEEE 802.1X authenticator verifies the identity of the subscriber using an EAP based security mechanism. This mechanism can be EAP-SIM, EAP-AKA, EAP-AKA' or any other supported by the AAA-server. Note that with this architecture the RADIUS interface is only used to connect the tunnel termination gateway to the AAA-server within a trusted network environment. This combined with the mutual authentication property of the security mechanism ensures that the end-user is in fact connected to their operator's network, and not to a rogue access point.

Figure 2.6.3. Swimlane illustration of the association and authentication process. Note that Anyfi.net software does not in any way alter this process, it merely tunnels the Wi-Fi frames over UDP/IP.

Since the 4-way handshake runs all the way from the mobile device to a TTP of the Service the encryption keys are also derived only in these two places. This architecture ensures user data integrity and data confidentiality end-to-end, all the way from the mobile device to the TTP. This is a key property underlying the security model.

2.6.1. Spectrum aware traffic prioritization

Anyfi.net software is designed to be integrated in Wi-Fi equipment that has a primary function and therefore goes great lengths to make sure that a mobile user does not negatively impact users of this primary function. It may seem that a simple fixed bandwidth limit for mobile devices would be sufficient for this purpose, but that is not the case. The average radio link tends to be quite poor for mobile devices and large amounts of radio spectrum can therefore be consumed by a mobile user even at modest throughput.

Unless radio resources are carefully managed a mobile device can severely impact the user experience of e.g. a residential subscriber even at low data rates. For example, it would not be uncommon for a mobile device to have such a low quality radio link that its maximum unthrottled throughput would be just 1 Mbps, or even less. A primary user of the same WTP, that normally enjoys throughput of up to 50 Mbps would then be severely impacted even if mobile bandwidth use is quite low. The table below provides some examples.

Mobile device throughput Potential impact on primary function of WTP
0.25 Mbps Max throughput decreases from 50 Mbps to 35 Mbps
0.5 Mbps Max throughput decreases from 50 Mbps to 18 Mbps
0.75 Mbps Max throughput decreases from 50 Mbps to 1 Mbps
Table 2.6.1.1. Mobile user throughput and impact on a residential subscriber without spectrum aware prioritization.

Root cause is an interaction between the IEEE 802.11 MAC layer and the TCP/IP stack: in combination they tend to distribute bandwidth between all users of the access point "fairly" — in the sense that each user gets approximately the same bandwidth. With the great variation in attainable bitrates between different devices this is however not an ideal definition of fairness as it tends to ensure an equally poor user experience for all users, even if there is just a single device in the network with a poor radio link.

Enterprise and carrier Wi-Fi vendors typically address this with a feature known as "airtime fairness", shifting the definition of fairness from equal bandwidth to equal radio time, i.e. spectrum use. This leads to a much improved average user experience.

Anyfi.net software goes one step beyond "airtime fairness" in three distinct ways. Firstly, it takes both radio spectrum and backhaul bandwidth into account.

Secondly, it prioritizes the primary function of the WTP, ensuring that e.g. a residential subscriber gets the airtime and backhaul bandwidth they need for a high quality user experience — before spare bandwidth and backhaul is distributed (fairly) among mobile users. In this sense the prioritization is very "unfair", to the advantage of primary users.

Lastly, it does so by actively throttling mobile devices. This means it prevents the packets of mobile devices from even reaching the device driver queues (of either the Wi-Fi radio or backhaul connection) if that could negatively impact a primary user. The throttling mechanism can therefore protect the primary function even if the backhaul lacks QoS functionality, or if the Wi-Fi driver manages its queues poorly (as is often the case). This method of actively throttling mobile users also protects the primary user's downstream WAN bandwidth, even if the queuing in this case is not in the WTP itself but rather in the broadband operator's network.

The result is the best possible mobile user experience with no impact to the primary function of the WTP. The table below provides some examples of such calculated bandwidth limits for the same example as in the table above.

Primary user throughput Mobile user throughput limit
0 Mbps No throttling of mobile user
0.1 Mbps Mobile user throttled to 0.5 Mbps
47 Mbps Mobile user throttled to 0.05 Mbps
Table 2.6.1.2. Primary bandwidth use and mobile device bandwidth limits with spectrum aware traffic prioritization.

Note that the spectrum aware traffic prioritization interacts with the radio policy control mechanism to make it possible to avoid that a mobile user connects through a WTP when there is not enough spare radio spectrum or backhaul bandwidth available to ensure a sufficient quality user experience.

This dynamic approach to traffic prioritization also removes the need to statically allocate a set amount of bandwidth to mobile users as is often done in community Wi-Fi type deployments. With Anyfi.net all available spare bandwidth becomes available for carrier Wi-Fi services, without impacting the user experience of residential subscribers.

2.6.2. Seamless handover

Handover from WTP to WTP is handled through the standard IEEE 802.11 mechanism, i.e. the mobile device periodically scans for new access points, and when appropriate will disassociate from its current access point and associate with a new one. It is however possible to restrict the mobile devices choice of WTP through the radio policy control mechanism, which in turn interacts with the spectrum aware traffic prioritization. This leads to a hybrid between client controlled and infrastructure controlled handover.

The Anyfi.net architecture where mobile data is always tunneled through a TTP aligns perfectly with the standard IEEE 802.11 mobility mechanism. Layer 2 connectivity is preserved during handover and Layer 3 connections are therefore unaffected. Since the IEEE 802.1X authenticator runs in the TTP the implementation of key caching and fast handover is greatly facilitated.

2.7. Traffic engineering considerations permalink

When a Wi-Fi over IP tunnel is terminated in on broadband subscriber's premises data needs to traverse the subscriber's home broadband connection twice. The reason is that the cryptographic key needed to encrypt and decrypt IEEE 802.11 frames to and from a mobile device is only available in the Service portion of the IEEE 802.11 stack in the subscribers own residential gateway or Wi-Fi router. This has strong benefits from a security point of view but may have some drawbacks from a traffic engineering perspective.

Figure 2.7.1. Temporal Key (TK) is normally only available in the client device and the TTP.

With most access network technologies this roundtrip to the subscriber's premises is all things considered acceptable, but there may be cases where the incentives to avoid the roundtrip are significant. For example, digital subscriber line technologies (xDSL) may constrain throughput in the uplink to less than 1 Mbps and since encrypted IEEE 802.11 frames destined for a mobile device will need to traverse the uplink this will limit the downstream throughput. Perhaps even more pressingly, in DOCSIS based access networks the total aggregate uplink capacity of a cable plant can be relatively low, and increasing this uplink capacity is already a major cost burden for operators.

This problem can however be solved by relaxing the security model in a careful and controlled manner. A novel network element, the Optimizer, is inserted in the communication path between the Radio and TTP. The Temporal Key (TK) used to encrypt and decrypt Unicast IEEE 802.11 data frames to and from the mobile device can then be transferred to the Optimizer and Internet-bound traffic can be broken out there.

Figure 2.7.2. The Optimizer is inserted into the communication path and the Temporal Key (TK) is transfered to this network element.

This requires that the Optimizer and the key transfer mechanism can be considered trustworthy from the Service's point of view. While this cannot be assumed in the general case there are some relevant special cases where this requirement can be met. Consider for instance the case where a DOCSIS operator has integrated Anyfi.net software in cable modems and is operating its own Controller. The end-subscriber can be assumed to trust the operator since the residential gateway firmware is operator managed. It would therefore be acceptable for the tunnel termination software in the residential gateway to transfer the Temporal Key (TK) to the operator controlled matchmaking service. The key can then be further transfered to the Optimizer which is also under the operators control.

Figure 2.7.3. With access to the Temporal Key (TK) the Optimizer break out Internet-bound traffic, thereby avoiding the roundtrip to the subscriber's home.

Once the key is in the Optimizer it is relatively trivial to implement central breakout of Internet-bound traffic. First all IEEE 802.11 unicast frames related to a mobile device is unencrypted using the Temporal Key (TK). The unencrypted IEEE 802.11 data frames coming from the mobile device are then filtered out and examined one at a time to determine if they should be targeted for central breakout. Broadcast frames can be simply forwarded to their intended destination.

IEEE 802.11 frames that have been targeted for breakout are decapsulated to expose the IP datagram, network address translated to appear to originate from the Optimizer and sent out on a public network interface. The network address translation in this case needs some extra consideration since many different mobile devices may have the same private IP address. Each Wi-Fi over IP tunnel that is relayed through the Optimizer therefore has its own NAT state using a subset of the IP addresses and port numbers assigned to the Optimizer.

When IP datagrams destined for the Optimizer arrive on the public network interface the NAT state tables are used to determine the relevant Wi-Fi over IP tunnel and the relevant mobile device's IP address. The IP datagram is then reverse network address translated, encapsulated as an IEEE 802.11 frame and injected into the traffic stream.

Remember that all IEEE 802.11 frames where unencrypted on receipt. This may seem unnecessary but is essential in order to inject frames originating from the public network interface into the traffic stream. The reason is that the encryption initialization vector (IV) must be adjusted or the frame will not be accepted by the mobile device. The last step is therefore to adjust the initialization vectors and re-encrypt all IEEE 802.11 frames with the Temporal Key (TK) (and for TKIP the Michael MIC Authenticator keys) before sending them on to their destination, i.e. the Radio where they will be transmitted or the TTP where they will be unencrypted and further processed by the networking stack in the residential gateway.

One of the advantages of this design is that the Radio need not be aware of the existence of the Optimizer. When the Controller responds to the connection request from the Radio it sends the Optimizer's IP address instead of the TTP's. Likewise, when the Controller sends the introduction message to the TTP it may send the Optimizer's IP address instead of the Radio's. The Optimizer is thus inserted in the communication path with minimum modification to the radio and tunnel termination software.

If the Optimizer fails or for some other reason becomes unavailable this will be detected by the Radio and TTP as a loss of network connectivity. After a short timeout they will attempt to reconnect and the Controller can opt to establish a direct connection between them.

 
3. Software integration

Anyfi.net software consists of the radio daemon anyfid and the tunnel termination daemon myfid.

On Linux platforms these are typically compiled to a multi-call binary to save flash memory. We make such Linux binaries available for a number of target platforms, see table below.

mips arm x86
uclibc 0.9.30 mips-linux-uclibc-0.9.30
mipsel-linux-uclibc-0.9.30
armeb-linux-uclibcgnueabi-0.9.30
arm-linux-uclibcgnueabi-0.9.30
i386-linux-uclibc-0.9.30
x86_64-linux-uclibc-0.9.30
uclibc 0.9.30.1 mips-linux-uclibc-0.9.30.1
mipsel-linux-uclibc-0.9.30.1
armeb-linux-uclibcgnueabi-0.9.30.1
arm-linux-uclibcgnueabi-0.9.30.1
i386-linux-uclibc-0.9.30.1
x86_64-linux-uclibc-0.9.30.1
uclibc 0.9.30.2 mips-linux-uclibc-0.9.30.2
mipsel-linux-uclibc-0.9.30.2
armeb-linux-uclibcgnueabi-0.9.30.2
arm-linux-uclibcgnueabi-0.9.30.2
i386-linux-uclibc-0.9.30.2
x86_64-linux-uclibc-0.9.30.2
uclibc 0.9.30.3 mips-linux-uclibc-0.9.30.3
mipsel-linux-uclibc-0.9.30.3
armeb-linux-uclibcgnueabi-0.9.30.3
arm-linux-uclibcgnueabi-0.9.30.3
i386-linux-uclibc-0.9.30.3
x86_64-linux-uclibc-0.9.30.3
uclibc 0.9.31 mips-linux-uclibc-0.9.31
mipsel-linux-uclibc-0.9.31
armeb-linux-uclibcgnueabi-0.9.31
arm-linux-uclibcgnueabi-0.9.31
i386-linux-uclibc-0.9.31
x86_64-linux-uclibc-0.9.31
uclibc 0.9.32 mips-linux-uclibc-0.9.32
mipsel-linux-uclibc-0.9.32
armeb-linux-uclibcgnueabi-0.9.32
arm-linux-uclibcgnueabi-0.9.32
i386-linux-uclibc-0.9.32
x86_64-linux-uclibc-0.9.32
uclibc 0.9.32.1 mips-linux-uclibc-0.9.32.1
mipsel-linux-uclibc-0.9.32.1
armeb-linux-uclibcgnueabi-0.9.32.1
arm-linux-uclibcgnueabi-0.9.32.1
i386-linux-uclibc-0.9.32.1
x86_64-linux-uclibc-0.9.32.1
uclibc 0.9.33 mips-linux-uclibc-0.9.33
mipsel-linux-uclibc-0.9.33
armeb-linux-uclibcgnueabi-0.9.33
arm-linux-uclibcgnueabi-0.9.33
i386-linux-uclibc-0.9.33
x86_64-linux-uclibc-0.9.33
uclibc 0.9.33.1 mips-linux-uclibc-0.9.33.1
mipsel-linux-uclibc-0.9.33.1
armeb-linux-uclibcgnueabi-0.9.33.1
arm-linux-uclibcgnueabi-0.9.33.1
i386-linux-uclibc-0.9.33.1
x86_64-linux-uclibc-0.9.33.1
uclibc 0.9.33.2 mips-linux-uclibc-0.9.33.2
mipsel-linux-uclibc-0.9.33.2
armeb-linux-uclibcgnueabi-0.9.33.2
arm-linux-uclibcgnueabi-0.9.33.2
i386-linux-uclibc-0.9.33.2
x86_64-linux-uclibc-0.9.33.2
glibc 2.8 mips-linux-gnu-2.8
mipsel-linux-gnu-2.8
armeb-linux-gnueabi-2.8
arm-linux-gnueabi-2.8
i386-linux-gnu-2.8
x86_64-linux-gnu-2.8
glibc 2.9 mips-linux-gnu-2.9
mipsel-linux-gnu-2.9
armeb-linux-gnueabi-2.9
arm-linux-gnueabi-2.9
i386-linux-gnu-2.9
x86_64-linux-gnu-2.9
glibc 2.10.1 mips-linux-gnu-2.10.1
mipsel-linux-gnu-2.10.1
armeb-linux-gnueabi-2.10.1
arm-linux-gnueabi-2.10.1
i386-linux-gnu-2.10.1
x86_64-linux-gnu-2.10.1
glibc 2.11 mips-linux-gnu-2.11
mipsel-linux-gnu-2.11
armeb-linux-gnueabi-2.11
arm-linux-gnueabi-2.11
i386-linux-gnu-2.11
x86_64-linux-gnu-2.11
glibc 2.11.1 mips-linux-gnu-2.11.1
mipsel-linux-gnu-2.11.1
armeb-linux-gnueabi-2.11.1
arm-linux-gnueabi-2.11.1
i386-linux-gnu-2.11.1
x86_64-linux-gnu-2.11.1
glibc 2.12.1 mips-linux-gnu-2.12.1
mipsel-linux-gnu-2.12.1
armeb-linux-gnueabi-2.12.1
arm-linux-gnueabi-2.12.1
i386-linux-gnu-2.12.1
x86_64-linux-gnu-2.12.1
glibc 2.12.2 mips-linux-gnu-2.12.2
mipsel-linux-gnu-2.12.2
armeb-linux-gnueabi-2.12.2
arm-linux-gnueabi-2.12.2
i386-linux-gnu-2.12.2
x86_64-linux-gnu-2.12.2
glibc 2.13 mips-linux-gnu-2.13
mipsel-linux-gnu-2.13
armeb-linux-gnueabi-2.13
arm-linux-gnueabi-2.13
i386-linux-gnu-2.13
x86_64-linux-gnu-2.13
glibc 2.14 mips-linux-gnu-2.14
mipsel-linux-gnu-2.14
armeb-linux-gnueabi-2.14
arm-linux-gnueabi-2.14
i386-linux-gnu-2.14
x86_64-linux-gnu-2.14
glibc 2.14.1 mips-linux-gnu-2.14.1
mipsel-linux-gnu-2.14.1
armeb-linux-gnueabi-2.14.1
arm-linux-gnueabi-2.14.1
i386-linux-gnu-2.14.1
x86_64-linux-gnu-2.14.1
glibc 2.15 mips-linux-gnu-2.15
mipsel-linux-gnu-2.15
armeb-linux-gnueabi-2.15
arm-linux-gnueabi-2.15
i386-linux-gnu-2.15
x86_64-linux-gnu-2.15
glibc 2.16.0 mips-linux-gnu-2.16.0
mipsel-linux-gnu-2.16.0
armeb-linux-gnueabi-2.16.0
arm-linux-gnueabi-2.16.0
i386-linux-gnu-2.16.0
x86_64-linux-gnu-2.16.0
glibc 2.17 mips-linux-gnu-2.17
mipsel-linux-gnu-2.17
armeb-linux-gnueabi-2.17
arm-linux-gnueabi-2.17
i386-linux-gnu-2.17
x86_64-linux-gnu-2.17
Table 3.1. Latest release of Anyfi.net software pre-built for a number of platforms. If you need software for another platform contact support@anyfi.net.

Note that the download links follow a specific pattern based on the GNU target name. This makes it easy to download Anyfi.net software pre-built for your cpu and software environment, even if your build system builds firmware for multiple platforms.

ANYFI_VERSION  := 1.1.0
ANYFI_TARGET   := $(ARCH)-$(OS)-$(LIBC)-$(LIBCV)
ANYFI_ARCHIVE  := anyfimac-$(ANYFI_VERSION)-$(ANYFI_TARGET).tar.bz2
ANYFI_BASE_URL := https://anyfi.net/download

$(ANYFI_ARCHIVE):
    wget $(ANYFI_BASE_URL)/$@
Example 3.1. Makefile that downloads Anyfi.net software pre-built for a particular platform.

Anyfi.net software is also available under separately negotiated license terms, both in source code and binary form. Please contact license@anyfi.net for more information.

This chapter details how to integrate this software in the firmware image of a public access point, residential gateway, consumer Wi-Fi router or tunnel termination gateway (TTG). Detailed step-by-step integration instructions are also separately available in the form of an Integration Guide. If you prefer learning by example have a look at the reference integration for CarrierWrt, an OpenWrt overlay.

3.1. Radio software permalink

The radio software consists of the user space daemon anyfid and its associated control command anyfidctl.

Figure 3.1.1. Anyfi.net radio software integrated in a Linux based residential gateway.

In this section we detail the requirements and impact of this software on the target system and outline how to integrate the software in a firmware image.

3.1.1. Wi-Fi chipset and driver requirements

In order to function as a Radio in the SDWN architecture the Wi-Fi chipset must have a software defined IEEE 802.11 Media Access Control (MAC) layer and support for multiple BSSIDs. Modern chipsets from most vendors meet this requirement.

The Wi-Fi driver must also support a low level interface so that Anyfi.net software can monitor the radio environment to detect the presence of a mobile device as well as send and receive raw encrypted IEEE 802.11 frames. The modern Linux Wi-Fi driver architecture (mac80211) supports this interface out of the box while older proprietary drivers may require some modification as part of the integration process.

Modifications for drivers from Broadcom Corporation, Ralink Technology Corporation, Qualcomm Atheros and Realtek Semiconductor Corporation are available to authorized licensees of these companies. Please contact us for more information.

3.1.2. Memory requirements and impact

Anyfi.net software (both radio and tunnel termination daemons compiled into a multi-call binary) is approximately 530 KB in size uncompressed. After compression (e.g. as part of a squashfs firmware image) it will consume less than 200 KB of flash memory. No data needs to be read or written to flash during the operation of the system.

The radio daemon will allocate some memory on the heap, primarily for caching and throttling buffers. Heap allocation is typically restricted to no more than 500 KB, but can be substantially reduced by adjusting buffer sizes if required.

3.1.3. CPU requirements and impact

The processing done by the radio daemon anyfid is very lightweight but nonetheless consumes CPU cycles, mostly for examining, copying and forwarding IEEE 802.11 frames. When no mobile clients are connected through the local radio this utilization should be minimal (below 5%) on a modern embedded CPU. When a mobile client is transferring data this CPU utilization can increase to 5 – 40% depending on throughput and CPU performance. The CPU load is largely independent on the number of connected mobile devices or the number of remote Wi-Fi networks accessed.

3.1.4. System software dependencies

Anyfi.net software is implemented in ISO C and easily portable across a number of embedded operating systems. The radio portion of the software has only relatively trivial operating system dependencies: memory allocation, file access, signals, DNS resolution, UDP/IP networking, etc. These are easily met by the Linux operating system, even with a minimal C library like uClibc. For other operating systems a minimal porting layer may be necessary.

3.1.5. Configuration parameters

The Anyfi.net radio daemon (anyfid) takes some arguments that may be exposed as configuration parameters.

Parameter Example Description
controller demo.anyfi.net FQDN or IP address of the Controller.
floor 10 The percentage of available spectrum and backhaul that anyfid will let mobile users consume even if there is competition with the primary user (default 5%).
ceiling 90 The maximum percentage of available spectrum and backhaul that anyfid will let mobile users consume (default 75%).
uplink 1048576 An estimate of the total upstream bandwidth available on the WAN connection, in bits per second.
downlink 8388608 An estimate of the total downstream bandwidth available on the WAN connection, in bits per second.
port N/A The local UDP port that anyfid should use for all communication with the outside world.
Table 3.1.5.1. Anyfi.net radio software configuration parameters.

Note that uplink and downlink can often be estimated by integration scripts, e.g. based on the sync rate of an xDSL WAN connection. If they are not specified or estimated by the integration anyfid will make a measurement against the nearest IP gateway using ICMP echo request (ping).

Whether or not to expose these configuration parameters through configuration interfaces (TR-069, WEBUI, etc.) depends on the type of equipment you are integrating in. See recommendations for public access points, residential gateways and consumer Wi-Fi routers.

3.1.6. Firmware integration

The radio daemon anyfid should be installed alongside other system daemons and started once the primary BSS of the access point is operational.

First a monitor interface and a pool of virtual access point interfaces must be created. The radio daemon anyfid will use the monitor interface to monitor the radio environment, and dynamically allocate BSSes from the pool as devices come into range. Interface creation is driver dependent, but we assume here that the monitor interface is named "monitor0" and that the pool consists of "anyfi0", "anyfi1", "anyfi2", and "anyfi3".

Then the daemon is then started with the following command:

anyfid --accept-license -c demo.anyfi.net -B -P /var/run/anyfid.pid monitor0 anyfi0/4
Example 3.1.6.1. Start anyfid in the background.

The -c flag tells anyfid which Controller to register with and receive its instructions from. The -B flag specifies that the daemon should run in the background. The -P flag instructs anyfid to create a file containing its process ID number (PID). The first non-flag argument is the monitor interface, followed by all virtual access point interfaces available to serve mobile devices.

To stop anyfid you send the TERM signal to its PID. On a Linux system that would be done with kill, as below.

kill –TERM $(cat /var/run/anyfid.pid)
Example 3.1.6.2. Stop anyfid with the TERM signal.

The PID file will be removed by anyfid as part of its cleanup and exit.

Whenever the Wi-Fi settings are changed, e.g. when changing the channel, anyfid must be restarted. Do this by stopping the daemon with the TERM signal and starting it again.

3.2. Tunnel termination software permalink

The tunnel termination software consists of the user space daemon myfid and its associated control command executable myfidctl.

Figure 3.2.1. Anyfi.net tunnel termination software integrated in a Linux based residential gateway.

Equipment with Anyfi.net tunnel termination software integrated can serve as a Tunnel Termination Point (TTP) of a Service, terminating Wi-Fi over IP tunnels coming in over the network from remote Radios. The tunnel termination software implements all the higher level functions of an IEEE 802.11 stack including authentication and encryption, effectively serving as the termination point for the IEEE 802.11 protocol. This extension of the IEEE 802.11 security mechanism over the wired network is key to the security model.

In this section we detail the requirements and impact of this software on the target system and outline how to integrate the software in a firmware image.

3.2.1. Memory requirements and impact

Anyfi.net software (both radio and tunnel termination daemons compiled into a multi-call binary) is approximately 530 KB in size uncompressed. After compression (e.g. as part of a squashfs firmware image) it will consume approximately 200 KB of flash memory. No data needs to be read or written to flash during the operation of the system.

The Anyfi.net tunnel termination daemon (myfid) will typically allocate very little memory on the heap: on the order of 10 KB per Wi-Fi over IP tunnel. A typical residential gateway will rarely terminate more than a handful of tunnels at any one time, so memory allocation in this environment is negligible.

3.2.2. CPU requirements and impact

Frame processing on the tunnel termination side requires significantly more CPU resources than on the radio side. The reason is that IEEE 802.11 frames are typically encrypted and decrypted in software inside myfid (since the hardware AES/RC4 implementation in the Wi-Fi chipset cannot easily be used to encrypt or decrypt a frame sent or received over IP). A modern CPU (e.g. 400 Mhz MIPS 24Kc) can perform AES encryption or decryption at a rate of about 10 Mbps. This often sets the upper limit for the throughput of a mobile device. The CPU load is largely independent of the number of separate Wi-Fi over IP tunnels being terminated and instead varies more or less linearly with aggregate throughput.

On systems with general purpose AES hardware it is of course possible to accelerate frame processing. Our standard software supports the Linux /dev/crypto interface. Support for other hardware acceleration mechanisms may require source code modification. Anyfi Networks provides software engineering services for this and other purposes.

3.2.3. System software dependencies

Anyfi.net software is implemented in ISO C and easily portable across a number of embedded operating systems. Operating system dependencies are for the most part relatively trivial: memory allocation, file access, DNS resolution, UDP/IP networking, signals and similar usually met by a subset of the POSIX API.

In addition to this the tunnel termination software also depends on system software for Ethernet bridging. On Linux systems these dependencies are often resolved against the kernel tun/tap interface functionality. This requires that the Linux kernel be built with the CONFIG_TUN configuration flag.

3.2.4. Configuration parameters

The Anyfi.net tunnel termination daemon (myfid) takes some parameters that may be exposed as configuration parameters.

Parameter Example Description
controller demo.anyfi.net FQDN or IP address of the Controller.
port N/A Optionally, the local UDP port that myfid should use for all communication.
Table 3.2.4.1. Anyfi.net tunnel termination software configuration parameters.

Whether or not to expose these configuration parameters through configuration interfaces (TR-069, WEBUI, etc.) depends on the type of equipment you are integrating in. See recommendations for residential gateways, consumer Wi-Fi routers and tunnel termination gateways.

3.2.5. Firmware integration

The Anyfi.net tunnel termination daemon myfid should be installed alongside other system daemons and started once the Primary BSS of the access point is operational (or simply at system startup in the case of a tunnel termination gateway).

The Anyfi.net tunnel termination daemon (myfid) uses a configuration file to permanently store some parts of its configuration. We assume that the interface associated with the Primary BSS is named "wlan0". An example of a typical configuration file is provided below.

# Configuration file for myfid - Anyfi.net tunnel termination daemon.
#
# All mandatory settings have example values that should be changed.
# Optional settings are marked with "optional" and have their default values.

# Bridge interface to use for client traffic.
bridge = br0

# The AP interface for the local Wi-Fi network (optional).
local_ap =

# The ESS identifier, aka SSID.
ssid = 'Example SSID'

# The universally unique identifier (UUID) for the ESS (optional).
uuid =

# The WPA/RSN authentication protocol(s) to use:
# open     Open network, i.e. no authentication or encryption
# wpa      Use Wi-Fi Alliance WPA
# rsn      Use IEEE 802.11 RSN, aka WPA2
# wpa+rsn  Use both WPA and RSN.
auth_proto = wpa+rsn

# The WPA/RSN authentication mode to use (WPA/RSN only):
# psk      Use IEEE 802.11 pre-shared key (PSK) authentication
# eap      Use IEEE 802.1X/EAP authentication.
auth_mode = psk

# The WPA cipher suites supported (optional):
# tkip       Support only the TKIP cipher
# ccmp       Support only the CCMP (AES) cipher
# tkip+ccmp  Support both TKIP and CCMP ciphers.
wpa_ciphers = tkip

# The RSN cipher suites supported (optional):
# tkip       Support only the TKIP cipher
# ccmp       Support only the CCMP (AES) cipher
# tkip+ccmp  Support both TKIP and CCMP ciphers.
rsn_ciphers = ccmp

# Group key (GMK) rekey period in seconds (optional).
group_rekey = 3600

# Strict GTK rekeying on/off (optional).
strict_rekey = 0

# Passphrase for deriving the pre-shared key (PSK only).
passphrase = 'secret passphrase'

# RADIUS authentication server IP address (802.1X/EAP only)
radius_auth_server =

# RADIUS authentication server port (802.1X/EAP only, optional)
radius_auth_port = 1812

# RADIUS authentication server shared secret (802.1X/EAP only)
radius_auth_secret = 'shared secret'

# RADIUS authorization server IP address (optional)
radius_autz_server =

# RADIUS authorization server port (optional)
radius_autz_port = 1812

# RADIUS authorization server shared secret (optional)
radius_autz_secret = 'shared secret'

# RADIUS accounting server IP address (optional)
radius_acct_server =

# RADIUS accounting server port (optional)
radius_acct_port = 1813

# RADIUS accounting server shared secret (optional)
radius_acct_secret = 'shared secret'

# RADIUS secondary accounting server IP address (optional)
radius_acct2_server =

# RADIUS secondary accounting server port (optional)
radius_acct2_port = 1813

# RADIUS secondary accounting server shared secret (optional)
radius_acct2_secret = 'shared secret'

# RADIUS client NAS-Identifier string (optional)
radius_nas_id =

# RADIUS client interface name (optional)
radius_nas_iface =

# RADIUS client UDP port (optional)
radius_nas_port =
Example 3.2.5.1. A typical myfid.conf file.

Once a configuration file has been generated myfid can be started as follows:

myfid --accept-license -c demo.anyfi.net -B -P /var/run/myfid.pid /etc/myfid.conf
Example 3.2.5.2. Start the myfid tunnel termination daemon.

Like anyfid, myfid accepts the -P flag to specify a custom PID file path and the -c flag to specify the Controller it should register with and receive its instructions from.

The Anyfi.net tunnel termination daemon (myfid) will monitor the bridge and access point interfaces to detect new devices connecting locally. When a new device connects myfid will inform the Controller of this fact, allowing it to create a database record encoding the device's preference for the Service that this instance of myfid provides access to. It is possible to remove all these associations by passing the -r (or --reset) flag to myfid when it is started. We recommend that the integration does this whenever the passphrase is changed, or there is some other indication that previously connected devices should no-longer have access to the network. Note however that this is not necessary for security reasons — access to the network is at all times protected with the standard Wi-Fi security mechanism.

Stop myfid by sending the TERM signal to its PID.

kill –TERM $(cat /var/run/myfid.pid)
Example 3.2.5.3. Stop myfid with the TERM signal.

It is advisable to restart the myfid daemon whenever the Wi-Fi settings are changed. Do this by stopping the daemon with the TERM signal and starting it again.

3.3. Public access point integration permalink

Public access point vendors only need to integrate the radio daemon anyfid.

Off-the-shelf integrations for reference designs from Broadcom Corporation, Ralink Technology Corporation and Qualcomm Atheros are available to authorized licensees. Integration on one of these platforms should take no more than a man-week. Anyfi Networks can provide professional software engineering services to perform or assist in integration.

3.3.1. Licensing options

Anyfi.net software is available to all vendors under a no-charge royalty-free license, along with detailed step-by-step integration instructions as part of our Integration Guide.

For full source code or professionally supported licenses please contact license@anyfi.net.

3.3.2. Configuration interface

The recommended configuration interface for public access points allows the operator to configure at least the 'controller', 'floor' and 'ceiling' configuration variables.

Carrierwrt-ap Figure 3.1. Example web configuration interface for a public access point.
3.3.3. Remote firmware update

Most public access point systems have remote firmware update capability. In most cases it should be possible to flash a firmware image incorporating Anyfi.net software into existing public access points at a zero CapEx.

3.4. Residential gateway integration permalink

Residential gateway vendors should integrate both the radio and the tunnel termination software.

Some use-cases, most notably mobile Wi-Fi offload, however only requires the radio software to be operated. When this is the operator's only requirement it is possible to conserve (approximately 100 KB of) flash memory by integrating only radio portion of the software.

Off-the-shelf integrations for reference designs from Broadcom Corporation, Ralink Technology Corporation, Qualcomm Atheros and Realtek Semiconductor Corporation are available to authorized licensees. Integration on one of these platforms should take no more than a man-week. Anyfi Networks can provide professional software engineering services to perform or assist in integration.

3.4.1. Licensing options

Anyfi.net software is available to all vendors under a no-charge royalty-free license, along with detailed step-by-step integration instructions as part of our Integration Guide.

For full source code or professionally supported licenses please contact license@anyfi.net.

3.4.2. Configuration interface

The recommended configuration interface for residential gateway allows the operator to configure at the 'controller', 'floor' and 'ceiling' configuration variables through TR-069. The end-subscribers should only be allowed to opt-out of the service, by checking a single check-box.

Carrierwrt-rgw Figure 3.2. Example "single checkbox" web configuration interface for a residential gateway.
3.4.3. Remote firmware update

Most residential gateway platforms support remote firmware updates and most operators have processes in place for this. In most cases it should be possible to flash a firmware image incorporating Anyfi.net software into existing residential gateways at a zero CapEx.

3.5. Consumer Wi-Fi router integration permalink

Consumer Wi-Fi router vendors should integrate both the radio and the tunnel termination software.

Off-the-shelf integrations for reference designs from Broadcom Corporation, Ralink Technology Corporation, Qualcomm Atheros and Realtek Semiconductor Corporation are available to authorized licensees. Integration on one of these platforms should take no more than a man-week. Anyfi Networks can provide professional software engineering services to perform or assist in integration.

3.5.1. Licensing options

Anyfi.net software is available to all vendors under a no-charge royalty-free license, along with detailed step-by-step integration instructions as part of our Integration Guide.

For full source code or professionally supported licenses please contact license@anyfi.net.

3.5.2. Configuration interface

The recommended configuration interface for a consumer Wi-Fi router simply allows the end-user to switch the functionality on or off, by toggling a single check-box.

Carrierwrt-router Figure 3.3. Example "single checkbox" web configuration interface for a consumer Wi-Fi router.
3.5.3. Remote firmware update

Most consumer Wi-Fi routers do not have support for automated firmware updates. To the extent that Anyfi.net software can be deployed electronically it will depend on manual firmware updates by end-users.

3.6. Tunnel termination gateway integration permalink

A tunnel termination gateway, as the name implies, should only support tunnel termination functionality functionality acting as a gateway to a Service. The configuration interface needs to allow adjustment of the standard Wi-Fi network settings, e.g. SSID, security mechanism, encryption algorithms and RADIUS servers.

3.6.1. Hardware crypto acceleration

Encryption and decryption of IEEE 802.11 frames can easily become a computational bottleneck on general purpose CPUs. AES-128 encryption hardware is therefore essential for high throughput applications. Anyfi.net software has built-in support for AES-NI and Cavium Octeon AES instructions, and can also leverage the Linux kernel /dev/crypto API for hardware acceleration.

3.6.2. Licensing options

Anyfi.net software is available to all vendors under a no-charge royalty-free license, along with detailed step-by-step integration instructions as part of our Integration Guide.

Anyfi Networks licenses high performance alternative implementations separately for use in tunnel termination gateways and service/access routers. Please contact info@anyfinetworks.com to discuss licensing options.

3.6.3. Configuration interface

The configuration interface of a tunnel termination gateway should allow the operator to configure the complete set of Wi-Fi network properties that go into the myfid.conf configuration file.

Carrierwrt-appliance Figure 3.4. Example command line configuration interface for a tunnel termination gateway.