Take Control with Network Access Profiles for Super SIM

Take Control with Network Access Profiles for Super SIM

I’ve spent my academic and professional career — most recently as an Engineering Manager for Twilio’s Super SIM — thinking about cellular network technologies and the future of cellular connected devices. As the world starts to really embrace cellular connectivity for fleets of IoT devices, one thing that strikes me is how fragmented the global cellular ecosystem is and how impactful that becomes for our customers trying to deploy low-powered, inexpensive devices all over the world.

The way that the PLMN ecosystem (PLMN = Public Land Mobile Network, or the radio networks that our devices connect to) has ‘naturally’ evolved makes it really tricky to build one IoT device and ship it everywhere.  To put control back in the hands of device makers, we built a feature called “Network Access Profiles” into Super SIM.

I want to share with you today how we did it, and why we think you’ll appreciate it.

Why do I need Network Access Profiles?

Let’s assume you have a fleet of devices that you want to deploy in various countries. We’ll focus on just one of those countries — Middle Earth — as an example.

In Middle Earth there are five different mobile networks with different Radio Access Technologies (RAT) available and different pricing: networks A, B, C, D, and E:

From the Super SIM Available Networks page, you can see that E is not a supported network. Network D is expensive and A doesn’t provide 4G/LTE.  Therefore you want to ensure that your devices can only connect to networks B and C.

At a very high level all you need to do is to create a customized Network Access Profile (NAP) that exclusively enables networks B and C for Middle Earth, then ensure your Fleet of devices is configured to use the new NAP.

How do the Profiles work?

When a cellular device boots it searches for a network signal, and it initiates an attachment procedure for authenticating with its ‘home network’, which in this case is where the Home Subscriber Server (which also supports 2G/3G) of the Twilio Mobile Core is located.

During the first Attachment procedure, the HSS identifies the device based on the IMSI (international mobile subscriber identity) that it presents. In the case of Super SIM, each SIM has multiple options as to the IMSI it presents. The HSS evaluates network permissions for the IMSI presented, and decides whether a device is allowed to connect to a particular network or not. Those permissions are based on a cascading rule system.

First, the HSS evaluates the global rules we’ve defined at Twilio. Those global rules allow us to restrict access to only the complete list of networks we support; in the case of network E, we won’t allow connections from any device, regardless of the NAP configuration. Then, the HSS evaluates the Network Access Profile, allowing access only to the networks configured by you; in this specific case, only attachments to networks B and C will be allowed.

What happens when there is a network outage?

Cloud computing has enabled us to build amazingly resilient highly available backend systems. But our overall IoT solution will only be as reliable as its weakest link. It might happen that a specific mobile network has an outage.

When using the Network Access Profile, you should ensure you build in enough redundancy in every country by allowing multiple networks per country. In case of outages, the device should automatically switch to another available network. If Twilio detects a critical outage on a specific network, we’ll temporarily force the rejection of attachments to that network, to speed up the process of your device moving to its second enabled network.

Create a customized Network Access Profile

Let’s contrive an example case: you want to deploy your devices in Italy — after all, it's the most beautiful country in the world.

We can take a quick look at Frequencycheck.com and see that there are four networks in Italy with the following LTE frequency bands supported. You can cross-reference that against the Super SIM pricing and get these results:

But—wait a minute. According to the Super SIM pricing, Twilio only supports three networks in Italy, and one of them is called ‘WindTre’.

By querying the Twilio Networks API, you can see that Twilio’s WindTre has two possible “MCC MNC” combinations. That’s because Wind and Tre merged not long ago, becoming WindTre. And while Twilio prices WindTre as one network, there are two potential radio identifiers that your device may connect to (identifiers which used to belong to Wind and Tre respectively):

Our IoT device – designed for the European market – supports LTE bands 3, 7, and 20. These are common throughout the EU (but totally different vs., say, North America). So we are in luck! We have four networks to choose from, all at the same price, and all of which can support a connection from our device.

(In addition to being the world’s most beautiful country, it appears that Italy is also the world’s most boring example for Network Access Profiles 🇮🇹😂.)

Let’s make this scenario a little more interesting: imagine your users have reported that Vodafone towers are performing much slower for your particular IoT device than the towers of TIM or WindTre. Perhaps there is a particular radio optimization supported by your device that Vodafone hasn’t implemented yet (this is contrived — Vodafone has an excellent network!).

This would be easy to solve: we could simply create a NAP that blocks connections to Vodafone. This shouldn’t cause any major gaps in coverage — we will still have multiple levels of redundancy, with all three european LTE bands remaining supported on two separate networks once Vodafone is disabled:

Step 1. Create a Network Access Profile for Italy

Step 2. Associate it with a Fleet

Step 3. Associate the Fleet with your Italian SIMs

Done! Our Italian SIMs now avoid connections to the Vodafone network, because Twilio’s HSS will reject Attachment requests based on the rules in the NAP.  If the issue is ever resolved, we can simply re-enable Vodafone.

What’s next?

Try out Super SIM! And let me know if you have any questions about the Super SIM architecture, Network Access Profiles, or cellular network design in general.

Start exploring Super SIM

• Read the announcement blog
• Learn how to test Super SIM with Adafruit Feather FONA 32u4 and Arduino MKR GSM 1400 
• Attend the Super SIM webinar on June 30th
• Subscribe to the Twilio Change Log for new feature notifications
• Order SIMs to try, check out the pricing, or chat with sales

Giuseppe Carella is an Engineering Manager on Twilio's IoT & Wireless team. His current teams are focusing on the API, usage and billing for the Super SIM and Programmable Wireless products. He can be reached at gcarella [at] twilio.com.