WiFi offloading vs VoWiFi

In recent years we have encountered a lot of customers wanting to utilize their networks more efficiently, and provide premium service for their subscribers. WiFi offloading and VoWiFi are popular ways to to extend the mobile operator’s network coverage into wifi, free bandwidth from congested cellular networks and improve user experience with better connectivity. The technologies share many similarities and both use a 3GPP AAA server for SIM based authentication.

WiFi offloading offers some flexibility in the supported authentication backends and the SIM authentication can be done through various HSS and HLR interfaces depending on what the mobile operator has available. This is especially important in roaming scenarios where the WiFi provider has agreements with multiple MNOs to offload their subscribers.

WiFi calling is more strictly standardised to support high QoS for the voice call, and also the handover between VoWiFi and VoLTE. This allows users to move outside the range of the WiFi hotspot and seamlessly continue the call over VoLTE, and vice versa.

Let’s take a look at the key differences between the two related technologies:

Comparison	WiFi offloading	VoWiFi
Purpose	Ease network congestion, Network CAPEX savings, Roaming cost savings, Secure authentication to private wireless networks: carrier, industrial, in-flight, underground, IoT	Ease network congestion, Indoor coverage extension, Combat OTT apps, Roaming cost savings
Relationship between MNO and access network provider	Agreement required between MNO and wifi provider	No relationship between MNO and wifi provider
Access network	Carrier or partner wifi	Any public or private wifi
Traffic	Data only	Voice and video calls
SIM authentication protocol	EAP-SIM, EAP-AKA, or EAP-AKA’	EAP-AKA
Supported HSS interfaces	SWx, Wx, Cx, S6a	SWx required
Supported HLR interfaces	MAP, SIGTRAN	Not supported
ePDG	Not applicable	ePDG mandatory
Security	WPA Enterprise	IPSec tunnel between UE and ePDG
IMSI Privacy	Yes, supported by Radiator	Yes, supported by Radiator

What is different?

The main difference between WiFi offloading and VoWiFi is the relationship between the mobile operator and the wifi provider: operator controlled data offloading always requires a prior agreement between the MNO and the WISP. WiFi offloading is often done in high traffic areas such as airports, sports stadiums and concert venues, since offloading users to WiFi is cheaper than adding microcells to boost the mobile signal. MNOs can invest in carrier wifi hotspots themselves, or make offloading agreements with wireless ISPs.

VoWiFi requires the mobile device to be connected to a wifi before attempting a VoWiFi call, but any type of wifi can be used for WiFi calling, including consumer home wifi. Therefore no relationship between the mobile operator and WiFi provider is required. However VoWiFi has specific technical requirements for the MNO: a HSS with SWx interface and ePDG are required.

Private network authentication

WiFi offloading technology is also applicable to private network offerings, such as industrial and IoT networks. SIM authentication provides a secure method to authenticate users into a private network using their SIM credentials and eliminates the human element of reusing and sharing passwords. In high security deployments the SIM authentication can be further combined with device IMEI check, to make sure that only authorised users and devices are able to access the private wifi network. VoWiFi is also possible in private networks, and can enable voice calls in challenging environments such as underground.

Interested in WiFi offloading or VoWiFi?

Radiator SIM Pack provides a fully featured 3GPP AAA server solution, with superb flexibility to connect with your environment. Please contact the Radiator team at sales (at) radiatorsoftware.com to get a quote.

Radiator SIM Pack 2.9 released

Recently, we have met increased demand for SIM authentication in different use cases and services. Radiator development is driven by the actual customer cases and we are now pleased to announce the release of Radiator SIM Pack version 2.9!

Here are selected highlights from the new release:

Cx support for EAP-SIM, EAP-AKA and EAP-AKA’ authentication

Diameter Cx interface provides an alternative way of fetching the SIM authentication vectors when the standard SWx interface is not available from the MNO. Cx is an HSS interface that is typically used to authenticate users from the IMS side of the network, but Radiator can now also use it for SIM based Wi-Fi authentication.

SIGTRAN location update features

Support for MAP UpdateLocation, MAP UpdateGprsLocation and MAP CancelLocation have been implemented in SIGTRAN. Location update features make it possible to resolve the user MSISDN (i.e. mobile number) and use IMSI related profile for authorisation. As a result, different authorisation rules can be enforced based on the MSISDN, or mobile numbers can be included in logging, accounting and other customer specific requirements.

Improved temporary identity generation

Temporary Mobile Subscriber Identity or TMSI is a pseudonym for the subscriber’s actual identity, IMSI. Plain or encrypted IMSI is always used for the initial SIM authentication, but a temporary identity can be generated for the subsequent requests to make re-authentication faster and increase security. Radiator TMSI implementation has now been updated per recent 3GPP specification: the improved implementation no longer requires a SQL session database further enhancing the speed of re-authentication. Historical data is also retained better.

For a full list of new features and changes, please see Radiator SIM Pack revision history.

Trends in operator AAA cases

In our recent projects with customers ranging from small private operators to major tier 1 carriers, we have seen these significant trends:

• Demand for Wifi offloading and VoWiFi remains high for various reasons: coverage and capacity expansion, ease of congestion in high density areas, and cost saving, especially for saving international roaming costs.
• Non-fixed backhaul connectivity cases (in-flight, train, maritime) cases are emerging.
• New private LTE/5G operators need SIM authentication to add Wi-Fi networks to their offerings. Radiator is an integral part in different MVNE solutions in connecting the MVNO and MNO network elements.

In addition, security requirements have increased. Demand for IMSI Privacy is driven by Android and iOS, and support for IMSI encryption is now a must for new offloading projects. RadSec is required for various roaming scenarios, including OpenRoaming. Both are supported by the Radiator SIM Pack - with a long track record of field proven production implementations.

Would you like to know more?

Radiator pre-sales team includes experienced engineers who can provide expertise for advanced Diameter and roaming use cases, including non-standard and custom cases.

In addition to top tier technical support, we also provide a flexible licensing model to match your business case. Whether you have your own subscribers, IoT devices or roaming guests, you can grow your license at the same pace where your business grows - you can just buy add-on licensing as you are onboarding more SIM authentication or VoWiFi end users, for example.

We always know that every customer case is different - so please do not hesitate to contact us at info@radiatorosoftware.com.

Radiator SIM Pack 2.8 released! Major scalability improvement and other enhanced features

We are pleased to announce the release of Radiator SIM Pack version 2.8. This new release contains major scalability improvement and many enhanced features.

Scalability improvement and other enhanced features

To make it easier to manage large installations and improve performance, Radiator 3GPP AAA Server now supports configuration with multiple parallel workers that use the same Diameter identity. This update was also reflected in earlier Radiator Service Provider Pack release. 

In addition, Radiator SIM Pack has supported IMSI Privacy since release 2.5 and 2.8 release now adds support for certificate revocation and expiration notifications. For more info about IMSI Privacy features in Radiator SIM Pack, please see our new whitepaper.

Also, customers using SIGTRAN will be pleased to learn that SIGTRAN stack upper layers have been rearranged to better support additional MAP dialogues. For more detailed changes, please see the Radiator SIM Pack revision history.

Would you like to know more?

If you like to know more about Radiator, the new release and how it can help you in your use case, you can always contact our team at info(a)radiatorsoftware.com - or fill out the contact form.

New whitepaper: Introduction to IMSI Privacy Protection for Wi-Fi with Radiator SIM Pack

 

Great news! We are proud to present our new whitepaper “Introduction to IMSI Privacy Protection for Wi-Fi with Radiator SIM Pack”. You can download the whitepaper from our website.

What is IMSI Privacy about and why is it important?

One of the key use cases for SIM authentication, Wi-Fi offloading enables SIM-based devices to automatically switch data and voice traffic from mobile networks to Wi-Fi networks. This lets mobile carriers and operators reduce their operating costs, and provide better network coverage and customer service, in locations with high amounts of mobile traffic. However, without IMSI Privacy Protection for Wi-Fi the mobile user’s identity will be exposed on the Wi-Fi network when the device is authenticated and the latest Android and iOS mobile devices will also give the user a security warning and may refuse to connect automatically.

Since many of the SIM-based Wi-Fi authentication use cases, such as Wi-Fi offloading, Voice over Wi-Fi and Wi-Fi roaming capabilities are growing in importance, mobile OS manufacturers are putting pressure on the industry to improve Wi-Fi security, leading to a clear need for reliable IMSI Privacy Protection.

In our white paper, we give an overview of the security issues with Wi-Fi SIM-based device authentication and introduce the Radiator SIM Pack, which is a proven solution for IMSI Privacy Protection for Wi-Fi.

For more information, please download the whitepaper from our website.

*) In SIM-based mobile devices, like smart phones and tablets, the user’s unique identifier is stored on the SIM card in a standard format known as the International Mobile Subscriber Identifier, or IMSI for short.

Protecting user identity with Radiator SIM Pack

Nowadays, mobile operators use complementary network technologies to improve user connectivity. Mobile data traffic originally targeted for cellular networks can be offloaded to designated Wi-Fi hotspots, therefore relieving congestion in high traffic areas. By implementing SIM authentication with Radiator SIM Pack, customer experience is enhanced by seamlessly authenticating users and logging them into the Wi-Fi network.

Cellular networks use IMSI (International Mobile Subscriber Identity) as a unique identifier for every user of the network, which comprises 15 digits including the user's telephone number. When this identifier is sent by the device to the network, privacy can be compromised if the connection request is not encrypted. This encryption relies both on the operator's AAA server and the user device.

Starting from revision 2.5, Radiator SIM Pack supports IMSI encryption, also known as "Permanent Identity Encryption"; functionality specified in 3GPP document S3-170116: "Privacy Protection for EAP-AKA". This feature is already implemented by some of our operator customers to cover their AAA server encryption. Alongside device manufacturers such as Apple, who already implement identity encryption, permanent identity of the user is not exposed, increasing their privacy protection.

The latest release of Radiator SIM Pack is available for new licensees and for licenced customers with valid download access. To find out if Radiator SIM Pack suits your needs, you can contact us at sales@radiatorsoftware.com and a member of our sales team will be happy to assist you. You can also contact us to renew your support contract and get access to the newest release. A full history of Radiator SIM Pack releases is available on our website.

Radiator SIM support 2.4 released

We are pleased to announce release 2.4 of Radiator SIM support. This release includes support for SCTP multihoming and has a number of smaller enhancements and bug fixes.

Revision 2.4 detailed updates and fixes

• 3GPPAutHSS now supports Peer-Auth-Application-Id as DiaPeerDef selector. Requires Carrier module 1.5 or later and Radiator 4.20 or later.
• Added configuration parameter HSSRealm to 3GPPAuthHSS. This value for this parameter is typically the realm where HSS resides. If not set, messages’ realm is set from DestinationRealm parameter of DiaPeerDef used to forwarding messages to the HSS. Defaults to not set.
• Subscription-Id AVP is now added to SWm DEA messages to relay MSISDN to ePDG.
• Updated EAP-SIM, EAP-AKA and EAP-AKA’ permanent, pseudonym (TMSI) and fast re-authentication identity leading characters to match RFC 4186, 4187 and 5448, and 3GPP TS 23.003 suggestions and requirements. Because of historical reasons, EAP-SIM fast re-authentication and EAP-AKA TMSI leading characters were swapped. EAP-AKA’ non-permanent identifiers are now fully separate from the respective EAP-AKA identifiers.
• Removed obsolete configuration parameters TestNoMAP and GetReauthQueryEAP. Support for TestClient and TestVectorFile were removed from AuthAKA.pm and related files because they are obsolete. Use AuthAKATEST or ServerWXMAP based configurations for testing.
• A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
• SCTP multihoming is now supported. Requires Radiator 4.22 and Radiator Radius::UtilXS package.

Also, for more information, please do not hesitate to contact us at info@radiatorsoftware.com . See also Radiator SIM Pack product page.

Make your Radiator log data searchable

This is the first part of blog series that helps you to use log data that Radiator generates. Jump to second part.

Radiator exports AAA (authentication, authorisation, accounting) data to various formats. You can process the log data further by other log collection systems, such as Splunk and Elasticsearch. In this article, we briefly describe how to export data in JSON format. The common use case is to record the metrics that best describe your environment, for example, authentication, and authorisation messages.

The image below shows you an example of visualised Radiator worker statistics. The graphics were created with Grafana. Click the image for a larger view.

Adding a new field

With Radiator, it is possible to export log data in JSON format (for more information, see JSON.org). Basically, JSON is a set of name-value pairs. The values can also be ordered lists and it is possible to nest lists inside other lists. This makes it possible to express complex data structures in an universal manner with JSON.

Usually, the hardest part in modifying configuration is to figure out how to synchronise modifications everywhere, especially if the logs are centrally collected and parsed. For example, if Client-Identifier or some other RADIUS attribute is added to a log message when authentication fails, you have to ensure the log parser engine understands the new field.

This is an example of AuthLog FILE, which has date, username, and result.

Wed May 18 15:48:44 2016:mikem:FAIL

If you add a new field, the log entry looks like this:

Wed May 18 15:48:44 2016:mikem:client-1:FAIL

Here is the same information as a default JSON message without the new field:

{"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication"}

Here is the JSON message with the new field: {"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication", “client”:”client-1”}

With JSON, it is easy to add the new field to Radiator log message. Usually, there is no need to modify the parser configuration since the fields are just a group of name-value pairs and not fixed together in any way.

Configuring Radiator

The configuration process is straightforward: add Log <FILE, SYSLOG, ...> clause and use it in the same way as existing ones to your Radiator config and you are done. With Radiator, you can customise your own LogFormatHook and add, remove, or modify the fields. This is how Radiator extends the log usage possibilities even further.

Note: The following configuration example needs Radiator 4.16 with latest patches. You must have JSON module installed. JSON::XS module is recommended (see https://metacpan.org/pod/JSON and https://metacpan.org/pod/JSON::XS).

Configuration example: JSON output to radius.cfg (source goodies/logformat.cfg):

---

# This logger logs events in JSON format. It requires the Perl JSON

# module. Note the specific requirement for loading the logger module.

<Log FILE>

       Identifier mylogger-json

       Trace 4

       Filename %L/logfile.json

       LogFormatHook sub { Radius::LogFormat::format_log_json(@_); }

</Log>

# This auth logger logs both successes and failures to a JSON file.

<AuthLog FILE>

       Identifier myauthlogger-json

       Filename %L/authlog.json

       LogFormatHook sub { Radius::LogFormat::format_authlog_json(@_); }

       LogSuccess 1

       LogFailure 1

</AuthLog>

# This is the Handler-clause.

<Handler>

   <AuthBy FILE>

       Filename %D/users

   </AuthBy>

   AuthLog myauthlogger-json

   # Log accounting messages in JSON format.

   AcctLogFileName %L/acctlog.json

   AcctLogFileFormatHook sub { Radius::LogFormat::format_acctlog_json(@_); }

</Handler>

---

In this example configuration, all log data is saved into a single file. This may cause problems in the real configuration because of increasing log data file size. You can avoid this by using log rotation tools, for example, logrotate in Unix-based systems. Rotating log files can safely be done without restarting Radiator. Radiator also supports the special characters in the file names.

Do you want to know more?

Your JSON files are now ready, the next step is to use them efficiently. In the next part of the series, we will introduce the more detailed use cases, which will help you get the most out of Radiator logging.

Using Radiator for Wi-Fi offloading: how to make savings in mobile packet core network

With Wi-Fi offloading, mobile operators can transfer traffic from their Evolved Packet Core network to Wi-Fi networks. One of the key reasons for this is cost savings - as an example from Radiator customer can demonstrate.Our customer has currently 50,000 public hotspots in their country - the best Wi-Fi coverage in the nation.

Hotspots in the country by operator

In order to get the most out of their Wi-Fi network, a solution was needed for automatic SIM authentication for mobile users. For this, our regional partner implemented a solution with Radiator SIM Pack for the customer. This enabled them to increase the network usage from 1 M usages  per month to over 70 million usages per month. A key component, in addition to Radiator SIM Pack, was iPhone Carrier Bundle with auto connect - that provides automatic authentication to the end-user.

After the initial surge, customer still sees growth of 13 % per month.

The current progress of WiFi Auto Connect usage

Because of the solution, customer is now offloading almost 600 TBytes of data from evolved mobile packet core (EPC) each month - and the amount is still growing. If cost of each GByte to the EPC is around USD $4, the customer is saving over USD $2M per month - and over $24M per year!

Amount of offloaded data by month

Interested in Wi-Fi offloading?

If you have interest in Radiator solutions for Wi-Fi offloading - please do not hesitate to contact our sales team at info@open.com.au