Content for  TS 23.228  Word version:  19.0.0

There are various identities that may be associated with a user of IP multimedia services. This clause describes these identities and their use.

Every IM CN subsystem user shall have one or more Private User Identities. The private identity is assigned by the home network operator, and used, for example, for Registration, Authorization, Administration, and Accounting purposes. This identity shall take the form of a Network Access Identifier (NAI) as defined in RFC 4282. It is possible for a representation of the IMSI to be contained within the NAI for the private identity.

• The Private User Identity is not used for routing of SIP messages.
• The Private User Identity shall be contained in all Registration requests, (including Re-registration and De-registration requests) passed from the UE to the home network.
• An ISIM application shall securely store one Private User Identity. For UEs supporting only non-3GPP accesses or UEs accessing IMS via SNPN, if neither ISIM nor USIM is present, but IMC is present, the Private User Identity shall be stored in IMC. It shall not be possible for the UE to modify the Private User Identity information stored on the ISIM application or IMC.
• The Private User Identity is a unique global identity defined by the Home Network Operator, which may be used within the home network to identify the user's subscription (e.g. IM service capability) from a network perspective. The Private User Identity identifies the subscription, not the user.
• The Private User Identity shall be permanently allocated to a user's subscription (it is not a dynamic identity), and is valid for the duration of the user's subscription with the home network.
• The Private User Identity is used to identify the user's information (for example authentication information) stored within the HSS (for use for example during Registration).
• The Private User Identity may be present in charging records based on operator policies.
• The Private User Identity is authenticated only during registration of the user, (including re-registration and de-registration).
• The HSS needs to store the Private User Identity.
• The S-CSCF needs to obtain and store the Private User Identity upon registration and unregistered termination.
• If mobile terminated short message service without MSISDN as defined in TS 23.204 is required then the Private User Identity shall be based on the IMSI according to clause 13.3 of TS 23.003.

Every IM CN subsystem user shall have one or more Public User Identities (see TS 22.228), including at least one taking the form of a SIP URI (see RFC 3261). The Public User Identity is used by any user for requesting communications to other users. For example, this might be included on a business card.

• Both telecom numbering and Internet naming schemes can be used to address users depending on the Public User identities that the users have.
• The Public User Identity shall take the form as defined in TS 23.003.
• An ISIM application shall securely store at least one Public User Identity. For UEs supporting only non-3GPP accesses or UEs accessing IMS via SNPN, if neither ISIM nor USIM is present, but IMC is present, the Public User Identity shall be stored in IMC. It shall not be possible for the UE to modify the Public User Identity, but it is not required that all additional Public User Identities be stored on the ISIM application or IMC.
• A Public User Identity shall be registered either explicitly or implicitly before originating IMS sessions and originating IMS session unrelated procedures can be established by a UE using the Public User Identity. Subscriber-specific services for unregistered users may nevertheless be executed as described in clause 5.6.5. Each implicit registration set shall contain at least one Public User Identity taking the form of a SIP URI.
• It shall be possible to identify Alias Public User Identities. For such a group of Public User Identities, operations that enable changes to the service profile and the service data configured shall apply to all the Public User Identities within the group. This grouping information shall be stored in the HSS. It shall be possible to make this grouping information available to the AS via the Sh interface, and Sh operations are applicable to all of the Public User Identities within the same Alias Public User Identity group. It shall be possible to make this information available to the S-CSCF via the Cx interface. It shall be possible to make this information available to the UE via the Gm interface.
• A Public User Identity shall be registered either explicitly or implicitly before terminating IMS sessions and terminating IMS session unrelated procedures can be delivered to the UE of the user that the Public User Identity belongs to. Subscriber-specific services for unregistered users may nevertheless be executed as described in clause 5.12.
• It shall be possible to register globally (i.e. through one single UE request) a user that has more than one public identity via a mechanism within the IP multimedia CN subsystem (e.g. by using an Implicit Registration Set). This shall not preclude the user from registering individually some of his/her public identities if needed.
• Public User Identities are not authenticated by the network during registration.
• Public User Identities may be used to identify the user's information within the HSS (for example during mobile terminated session set-up).

A Globally Routable User Agent URI (GRUU) is an identity that identifies a unique combination of Public User Identity and UE instance that allows a UE to address a SIP request to a specific Public User Identity UE combination instance, as opposed to a Public User Identity, in order to ensure that the SIP request is not forked to another registered UE of the same Public User Identity. There are two types of GRUUs; Public GRUUs (P-GRUUs) and Temporary GRUUs (T-GRUUs). P-GRUUs are GRUUs that reveal the Public User Identity of the user and are very long lived. T-GRUUs are GRUUs that contain a URI that do not reveal the Public User Identity of the user and are valid until the contact is explicitly de-registered or the current registration expires. The IM CN subsystem shall support the capability for IMS UEs to obtain both T-GRUUs and P-GRUUs when performing IMS registration, exchange GRUUs using SIP requests and responses and use GRUUs to address SIP requests to specific UEs according to RFC 5627.

It shall be possible to support a wildcarded Public User Identity. A wildcarded Public User Identity expresses a set of Public User Identities grouped together. It shall be possible to include and express the wildcarded Public User Identity in the implicit registration set according to clause 5.2.1a. Only distinct Public User Identities shall be used for explicit registration. The implicit registration of a wildcarded Public User Identity shall be handled in the same manner as the implicit registration of a distinct Public User Identity from a network perspective, with only one service profile associated to the wildcarded Public User Identity. It shall be possible for a user to have a distinct Public User Identity even if it matches a wildcarded Public User Identity. Such a distinct Public User Identity may have a different service profile than the wildcarded Public User Identity. The matching of a distinct Public User Identity shall take precedence over matching of wildcarded Public User Identity. When the value of a Public User Identity matches what is expressed as an implicitly registered wildcarded Public User Identity and there is no better match, then the procedures are the same as in the case that the identifier matches an implicitly registered distinct Public User Identity.

Routing of SIP signalling within the IMS shall use SIP URIs or other (non SIP) AbsoluteURIs. AbsoluteURIs are defined in RFC 3986. Routing of SIP signalling within the IMS using AbsoluteURI (non SIP) shall only be supported for IMS signalling from IMS user to external networks. E.164 [2] format Public User Identities shall not be used for routing within the IMS, and session requests based upon E.164 format Public User Identities will require conversion into SIP URI format for internal IMS usage.

When using a phone number as the dialled address, the UE can provide this number in the form of a SIP URI or a TEL URI. This phone number can be in the form of E.164 format (prefixed with a '+' sign), or a local format using local dialling plan and prefix. The IMS will interpret the phone number with a leading '+' to be a fully defined international number.

If a terminating session with a TEL URI is used, the HSS and the SLF (in the case that more than one independently addressable HSS is utilized by a network operator) shall support the TEL URI format Public User Identity.

The home network operator is responsible for the assignment of the Private User Identities, and Public User Identities; other identities that are not defined by the operator may also exist.

The IMS Service Profile is a collection of service and user related data as defined in TS 29.228. The Service Profile is independent from the Implicit Registration Set, e.g. Public User Identities with different Service Profiles may belong to the same Implicit Registration Set. Initial filter criteria in the service profile provide a simple service logic comprising of user / operator preferences that are of static nature i.e. they do not get changed on a frequent basis. It shall be possible to identify Alias Public User Identities. See clause 4.3.3.2 for more details. Application servers will provide more complex and dynamic service logic that can potentially make use of additional information not available directly via SIP messages (e.g. location, time, day etc.). The IMS service profile is defined and maintained in the HSS and its scope is limited to IM CN Subsystem. A Public User Identity shall be registered at a single S-CSCF at one time. All Public User Identities of an IMS subscription shall be registered at the same S-CSCF. The service profile is downloaded from the HSS to the S-CSCF. Only one service profile shall be associated with a Public User Identity at the S-CSCF at a given time. Multiple service profiles may be defined in the HSS for a subscription. Each Public User Identity is associated with one and only one service profile. Each service profile is associated with one or more Public User Identities. An ISIM application shall securely store the home domain name of the subscriber. For UEs supporting only non-3GPP accesses or UEs accessing IMS via SNPN, if neither ISIM nor USIM is present, but IMC is present, the home domain name shall be stored in IMC. It shall not be possible for the UE to modify the information from which the home domain name is derived. It is not a requirement for a user to be able to register on behalf of another user which is third party registration specified in RFC 3261 or for a device to be able to register on behalf of another device or for combinations of the above for the IM CN subsystem for this release. Public User Identities may be shared across multiple Private User Identities within the same IMS subscription. Hence, a particular Public User Identity may be simultaneously registered from multiple UEs that use different Private User Identities and different contact addresses. If a Public User Identity is shared among the Private User Identities of a subscription, then it is assumed that all Private User Identities in the IMS subscription share the Public User Identity. The relationship for a shared Public User Identity with Private User Identities, and the resulting relationship with service profiles and IMS subscription, is depicted in Figure 4.6. An IMS subscription may support multiple IMS users.

All Service Profiles of a user shall be stored in the same HSS, even if the user has one or more shared Public User Identities.

Each Public User Identity may have one or more Globally Routable User Agent URIs (GRUUs). There are two types of GRUU, P-GRUUs and T-GRUUs which are associated with Public User Identities and are generated and assigned to the UE together during registrations and re-registration in a pair of one P-GRUU and one T-GRUU. Each pair of a P-GRUU and a T-GRUU is associated with one Public User Identity and one UE. During subsequent re-registrations the same P-GRUU will be assigned to the UE but a new and different T-GRUU will be generated and assigned. After a re-registration all the previous T-GRUUs generated during the period of this registration are all still valid. A UE may retain some or all of the previous T-GRUUs obtained during the initial registration or previous re-registrations along with the new T-GRUU or the UE may replace some or all of the previous T-GRUUs with the new T-GRUU. The current set of the P-GRUU and all T-GRUUs which are currently valid during this registration period is referred to here as the GRUU set. This relationship is depicted in Figure 4.6a. If a UE registers (explicitly or implicitly) with multiple Public User Identities, a separate GRUU set is associated with each. If different UEs register with the same Public User Identity, a different GRUU set is associated with each.

The ENUM/DNS translation mechanism as specified in RFC 3761 can be used by all IMS nodes that require E.164 address to SIP URI resolution. The actual ENUM/DNS database(s) used to perform address translations are outside the scope of 3GPP and are therefore a matter for the network operator. There is no requirement that the universal ENUM service on the Internet be used. As such, it is possible that the ENUM/DNS mechanism uses a different top level domain to that of "e164.arpa." (as mandated in Section 1.2 of RFC 3761), therefore, the top level domain to be used for ENUM domain names shall be a network operator configurable option in all IMS nodes that can perform ENUM/DNS resolution. In some scenarios, owners of ENUM servers may require information on who is the querying IMS operator, to determine an appropriate response (including whether to respond at all). This capability is required on the egress of the IMS network, particularly in the presence of shared network elements and intermediary IMS network(s) between the originating IMS operator and target ENUM/DNS server(s). ENUM databases may contain Number Portability information. Number Portability is further described in clause 4.18.1.

The S-CSCF shall support the ability to translate the E.164 address contained in a Request-URI in the Tel: URI format (as specified in RFC 3966) to a SIP routable SIP URI using the ENUM/DNS translation mechanism as specified in clause 4.3.5.1. If this translation succeeds, then the session shall be routed according to the returned SIP URI. If this translation fails, then the session may be forwarded to a BGCF for further routing (e.g. to the PSTN) as described in clause 5.19 or appropriate notification shall be sent to the originating session endpoint, depending on network operator configuration. When clause 4.15a (Roaming Architecture for Voice over IMS with Local Breakout) is in use, and the Home Network decides to loop-back the call to the visited network, the Home network can choose not to translate the E.164 address in the Request-URI to a globally routable SIP URI, and leave it to the visited network.

Per network operator policy, the network may attempt to resolve and route a SIP URI representing a telephone number and a domain that does not own the target user using the ENUM/DNS translation mechanism specified in clause 4.3.5.1. The need for address resolution may be triggered by the S-CSCF, and the I-CSCF or transit function, as determined by network operator configuration. Procedures applied to the S-CSCF, I-CSCF and transit functions are outlined below. When an originating S-CSCF receives an originating request with a Request-URI containing the SIP representation of an E.164 number, network operator policy shall dictate whether the procedure shall be carried out for all the domains of the SIP URI where those domains belong to the home network, or not at all. If operator policy indicates that the procedure is to be performed, then the S-CSCF shall reuse the procedure specified in clause 4.3.5 for handling of Tel URIs. If the operator policy at the originating S-CSCF dictates that the procedure shall not be performed or the SIP URI containing the representation of an E.164 number contains a domain that does not belong to the home network, then the S-CSCF shall handle and route the request in the same manner as a SIP URI. Prior to an HSS Location Query, the I-CSCF shall translate a SIP URI representing a telephone number contained in a Request-URI into the Tel: URI format specified in RFC 3966. The resultant Tel URI shall then be used for performing the HSS Location Query. If the HSS Location Query response indicates that the user does not exist, and if configured by operator policy, the I-CSCF shall invoke the portion of transit functionality that translates the E.164 address contained in the Tel URI in the Request-URI into a routable SIP URI, reusing the procedure specified in clause 4.3.5.2 for handling of Tel URIs.