6 Procedure Descriptions

29.2283GPPIP Multimedia (IM) Subsystem Cx and Dx InterfacesRelease 17Signalling flows and message contentsTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

In the tables that describe the Information Elements transported by each command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the Category "Cat." column. The application level specification overrides the ABNF defining the presence of the AVPs to be included in the Diameter commands. The category defined by the Information Element table shall always be the same, i.e. Optional; or more restrictive, i.e. Mandatory or Conditional, than the presence requirements defined by the ABNF syntax, e.g. a required AVP in the ABNF shall not be overridden by an Optional IE but an Optional AVP in the ABNF may be overridden by the Mandatory or Conditional IE Category.

– A mandatory Information Element shall always be present in the command. If this Information Element is absent, an application error occurs at the receiver and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element.

– A conditional Information Element (marked as (C) in the table) shall be present in the command if certain conditions are fulfilled.

– If the receiver detects that those conditions are fulfilled and the Information Element is absent, an application error occurs and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element.

– If those conditions are not fulfilled, the Information Element shall be absent. If however this Information Element appears in the message, it shall not cause an application error and it may be ignored by the receiver if this is not explicitly defined as an error case. Otherwise, an application error occurs at the receiver and an answer message with the Result-Code set to DIAMETER_AVP_NOT_ALLOWED shall be sent back to the originator of the request. A Failed-AVP AVP containing a copy of the corresponding Diameter AVP shall be included in this message.

– An optional Information Element (marked as (O) in the table) may be present or absent in the command, at the discretion of the application at the sending entity. Absence or presence of this Information Element shall not cause an application error and may be ignored by the receiver.

When a procedure is required to determine whether two S-CSCF names are equal, the rules for SIP URI comparison specified in RFC 3261 clause 19.1.4 shall apply.

When a procedure is required to determine the Public Identity used for an identity lookup in HSS and SLF, the HSS and SLF shall use the Public Identity from the SIP URI or Tel URI as contained in the Public-Identity AVP that is in canonical form as described by TS 23.003 [17].

Unknown permanent failure error codes shall be treated in the same way as DIAMETER_UNABLE_TO_COMPLY. For unknown transient failure error codes the request may be repeated, or handled in the same way as DIAMETER_UNABLE_TO_COMPLY.

6.1 Location management procedures

6.1.1 User registration status query

This procedure is used between the I-CSCF and the HSS during SIP registrations. The procedure is invoked by the I-CSCF, corresponds to the combination of the functional level operations Cx-Query and Cx-Select-Pull (see TS 23.228 [1]) and is used:

– To authorize the registration of the distinct Public User Identity, checking multimedia subsystem access permissions and roaming agreements.

– To perform a first security check, determining whether the distinct Public User Identity in the message is associated with the Private User Identity sent in the message.

– To obtain either the S-CSCF where the distinct Public User Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), or the list of capabilities that the S-CSCF has to support.

This procedure is mapped to the commands User-Authorization-Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.1.1.1 and 6.1.1.2 detail the involved information elements.

Table 6.1.1.1: User registration status query

Information element name	Mapping to Diameter AVP	Cat.	Description
Public User Identity (See 7.2)	Public-Identity	M	Public User Identity to be registered
Visited Network Identifier (See 7.1)	Visited-Network-Identifier	M	Identifier that allows the home network to identify the visited network
Type of Authorization (See 7.14)	User-Authorization-Type	C	Type of authorization requested by the I-CSCF. If the request corresponds to a de-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is equal to zero, this AVP shall be present in the command and the value shall be set to DE-REGISTRATION. If the request corresponds to an initial registration or a re-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is not equal to zero then this AVP may be absent from the command. If present its value shall be set to REGISTRATION. If the request corresponds to an initial registration or a re-registration or a de-registration and the I-CSCF explicitly queries the S-CSCF capabilities, then this AVP shall be present in the command and the value shall be set to REGISTRATION_AND_CAPABILITIES. The I-CSCF shall use this value when the S-CSCF currently assigned to the Public User Identity in the HSS, cannot be contacted and a new S-CSCF needs to be selected. The I-CSCF shall also use this value for RLOS related registrations when the S-CSCF currently assigned to the Public User Identity in the HSS does not support RLOS (see 3GPP TS 23.228 [1] annex Z) and a new S-CSCF (supporting RLOS) needs to be selected. RLOS support of the different S-CSCFs shall be locally configured in the I-CSCF, and this capability is independent on the subscribed capabilities received from HSS.
Private User Identity (See 7.3)	User-Name	M	Private User Identity
Routing Information (See 7.13)	Destination-Host, Destination-Realm	C	If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF.
UAR Flags (See 7.19)	UAR-Flags	O	This Information Element contains a set of indications. See 7.19 for the content of the information element.

Table 6.1.1.2: User registration status response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result (See 7.6)	Result-Code / Experimental-Result	M	Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
S-CSCF capabilities (See 7.5)	Server-Capabilities	O	Required capabilities of the S-CSCF to be assigned to the IMS Subscription.
S-CSCF Name (See 7.4)	Server-Name	C	Name of the assigned S‑CSCF.

6.1.1.1 Detailed behaviour

The HSS shall, in the following order (if there is an error in any of the following steps the HSS shall stop processing and return the corresponding error code, see TS 29.229 [5]):

0. If the HSS supports WebRTC as described in TS 23.228 [1] clause U.2.1.4, it shall check if the Private User Identity and the Public User Identity are managed by a third party, if so the HSS continues in step 4.

NOTE : How the HSS identifies that the Private User Identity and the Public User Identity are managed by a third party for WebRTC and how the HSS identifies the corresponding user profile are implementation specific.

1. Check that the Private User Identity and the Public User Identity exists in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn’t, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

3. Check that the Public User Identity received in the request is associated with the Private User Identity received in the request. If not Experimental-Result-Code shall be set to DIAMETER_ERROR _IDENTITIES_DONT_MATCH.

4. Check whether the Public User Identity received in the request is barred from the establishment of multimedia sessions.

– If it is an IMS Emergency Registration (by checking the UAR Flags) or the Public User Identity received in the request is not barred, continue to step 5.

– Otherwise, the HSS shall check whether there are other non-barred Public User Identities to be implicitly registered with that one.

– If so, continue to step 5.

– If not, Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED.

5. Check the User-Authorization-Type received in the request:

– If it is REGISTRATION or if User-Authorization-Type is absent from the request, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration:

– If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. Continue to step 6.

– If it is DE_REGISTRATION, the HSS may not perform any check regarding roaming. Continue to step 6.

– If it is REGISTRATION_AND_CAPABILITIES, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration:

– If it is not, and the Public User Identity is allowed to roam in the visited network (if not Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED) and authorized to register (if not Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED). The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. If an S-CSCF is already assigned in the HSS and IMS Restoration Procedures are supported in the HSS, the HSS shall set the S-CSCF reassignment pending flag and shall allow overwriting of the S-CSCF name in the next SAR request. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing.

– If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it can select any available S-CSCF. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing.

6. Check the state of the Public User Identity received in the request:

– If it is registered, the HSS shall return the stored S-CSCF name. No S-CSCF capabilities shall be present in the response. If User-Authorization-Type is equal to REGISTRATION or is absent, Experimental-Result-Code shall be set to DIAMETER_SUBSEQUENT_REGISTRATION. If User-Authorization-Type is equal to DE-REGISTRATION, Result-Code shall be set to DIAMETER_SUCCESS.

– If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) and User-Authorization-Type is equal to DE-REGISTRATION, the HSS shall return the stored S-CSCF name and the Result-Code shall be set to DIAMETER_SUCCESS. If the User-Authorization-Type is equal to REGISTRATION or is absent, then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities.

– If it is not registered yet, the HSS shall check the value of User-Authorization-Type received in the request:

– If the value of User-Authorization-Type is DE_REGISTRATION and the Authentication pending flag is set, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF capabilities. Otherwise, if Authentication pending flag is not set, the HSS shall not return any S-CSCF name or S-CSCF capabilities. The HSS shall set the Experimental-Result-Code to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED in the response.

– If the value of User-Authorization-Type is REGISTRATION or is absent, then the HSS shall check if there is at least one Public User Identity within the IMS Subscription with an S-CSCF name assigned.

– If there is at least one Public User Identity within the IMS Subscription that is registered, the HSS shall return the S-CSCF name assigned for that Public User Identity and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities.

– If there is at least one Public User Identity within the IMS Subscription that is unregistered (i.e registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored), then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities.

– If there is no identity of the user within the same IMS Subscription that is registered or unregistered, the HSS shall check if there is an S-CSCF name stored for the user (e.g. the user is being authenticated by the S-CSCF as indicated by the Authentication pending flag). If it is, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities.

– If there is not any Public User Identity within the IMS Subscription with an S-CSCF name assigned, then the HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it may select any available S-CSCF. Experimental-Result-Code shall be set to DIAMETER_FIRST_REGISTRATION. The HSS shall not return any S-CSCF name.

If the HSS cannot fulfil received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response.

6.1.2 S-CSCF registration/deregistration notification

This procedure is used between the S-CSCF and the HSS. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-Put and Cx-Pull (see TS 23.228 [1]) and is used:

– To assign an S-CSCF to a Public Identity, or to clear the name of the S-CSCF assigned to one or more Public Identities.

– To download from HSS the relevant user information for the S-CSCF.

– To backup and retrieve the S-CSCF Restoration Information (see TS 23.380 [19]) in the HSS.

– To provide a P-CSCF Restoration Indication, and optionally, the address of the failed P-CSCF, to the HSS and trigger P-CSCF Restoration mechanism.

This procedure is mapped to the commands Server-Assignment-Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.1.2.1 and 6.1.2.2 describe the involved information elements.

Table 6.1.2.1: S-CSCF registration/deregistration notification request

Information element name	Mapping to Diameter AVP	Cat.	Description
Public User Identity / Public Service Identity (See 7.2 and 7.2a)	Public-Identity	C	Public Identity or list of Public Identities. One and only one Public Identity shall be present if the Server-Assignment-Type is any value other than TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, USER_DEREGISTRATION_STORE_SERVER_NAME or ADMINISTRATIVE_DEREGISTRATION. If Server-Assignment-Type indicates deregistration of some type and Private Identity is not present in the request, at least one Public Identity shall be present.
S-CSCF Name (See 7.4)	Server-Name	M	Name of the S-CSCF.
Private User Identity / Private Service Identity (See 7.3 and 7.3a)	User-Name	C	Private Identity. It shall be present if it is available when the S-CSCF issues the request. It may be absent during the initiation of a session to an unregistered Public Identity (Server-Assignment-Type shall contain the value UNREGISTERED_USER) or after S-CSCF recovery upon originating request different than REGISTER (Server-Assignment-Type shall contain the value NO_ASSIGNMENT). In case of de-registration, Server-Assignment-Type equal to TIMEOUT_DEREGISTRATION, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME if no Public-Identity AVPs are present then User-Name AVP shall be present.
Server Assignment Type (See 7.8)	Server-Assignment-Type	M	Type of update, request or notification that the S-CSCF requests in the HSS (e.g: de-registration). See 3GPP TS 29.229 [5] for all the possible values.
User Data Already Available (See 7.16)	User-Data-Already-Available	M	This indicates if the user profile and charging information and, if supported and present in the subscription, allowed WAF and/or WWSF identities are already available in the S-CSCF. In the case where Server-Assignment-Type is not equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER, the HSS shall not use User Data Already Available when processing the request.
Routing Information (See 7.13)	Destination-Host	C	If the S-CSCF knows the HSS name, the Destination-Host AVP shall be present in the command. This information is available if the request belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent as a consequence of a session termination for an unregistered Public Identity. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the S-CSCF.
Wildcarded Public Identity (See 7.2b)	Wildcarded-Public-Identity	O	If the request refers to a Wildcarded PSI or Wildcarded Public User Identity, and the Server-Asignment-Type is set to UNREGISTERED_USER, NO_ASSIGNMENT, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION, the S-CSCF may include the corresponding Wildcarded PSI or Wildcarded Public User Identity in this information element. If this element is present, it shall be used by the HSS to identify the identity affected by the request. The terms Public Identity or Public Service Identity in the detailed behaviour refer then to the Wildcarded Public Identity.
S-CSCF Restoration Information (See 7.21)	SCSCF-Restoration-Info	C	When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION or RE_REGISTRATION, and any of the related restoration information changed compared to the previous one, the S-CSCF shall send this information element to the HSS. This information allows a later retrieval in case of an S-CSCF service interruption.
Multiple-Registration-Indication (See 7.23)	Multiple-Registration-Indication	C	When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION and the registration is a multiple registration and the Public User Identity is not stored as registered with the Private User Identity as in the request in the S-CSCF, the S-CSCF shall send this information element to the HSS.
Session-Priority (See 7.24)	Session-Priority	O	This information element, if present, shall indicate the session’s priority to the HSS.
SAR Flags (See 7.28)	SAR-Flags	O	This Information Element contains a set of indications. See 7.28 for the content of the information element.
Failed P-CSCF	Failed-PCSCF	O	If present, this Information Element shall contain the address (FQDN and/or IP addresses) of a failed P-CSCF; it shall only be included if the SAR Flags IE contains the "P-CSCF Restoration Indication" (see clause 7.28).

Table 6.1.2.2: S-CSCF registration/deregistration notification response

Information element name	Mapping to Diameter AVP	Cat.	Description
Private User Identity / Private Service Identity (See 7.3 and 7.3a)	User-Name	C	Private Identity. It shall be present if it is available when the HSS sends the response. It may be absent in the following error case: when the Server-Assignment-Type of the request is UNREGISTERED_USER and the received Public Identity is not known by the HSS.
Registration result (See 7.6)	Result-Code / Experimental-Result	M	Result of registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
User Profile (See 7.7)	User-Data	C	Relevant user profile. It shall be present when Server-Assignment-Type in the request is equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER according to the rules defined in clause 6.6. If the S-CSCF receives more data than it is prepared to accept, it shall perform the de-registration of the Private Identity with Server-Assignment-Type set to DEREGISTRATION_TOO_MUCH_DATA and send back a SIP 3xx or 480 (Temporarily Unavailable) response, which shall trigger the selection of a new S-CSCF by the I-CSCF, as specified in 3GPP TS 24.229 [8].
Charging Information (See 7.12)	Charging-Information	C	Addresses of the charging functions. It shall be present when the User-Data AVP is sent to the S-CSCF according to the rules defined in clause 6.6. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other elements shall be included if they are available.
Associated Private Identities	Associated-Identities	O	This AVP contains all Private Identities, which belong to the same IMS subscription as the Private Identity or Public Identity received in the SAR command. If the IMS subscription contains only single Private Identity this AVP shall not be present.
Loose-Route Indication	Loose-Route-Indication	C	This AVP indicates to the S-CSCF that loose-route mechanism shall be applied to the public identities contained in the user profile received from the HSS. If the loose-route mechanism is required, this AVP shall be present and set to LOOSE_ROUTE_REQUIRED. If the Loose-Route mechanism is not required, this AVP may be either absent or present. If present, it shall be set to LOOSE_ROUTE_NOT_REQUIRED.
S-CSCF Restoration Information (See 7.21)	SCSCF-Restoration-Info	C	This information shall be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either UNREGISTERED_USER or NO_ASSIGNMENT. This information shall also be present if it was stored by the S-CSCF in the HSS and the SAR indicates it is related to a multiple registration and Server-Assignment-Type is REGISTRATION. This information may be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either REGISTRATION or RE-REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command.
Associated Registered Private Identities (See 7.22)	Associated-Registered-Identities	C	This AVP contains all Private Identities that were registered with the Public Identity received in the SAR command. The HSS shall send this information element if the IMS Restoration Procedures are supported and the value of Server-Assignment-Type in the request is REGISTRATION or RE_REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command. Otherwise, this AVP shall not be present.
S-CSCF Name (See 7.4)	Server-Name	C	Name of the assigned S-CSCF. This AVP shall be present, if the requesting S-CSCF name is different from the previously assigned S-CSCF name stored in the HSS.
Wildcarded Public Identity (See 7.2b)	Wildcarded-Public-Identity	C	This AVP shall be present if: – the value of Server-Assignment-Type in the request was UNREGISTERED_USER or NO_ASSIGNMENT and – the Wildcarded-Public-Identity AVP in the request was not present and – the Public Identity in the request fell within the range of a Wildcarded Public User Identity in the HSS whose state is registered/unregistered. If this element is present, it shall be used by the S-CSCF to identify the identity affected by the request.
Priviledged-Sender Indication (See 7.26)	Priviledged-Sender-Indication	O	This AVP indicates if the Private User Identity shall be considered as a priviledged sender. If not present, it means that the Private User Identity is not considered a priviledged sender.
Allowed WAF and/or WWSF Identities (See 7.29)	Allowed-WAF-WWSF-Identities	C	Addresses of the WAFs and/or WWSFs the subscription is allowing to use. This AVP shall be present if both a) it is applicable for the subscription and b) the User-Data AVP is present.

6.1.2.1 Detailed behaviour

On registering/deregistering a Public Identity the S-CSCF shall inform the HSS. The same procedure is used by the S-CSCF:

– to get the user information which contains the user profile, the charging information and the allowed WAF and/or WWSF Identities. The relevant user profile downloaded is described in more detailed in clauses 6.5.1 and 6.6.

– to provide a P-CSCF Restoration Indication to the HSS when the S-CSCF, supporting the HSS based P-CSCF restoration mechanism described in TS 23.380 [19], has identified a P-CSCF failure for a given UE and then triggers the P-CSCF Restoration mechanism execution for this UE.

The Public-Identity AVP and User-Data AVPs in this command pair shall contain only one type of identities i.e. either only Public User Identities, or only Public Service Identities. User initiated registration/deregistration procedures (i.e. server-assignment-type is set to RE_REGISTRATION, USER_DEREGISTRATION, etc.) shall only be allowed for distinct Public User Identities.

The HSS holds information about the state of registration of all the identities related to an IMS Subscription. The S-CSCF uses this procedure to update such states. For Shared Public User Identities, the S-CSCF shall initiate this procedure towards the HSS for each Private User Identity undergoing a Registration or Deregistration related to the Shared Public User Identity. For implicitly registered identities, the rules defined in Clause 6.5.1 shall apply.

When the request message was received because of a terminating session request, the HSS may prioritise the received request message according to priority level received within the Session-Priority AVP.

NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message.

The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TS 29.229 [5]):

1. Check that the Public Identity and Private Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. The HSS may check whether the Private and Public Identities received in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH.

3. If more than one Public-Identity AVP is present and the Server-Assignment-Type is one of the values defined in Table 6.1.2.1 as applying for only one identity, then the Result Code shall be set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no user information shall be returned.

4. The HSS shall check the Public Identity type received in the request.

– If the identity in the request is a distinct Public User Identity, continue in step 5, otherwise the HSS shall check the server-assignment-type:

If it indicates REGISTRATION, RE_REGISTRATION, USER_DEREGISTRATION, USER_DEREGISTRATION_STORE_SERVER_NAME, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE.

– If the identity in the request is a Public Service Identity, then check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.

5. Check the Server Assignment Type value received in the request:

– If it indicates REGISTRATION or RE_REGISTRATION, the HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data.

If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set, the HSS shall include the name of the previously assigned S-CSCF in the response message and the Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag.

If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS, the HSS shall download the relevant user information taking into consideration the value set in the User-Data-Already-Available AVP (see clause 6.6). The Result-Code shall be set to DIAMETER_SUCCESS and the HSS shall set the registration state of the Public User Identity as registered (if not already registered). If the S-CSCF Restoration Information is included in the request and the HSS implements IMS Restoration procedures, and if it is RE_REGISTRATION, the HSS shall store this information. If the Public User Identity’s authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. If the loose-route mechanism is required for the registered Public User Identities, the Loose-Route-Indication AVP shall be added to the answer message. If there are multiple Private User Identities being registered with the Public Identity received in the request message, and the IMS Restoration Procedures are supported in the HSS, the Associated-Registered-Identities AVP shall be added to the answer message and it shall contain all Private User Identities being registered with the Public Identity, and subject to the operator policy, the HSS may include all stored S-CSCF Restoration Information groups associated to the Private User Identities in the response.

NOTE 2: If the HSS returns all the S-CSCF Restoration Information groups in the response, the S-CSCF can ignore the Associated-Registered-Identities AVP and skip additional Server-Assignment-Request since the information is already made available.

If it is REGISTRATION and the HSS implements IMS Restoration procedures, if multiple registration indication is included in the request and the Public User Identity is stored as registered in the HSS, and there is restoration information related to the Private User Identity, the HSS shall not overwrite the stored S-CSCF Restoration Information, instead, it shall send the stored S-CSCF restoration information together with the user profile in the SAA. Subject to the operator policy, if there is S-CSCF Restoration Information associated with several Private User Identities, the HSS may include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. Otherwise, the HSS shall store the received S-CSCF restoration information. The Result-Code shall be set to DIAMETER_SUCCESS.

– If it indicates UNREGISTERED_USER, the following applies.

If the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature. If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED.

The HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data:

– If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include the name of the previously assigned S-CSCF in the response message and the Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

– If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag.

– If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS, the HSS shall store the S-CSCF name.

The HSS shall check the Public Identity registration state:

– If the registration state of the Public Identity is not registered or unregistered, the HSS shall set or keep the registration state of the Public Identity as unregistered, i.e. registered as a consequence of an originating or terminating request and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message.

– If the registration state of the Public Identity is registered and IMS restoration procedures are not supported, the HSS shall set the registration state of the Public identity as unregistered, clear any S-CSCF Restoration Information associated with the Public User Identity (if any) and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message.

NOTE 3: The case where S-CSCF Restoration Information is stored in the HSS even though IMS Restoration Procedures are not supported corresponds to the situation where the HSS supports IMS Restoration Procedures but a new assigned S-CSCF does not, while the former S-CSCF supported this feature.

– If the registration state of the Public Identity is registered and IMS restoration procedures are supported and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include in the response all S-CSCF Restoration Information related with the Public User Identity. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE.

– If the registration state of the Public Identity is Registered and IMS Restoration Procedures are supported and a P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS shall set the registration state of the Public identity as Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity (if any). The Result-Code shall be set to DIAMETER_SUCCESS.

If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription.

If the S-CSCF receives a wildcarded public identity from the I-CSCF, the S-CSCF shall use this wildcarded public identity to fetch the user profile (i.e. by sending a Cx-SAR including Wildcarded-Public-Identity AVP if the profile is not available) and registration information locally stored.

If the S-CSCF does not receive a wildcarded public identity, the S-CSCF shall not perform wildcarded public identity matching and shall use the public identity received instead to fetch the user profile (i.e. by sending a Cx-SAR without including Wildcarded-Public-Identity AVP if the profile is not available) and registration information.

NOTE 4: There may be SIP requests in which the S-CSCF does not receive information of a wildcarded public identity, e.g. originating call from an AS on behalf of a user.

NOTE 5: Since a distinct public identity falling into the range of a wildcarded public identity can have a different service profile, the S-CSCF does not perform the wildcarded public identity matching against the public identity received to avoid using the wrong service profile.

If the Wildcarded-Public-Identity AVP is not received and if the Public Identity falls within the range of a wildcarded public identity whose registration state is registered and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall not overwrite the registration state. The Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE and the HSS shall include the Wildcarded-Public-Identity AVP in the response. Upon reception of this error, the S-CSCF should behave as if it has received a wildcarded public identity in the first place.

If SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS supporting the P-CSCF-Restoration–mechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TS 23.380 [19] clause 5.4. The Result-Code shall be set to DIAMETER_SUCCESS.

– If it indicates TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION, the following applies.

If it indicates ADMINISTRATIVE_DEREGISTRATION and if the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature. If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED.

The HSS shall check the registration state for all the Public Identities in the request.

– If a Private User Identity is present in the request, if the request did not contain Public Identities the HSS shall check the registration state of the Public Identities associated with the Private Identity identified in the request. For each Public Identity:

– If the registration state of the Public User Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities.

– If the Public User Identity is currently registered with only one Private User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name and any S-CSCF Restoration Information associated with the Public User Identity.

– If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with this Private User Identity.

– If a Private User Identity is absent in the request, if the Public User Identity is currently registered with more than one Private User Identity, the HSS shall stop processing this request and shall set the Result-Code to DIAMETER_MISSING_AVP.

– if the registration state of the Public Identity is Unregistered, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity.

In case of ADMINISTRATIVE_DEREGISTRATION, if SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS or combined HSS-UDM supporting the P-CSCF-Restoration-mechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TS 23.380 [19] clause 5.4, and SMF and/or AMF, using the Nudm_UECM_P-CSCF-RestorationNotification service operation as described in TS 23.380 [19] clause 5.8.4.

The Result-Code shall be set to DIAMETER_SUCCESS

– If it indicates TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME the HSS decides whether to keep the S-CSCF name associated to the Private User Identity stored or not for all the Public User Identities that the S-CSCF indicated in the request. If no Public User Identity is present in the request, the Private User Identity shall be present.

– If the HSS decides to keep the S-CSCF name stored the HSS shall keep the S-CSCF name stored for all the Public User Identities associated to the Private User Identity. The Result-Code shall be set to DIAMETER_SUCCESS.

The HSS shall check if each Public User Identity in the request is currently registered with one or more Private User Identities. If the request did not contain Public User Identities the HSS shall check if each Public User Identity associated with the Private User Identity in the request is currently registered with one or more Private User Identities. For each Public User Identity;-

– If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity

– If more than one Private User Identity that shares that Public User Identity is currently registered with the Public User Identity the HSS shall keep the registration state of the Public User Identity as Registered. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with the Private User Identity in the request.

– If the HSS decides not to keep the S-CSCF name the Experimental-Result shall be set to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED.

– If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name associated with Public User Identity.

– If it indicates NO_ASSIGNMENT, the HSS checks whether the Public Identity is assigned for the S-CSCF requesting the data. If the requesting S-CSCF is not the same as the assigned S-CSCF and the S-CSCF reassignment pending flag is not set, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY, otherwise the HSS shall download the relevant user information and the Result-Code shall be set to DIAMETER_SUCCESS. If relevant S-CSCF Restoration Information is stored in the HSS and IMS Restoration Procedures are supported, it shall be added to the answer message. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription.

NOTE 6: the check of the S-CSCF reassignment pending flag is needed since an S-CSCF supporting restoration procedures can receive a user initiated de-registration for a Public Identity for which it does not have any registration data (see TS 23.380 [19]). In such case, the S-CSCF indicates NO_ASSIGNMENT in Server-Assignment-Type to retrieve any possible restoration information from the HSS.

– If it indicates AUTHENTICATION_FAILURE (e.g. there is a mismatch in IP-address secure binding information) or AUTHENTICATION_TIMEOUT (e.g. no response to Digest challenge), the HSS shall keep the registration state of the Public User Identity. The HSS shall check the registration state for the Public User Identity in the request and only if the registration state of the Public User Identity is Not Registered, the HSS shall clear the S-CSCF name associated with the Public User Identity.

If the Public User Identity’s authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. The Result-Code shall be set to DIAMETER_SUCCESS.

If the HSS cannot fulfil the received request, e.g. due to database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. The HSS shall not modify any registration state nor download any Public Identity information to the S-CSCF.

See clause 8.1.2 and 8.1.3 for the description of the handling of the error situations: reception of an S-CSCF name different from the one stored in the HSS and reception of a Server-Assignment-Type value not compatible with the registration state of the Public Identity.

6.1.3 Network initiated de-registration by the HSS, administrative

In case of network initiated de-registration of by the HSS, the HSS change the state of the Public Identities to Not Registered and send a notification to the S-CSCF indicating the identities that shall be de-registered. The procedure is invoked by the HSS, corresponds to the functional level operation Cx-Deregister (see TS 23.228 [1]).

This procedure is mapped to the commands Registration-Termination-Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.1.3.1 and 6.1.3.2 describe the involved information elements.

Table 6.1.3.1: Network Initiated Deregistration by HSS request

Information element name	Mapping to Diameter AVP	Cat.	Description
Public User Identity / Public Service Identity (See 7.2 and 7.2a)	Public-Identity	C	It contains the list of Public Identities that are de-registered, in the form of SIP URL or TEL URL. Public-Identity AVP shall be present if the de-registration reason code is NEW_SERVER_ASSIGNED. It may be present with the other reason codes.
Private User Identity / Private Service Identity (See 7.3 and 7.3a)	User-Name	M	It contains the Private Identity in the form of a NAI. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure.
Reason for de-registration (See 7.11)	Deregistration-Reason	M	The HSS shall send to the S-CSCF a reason for the de-registration. The de-registration reason is composed of two parts: one textual message (if available) that is intended to be forwarded to the user that is de-registered, and one reason code (see 3GPP TS 29.229 [5]) that determines the behaviour of the S-CSCF
Routing Information (See 7.13)	Destination-Host	M	It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF.
Associated Private Identities	Associated-Identities	O	This AVP contains Private Identities, which belong to the same IMS subscription as the Private Identity in the User-Name AVP and should be de-registered together with that one. If the IMS subscription contains only a single Private Identity, this AVP shall not be present.
RTR Flags (See 7.30)	RTR-Flags	O	This information element contains a bit mask. See 7.30 for the meaning of the bits.

Table 6.1.3.2: Network Initiated Deregistration by HSS response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result (See 7.6)	Result-Code / Experimental-Result	M	This information element indicates the result of de-registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Associated Private Identities	Associated-Identities	C	This AVP shall be present if the S-CSCF de-registered more than one Private Identity with the request. It contains all Private Identities that have been deregistered together with the one in the User-Name AVP of the request.
Identities with Emergency Registration (See 7.25)	Identity-with-Emergency-Registration	C	This information element indicates a list of pairs of private and public user identities which have not been de-registered due to emergency registration.

6.1.3.1 Detailed behaviour

The HSS shall de-register the affected identities and invoke this procedure to inform the S-CSCF. The S-CSCF shall remove all the information stored in the S-CSCF for the affected identities.

The HSS may de-register:

– One Public Identity or a list of Public Identities. HSS may include all Public User Identities associated with the User-Name AVP to the request. This option is applicable with all reason codes.

– One or more Private Identities of the IMS Subscription with all associated Public Identities. No Public-Identity AVPs shall be present in this case. This option is applicable with reason codes PERMANENT_TERMINATION, SERVER_CHANGE, and REMOVE_S-CSCF.

– All Public Service Identities that match a Wildcarded Public Service Identity. In this case the HSS may send one of the Public Service Identities that was received in the Server Assignment Request for that Wildcarded Public Service Identity and the associated Private Service Identity.

– A Wildcarded Public User Identity. In this case the HSS shall send a distinct Public User Identity that belongs to the same implicit registration set as the Wildcarded Public User Identity and the associated Private User Identity.

The HSS shall send in the Deregistration-Reason AVP the reason for the de-registration, composed by a textual message (if available) aimed for the user and a reason code that determines the action the S-CSCF has to perform. The possible reason codes are:

– PERMANENT_TERMINATION: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to the Public Identity and associated implicitly registered/unregistered Public Identities (if any) for the Private Identity(ies) indicated in the request (e.g. due to an IMS subscription cancellation, or modification, or a removal of IP-address secure binding information when GIBA is used). This reason also indicates that no other S-CSCF can be assigned.

The HSS shall check the registration state of the Public Identities. If no Public Identities are involved, the HSS shall check the registration state of the Public Identities associated with the Private User Identity identified. For each Public Identity:

– If the registration state of the Public Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities.

– If the Public User Identity is currently registered with only one Private User Identity, the HSS shall check whether the Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response.

– If included, the HSS shall keep the S-CSCF name associated with the Public User Identity and set the registration state of the Public User Identity to Unregistered.

– If not included, the HSS shall clear the S-CSCF name associated with the Public User Identity, and set the registration state of the Public User Identity to Not Registered The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered.

– If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered.

– If the registration state of the Public Identity is Unregistered, the HSS shall check whether this Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response.

– If included, the HSS shall keep the S-CSCF name associated with the Public User Identity.

– If not included, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity.

– NEW_SERVER_ASSIGNED: The HSS indicates to the S-CSCF that a new S-CSCF has been allocated to the IMS Subscription e.g. because the previous assigned S-CSCF was unavailable during a registration procedure. The S-CSCF shall remove all information for all of the Public Identities indicated in the request.

– SERVER_CHANGE: The HSS indicates to the S-CSCF that the de-registration is requested to force the selection of new S-CSCF to assign to the IMS Subscription (e.g. when the S-CSCF capabilities are changed in the HSS or when the S-CSCF indicates that it has not enough memory for the updated User Profile). The HSS shall set the registration state to "Not Registered" and clear the S-CSCF name for all of the Public Identities affected by the request. If the S-CSCF does not indicate in the response all the Private Identities that were in the request, the HSS shall repeat this request for each of the remaining Private Identities in the IMS Subscription that are known to the S-CSCF. The S-CSCF should start the network initiated de-registration towards the user, i.e. all registrations within the IMS Subscription are de-registered and the user is asked to re-register to all existing registrations.

– REMOVE_S-CSCF: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to an unregistered Public Identity(ies) (i.e registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) for a given IMS Subscription.

The HSS shall check if an emergency registration exists in the S-CSCF, checking for each Public Identity contained in the request whether it is present in the information element Identities with Emergency Registrations returned by S-CSCF.

– If an emergency registration does not exist in S-CSCF, for each Public Identity contained within the request, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. The S-CSCF shall remove all information related to the Public User Identity contained within the request.

– If an emergency registration exists in S-CSCF for one or more Public User Identities contained in the request, the S-CSCF should include the corresponding Private Identity /Public User Identity pairs in the information element Identities with Emergency Registrations in the answer. The HSS, when receiving such an answer, shall not change the registration state of the Public User Identities present in the information element Identities with Emergency Registrations and shall keep unchanged the S-CSCF name associated with these Public User Identities.

Public Identities which are emergency registered in the S-CSCF shall not be de-registered when a Cx-Deregistration request with a -reason code of PERMANENT_TERMINATION or REMOVE_S-CSCF is received from the HSS. In this case

– if all to be de-registered identities are emergency registered, a Result-Code set to DIAMETER_UNABLE_TO_COMPLY and a list of Private / Public Identity pairs which are emergency registered shall be returned to the HSS

– if a proper subset of the to be de-registered identities are emergency registered, a Result-Code of DIAMETER_LIMITED_SUCCESS and a list of Private Identity / Public Identity pairs which are emergency registered shall be returned to the HSS.

NOTE 1: If the Public Identity that is emergency registered has normal registration as well, then for the normal registration the S-CSCF will perform the detailed de-registration procedures towards the UE for each reason code as described in TS 24.229 [8].

NOTE 2: It is assumed that Public Identities which are implicitly registered along with an emergency registration are also emergency registered.

The detailed de-registration procedures performed by the S-CSCF are described in TS 24.229 [8].

6.1.4 User location query

This procedure is used between the I-CSCF and the HSS to obtain the name of the S-CSCF assigned to a Public Identity, or the name of the AS hosting a PSI for direct routing. The procedure is invoked by the I-CSCF, is performed per Public Identity, and corresponds to the functional level operation Cx-Location-Query (see TS 23.228 [1]).

This procedure is mapped to the commands Location Info Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.1.4.1 and 6.1.4.2 detail the involved information elements.

Table 6.1.4.1: User Location query

Information element name	Mapping to Diameter AVP	Cat.	Description
Public User Identity / Public Service Identity (See 7.2 and 7.2a)	Public-Identity	M	Public Identity
Routing information (See 7.13)	Destination-Host, Destination-Realm	C	If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF.
Originating Request (See 7.18)	Originating-Request	O	It indicates that the request is related to an originating SIP message.
Type of Authorization (See 7.14)	User-Authorization-Type	C	This information element shall be present and set to REGISTRATION_AND_CAPABILITIES by the I-CSCF if IMS Restoration Procedures are supported and the S-CSCF currently assigned to the Public User Identity in the HSS cannot be contacted.
Session Priority (See 7.24)	Session-Priority	O	This information element, if present, shall indicate the session’s priority to the HSS.

Table 6.1.4.2: User Location response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result (See 7.6)	Result-Code / Experimental-Result	M	Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
S-CSCF Name / AS name (See 7.4 and 7.4a)	Server-Name	C	Name of the assigned S-CSCF for basic IMS routing or the name of the AS for direct routing.
S-CSCF capabilities (See 7.5)	Server-Capabilities	O	It contains the information to help the I-CSCF in the selection of the S-CSCF.
Wildcarded Public Identity (See 7.2b)	Wildcarded-Public-Identity	O	If the requests refers to a Wildcarded PSI or Wildcarded Public User Identity (the Public Identity in the request matches a Wildcarded PSI or Wildcarded Public User Identity in the HSS), the HSS shall include the corresponding Wildcarded Public Identity in this information element. The matching of distinct Public Identies takes precedence over the matching of wildcarded public identities.
LIA Flags (See 7.27)	LIA-Flags	O	This information element contains a bit mask. See 7.27 for the meaning of the bits.

6.1.4.1 Detailed behaviour

The HSS may prioritise the received request message according to priority level received within the Session-Priority AVP.

NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message.

The HSS shall, in the following order (if an error occurs in any of the ste

The HSS shall, in the following order (if an error occurs in any of the steps the HSS shall stop processing and return the corresponding error code, see TS 29.229 [5]):

1. Check that the Public Identity is known. If not the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. Check the type of the Public Identity contained in the request:

– If this is a Public User Identity, continue to step 2a.

– If this is a Public Service Identity:

– Check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.

– Check if the name of the AS hosting the Public Service Identity is stored in the HSS and that the request does not contain the Originating-Request AVP.

– If this is the case, if IMS Restoration Procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES:

– If it is, the HSS shall reject the request with Result-Code set to DIAMETER_UNABLE_TO_COMPLY.

– Otherwise, the HSS shall return the AS name and the Result-Code AVP shall be set to DIAMETER_SUCCESS. HSS may set PSI Direct Routing Indication bit in LIA-Flags AVP, then I-CSCF shall not perform IMS Restoration Procedures (see clause 4.3.3 in TS 23.380 [19]).

– Otherwise, continue to step 2a.

2a. If IMS Restoration procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES:

– If it is, then the HSS may return the Server-Capabilities AVP. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. Also the HSS shall set the S-CSCF reassignment pending flag and allow overwriting of the S-CSCF name in the next SAR request, which enables the I-CSCF to select an S-CSCF. The Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing.

– Otherwise, continue to step 3.

3. Check the state of the Public Identity received in the request, and where necessary, check if the Public Identity has terminating services related to the unregistered state.

– If it is registered, the HSS shall return the stored S-CSCF name. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code AVP shall be set to DIAMETER_SUCCESS.

– If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS.

– If it is not registered, but either it has terminating services related to unregistered state or the request contains the Originating-Request AVP, the HSS shall check if there is at least one Public Identity within the IMS Subscription with an S-CSCF name assigned:

– If this is the case the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS.

– If there is not any S-CSCF name assigned to a Public Identity within the IMS Subscription, the HSS may return information about the required S-CSCF capabilities, which enables the I-CSCF to select an S-CSCF. The Server-Capabilities AVP may be present. The HSS shall send the same server capability set that is sent in the user registration status response during the registration. If Server-Capabilities AVP is not present, the I-CSCF shall understand that any S-CSCF is suitable for the IMS Subscription. The Server-Name AVP shall not be present. The Experimental-Result-Code shall be set to DIAMETER_UNREGISTERED_SERVICE.

– If it is not registered or unregistered, and the Public Identity has no terminating services related to the unregistered state and the request does not contain the Originating-Request AVP, the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.

If the HSS cannot fulfil the received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response.

6.2 User data handling procedures

6.2.1 User Profile download

As part of the registration procedure ( TS 23.228 [1]) S-CSCF obtains user data and service related information by means of the Cx-Put Resp operation (see 6.1.2).

6.2.2 HSS initiated update of User Information

This procedure is initiated by the HSS to update at least one of the following user information in S-CSCF:

– User profile information and/or

– Charging information and/or

– Allowed WAF and/or WWSF Identities and/or

– SIP Digest authentication information in the S-CSCF.

This procedure shall not be used by the HSS to add, delete, or update the value of the IMSI.

This procedure corresponds to the functional level operation Cx-Update_Subscr_Data (see TS 23.228 [1]).

This procedure is mapped to the commands Push-Profile-Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.2.2.1 and 6.2.2.2 describe the involved information elements.

Table 6.2.2.1: User Profile Update request

Information element name	Mapping to Diameter AVP	Cat.	Description
Private User Identity / Private Service Identity (See 7.3 and 7.3a)	User-Name	M	Private Identity. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure.
User profile (See 7.7)	User-Data	C	Updated user profile (see clauses 6.5.2.1 and 6.6.1), with the format defined in clause 7.7. It shall be present if the user profile is changed in the HSS. If the User-Data AVP is not present, the SIP-Auth-Data-Item or Charging-Information AVP or Allowed-WAF-WWSF-Identities AVP shall be present.
Authentication Data (See 7.9)	SIP-Auth-Data-Item	C	SIP Digest authentication information. It shall be present if the used authentication scheme is SIP Digest and when password change has occurred in the HSS. If the SIP-Auth-Data-Item AVP is not present, the Charging-Information or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. See Table 6.3.6 for the contents of this information element.
Charging Information (See 7.12)	Charging-Information	C	Addresses of the charging functions. It shall be present if the charging addresses are changed in the HSS. If the Charging-Information AVP is not present, the SIP-Auth-Data-Item or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other charging information shall be included if it is available.
Routing Information (See 7.13)	Destination-Host	M	It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF.
Allowed WAF and/or WWSF Identities (See 7.29)	Allowed-WAF-WWSF-Identities	C	Addresses of the WAFs and/or WWSFs the subscription is allowing to use. It shall be present if the allowed WAF and/or WWSF identities are changed in the HSS.

Table 6.2.2.2: User Profile Update response

Information element name

Mapping to Diameter AVP

Cat.

Description

Result

(See 7.6)

Result-Code / Experimental-Result

This information element indicates the result of the update of User Profile in the S-CSCF.

Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]).

Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

6.2.2.1 Detailed behaviour

The HSS shall make use of this procedure to update the relevant user information to the S-CSCF. See clauses 6.5.2.1 and 6.6.1 for the rules of user profile updating. See clause 6.5.2.3 for the rules of Charging Information update. See clause 6.5.2.4 for the rules of SIP Digest Authentication Data update. See clause 6.5.2.5 for the rules of Allowed WAF and/or WWSF Identities update.

If there are multiple registered Private User Identities associated to the Public User Identity in the HSS, the HSS shall send only single request and select arbitrarily one of the Private User Identities and put it into the request. For updates of the profile of a Wildcarded Public Identity, the HSS shall send only one single request. That request shall contain the Wildcarded Public Identity.

The SIP-Auth-Data-Item AVP and/or Charging-Information AVP and/or the User-Data AVP shall be present in the request.

If the User-Data AVP is present in the request, the S-CSCF shall overwrite, for the Public Identities indicated in the User profile included in the request, current information with the information received from the HSS, except in the error situations detailed in table 6.2.2.1.1.

If the Charging-Information AVP is present in the request, the S-CSCF shall replace the existing charging information with the information received from the HSS.

The SIP-Auth-Data-Item AVP shall be present if the command is sent in order to update SIP Digest authentication information due to a password change.

If the S-CSCF receives data that it can not recognise, unsupported user data in a part of the request where it may not be ignored or more data than it can accept, it shall return the corresponding error code to the HSS as indicated in table 6.2.2.1.1. The S-CSCF shall not overwrite the data that it already has to give service to the IMS Subscription. The HSS shall initiate a network-initiated de-registration procedure towards the S-CSCF with Deregistration-Reason set to SERVER_CHANGE, which will trigger the assignment of a new S-CSCF.

If the HSS receives DIAMETER_ERROR_USER_UNKNOWN from the S-CSCF in the Push-Profile-Answer, then the HSS shall re-send the request using another arbitrarily selected registered Private Identity (if any). If restoration procedures are not supported, the HSS shall set the unknown Private User Identity’s registration status to "not registered"; this will allow the synchronization of the registration status in HSS and S-CSCF.

NOTE: If restoration procedures are supported, restoration procedures will ensure synchronization of the registration status in HSS and S-CSCF, i.e. the S-CSCF can either immediately retrieve the S-CSCF restoration information for the registered Public User Identity (sending SAR with Server Assignment Type set to NO_ASSIGNMENT), or wait for reception of a SIP request.

Table 6.2.2.1.1 details the valid result codes that the S-CSCF can return in the response.

Table 6.2.2.1.1: User information update response valid result codes

Result-Code AVP value	Condition
DIAMETER_SUCCESS	The request succeeded.
DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA	The request failed. The S-CSCF informs the HSS that the received user information contained information, which was not recognised or supported by the S-CSCF due to unsupported S-CSCF capabilities.
DIAMETER_ERROR_USER_UNKNOWN	The request failed because the Private Identity is not found in S-CSCF.
DIAMETER_ERROR_TOO_MUCH_DATA	The request failed. The S-CSCF informs to the HSS that it tried to push too much data into the S-CSCF.
DIAMETER_UNABLE_TO_COMPLY	The request failed.

6.3 Authentication procedures

This procedure is used between the S-CSCF and the HSS to exchange information to support the authentication between the end user and the home IMS network. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-AV-Req and Cx-AV-Req-Resp (see TS 33.203 [3]) and is used:

– To retrieve authentication vectors from the HSS.

– To resolve synchronization failures between the sequence numbers in the UE and the HSS for authentication schemes that support this capability (e.g. IMS-AKA).

– To promote the result of the NASS-level authentication to the IMS level.

– To retrieve the IP-address secure binding information for GPRS-IMS-Bundled Authentication (GIBA) from the HSS.

This procedure is mapped to the commands Multimedia-Auth-Request/Answer in the Diameter application specified in TS 29.229 [5]. Tables 6.3.1 through 6.3.7 detail the involved information elements.

Table 6.3.1: Authentication Request

Information element name	Mapping to Diameter AVP	Cat.	Description
Public User Identity (See 7.2)	Public-Identity	M	This information element contains the Distinct Public User Identity of the user
Private User Identity (See 7.3)	User-Name	M	This information element contains the Private User Identity
Number Authentication Items (See 7.10)	SIP-Number-Auth-Items	M	This information element indicates the number of authentication vectors requested. Certain authentication schemes do not support more than one set of authentication vectors (e.g. SIP Digest, GIBA).
Authentication Data (See 7.9)	SIP-Auth-Data-Item	M	See Table 6.3.2 for the contents of this information element.
S-CSCF Name (See 7.4)	Server-Name	M	This information element contains the name (SIP URL) of the S-CSCF.
Routing Information (See 7.13)	Destination-Host	C	If the S-CSCF knows the HSS name this AVP shall be present. This information is available if the MAR belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent in case of the initial registration. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the client.

Table 6.3.2: Authentication Data content in Authentication Request

Information element name	Mapping to Diameter AVP	Cat.	Description
Authentication Scheme (See 7.9.2)	SIP-Authentication-Scheme	M	This information element indicates the authentication scheme. See 3GPP TS 29.229 [5] for a list of values
Authentication Context (See 7.9.7)	SIP-Authentication-Context	C	This information element shall contain authentication-related information relevant for performing the authentication. It shall be absent for IMS-AKA authentication schemes.
Authorization Information (See 7.9.4)	SIP-Authorization	C	This information element shall only be present for a request due to an IMS-AKA synchronization failure. If present, only IMS-AKA authentication schemes are allowed.

Table 6.3.3: Void

Table 6.3.4: Authentication Request Response

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity (See 7.2)	Public-Identity	C	Public User Identity. It shall be present when the result is DIAMETER_SUCCESS.
Private User Identity (See 7.3)	User-Name	C	Private User Identity. It shall be present when the result is DIAMETER_SUCCESS.
Number Authentication Items (See 7.10)	SIP-Number-Auth-Items	C	This information element indicates the number of authentication vectors delivered in the Authentication Data information element. It shall be present when the result is DIAMETER_SUCCESS. For SIP Digest, NASS Bundled authentication and GIBA this AVP shall be set to a value of 1.
Authentication Data (See 7.9)	SIP-Auth-Data-Item	C	If the SIP-Number-Auth-Items AVP is equal to zero or it is not present, then this information element shall not be present. See Table 6.3.5 for the contents of this information element.
Result (See 7.6)	Result-Code / Experimental-Result	M	This information element indicates the result of the operation. It shall be mapped to Result-Code AVP for errors defined in the Diameter base protocol (see IETF RFC 6733 [31]). It shall be mapped to Experimental-Result AVP for Cx/Dx errors. This information element is mapped to a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

Table 6.3.5: Authentication Data information element content in Authentication Request Response

Information element name	Mapping to Diameter AVP	Cat.	Description
Item Number (See 7.9.1)	SIP-Item-Number	C	This information element shall only be present for IMS-AKA authentication schemes. This information element shall be present when there are multiple occurrences of the Authentication Data information element in the Authentication Request Response, and the order in which they should be processed is significant. In this scenario, Authentication Data information elements with a low Item Number information element value should be processed before Authentication Data information elements with a high Item Number information element value.
Authentication Scheme (See 7.9.2)	SIP-Authentication-Scheme	M	This information element indicates the authentication scheme.
Authentication Information (See 7.9.3)	SIP-Authenticate	C	This information element shall only be present for IMS-AKA authentication schemes.
Authorization Information (See 7.9.4)	SIP-Authorization	C	This information element shall only be present for IMS-AKA authentication schemes.
Confidentiality Key (See 7.9.5)	Confidentiality-Key	C	This information element shall be present for IMS AKA authentication schemes. It shall contain the confidentiality key.
Integrity Key (See 7.9.6)	Integrity-Key	C	This information element shall only be present for IMS-AKA authentication schemes. This information element shall contain the integrity key.
Digest Authenticate (See 7.9.8)	SIP-Digest-Authenticate	C	This information element shall only be present for SIP Digest authentication scheme. See Table 6.3.7 for contents of this grouped AVP.
Line Identifier (See 7.9.9)	Line-Identifier	C	This information element shall only be present for NASS Bundled authentication scheme. This information element contains fixed broadband access line identifier associated to the user. This information element can be repeated.
Framed IP Address (See 7.9.10)	Framed-IP-Address	C	This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv4 address, this AVP shall be included.
Framed IPv6 Prefix (See 7.9.11)	Framed-IPv6-Prefix	C	This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv6 address, this AVP shall be included.
Framed Interface Id (See 7.9.12)	Framed-Interface-Id	C	This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If and only if the IP Address of the User is an IPv6 address and the Framed-IPv6-Prefix AVP alone is not unique for the user this AVP shall be included.

Table 6.3.6: Void

Table 6.3.7: Digest Authenticate information element content – Response for SIP Digest

Information element name	Mapping to Diameter AVP	Cat.	Description
Digest Realm (See 7.9.8.1)	Digest-Realm	M	This information element corresponds to the Realm parameter as defined in IETF RFC 7616 [33].
Digest Algorithm (See 7.9.8.3)	Digest-Algorithm	O	This information element contains the algorithm as defined in IETF RFC 7616 [33]. If this information element is present, it shall contain "MD5". If neither the Digest Algorithm information element nor the Alternate Digest Algorithm information element are present, then the value "MD5" is assumed. (NOTE 1)
Digest QoP (See 7.9.8.4)	Digest-QoP	M	This information element contains the QoP as defined in IETF RFC 7616 [33]. This information element shall be set to a value of "auth" by the HSS.
Digest HA1 (See 7.9.8.5)	Digest-HA1	M	This information element contains the H(A1) for algorithm "MD5" as defined in IETF RFC 7616 [33]. (NOTE 1)
Alternate Digest Algorithm (See 7.9.8.6)	Alternate-Digest-Algorithm	O	This information element contains the algorithm as defined in IETF RFC 7616 [33]. (NOTE 2)
Alternate Digest HA1 (See 7.9.8.6)	Alternate-Digest-HA1	O	This information element contains the H(A1), as defined in IETF RFC 7616 [33]. (NOTE 2)
NOTE 1: The MD5 algorithm is only supported for backward compatibility and may only be provided within the Digest Algorithm information element. NOTE 2: If the Alternate Digest HA1 information element is present, the Digest HA1 information element shall also be present and the Digest HA1 information element shall contain the MD5 hash. The algorithm of the Alternate Digest HA1 information element shall be determined by the Alternate Digest Algorithm information element.

Table 6.3.8: Void

Table 6.3.9: Void

6.3.1 Detailed behaviour

The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TS 29.229 [5]):

1. Check that the Private User Identity and the Public User Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn’t, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

3. Check whether the Private and Public User Identities in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH.

4. Check the authentication scheme indicated in the request, and

– if it is "Unknown", check the authentication scheme stored in HSS. If it is neither NASS-Bundled authentication nor SIP Digest authentication, Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED.

– if not, check that the authentication scheme indicated in the request is supported. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED.

This step is only applicable for IMS-AKA authentication. If the request indicates there is a synchronization failure, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS:

– If they are identical the HSS shall process AUTS as described in TS 33.203 [3] and return the requested authentication information. The Result-Code shall be set to DIAMETER_SUCCESS.

5. Check the registration status of the Public User Identity received in the request:

– If it is registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS:

– If they are different, the HSS shall overwrite the S-CSCF name. If IMS restoration procedures are supported and the S-CSCF reassignment pending flag is set, the HSS shall reset the flag and keep the S-CSCF restoration information associated with the Public User Identity. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity’s authentication pending flag which is specific to the Private User Identity received in the request. The Result-Code shall be set to DIAMETER_SUCCESS.

– If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) or not registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS:

– If they are different or if there is no S-CSCF name stored in the HSS for any Public User Identity of the IMS subscription, the HSS shall store the S-CSCF name. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity’s authentication pending flag which is specific to the Private User Identity which was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS.

– If they are identical, the HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity’s authentication pending flag which is specific to the Private User Identity that was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS.

Exceptions to the cases specified here shall be treated by HSS as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY. No authentication information shall be returned.

6.4 User identity to HSS resolution

The User identity to HSS resolution mechanism enables the I-CSCF and the S-CSCF to find the identity of the HSS, that holds the subscriber data for a given Public Identity when multiple and separately addressable HSSs have been deployed by the network operator. The resolution mechanism is not required in networks that utilise a single HSS. An example for a single HSS solution is server farm architecture.

The resolution mechanism described in TS 23.228 [1] shall use a Subscription Locator Function (SLF) or a Diameter Proxy Agent.

The I-CSCF and the S-CSCF accesses the SLF via the Dx interface. The Dx interface shall always be used in conjunction with the Cx interface. The Dx interface shall be based on the Diameter base protocol as specified in IETF RFC 6733 [31]. The SLF functionality shall use the routing mechanism provided by an enhanced Diameter redirect agent.

The SLF or the Diameter Proxy Agent shall be able to determine the HSS identity.

To get the HSS identity the I-CSCF and the S-CSCF shall send the Cx request normally destined to the HSS to a pre-configured Diameter address/name.

– If this Cx Request is received by an SLF (acting as a Diameter redirect agent), the SLF shall determine the HSS identity and sends to the I-CSCF or S-CSCF a notification of redirection towards the HSS identity, in response to the Cx request. Multiple HSS identities may be included in the response, as specified in IETF RFC 6733 [31]. In such a case, the I-CSCF or the S-CSCF shall send the Cx Request to the first HSS identity in the ordered list received in the Cx Response from the SLF. If the I-CSCF or S-CSCF does not receive a successful response to the Cx Request, the I-CSCF or S-CSCF shall send a Cx Request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received.

– If this Cx Request is received by the Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and – if the Diameter load control mechanism is supported (see IETF IETF RFC 8583 [29]) – optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Cx request directly to the determined HSS. The I-CSCF and S-CSCF shall determine the HSS identity from the response to the Cx request received from the HSS.

While the I-CSCF is stateless, the S-CSCF shall store the HSS identity/name/Realm, as specified in TS 23.228 [1] and shall use it in further Cx requests associated to the same IMS Public Identity.

In networks where the use of the user identity to HSS resolution mechanism is required, each I-CSCF and S-CSCF shall be configured with the address/name of the SLF or the Diameter Proxy Agent to enable use of these resolution mechanisms.

6.5 Implicit registration

Implicit registration is the mechanism by which a user is allowed to register simultaneously more than one of his/her Public User Identities. The HSS knows the identities that are to be implicitly registered when it receives the indication of the registration of an individual identity.

What follows is an extension of the affected basic procedures.

6.5.1 S-CSCF initiated procedures

The result of the S-CSCF initiated procedures affects all the Public User Identities that are configured in the HSS to be in the same implicitly registered Public User Identity set with the targeted individual Public User Identity. Where the S-CSCF initiated procedure affects the Registration state of the targeted Public User Identity, the Registration states of the Public User Identities in the associated implicitly registered Public User Identity set are affected in the same way.

6.5.1.1 Registration

The notification of a registration of a Public User Identity implies the registration of the corresponding implicitly registered Public User Identity set. The user information downloaded in the response contains the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. This allows the S-CSCF to know which Public User Identities belong to the implicitly registered Public User Identity set. The S-CSCF shall take from the set of implicitly registered Public User Identities the first identity which is not barred, and use this as the default Public User Identity. The default Public User Identity shall be a distinct Public User Identity.

6.5.1.2 De-registration

The de-registration of a Public User Identity implies the de-registration of the corresponding implicitly registered Public User Identity set, both in the HSS and in the S-CSCF. The S-CSCF shall include in the request a single Public User Identity to deregister all the Public User Identities that belong to the corresponding implicitly registered Public User Identity set.

The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF.

6.5.1.3 Authentication

Setting the authentication pending flag for a Public User Identity implies setting the authentication pending flag for each corresponding implicitly registered Public User Identity in the HSS.

6.5.1.4 Downloading the user profile

If the S-CSCF requests to download a user profile from HSS, the user profile in the response shall contain the Public User Identities of the corresponding implicitly registered Public User Identity set with the associated service profiles.

6.5.1.5 Initiation of a session to a non-registered user

The change of a Public User Identity to the Unregistered state due to the initiation of a session from/to a Public Identity that was in Not Registered state and the opposite change from Unregistered state to Not Registered state implies the same change for all the Public User Identities in the same Implicit Registration Set.

6.5.2 HSS initiated procedures

6.5.2.1 Update of User Profile

A request sent by the HSS to update the user profile shall include only the Public User Identities of the implicitly registered Public User Identity set, with the associated service profiles (even if not updated). If other Public User Identities not associated with the implicitly registered Public User Identity set are affected, they shall be downloaded in separate commands.

This procedure shall be used by the HSS to add a newly provisioned or Not Registered Public User Identity or Identities to an existing implicitly registered Public User Identity set that is in the state Registered or Unregistered. The added Public User Identity gets the registration state of the set it is added to.

The HSS shall use this procedure if a Public User Identity or Identities are removed from the implicitly registered Public User Identity set that is in a state Registered or Unregistered. In practise, this is done by sending a PPR for the set without the removed identities. The S-CSCF shall remove all information stored in the S-CSCF for the removed identities.

The HSS shall not use this procedure if there is no Public User Identities left in the implicitly registered Public User Identity set after the removal. In that case HSS shall use the RTR command instead.

The HSS shall not use this procedure to change the default Public User Identity of the implicitly registered Public User Identity set that is in a state Registered. In that case the HSS shall use the RTR command to de-register the Public User Identity set.

When a change of the Reference Location Information occurs (e.g.. a change of authorization), the HSS may use a network initiated de-registration instead of this procedure, and may indicate to the S-CSCF that the de-registration is sent due to change of Reference Location Information.

Moving of a Public User Identity or Identities from one implicitly registered Public User Identity set to another set shall be done in two steps: First the identity or identities are removed from the "old" set as described above, then the identity or identities are added to the "new" set as described above.

6.5.2.2 De-registration

A request sent by the HSS to de-register any of the identities included in an implicitly registered Public User Identity set shall affect all the Public User Identities of the deregistered set.

The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF.

6.5.2.3 Update of the Charging information

A request sent by the HSS to update the charging information shall include the Private User Identity for whom the charging information changed.

If corresponding Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and charging information is changed, the HSS should immediately push this information to the S-CSCF.

6.5.2.4 Update of the SIP Digest Authentication Data

A request sent by the HSS to update the authentication data shall include the Private User Identity for whom the authentication data changed.

If corresponding Public Identity is registered and authentication data is changed, the HSS should immediately push this information to the S-CSCF.

If corresponding Public Identity is either not registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), authentication pending flag is set and authentication data is changed, the HSS should immediately push this information to the S-CSCF.

6.5.2.5 Update of the Allowed WAF and/or WWSF Identities

A request sent by the HSS to update the WAF and/or WWSF identities allowed for the subscription shall include the Private User Identity for whom this information changed.

If corresponding Public Identity is registered and allowed WAF and/or WWSF identities are changed, the HSS should immediately push this information to the S-CSCF.

6.6 Download of the Relevant User Profile and Charging Information and Allowed WAF and/or WWSF Identities

The download of the relevant user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities from the HSS to the S-CSCF depends on whether the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities are already stored in the S-CSCF. If the SiFC feature is supported by the HSS and S-CSCF, the HSS shall download the identifiers of the shared iFC sets. If either the HSS or the S-CSCF does not support the SiFC feature, the HSS shall download the complete iFCs, and SiFC identifiers shall not be downloaded by the HSS. The SiFC feature is defined in TS 29.229 [5].

If User-Data-Already-Available is set to USER_DATA_NOT_AVAILABLE the HSS shall download the requested user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities. If the Public User Identity in the request is included in an implicitly registered Public User Identity set, the HSS shall include in the response the service profiles associated with all Public User Identities within the implicitly registered Public User Identity set to which the received Public User Identity belongs.

If User-Data-Already-Available is set to USER_DATA_ALREADY_AVAILABLE, the HSS should not return any user profile or charging information data or allowed WAF and/or WWSF identities. The HSS may override User-Data-Already-Available set to USER_DATA_ALREADY_AVAILABLE and download the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities.

6.6.1 HSS initiated update of User Profile

The request to update the user profile in the S-CSCF includes only the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. See 6.5.2.1.

If the Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and there are changes in the user profile, the HSS should immediately push the complete user profile to the S-CSCF.

6.6.2 S-CSCF operation

At deregistration of a Public User Identity, the S-CSCF shall store the user information if it sends Server-Assignment-Request command including Server-Assignment-Type AVP set to value USER_DEREGISTRATION_STORE_SERVER_NAME or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME and the HSS responds with DIAMETER_SUCCESS. Otherwise the S-CSCF shall not keep user information.

6.7 S-CSCF Assignment

The list of mandatory and optional capabilities received by an I-CSCF from the HSS allows operators to distribute users between S-CSCFs, depending on the different capabilities (e.g. features, role, geographical location) that each S-CSCF may have. Alternatively, an operator has the possibility to steer users to certain S-CSCFs.

The operator shall define (possibly based on the functionality offered by each S-CSCF installed in the network) the exact meaning of the S-CSCF mandatory and optional capabilities available in his network. It is an operator task to allocate a unique value to represent a single capability (e.g. support of "wildcarded PSI") or a set of capabilities (e.g. support of "alias" and "Shared IFC sets" and "wildcarded PSI") and to use these values to identify capabilities that are mandatory and/or optional to support for a given subscription. It is a configuration task for the operator to ensure that the I-CSCF has a correct record of the capabily values received from the HSS for each S-CSCF available in his network. The I-CSCF and the HSS do not need to know the semantic of these values. This semantic is exclusively an operator issue.

As a first choice, the I-CSCF shall select an S-CSCF that has all the mandatory and optional capabilities for the user. Only if that is not possible shall the I-CSCF apply a ‘best-fit’ algorithm. If more than one S-CSCF is identified that supports all mandatory capabilities the I-CSCF may then consider optional capabilities in selecting a specific S-CSCF. The ‘best-fit’ algorithm is implementation dependent and out of the scope of this specification.

It is the responsibility of the operator to ensure that there are S-CSCFs which have mandatory capabilities indicated by the HSS for any given user. However, configuration errors may occur. If such errors occur and they prevent the I-CSCF from selecting an S-CSCF which meets the mandatory capabilities indicated by the HSS, the I-CSCF shall inform the operator via the O&M subsystem.

As an alternative to selecting an S-CSCF based on the list of capabilities received from the HSS, it is possible to steer users to certain S-CSCFs. To do this, the operator may include one or more S-CSCF names as part of the capabilities of the user profile. The reason for the selection (e.g. all the users belonging to the same company/group could be in the same S-CSCF to implement a VPN service) and the method of selection are operator issues and out of the scope of this specification. If this alternative is chosen, the HSS shall include Server-Name AVPs in the Server-Capabilities AVP and should not include Mandatory-Capability AVPs or Optional-Capability AVPs in the Server-Capabilities AVP, and the I-CSCF when receiving Server-Name AVPs within the Server-Capabilities AVP shall discard any Mandatory-Capability AVP and any Optional-Capability AVP received within the Server-Capabilities AVP.

The following table is a guideline for operators that records S-CSCF capabilities that need to be supported by an S-CSCF in order to serve a user or a service (identified by a Public User Identity or Public Service Identity), that cannot be served by an S-CSCF which is only compliant to a previous 3GPP release.

Table 6.7: Guidelines for S-CSCF Capabilities

Capability	Mandatory or Optional (NOTE 1)	Description
Support of "Wildcarded PSI"	M	This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded PSIs.
Support of "OrigUnreg SPT"	M	This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case "Originating_Unregistered" received from the HSS in the user profile.
Support of "OrigCDIV SPT"	M	This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case "Originating_CDIV" received from the HSS in the user profile.
Support of "Shared iFC sets"	O	This capability indicates that the assigned S-CSCF may support the "SiFC" feature defined in the 3GPP TS 29.229 [5].
Support of "Display Name"	O	This capability indicates that the assigned S-CSCF may support the handling of "Display Name". The behaviour of the S-CSCF related to this missing data is the same as if the HSS did not send the Display Name.
Support of "Alias"	O	This capability indicates that the assigned S-CSCF may support the "AliasInd" feature defined in 3GPP TS 29.229 [5].
Support of "SIP Digest Authentication"	M	This capability indicates that the assigned S-CSCF shall support the handling of SIP Digest Authentication.
Support of "NASS Bundled Authentication"	M	This capability indicates that the assigned S-CSCF shall support the handling of NASS Bundled Authentication.
Support of "Wildcarded IMPUs"	M	This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded Public User Identities.
Support of "Loose-Route "	M	This capability indicates that the assigned S-CSCF shall support the loose-route mechanism.
Support of "Service Level Trace"	M	This capability indicates that the assigned S-CSCF shall support the Service Level Trace mechanism.
Support of "Priority Service"	M	This capability indicates that the S-CSCF shall support a network default pre-configured namespace (e.g. "wps") and the associated Service Priority Level. See IETF RFC 4412 [22] and 3GPP TS 24.229 [8].
Support of "Extended Priority " (NOTE 2)	M	This capability indicates that the S-CSCF shall support the Priority Namespaces and their associated Priority Levels. See IETF RFC 4412 [22] and 3GPP TS 24.229 [8].
Support of "Early IMS Security"	M	This capability indicates that the assigned S-CSCF shall support GIBA.
Support of "Reference Location"	M	This capability indicates that the assigned S-CSCF shall support the handling of reference location as defined in 3GPP TS 23.167 [23].
Support of "Priviledged-Sender"	M	This capability indicates that the S-CSCF shall support priviledged sender. See 3GPP TS 24.229 [8].
Support of "IMSI"	M	This capability indicates that the assigned S-CSCF shall support the handling of the IMSI.
Support of "Maximum Number of allowed simultaneous registrations"	M	This capability indicates that the assigned S-CSCF shall support the handling of maximum number of allowed simultaneous registrations per user as received from the HSS.
NOTE 1: Mandatory (M) corresponds to a Mandatory Capability that shall be supported by the assigned S-CSCF for a given user. The I-CSCF shall not select an S-CSCF that does not meet a mandatory capability. The selection of a S-CSCF not supporting this capability would lead to an unspecified network behaviour. Optional (O) corresponds to an Optional Capability that may be supported by the assigned S-CSCF for a given user. The selection of a S-CSCF that would not support this capability will not significantly affect the network behaviour. NOTE 2: Support of "Extended Priority " is backward compatible with continued support of the "Priority Service".