What is the protocol stack for an SBI interface? How are the interactions between NFs organized? That's what we will see in this video. We have already mentioned that HTTP/2 is used for dialogues between NFs. It's an evolution of HTTP/1.1, providing smaller latency and greater reliability. In 5G, messages are encoded in JSON. The advantage of this format is that it's text-oriented. To interpret the messages, it's enough to read them. The emphasis is therefore on readability and also ease of evolution. To avoid having messages that are too long, we can use a compression algorithm, such as the well-known gzip, but also other algorithms currently on the rise like Brotli. Whenever possible, a REST approach is used. We will look at that in a few minutes. To make sure exchanges are secured, the TLS protocol, "Transport Layer Security" is proposed by default. Operators can use other means of security if they wish to do so. We have the following protocol stack between service consumer and service producer with HTTP/2, possibly over TLS, which is always over TCP itself, over IP. What do we mean by REST? REST stands for "REpresentational State Transfer". It's a very general concept that was defined in the 2000s by Roy Thomas Fielding in his doctoral thesis. One central notion in REST is the resource. What is a resource? A resource is an object with a type, associated data, and methods that allow you to operate on this object and it might possibly also have relationships with other objects, in other words, relationships between different resources. Let's look at a few examples to help us understand what we are talking about. A resource can be a text file, it can be an HTML page, an image, a video; but to take a more 5G context, it can be a subscriber profile or the status of a UE, I mean, for example the technology it is positioned on (4G, 5G or WI-FI) or it could be pointer, for example, to a video and so we find relationships between resources. For an API to be REST compatible, or what we call RESTful API, there are six constraints defined by Fielding. The first is to have a uniform interface to access or modify a resource. The second is a client-server approach. This is what we have in 5G. The third is what we call a stateless dialogue. This means that the server must treat each request as if it's a new request. It's not required to refer to any history or the elements needed to process the request are present in the request. There is no notion of session. We have a property related to this, known as idempotence. If we consider multiple successive identical requests, they must have the same effect as a single request. This means that there is the possibility of caching items. If several requests are sent and they are identical, an intermediary device can store the response it saw on the first request and respond directly to the subsequent requests to offload the server. There is the possibility of having a layered system. In this context, it's not about OSI layers. Rather, it's a question of so-called multi-tier architectures, where for example, we will separate the representation of data, the processing itself, and the storage, which can be implemented in different hardware. The sixth property is "code on demand", which is optional. With code on demand, a client can request the runtime code from a server. As we mentioned, one central notion in REST is the resource. Each resource in a 5G core network is accessed by its URI or "Uniform Resource Identifier", which has the following format. We start with a field called apiRoot, which includes the protocol used (HTTP or HTTPS when using TLS) and then includes the authority. The authority allows us to be sure that the resource is unique. An authority can be, for the operator Syldavia Telecom, http://syltel.com or https://5Goperator.fr for another operator in France. It could also be an IP address. This APIroot part is specific to the network operator. Then, there's something we've already seen: the name of the API, for example nudm-sdm for the UDM and the subscriber- data-management service, (of course, there are many other possible APIs) the API version to make it possible for the system to evolve and then an API specific part. This whole part is completely specified in the 3GPP recommendations. There is no flexibility unlike with the apiRoot. It's important to note that there is a hierarchical structure. We can define a parent and children, grandchildren, and so on. For an example of a URI that can correspond to resource in 5G, we have http://syltel.com, that's the apiRoot, nudm-sdm is the name of the API. We have then the version (V2). Then we specify the subscriber (SUPI, the identity) and the specific string "am-data" for the subscription data related to access and mobility. This hierchical structure can be represented as a tree. We can see for example the resources of the UDM as a tree and the root being the APIroot. We see the name of the API, then the version, which means for example that the profile of each subscriber will be indicated by a URI where we are going to find the IMSI of the subscriber, since in most cases, the SUPI is equal to the IMSI. The URI of a different subscriber with a different IMSI will have the same structure, but of course may have a different subscriber profile. Those are just a few examples. What is important is to see that here we define the resource and identify it without being concerned about where the corresponding data are physically stored. To conclude, in the REST approach, the central notion is the resource. With a slight exaggeration, we can say: everything is a resource. Each resource is identified by each URI, "Uniform Resource Identifier", which starts with the variable operator-dependent APIroot part, as well as a fully specified service-dependent part. Actions on resources are possible with HTTP/2, which can be used on top of TLS for security and is always above TCP/IP. In the following video, we will see more concretely what actions are possible on the resource.
