SAA

Server Assignment Answer

Protocol →
Introduced in Rel-8

SAA is a Diameter protocol message sent by the HSS to the I-CSCF in response to a Server Assignment Request, providing user authentication and service profile data within the IMS Cx interface.

Category
Protocol
Introduced
Rel-8
Where
Core Network › 5G Core
Specifications
1 specs
SAA Description Purpose Related Classification Detected Changes Specifications

Description

The Server Assignment Answer (SAA) is a critical Diameter command within the 3GPP IP Multimedia Subsystem (IMS) architecture. It is defined in the Cx interface specification (TS 23.380 and related) as the response message to a Server Assignment Request (SAR). The SAA is sent from the Home Subscriber Server (HSS), the central user database, to the Interrogating-Call Session Control Function (I-CSCF). This exchange occurs during key IMS registration and session establishment procedures to authorize a user and retrieve their service configuration.

When a User Equipment (UE) attempts to register with the IMS network, the I-CSCF receives the SIP REGISTER request. The I-CSCF then sends a Diameter SAR to the HSS to perform server assignment. The SAR informs the HSS which Serving-CSCF (S-CSCF) has been selected or is being queried for to serve the user. The HSS processes this request, which includes checking the user's subscription status, authentication data, and the capabilities of the nominated S-CSCF. The HSS then formulates and sends the SAA back to the I-CSCF. The SAA message carries several key Attribute-Value Pairs (AVPs), most importantly the user's authentication vectors (for SIP digest authentication), the assigned S-CSCF name if the registration is successful, and the user's IMS service profile. The service profile contains the initial Filter Criteria (iFC), which are triggers that dictate how incoming SIP messages for that user should be routed to specific Application Servers (AS).

The SAA message's content directly dictates the subsequent actions of the I-CSCF. If the SAA contains a successful result code and an S-CSCF name, the I-CSCF will forward the SIP REGISTER request to that specific S-CSCF. The authentication vectors within the SAA are used by the S-CSCF to challenge the UE. If the HSS rejects the assignment (e.g., user unknown or barred), the SAA will contain an appropriate error code, and the I-CSCF will terminate the registration attempt, sending a SIP error response to the UE. Thus, the SAA is the authoritative response that gates access to IMS services, linking subscriber data in the HSS with the dynamic session control logic in the CSCFs.

Purpose & Motivation

The SAA message exists as part of the Diameter-based Cx interface to decouple subscriber data management from session control in the IMS. In pre-IMS architectures, user data and call control logic were often tightly integrated, making networks inflexible and difficult to scale. The IMS model introduced a clear separation: the HSS holds all subscription and authentication data, while the CSCFs handle session signaling. The SAR/SAA transaction is the protocol mechanism that bridges this separation.

This design solves several key problems. First, it enables centralized subscriber management. A single HSS can serve multiple CSCFs and other network functions, ensuring consistency. Second, it allows for dynamic S-CSCF assignment. The I-CSCF can query the HSS (via SAR) for a suitable S-CSCF based on user capabilities, and the HSS responds (via SAA) with the assignment, enabling load balancing and service-based routing. Third, it provides a secure and standardized method for distributing sensitive authentication data from the HSS to the network edge (the S-CSCF) only when needed, following a request-response model. The SAA, as the secure container for this data, is fundamental to IMS authentication and authorization.

Classification

Part ofIMS
Related approachesHSSI-CSCFCSCF

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-8, normative work from Rel-15.

Rel-15 2 changes

In Release 15, the SAA function was enhanced to support S-CSCF restoration after a failure by including S-CSCF restoration information. Specifically, when an HSS receives an SAR with Server Assignment Type set to NO_ASSIGNMENT and holds restoration data, it sends this information within the SAA to the newly assigned S-CSCF. This allows the S-CSCF to recover user registration data and trigger matched services, facilitating faster session restoration with minimal user impact.

  • New Clause for P-CSCF Restoration in 5G Access TS 23.380CR0096
  • Updates to PCF Based P-CSCF Restoration Solution TS 23.380CR0102
Rel-16 7 changes

In Release 16, the SAA function was enhanced to support IMS restoration procedures, specifically allowing the HSS to send S-CSCF restoration information within the SAA message when a new S-CSCF is assigned after a failure. This occurs when the S-CSCF sends a Server-Assignment-Request (SAR) with the NO_ASSIGNMENT type to retrieve lost user data, enabling the S-CSCF to restore services for registered users. Additionally, the procedures were defined for scenarios like S-CSCF restoration after a restart and during terminating service requests when a previous S-CSCF fails.

  • 5G P-CSCF restoration using Nudm TS 23.380CR0107
  • P-CSCF restoration TS 23.380CR0109
  • Correction to P-CSCF Restoration Procedures TS 23.380CR0105
  • Add P-CSCF subscription info to Restoration information TS 23.380CR0106
  • S-CSCF restoration after registration timer expiry TS 23.380CR0110
  • P-CSCF restoration alignment TS 23.380CR0113

+ 1 more changes

Rel-17 2 changes

In Release 17, the SAA function was enhanced to support P-CSCF restoration procedures, building upon the existing S-CSCF restoration mechanisms. The specification introduced specific behaviors for the HSS to include S-CSCF restoration information in the SAA message when triggered by a Server Assignment Request with the type NO_ASSIGNMENT, following a reselection indication. This allows a newly assigned S-CSCF to retrieve lost user registration data and restoration information groups from the HSS to efficiently recover service after a P-CSCF or S-CSCF failure.

  • P-CSCF restoration TS 23.380CR0118
  • Correction to HSS-based and PCRF-based P-CSCF restoration TS 23.380CR0117
Rel-19 1 change

In Release 19, enhancements to the SAA function were introduced to support S-CSCF restoration after a failure, specifically allowing a newly assigned S-CSCF to retrieve restoration information from the HSS. This is triggered when the S-CSCF receives a reselection indication and sends a Server-Assignment-Request (SAR) with the Server Assignment Type set to NO_ASSIGNMENT. Upon receiving this, the HSS includes the S-CSCF restoration information along with the user profile in the Server Assignment Answer (SAA), enabling the new S-CSCF to recover user session data.

  • P-CSCF triggering SMF/PGW-C failure checking TS 23.380CR0129

Explore further

Broader topics and technologies where SAA plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.380 vj10 IMS Restoration Procedures Rel-19