Table of Contents

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.

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.

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.

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.

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.

A tunnel termination gateway (TTG) 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. In the most common case a TTG is implemented in software running on blade hardware conforming to a standard form factor, e.g. AdvancedTCA, but it can also be implemented using special purpose hardware or even as a so-called virtual appliance, e.g. a VMware image.

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.

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. Note though that while SSIDs should be locally unique they cannot be relied on as a globally unique identifier; there can be networks with the same SSID elsewhere in the world.

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.

There is a one-to-one relationship between WTPs and radio front-ends. The difference is that WTP is used to refer to the physical device whereas radio front-end refers to the abstract architectural element.

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.

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 front-end 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 simultaneously active Virtual BSSes, each terminated in a separate TTP.

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

In this case as well there is a one-to-one relationship between TTPs and tunnel termination back-ends. The difference is that TTP is used to refer to the physical device whereas tunnel termination back-end refers to the abstract architectural element.

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 [1].

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 [2].

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 technology makes it possible to create ZERO sign-on services, i.e. services that require no special software on the device, or manual registration process, but still provides "no touch" authentication even the first time a user connects.

The WPA/WPA2 security protocol are commonly used to secure the air interface of Wi-Fi systems. With Anyfi.net this protocol is extended over the backhaul as well and terminated in a tunnel termination back-end. This leads to a greatly simplified security model with strong and verifiable guarantees for user plane data integrity and privacy.

An access point with Anyfi.net support often has another primary function: it may e.g. serve 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.

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 the passphrase must be protected. In a WPA/WPA2 Enterprise context it means ensuring that no untrusted entity has access to the RADIUS interface.

Anyfi.net software goes to great lengths to protect 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 tunnel termination gateway (TTG) which can be physically secured.

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. Anyfi.net technology in contrast encrypts the connection end-to-end, all the way from the mobile device to the tunnel termination point (TTP), using the standard IEEE 802.11i AES or TKIP encryption. The encryption keys are derived in the mobile device and at the tunnel termination point (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.

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 technology rests firmly on the tested and proven WPA/WPA2 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 tunnel termination back-end 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 the IEEE 802.11 subsystem against such attacks.

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

Man-in-the-middle attacks are much 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 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 [4] and we do not consider that a significant threat in practice.

The control plane provides a mechanism for fine-grained control of network visibility. Visibility decisions can be made both on a per mobile device and per radio front-end basis, by simply choosing when to present a network to a mobile device.

A decision to present a network is encoded by the matchmaking service as a network visibility policy and sent to the radio front-end in a UDP packet. The front-end then matches the estimated properties of a hypothetical future connection against the policy to decide if to allocate a virtual BSS on the Wireless Termination Point or not. The network visibility policy can e.g. contain a minimum signal level threshold and thresholds for the estimated upstream and downstream capacities of a connection (taking both spare backhaul and radio spectrum into account).

Some examples of functionality that can be accomplished by selectively presenting networks 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 with alternate access methods switching over to a low quality Wi-Fi network.

   It is also possible to consider the Wireless Termination Point's available spare capacity, radio spectrum and backhaul, and only making the mobile devices preferred network available if these spare resources are adequate for a high quality user experience.

2. Block service when in the vicinity of the home Wi-Fi network

   There are cases when a device may roam onto a neighbouring Wireless Termination Point (WTP) even though there is a direct radio link between the device and the Tunnel Termination Point (TTP). Anyfi.net tunnel termination back-end software implements some functionality to avoid this; specifically refusing to communicate with a mobile device through a Wi-Fi over IP tunnel if the same device can be heard on the local radio.

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 cloud-based matchmaking service can in these cases instruct the radio front-end to delay the presentation of highly mobile devices' preferred networks, in effect limiting service to stationary or nomadic 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.8 GHz band. The cloud-based matchmaking service can trivially accomplish this by instructing radio front-ends operating in the 2.4 GHz band to delay the presentation of the network when the request is coming from a 5.8 GHz capable device and there is a 5.8 GHz radio front-end within range.

5. Graceful degradation under tunnel termination overload

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

The tunnel termination back-end may also update the visibility policy employed by a radio front-end to which it is directly connected. This is useful when suppressing remote connections if the device is in close proximity to the home Wi-Fi network.

The Anyfi.net technology and protocols have been carefully designed to only allocate resources when they are actually needed. The radio front-end will only allocate a new Virtual BSS if there is a device that needs to be served through an already allocated Virtual BSS. It will then set up a beacon and answer probe requests based on the beacon template provided by the matchmaking service.

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

This just-in-time resource allocation scheme ensures that tunnel termination back-end load scales with the number of mobile devices served, and not with the number of radio front-ends in the network.

Tunnel termination back-ends periodically send a load indication message to the cloud-based matchmaking service. This load indication can be used to limit the rate of new tunnels to the back-end. When the tunnel termination resources of a virtual Wi-Fi network become overloaded the matchmaking service will prioritize tunnels originating from access points with a high quality radio link to the mobile device, thereby ensuring that available resources are used to maximum possible benefit.

Several tunnel termination back-ends may also be configured with identical Service UUID and Wi-Fi network properties. In this case the matchmaking service will automatically distribute Wi-Fi over IP connections across available back-ends. This mechanism can be used to load balance across several tunnel termination gateways.

If multiple tunnel termination back-ends are used to terminate the same Wi-Fi network this will also provide redundancy and automatic failover. Should tunnel termination gateway suffer a failure, the radio front-ends connected to it will close the connection and deallocate their corresponding virtual BSSes. When a mobile device reassociates to the network the matchmaking service will introduce the radio front-end to a tunnel termination back-end running on another tunnel termination gateway. The end result is a glitch in connectivity that lasts less than a minute and it only affects the STAs that were served by the failing tunnel termination gateway.

NAT traversal is an integral part of the design. Both the radio front-end and the tunnel termination back-end software can be deployed behind Network Address Translation (NAT) with so-called cone properties.

It may seem that a simple fixed bandwidth limit for mobile devices would be sufficient but this is unfortunately not the case. The average radio link quality for mobile devices tend to be quite low and large amounts of spectrum are therefore consumed even at modest throughput. Unless radio resources are carefully managed a mobile device can severely impact the user experience of 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 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.

Anyfi.net software takes both backhaul and spectrum use into account and recalculates bandwidth limits for mobile STAs many times per minute. 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.

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. It is however possible to restrict the mobile devices choice of WTP through the network visibility control mechanism. This leads to a hybrid between client controlled and infrastructure controlled handover.

The Anyfi.net architecture where mobile data is always tunneled through a tunnel termination back-end 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 tunnel termination back-end the implementation of key caching and fast handover is greatly facilitated.

In order to function as a radio front-end 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.

Driver modifications for chipsets from Broadcom Corporation, Ralink Technology Corporation and Qualcomm Atheros are available as part of our reference integrations.

The Anyfi.net radio front-end daemon is approximately 100 KB in size uncompressed. After compression (e.g. as part of a squashfs firmware image) it will consume approximately 40 KB of Flash memory. No data needs to be read or written to Flash during the operation of the system.

In its standard configuration the radio front-end daemon will use approximately 1 MB of RAM memory when idle and up to 2 MB at maximum throughput. Most of this memory is used for caching and throttling buffers. Memory use can be reduced substantially by reducing cache and buffer sizes if required.

The processing done by the radio front-end 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 20 – 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.

The radio front-end portion of Anyfi.net software has only relatively trivial operating system dependencies: memory allocation, file access, signals, etc.

The front-end daemon anyfid should be installed alongside other system daemons and started once the primary BSS of the access point is operational. Run the daemon with the following command:

anyfid --accept-license -B monitor0 -P /var/run/anyfid.pid

The -B flag specifies that the daemon should run in the background. The -P file instructs anyfid to create a file containing its process ID number (PID).

The --account command line option can be used to tie this radio to a platform Account.

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

kill –TERM $(cat /var/run/anyfid.pid)

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 number, anyfid must be restarted. Do this by stopping the daemon with the TERM signal and starting it again.

The Anyfi.net tunnel termination back-end daemon (myfid) is approximately 300 KB in size uncompressed. After compression (e.g. as part of a squashfs firmware image) it will consume approximately 150 KB of Flash memory. No data needs to be read or written to flash during the operation of the system.

The tunnel termination back-end portion of the software will use very little RAM, usually in the range 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.

Frame processing on the tunnel termination back-end side requires significantly more CPU resources than on the front-end. The reason is that IEEE 802.11 frames are encrypted and decrypted in software on the back-end (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 approximately linearly with aggregate throughput.

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, sockets, signals and similar usually met by a subset of the POSIX API.

In addition to this the tunnel termination back-end 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 following configuration flags:

• CONFIG_TUN

The tunnel termination back-end daemon myfid (or the multi-call binary anyfimac) should be installed alongside other system daemons and started once the primary BSS of the access point is operational.

We assume below that the interface associated with the primary BSS is named "ap0" and that a monitor interface "monitor0" receives frames on the same radio.

myfid -B -i ap0 –m monitor0 br-lan /var/run/ap0.conf

Like anyfid, myfid accepts the -P flag to specify a custom PID file path. Stop myfid by sending the TERM signal to its PID.

The -i command line argument specifies a Primary BSS that should be monitored for new devices connecting. When a new device is detected myfid will instruct the matchmaking server to create a Binding so that the device can connect to this network when mobile. We say that the client is auto-bound to the network. It is possible to remove all these bindings 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.

The --account command line argument can optionally be used to tie this service to a platform Account.

kill –TERM $(cat /var/run/myfid.pid)

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.

The Anyfi.net radio front-end software is available to all under a no-charge royalty-free license.

Most public access point systems have remote firmware update capability. It should be possible to flash a firmware image incorporating Anyfi.net software into existing public access points at zero CAPEX.

Anyfi.net software is available to all under a no-charge royalty-free license.

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

Anyfi.net software is available to all under a no-charge royalty-free license.

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

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 can leverage the Linux kernel APIs for hardware acceleration. These support e.g. Intel AES-NI instructions and the AMD Geode hardware crypto accelerator.

Anyfi.net software is available to all under a no-charge royalty-free license.

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

An Account is a representation of a legal entity interacting with the platform. The Account is charged for use of the platform.

An Account is identified by the email address that was used to register the Account.

A Client is a representation of a mobile Wi-Fi device.

A Client is identified in the platform by its MAC address. Note however that the MAC address is not used for authentication purposes.

A Radio is a representation of an IEEE 802.11 access point radio partially controlled by Anyfi.net software. A residential gateway for instance often has a single Radio. A public access point with integrated Anyfi.net software may have several Radios. From a platform point of view these are entirely separate entities.

A Radio is identified by the permanent MAC address of the Wi-Fi chipset.

A Service is a representation of an Extended Service Set (ESS). This may be the home network associated with a residential gateway or the switching backplane of a tunnel termination gateway (TTG). Each Service has an ESSID, also known as an SSID, but this is not guaranteed to be globally unique. A Service is instead identified by a Universally Unique Identifier (UUID).

Bindings control network visibility, specifying that a certain Service should visible to a certain Client when that client device is close to a certain Radio. Bindings can be created and destroyed through the control panel or the RESTful web service, but they can also be created automatically when a Client is authenticated locally (and destroyed e.g. when the passphrase is changed).

Bindings always specify a unique Service, but may specify several Clients and Radios with a wildcard pattern. This makes Bindings a very powerful concept: essentially any type of mobile Wi-Fi service can be created by creating appropriate Bindings.

Below are a number of examples of Bindings filling various purposes.

Note that a Binding by default can only affect Radios and Services associated with the same Account.

In this context it should also be noted that Bindings are not a network access restriction mechanism. All connections are separately secured with the standard WPA/WPA2 security mechanism as configured in the tunnel termination back-end.

A Binding is identified by an integer assigned by the platform. This integer identifier is guaranteed to be unique within the scope of a single Account.

A Contract is a representation of a contractual agreement between a subscriber and an operator. From a technical perspective a Contract determines what happens after a Client connects to a Service. For example, the Contract can stipulate that the Capture mechanism should be employed to restrict access to the network and interact with the subscriber through a captive portal web application. The Contract is also the basis for all settlement through the radio access capacity exchange.

A Contract specifies a Service, a subscriber identity (EAP user or device MAC) and a type. The only currently supported type is "data". For "data" Contracts the associated Account is charged per byte transferred. More Contract types, e.g. day passes, week passes and monthly contracts with unlimited data may be supported in the future.

A Contract is identified by an integer assigned by the platform. This integer identifier is guaranteed to be unique within the scope of a single Account.

Accounting Records document the use of Radio resources to provide a Client access to a Service. From a technical perspective an Accounting Record contains information about a certain Client's use of a certain Radio to access a certain Service. Information collected includes data volume, connection time and radio link quality parameters.

An Accounting Record is identified by an integer assigned by the platform. This integer identifier is guaranteed to be unique within the scope of a single Account.

The auto-bind mechanism allows the tunnel termination back-end to automatically create a Binding under some circumstances. This automatic registration mechanism can be used to create mobile Wi-Fi services with a ZERO sign-on user experience. The tunnel termination back-end software may create Bindings under the following circumstances:

1. A STA has authenticated with a local Wi-Fi network

   When the tunnel termination back-end software is integrated in equipment with a local IEEE 802.11 access point it can be instructed to monitor this access point to detect when a STA authenticates, and to auto-bind the corresponding Client to the corresponding Service.

2. An unknown MAC address has been detected on a wired interface

   The tunnel termination back-end software can also monitor a wired network port and detect IEEE 802.3 frames coming from a previously unknown device, and auto-bind the corresponding Client to the Service. This can be used in conjunction with legacy access points to automatically bind Clients when they have authenticated with a legacy access point connected to the same ESS.

3. A Client has authenticated with the Service remotely

   Since a Binding can contain wildcard identifiers for the Client and Radio it may in some circumstances be beneficial to create a more specific binding the first time a Client connects remotely over a Wi-Fi over IP tunnel. The tunnel termination back-end software can be instructed to automatically create such bindings.

Note that the auto-bind mechanism may attempt to create the same Binding several times. This is however inconsequential since subsequent attempts will be filtered out and ignored in the cloud-based matchmaking service.

The Capture mechanism allows HTTP requests from the Client to be intercepted in the tunnel termination back-end and redirected to a specific URL, the Capture URL.

The Capture URL is of the format
http://#{PORTAL_HOST}/capture?service=#{SERVICE_UUID}&client=#{CLIENT_MAC}&radio=#{RADIO_MAC}
with variable parts defined below.

The Capture mechanism is only applied to a Client when the tunnel termination back-end is instructed to do so by the cloud-based matchmaking service. The matchmaking server examines the associated Contract and Service to determine this: if a capture URL has been configured in the Service and the Contract stipulates that the Client should be captured the tunnel termination back-end is instructed to apply the Capture mechanism.

It is also possible to configure a Service with a whitelist of IP ranges that should be accessible to the subscriber even when the Capture mechanism is active.

The Activate mechanism can be used to lift an access restriction already imposed by the Capture mechanism. When the captive portal web application has finished interacting with the end-user access restrictions can be lifted by directing the end-user's browser to a specific URL, the Activate URL.

The Activate URL is of the format
http://#{PORTAL_HOST}:3000/activate?token=#{ACCESS_TOKEN}&url=#{NEXT_URL}
with variable parts defined below.

Note that the Activate URL is not a real URL in the sense that the portal web application should respond to HTTP requests on port 3000. Instead this request is intercepted by the tunnel termination back-end and a HTTP redirect response is generated locally in the tunnel termination point (TTP), after the access token has been verified.

In the case of an error the browser in the Client is directed back to the portal web application with an 'error' parameter describing the error.

The Identify mechanism allows you to detect how a Client is currently connected even in cases when the end-user's browser has not been redirected to your website through the Capture mechanism. By redirecting the browser in the Client to a special URL, the Identify URL, you can identify the Client, Service and Radio of the current connection.

The Identify URL is of the format
http://#{PORTAL_HOST}:3000/identify?url=#{NEXT_URL}
with variable parts defined below.

Note that the Identify URL is not a real URL in the sense that the portal web application should respond to HTTP requests on port 3000. Instead this request is intercepted by the tunnel termination back-end and a HTTP redirect response is generated locally in the tunnel termination point (TTP).

The result will be returned to you as HTTP GET parameters on a subsequent redirect back to your web application. The request URL will have the format
#{NEXT_URL}?service=#{SERVICE_UUID}&client=#{CLIENT_MAC}&radio=#{RADIO_MAC}
with variable parts defined below.

This mechanism can be used to implement convenient management of mobile subscriptions e.g. in subscriber self-service pages.

The simplest way to use the platform is to provide remote access to an existing residential or corporate Wi-Fi network. Radios and Services of course have to be associated with your Account, but other than that you can pretty much lean back and relax: the auto-bind mechanism will automatically create the necessary Binding whenever a new device is connected locally.

Figure 4.1. Anyfi.net Market — configuring the Capture URL.

If you wish to charge the end-user for the service it gets slightly more complicated. You will need to set the captive portal URL on each Service to point to your portal web application. This will cause the Capture mechanism to redirect HTTP requests from Clients that to now yet have a Contract to your web application, where you can collect payment or agree on payment in the future. Your web application will also need to interact with the platform through the RESTful XML API in order to create new Contracts and activate service after payment has been arranged, e.g. in the form of a surcharge on the subscriber's next monthly bill.

While it is technically possible for an advanced user to circumvent the Capture mechanism in network equipment that is under his or her physical control, doing so is against the license terms of Anyfi.net software. Circumvention can be easily detected from the cloud-based matchmaking service and Services with circumvented access restrictions may be disabled.

Another way to use the platform is to distribute a centrally terminated carrier-grade Wi-Fi network through all your Radios.

For this you will of course need to tie your Radios to your Account. But you will also need some Tunnel Termination Points (TTPs) for your carrier-grade Service. A Tunnel Termination Gateway (TTG) is a network element designed for that purpose, terminating millions of Wi-Fi over IP tunnels in a data center or a mobile network core.

Figure 4.2. Anyfi.net Market — an EAP-SIM authenticated service.

But since your subscribers will never connect locally to your TTG (it has no local Wi-Fi network — it exists only within the platform) you will need to manually create a Binding before this network becomes visible to any device. When a WPA/WPA2 Enterprise authenticated Service without local Radios is associated with your Account you will see a notice at the top of the page asking if you want to create a broadcast Binding for it. A broadcast binding makes your Service visible to all Clients within radio range of any one of your Radios. Just press the button to create the binding.

Figure 4.3. Anyfi.net Market — a broadcast binding has been created.

Now whenever a device comes close to any one of your access points they will be presented with your centrally terminated carrier-grade Wi-Fi network.

The control panel interface also lets you monitor use of your carrier Wi-Fi service. For a given time period it's possible to determine how many Clients have connected through a given Radio or to a certain Service, as well as data volume, connection time and radio link quality statistics.

Figure 4.4. Anyfi.net control panel — home page.

This information is available through the RESTful XML API in the form of Accounting Record resources, allowing for integration with your favourite CRM system.

API clients are authenticated using SSL client certificates. The client certificate ties the caller to an Account and determines which resources they can access and manipulate.

To retrieve a client certificate you need to first generate a Certificate Signing Request (CSR). Make sure that the Common Name (CN) is the email address that identifies your Account and that other fields are reasonably and truthfully filled in. Please do not specify an email address in any other field, or set a challenge passphrase.

openssl req -out anyfi-$(date +"%Y%m%d").csr \
            -new -newkey rsa:2048 -nodes -keyout anyfi.key

Then upload the CSR through the control panel interface. We will review your request and if appropriate sign a corresponding certificate. When your certificate ("client.crt") has been signed it will be available for download.

You now have all the credentials you will need to authenticate. Please make sure that no third party learns your private key. If you believe that your private key has been compromised contact support@anyfi.net immediately.

alias scurl="curl --cert client.crt \
                  --key anyfi.key   \
                  -H 'Accept: application/xml+vnd.anyfi.api-v1'"

Errors are indicated with HTTP status codes and explained with accompanying plain text.

A radio resource is created by the platform every time a new Radio starts up and registers with the cloud-based matchmaking service. In order for the resource to be accessible through the RESTful XML API it must however have been associated with the API client's Account. This association is controlled with the --account command line option provided to anyfid. This command line option can often be controlled through the configuration interface of the access point.

Radio resources can be retrieved and manipulated as exemplified below.

$ scurl https://anyfi.net/api/radios.xml
<?xml version="1.0" encoding="UTF-8"?>
<radios type="array">
  <radio account="info@anyfinetworks.com" ip="193.13.███.███" hwaddr="00:25:86:d9:63:9e"/>
  <radio account="info@anyfinetworks.com" ip="193.13.███.███" hwaddr="00:27:22:aa:7d:e2"/>
</radios>

A service resource is created by the platform whenever a new Service starts up and registers with the cloud-based matchmaking service.

In order for the resource to be accessible through the RESTful XML API it must however have been associated with the API client's Account. This association is controlled with the --account command line option provided to myfid. This command line option can often be controlled through the configuration interface of the access point or tunnel termination gateway.

Service resources can be retrieved and manipulated as exemplified below.

$ scurl https://anyfi.net/api/services.xml
<?xml version="1.0" encoding="UTF-8"?>
<services type="array">
  <service account="info@anyfinetworks.com"
           capture_url=""
           uuid="5e5d0125-15b6-4907-9d91-49613689a913"
           ssid="Kontoret"
           authentication="personal">
    <instance ip="193.13.███.███" load_factor="0.079"/>
  </service>
  <service account="info@anyfinetworks.com"
           capture_url=""
           uuid="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
           ssid="eapsim1x"
           authentication="enterprise">
    <instance ip="193.13.███.███" load_factor="0.0"/>
  </service>
</services>

$ scurl -X PUT \
        -H 'Content-Type: application/xml+vnd.anyfi.api-v1' \
        -d '<service capture_url="http://some.web.application/capture"></service>' \
        https://anyfi.net/api/services/5e5d0125-15b6-4907-9d91-49613689a913.xml
$ scurl https://anyfi.net/api/services/5e5d0125-15b6-4907-9d91-49613689a913.xml
<?xml version="1.0" encoding="UTF-8"?>
<service account="info@anyfinetworks.com"
         capture_url="http://some.web.application/capture"
         uuid="5e5d0125-15b6-4907-9d91-49613689a913"
         authentication="personal"
         ssid="Kontoret">
  <instance load_factor="0.172" ip="193.13.███.███"/>
</service>

A contract resource is a representation of a Contract. Contracts are automatically created when a Client connects to a Service for the first time. A Contract can be manipulated or replaced by an administrator through the control panel interface or programmatically through this API.

Contract resources can be retrieved and manipulated as exemplified below.

$ scurl https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/contracts.xml
<?xml version="1.0" encoding="UTF-8"?>
<contracts type="array">
  <contract id="1918"
            service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
            client="c8:33:4b:47:c0:53" />
</contracts>

$ scurl -X POST \
      -d '<contract service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
                    client="c8:33:4b:47:c0:53"
                    max_bandwidth_up="1048576"
                    max_bandwidth_down="1048576" />'
      https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/contracts/
<?xml version="1.0" encoding="UTF-8"?>
<contract id="31"
          service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
          client="c8:33:4b:47:c0:53"
          max_bandwidth_up="1048576"
          max_bandwidth_down="1048576" />

A binding resource is a representation of a Binding. They can be created by the platform through the auto-bind mechanism, by an administrator through the control panel interface or programmatically through this API.

Binding resources can be retrieved and manipulated as exemplified below.

$ scurl https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<bindings type="array">
  <binding id="12346"
           radio="*"
           service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
           client="c8:33:4b:47:c0:53" />
  <binding id="2147483663"
           radio="*"
           service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
           client="*" />
</bindings>

$ scurl -X DELETE \
        https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/bindings/2147483663.xml
$ scurl https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/bindings.xml
<?xml version="1.0" encoding="UTF-8"?>
<bindings type="array">
  <binding id="12346"
           radio="*"
           service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
           client="c8:33:4b:47:c0:53" />
</bindings>

$ scurl -X POST \
        -H 'Content-Type: application/xml+vnd.anyfi.api-v1' \
        -d '<binding radio="*" service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7" client="*" />' \
        https://anyfi.net/api/services/4ae9582b-0581-4ef7-b675-b3cbce03b6a7/bindings/
<?xml version="1.0" encoding="UTF-8"?>
<binding id="2147483663"
         radio="*"
         service="4ae9582b-0581-4ef7-b675-b3cbce03b6a7"
         client="*" />

An accounting record resource is a representation of a Accounting Record. They are created automatically by the platform as Clients connect to Services. They can be retrieved through this API to monitor usage, create statistics and for other similar purposes.

$ scurl "https://anyfi.net/api/accounting_records.xml?from=2012-06-01&to=2012-06-02"
<?xml version="1.0" encoding="UTF-8"?>
<accounting_records type="array">
  <accounting_record id="67721"
                     buyer="info@anyfinetworks.com"
                     seller="█████@█████.com"
                     radio="00:27:22:aa:7d:e2"
                     contract="8171"
                     created_at="2012-06-01 08:36:57 UTC"
                     data_up="9.22 MB"
                     data_down="14.13 MB"
                     amount="0.01 USD"/>
</accounting_records>

Before we go into the mobile user experience we should point out that our first priority is always to protect the primary function of the residential gateway, i.e the fixed-line subscriber's use of the connection. The Anyfi.net radio front-end software carefully monitors the fixed-line subscriber's use of both backhaul and radio resources. When there is a risk that a mobile user may in any way impact the primary function the mobile user will be throttled, both in the downstream and upstream direction, to prevent such impact. We call this spectrum aware traffic prioritization.

The home Wi-Fi user experience should be familiar to most. Anyfi.net technology lets an operator provide that exact same user experience outside the home, whenever the subscriber is close to any one of the operator's residential gateways. The user experience is exactly like at home; open a laptop or take the key lock off a phone and it will automatically connect. Note that there is no software to install on the device, no manual registration process and no username or password to remember. Yet the connection is completely secure, protected end-to-end with the standard WPA/WPA2 Personal security mechanism.

The quality of experience is however highly dependent on the radio access coverage, which in turn depends on the operator's geographic market penetration. An operator with a residential broadband market share of 5-10% should be able to provide acceptable service with reasonable coverage in an inner city area. In areas with a lower density of residential broadband connections the service will be of a more nomadic nature than fully mobile.

Anyfi.net software is available under a no-charge royalty-free license and can be deployed in residential gateways as a remote firmware update. This however requires that the operator has a remote firmware update process in place.

While Anyfi.net software an be integrated on most residential gateway platforms integration is greatly simplified if the platform is Linux based and uses a Broadcom, Ralink or Atheros Wi-Fi chipset.

In addition the operator may need a provisioning system (based e.g. on TR-069) in order to enable and disable Anyfi.net software for individual subscribers.

The key strengths of Anyfi.net technology translate into a superior user experience, as well as a scalable and economical solution for the operator.

In this deployment scenario both the radio front-end and the tunnel termination back-end portions of Anyfi.net software needs to be integrated in residential gateways.

A three stage deployment process is recommended:

1. Firmware integration and lab trial

   Anyfi.net software integrated in a (beta) firmware image targeting the relevant customer premises equipment such as residential gateways or modems with integrated Wi-Fi. This firmware image is then tested in the operator's lab. A successful outcome of the lab trial may be a suitable first tollgate for the integration project.

2. Solution integration and field trial

   The equipment vendor delivers a production firmware image to the operator and this image is used to remotely update a large installed base of customer premises equipment. At this stage only the front-end portion of the software should be activated in order to ensure that the user experience of subscribers is not yet impacted, and that the operator is not charged for all subscribers during the field trial. Depending on the business model that the operator wishes to implement it may or may not be necessary to integrate with OSS/BSS systems. The back-end portion of the software can then be activated for select subscribers, e.g. the employees of the operator or a small set of beta subscribers.

   In some cases it may be necessary to optimize data flow from a traffic engieering perspective at this stage. A successful outcome of the field trial may be a suitable second tollgate for the integration project.

3. Commercial operation

   Once the field trial has been successfully concluded the mobile Wi-Fi service can be enabled for all subscribers by simply activating the back-end portion of the software in all residential gateways.

Before we go into the mobile user experience we should point out that our first priority is always to protect the primary function of the residential gateway, i.e. the fixed-line subscriber's use of the connection. The Anyfi.net radio front-end software in the residential gateway carefully monitors the fixed-line subscriber's use of both backhaul and radio resources. When there is a risk that a mobile subscriber may in any way impact the primary function the mobile subscriber will be throttled, both in the downstream and upstream direction, to prevent such impact. We call this spectrum aware traffic prioritization.

SIM authentication with EAP-SIM/AKA has been a part of the Wi-Fi standard for some time, and with recent initiatives by the Wi-Fi Alliance [7] and the Wireless Broadband Alliance (WBA) [8] device support is set to accelerate. On most devices, e.g. all Apple devices, a ZERO sign-on user experience can be achieved.

Anyfi.net technology adds to this user experience in important ways. Firstly, the Wi-Fi over IP tunnel ensures that the mobile communication is protected by the WPA/WPA2 security mechanism end-to-end, all the way from the device to the operator's data center or core network. Secondly, since the IEEE 802.1X authentication is performed in a tunnel termination gateway (TTG) and the encryption keys never leave this gateway the strong mutual authentication property of the WPA/WPA2 security mechanism is preserved. This means that the end-subscriber can be certain that they are in fact connected to their trusted mobile operator, and not to a rogue access point (with unauthorized access to the operator's RADIUS interface). Lastly but perhaps most importantly, Anyfi.net technology allows the operator to only offload mobile devices to Wi-Fi when the radio link between device and access point meets some minimum quality requirement and to fail gracefully when tunnel termination or IEEE 802.1X authentication resources become a limiting factor.

The operator can also manage the quality of experience dynamically through the RESTful web service, e.g. ensuring that only the devices with a high data volume usage pattern or a certain type of data plan are presented with the operator branded and EAP-SIM/AKA authenticated Wi-Fi network.

Anyfi.net software is available under a no-charge royalty-free license and can be deployed in residential gateways as a remote firmware update. This however requires that the operator has a remote firmware update process in place.

While Anyfi.net software can be integrated on most residential gateway platforms integration is greatly simplified if the platform is Linux based and uses a Broadcom, Ralink or Atheros Wi-Fi chipset.

In addition the operator may need a provisioning system (based e.g. on TR-069) in order to enable and disable Anyfi.net software for individual subscribers.

The key strengths of Anyfi.net technology translate into a superior user experience, as well as a scalable and economical solution for the operator.

In this deployment scenario only the radio front-end portion of Anyfi.net software needs to be integrated in residential gateways. The tunnel termination back-end software comes pre-integrated in a tunnel termination gateway installed in the operator's data center or core network.

Public access points with IEEE 802.1X authentication support can be integrated in the system without requiring firmware integration of Anyfi.net software. Additional public access points with Anyfi.net software pre-integrated can easily be added to the system later to improve coverage in public areas with a high subscriber density.

A three stage deployment process is recommended:

1. Firmware integration and lab trial

   Anyfi.net software is integrated in a (beta) firmware image targeting the relevant customer premises equipment such as residential gateways or modems with integrated Wi-Fi. This firmware image is then tested against a tunnel termination gateway (TTG) in the operator's lab. A successful outcome of the lab trial may be a suitable first tollgate for the integration project.

2. Solution integration and field trial

   The equipment vendor delivers a production firmware image to the operator and this image is used to remotely update a large installed base of customer premises equipment. At this stage the service should not be accessible to all mobile devices. Individual devices should instead be bound to the service in the tunnel termination gateway with a Binding created using the control planel. The complete solution can then be tested in the field without causing any interruption.

3. Commercial operation

   Once the field trial has been successfully concluded mobile Wi-Fi offloading can be enabled for more devices by registering them individually through the RESTful web service, or by creating a wildcard Binding specifying all Clients.

Before we go into the guests user experience we should point out that our first priority is always to protect the primary function of the access point. The Anyfi.net radio front-end software carefully monitors primary use of both backhaul and radio resources. When there is a risk that a guest user may in any way impact the primary function that user will be throttled, both in the downstream and upstream direction, to prevent such impact. We call this spectrum aware traffic prioritization.

The user experience of remote access to a Wi-Fi network through a Wi-Fi over IP tunnel is identical to that of local access to the same. There is no software to install on the device, no registration process and no new username or password to remember. Anyfi.net technology simply makes the preferred network of each and every device magically appear, where and when it's needed.

Anyfi.net software is available under a no-charge royalty-free license and can be integrated in most consumer Wi-Fi routers and corporate WLAN access points with 200 KB flash to spare. Integration is however greatly simplified if the target platform is Linux based and uses a Broadcom, Ralink or Atheros Wi-Fi chipset.

The key strengths of Anyfi.net technology translate into a superior user experience for your customers.

For a consumer Wi-Fi router manufacturer integration is very straightforward: simply integrate the software in your firmware build environment. Anyfi Networks can assist with professional services and reference integrations for all the major platforms from Broadcom, Ralink and Atheros.

For a corporate WLAN vendor integration can be slightly more complex. This is because integration towards the platform may be necessary. If you have a continuing relationship with your customer base this should however pose no serious problem. You can integrate through the RESTful web service and resell our services on a wholesale basis. Alternatively you can leave the choice to your customer, allowing them to configure their equipment with an Anyfi.net Account if they so wish.

In some cases it may not be practical for a corporation to upgrade to access points and/or WLAN controllers with Anyfi.net support. In that case virtual Remote Access Point (vRAP) functionality can instead be implemented with a separate tunnel termination gateway (TTG). For small businesses a TTG implemented as a VMware image may suffice. This means that a virtual Remote Access Point (vRAP) solution can be bundled e.g. with a number of consumer Wi-Fi routers and quickly brought to market at a competitive price point.