Description
Service Provider Identification (SPI) is a parameter within 3GPP systems that unambiguously identifies the provider of a specific service or set of services to a user. It is distinct from subscriber identifiers like IMSI or MSISDN. The SPI is used by network functions to determine which policies, charging rules, and quality-of-service treatments to apply for a given data session or service flow. It is a key element in enabling service-aware networks.
Architecturally, the SPI is often configured in the user's subscription profile stored in the HSS (for packet core) or HLR. During session establishment, such as a PDN connection in EPS or a PDU session in 5GS, the relevant network node (e.g., MME, SMF) retrieves the SPI along with other subscription data. This SPI is then provided to policy and charging control functions like the PCRF (in 4G) or PCF (in 5G). The PCRF/PCF uses the SPI, in combination with other parameters like the APN or DNN, to select the appropriate Policy and Charging Control (PCC) rules. These rules dictate aspects like bandwidth limits, QoS class identifiers (QCIs/5QIs), and charging methods specific to that service provider's offering.
How it works in practice: An MVNO (Mobile Virtual Network Operator) leasing capacity from an MNO (Mobile Network Operator) will have its own unique SPI. When an MVNO subscriber attaches to the network, the MNO's policy system identifies the SPI associated with that subscriber's profile. It can then apply a different set of policies (e.g., throttling thresholds, permitted services) compared to the MNO's own direct subscribers, even though they are using the same physical radio infrastructure. This enables the host MNO to offer differentiated wholesale services. The SPI is also used in steering roaming scenarios to identify the home service provider of a roaming user.
Purpose & Motivation
The SPI exists to enable service differentiation and multi-tenancy in shared network infrastructures. The core problem it solves is the need for a single physical network (e.g., an MNO's RAN and core) to host multiple logical service providers (like MVNOs, enterprise customers, or IoT service providers) and treat their traffic differently according to commercial agreements. Without an SPI, the network could only apply policies based on the subscriber identity or APN, which is insufficient for complex wholesale and service aggregation models.
Historically, as mobile markets became more competitive, regulators and commercial pressures drove the rise of MVNOs. This created a technical requirement for the host MNO to identify which entity was ultimately responsible for a subscriber's service. The SPI, introduced in 3GPP Release 99, provided this capability. It was motivated by the need for flexible policy and charging control, which was becoming increasingly important with the advent of packet-switched data services (GPRS) where service tiers and billing models were more varied than simple voice calls.
It addresses the limitation of earlier networks that were essentially single-tenant. The SPI allows the decoupling of service provisioning from network operation. This enables new business models, such as an IoT platform provider (the service provider identified by the SPI) offering connectivity through multiple MNOs, with the MNOs applying the platform's specific policies uniformly. It is a cornerstone for enabling efficient and automated service delivery in modern, software-defined mobile networks.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (8 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the specification introduced a correction for the Service Provider Identification (SPI) function by addressing an error in the handling of an ESP SPI within a Delete payload. This change ensured the accurate identification and management of the Service Provider, which is the entity providing services to a subscriber. The update maintained the integrity of service provider-related procedures within the specification framework.
- Incorrect ESP SPI in Delete payload TS 24.302CR0625
In Release 18, the SPI function was enhanced to support the identification of DetNet flows and to explicitly indicate the SPI during the IPsec Security Association modification procedure. Furthermore, clarifications were provided for the specific SPI used within the UP_SA_INFO Notify payload. These updates refined the technical mechanisms for service provider identification within various security and packet flow contexts.
In Release 19, the SPI function was enhanced to support the identification of a serving satellite in UE-to-satellite-to-UE communication scenarios. Furthermore, the release introduced updates and enhancements to the procedures for reporting Multiplexed Media Identification information to network functions like the PCF, including associated data rate limitation details. These changes expanded the identification mechanisms available to the Service Provider within new network architectures.
- Support of serving satellite identification in UE-SAT-UE communication TS 29.514CR0704
- Support of serving satellite identification in UE-SAT-UE communication TS 29.514CR0722
- Update the multiplexed media identification information to PCF TS 29.514CR0753
- Enhancements on the Multiplexed Media Identification and Data Rate Limitation information reporting TS 29.514CR0824
Explore further
Broader topics and technologies where SPI plays a role.
Defining Specifications
3GPP specifications that define or reference SPI, 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 23.048 v1400 | Secured Packets for UICC Remote Management | Rel-5 |
| TS 23.060 vj00 | GPRS Service Description Stage 2 | Rel-19 |
| TS 23.140 v1600 | MMS Non-Realtime Service Definition | Rel-6 |
| TS 23.218 vj00 | IMS Call Model Specification | Rel-19 |
| TS 24.302 vj00 | Access to EPC via non-3GPP networks; Stage 3 | Rel-19 |
| TS 24.502 vj20 | 5G Core Access via Non-3GPP Networks; Stage 3 | Rel-19 |
| TS 29.204 vj00 | SS7 Security Gateway Functional Description | Rel-19 |
| TS 29.513 vj40 | 5G PCC Signalling Flows & QoS Mapping | Rel-19 |
| TS 29.514 vj40 | 5G System; Policy Authorization Service; Stage 3 | Rel-19 |
| TS 31.114 v1800 | USAT Interpreter Transmission Protocol | Rel-8 |
| TS 31.801 vf10 | Requirements for Secure Platform for 3GPP Apps | Rel-15 |
| TS 33.204 vj00 | TCAP Security (TCAPsec) Stage 2 Specification | Rel-19 |
| TS 33.210 vj20 | UMTS Security for IP Networks | Rel-19 |
| TS 33.822 v1800 | Security Architecture for Inter-Access Mobility | Rel-8 |