Content for TS 23.228 Word version: 19.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

5.2 Application level registration procedures 5.2.0 General 5.2.1 Requirements considered for registration 5.2.1a Implicit Registration 5.2.1a.0 General 5.2.1a.1 Implicit Registration for UE without ISIM or IMC 5.2.2 Registration flows 5.2.2.1 Requirements to consider for registration 5.2.2.2 Assumptions 5.2.2.3 Registration information flow - User not registered 5.2.2.4 Re-Registration information flow - User currently registered 5.2.2.5 Stored information.
...

5.2 Application level registration procedures p. 75

5.2.0 General |R6| p. 75

The following clauses address requirements and information flows related to registration in the IP multimedia subsystem. Assumptions that apply to the various information flows are listed as appropriate.

5.2.1 Requirements considered for registration p. 75

The following points are considered as requirements for the purpose of the registration procedures.

The architecture shall allow for the Serving-CSCFs to have different capabilities or access to different capabilities. E.g. a VPN CSCF or CSCFs in different stages of network upgrade.

The network operator shall not be required to reveal the internal network structure to another network. Association of the node names of the same type of entity and their capabilities and the number of nodes will be kept within an operator's network. However disclosure of the internal architecture shall not be prevented on a per agreement basis.

A network shall not be required to expose the explicit IP addresses of the nodes within the network (excluding firewalls and border gateways).

It is desirable that the UE will use the same registration procedure(s) within its home and visited networks.

It is desirable that the procedures within the network(s) are transparent to the UE, when it registers with the IM CN subsystem.

The Serving-CSCF is able to retrieve a service profile of the user who has IMS subscription. The S-CSCF shall check the registration request against the filter information and if necessary inform Application Servers about the registration of the user; it shall be possible for the filter information to allow either just the initial registrations of the user or also subsequent re-registrations to be communicated to the Application Servers. The Serving-CSCF knows how to reach the Proxy-CSCF currently serving the user who is registered.

The HSS shall support the possibility to bar a Public User Identity from being used for IMS non-registration procedures. The S-CSCF shall enforce these barring rules for IMS. Examples of use for the barring function are as follows:

Currently it is required that at least one Public User Identity shall be stored in the ISIM application or, for UEs supporting only non-3GPP accesses or UEs accessing IMS via SNPN, in the IMC, if IMC is present. If the user/operator wants to prevent this Public User Identity from being used for IMS communications, it shall be possible to do so in the network without affecting the ISIM application or IMC directly.

The HSS shall support the possibility to restrict a user from getting access to IM CN Subsystem from unauthorized visited networks.

It shall be possible to register multiple public identities via single IMS registration procedure from the UE. See clause 5.2.1a for details.

10)

It shall be possible to register a Public User Identity that is simultaneously shared across multiple contact addresses (at the same or via separate UEs) via IMS registration procedures. However, each registration and each de-registration process always relates to a particular contact address and a particular Private User Identity.

The number of allowed simultaneous registrations is defined by home operator policy, e.g. locally configured at the S-CSCF or, when registration is requested via separate UEs, per subscribed value if received from the HSS.

10a)

It shall be possible for the UE to indicate to the network whether the registration adds a new contact to an existing registration from the same UE.

11)

Registration of a Public User Identity shall not affect the status of already registered Public User Identity(s), unless due to requirements by Implicit Registration set defined in clause 5.2.1a.

12)

When multiple UEs share the same public identity (es), each UE shall be able to register its contact address(es) with IMS.

13)

The UE may indicate its capabilities and characteristics in terms of SIP User Agent capabilities and characteristics described in RFC 3840 during IMS registration. The UE may also update its capabilities by initiating a re-registration when the capabilities are changed on the UE.

14)

If a UE supports GRUU, the UE shall indicate its support for GRUUs and obtain a P-GRUU and a T-GRUU for each registered Public User Identity during IMS registration as described in RFC 5627.

15)

The P-CSCF may subscribe to notifications of the status of the IMS Signalling connectivity after successful initial user IMS Registration.

16)

When the access network type information is available from the access network, the P-CSCF shall ensure that the IMS registration request received from the UE to the SIP server (e.g. S-CSCF) contains the correct information. The P-CSCF may subscribe to notification of changes in the type of access network.

17)

The P-CSCF shall cancel any active subscription e.g. to notifications of the status of the IMS Signalling connectivity and/or of the change of access network type when the user is de-Registered from the IM CN subsystem.

18)

When the UE determines that the radio conditions are suitable for IMS PS voice/video services (e.g. UE is in normal coverage or in CE mode A as defined in Annex E, clause E.1.2) then UE may register for IMS voice/video services.

5.2.1a Implicit Registration p. 76

5.2.1a.0 General |R6| p. 76

When an user has a set of Public User Identities defined to be implicitly registered via single IMS registration of one of the Public User Identity's in that set, it is considered to be an Implicit Registration. No single public identity shall be considered as a master to the other Public User Identities. Figure 5.0c shows a simple diagram of implicit registration and Public User Identities. Figure 5.0d shows a similar diagram when multiple Private User Identities are involved. In order to support this function, it is required that:

HSS has the set of Public User Identities that are part of implicit registration.
Cx reference point between S-CSCF and HSS shall support download of all Public User Identities associated with the implicit registration, during registration of any of the single Public User Identities within the set.
All Public User Identities of an Implicit Registration set must be associated to the same Private User Identities. See Figure 5.0d for the detailed relationship between the public and private user entities within an Implicit Registration set.
When one of the Public User Identities within the set is registered, all Public User Identities associated with the implicit registration set are registered at the same time.
When one of the Public User Identities within the set is de-registered, all Public User Identities that have been implicitly registered are de-registered at the same time.
Registration and de-registration always relates to a particular contact address and a particular Private User Identity. A Public User Identity that has been registered (including when implicitly registered) with different contact addresses remains registered in relation to those contact addresses that have not been de-registered.
Public User Identities belonging to an implicit registration set may point to different service profiles; or some of these Public User Identities may point to the same service profile.
When a Public User Identity belongs to an implicit registration set, it cannot be registered or de-registered individually without the Public User Identity being removed from the implicit registration list.
All IMS related registration timers should apply to the set of implicitly registered Public User Identities
S-CSCF, P-CSCF and UE shall be notified of the set of Public User Identities belonging to the implicitly registered function. Session set up shall not be allowed for the implicitly registered Public User Identities until the entities are updated, except for the explicitly registered Public User Identity.
The S-CSCF shall store during registration all the Service profiles corresponding to the Public User Identities being registered.
When a Public User Identity is barred from IMS communications, only the HSS and S-CSCF shall have access to this Public User Identity.

Reproduction of 3GPP TS 23.228, Fig. 5.0c: Relationship of Public User Identities when implicitly registered

Figure 5.0c: Relationship of Public User Identities when implicitly registered

Reproduction of 3GPP TS 23.228, Fig. 5.0d: The relation of two shared Public User Identities (Public-ID-3 and 4) and Private User Identities

Figure 5.0d: The relation of two shared Public User Identities (Public-ID-3 and 4) and Private User Identities

5.2.1a.1 Implicit Registration for UE without ISIM or IMC p. 77

If an UE is registering in the IMS without ISIM or, for UEs supporting only non-3GPP accesses or UEs accessing IMS via SNPN, without IMC, it shall require the network's assistance to register at least one Public User Identity, which is used for session establishment & IMS signalling. Implicit registration shall be used as part of a mandatory function for these ISIM-less or IMC-less UEs to register the Public User Identity(s). In addition to the functions defined in clause 5.2.1a, the following additional functions are required for this scenario.

The Temporary public identity shall be used for initial registration process
It shall be defined in HSS that if the user does not have implicit registration activated then the user shall not be allowed to register in the IMS using the Temporary Public User Identity.

5.2.2 Registration flows p. 78

5.2.2.1 Requirements to consider for registration p. 78

The additional requirement for the registration information flow for this clause is:

A Serving-CSCF is assigned at registration, this does not preclude additional Serving-CSCFs or change of CSCF at a later date. Procedures for use of additional CSCFs are not standardised in this release.

5.2.2.2 Assumptions p. 78

The following are considered as assumptions for the registration procedures as described in clause 5.2.2.3:

IP-CAN bearer is already established for signalling and a mechanism exists for the first REGISTER message to be forwarded to the proxy.
The I-CSCF shall use a mechanism for determining the Serving-CSCF address based on the required capabilities. The I-CSCF obtains the name of the S-CSCF from its role as an S-CSCF selector (Figure 5.1) for the determination and allocation of the Serving-CSCF during registration.
The decision for selecting the S-CSCF for the user in the network is made in the I-CSCF.
A role of the I-CSCF is the S-CSCF selection.

In the information flows described in clause 5.2.2.3 and clause 5.2.2.4, there is a mechanism to resolve a name and address. The text in the information flows indicates when the name-address resolution mechanism is utilised. These flows do not take into account security features such as user authentication. The description of the impact of IMS security features is done in TS 33.203.

5.2.2.3 Registration information flow - User not registered p. 78

The application level registration can be initiated after the registration to the access is performed, and after IP connectivity for the signalling has been gained from the access network. For the purpose of the registration information flows, the user is considered to be always roaming. For user roaming in their home network, the home network shall perform the role of the visited network elements and the home network elements.

Reproduction of 3GPP TS 23.228, Fig. 5.1: Registration - User not registered

Figure 5.1: Registration - User not registered

Step 1.

After the UE has obtained IP connectivity, it can perform the IM registration. To do so, the UE sends the Register information flow to the proxy (Public User Identity, Private User Identity, home network domain name, UE IP address, Instance Identifier, GRUU Support Indication).

Step 2.

Upon receipt of the register information flow, the P-CSCF shall examine the "home domain name" to discover the entry point to the home network (i.e. the I-CSCF). The proxy shall send the Register information flow to the I-CSCF (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address). A name-address resolution mechanism is utilised in order to determine the address of the home network from the home domain name. The P-CSCF network identifier is a string that identifies at the home network, the network where the P-CSCF is located (e.g. the P-CSCF network identifier may be the domain name of the P-CSCF network).

Step 3.

The I-CSCF shall send the Cx-Query/Cx-Select-Pull information flow to the HSS (Public User Identity, Private User Identity, P-CSCF network identifier).

The HSS shall check whether the user is registered already. The HSS shall indicate whether the user is allowed to register in that P-CSCF network (identified by the P-CSCF network identifier) according to the User subscription and operator limitations/restrictions if any.

Step 4.

Cx-Query Resp/Cx-Select-Pull Resp is sent from the HSS to the I-CSCF. It shall contain the S-CSCF name, if it is known by the HSS, or the S-CSCF capabilities, if it is necessary to select a new S-CSCF. When capabilities are returned, the I-CSCF shall construct a name from the capabilities returned.

If the checking in HSS was not successful the Cx-Query Resp shall reject the registration attempt.

Step 5.

The I-CSCF, using the name of the S-CSCF, shall determine the address of the S-CSCF through a name-address resolution mechanism. The name-address resolution mechanism is allowed to take the load information of the S-CSCFs (e.g. obtained using network management procedures) into consideration when deciding the address of the S-CSCF. The I-CSCF also determines the name of a suitable home network contact point, possibly based on information received from the HSS. I-CSCF shall then send the register information flow (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address to the selected S-CSCF. The home network contact point will be used by the P-CSCF to forward session initiation signalling to the home network.

The S-CSCF shall reject the registration if the number of registered contact addresses for a Public User Identity from the same UE exceeds the limit of simultaneous registrations configured at the S-CSCF. The S-CSCF shall also reject the registration from separate UEs if the allowed number of simultaneous registrations according to the S-CSCF configuration or per subscribed value for a Public User Identity received from the HSS exceeds the limit of simultaneous registrations. The S-CSCF shall store the P-CSCF address/name, as supplied by the visited network. This represents the address/name that the home network forwards the subsequent terminating session signalling to the UE. The S-CSCF shall store the P-CSCF Network ID information.

Step 6.

The S-CSCF shall send Cx-Put/Cx-Pull (Public User Identity, Private User Identity, S-CSCF name) to the HSS.

Step 7.

The HSS shall store the S-CSCF name for that user and return the information flow Cx-Put Resp/Cx-Pull Resp (user information) to the S-CSCF. The user information passed from the HSS to the S-CSCF shall include one or more names/addresses information which can be used to access the platform(s) used for service control while the user is registered at this S-CSCF. The S-CSCF shall store the information for the indicated user. In addition to the names/addresses information, security information and the MPS for Messaging indication may also be sent for use within the S-CSCF.

Step 8.

Based on the filter criteria, the S-CSCF shall send register information to the service control platform and perform whatever service control procedures are appropriate.

Step 9.

The S-CSCF shall return the 200 OK information flow (home network contact information, a GRUU set) to the I-CSCF.

Step 10.

The I-CSCF shall send information flow 200 OK (home network contact information, a GRUU set) to the P-CSCF. The I-CSCF shall release all registration information after sending information flow 200 OK.

Step 11.

The P-CSCF shall store the home network contact information, and shall send information flow 200 OK (a GRUU set) to the UE. The P-CSCF may subscribe to notifications of the status of the IMS Signalling connectivity from PCRF/PCF (see TS 23.203 and TS 23.503 for more details).

If the S-CSCF receives the priority information of the MPS subscribed-UE, including an MPS for Messaging indication, as a part of user profile from the HSS, the S-CSCF provides the priority information to the P-CSCF and the P-CSCF stores this information for the MPS-subscribed UE.

5.2.2.4 Re-Registration information flow - User currently registered p. 80

Periodic application level re-registration is initiated by the UE either to refresh an existing registration or in response to a change in the registration status of the UE. A re-registration procedure can also be initiated when the capabilities of the UE have changed or the IP-CAN has changed. The UE should perform IMS re-registration when the IP-CAN used by the UE changes between 3GPP access and WLAN access.

Re-registration follows the same process as defined in clause 5.2.2.3 "Registration Information Flow - User not registered". When initiated by the UE, based on the registration time established during the previous registration, the UE shall keep a timer shorter than the registration related timer in the network.

Reproduction of 3GPP TS 23.228, Fig. 5.2: Re-registration - user currently registered

Figure 5.2: Re-registration - user currently registered

Step 1.

The UE initiates a re-registration. For periodic registration, the UE initiates a re-registration prior to expiry of the agreed registration timer. To re-register, the UE sends a new REGISTER request. The UE sends the REGISTER information flow to the proxy (Public User Identity, Private User Identity, home network domain name, UE IP address, capability information, Instance Identifier, GRUU Support Indication).

Step 2.

Upon receipt of the register information flow, the P-CSCF shall examine the "home domain name" to discover the entry point to the home network (i.e. the I-CSCF). The proxy does not use the entry point cached from prior registrations. The proxy shall send the Register information flow to the I-CSCF (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address). A name-address resolution mechanism is utilised in order to determine the address of the home network from the home domain name. The P-CSCF network identifier is a string that identifies at the home network, the network where the P-CSCF is located (e.g. the P-CSCF network identifier may be the domain name of the P-CSCF network).

Step 3.

The I-CSCF shall send the Cx-Query information flow to the HSS (Public User Identity, Private User Identity and P-CSCF network identifier).

Step 4.

The HSS shall check whether the user is registered already and return an indication indicating that an S-CSCF is assigned. The Cx-Query Resp (indication of entry contact point, e.g. S-CSCF) is sent from the HSS to the I-CSCF.

Step 5.

The I-CSCF, using the name of the S-CSCF, shall determine the address of the S-CSCF through a name-address resolution mechanism. The I-CSCF also determines the name of a suitable home network contact point, possibly based on information received from the HSS. I-CSCF shall then send the register information flow (P-CSCF address/name, Public User Identity, Private User Identity, P-CSCF network identifier, UE IP address to the selected S-CSCF. The home network contact point will be used by the P-CSCF to forward session initiation signalling to the home network.

The S-CSCF shall store the P-CSCF address/name, as supplied by the visited network. This represents the address/name that the home network forwards the subsequent terminating session signalling to the UE.

Step 6.

The S-CSCF shall send Cx-Put/Cx-Pull (Public User Identity, Private User Identity, S-CSCF name) to the HSS. Note: Optionally as an optimisation, the S-CSCF can detect that this is a re-registration and omit the Cx-Put/Cx-Pull request.

Step 7.

The HSS shall stores the S-CSCF name for that user and return the information flow Cx-Put Resp/Cx-Pull-Resp (user information) to the S-CSCF. The S-CSCF shall store the user information for that indicated user.

Step 8.

Based on the filter criteria, the S-CSCF shall send re-registration information to the service control platform and perform whatever service control procedures are appropriate.

Step 9.

The S-CSCF shall return the 200 OK information flow (home network contact information, a GRUU set) to the I-CSCF.

Step 10.

Step 11.

The P-CSCF shall store the home network contact information, and shall send information flow 200 OK (a GRUU set) to the UE.

If the S-CSCF receives the priority information of the MPS subscribed-UE as a part of user profile from the HSS, the S-CSCF provides the priority information to the P-CSCF and the P-CSCF stores this information for the MPS-subscribed UE.

5.2.2.5 Stored information. p. 82

Table 5.1 provides an indication of some of the information stored in the indicated nodes during and after the registration process. Note that Table 5.1 is not an exhaustive list of stored information, i.e. there can be additional information stored due to registration.

Table 5.1: Information Storage before, during and after the registration process

Node	Before Registration	During Registration	After Registration
UE - in local network	Credentials Home Domain Proxy Name/Address	Same as before registration	Credentials Home Domain Proxy Name/Address UE P-GRUU At least one T-GRUU
Proxy-CSCF - in Home or Visited network	Routing Function	Initial Network Entry point UE Address Public and Private User IDs Access Network Type	Final Network Entry point UE Address Public and Private User IDs Access Network Type
Interrogating-CSCF - in Home network	HSS or SLF Address	Serving-CSCF address/name P-CSCF Network ID Home Network contact Information	No State Information
HSS	User Service Profile	P-CSCF Network ID	Serving-CSCF address/name
Serving-CSCF (Home)	No state information	HSS Address/name User profile (limited - as per network scenario) Proxy address/name P-CSCF Network ID Public/Private User ID UE IP Address UE P-GRUU UE T-GRUU	May have session state Information Same as during registration