Service Area Restriction

Table 1. Feature History

Feature Name

Release Information

Description

Service Area Restriction

 2023.04

Cisco AMF supports the service area restriction for the UE to enforce restrictions on the services that UE can access based on location and tracking area codes.

Default Setting: Disabled – Configuration Required

Feature Summary and Revision History

Summary Data

Table 2. Summary Data

Applicable Product(s) or Functional Area

AMF

Applicable Platform(s)

SMI

Feature Default Setting

Enabled - Always-on

Related Documentation

Not Applicable

Revision History

Table 3. Revision History

Revision Details

Release

First introduced.

2023.04.0

Service Area Restriction

Service Area Restriction (SAR) is a mechanism that allows the network operators to define specific geographic areas where a User Equipment (UE) is either allowed or restricted to access services. The SAR enables fine-grained control over the availability of services based on the location of the UE.

Feature Description

The SAR involves configuring the 5G core network to enforce restrictions on the services that a UE can access based on its location, often identified by specific geographical identifiers such as Tracking Area Codes (TACs). The Service Area Restrictions (SAR) within subscription data can be configured by the Unified Data Management (UDM).

How it Works

The Access and Mobility Management Function (AMF) enhances its capabilities to provide robust service area restrictions handling, aligning with the access control information provided in subscriber data by the Unified Data Management (UDM) entity. This feature ensures that access restrictions based on subscription data are efficiently enforced for all subscribers.

Following are the capabilities of the service area restriction feature in the AMF:

  • The AMF is equipped to receive and store the ServiceAreaRestriction data provided by the UDM in the subscriber's User Equipment (UE) context. This data encompasses information regarding allowed or not allowed areas for the subscriber.

  • To enforce the defined service area restrictions, the AMF provisions the restriction information to the UE using registration accept and UE configuration update command message. The AMF communicates these restrictions to the Gnb using initial context setup request, handover request and downlink NAS transport messages.

  • In mobility scenarios involving AMF changes, where a subscriber transitions from one AMF (S-AMF) to another (T-AMF), the service area restrictions provided by the UDM are transferred along with the UE context.

UDM based Service Area Restrictions

When the UDM provides the subscriber data, the AMF automatically implements and enforces access restrictions based on subscription data for all subscribers. The UDM can provide either a list of Tracking Area Codes (TACs) or Area Codes to the AMF as part of service area restrictions. However, this feature exclusively supports TAC lists provided by the UDM.

If the UDM includes Area Codes in the Service Area Restriction (SAR) data, the AMF doesn't apply any service area restrictions and ignores the SAR data. In cases where the UDM provides TACs, it's expected that these TACs align with the Tracking Area Identity (TAI) list configured within the AMF.

The AMF anticipates the UDM to provide up to 16 TACs, either per area or across multiple areas. However, even if the UDM sends more than 16 TACs for a particular area or across multiple areas, the AMF relays a maximum of 16 TACs (starting from the first area) in NGAP/NAS messages.

AMF supports service area list types 00,01, and 11.

If the initial two TACs in an area are consecutive in sequence in the SAR IE, then AMF assumes that all TACs in that specific area are in consecutive sequence, and uses TYPE 01 service area list.

When the UDM specifies the restriction type as "ALLOWED_AREAS" and doesn't specify any areas, it signifies that the UE is allowed in all areas. In such cases, the AMF sets the type-list as 11 in the registration accept message, and in N2 messages, the AMF doesn't fill any service area restrictions. The AMF doesn't incorporate any service area restrictions in this area.

When the UDM specifies the restriction type as "NOT_ALLOWED_AREAS" and doesn't provide any areas, it indicates that the UE is not allowed in any areas. In this case, registration area is filled as not allowed TACs.

If UDM removes the existing service area restrictions through data change notification, The AMF triggers the UE configuration update procedure with service area list type 11 and sends the mobility restrictions IE to Gnb without service area information.

If UDM sends an invalid restriction type during registration, the SAR content is dropped by the AMF.

UDM Data Change Notification

When AMF detects a change in Service Area Restriction (SAR) due to a Data Change Notification from UDM:

  • If the UE is in connected mode, AMF triggers a UE Configuration update command to the UE.

  • If the UE is in idle mode, AMF triggers paging.

The AMF updates UE context with the SAR information from UDM instantly and it doesn't wait for a response from the UE.

Enforcing Service Area Code Restrictions at AMF

The AMF enforces service area restrictions, if it determines that the UE is in a non-allowed area or is not in an allowed area. The AMF doesn’t enforce any service area restrictions for emergency services. Following are the procedures for enforcing the service area restrictions at AMF.

  • Registration procedure

    • During registration procedure, if AMF detects that UE has moved into a non-allowed area, and if UE is requesting to reactivate any non-emergency PDU using the uplink data status IE, then the AMF fills “28 "Restricted service area" as cause in the PDU reactivation result error for the corresponding PDUs in registration accept.

    • During registration procedure with UE being in connected mode, For example - Mobility registration post handover, if AMF detects UE has moved into a restricted service area, and if PDU session status IE indicates presence of any non-emergency PDUs , the AMF initiates the release of the PDU by sending SM update context with release IE set as true towards SMF.

  • Service Request procedure

    • During service request, if the service type IE in the service request message is set to "signaling" or "data", then the AMF sends a service reject message with the 5GMM cause value set to #28 "Restricted service area";


      Note

      #28 "Restricted service area" is default cause value. If any specific cause is configured under local cause code mapping CLI, the same cause code is used.

    • If service type is "mobile terminated services", and service request contains uplink data IE indicating non-emergency PDUs to be reactivated, the AMF fills “28 "Restricted service area" as cause in the PDU reactivation result error.

  • Handover procedure

    • In case of handovers like Xn, and N2 , if applicable, the AMF enforces the restrictions when mobility registration is received as part of the handover procedure.

    • In case of scenarios involving AMF change like registration, N2 handovers:

      • If service area restrictions are available in the source AMF (S-AMF), the S-AMF forwards them to the target AMF (T-AMF).

      • In case of N2 handover, T-AMF forwards the service area restriction received from the S-AMF's handover request to the target gNB.

      • T-AMF retrieves subscription data from the UDM as part of registration procedure. The SAR information received from the UDM supersedes the SAR details sent by the S-AMF and the same is updated to UE and gNB Accordingly.

    • In case of N26 idle mode 4g to 5g HO:

      • AMF doesn't consider the PDU session status IE for any PDU synchronization.

      • If the UE is in a restricted area, the AMF refrains from sending the CreateSMContext to the SMF.

      • PDU creation and reactivation occur simultaneously, AMF doesn't populate the reactivation result or error cause, but it always fills the PDU session status IE in registration accept.

  • While UE is in restricted area, upon receiving uplink 5G-SM message from UE which is not forwarded due to service area restrictions; the AMF sends back the 5GSM message to the UE with cause code as #28 "Restricted service area".

  • The AMF rejects the N1N2 messages with a message class of SM from the SMF for non-emergency PDN when it is in a restricted service area.

  • When UE is in idle mode, and if UE is in non-allowed area, the AMF pages the UE only for emergency services, MT SMS, and for other mobility related messages.


    Note

    The AMF detects whether the UE is in allowed or non-allowed area based on the last known location. On the basis of this information, the AMF decides whether to proceed with paging or not.

  • In case of UDM data change notification received when UE is in connected mode, the AMF triggers the UE configuration update procedure immediately towards UE. The restrictions are enforced only when mobility registration request is sent by UE.

Configuring Local Cause Code Mapping for Service Area

This configuration supports the mapping of local-defined cause code to restricted area restrictions. To configure the local cause code mapping for the service area, following is an example configuration: 

config 
   local-cause-code-maplocal-cause-code-map_name 
      restricted-zone-code cause-code-5gmm 
      possible completions [no-suitable-cells-in-tracking-area | 5GS-services-not-allowed | no-suitable-cells-in-tracking-area | plmn-not-allowed | restricted-service-area | roaming-not-allowed-in-this-tracking-area | tracking-area-not-allowed ] 
      end

If a local cause code is configured for service area restriction (SAR), the AMF uses the configured cause code from the CLI. Otherwise, the default cause code #28 "Restricted service area" is used.


Note

The AMF uses the mapped cause code CLI only while sending the service reject messages.

Show Subscriber to indicate UE in Serving Area

When there is no Service Area Restriction (SAR) information available from the UDM, the AMF designates the "In Serving Area" status as "Unknown Area." On the other hand, if the UDM provides valid SAR data, the AMF assesses the UE's location by comparing its Tracking Area Code (TAC) with the UDM's response SAR. Based on this comparison, the AMF determines the UE's state as either allowed or not allowed in the given area. Following is the example of the output. 

show subscriber supi xyz

"InServingArea": "ALLOWED"

"serviceAreaRestriction": {
"restrictionType": "ALLOWED_AREAS",
"areas": [
{
"tacs": [
"1e",
"14"
]
},
{
"tacs": [
"0a",
"ABCD"
]
},
{
"tacs": [
"FFFE",
"FFFF"
]
}
]
}

Here are the possible outcomes:

  • If the UE's TAC is not allowed - "In Serving Area": "NOT_ALLOWED"

  • If the UE's TAC is allowed - "In Serving Area": "ALLOWED"

  • If the AMF is unable to evaluate the service area restriction from the UDM's response - "In Serving Area": "UNKNOWN_AREA"

Limitations

This feature has the following limitations:

  • The AMF doesn't support the area code received as a part of service area restrictions from the UDM.

  • The AMF doesn't support the implementation of Policy Control Function (PCF) interaction for Service Area Restriction (SAR) information.

  • The AMF doesn't support the event exposure services for service area restriction changes notification to other NF.