Service Access Point Identifier

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.

Key Features

• Uniquely identifies the logical service or upper-layer protocol entity within a data link layer connection.
• Used for multiplexing multiple logical channels (e.g., signaling, SMS) over a single physical channel.
• A core component of the frame address field in LAPDm (GSM) and related data link protocols.
• Enables the data link layer to correctly route incoming frames to the appropriate higher-layer service.
• Pre-defined values for specific services (e.g., SAPI=0 for Call Control, SAPI=3 for SMS).
• Essential for efficient use of radio resources by supporting concurrent services.

Evolution Across Releases

Defining Specifications