What is the Twilio Mobile Core?

September 25, 2019
Written by
Twilion

Twilio Mobile Core Header

At Twilio’s 2019 SIGNAL Conference, we presented the Twilio Mobile Core as the engine behind Twilio’s Super SIM. A Mobile Core provides all the functionality required to enable a device with wireless capabilities to connect to the cellular network independent of its radio technologies (4G, 5G, etc.). 

Let’s talk about Twilio’s Mobile Core implementation – along with how it helps you.

What is a Mobile Core?

A Mobile Core comprises different network functions defined by several standardization bodies. The 3rd Generation Partnership Project (3GPP) is the primary group that focuses on mobile network architectures and protocols. 

In the past decades, 2G/3G/4G network functions have been implemented as dedicated hardware-based appliances. Unlike most other deployments, our Mobile Core implementation is 100% software based and deployed on Amazon Web Services. 

Why does Twilio have a Mobile Core?

You may be wondering: what’s Twilio doing with a Mobile Core? 

Our Mobile Core allows us to meet developers’ expectations for: 

  • global scale
  • high availability
  • fast iteration cycles

By owning our Mobile Core, Twilio gives you and your customers the lifecycle control you really need for your fleets of IoT devices. 

Flexibility is another key element we can provide you: with our REST APIs you can build new use cases that weren’t possible – or economically feasible – before. Additionally, we help provide insights which are extremely useful when you start scaling your fleets of devices. 

How does the Twilio Mobile Core work? 

Let’s assume you have an IoT device – a scooter for instance – and you’d like internet connectivity. Maybe you want your customers to be able to unlock it and use it. 

Well, the first thing you need to do is to buy a Super SIM from Twilio. That’s easy!  

The Super SIM represents the physical device containing the “secrets” utilized to register with the network. This procedure is named attachment in the telecommunications domain. Attachment is needed to authenticate and authorize the device to connect to a network, and ultimately grants the device internet connectivity. 

How a device connects to the network

In a very simplified view, your scooter connects to the nearest Radio Access Network (RAN), acting as the first point of contact between the device and the carrier network. The core network receives the signal from the device, including the information contained in the SIM card (such as the International Mobile Subscriber Identity (IMSI)) and authenticates/authorizes the device to connect to the network (the green line in the picture below). 

Carrier connectivity to network

The IMSI contains the Mobile Country Code (MCC) and the Mobile Network Code (MNC) as prefixes, which are used for identifying the SIM card’s carrier network. In addition, the IMSI includes the Mobile Subscription Identification Number (MSIN) used to identify the subscriber within the carrier network. 

For instance, the following IMSI, `3102401234567890`, contains MCC `310` and MNC `240`, which identify `T-Mobile` as the carrier, and MSIN `1234567890`, identifying a specific account number in that network.

MCC, MNC, MSIN diagram

Once the authentication procedure is completed, a set of dedicated tunnels known as dedicated bearers (the red-dotted lines above), are established between the device and the user plane entities of the carrier network. These act as breakout entities towards the internet. 

While roaming, the attachment procedure is similar – the only difference is, initially the scooter will interoperate with the visited operator core network (known as the Visited Public Land Mobile Network (VPLMN)). Based again on the MCC and MNC contained in the IMSI, that traffic is home routed and the IMSI’s owner can decide whether or not to authorize the device to connect to the network while roaming. 

Carrier connection when roaming

Roaming scenarios are very important for IoT use cases where devices are deployed all around the world. 

Background on LTE architecture

Now, let’s look at an overview of LTE architecture.

Scooter connection to IP backbone when roaming
  1. During the attachment procedure, the device (here the modem contained in the scooter) will scan for the nearest cell tower to connect to (1).

    This procedure is typically initialized by the base stations and terminated at the Mobility Management Entity (MME) node of the VPLMN. The MME is one of the central components of the VPLMN. The MME identifies whom the IMSI belongs to by extracting the MNC and MCC fields.

    This particular case is a roaming scenario; the MME will need to talk to the Home Subscriber Service (HSS) of the Home PLMN in order to authenticate and authorize the scooter to connect to the network. The HSS is a database owning that IMSI and all the associated subscription information.
  2. The protocol used for exchanging Authentication, Authorization, and Accounting (AAA) messages between the MME and the HSS is called Diameter (2).
  3. Once the HSS gives an `OK`, ​​the MME determines which internet gateway to use for sending internet traffic. In LTE architecture, this gateway is called the Packet Data Network Gateway (P-GW). In order to figure out which PGW to use, the MME performs a simple DNS query to get the PGW’s IP.

    This is handled via a simple DNS lookup of the Access Point Name (APN), to the HPLMN DNS server (3).
  4. Once the selection is done, the MME instructs the Serving GW (SGW) to establish a GPRS Tunnel Protocol (GTP) tunnel with the selected P-GW (4). 
  5. Once the required tunnels are established, the device can connect to the internet (5 [dotted red-lines]).  

And that’s it, at a high level. At a lower level, see the 3GPP’s Specification document(s) for 2G/3G and LTE networks.

The Twilio Mobile Core: Resilient, Customizable, and Insightful

As already mentioned, the Twilio Mobile Core is 100% software-based and stateless by design. It comprises a set of components required to support all the existing Radio Access Technologies. 

In the Twilio Mobile Core, we adopt a continuous deployment strategy. We use Twilio platform toolkits such as Lazarus, our remediation system, to replace hosts with poor health. 

We’re integrated with event streaming platforms like Kafka and Elasticsearch to collect and analyze events produced by the network.

Super SIM API

This allows us to provide you powerful APIs providing fine grained control over your fleets of devices. Listen to the presentation given by Jonas Boerjesson, our Senior Software Architect, at SIGNAL 2019 to understand more about our Mobile Core and the use cases empowered by Super SIM:

Our SIGNAL presentation is just the beginning. Our agile process allows us to deliver innovative features that support your evolving use cases. We can’t wait to see what you build on top of our Mobile Core!

Super SIM is powered by the Twilio Mobile Core. If you'd like to learn more about Super SIM and sign up for the beta, visit us here.

Giuseppe Carella is an Associate Engineering Manager on Twilio’s Wireless IoT team. He is currently managing the Super SIM team, focusing on the API layers between the Twilio Mobile Core and Twilio’s customers. He can be reached at gcarella [at] twilio.com.