Description
The Application Relation is a fundamental architectural concept in 3GPP standards that defines the relationship and interaction between the 3GPP network domain and external application providers. It establishes a standardized framework for service exposure, allowing authorized third-party applications to securely access network capabilities and information. The AR encompasses the protocols, interfaces, security mechanisms, and business agreements necessary for this interaction, serving as the boundary where network services are made available to the application layer.
Architecturally, the AR is implemented through specific reference points and network functions designed for service exposure. In earlier 3GPP releases, this was primarily realized through the Open Service Access (OSA) framework and later evolved into more sophisticated architectures like the IP Multimedia Subsystem (IMS) Service Capability Interaction Manager (SCIM) and the Service Capability Exposure Function (SCEF) in 4G, eventually leading to the Network Exposure Function (NEF) in 5G. These functions act as gateways, controlling and mediating access to network services such as user location, presence information, quality of service control, and device triggering.
The operation of an AR involves several key components: the exposure function (e.g., NEF, SCEF), which authenticates application requests and translates them into network-internal commands; the application server, which resides in the external domain and consumes the exposed capabilities; and the standardized APIs (Application Programming Interfaces) that define the communication protocol. Security is paramount, enforced through authentication, authorization, and accounting (AAA) mechanisms, often involving OAuth 2.0 and API key management. The AR also defines charging models and service level agreements (SLAs) between the network operator and the application provider.
In the network ecosystem, the AR plays a critical role in enabling new business models and service innovations. It allows operators to monetize their network assets beyond basic connectivity by exposing valuable capabilities to vertical industries (e.g., automotive, healthcare, IoT). For application developers, it provides a consistent, carrier-grade interface to enhance their services with network intelligence, such as ensuring low latency for real-time applications or triggering devices to wake up and receive data, which is essential for battery-constrained IoT devices.
Purpose & Motivation
The Application Relation was created to address the growing need for a secure and standardized method for third-party applications to interact with telecom network capabilities. Prior to its standardization, application integration was often achieved through proprietary, vendor-specific interfaces, which were costly, complex, and hindered service innovation and interoperability. The AR provides a common framework that decouples application development from underlying network technology, fostering an open ecosystem.
Historically, the concept was introduced in 3GPP Release 6 as part of the push towards all-IP networks and the development of IMS. It solved the problem of 'walled gardens' by allowing trusted external partners to access network services in a controlled manner. This enabled new revenue streams for operators through service exposure and allowed for the creation of richer, context-aware applications that could leverage network data like user location or session status.
The evolution of the AR reflects the changing landscape of telecommunications, from voice-centric services to data-driven applications and the Internet of Things. It addresses the limitations of previous ad-hoc integrations by providing a scalable, secure, and billable interface. This is crucial for supporting diverse vertical industry requirements in 4G and 5G, where applications in automotive, industrial automation, and healthcare demand reliable access to network-controlled parameters like latency, bandwidth, and device management.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (22 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-6, normative work from Rel-15.
In Release 15, the "AR" (Application Relation) function itself is not explicitly defined or newly introduced within the provided grounding context. The context details various application-layer concepts like the MTC Server acting as a Services Capability Server for an Application Server, but does not specify a new "AR" function. The listed Change Request title, "Relation between SSB and SS-Burst," pertains to physical layer synchronization signals and is not directly related to the application relation function as described in the architectural excerpts.
- Relation between SSB and SS-Burst TS 38.300CR0096
In Release 16, the update for the AR function specifically introduced enhancements to the "Use Case" for AR/MR Device Types. This involved refining the framework and application interface definitions to better support the service enablers and application protocols for these advanced devices. The changes aimed to facilitate the application relationship within the network architecture for such specialized user equipment.
- Use Case Update for AR/MR Device Type TS 26.928CR0001
In Release 17, the enhancements for the Application Relation (AR) function introduced new security requirements specifically for critical medical applications. Additionally, the release provided clarifications for the application of slice-based Random Access Channel (RACH) configuration procedures.
In Release 18, the Application Relation (AR) function introduced support for split rendering negotiation and media re-negotiation for AR applications, including an implicit neural representation format for AR scenes. These enhancements were facilitated by updates to the media control API to handle AR media re-negotiation indications and to meet new application server requirements.
- EN resolution on AR media TS 29.176CR0001
- Application Server related requirements from FS_Resident (pirates) TS 22.261CR0534
- [FS_5GSTAR] Implicit Neural Representation format in AR Scenes TS 26.998CR0003
- Support of AR media split rendering negotiation TS 24.186CR0010
- Add the Media re-negotiation indication to Nimsas_MediaControl API to support AR TS 29.175CR0011
In Release 19, the AR function was enhanced to support the standalone Data Channel (DC), including procedures for network-initiated peer-to-peer application data channel establishment and interworking via the DC Application Server. Updates also addressed application data channel multiplexing, application-specific PDU handling, and refined application error handling for services like Nimsas_ImsEE with the addition of specific HTTP response codes such as MEDIA_ID_CONFLICT. Corrections were further applied to AR communication procedures and media instruction data types.
- Update session control and DC application related requirement to support the standalone DC TS 24.186CR0039
- Procedure of network initiated P2P application data channel establishment TS 24.186CR0062
- Procedure of application data channel interworking via DC AS for originating UE TS 24.186CR0065
- The requirement of the UE related to DC application in 8.1 TS 24.186CR0087
- Update on IMS data channel application for standalone data channel TS 24.186CR0094
- Handling of application data channel multiplexing TS 24.186CR0096
+ 7 more changes
Explore further
Broader topics and technologies where AR plays a role.
Defining Specifications
3GPP specifications that define or reference AR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 22.261 vk30 | 5G System Service Requirements | Rel-20 |
| TR 22.804 vg30 | 5G Automation in Vertical Domains Study | Rel-16 |
| TS 22.823 vg10 | IMS enhancements for new real-time communication services | Rel-16 |
| TR 22.832 vh40 | Study on cyber-physical control in vertical domains | Rel-17 |
| TR 22.873 vi00 | Technical Report on IMS Multimedia Telephony Service Enhancements | Rel-18 |
| TR 23.976 vj00 | Push Service Requirements Analysis | Rel-19 |
| TS 24.186 vj60 | IMS Data Channel applications | Rel-19 |
| TS 26.119 vj00 | XR Media Capabilities for AR Devices | Rel-19 |
| TS 26.141 vj00 | IMS Messaging & Presence Media Formats | Rel-19 |
| TS 26.506 vj20 | Real-Time Media Communication Architecture for 5G | Rel-19 |
| TS 26.567 vj00 | IMS-based Split Rendering | Rel-19 |
| TR 26.806 vi00 | Technical Report on Smartly Tethering AR Glasses | Rel-18 |
| TR 26.812 vi10 | Technical Report | Rel-18 |
| TR 26.857 vi00 | Technical Report on Media Service Enablers | Rel-18 |
| TR 26.862 vh00 | Immersive Teleconferencing & Telepresence for Remote Terminals | Rel-17 |
| TR 26.865 vi00 | Technical Report | Rel-18 |
| TR 26.928 vj00 | Study on eXtended Reality (XR) in 5G | Rel-19 |
| TR 26.933 vj00 | Study on Diverse Audio Capturing System | Rel-19 |
| TR 26.956 vj01 | Beyond 2D Video Formats & Codecs Study | Rel-19 |
| TR 26.998 vj00 | 5G AR/MR Glasses Integration Study | Rel-19 |
| TS 29.175 vj40 | IMS AS Service-Based Interface Protocol | Rel-19 |
| TS 29.176 vj40 | Nmf Service Based Interface for Media Function | Rel-19 |
| TS 38.300 vj00 | NG-RAN Overall Description | Rel-19 |
| TR 38.835 vi01 | Technical Report on XR Enhancements for NR | Rel-18 |
| TR 38.838 vh00 | Study on XR Evaluations for NR | Rel-17 |