SAI

Service Area Identifier

Identifier →
Introduced in R99 Also in: Core Network, Radio Access Network, User Equipment

SAI is a unique identifier for a group of cells within a Location Area, used in UMTS and LTE networks for location-based services, paging optimization, and mobility management.

Category
Identifier
Introduced
R99
Where
Services › Codecs
Also touches
3 segments
Specifications
28 specs
SAI Description Purpose Detected Changes Specifications

Description

The Service Area Identifier (SAI) is a fundamental concept in 3GPP networks, defined within the UMTS Terrestrial Radio Access Network (UTRAN) and Evolved UTRAN (E-UTRAN) architectures. It is a structured identifier that uniquely represents a Service Area, which is a logical grouping of one or more cells. The SAI is constructed from the Mobile Country Code (MCC), Mobile Network Code (MNC), Location Area Code (LAC), and Service Area Code (SAC). This hierarchical structure allows it to be globally unique and nested within the broader Location Area (LA) and Public Land Mobile Network (PLMN). The SAI is primarily used by the Core Network (CN), specifically the Mobility Management Entity (MME) in LTE or the Serving GPRS Support Node (SGSN) in UMTS/GPRS, for location management and service triggering.

Operationally, the SAI plays a critical role in mobility management procedures. When a User Equipment (UE) moves and performs a location update, it can report its current Service Area to the network. This allows the network to track the UE's location with finer granularity than just the Location Area, enabling more efficient paging. Instead of paging the entire LA, the network can target the specific Service Area where the UE was last known to be, significantly reducing signaling load and paging latency. The SAI is communicated between the Radio Access Network (RAN) and the Core Network via protocols like the Radio Access Network Application Part (RANAP) in UMTS and the S1 Application Protocol (S1AP) in LTE.

Beyond mobility, the SAI is a key enabler for location-based services (LBS) and regulatory features. Service providers can use the SAI to determine a subscriber's approximate location for services like localized advertising, emergency alerts, or lawful interception. In the context of CAMEL (Customised Applications for Mobile networks Enhanced Logic) or other intelligent network services, the SAI can be a trigger point for service logic execution. Its definition across numerous 3GPP specifications, from core network protocols to service requirements, underscores its integral role in network architecture, providing a stable and standardized reference point for area-based functionalities throughout multiple generations of 3GPP systems.

Purpose & Motivation

The Service Area Identifier was introduced to address the need for more granular location tracking than what was provided by the Location Area Identifier (LAI). In early GSM networks, the LAI was the primary unit for location registration and paging. Paging an entire Location Area, which could contain hundreds of cells, generated substantial signaling traffic and could lead to inefficient battery consumption in UEs due to frequent listening. The SAI was created to subdivide the Location Area into smaller, manageable Service Areas.

This subdivision solves the problem of paging overload by allowing the network to page only the cells within the specific Service Area where a UE is likely located. This optimization reduces core-to-RAN signaling, decreases paging channel congestion, and speeds up call setup times. Furthermore, it enables the network to offer advanced, area-dependent services. For instance, differentiated charging, location-based content delivery, and compliance with geographic regulatory requirements all rely on the ability to pinpoint a user's location to a specific Service Area.

The SAI's design as a hierarchical identifier within the PLMN and LA structure ensures backward compatibility and seamless integration with existing mobility management paradigms. It provided a future-proof mechanism that has been maintained from UMTS (3G) through LTE (4G) and into 5G systems for certain interworking scenarios, demonstrating its effectiveness as a foundational concept for efficient network resource management and enhanced service capabilities.

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 2 changes

In Release 15, the specification introduced the inclusion of the Service Area Identifier (SAI) as an optional parameter within GTP signaling messages, specifically in the Create PDP Context Request and Update PDP Context Request. This allows the SGSN to provide CGI/SAI information to the GGSN, supporting functions like charging correlation where the SAI can be included as a RADIUS attribute for accounting. The update also involved corrections to the MBMS SAI Information Element to conform to TLV encoding standards.

  • Correction of MBMS SAI IE to conform to TLV-E TS 24.334CR0314
  • Solve Editor's Note on Access Network charging Identifier TS 32.299CR0816
Rel-16 1 change

In Release 16, the specification introduced the "Application Identifier" as a distinct input parameter for charging rule selection, which is associated with each service provided by an Application Function. This identifier, along with other AF-provided information like the Application Event Identifier, is used by the Charging Rules Function to dynamically select and complete the appropriate charging rules for a service data flow.

Explore further

Broader topics and technologies where SAI plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.125 v1700 Flow Based Charging Architecture Rel-7
TS 23.141 vj00 Presence Service Stage 2 Architecture Rel-19
TS 23.179 vd50 MCPTT Functional Architecture Rel-13
TS 23.216 vj00 SRVCC Architecture Enhancements Rel-19
TS 23.271 vj00 LCS Stage 2 Specification Rel-19
TS 23.292 vj00 IMS Centralized Services (ICS) Architecture Rel-19
TS 23.379 vk00 MCPTT Functional Architecture Rel-20
TS 23.479 vj00 MBMS API for Mission Critical Services Rel-19
TS 23.792 vg00 MBMS API for Mission Critical Services Rel-16
TS 23.795 vg10 V2X Application Architecture Study Rel-16
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.281 vj40 MCVideo Signalling Control Specification Rel-19
TS 24.282 vj50 MCData Signalling Control Protocols Rel-19
TS 24.334 vj00 ProSe Protocols and Procedures Rel-19
TS 24.379 vj50 Mission Critical Push To Talk (MCPTT) call control Rel-19
TS 24.385 vj00 V2X Communication Provisioning Management Object Rel-19
TS 24.386 vj00 V2X Communication Protocols and Procedures Rel-19
TS 25.305 vj00 UTRAN UE Positioning Stage 2 Rel-19
TS 25.413 vj00 Radio Access Network Application Part (RANAP) Rel-19
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19
TS 26.348 vj00 xMB Interface Specification Rel-19
TS 26.849 vc10 MBMS Operation on Demand (MooD) Rel-12
TS 32.250 vj00 Circuit Switched Offline Charging Rel-19
TS 32.299 vj00 Diameter Charging Applications for 3GPP Rel-19
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TS 33.107 vj00 Lawful Interception Architecture & Functions Rel-19
TS 36.579 3GPP TR 36.579 R99
TS 37.579 vi40 Mission Critical services conformance testing Rel-18