To effectively read the article, some familiarity with mobile networks is assumed.
We haven’t talked about offloading or unloading mobile data traffic from mobile networks over a Wi-Fi network for a long time.. But the situation nevertheless continues to evolve. Such offload can be, let’s say, a clean offload using existing modern Wi-Fi networks or offload using Hotspot 2.0 technologies. To a greater extent, we will talk about the version with the use of HS2.0. Such an approach is widely and hotly debated today in narrow circles. Moreover, some operators have already tested something or even launched commercial solutions in one form or another. It can be said that the flame of new interest flares up around HS2.0 after the surge and fall in 2012-2013 due to the lack of compatible devices and provisioning mechanisms. Moreover, the possibility of using HS2.0 is not only a privilege of mobile operators or MVNO, but it can also be used by all other fixed operators and providers.
Probably, it makes no sense to discuss the fundamental advantages of using unlicensed or conditionally unlicensed spectrum in comparison with the licensed (actually Wi-Fi against 3G / 4G) to serve the huge and ever-increasing amount of data traffic generated by various mobile or other non-stationary devices. This was mentioned many times in various articles and on our resource in particular. On the other hand, without a clear understanding of the architecture of the target system solution, the features and the business case associated with this solution, many of the advantages can be significantly reduced due to costs, sometimes unnecessary. But first things first.
It should be understood that a Wi-Fi network can be both trusted and untrusted in relation to the network of a mobile communication operator. In this article, we will talk about the version of the trusted Wi-Fi network (Trusted non-3GPP WiFi-Access, in accordance with the recommendations of 3GPP). The untrusted option implies the need to address the issue of security, which is usually transformed into the formation of IPSec tunnels between the client device and the mobile packet bark. This imposes the need for specialized clients on a mobile device, as well as devices for terminating such tunnels in the cortex, plus very expensive licenses and the like. Operators usually prefer to work with a trusted option that is much simpler and potentially cheaper. In the case of a trusted Wi-Fi network, this network belongs to either the mobile operator itself or its partner, a fixed telecom operator operating in the MVNO model with respect to this mobile operator. I.e, we have a Wi-Fi access network completely or conditionally controlled by a mobile operator. Naturally, such an approach makes it necessary to integrate a Wi-Fi network with a mobile packet bark of a mobile telecommunications operator. Or, in some rare cases, elements of a mobile packet cortex are purchased and deployed by a fixed provider who wishes to receive an MVNO solution of a deeper level.
Hotspot 2.0 in Mobile and Fixed Applications
For fixed operators or providers, there is usually no need to somehow integrate with the mobile network. Here, devices without a mobile radio, such as all sorts of desktop computers and laptops, tablets with Wi-Fi, are of higher priority. Although, of course, in many cases, users with the most common mobile smartphones and tablets with Wi-Fi radio will also knock on such a wireless access network, and we should be ready for this.
This results in the variants of clients that such a trusted Wi-Fi network must be able to authenticate and maintain:
Mobile devices with a SIM or USIM card that do not support HS2.0
2. Mobile devices with a SIM or USIM card, supporting HS2.0 R1
3. Mobile devices with a SIM card or a USIM card that support HS2.0 R2
(this is a promising direction at the beginning of 2016)
4. Any devices without a SIM card that do not support HS2.0,
5. Any devices without a SIM card that support HS2.0 R1,
6. Any devices without a SIM card that support HS2.0 R2
(at the beginning of 2016 this is a promising direction)
The diagram below reflects the real high-quality picture of the client devices on the market at the time of publication of the article.
Non-SIM devices can “belong” both to the mobile operator itself, for example, under contracts with B2B clients, and also be clients of a fixed operator acting as MVNO in such a system.
Having touched upon such a topic as the decisions of the Hotspot 2.0 standards group, let’s remember what it is, who does what and what is the meaning of various releases.
Hotspot 2.0 was created to solve the main problem: providing Wi-Fi users the same level of ease of access to the service on a global scale as users of mobile networks. Turned on a device compatible with HS2.0 and magically already online. In this case, the user should not care about what is happening on the network. All other interesting technological capabilities of HS2.0 were added to the solution of this main task.
Three organizations mainly participate in technology standardization under the common name Hotspot 2.0:
1. IEEE
IEEE is developing an 802.11u standard. Support for this standard is mandatory both on the user device side and on the Wi-Fi network side.
2. Wi-Fi Alliance (WFA)
Using the 802.11u standard as the basis of the WFA, it is working on mechanisms for automating network search and user authentication. WFA also solves the problem of compatibility of user devices and the network through the provision of joint testing procedures. WFA has organized and maintains a Passpoint certification program. This program has already passed hundreds of devices that are compatible with HS2.0 Release 1 and is currently working on certification of devices and technologies for HS2.0 Release 2. Actually, the Wi-Fi Alliance, by and large, creates what is eventually accepted call hotspot 2.0.
3. Wireless Broadband Alliance (WBA)
The WBA is developing technology compatibility requirements in commercial solutions using IEEE and WFA. The WBA has launched and is promoting a very important initiative called Next Generation Hotspot (NGH). NGH aims to form global inter-network roaming mechanisms for Wi-Fi access service providers. There are still more open questions than answers, and the process is slow. In fact, the option of inter-network roaming in a meaningful form (functionally limited) is so far achieved by connecting the operator’s network with a Wi-Fi aggregator supporting HS2.0. Today, this functionality has been demonstrated by Boingo. At the time of the publication of the article, Boingo supported HS2.0 service for Apple iOS devices compatible with HS2.0 / R1. Another large iPass aggregator is also working on a similar service.
At the beginning of 2016 there are two developed releases Hotspot 2.0. Developers had to go to such a division since the task initially set was extremely difficult to implement.
1. Hotspot 2.0, Release-1
R1 aims to provide automatic user access to the service in hotspots ( WiFi networks ), where this user can be authenticated and authorized. By using 802.1x in conjunction with the 802.11i security architecture, authentication at the second level and radio channel encryption in public hotspots are provided. Additionally, it became possible to integrate multiple partner providers behind an HS2.0 compliant network and provide their users with automatic access through a single HS2.0 compliant SSID. The R1 began to use the IEEE 802.11u standard, and the Access Network Query Protocol (ANQP) search and exchange protocol was introduced.
Despite the fact that at the moment there are many network components and user devices that are compatible with HS2.0 / R1, these devices do not yet dominate the device market. And, most importantly, the provisioning of user devices integrated into the system solution was not implemented in R1. Thus, to build a network of HS2.0 / R1 and the use of compatible user devices will have to solve the issue of configuration management.
2. Hotspot 2.0, Release-2
R2 addresses the challenges of managing user devices and provisioning subscriptions. To solve this complex task, the OMA-DM (Open Mobile Alliance’s Device Management) architecture was introduced, ensuring the use of an XML-based tree structure. Also in R2, new network elements were introduced, the main one being the OSU (Online SignUp server), designed to provide secure provisioning and adding devices supporting R2 to the network (onboarding).
To understand the difference between accessing an HS2.0 device to a WiFi / HS2.0 network from any conventional Wi-Fi device (not HS2.0) to a regular Wi-Fi network, let’s look at how the interaction occurs in network HS2.0.
So Access to the Network with Support for HS2.0:
The Wi-Fi access point sends beacons that contain additional fields in accordance with the 802.11u standard. User devices that understand 802.11u listen to these beacons.
• User devices send samples with 802.11u fields.
• The device selects an access point and sends an ANQP request requesting HS2.0 information. This may be, for example:
– location name (name of the store, stadium, etc.), –
IP addressing,
– network identifier (NAI Realm),
– DNS sheet, external data channel (WAN) metrics.
• The access point responds with ANQP providing information.
This could be, for example:
-SuperShoppingMall
-IPv4 NAT
-MNO-aaabbb.com / TTLS
-MCC yyy MNC zzz
-MNO.com
-12/3 Mbps, Up / Up
• The device compares the pre-configured profile on itself with the data received from the access point and performs the association to the desired SSID if it is possible.
Everything described above, if the user device supports HS2.0 and has already been retested for this by its home carrier, occurs automatically. The network where the user wants to access must maintain roaming relationships with his home operator. This can be achieved through direct inter-operator integration or through access to specialized HS2.0 compliant traffic exchange points. Or it can be a joint with a compatible Wi-Fi aggregator, for example, such as the previously mentioned Boingo. If everything is built as it should, then the user simply wants to use this access – and forward to the Internet. With the right developments, if the device supports HS2.0 and 802.1x, there is no need to search for the desired network, enter a Credentials etc.
Now let’s dwell on what options of off-road exist and how they differ. The names are quite conditional, but reflecting the essence of the question.
- Simple or ordinary offload
- Offload using Hotspot 2.0
Simple offload implies the possibility for b About proceed of the modern devices to access the Wi-Fi network. At the same time, mobile devices should be able to offload mobile data traffic with support for one of the following authentication methods specific to mobile devices: EAP-SIM, EAP-USIM, EAP-AKA. Usually, EAP-SIM is used today. Given the fact that the client information, in this case, is stored in the HLR (Home Local Register) or HSS (Home Subscription Server) of the mobile carrier, the Wi-Fi network must be integrated via the RADIUS protocol with the mobile bark. By the way, st OhIt is to say that in some situations HLR may be part of the HSS structure, but this is rare. Note that the HLR does not support the RADIUS protocol, and EAP methods are transmitted in RADIUS messages, so the typical practice is to convert EAP-SIM to SIGTRAN to interact with the HLR. In case of sufficiently old HLRs that do not support SIGTRAN, but the only SS7 on digital streams of type E1 / T1 or more, STP (Signaling Transfer Point) can be used. Depending on the vendor, often such an element is not only capable of terminating RADIUS with EAP-SIM, but also converting EAP-SIM to SS7 and transmitting via TDM channels. In an IP network, the function of converting EAP-SIM to SIGTRAN is most often performed by an AAA Server with the functionality of a MAP converter or MAP gateway. For non-SIM clients, EAP-TLS, EAP-TTLS, PEAP methods within 802 are very popular.
If the presence of clients that do not support 802.1x is allowed, then web authentication can be enabled through a web portal. It should be noted that web portals are rapidly losing popularity due to the low level of security of this approach. In some situations, web portals are beginning to be used to provision (change configuration) devices. In this case, a profile can be located on the portal for making changes in the device configuration to, for example, start using its Hotspot 2.0 functions. The user can download such a profile, apply, and then everything will happen automatically. So today Apple iOS devices that support HS2.0 / R1 are configured, and more recently, similar support has been added to Android 6.
If the operator’s Wi-Fi network is built on a centralized architecture controlled by a wireless controller, then such a controller usually performs the function of a proxy server, for example, for a RADIUS protocol, forwarding RADIUS messages to an external AAA Server, or for HTTP / HTTPS protocol, performing Redirect (redirect) such messages to an external web portal. Even if the WLAN controller has a built-in web portal and any authentication capabilities, the use of external devices is done to scale the solution and to get much more extensive AAA functionality and many other advantages.
The WLAN controller, in addition to the integrated Wi-Fi network management function itself, can also perform the WAG function (Wireless Access Gateway, 3GPP). Or, WAG can be a separate device working together with the controller in a single solution. If you don’t go into details that are not very important at this stage, then the main task of WAG is to unite the WiFi world with the mobile world by forming various tunnels and, above all, GTP tunnels (GTP: GPRS Tunneling Protocol). A GTP connection is generally performed in one of the following ways:
- Integration of WAG and 3G GGSN by using GTPv1
- Integration of WAG and 4G PGW by using GTPv2
In order not to complicate, let us leave the description of the interfaces behind the crowd of this article. You can always find these details in the relevant 3GPP documents.
Now let’s get back to using the GTP protocol to integrate a Wi-Fi network with a mobile packet bark. This approach, on the one hand, is recommended by 3GPP, but to what extent is this justified for telecom operators participating in the project, especially for the mobile operator? Let’s figure it out.
A mobile device in a mobile network transmits data through the so-called PS-domain (packet switched) or domain with packet-switched. In this case, voice traffic is transmitted through a CS-domain (circuit switched) or a circuit-switched domain. Theoretically, fourth-generation networks (LTE / Advanced-LTE) can support both voice and data over IP, thereby transforming into an All-IP network, but such homogeneous networks with large-scale voice and data support over IP can assume almost none. Mobile networks, even the most modern, are heterogeneous, combining in themselves the legacy of past years and modern technologies. And with this one has to live in the real world. This results in extreme difficulties in the implementation of handovers with saving the session from the access of one technology (for example, 3G) to the access of another technology (for example, Wi-Fi) and vice versa. And it is much more difficult with voice sessions, especially if such a session was initiated in the cs-domain of the mobile network and it is necessary to continue it in the Wi-Fi network, which by definition is packet-based or vice versa. It must be said that some solutions to the problem exist, but none has yet become widely accepted. In general, this is a big and complex issue that is not the topic of this article.
It is important to know that many of today’s mobile devices, if not all, after joining the Wi-Fi network and starting offload data traffic to this network, continue to maintain their GTP tunnel into the mobile packet cortex through the mobile network. In addition to this, one more GTP tunnel from WAG to the packet bark for the session of the same subscriber necessarily occurs. Thus, to implement mobile data offload in Wi-Fi with integration via GTP tunnels, it is often necessary to significantly increase the number of licenses and the performance of mobile packet cortex (GGSN and / or PGW). That is, in the first approximation, we can very roughly talk about the need to double the number of licenses in the bark. Of course, this can and must be carefully optimized, but for simplicity of perception, we will assume the doubling assumption. Hence, for a large subscriber base of a mobile operator, only modification of the package bark can add millions, if not tens of millions of dollars, to a project. And that’s not counting the actual deployment of the Wi-Fi network and WAG gateways.
A number of mobile operators clearly prefer to receive data traffic, regardless of the type of access to their packet bark, in order to apply a single polishing mechanism, traffic calculation and billing to all subscribers. This is a clear desire, but its implementation eventually becomes very expensive in practice.
In addition to GTP tunnels, other tunneling technologies can be used for integration, for example, PMIPv6, SoftGRE and a number of other, less popular ones. But GTP remains the most common and clear option for today for mobile telecom operators.
What can be done to reduce the cost of building a solution for offload? In any case, for offload mobile data will have to perform integration at least to ensure the authentication of subscribers. Perhaps one of the most interesting (and financially significant) questions at the same time – is it necessary to integrate with the mobile packet cortex through these or other tunnel technologies? Under certain conditions, this cannot be avoided, for example, with the unequivocal demand for maintaining continuity of sessions. But this condition imposes a lot of additional requirements, such as the introduction of the Home Agent function, etc. Another situation arises when the mobile operator wants all data traffic, regardless of the type of access, to be sent to its packet core. We discussed motivation earlier. Such a desire is understandable and obvious, but the price of realization is very high,
Is it necessary to tunnel traffic into the mobile packet cortex, if there are no special conditions? The control part of the traffic (Control plane), first of all, RADIUS messages, will have to be transferred in any way from the Wi-Fi network to the mobile core to perform subscriber authentication, as described earlier. But data traffic (Data plane) is not necessary to redirect to the kernel. It can be completely terminated locally, directly at access points, and redirected to the nearest route to the Internet. This is called a local breakout. If the operator has a full-featured 3GPP AAA server, then it can be used not only to authenticate subscribers but also to perform accounting for traffic calculation and billing. At the same time, such an AAA server is usually able to convert RADIUS to SIGTRAN. If such an AAA server already exists with the operator,
As an example, some large mobile operators even conducted quite successful offload testing and Hotspot 2.0 with integration via GTP, and then carefully considered the full costs and realized that offload was needed, but costs needed to be optimized. As a result, offload and Hotspot 2.0 remained, but during the transition to the commercial operation, they refused from tunnels to the core, performing local data traffic termination. This allowed to reduce costs to an acceptable level and at the same time successfully complete the task.
If we follow the simplified path, then to deploy a solution with Hotspot 2.0, which will be able to work with both HS2.0- and non-HS2.0 clients, it will be required in the general case:
- Wi-Fi access points that support HS2.0 (802.11u).
- Wi-Fi network controller supporting HS2.0
- AAA server for authentication and accounting of its users and integration with other networks through a RADIUS proxy mechanism. To integrate with mobile bark on the AAA server, you need a MAP gateway functionality.
- Means of safely introducing new customers to the network (onboarding).
You will also have to resolve issues of integration with other carrier networks or aggregators.
The short format of the article can not cover all the nuances and pitfalls on the difficult path of implementing solutions HS2.0, but we tried to touch on the main aspects and features.