Description
An Application Service Provider (ASP) is a fundamental architectural component in 3GPP networks that represents an external entity providing application-layer services to end users. The ASP operates outside the trusted domain of the mobile network operator but interfaces with it through standardized reference points and Application Programming Interfaces (APIs), primarily defined in the 3GPP Service Capability Exposure Function (SCEF) and Network Exposure Function (NEF) architectures. The ASP hosts the application servers, executes service logic, manages user data specific to its services, and initiates communication with User Equipment (UE) or network functions to deliver its services. This separation allows for specialized service development while leveraging the connectivity, security, and subscriber management of the 3GPP network.
The technical operation of an ASP involves several key interfaces. For machine-type communication and IoT services, the ASP interfaces with the SCEF (in 4G) or NEF (in 5G) using standardized RESTful APIs (e.g., based on HTTP/JSON). Through these interfaces, the ASP can request network capabilities such as device triggering (sending control messages to wake up or command UEs), monitoring specific events (like UE reachability, location changes, or communication failure), and accessing network information (with user consent). The ASP authenticates itself to the network, and its requests are authorized based on policies and subscription data. The network then acts on these requests, providing the ASP with the requested service or information while maintaining network security and subscriber privacy.
Architecturally, the ASP is a logical role that can be fulfilled by various real-world entities: a corporate IT department providing enterprise applications, a cloud service provider offering SaaS, an IoT platform managing connected devices, or a content provider delivering media services. In the 5G System (5GS), the ASP's interactions are more granular and service-based, aligning with the cloud-native principles of 5G Core. The ASP can subscribe to notifications for network events and invoke service operations through the NEF, which acts as a secure broker and policy enforcement point. The ASP is also central to the concept of Edge Computing, where application instances can be deployed at the network edge (via the Edge Application Server) to achieve ultra-low latency, which is critical for services like industrial automation, augmented reality, and intelligent transportation.
The ASP's role extends into service charging and policy control. It can provide service-specific information to the network's charging systems (like CHF in 5G) to enable differentiated charging based on application usage. For policy control, the ASP can influence the Quality of Service (QoS) for its data flows by communicating with the Policy Control Function (PCF). This allows an ASP providing a video conferencing service, for example, to request a guaranteed bit rate bearer for its traffic. Furthermore, in the context of Network Slicing, an ASP may be associated with a specific Network Slice (identified by a S-NSSAI) to receive tailored network characteristics that match its service requirements, such as enhanced mobile broadband, ultra-reliable low-latency communication, or massive IoT connectivity.
Purpose & Motivation
The ASP concept was introduced to formalize and standardize the relationship between mobile network operators and third-party service providers, a need that became critical with the rise of mobile data services and the internet economy. Prior to its standardization, third-party services often relied on non-standard, proprietary integrations or operated entirely over-the-top (OTT) without the ability to leverage intrinsic network capabilities like quality of service, precise device triggering, or subscriber-aware services. This limited the sophistication, reliability, and performance of mobile applications. The ASP model, established in 3GPP Release 8 alongside the Evolved Packet System (EPS), created a framework for secure, scalable, and billable integration of external services, enabling the operator network to become a platform for innovation.
The primary problem the ASP architecture solves is the secure exposure of network capabilities to authorized external entities. Without a standardized ASP interface, operators would face security risks and management complexity in allowing external access. The ASP framework defines authentication, authorization, and accounting (AAA) mechanisms, ensuring that only vetted providers can access network APIs and only for permitted purposes. It also solves the business problem of service monetization, providing clear mechanisms for operators to charge ASPs for the use of network resources and capabilities, creating new revenue streams beyond simple connectivity.
Furthermore, the ASP model is essential for enabling advanced services like Internet of Things (IoT), where devices with intermittent connectivity need to be reliably reached by cloud applications (via device triggering), or where applications need to be notified of device status changes. It also underpins the 5G vision of network-as-a-service and vertical industry support, allowing enterprises (functioning as ASPs) to directly control and customize their slice of the network for factory automation, smart grid, or healthcare applications. The evolution of the ASP role through subsequent releases reflects the growing importance of network openness and programmability in the telecom industry.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (99 CRs across 6 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the ASP function was formally defined within the framework for Single Sign-On (SSO) services, introducing the key role of an Affiliated Application Service Provider (AASP) that has a trust relationship with the operator's Identity or SSO Provider. This enabled use cases where a user, after initial network authentication, could gain seamless and transparent access to multiple affiliated application services without re-entering credentials. The release also specified support for OpenID, where the operator acts as an OpenID Provider to authenticate users for ASPs that function as Relying Parties.
- Clarification on enforcement of Application Detection Control TS 23.503CR0032
- Alignment for policy control application specific information TS 23.503CR0082
- URSP updates and Application to PDU session association re-evaluation TS 23.503CR0109
- BDT: clarification on network area information and ASP identifier TS 23.503CR0121
- Clarification on Application identifier TS 23.503CR0128
- Application detection report when the PFDs are removed TS 23.503CR0132
+ 2 more changes
In Release 16, enhancements for the Application Service Provider (ASP) function included clarifying the association between an application and a PDU session and providing support for applications with specific QoS hints. Furthermore, the release introduced corrections and failure response handling for the SCEF northbound APIs, including aspects like the correct application port and aggregation. These updates refined the interaction between ASPs, the network core, and services like Single Sign-On (SSO) for affiliated ASPs.
- Support of applications with specific QoS hints TS 29.214CR1643
- Clarification for the association between application and PDU session TS 23.503CR0240
- URI of the SCEF northbound APIs TS 29.122CR0249
- Protocol or application errors TS 29.122CR0310
- Support of MTC Provider Id TS 29.122CR0165
- Correct SCEF aggregation TS 29.122CR0208
+ 2 more changes
In Release 17, enhancements for the Application Service Provider (ASP) function focused on refining application identification and error handling across multiple northbound APIs, including the ChargeableParty, AsSessionWithQoS, and various monitoring and configuration interfaces. The release also introduced new capabilities for application event exposure, analytics for user data congestion with application contribution, and clarifications on associating applications to PDU sessions and influence requests. Furthermore, support was added for application duration in dispersion analytics and for including an Application Server Instance in service experience reporting.
- KI#3, clarification on the TSC Assistance Container provider, AF functionality and PCF report TS 23.503CR0640
- Updates to AF Application Identifier in ChargeableParty API TS 29.122CR0341
- Updates to AF Application Identifier in AsSessionWithQoS API TS 29.122CR0342
- Missing application errors in the Monitoring API TS 29.122CR0583
- Update UE Application collective behaviour for NF Load analytics TS 29.517CR0058
- Add Application duration for Dispersion TS 29.517CR0064
+ 21 more changes
In Release 18, the ASP function was enhanced with new capabilities for application group management, allowing services to be retrieved using an application group identifier. Furthermore, the release introduced mechanisms for Application-Specific Expected UE Behaviour parameters and expanded event exposure for application traffic detection to assist network functions. These updates built upon the foundational role of the ASP in providing Application Services and its relationships within Single Sign-On (SSO) and OpenID frameworks.
- Negotiation of the time window for Application Data Transfer TS 23.503CR0764
- PFDF consume Application Detection analytics from NWDAF TS 23.503CR0783
- Application Function influence SFC support TS 23.503CR0756
- Adding application detection event exposure from PCF TS 23.503CR0831
- Using LBO info for authorizing the application guidance request for URSP determination in VPLMN TS 23.503CR1077
- Enabling ACR with cloud applications TS 23.558CR0264
+ 33 more changes
In Release 19, the ASP function was enhanced with new capabilities for Application Layer AI/ML Member Capability Analytics and expanded Application Performance Analytics, including slice-specific and UE-to-UE performance monitoring. It introduced support for Application Groups, with new identifiers and profiles to manage service continuity and end-to-end response time for common EAS serving multiple UEs. Furthermore, the release added mechanisms for application service continuity during EDN overload and enhanced EAS instantiation to meet strict E2E KPI requirements for applications like XR.
- Support of Application Layer AI/ML Member capability Analytics TS 23.436CR0039
- Updates to application performance analytics TS 23.436CR0048
- Updates to Application Layer AI/ML Member Capability Analytics TS 23.436CR0050
- Updates to Slice-specific Application Performance Analytics TS 23.436CR0053
- Updates to UE-to-UE Application Performance Analytics TS 23.436CR0054
- Application service continuity due to EDN overload TS 23.558CR0622
+ 10 more changes
In Release 20, the primary update for the Application Service Provider (ASP) function was a refinement of the application enablement architecture to formally introduce and define the "Affiliated Application Service Provider" (AASP) role. This established a trusted framework where an AASP, acting as a Relying Party, can leverage operator-provided Single Sign-On (SSO) and OpenID-based authentication. The enhancements specifically enable secure, seamless, and transparent user access to these affiliated services, including for non-3GPP devices without UICCs, by utilizing pre-provisioned operator credentials.
- Update application enablement architecture TS 23.482CR0069
Explore further
Broader topics and technologies where ASP plays a role.
Defining Specifications
3GPP specifications that define or reference ASP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 22.895 vc00 | 3GPP SSO Framework Integration Study | Rel-12 |
| TS 23.203 vj20 | Policy and charging control architecture | Rel-19 |
| TS 23.435 vj30 | Network Slice Capability Exposure Procedures | Rel-19 |
| TS 23.436 vk00 | ADAEnabler Functional Architecture and Information Flows | Rel-20 |
| TS 23.482 vk00 | AIML Enablement Service Architecture | Rel-20 |
| TS 23.503 vk00 | 5G Policy and Charging Control Framework | Rel-20 |
| TS 23.558 vk00 | Architecture for Edge Applications | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TR 23.758 vh00 | Study on Edge Application Architecture | Rel-17 |
| TS 24.523 vj00 | NGCN-NGN Interconnection Scenarios | Rel-19 |
| TS 26.532 vj00 | 5G Data Collection and Reporting API Specification | Rel-19 |
| TR 26.803 vh00 | 5G Media Streaming Extensions for Edge Processing | Rel-17 |
| TS 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| TR 26.942 vj00 | Study on Media Energy Consumption Exposure & Evaluation | Rel-19 |
| TS 28.538 vj40 | Edge Computing Management (ECM) | Rel-19 |
| TR 28.815 vh00 | Charging Study for Edge Computing | Rel-17 |
| TR 28.844 vi00 | Technical Report on Charging Aspects of Satellite in 5GS | Rel-18 |
| TS 29.122 vj40 | T8 Reference Point for Northbound APIs | Rel-19 |
| TS 29.154 vj00 | Nt Reference Point Protocol | Rel-19 |
| TS 29.214 vj20 | Policy and Charging Control over Rx | Rel-19 |
| TS 29.517 vj40 | 5G AF Event Exposure Service Stage 3 | Rel-19 |
| TS 29.543 vj20 | 5G Data Transfer Policy Control Services Stage 3 | Rel-19 |
| TS 29.554 vj10 | 5G Background Data Transfer Policy Control Service | Rel-19 |
| TS 29.558 vj40 | Enabling Edge Applications | Rel-19 |
| TS 29.591 vj40 | 5G NEF Southbound Services Stage 3 | Rel-19 |
| TS 32.141 vj00 | Subscription Management (SuM) Architecture | Rel-19 |
| TS 32.257 vj00 | Edge Computing Charging Management | Rel-19 |
| TS 37.571 vj00 | UE Conformance for Positioning | Rel-19 |
| TS 37.579 vi40 | Mission Critical services conformance testing | Rel-18 |
| TS 38.523 vj20 | 5G NR UE Conformance Testing: Idle/Inactive | Rel-19 |