Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Identifier

SAPI

Service Access Point Identifier

Identifier →

SAPI is a numerical identifier used at the data link layer to distinguish between different logical channels or services, identifying the specific higher-layer protocol entity for which a frame is destined.

Introduced
Rel-4
Where
Radio Access Network
Specifications
12 specs
Also in
Core Network
SAPI Description Purpose What changed Neighbours Specifications

Description

The Service Access Point Identifier (SAPI) is a key field in the header of data link layer frames, most notably defined for the LAPDm (Link Access Protocol on the Dm channel) protocol used in GSM. It operates at Layer 2 of the protocol stack. The SAPI value uniquely identifies the logical service access point within the data link layer entity, effectively specifying which upper-layer entity or service is the source or destination of the transmitted frame. This allows multiple logical communication channels to be multiplexed over a single physical radio resource (like the SDCCH or SACCH).

How SAPI works is integral to frame addressing and demultiplexing. When a higher-layer protocol (e.g., Call Control (CC), Mobility Management (MM), or Short Message Service (SMS)) needs to send a message, it passes its data to the data link layer via a specific SAP associated with a pre-defined SAPI value. The LAPDm entity then constructs a frame, placing this SAPI value in the address field of the frame header alongside the Terminal Endpoint Identifier (TEI). This frame is sent over the air interface. The receiving data link layer entity examines the SAPI in the incoming frame's header. Based on this value, it routes the extracted payload (the Layer 3 message) to the corresponding upper-layer protocol entity. For example, a frame with SAPI=0 is delivered to the Call Control protocol, while a frame with SAPI=3 is delivered to the entity handling SMS.

Key components include the SAPI field itself (typically 3 or 6 bits wide), the associated data link layer connection, and the mapping table within the protocol stack that links each SAPI value to its corresponding higher-layer service. Its role is to provide efficient, concurrent support for multiple control signaling flows and user data services (like alternate speech/data) without requiring separate physical channels for each. This multiplexing is crucial for optimizing the use of scarce radio resources and managing the complexity of mobile station signaling.

Purpose & Motivation

The SAPI was created to address the need for efficient multiplexing of multiple logical signaling and data channels over the limited physical channels available in a GSM (and later GPRS) system. In early mobile systems, dedicating a physical channel to each type of control signal (call setup, mobility updates, SMS) would be extremely wasteful of spectrum. The SAPI mechanism allows these diverse flows to share a common data link layer connection.

It solves the problem of demultiplexing at the receiver. Without a clear identifier in each frame, the receiving stack would not know whether a given message contained a handover command, a SMS submission, or user data. The SAPI provides this destination address at the logical link level. This enables the phone and network to simultaneously manage a voice call (SAPI=0), send an SMS (SAPI=3), and potentially handle packet data (SAPI values for GPRS) all on the same assigned timeslot.

Historically, its introduction in GSM (and formalization in 3GPP Rel-4) was motivated by the requirement to support a growing set of services beyond basic voice telephony on a single, unified signaling infrastructure. It addressed the limitations of simpler link protocols by providing a standardized, flexible addressing scheme that could accommodate new services (like GPRS) through the assignment of new SAPI values, thereby future-proofing the data link layer architecture.

What changed in its specifications

The latest release-to-release comparison of specifications that define SAPI. Each summary describes the whole specification, not only this term.

TR 21.905Rel-17 → Rel-18

Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.

Full comparison in TR 21.905 →
TS 34.109Rel-10 → Rel-11

Rel-11 brings only minor changes to TS 34.109: 1 clause changed, with no change attributed to a release feature.

Full comparison in TS 34.109 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-4 Initial

Formally specified within 3GPP for GSM/GPRS data link layer protocols, standardizing the use of SAPI values for multiplexing various control and user-plane services. It defined the mapping between specific SAPI numbers and logical channels/services, such as signaling, SMS, and packet data, on the Um and Abis interfaces.

Defining Specifications

3GPP specifications that define or reference SAPI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj20 3GPP Terminology and Definitions Rel-19 read
TS 23.110 vj00 Access Stratum Services Specification Rel-19 read
TS 24.065 v310 GPRS Subnetwork Dependent Convergence Protocol R99 read
TS 34.109 vj00 UE Conformance Test Functions for UMTS Rel-19 read
TS 43.051 vj00 GERAN Stage 2 Service Description Rel-19 read
TS 43.129 vj00 PS Handover in GERAN A/Gb and GAN Modes Rel-19 read
TR 43.901 vj00 Generic Access to A/Gb Interface Feasibility Study Rel-19 read
TS 44.060 vj00 GERAN RLC/MAC Protocol Specification Rel-19 read
TS 44.065 vj00 GPRS SNDCP Specification Rel-19 read
TS 44.160 vg00 GERAN Iu Mode RLC/MAC Protocol Specification Rel-16 read
TS 49.008 vj00 BSSAP on E-interface for inter-MSC handover Rel-19 read
TS 52.021 vj00 GSM A-bis Interface Network Management Rel-19 read