Description
The Registration Operator (RO) is a functional role defined within the 5G System (5GS) architecture, specified in contexts like secondary authentication/authorization and network slice-specific authentication and authorization (NSSAA). Conceptually, the RO is a network operator—distinct from, but possibly the same as, the primary Serving PLMN (Public Land Mobile Network)—that holds the subscription and service profile for a user regarding a particular service or network slice instance. When a UE requests access to a service that requires separate credentials (e.g., an enterprise service, a third-party application service, or a specific network slice), the primary network (the Visited PLMN or Home PLMN) may interact with the RO to authenticate the user specifically for that service context.
Architecturally, the RO interacts with the 5G core network functions, primarily the Authentication Server Function (AUSF) and the Network Slice-Specific Authentication and Authorization Function (NSSAAF). In a secondary authentication flow, the UE establishes a primary connection with its home PLMN (HPLMN). Upon attempting to access a service requiring secondary authentication, the Session Management Function (SMF) may trigger an EAP-based authentication dialogue. The AUSF in the HPLMN then acts as an EAP authenticator, proxying the authentication messages to the RO's authentication server, which holds the user's credentials for that service. The RO validates the credentials and authorizes access to the requested service or slice.
In the NSSAA procedure for network slicing, when a UE requests a slice that requires separate authentication (S-NSSAI with Authentication/Authorization required), the AMF invokes the NSSAAF. The NSSAAF communicates with the RO associated with that specific S-NSSAI. The RO performs the slice-specific authentication and authorization, returning a result to the NSSAAF and AMF, which then allows or denies the UE's registration for that slice. The RO's role is thus to decentralize authentication authority, enabling multi-operator service delivery, enterprise network integration, and flexible business models where the service provider (the RO) is separate from the connectivity provider (the PLMN).
Purpose & Motivation
The Registration Operator concept was introduced to address the evolving business and technical landscape of 5G, particularly network slicing and service-based architecture. Previous generations (4G and earlier) primarily relied on a single, monolithic authentication via the home PLMN using the (U)SIM credentials. This model was insufficient for 5G's vision of supporting diverse vertical industries (e.g., automotive, healthcare, manufacturing) where a third-party service provider (like an enterprise or a cloud provider) needs to control access to its specific network slice or service independently of the mobile network operator providing the radio connectivity.
Its creation solves the problem of delegated authentication and authorization. Without the RO model, the HPLMN would need to manage all credentials for all possible third-party services, creating scalability, security, and business relationship complexities. The RO allows the service provider to retain ownership of the user's service-level identity and policy. This enables new business models, such as a factory owner (the RO) contracting with a mobile operator for a private 5G slice and directly managing which employees or devices can access that slice.
Furthermore, the RO facilitates regulatory and operational separation. In scenarios like neutral host networks or multi-operator core networks (MOCN), different operators might act as the RO for their respective subscribers sharing the same radio infrastructure. It also enhances security by compartmentalizing authentication domains; a breach in a third-party RO's credentials does not compromise the user's primary mobile network subscription. The motivation stems from 3GPP's work on secondary authentication (from EPC) and its formalization in 5G for slice-specific access control, providing the architectural hooks needed for a truly multi-tenant, service-oriented 5G ecosystem.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (3 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-9, normative work from Rel-16.
In Release 16, the Registration Operator (RO) function was newly introduced within the Common API Framework (CAPIF) to define architectural requirements and procedures for the registration of API provider domain functions on the CAPIF core function. This specifically enables the capability to register, update, and manage the registration information of these domain functions, which can include roles like API Exposing Function (AEF) and API Management Function (AMF). The procedures detail the information flows for registration requests and responses between the API management function and the CAPIF core function.
In Release 19, the new capability for the Registration Operator (RO) function is that the CAPIF Core Function (CCF) can now obtain RO authorization information. This information is used by the CCF, acting as the Authorization Function, as part of the API invoker authorization process to grant permission for accessing a resource owner's resources via a service API.
- CCF obtaining RO authorization information TS 23.222CR0282
Explore further
Broader topics and technologies where RO plays a role.
Defining Specifications
3GPP specifications that define or reference RO, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.222 vj80 | Common API Framework for 3GPP Northbound APIs | Rel-19 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TS 28.628 vj00 | SON Policy NRM IRP Information Service | Rel-19 |
| TS 32.522 vb70 | SON Policy NRM IRP Information Service | Rel-11 |
| TS 33.812 v920 | M2M Remote Subscription Management Security | Rel-9 |
| TR 38.864 vi10 | Technical Report on Network Energy Savings for NR | Rel-18 |