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.
Classification
Evolution Across Releases
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.
Explore further
Broader topics and technologies where SAPI plays a role.
Defining Specifications
3GPP specifications that define or reference SAPI, 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.110 vj00 | Access Stratum Services Specification | Rel-19 |
| TS 24.065 v1310 | GPRS Subnetwork Dependent Convergence Protocol | Rel-4 |
| TS 34.109 vj00 | UE Conformance Test Functions for UMTS | Rel-19 |
| TS 43.051 vj00 | GERAN Stage 2 Service Description | Rel-19 |
| TS 43.129 vj00 | PS Handover in GERAN A/Gb and GAN Modes | Rel-19 |
| TR 43.901 vj00 | Generic Access to A/Gb Interface Feasibility Study | Rel-19 |
| TS 44.060 vj00 | GERAN RLC/MAC Protocol Specification | Rel-19 |
| TS 44.065 vj00 | GPRS SNDCP Specification | Rel-19 |
| TS 44.160 vg00 | GERAN Iu Mode RLC/MAC Protocol Specification | Rel-16 |
| TS 49.008 vj00 | BSSAP on E-interface for inter-MSC handover | Rel-19 |
| TS 52.021 vj00 | GSM A-bis Interface Network Management | Rel-19 |