Service Area Restriction Information

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.

Key Features

• Defines Allowed and Non-Allowed Tracking Area lists for granular control
• Enforced by the AMF during registration and mobility procedures
• Integrated with subscriber data in the UDM
• Supports application per Network Slice instance
• Enables network-initiated deregistration upon violation
• Dynamic update capability via policy control

Evolution Across Releases

Defining Specifications