SPI

Service Provider Identification

Identifier →
Introduced in R99 Also in: Services, Security

SPI is a unique identifier used in 3GPP systems to distinguish the service provider, enabling service differentiation, billing, policy enforcement, and specific rule application based on the provider.

Category
Identifier
Introduced
R99
Where
Core Network › 5G Core
Also touches
2 segments
Specifications
15 specs
SPI Description Purpose Related Classification Detected Changes Specifications

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

Part ofMVNO
Related approachesAPN

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-15 1 change

In Release 15, a correction was introduced for the Service Provider Identification (SPI) function to address an error in the handling of Delete payloads. Specifically, the change resolved an issue where an incorrect ESP SPI could be included within such a payload. This ensured the proper identification and management of security associations during deletion procedures.

  • Incorrect ESP SPI in Delete payload TS 24.302CR0625
Rel-18 2 changes

In Release 18, the Service Provider Identification (SPI) function was enhanced with a new procedure to indicate the SPI specifically for an IPsec Security Association modification. Furthermore, the release provided clarifications regarding the SPI parameter used within the UP_SA_INFO Notify payload.

  • Indicate the SPI for IPsec SA modification procedure TS 24.502CR0226
  • Clarification for the SPI used in UP_SA_INFO Notify payload TS 24.502CR0276

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.