What's in a Name?
“It has been said that the principal function of an operating system is to define a number of different names for the same object, so that it can busy itself keeping track of the relationship between all of the different names.” – David Clark, RFC 814
As I’ve come up to speed on the mobile cellular network, it’s been interesting to learn about the design decisions made over the years. And it’s natural (for me) to compare those decisions to how the Internet addressed similar problems. Being a student of system design, the opportunity to compare two similar systems that evolved in parallel over the same 40-year time period is one I can’t resist. My favorite example is global identity management, which puts me in mind of the most influential paper I read as a grad student many years ago: Jerry Saltzer’s Lecture Notes on Naming and Binding of Objects (which he later amended with RFC 1498).
For starters, I’ll assume everyone understands how IP addresses serve as a globally unique identifier for every device that wants to send and receive packets on the Internet, and how routers “interpret” these identifiers to carry out the process of packet delivery. A critically important design decision is that these unique ids are independent of any addresses used by the underlying networking technologies (802.3 and 802.11’s 48-bit addresses being the canonical example), with each network technology providing an IP-to-Physical address mapping mechanism (e.g., ARP).
In the mobile cellular network, the objective is to build a global Radio Access Network (RAN), where any two RAN-connected devices can communicate, no matter where they are currently located and how often they move. And to support this global connectivity, each device is assigned a globally unique identifier, called an IMSI (International Mobile Subscriber Identity). This IMSI, which is “burned" into the device’s SIM card, is a 64-bit, self-describing identifier that is commonly represented as a 15-digit decimal number. For example, the following is an interpretation we use in a Private 5G implementation:
MCC: Mobile Country Code (3-digit decimal number).
MNC: Mobile Network Code (3-digit decimal number).
ENT: Enterprise Code (3-digit decimal number).
SUB: Subscriber (6-digit decimal number).
The first two fields (MCC, MNC) uniquely identify the MNO (Mobile Network Operator), while the last two fields are one example of how an MNO might use additional hierarchical structure to uniquely identify every device it serves. (When providing 5G connectivity to enterprises, an ENT field makes sense, but other MNOs might assign the last 9 digits using some other structure.) The MCC and MNC play a role in roaming: when a device tries to connect to a “foreign network” those fields are used to find the “home network”, where the rest of the IMSI leads to a subscriber profile that says whether or not roaming is enabled for this device. It’s then the responsibility of the Mobile Core to “interpret” IMSIs in support of global connectivity.
There are two equally valid views of the Mobile Core. The Internet-centric view is that each local instantiation of the Mobile Core (e.g., serving a metro area) acts as a router on the global Internet. In this view, IP addresses serve as the unique global identifier that makes it possible for any RAN-connected device to communicate with any Internet addressable device or service. The 3GPP-centric view is that a distributed set of Mobile Cores (interconnected by one or more backbone technologies, of which the Internet is just one example) cooperate to turn a set of physical RANs into one logically global RAN. In this perspective, the IMSI serves as the global identifier that makes it possible for any two mobile devices to communicate with each other.
Both of these perspectives are correct, but since broadband communication using Internet protocols to access cloud services is today’s dominant use case, taking the Internet-centric perspective of the Mobile Core makes sense. But the 3GPP-perspective is still there, making it worth a closer look at its underlying design rationale and the consequences of those decisions as the two networks become increasingly integrated.
For starters, a careful reader will likely have already objected to my use of the term “identity” instead of “identifier” since we’re talking about devices and not principals. But the word “identity” is explicitly part of an IMSI because the assumption is that it uniquely identifies a subscriber (the “S” in both SIM and IMSI). The device and the customer using the device have been conflated in the 3GPP architecture, which of course breaks down when there could be tens or hundreds of IoT devices for every person, with no obvious association among them. Accounting for this problem is the first “architecture alignment” fix we had to make when trying to provide Private 5G Connectivity as a managed cloud service.
Once you think of an IMSI as the mobile network’s equivalent of a 48-bit MAC address, the design makes more sense. This includes how addresses are assigned to ensure uniqueness: (MCC, MNC) pairs are assigned by a global authority to every MNO, each of which then decides how to uniquely assign the rest of the IMSI identifier space to devices. This approach is similar to how network vendors are assigned a unique prefix for all the MAC addresses they configure into the NIC cards and WiFi chips they ship, but there is a big difference: It is the MNO, not the device vendor, who is responsible for assigning IMSIs to SIM cards. This makes the IMSI allocation problem closer to how the Internet assigns IP addresses, but unlike DHCP, the IMSI-to-device binding is static.
This is important because, unlike 802.11 addresses, IMSIs are also intended to support global routing. (Here, I am using a liberal notion of routing, and focusing on the original 3GPP-perspective of the global RAN in which the Internet is just a possible packet network that interconnects Mobile Cores.) A hierarchically distributed database maps IMSIs onto the collection of information needed to forward data to the corresponding device. This includes a combination of relatively static information about the level of service the device expects (including the corresponding phone number and subscriber profile/account information), and more dynamic information about the current location of the device (including which Mobile Core instance, and which base station served by that Core, currently connects the device to the global RAN).
There are, of course, many more details—including how to find a device that has roamed to another MNO's network—but conceptually the process is straightforward. (As a thought experiment, imagine how you would build a "logically global WiFi" using just 802.11 addresses, rather than depending on the additional layer of addressing provided by IP.) The important takeaway is that IMSIs are used to locate the Mobile Core instance that is then responsible for authenticating the device, tracking the device as it moves from base station to base station within that Core's geographic region, and forwarding packets to/from the device.
Two other observations about the relationship between IMSIs and IP addresses are worth highlighting. First, the odds of someone trying to "call" or "text" an IoT device, drone, camera, or robot are virtually zero. It is the IP address assigned to each device (by the local Mobile Core) that is used to locate (route packets to) the device. In this context, the IMSI plays exactly the same role in a physical RAN as an 802.11 address plays in a LAN, and the Mobile Core behaves just like any access router.
Second, whether a device connects to a RAN or some other access network, it is assigned a new IP address any time it moves from one coverage domain to another. Even for voice calls in the RAN case, ongoing calls are dropped whenever a device moves between instantiations of the Mobile Core (i.e., uninterrupted mobility is supported only within the region served by a given Core). This is typically not a problem when the RAN is being used to deliver broadband connectivity because Internet devices are almost always clients requesting a cloud service; they just start issuing requests with their new (dynamically assigned) IP address.
So what have we learned? Certainly that reconciling identifiers across network architectures is a tricky exercise, especially when one of those architectures conflates device identifiers with principal identity, and is not able to dynamically reassign said identifiers when devices move. More importantly, though, this case study is a great reminder that while technology changes frequently, system design principles such as those articulated by Saltzer stand the test of time. We can expect the Internet’s IP addressing scheme, which embodies many of these principles, to define the global identifier that matters, while IMSIs may be reduced to providing value only within a physical RAN, similar to 48-bit MAC addresses in a physical LAN.
If you’d like some further detail on how mobile cores and RANs work, our book on 5G networks aims to explain these concepts to systems-oriented people. We’re in the process of writing a comprehensive update to that book with a focus on Private 5G–stay tuned for more details. On the SDN front, you can now view the panel discussion hosted by The Networking Channel on how SDN has taken off in the Asia-Pacific Region, with our Japanese colleagues Motonori Shindo and Kentaro Ebisawa joining Bruce for the session.