Contents

1   Introduction

The interface between the Call Session Control Function (CSCF) and the Home Subscriber Server/Subscriber Location Function (HSS/SLF) is described using the reference point Cx/Dx interface as described in the 3GPP TS 29.229 Cx and Dx interfaces based on the Diameter Protocol specification.

2   Interface Overview

The interface between the CSCF and the HSS/SLF is shown in Figure 1.

Note:  

The dotted line illustrates the system boundaries.

The Cx/Dx interface is the reference point between the CSCF, meaning the Interrogating CSCF (I-CSCF) and the Serving CSCF (S-CSCF), and the HSS/SLF in the IMS multimedia network.

2.1   Interface Role

All services between the CSCF and the HSS/SLF are described from a CSCF point of view.

2.2   Services

The services offered by the CSCF are shown in Table 1.

The user services offered by the 3GPP® Cx/Dx are shown in Table 2.

The user services offered by the Ericsson proprietary services Cx/Dx are shown in Table 3.

2.3   Encapsulation and Addressing

The CSCF Cx/Dx application protocol is used on top of the Diameter Base Protocol, as described in the RFC 3588 Diameter Base Protocol specification.

The CSCF supports Diameter over SCTP and TCP.

The Attribute-Value Pair (AVP) Length indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field, if present, and the AVP data.

The DiameterIdentity format is derived from the OctetString AVP Base Format, as follows:

• DiameterIdentity = FQDN

The DiameterURI must follow the Uniform Resource Identifiers (URI) syntax, as follows:

• "aaa://" FQDN [ port ] [ transport ] [ protocol ]

3   Procedures

The 3GPP Diameter procedures are shown in Table 4.

3.1   Lower-Level Procedures

3.1.1   HSS Selection

There can be one or several HSS nodes in the network where the following apply:

• Where there is only one HSS in the network, the CSCF uses a "static" HSS configuration parameter CscfCXDestinationHost.
• In a network with several HSS nodes, the parameter is set to NotConfigured and the Subscriber Location Function (SLF) node is used to find out which HSS that keeps data for a specific subscriber.

In the SLF case, the CSCF sends the Diameter message on the Dx interface where the Destination-Host AVP is not present. The response from the SLF contains a redirection host in the Redirect-Host AVP and the Result-Code is set to DIAMETER_REDIRECT_INDICATION. The CSCF forwards the same request on the Cx interface, now including the Destination-Host AVP received in the Redirect-Host AVP from the SLF.

3.1.1.1   Successful HSS Selection

A successful HSS selection procedure is shown in Figure 2.

The procedure is as follows:

3.1.1.2   Unsuccessful HSS Selection – User Not Found

An unsuccessful HSS selection procedure, where the user is not found, is shown in Figure 3.

The procedure is as follows:

3.1.1.3   Unsuccessful HSS Selection – Time-Out to SLF

An unsuccessful HSS selection process, where there is a time-out to the SLF, is shown in Figure 4.

The procedure is as follows:

3.2   User Registration Status Query

The following procedure is used by the I-CSCF to the HSS during SIP registration:

• Authorize the registration of the Public User Identity, checking access permissions and roaming agreements.
• Perform a first security check, determining whether the Public User Identity in the message is associated with the Private User Identity sent in the message.
• Obtain either the S-CSCF where the Public User Identity is registered or unregistered, or if not registered the list of capabilities that the S-CSCF has to support.

  The list of capabilities can be empty allowing the I-CSCF to select any available S-CSCF.

The I-CSCF requests the authorization of the registration of the user by the User-Authorization-Request (UAR) command.

The CSCF provides the Public and Private User Identities and the visited network identity to the HSS.

The HSS uses registration information provided by the I-CSCF to authorize the user, based on internal information and on roaming agreements with the visited network.

If the user is registered or unregistered, the HSS returns a stored S-CSCF name.

If the user is not registered, the HSS can return S-CSCF capabilities (mandatory and optional S-CSCF capabilities, or both) that are used for the selection of an S-CSCF by the I-CSCF. The S-CSCF capabilities can also include a list of preconfigured S-CSCF names to be used for the initial registration. If no S-CSCF capabilities are returned, it is up to the I-CSCF to select a suitable S-CSCF.

3.2.1   Use Cases – User Registration

3.2.1.1   Successful UAR – Initial Registration

A successful UAR with initial registration is shown in Figure 5.

The procedure is as follows:

3.2.1.2   Successful UAR – Subsequent Registration

A successful UAR with subsequent registration is shown in Figure 6.

The procedure is as follows:

3.2.1.3   Successful UAR – Deregistration

A successful UAR with deregistration is shown in Figure 7.

The procedure is as follows:

3.2.1.4   Request for Capabilities in Case of Reselection of S-CSCF

A request for capabilities, in case of reselection of an S-CSCF, is shown in Figure 8.

The procedure is as follows:

3.3   User Location Query

This procedure is used by the I-CSCF to the HSS to obtain the following:

• The name of the S-CSCF assigned to a Public Identity
• The server capabilities to help the I-CSCF in the selection of the S-CSCF
• The name of the AS hosting a PSI for direct routing

The I-CSCF requests S-CSCF location information by the Location Information Request (LIR) command.

The I-CSCF provides the Public User Identity to the HSS. The Experimental-Result-Code DIAMETER_ERROR_USER_UNKNOWN is returned if the user is unknown, otherwise depending on the state of the user, the following answers can be provided:

The I-CSCF supports the 3GPP Standardized Restoration Procedure; it always indicates the support of the feature by setting the IMSRestorationInd bit in the Supported-Features AVP of the LIR command. If the I-CSCF sends an LIR with UAT equals to REGISTRATION_AND_CAPABILITIES and sets the IMSRestorationInd bit of the Supported-Features AVP, the HSS allows the S-CSCF name of the user to be updated in the next Server-Assignment-Request (SAR) message.

3.3.1   Use Cases – User Location

3.3.1.1   Successful User Location Query – Public Identity Registered or Unregistered

A successful user location query with public identity that is registered or unregistered is shown in Figure 9.

The procedure is as follows:

Note:  

If the HSS matches the IP Multimedia Public Identity (IMPU) to a wildcarded public identity, the Location Information Answer (LIA) message includes a Wildcarded-Public-Identity AVP.

3.3.1.2   Successful User Location Query – Public Identity Registered or Unregistered, Server Capabilities Are Requested

A successful user location query with public identity that is registered or unregistered, and where server capabilities are requested, is shown in Figure 10.

The procedure is as follows:

Note:  

If the HSS matches the IMPU to a wildcarded public identity, the LIA message includes a Wildcarded-Public-Identity AVP.

3.3.1.3   Successful User Location Query – Public Identity Not Registered but Has Unregistered Services

A successful user location query with public identity that is not registered but has unregistered services is shown in Figure 11.

The procedure is as follows:

Note:  

If the HSS matches the IMPU to a wildcarded public identity, the LIA message includes a Wildcarded-Public-Identity AVP.

3.3.1.4   Unsuccessful User Location Query – Public Identity Not Registered and Has No Unregistered Services

An unsuccessful user location query with public identity that is not registered and has no unregistered services is shown in Figure 12 .

The procedure is as follows:

3.3.1.5   Successful User Location Query – Originating Request

A successful user location query with originating request is shown in Figure 13.

The procedure is as follows:

Note:  

If the HSS matches the IMPU to a wildcarded public identity, the LIA message includes a Wildcarded-Public-Identity AVP.

3.3.1.6   Unsuccessful User Location Query – Originating Request

An unsuccessful user location query with originating request is shown in Figure 14.

The procedure is as follows:

3.4   Server-Assignment-Request

This procedure is used by the S-CSCF to the HSS to perform the following:

• Assign an S-CSCF to a Public Identity or clear the name of the S-CSCF assigned to one or several Public Identities.
• Download the user profile and the Charging information from the HSS.
• Store and retrieve restoration information with or without subscription information of a user if the restoration procedure is supported and enabled in the S-CSCF and the HSS.
• Trigger the P-CSCF restoration procedure for a user whose registered P-CSCF is not functioning.

The S-CSCF requests the Registration/Deregistration Notification, User profile download, restoration information upload and download, and triggering of P-CSCF restoration procedure by the SAR command.

In an Initial Registration, the S-CSCF updates the specified user in the HSS with the S-CSCF name and the restoration information, and requests the user data and Charging information from the HSS by sending the SAR. The main data is the S-CSCF server name, the username, the Public User Identity, and an indication that the update concerns setting the S-CSCF name, Server-Assignment-Type = REGISTRATION. In addition, if the restoration procedure is enabled in the S-CSCF, the S-CSCF includes the restoration information, Multiple-Registration-Indication AVP, and Supported-Feature AVP with IMSRestorationInd bit set in the SAR message.

When a Server-Assignment-Answer (SAA) is received, the S-CSCF checks that the operation is successful, as follows:

• If it is successful, the S-CSCF stores the Private User Identity and the Public User Identity. In case the requested Public User Identity belongs to an Implicit Registration Set, several Public User Identities are received. The CSCF stores user data and Charging information for each IMPU. If restoration procedure is enabled in both S-CSCF and HSS, HSS can for Server-Assignment-Types REGISTRATION and RE_REGISTRATION indicate that 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. For the REGISTRATION case, the S-CSCF sends another SAR with SAT NO_ASSIGNMENT to fetch restoration data for all IMPIs associated with this IRS. S-CSCF does not need to send a second SAR in the RE_REGISTRATION case. If the restoration procedure is enabled in the S-CSCF and the Server-Assignment-Answer indicates that the HSS does not support the restoration procedure, the S-CSCF stops updating the restoration information of the user in the same registration session. If the Loose-Route-Indication AVP is received for a registered Public Identity, it is stored by the S-CSCF.
• If it is unsuccessful and the restoration procedure is disabled, the S-CSCF maps the answer to a SIP response code and rejects the registration.
• If it is unsuccessful and the response code is ERROR_IN_ASSIGNMENT_TYPE and the restoration procedure is enabled, the S-CSCF restores all user information according to the restoration information received and sends another Server-Assignment-Request message with updated restoration information and the USER_DATA_ALREADY_AVAILABLE AVP to the HSS with Server-Assignment-Type set to RE_REGISTRATION.
• If no response is received from the HSS within Diameter time-out period, the registration is rejected.

If Deregistration (user, time-out or administrative deregistration), the S-CSCF sends the SAR requesting the HSS to clear the S-CSCF for a specified user. User profile or Charging information is not downloaded. If the Deregistration is triggered by the user or the S-CSCF and if restoration procedure is enabled, the S-CSCF includes the updated restoration information in the Server-Assignment-Request.

The CSCF supports the 3GPP Standardized Restoration Procedure; if the Restoration Procedure is enabled, the S-CSCF always indicates the support of the feature by setting the IMSRestorationInd bit in the Supported-Features AVP of the SAR command. The CSCF also supports the 3GPP Shared Initial Filter Criteria (SiFC) feature; if the SiFC is enabled, the S-CSCF always indicates the support of the feature by setting the SiFC bit in the Supported-Features AVP of the SAR command. The Restoration Procedure and SiFC handling proceeds according to the returned Server-Assignment-Answer (SAA).

If terminating an INVITE, NOTIFY, UPDATE, or MESSAGE request to a registered user whose P-CSCF is not functioning, and if the P-CSCF restoration procedure is enabled, the S-CSCF sends a SAR to the HSS to trigger P-CSCF restoration. The SAR includes the SAR-Flags AVP with bit 0 set and the Supported-Features AVP with the third bit set to indicate the support of the P-CSCF restoration procedure.

If terminating call to an unregistered user, the S-CSCF sends a SAR to the HSS to store the S-CSCF name and request the user profile. If the restoration procedure is enabled in the S-CSCF, restoration information is requested as well.

If terminating call to a not registered Wildcarded Public Service Identity, the S-CSCF sends an SAR with Server-Assignment-Type = UNREGISTERED_USER to the HSS and includes the Wildcarded Public Service Identity, extracted from the received P-Profile-Key header, in the Wildcarded-Public-Identity AVP.

If originating call to an unregistered Wildcarded Public User Identity, the S-CSCF sends an SAR with Server-Assignment-Type = UNREGISTERED_USER to the HSS and includes the Wildcarded Public User Identity, extracted from the received P-Profile-Key header, in the Wildcarded-Public-Identity AVP.

If S-CSCF Network Initiated Deregistration, with Server-Assignment-Type = TIMEOUT_DEREGISTRATION, for a Wildcarded Public Service Identity, the S-CSCF includes the Wildcarded Public Service Identity in the Server-Assignment-Request, in the Wildcarded-Public-Identity AVP.

If S-CSCF Network Initiated Deregistration, with Server-Assignment-Type = TIMEOUT_DEREGISTRATION, for a Wildcarded Public User Identity, the S-CSCF includes the default Public User Identity from the Implicit Registration Set (IRS) in the Server-Assignment-Request, in the Public-Identity AVP, if it is a Public Identity. If the default Public User Identity is a Wildcarded Public User Identity, the S-CSCF includes it in the Wildcarded-Public-Identity AVP.

If initial registration of the emergency contact, and there are no other contacts registered, the S-CSCF sends an SAR with Server-Assignment-Type = NO_ASSIGNMENT.

If there is a registration of a regular, non-emergency, contact and there is already an emergency contact, the S-CSCF sends an SAR with Server-Assignment-Type = REGISTRATION.

If there is a deregistration of a regular contact and only the emergency contact remains registered, the S-CSCF sends an SAR Server-Assignment-Type = USER_DEREGISTRATION_STORE_SERVER_NAME.

When the regular contact has expired its registration period and only the emergency contact remains, the S-CSCF is to send an SAR with Server-Assignment-Type = TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME.

When the last contact which is an emergency contact expires, SAR with Server-Assignment-Type = TIMEOUT_DEREGISTRATION.

When an originating RegEvent subscription request is received from a contact of a registered user and if the restoration with subscription information procedure is enabled, the S-CSCF sends SAR to HSS with Server-Assignment-Type = RE_REGISTRATION and User-Data-Already-Available = USER_DATA_ALREADY_AVAILABLE to update the subscription information of the contact restoration information.

3.4.1   Use Cases – Registration, Deregistration, Downloading User Profile, and Restoration Procedures

3.4.1.1   Successful Initial Registration

A successful initial registration is shown in Figure 15.

The procedure is as follows:

3.4.1.2   Successful Deregistration Notification Request – No User Profile Download

A successful deregistration notification request with no user profile download is shown in Figure 16.

The procedure is as follows:

3.4.1.3   Registration Time-out

A registration time-out is shown in Figure 17.

The procedure is as follows:

Note:  

When the CSCF administrative state is changed to locked and there exist registered users in the CSCF, then the CSCF initiates deregistration for these users and sets the Server-Assignment-Type to TIMEOUT_DEREGISTRATION.

3.4.1.4   Administrative Deregistration

An administrative deregistration is shown in Figure 18.

The procedure is as follows:

Note:  

At internal S-CSCF failure, following a successful Server-Assignment-Request (SAA) response, the CSCF performs administrative deregistration by initiating deregistration for that user and setting the Server-Assignment-Type to ADMINISTRATIVE_DEREGISTRATION.

When the CSCF administrative state is changed to locked and there exist registered users in the CSCF, then the CSCF initiates deregistration for these users and sets the Server-Assignment-Type to TIMEOUT_DEREGISTRATION.

When a user is deregistered by an administrator in the S-CSCF through shortening the remaining registration time to 0, that is, to set the time element of ScscfShortenUserRegistrationTime to 0, the S-CSCF initiates deregistration for this user and sets the Server-Assignment-Type to ADMINISTRATIVE_DEREGISTRATION.

3.4.1.5   Successful Call – User Not Registered in S-CSCF and HSS, User Profile Download

A successful call where the user is not registered in the S-CSCF and the HSS, and the user profile is downloaded is shown in Figure 19.

The procedure is as follows:

3.4.1.6   Successful Call – User Not Registered in S-CSCF but Registered in HSS, Restoration Information, and User Profile Download

A successful call where the user is not registered in the S-CSCF but registered in the HSS and the restoration information and user profile are downloaded, is shown in Figure 20.

The procedure is as follows:

3.4.1.7   Successful Registration Notification Request – User in Unregistered State

A successful registration notification request where the user is in unregistered state is shown in Figure 21.

The procedure is as follows:

3.4.1.8   Unsuccessful Registration Notification Request

An unsuccessful registration notification request is shown in Figure 22.

The procedure is as follows:

3.4.1.9   Successful Registration Notification – Answer Rejected

A successful registration notification with an answer rejected is shown in Figure 23.

The procedure is as follows:

3.4.1.10   Successful Request of User Data

A successful request of the user data from the HSS is shown in Figure 24.

The procedure is as follows:

3.4.1.11   Successful Registration Time-out Notification with Request to Store Server Name

A registration time-out and the S-CSCF request to the HSS to deregister the user but to keep the server name is shown in Figure 25.

The procedure is as follows:

3.4.1.12   Successful Deregistration Notification with Request to Store Server Name

A successful deregistration notification request to deregister the user but keep the server name is shown in Figure 26.

The procedure is as follows:

3.4.1.13   Successful Triggering of P-CSCF Restoration Procedure for an IMPU Registered with One IMPI

Successful triggering of the P-CSCF Restoration Procedure for an IPMU that is registered with one IMS Private Identity (IMPI) is shown in Figure 27.

The procedure is as follows:

3.4.1.14   Successful Triggering of P-CSCF Restoration Procedure for an IMPU Registered with Multiple IMPIs

Successful triggering of the P-CSCF Restoration Procedure for an IMPU that is registered with multiple IMPIs is shown in Figure 28.

The procedure is as follows:

3.4.1.15   Successful RegEvent Subscription Request – No User Profile Download

A successful RegEvent subscription is shown in Figure 29.

The procedure is as follows:

3.5   Authentication Request

This procedure is used by the S-CSCF to the HSS, for the following:

• AKA authentication; retrieve Authentication Vectors (AVs) from the HSS.
• AKA authentication; resolve synchronization failures between the sequence numbers in UE and the HSS.
• NASS Bundled Authentication retrieves the Line Identifiers or an indication that the Line Profile verification has successfully been performed in the HSS.
• Digest Authentication; retrieve AVs from the HSS.
• GPRS IMS Bundled Authentication (GIBA) authentication, retrieve UE IP address from the HSS.

The S-CSCF requests the Authentication Request by the Multimedia-Authentication-Request (MAR) command.

When the S-CSCF has determined that the IMS AKA authentication applies, it sends an MAR to the HSS requesting the AV. The request identifies the user by both private and Public User Identities and specifies that the AVs are desired and the SIP-Authentication-Scheme AVP set to Digest-AKAv1-MD5.

When MAA with Result-Code DIAMETER_SUCCESS is received, the S-CSCF extracts the RAND, AUTN, XRES, IK, and CK from the AV and includes it in a challenge to the UE.

When the S-CSCF has determined that the NASS Bundled Authentication applies, it sends an MAR to the HSS requesting the Line Identifiers for NASS-Bundled. The request includes the private and Public User Identities and the SIP-Authentication-Scheme AVP is set to NASS-Bundled. The private user identity is sent by the UE or if not, the S-CSCF derives it from the To header of the SIP REGISTER request.

The S-CSCF receives the Multimedia-Authentication-Answer (MAA) with Result-Code DIAMETER_SUCCESS and one or several Line-Identifier AVPs. The SIP-Authentication-Scheme AVP is set to NASS-Bundled. The S-CSCF compares the string in the Line-Identifier AVPs with the string in the dsl-location parameter in the PAccess-Network-Id header. If there is a match, the authentication is successful and the S-CSCF continues to process the request.

When the S-CSCF has determined that Digest Authentication applies, it sends an MAR to the HSS with the SIP-Authentication-Scheme AVP set to SIP Digest. The request identifies the user by both private and Public User Identities and specifies that the AVs are desired. The private user identity is either sent by the UE or if not, the S-CSCF derives it from the To header of the SIP REGISTER request.

When the MAA with Result-Code DIAMETER_SUCCESS is received, the S-CSCF extracts the SIP Digest Authentication data (Digest-Realm, Digest-Algorithm, Digest-QoP, Digest-HA1, and optionally Secondary-Digest-HA1) from the response and uses the information to challenge the UE.

When the S-CSCF has determined that GIBA authentication applies, it sends an MAR to the HSS with the SIP-Authentication-Scheme AVP set to Early-IMS-Security. The request identifies the user by both private and Public User Identities and specifies that one authentication item, the UE IP address, is desired. The private user identity is not sent by the UE but the S-CSCF derives it from the SIP REGISTER request To header.

When the MAA with Result-Code DIAMETER_SUCCESS and SIP-Authentication-Scheme Early-IMS-Security is received, the S-CSCF extracts the UE IP address from the response and uses the information to compare to the UE IP address received in the REGISTER request.

When the S-CSCF has determined that NASS Bundled Authentication and Digest both can apply, it sends an MAR to the HSS with the SIP-Authentication-Scheme AVP set to Unknown. The request identifies the user by both the private and Public User Identities. The private user identity is either sent by the UE or if not, the S-CSCF derives it from the To header of the SIP REGISTER request.

The S-CSCF receives the MAA with Result-Code DIAMETER_SUCCESS and the SIP-Authentication-Scheme AVP is set to NASSBundled or SIP Digest. If set to SIP Digest, the regular SIP digest procedures are executed. If set to NASS-Bundled, the S-CSCF compares the string in the Line-Identifier AVPs with the string in the dsl-location parameter in the P-Access-Network-Id header. If there is a match, the authentication is successful and the S-CSCF continues to process the request. If the Line-Identifier AVP contains the string Line_Profile, no further authentication is performed by the S-CSCF.

When the MAA with an error indication is received or the S-CSCF fails to get any response from the HSS, that is time-out, the SIP request is rejected. In either case, no security information is included in the response.

3.5.1   Use Cases – Authentication Request

3.5.1.1   Successful Authentication Request, AKA

A successful authentication request with AKA, is shown in Figure 30.

The procedure is as follows:

3.5.1.2   Successful Authentication Request, AKA – Synchronization Failure

A successful authentication request with AKA and synchronization failure is shown in Figure 31.

The procedure is as follows:

3.5.1.3   Successful Authentication Request-NASS-Bundled

A successful authentication request with NASS-Bundled is shown in Figure 32.

The procedure is as follows:

3.5.1.4   Unsuccessful Authentication Request – NASS-Bundled Not Supported for User

An unsuccessful authentication request with NASS-Bundled not supported for the user is shown in Figure 33.

The procedure is as follows:

3.5.1.5   Successful Authentication Request – Digest

A successful authentication request with digest is shown in Figure 34.

The procedure is as follows:

3.5.1.6   Unsuccessful Authentication Request – Digest Not Supported for User

An unsuccessful authentication request with digest not supported for the user is shown in Figure 35.

The procedure is as follows:

3.5.1.7   Successful Authentication Request – GIBA

A successful authentication request with GIBA is shown in Figure 36.

The procedure is as follows:

3.5.1.8   Unsuccessful Authentication Request – GIBA Not Supported for User

An unsuccessful authentication request with GIBA not supported for the user is shown in Figure 37.

The procedure is as follows:

3.5.1.9   Successful Authentication Request – Unknown Authentication

A successful authentication request with unknown authentication is shown in Figure 38.

The procedure is as follows:

3.5.1.10   Unsuccessful Authentication Request – Unknown Authentication, No Matching Line Profile for User

An unsuccessful authentication request with unknown authentication and no matching line profile for user is shown in Figure 39.

The procedure is as follows:

3.6   Network Initiated Deregistration

The following procedure is used by the HSS to the S-CSCF to request deregistration of a user, Public Identity, or a list of Public Identities:

• The HSS requests the Network Initiated Deregistration through the Registration Termination Request (RTR) command.

  The RTR contains a Private User Identity and optionally one or several Public User Identities.

• The S-CSCF checks the processor load. If the processor capacity cannot be granted, the S-CSCF returns the Result-Code DIAMETER_TOO_BUSY. Also other initial checks of the Diameter request are performed.
• The S-CSCF checks that the Private User Identity and Public User Identity has the state registered or unregistered in the CSCF. If not, then the Experimental-Result-Code DIAMETER_ERROR_USER_UNKNOWN is returned.

  Where the RTR contains only a Private User Identity, and none of the Public Identities are emergency registered, the Private User Identity is removed from the CSCF database. All Public User Identities or Implicit Registration Sets tied to the Private User Identity are removed unless they are also tied to other Private User Identities.

  Where the RTR contains a Private User Identity and one or more Public User Identities which are not emergency registered, all implicit registrations sets that the Public User Identities belongs to are removed. In case they are associated with other Private User Identities, the Public Identity is only removed for the private identity specified in the request. If a list of Public User Identities is received, each registered Public User Identity is deregistered. An unregistered Public User Identity in the list is ignored.

  The Private User Identity is removed if no more Public User Identities or Implicit Registration Sets are tied to it.

  Where the HSS initiates a deregistration of a Wildcarded Public Identity, the RTR contains the Private identity, User-Name, associated with the Wildcarded Public Identity.

  Where deregistration of a Wildcarded Public User Identity, the RTR can also contain one or more Distinct IMPUs from the IRS.

  If the HSS initiates a permanent deregistration of a Private User Identity with the Reason Code PERMANENT_TERMINATION, where one or a subset of the Public Identities or Implicit Registration Set is emergency registered, the S-CSCF only deregisters the public identities that are not emergency registered.

  Where the RTR results in that Public User Identities or Implicit Registration Sets are removed the following two steps are performed for each removed Public User Identity or Implicit Registration Set, as follows:

  • The S-CSCF releases each multimedia session that was initiated with this Public User Identity or any of the implicitly registered Public User Identities.
  • The S-CSCF removes the Public User Identities, their registration states and their associated service profiles.
• After successful deregistration, the S-CSCF sends a Registration Termination Answer (RTA) with Result-Code = " DIAMETER_SUCCESS" to the HSS.
• If a proper subset of the identities to be deregistered are emergency registered, the S-CSCF sends an RTA with Result-Code = " DIAMETER_LIMITED_SUCCESS". The RTA includes a list of IMPI/IMPU pairs that are emergency registered, and have been requested to be deregistered by the HSS through the RTR. One IMPI/IMPU pair is included in one Identity-with-Emergency-Registration AVP.
• If all identities to be deregistered are emergency registered, the S-CSCF sends an RTA with Result-Code = " DIAMETER_UNABLE_TO_COMPLY".” The RTA includes a list of IMPI/IMPU pairs that are emergency registered and have been requested to be deregistered by the HSS through the RTR. One IMPI/IMPU pair is included in one Identity-with-Emergency-Registration AVP.

3.6.1   Use Cases – Network Initiated Deregistration

3.6.1.1   Successful Network Initiated Deregistration of User

A successful network initiated deregistration of a user is shown in Figure 40.

The procedure is as follows:

3.6.1.2   Successful Network Initiated Deregistration of Public Identity or List of Public Identities

A successful network initiated deregistration of a public identity or a list of public identities is shown in Figure 41.

The procedure is as follows:

3.6.1.3   Successful Network Initiated Deregistration – Public Identity Not Registered

A successful network initiated deregistration with public identity not registered is shown in Figure 42.

The procedure is as follows:

3.6.1.4   Unsuccessful Network Initiated Deregistration, Public Identity Only Emergency Registered

An unsuccessful network initiated deregistration with public identity emergency registered in the CSCF is shown in Figure 43.

The procedure is as follows:

3.6.1.5   Limited Success of Network Initiated Deregistration, Public Identity Registered, and Emergency Registered

A network initiated deregistration with a subset of public identity emergency registered in the CSCF is shown in Figure 44.

The procedure is as follows:

3.7   HSS Initiated User Profile Update

The following procedure is used by the HSS to the S-CSCF to update user profile information, Charging information, and digest authentication information, or all three:

• The HSS requests the S-CSCF to update the relevant user information through the Push-Profile-Request (PPR) command.

  The PPR contains the user profile information, including updating server profiles for IMPUs, adding IMPUs, removing IMPUs, and changing barring states of IMPUs in an IRS, and Charging information.

• The S-CSCF checks the processor load. If the processor capacity cannot be granted, the S-CSCF returns the Result-Code DIAMETER_TOO_BUSY. Also other initial checks of the Diameter request are performed.

  If the request requires support of the SiFC feature and this feature is disabled in the S-CSCF, the Experimental-Result-Code DIAMETER_ERROR_ FEATURE_UNSUPPORTED is returned.

  If an Alias Identity Group is received, the S-CSCF responds with Experimental-Result-Code DIAMETER_ERROR_FEATURE_UNSUPPORTED in the Push-Profile-Answer (PPA) to the HSS.

• The S-CSCF checks if the request contains an Implicit Registration Set, that there is no change of the default IMPU. That means that the first unbarred IMPU is not replaced, or removed, or has changed its barring state. If so, the Experimental-Result-Code DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA is returned.
• If the request contains a new Wildcarded Public User Identity (wIMPU) for an Implicit Registration Set that was not registered for any wIMPU, then the Experimental-Result-Code DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA is returned.
• The S-CSCF checks that the user has the state registered or unregistered in the CSCF. If not, then the Experimental-Result-Code DIAMETER_ERROR_USER_UNKNOWN is returned.

  If the User-Data AVP includes an SiFC identity not defined in the S-CSCF, then the Experimental-Result-Code DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA is returned.

  If the user is registered or unregistered and the User-Data AVP is present in the request, the S-CSCF replaces the current information with the information received from the HSS, for all the Public Identities that are indicated in the User profile that is included in the request.

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

  The SIP-Auth-Data-Item AVP is present if the command is sent to update SIP Digest Authentication information because of a password change.

• After successful update, the S-CSCF responds with a PPA with Result-Code DIAMETER_SUCCESS to the HSS.
• If the S-CSCF receives data that it cannot recognize, unsupported user data or more data than it can accept, it returns the corresponding error code in the Experimental-Result-Code AVP in the PPA to the HSS.

3.7.1   Use Cases – HSS Initiated User Profile Update

3.7.1.1   Successful HSS Initiated User Profile Update

A successful HSS initiated user profile update is shown in Figure 45.

The procedure is as follows:

3.7.1.2   Unsuccessful HSS Initiated User Profile Update – Unsupported Data

An unsuccessful HSS initiated user profile update with unsupported data is shown in Figure 46.

The procedure is as follows:

3.7.1.3   Unsuccessful HSS Initiated User Profile Update – Unsupported Feature

An unsuccessful HSS initiated user profile update with unsupported feature is shown in Figure 47.

The procedure is as follows:

3.7.1.4   Successful HSS Initiated User Profile Update 2

A successful HSS initiated user profile update is shown in Figure 48.

The procedure is as follows:

4   Information Model

The command codes for the Cx/Dx interface application are taken from the range allocated by IANA®. For these commands, the Application-ID field is set to 16777216, the application identifier of the Cx/Dx interface application, allocated by IANA.

The Command Codes are defined in Table 5.

The presence of an information element, as defined in the P column, is defined as follows:

• M = Mandatory
• C = Conditional (Mandatory under certain circumstances)
• O = Optional

The following symbols are used in the Message Format:

• < AVP > indicates a mandatory AVP with a fixed position in the message.
• { AVP } indicates a mandatory AVP in the message.
• [ AVP ] indicates an optional AVP in the message.
• * AVP indicates that multiple occurrences of an AVP are possible.

The symbols are according to the RFC 3588 Diameter Base Protocol specification.

4.1   Supported Diameter Cx/Dx Commands

4.1.1   UAR

The User-Authorization-Request (UAR) command, indicated by the Command-Code field set to 300 and the "R" bit set in the Command Flags field, is sent by the I-CSCF to the HSS to request the authorization of the registration of a user.

In the command, the I-CSCF includes the information elements shown in Table 6.

The message format for Cx and Dx is as follows:

< User-Authorization-Request > ::= 
            < Diameter Header: 300, REQ, PXY, 16777216 >
  < Session-Id >
  { Vendor-Specific-Application-Id } 
  { Auth-Session-State } 
  { Origin-Host } 
  { Origin-Realm } 
  [ Destination-Host ] 
  { Destination-Realm } 
  { User-Name } 
  { Public-Identity } 
  { Visited-Network-Identifier } 
  [ User-Authorization-Type ] 
  [ Access-Network-Information ]
* [ Supported-Features ] 
  [ UAR-Flags ]

4.1.2   User-Authorization-Answer

The User-Authorization-Answer (UAA) command, indicated by the Command-Code field set to 300 and the "R" bit cleared in the Command Flags field, is sent by an HSS in response to the User-Authorization-Request (UAR) command.

The HSS returns the parameters shown in Table 7.

The message format for Cx is as follows:

< User-Authorization-Answer > ::= 
               < Diameter Header: 300, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
* [ Supported-Features ]
 [ Server-Name ]
 [ Server-Capabilities ]
* [ Failed-AVP ]
* [ AVP ]
[ 3GPP-SGSN-MCC-MNC ]
[ GPRS-Roaming-Status ]

Either the Server-Name AVP or the Server-Capabilities AVP can be present in the message, but not in both of them.

If both the Server-Name AVP and the Server-Capabilities AVP are not present, the I-CSCF can select any available S-CSCF.

The Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

The SLF returns the parameters shown in Table 8.

The message format for Dx is as follows:

< User-Authorization-Answer > ::= 
               < Diameter Header: 300, PXY, 16777216 >
< Session-Id >
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]

4.1.2.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 9.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in successful cases takes one of the values shown in Table 10.

4.1.2.2   Error Cases

The Result-Code AVP takes one of the values shown in Table 11.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in error cases takes one of the values shown in Table 12.

4.1.3   Location-Info-Request

The LIR command, indicated by the Command-Code field set to 302 and the "R" bit set in the Command Flags field, is sent by the I-CSCF to the HSS to request the authorization of the registration of a user.

The I-CSCF includes the information elements in the command as shown in Table 13.

The message format for Cx and Dx is as follows:

< Location-Info-Request > ::= 
            < Diameter Header: 302, REQ, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Destination-Host ]
 { Destination-Realm }
 { Originating-Request }
 { Public-Identity }
 [ User-Authorization-Type ]
 [ Session-Priority ]
*[ Supported-Features ]

4.1.4   Location-Info-Answer

The LIA command, indicated by the Command-Code field set to 302 and the "R" bit cleared in the Command Flags field, is sent by an HSS in response to the LIR command.

The HSS returns the information elements in the command as shown in Table 14.

The message format for Cx is as follows:

< Location-Info-Answer > ::= 
               < Diameter Header: 302, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
* [ Supported-Features ]
 [ Server-Name ]
 [ Server-Capabilities ]
 [ Wildcarded-Public-Identity ]
* [ Failed-AVP ]
* [ AVP ]

Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

Either the Server-Name AVP or Server-Capabilities AVP can be present in the message, but not in both of them.

The Server-Capabilities AVP can be absent to indicate to the I-CSCF that it can select any available S-CSCF.

Note:  

According to 3GPP TS29.228 v8.8.0/v.9.3.0 or later releases, TS29.229 v8.9.0/v.9.3.0 or later releases, the Wildcarded-IMPU AVP (code 636) has been deprecated, to cope with a vendor who has implemented its Cx interface according to the old release before the previously stated releases, when the Wildcarded-IMPU AVP (code 636) is received from HSS in LIA message, it is processed by I-CSCF in the same way as if the Wildcarded-Public-Identity AVP (code 634) is received.

SLF returns the information elements in the command as shown in Table 15.

The message format for Dx is as follows:

< Location-Info-Answer > ::= 
               < Diameter Header: 302, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Redirect-Host ]
 [ Redirect-Host-Usage ]
 [ Redirect-Max-Cache-Time ]

4.1.4.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 16.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in successful cases takes one of the values shown in Table 17.

4.1.4.2   Error Cases

The Result-Code AVP takes one of the values shown in Table 18.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in error cases takes one of the values shown in Table 19.

4.1.5   Server-Assignment-Request

The SAR command, indicated by the Command-Code field set to 301 and the "R" bit set in the Command Flags field, is sent by the S-CSCF to the HSS to request it to store or remove the name of the server that is serving the user and request download of the user profile.

The S-CSCF includes the information elements in the command as shown in Table 20.

The message format for Cx/Dx is as follows:

<Server-Assignment-Request > ::= 
            < Diameter Header: 301, REQ, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Destination-Host ]
 { Destination-Realm }
*[ Supported-Features ]
 [ User-Name ]
* [ Public-Identity ]
 [ Wildcarded-Public-Identity ]
 { Server-Name }
 { Server-Assignment-Type }
 [ Multiple-Registration-Indication ]
 [ SCSCF-Restoration-Info ]
 [ Session-Priority ]
 { User-Data-Already-Available }
* [ Activity-Information ]
 [ SAR-Flags ]

4.1.6   Server-Assignment-Answer

The SAA command, indicated by the Command-Code field set to 301 and the "R" bit cleared in the Command Flags field, is sent by an HSS in response to the SAR command.

The HSS returns the information elements in the command as shown in Table 21.

The message format for Cx is as follows:

< Server-Assignment-Answer > ::= 
               < Diameter Header: 301, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ User-Name ]
* [ Supported-Features ]
 [ User-Data ]
 [ Charging-Information ]
 [ Associated-Identities ]
 [ Loose-Route-Indication ]
* [ Failed-AVP ]
* [ SCSCF-Restoration-Info ]
 [ Associated-Registered-Identities ]
* [ AVP ]

Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

The SLF returns the information elements in the command as shown in Table 22.

The message format for Dx is as follows:

< Server-Assignment-Answer > ::= 
               < Diameter Header: 301, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Redirect-Host ]
 [ Redirect-Host-Usage ]
 [ Redirect-Max-Cache-Time ]

4.1.6.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 23.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in successful cases takes one of the values shown in Table 24.

4.1.6.2   Error Cases

The Result-Code AVP takes one of the values shown in Table 25.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in error cases takes one of the values shown in Table 26.

4.1.7   Multimedia-Auth-Request

The MAR command, indicated by the Command-Code field set to 303 and the "R" bit set in the Command Flags field, is sent by the S-CSCF to the HSS to request the security information.

The S-CSCF includes the information elements in the command as shown in Table 27.

Authentication Data included in the SIP-Auth-Data-Item AVP sent in the request is shown in Table 28.

Authentication Data included in the SIP-Auth-Data-Item AVP sent in the request when Synchronization Failure is shown in Table 29.

The message format for Cx/Dx is as follows:

< Multimedia-Auth-Request > ::= 
            < Diameter Header: 303, REQ, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Destination-Host ]
 { Destination-Realm }
 { User-Name }
 { Public-Identity }
 { SIP-Auth-Data-Item ]
 { SIP-Number-Auth-Items }
 { Server-Name }

4.1.8   Multimedia-Auth-Answer

The MAA command, indicated by the Command-Code field set to 303 and the "R" bit cleared in the Command Flags field, is sent by an HSS in response to the MAR command.

The HSS returns the information elements in the command as shown in Table 30.

Authentication Data included in the SIP-Auth-Data-Item AVP received in the response for AKA Authentication is shown in Table 31.

Authentication Data included in the SIP-Auth-Data-Item AVP received in the response for NASS Bundled Authentication is shown in Table 32.

Authentication Data included in the SIP-Auth-Data-Item AVP received in the response for SIP Digest Authentication is shown in Table 33.

Authentication Data included in the SIP-Auth-Data-Item AVP received in the response for GIBA is shown in Table 34.

SIP-Digest-Authenticate content is shown in Table 35.

The message format for Cx is as follows:

< Multimedia-Auth-Answer > ::= 
               < Diameter Header: 303, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ User-Name ]
 [ Public-Identity ]
 [ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
* [ Supported-Features ]
* [ Failed-AVP ]
* [ AVP ]

Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

The SLF returns the information elements in the command as shown in Table 36.

The message format for Dx is as follows:

< Multimedia-Auth-Answer > ::= 
               < Diameter Header: 303, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 [ Redirect-Host ]
 [ Redirect-Host-Usage ]
 [ Redirect-Max-Cache-Time ]

4.1.8.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 37.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

4.1.8.2   Error Cases

The Result-Code AVP takes one of the values shown in Table 38.

(1)  The SLF replies the corresponding answer message with the "E" bit set.

The Experimental-Result AVP in error cases takes one of the values shown in Table 39.

4.1.9   Registration-Termination-Request

The RTR command, indicated by the Command-Code field set to 304 and the "R" bit set in the Command Flags field, is sent by the HSS to the S-CSCF to request network initiated deregistration.

The HSS includes the information elements in the command as shown in Table 40.

Deregistration reason includes the Reason Code AVP that can have the following values:

• PERMANENT_TERMINATION:

  The IMS subscription or service profiles has been permanently terminated. It is used when a user or a Public Identity is deleted.

• NEW_SERVER_ASSIGNED:

  A new S-CSCF has been allocated to the user, replacing the previously assigned S-CSCF. This deregistration reason is sent for the Public Identity in the SAR where the new S-CSCF name is received and for the Public User Identities belonging to the same Implicit Registration Set.

• SERVER_CHANGE:

  It is indicated for the rest of Public User Identities of a user for which a new S-CSCF has been assigned. It is also used when the user or service S-CSCF capabilities are changed in the HSS or when the S-CSCF indicates that it has not enough memory for an updated User Profile upon execution PPR.

• REMOVE_S-CSCF:

  The HSS indicates to the S-CSCF that the S-CSCF is no longer to be used for a given user. It is used in cases of operator initiated user/Public Identity deregistration, when a user or subscriber is barred for registration, when a Public Identity that does not belong to an Implicit Registration Set is barred and when a user is locked because of several authentication failures.

All the Public Identities in an RTR command must belong to the same private identity.

If deregistration of a registered/unregistered Public Identity in an Implicit Registration Set, one or several Public User Identities in the Implicit Registration Set are included in the message.

The message format is as follows:

< Registration-Termination-Request> ::= 
            < Diameter Header: 304, REQ, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 { Destination-Host }
 { Destination-Realm }
 { User-Name }
* [ Public-Identity ]
 { Deregistration-Reason }
 [ Associated-Identities ]
* [ Supported-Features ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]

4.1.10   Registration-Termination-Answer

The RTA command, indicated by the Command-Code field set to 304 and the "R" bit cleared in the Command Flags field, is sent by the S-CSCF in response to the RTR command.

The S-CSCF returns the information elements in the command as shown in Table 41.

The message format is as follows:

< Registration-Termination-Answer> ::= 
               < Diameter Header: 304, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
* [ Failed-AVP ]
* [ Identity-with-Emergency-Registration ]
* [ Activity-Information ]

Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

If the Associated-Identities AVP is received, the S-CSCF ignores the AVP and it is not returned in the RTA.

4.1.10.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 42.

4.1.10.2   Error Cases

The Result-Code AVP in error cases takes one of the values shown in Table 43.

The Experimental-Result AVP in error cases takes one of the values shown in Table 44.

4.1.11   Push-Profile-Request

The PPR command, indicated by the Command-Code field set to 305 and the "R" bit set in the Command Flags field, is sent by the HSS to the S-CSCF to request update of the user profile, or to inform S-CSCF that all GIBA information in the HSS has become invalid.

The HSS includes the information elements in the command as shown in Table 45.

SIP-Auth-Data-Item AVP for Digest Authentication is shown in Table 46.

SIP-Auth-Data-Item for GIBA is shown in Table 47.

User-Name AVP for GPRS IMS Bundled Authentication is shown in Table 48.

The message format is as follows:

< Push-Profile-Request> ::= 
            < Diameter Header: 305, REQ, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
 { Destination-Host }
 { Destination-Realm }
 { User-Name }
 [ User-Data ]
 [ Charging-Information ]
 [ SIP-Auth-Data-Item]
* [ Supported-Features ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]

4.1.12   Push-Profile-Answer

The PPA command, indicated by the Command-Code field set to 305 and the "R" bit cleared in the Command Flags field, is sent by the S-CSCF in response to the PPR command.

The S-CSCF returns the information elements in the command as shown in Table 41.

The message format is as follows:

< Push-Profile-Answer > ::= 
               < Diameter Header: 305, PXY, 16777216 >
 < Session-Id >
 { Vendor-Specific-Application-Id }
 [ Result-Code ]
 [ Experimental-Result ]
 { Auth-Session-State }
 { Origin-Host }
 { Origin-Realm }
* [ Supported-Features ]
* [ Failed-AVP ]

The Result-Code AVP contains results defined in the Diameter Base Protocol and Experimental-Result AVP is used for Cx/Dx results. Only one of them must be present in the message.

4.1.12.1   Successful Cases

The Result-Code AVP takes one of the values shown in Table 50.

4.1.12.2   Error Cases

The Result-Code AVP in error cases takes one of the values shown in Table 43.

The Experimental-Result AVP in error cases takes one of the values shown in Table 52.

5   Formal Syntax

5.1   Diameter Base AVPs

The Diameter Base Protocol AVPs, their AVP Code values, and types are described in tables. The Vendor-ID header is not to be included for these AVPs. These are defined in the RFC 3588 Diameter Base Protocol and RFC 5090 RADIUS Extension for Digest Authentication specifications.

A summary of the attributes is listed in Table 53.

5.1.1   Auth-Application-Id

The Auth-Application-Id AVP attribute, as shown in Table 54, is used to advertise support of the Authentication and Authorization portion of an application.

The Diameter application identifier assigned by IANA to the Cx/Dx interface application is 16777216.

5.1.2   Auth-Session-State

The Auth-Session-State AVP attribute, as shown in Table 55, indicates whether state is maintained for a particular session.

The value is set to NO_STATE_MAINTAINED (1) to indicate that the CSCF does not maintain any state information about this session and that the CSCF does not send any Session-Termination-Request.

5.1.3   Destination-Host

The Destination-Host AVP attribute, as shown in Table 56, is present when the CSCF knows the address/name of the HSS for a certain user.

Example:

neighbour1.remote.example.com

5.1.4   Destination-Realm

The Destination-Realm AVP attribute, as shown in Table 57, contains the realm the message is to be routed to.

Example:

remote.example.com

5.1.5   Digest-Algorithm

The Digest-Algorithm AVP attribute, as shown in Table 58, holds the algorithm parameter that influences the HTTP Digest calculation. If the information element is missing, the value MD5 is assumed. Also if any value other MD5 is specified, the value is ignored and MD5 is used.

The Digest-Algorithm AVP is defined in the RCF 4740 Diameter Session Initiation Protocol (SIP) Application and RFC 5090 RADIUS Extension for Digest Authentication (Feb 2008) specifications.

5.1.6   Digest-HA1

The Digest-HA1 AVP attribute, as shown in Table 59, holds the digested value of the username, authentication realm, and user password.

The Digest-HA1 AVP is defined in the RCF 4740 Diameter Session Initiation Protocol (SIP) Application and RFC 5090 RADIUS Extension for Digest Authentication (Feb 2008) specifications.

5.1.7   Digest-QoP

The Digest-QoP AVP attribute, as shown in Table 60, holds the Quality of Protection parameter that influences the HTTP Digest calculation. The value of "auth" is always assumed.

The Digest-QoP AVP is defined in the RCF 4740 Diameter Session Initiation Protocol (SIP) Application and RFC 5090 RADIUS Extension for Digest Authentication (Feb 2008) specifications.

5.1.8   Digest-Realm

The Digest-Realm AVP, as shown in Table 61, contains a string to be displayed to users so they know which username and password to use. This string contains at least the name of the authenticating host.

Example:

“Welcome to the ims.XYZ.net network, 
please insert your username and password”

The Digest-Realm AVP is defined in the following RCF 4740 Diameter Session Initiation Protocol (SIP) Application and RFC 5090 RADIUS Extension for Digest Authentication (Feb 2008) specifications.

5.1.9   Event-Timestamp

The Event-Timestamp AVP attribute, as shown in Table 62, is of type Time and contains the time at which the reported event occurred. The Time format is derived from the OctetString AVP Base Format. The string must contain four octets, in the same format as the first 4 bytes are in the NTP time stamp format. This represents the number of seconds since 0h on 1 January 1900 regarding the Coordinated Universal Time (UTC).

Example corresponding to 2010-04-20 15.00.00: 3480850800

The Event-Timestamp AVP and the NTP time stamp are defined in the RFC3588 Diameter Base Protocol (Sept 2003) and Section 3 in RFC 2030 Simple Network Time Protocol specifications.

5.1.10   Experimental-Result