Hypermedia As The Engine Of Application State

Description

Hypermedia As The Engine Of Application State (HATEOAS) is a core principle of the Representational State Transfer (REST) architectural style applied within the 5G Core Network's service-based architecture (SBA). It dictates that a client (a Network Function, NF, consumer) should interact with a server (a NF producer) by following hypermedia links and forms embedded within the resource representations it receives, rather than relying on out-of-band API knowledge or hardcoded URLs. In practice, when a NF consumer (e.g., an AMF) requests a resource from a NF producer (e.g., an NRF), the response (typically in JSON format) includes not just the requested data, but also a set of `_links`.

These `_links` are Uniform Resource Identifiers (URIs) that indicate the possible next actions or related resources the client can access, such as `self`, `update`, `delete`, or links to other related NF services. The client's application state is driven by navigating these links. For instance, after discovering a Session Management Function (SMF) instance via the NRF, the AMF would follow the link provided for that SMF instance to initiate service-based communication (e.g., using the `nsmf-pdusession` API). The server dictates the available state transitions by which links it includes, allowing the server's API to evolve without breaking clients that simply follow links.

Within the 3GPP specifications (e.g., TS 29.501, TS 23.502), HATEOAS is implemented in the HTTP/2-based service-based interfaces like Nnrf (NF Repository Function), Nnef (Network Exposure Function), and Namf (Access and Mobility Management Function). The OpenAPI definitions for these interfaces include the schema for `Links` and `ProblemDetails` objects. This architectural approach decouples NF service consumers from the specific deployment topology and URI structures, enabling dynamic service discovery, load balancing, and graceful evolution of the network. The Network Repository Function (NRF) acts as a central hypermedia engine, providing the initial links that bootstrap the interaction between other NFs.

Purpose & Motivation

HATEOAS was adopted in 3GPP's 5G SBA to solve critical problems of scalability, flexibility, and maintainability in the core network. Traditional telecom interfaces were based on static, point-to-point protocols (e.g., Diameter) with rigid relationships. Adding a new network function or changing an API version required coordinated updates across multiple nodes, hindering innovation and network slicing. The purpose of applying HATEOAS is to create a loosely coupled system where network functions discover and interact with each other dynamically.

This addresses the limitation of hardcoded dependencies. A client NF only needs to know how to interact with a bootstrap endpoint (like the NRF) and how to interpret hypermedia links. The server NF controls the available interactions. This allows for seamless introduction of new services, versioning of APIs (by providing different links for different versions), and support for network slicing where different slices may have different instances of the same NF type. It empowers cloud-native principles in the 5G Core, enabling auto-scaling, self-healing, and continuous deployment, as new instances can register with the NRF and immediately become discoverable via the hypermedia links it provides without requiring reconfiguration of all potential consumer NFs.

Key Features

• Client interactions are driven by hypermedia links provided in server responses
• Decouples client and server, allowing independent evolution of URI structures and API versions
• Central to the dynamic service discovery facilitated by the Network Repository Function (NRF)
• Implemented using `_links` objects in JSON representations over HTTP/2
• Enables support for network slicing and cloud-native deployment models
• Reduces out-of-band coordination and configuration between network functions

Evolution Across Releases

Defining Specifications