SAP

Service Access Point

Protocol →
Introduced in R99 Also in: Services

SAP is the conceptual point within a protocol layer where services are provided to the layer above, defining the interface and primitives for communication between adjacent layers.

Category
Protocol
Introduced
R99
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
52 specs
SAP Description Purpose Specifications

Description

A Service Access Point (SAP) is a fundamental architectural concept in layered communication systems, including the 3GPP protocol stacks for UE, RAN, and Core Network. It represents the logical interface at the boundary between two adjacent protocol layers (e.g., between the RLC and MAC layers, or between the NAS and RRC layers). The SAP is not a physical connection but a defined set of abstract communication primitives and associated data structures through which a lower layer (the service provider) offers its services to the immediate upper layer (the service user).

How a SAP works is defined by the exchange of service primitives. These are typically categorized as Request, Indication, Response, and Confirm. For instance, when the RRC layer (user) needs to send a message, it issues a DATA.request primitive to the lower RLC layer (provider) via their SAP, passing the message as a parameter. The RLC layer then handles the transmission. Upon receipt of data from the peer, the RLC layer issues a DATA.indication primitive up to the RRC layer via the same SAP. This abstraction hides the implementation details of the lower layer, allowing upper layers to operate solely based on the service offered.

The key components of the SAP concept are the Service Primitives themselves and the Service Data Unit (SDU). The SDU is the packet of data passed down through a SAP. The lower layer may add its own headers and trailers to this SDU, transforming it into a Protocol Data Unit (PDU) for its own peer-to-peer communication. SAPs are defined for every layer interface in 3GPP specifications, such as the Service Access Point Identifier (SAPI) for the LAPDm link layer in GSM, or the logical channels between MAC and RLC in LTE/NR. Their role is to create a clean, standardized, and interoperable separation of concerns, which is essential for modular network design, independent layer development, and multi-vendor equipment compatibility.

Purpose & Motivation

The SAP concept exists to enable the structured, layered design of communication protocol stacks, which is a cornerstone of modern telecommunications and computer networking (inspired by the OSI model). Before layered architectures, protocol software was often monolithic and tightly integrated, making it difficult to modify, upgrade, or replace individual functional components without affecting the entire system.

The SAP solves the critical problem of defining how different layers of a complex system, potentially developed by different teams or vendors, interact with each other in a predictable and standardized way. It provides a formal contract between layers. This allows for the independent evolution of layers; for example, the physical layer technology can evolve from GSM to UMTS to LTE to 5G NR, while the core network signaling protocols above the transport layers can remain largely consistent or evolve separately.

Historically, its adoption in 3GPP standards (from GSM R99 onwards) was motivated by the need for rigorous specification to ensure global interoperability. It addressed the limitations of ad-hoc inter-layer communication by providing a precise language of primitives and parameters. This formalization reduced implementation ambiguity, allowed for conformance testing, and ultimately enabled the successful deployment of multi-vendor mobile networks where a UE from one manufacturer must seamlessly work with infrastructure from another.

Evolution Across Releases

R99 Initial

Formally adopted as a core architectural concept in 3GPP specifications for the GSM/UMTS protocol stacks. It defined the service interfaces between layers such as RRC, RLC, MAC, and the physical layer, establishing the primitives for control and data transfer that enabled the separation of the new UMTS radio access network from the evolved GSM core network.

Explore further

Broader topics and technologies where SAP plays a role.

Defining Specifications

3GPP specifications that define or reference SAP, 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 22.060 vj00 GPRS Stage 1 Service Description Rel-19
TS 23.107 vj00 UMTS QoS Framework Rel-19
TS 23.110 vj00 Access Stratum Services Specification Rel-19
TS 23.207 vj00 End-to-End QoS Framework for GPRS Rel-19
TS 23.852 vc00 Study on GTP-based S2a for WLAN Access Rel-12
TR 23.910 v1400 UMTS Circuit Switched Bearer Services Overview Rel-5
TS 25.201 vj00 UTRA Physical Layer General Description Rel-19
TS 25.301 vj00 UE-UTRAN Radio Interface Protocol Architecture Rel-19
TS 25.302 vj00 UTRA Physical Layer Services Rel-19
TS 25.304 vj00 UTRA Idle Mode Procedures Specification Rel-19
TS 25.321 vj00 MAC Protocol Specification for UTRAN Rel-19
TS 25.322 vj00 RLC Protocol Specification Rel-19
TS 25.331 vj00 UTRAN RRC Protocol Specification Rel-19
TS 25.367 vj00 Home NodeB Mobility Procedures Rel-19
TS 25.402 vj00 UTRAN Synchronisation Mechanisms Rel-19
TS 25.410 vj00 Iu Interface Introduction for UTRAN Rel-19
TS 25.413 vj00 Radio Access Network Application Part (RANAP) Rel-19
TS 25.415 vj00 Iu Interface User Plane Protocol Rel-19
TS 25.452 vj00 Iupc Interface Signalling Transport for PCAP Rel-19
TR 25.912 vj00 Evolved UTRA and UTRAN Technical Report Rel-19
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19
TS 26.247 vj00 3GPP Progressive Download & DASH over HTTP Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TS 26.851 vb20 Enhancements to Multimedia (EMM) for PSS, MMS, MBMS Rel-11
TR 26.906 vj00 HEVC Evaluation for 3GPP Services Rel-19
TR 26.938 vj00 DASH Deployment Guidelines for 3GPP Networks Rel-19
TR 26.949 vj00 TV Service Profiles for 3GPP Networks Rel-19
TS 29.415 vj00 Nb User Plane Protocol Specification Rel-19
TS 32.101 vj00 Management principles and high-level requirements Rel-19
TS 33.885 ve10 Security Study for V2X Services Rel-14
TS 36.201 vj00 LTE Physical Layer General Description Rel-19
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.302 vj00 E-UTRA Physical Layer Services Rel-19
TS 36.304 vj00 UE Idle Mode Procedures in E-UTRA Rel-19
TS 36.322 vj00 E-UTRA Radio Link Control Protocol Specification Rel-19
TS 36.323 vj00 PDCP Protocol Specification Rel-19
TS 36.331 vj00 LTE RRC Protocol Specification Rel-19
TS 36.360 vj00 LTE-WLAN Aggregation Adaptation Protocol Rel-19
TS 36.361 vj00 LWIP Encapsulation Protocol Specification Rel-19
TS 36.401 vj00 E-UTRAN Overall Architecture Description Rel-19
TS 36.410 vj00 S1 Interface: General Aspects and Principles Rel-19
TS 36.456 vj00 SLm Interface Introduction Rel-19
TS 38.201 vj00 NR Physical Layer General Description Rel-19
TS 38.323 vj00 Packet Data Convergence Protocol (PDCP) Rel-19
TS 38.401 vj10 NG-RAN Architecture Specification Rel-19
TS 43.051 vj00 GERAN Stage 2 Service Description 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.160 vg00 GERAN Iu Mode RLC/MAC Protocol Specification Rel-16
TS 45.820 vd10 CIoT for Internet of Things Rel-13
TR 45.902 vj00 Flexible Layer One (FLO) for GERAN Rel-19
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.