Facing integration with the NEF
As you will know if you are around here, 5G networks have been (and will be) a breakthrough and a change in the way both end users and applications interact with the network. This is due to the fact that one of the “novelties” offered by 5G is the capability for applications (either deployed as part of the network core or from third parties) to interact with the network itself, requesting data from it or even requiring changes depending on the state of the network or the context of the application itself.
In this post, we will focus on one of the 5G components that offer this functionality, the NEF, and how we can take advantage of it using one of the applications of this project as an example.
First of all, what is the NEF?
The NEF (Network Exposure Function) is defined as a component of a 5G Core, located between the 5G core network and the third-party applications deployed over the 5G network, responsible for offering and managing the connections from the external applications that want to access to the internal data of the 5G core. In other words, this component offers access to the internal data from the 5G core to third-party applications, something that was not possible previously. In that sense, the NEF has appeared in the 5G standards as an intelligent, service-aware “border gateway” that will enable external applications to communicate with the 5G Network Functions securely. In this way, those external applications will be able to know, for example, the status of the network (i.e., in terms of congestion) and change its functionality accordingly.
But how can this be useful?
Let’s show it with an example. We’ll focus on 5GASP’s Network Application #4, Migrate, initially developed under the H2020 5Ginfire project [1][2]. This application belongs to the Automotive vertical, and its purpose is not only to deploy a digital twin of the vehicle’s on-board unit on its nearest location (the nearest EDGE node) but also being able to “migrate” that digital twin (called vOBU, virtual On-Board Unit) whereas the car moves. To do so, the original design relied on SDN (Software Defined Networks) and required a strong knowledge of the underlying infrastructure, that is, it was very infrastructure dependent. This means that the original solution was not easily interoperable, nor easy to be deployed over third-party infrastructures, since network operators or managers do not allow external applications to control their SDN management network — for safety concerns.
So, the previous design relied on SDN to detect the movement of the car, as they weren’t able to know when it had moved otherwise. And here is where the NEF appears on stage, as part of the information it offers to external applications is, apart from QoS aspects, the location of a certain UE. So, in this sense, instead of depending on SDN, the application can ask directly to the network for the location of the OBU and when the movement is detected (that is, there is an EDGE node nearer than the one previously used), ask for the migration of the vOBU to the new location. Furthermore, this change has also eased the migration process, as now it is based on the cell the car is connected to, which makes the process of selecting the best node easier, as it is possible to map the cell to its nearer EDGE node. Previously, a mapping between the switch that had detected the data from a new location (and that location) had to be performed, which means the whole process was more complicated.
So here you can find an example of the real usefulness of 5G networks, and how 5GASP can improve SMEs and small developers to adapt their applications or ideas to these scenarios, enabling applications that weren’t feasible before, in previous deployments of cellular networks.
[1] https://5ginfire.eu/ [2] J. Santa et al., “MIGRATE: Mobile Device Virtualisation Through State Transfer,” in IEEE Access, vol. 8, pp. 25848-25862, 2020, doi: 10.1109/ACCESS.2020.2971090.