SARI

Service Area Restriction Information

Mobility →
Introduced in Rel-15

SARI is the 3GPP data set that defines allowed and non-allowed tracking areas to control where a User Equipment is permitted to obtain service.

Category
Mobility
Introduced
Rel-15
Where
Core Network › 5G Core
Specifications
1 specs
SARI Description Purpose Related Classification Detected Changes Specifications

Description

Service Area Restriction Information (SARI) is a subscriber-specific or session-specific policy parameter in the 5G System (5GS). It is managed by the Unified Data Management (UDM) function as part of a user's subscription data and is provided to the Access and Mobility Management Function (AMF) during registration and session establishment procedures. The SARI contains two primary lists: an Allowed Area and a Non-Allowed Area, each composed of Tracking Area Identities (TAIs). The AMF uses this information to enforce mobility restrictions by allowing or denying registration, service requests, and handovers based on the UE's current or target location.

Architecturally, SARI is propagated through key 5G interfaces. The UDM includes it in the Nudm_SubscriberDataManagement service responses to the AMF. The AMF then evaluates the UE's current TAI against the SARI. If the UE is in a Non-Allowed Area, the AMF can reject the registration with an appropriate cause code, effectively barring service. For an ongoing session, if a UE moves into a Non-Allowed Area, the AMF can initiate a network-initiated deregistration or modify the PDU session. The policy can also be applied per Network Slice, allowing different service area restrictions for different slices assigned to the same UE.

How it works involves precise coordination between the UE's location update procedures and the AMF's policy enforcement. When a UE performs a Registration Request or a Periodic Registration Update, the AMF receives the UE's current TAI. It fetches the subscriber's SARI (if not already cached) and performs a check. The 'Allowed Area' takes precedence; if a TAI is present in both the Allowed and Non-Allowed lists, it is considered allowed. This granular control allows operators to define complex service footprints, such as permitting service only in a specific city (Allowed Area) or everywhere except a sensitive site (Non-Allowed Area). SARI is a crucial tool for implementing regulatory mandates (e.g., no service in secure government facilities), commercial agreements (geofenced services), and efficient network slice isolation.

Purpose & Motivation

SARI was introduced in 5G to provide a more flexible and powerful mechanism for geographic service control than what was available in previous generations like 4G EPC. Earlier systems used concepts like Forbidden Tracking Areas or equivalent location-based restrictions, but they were often less granular and not as seamlessly integrated with subscriber data management and network slicing policies. The rise of 5G use cases, such as private networks, network slicing for vertical industries, and stringent regulatory requirements, created a need for precise, dynamic, and slice-aware service area management.

The primary problem SARI solves is the need for differentiated access control based on geography. For example, a factory deploying a private 5G network needs to ensure its ultra-reliable low-latency communication (URLLC) slice is only accessible within the factory premises. Similarly, a regulator may require that mobile service be disabled within prisons or military zones. SARI provides the standardized mechanism to enforce these policies at the network core, preventing unauthorized access or service leakage outside defined boundaries.

Its creation was motivated by the 5G architectural shift towards cloud-native, service-based interfaces and the explicit support for network slicing. SARI is a key enabler for slice isolation, allowing different slices to have independent geographic footprints. It also supports dynamic updates; an operator can modify a user's SARI in the UDM, and the change can be pushed to the serving AMF, enabling real-time changes to service areas for security or operational reasons, which was more cumbersome in prior architectures.

Classification

Part ofAMF
Related approachesUDM

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the Subscribed-Data-Report event type and the SARI (Service Area Restriction Information) data type were removed. This change was implemented through a specific Change Request, streamlining the subscribed data reporting procedures.

  • Remove Subscribed-Data-Report event type and SARI data type TS 29.518CR174

Explore further

Broader topics and technologies where SARI plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 29.518 vj50 AMF Service Based Interface Protocol 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.