How can an external service provider develop its own services using the 5G network? That's what we will see in this video. As we have seen, the 5G network has some knowledge of user's habits or what they are doing, if they are on the move. 5G networks also provide a way to reach the user. We know that several network functions provide a notification service, for example, the AMF or the SMF or the PCF. For this reason, it's interesting to allow third-party companies to develop services using the ability to reach UEs that 5G networks provide. But it has to be done in a secure way for both the 5G operator and the company providing the service. This requires secure and restricted access to the 5G network. By "restricted", I mean that the external company only has access to the services it has subscribed to. For this, we introduce the "Network Exposure Function" or NEF. As you can see on this diagram, the NEF is a gateway between the different functions of the 5G network, UDM, AMF, SMF, PCF, and the AF. The AF is the application function owned by the external company and on which it develops its own services. The application parts are generally represented on the top of the figures. The parts that are more related to the network are generally at the bottom. The interface between the NEF and the third party AF is called the north-bound interface. What procedures are available on these north-bound interface? Well, first of all, monitoring using notification services. Monitoring, for example, of a UE, where is it? Is the UE reachable? What is the UE's roaming status? Is the UE in its home network or abroad? Is the UE still connected? This can also be for a group of UEs, for example you might want a notification when there are more than a certain number of terminals in a given geographical area. Another service provided on the north-bound interface is device triggering, which is done using the "Short Message Service" or SMS. External parameters might also be provided by the third party company to the 5G network or "Packet-Flow Description" (PFD) which is usually related to the establishment of sessions with required quality of service level. Let's look at a small example. Let's imagine a utility company with a team that needs to do something in a certain place, for example, an electricity company that has to repair a power transmission line. Each of the people has a 5G terminal. The company specified the work area, the cells where the UEs are located, and the number and identity of the UEs, and asks the operator for a certain quality of service. The company is also able to describe the type of flows that are going to be exchanged and the quality of service required. Finally, some communications can be paid for by advertising. Thus, the party being charged might change when a session is setup or during a session. Let's have a look at two examples of procedures related to monitoring and triggering. Imagine there is a company that wants to be notified when a particular UE loses connectivity. This is a service provided by the AMF. The external AF never contacts the AMF directly, but instead sends a subscription request to the NEF specifying the type of event "loss of connectivity" and phone number in question. Indeed, the SUPI "SUbscriber Permanent Identity" remains internal to the 5G network and should never be communicated to the outside. So, we identify the UE by a phone number, for example. The NEF doesn't send the subscription request directly to the AMF, but rather sends it to the UDM in order to benefit from the translation of the telephone number into SUPI. Once this is done, the UDM acts as a relay and forwards the subscription request to the AMF. A positive acknowledgment is sent and the confirmation is sent back to the AF. When the event occurs, we can see that the notification is sent directly from the AMF to the NEF. This means that it's indeed the NEF that creates the callback URI so that this callback URI is just relayed by the UDM and the notification can be done directly. Let's take another example of device triggering procedure. Let's imaging the AF, wants to trigger a particular UE and makes a request to the NEF. The NEF checks that the AF is authorized to make this request may also do a load control since the AF may have a limited rate of trigger submissions for security reasons. The NEF then contacts the UDM to again request the conversion of the phone number into SUPI. Once the SUPI is retrieved, the NEF asks the UDM, which is the SMS center that manages the corresponding SUPI. 25 years ago, there would have been a consensus to merge these two messages into one. Today the consensus go the other way. Why is that? Well, because the APIs used and the services within the UDM are different. As we want to keep services completely independent, so we prefer to keep two separate response requests rather than merging them. This is an example of a new specification philosophy. Once the SMS center is known to the NEF, the request is sent to the SMS center and so on. There is nothing special to signify except there may be in the form of a notification, confirmation of delivery of the SMS. In summary, the NEF "Network Exposure Function" is a gateway between the 5G network and the AF "Application Function" of an external company that develops services. It enables the secure exposure of event notifications and also allows the external AF to securely provide information to the 5G network. The services provided by the NF generally build on existing services and all other existing NFS and the services they provide. The main objective of the NEF is to provide a secure way to develop services for external companies.
