Reachability in 5G obvious?
The reachability in 5G seems obvious. I mean, everybody in the telecom industry has been familiar with the “Call Forwarding on Unreachable” Supplementary Service since… well, always. A GSM phone would be unreachable because it was powered off, lost coverage, ran out of battery, put into airplane mode, drowned or thrown under a truck. The network would have some mechanisms – timers, periodic updates, paging – to have some knowledge of whether a UE is reachable at a given moment or not.
It is interesting to see that in a short list of the basic functionalities of one of the absolutely central Network Functions in the 5G Core – the Access and Mobility Management Function, AMF – “reachability management” seems to be in the same category as handling the UE’s Registration or mobility handling procedures.
Is there perhaps some new “reachability” concept then, different from what we traditionally understood under the term?
Well, in some sense, yes. Reachability as such is of course still the same it always was – a “reachable” UE can receive incoming communication. Not a great feat for Connected UEs – those are the ones with a currently existing signalling or data connection, assigned resources, UE contexts and bindings stored in various network functions between the UE and the remote end it exchanges information with. For UEs that are not in Connected Mode reachability is guaranteed with a paging mechanism that enables the network to call out to a UE that incoming communication requires it to present itself, and make itself available. This has not changed.
The standardization of the 5G systems comes with a realization that the focus on the network users is drastically shifting – from humans to machines. What we have understood with the advent of IoT is that a big percentage of devices (that do behave differently than humans with their calls, applications and internet browsing) need to only send small amounts of infrequent data. Various meters, sensors, alarms send just a few octets now and then, possibly in a period spanning weeks or months. These devices are also pretty focused on preserving their batteries, as they are often in hard to reach places where changing the battery is very difficult, or even impossible. In an understanding of that characteristic the required battery lifetime in the guidelines for simple IoT devices reach up to 10-15 years.
The most efficient way of battery preservation is of course switching a device off. Without the need to activate the radio transmitter or receiver the same battery can last for years instead of hours (as in the case of smartphones). And when we look at devices, not smartphones – the very same devices that only need to communicate seldom – this seems the perfect approach. Switch off the radio components for a month, switch them on for a scheduled transmission, then go back to sleep. Meaning – become unreachable. Such a battery saving scheme, simple and efficient, unfortunately does create a problem – what if the network would like to send something to the UE? The device has its receiver switched of, therefore it will not hear paging messages. And this would be a normal mode of operation for the device, creating a big problem for the Application Server should it want to send anything to the UE – like provide a firmware upgrade to the UE.
So, yes, reachability becomes much more of an issue in the IoT environment, both in 4G optimised for IoT (LTE-M, NB-IoT) and in 5G where mMTC is one of the basic Use Cases. For that very reason already in 4G some new features were designed for the network to acquire knowledge on the expected transmission/reachability times of the devices. 5G takes these initial solutions much further, acknowledging the fact that IoT devices will probably spend big parts of their lives dormant, waking up – and becoming reachable – only at times, and for rather short periods. A whole sequence of signalling exchanges, with dedicated messages and parameters has been created for the external Application Function (that knows what data and when the device will send) to share that knowledge with the 5G Network Functions responsible for paging, mobility handling and the actual data transfer.
If you are interested in the application-specific information that can be shared by the AF with the 5G networks – Mobility Patterns, Expected UE Behaviour, Traffic Patterns – visit our 5G Core Network Architecture training.