Today lets have a look at how the 5G Core (5GC) does Connection-, Registration- and Session-Management for 5G devices. As in the previous posts, the procedures are described in 3GPP TS 23.501 which is the 5G analog to the 4G LTE core network description in 3GPP TS 23.401. I guess the similar number is no coincidence.
Connection Management (CM)
While there are a few surprises, the 3 different types of management tasks are similar to what already exists today in the 4G EPC (Evolved Packet Core). When the device wants to communicate with the core network, be it because it has just been switched-on, or because it has been idle for some time and the network has temporarily removed the resources to transfer data (while IP addresses remain in place), it needs to establish a connection to the Access Management Function (AMF). This is referred to as connection management.
While an LTE device in the EPC can either be in CM-Connected or in CM-Idle state, a 5G UE can also be in ‘CM Connected + RRC Inactive state’ when connected to the 5G Core. This state is between CM-Idle and CM-Connected. I think this has been a lesson from LTE, where devices are quite often put into RRC idle state on the radio interface and thus to CM-Idle state towards to core network to conserve power. It doesn’t take long, however, before data needs to be transferred again which then requires a new connection to the core network. This is quite a bit of overhead. In 5G, this will be reduced by the AMF and gNB agreeing that the connection to the core network can remain in place while radio connectivity is removed for a while.
Registration Management (RM)
Being connected to the core network is great but, for example right after power on, the network does not know the mobile device as mutual authentication has yet to be performed and encryption parameters have to first be exchanged as well. This is part of Registration Management. So in most cases, a device that is in CM-Connected state is also in RM-Registered state, except for initial connection attempts. Again, the AMF node takes care of this.
Session Management (SM)
As discussed in part 5 of this 5G core network series, being registered doesn’t necessarily mean that a device also has an IP address. Requesting one, to be a bit superficial for a moment, is part of Session Management (SM), which is handled by the Session Management Function (SMF). The device reaches the SMF via the AMF, i.e. all session management traffic is run through the AMF, which then forwards it along. So perhaps there are a few things during session management that are also interesting for the AMF but I haven’t yet gone down deep enough to see what those would be. Once a session is established, the device usually has an IP address or an IPv6 prefix (or both) and can communicate with the Internet.
MAC Layer Sessions
While in the 4G EPC, devices are only assigned IPv4 addresses and/or IPv6 prefixes, the 5G core network also has a session type that does NOT use IP addresses for routing. These non-IP sessions are based on layer 2 MAC addresses and devices are free to run their own IP addressing scheme on top. The 5G core is only looking at the MAC layer for such sessions. Sounds weird at first but I can imagine such sessions might be useful should 5G radio networks be used in locations such as factories where lots of devices communicate with each other and layer 3 connectivity is managed outside of the 5G core.
MICO
So much for the 3 different types of management tasks in the 5G core. Before I close for today, let me jump back to connection management again for a second, because there is a new concept that does not exist in 4G which is referred to as Mobile Initiated Connection Only (MICO). A device can request the AMF to enable MICO mode which means that once the connection goes to idle, it’s not possible to inform the device of incoming (IP) packets from the Internet. This is probably quite useful for devices that run services which always connect to the server to deliver their data without being asked for it in the first place. As part of this, the server can then send its commands or data. If the server doesn’t, it has to wait until the device contacts it again. A typical smartphone or tablet wouldn’t request MICO to be activated but a lot of machine type applications will definitely benefit from this.
And that’s it for today, more details on Session Management coming up in the next post.