The mechanisms for addressing and routing for access to IM CN subsystem services and issues of general IP address management are discussed in TS 23.221.
When a UE is assigned an IPv6 prefix, it can change the global IPv6 address it is currently using via the mechanism defined in RFC 4941, or similar means. When a UE is registered in the IM CN Subsystem with an IP address, any change to this IP address that is used to access the IM CN subsystem will result in dropping the active SIP dialogs, and shall trigger automatic registration. This automatic registration updates the UE's IP address and security association. To avoid disruption of ongoing IM CN subsystem services, the UE should not change the IP address that it uses to access the IM CN subsystem while engaged in active SIP dialogs (e.g. INVITE or SUBSCRIBE-NOTIFY dialogs).
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, 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 TS 23.003, clause 13.3.
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, 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.
The following architectural requirements shall apply to support of GRUU in the IMS:
If a UE could become engaged in a service (e.g. telephony supplementary service) that potentially requires the ability to identify and interact with a specific UE even when multiple UEs share the same single Public User Identity then the UE should support GRUU.
A GRUU shall be registered in the IMS network with a unique combination of specific Public User Identity and UE.
If a UE supports GRUU, it shall indicate support for a GRUU that is associated with a specific Public User Identity at the time of registration of the Public User Identity. The UE shall use the same instance ID for all registration requests regardless of the access network used for registration. A function that registers on behalf of a UE shall use the same Instance ID as if that UE had performed the registration itself.
The IMS network shall be able to receive an indication of support for GRUU for a specific Public User Identity at a specific UE instance and be able to generate both P-GRUU's and T-GRUU's and return them back to the UE that indicated support for GRUU.
When the IMS network receives indication of GRUU support for a specific Public User Identity from the UE during a registration request, the IMS network shall also generate P-GRUU's and T-GRUU's for all implicitly registered Public User Identities belonging to the same implicit registration set. The IMS network shall communicate all these other GRUUs to the UE.
Registrations of all GRUUs associated with a specific Public User Identity shall also be directed to the same S-CSCF.
The IMS network will be able to generate GRUU's for any UE registered with a valid SIP URI.
The IMS network shall generate the same P-GRUU for a given Public User Identity and Instance Identifier combination.
The IMS network shall generate a different T-GRUU for a given Public User Identity and Instance Identifier combination for each registration and re-registration.
The IMS network shall be able to derive the Public User Identity directly from the P-GRUU. The Public User Identity derived from the P-GRUU used to identify the contact address of the sender shall be same as the Public User Identity used to identify the initiator or an associated Public User Identity. If the URI in the SIP Contact header of the sender carries a parameter indicating that it is a GRUU but does not comply with the stated requirement or if there is no registration corresponding to the GRUU, then the IMS network should reject the request.
The IMS network shall be able to route requests destined to a GRUU to the UE instance registered with that GRUU.
The IMS network shall not fork SIP requests addressed to a GRUU to separate UEs.
A UE that is capable of supporting GRUUs shall be able to differentiate between a GRUU and a Public User Identity.
The IMS network shall support establishment of session or non-session related communication using a GRUU.
A UE supporting GRUUs shall be able to inter-work with an IMS network not supporting GRUUs.
A UE supporting GRUUs shall be able to inter-work with a UE not supporting GRUUs per RFC 5627].
A UE or network that supports GRUUs shall not negatively affect networks or UEs that do not support GRUUs.
It shall be possible to define iFCs that match the Public User Identity part of a GRUU.
It shall be possible for iFCs to determine whether the Request URI of a message contains a GRUU, and then trigger to Application Servers that are only applicable for GRUUs.
It shall be possible to provide terminating services to a GRUU associated with a currently unregistered subscriber.
It shall be possible to apply same level of privacy irrespective whether GRUU is used or not.
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  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.
(not reproduced yet)
Figure 4.5: Relationship of the Private User Identity and Public User Identities
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 184.108.40.206 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, 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.
(not reproduced yet)
Figure 4.6: The relation of a shared Public User Identity (Public-ID-2) and Private User Identities
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.
(not reproduced yet)
Figure 4.6a: The relationship of Public User Identities, GRUUs, and UEs
The CSCF, BGCF and MGCF nodes shall be identifiable using a valid SIP URI (Host Domain Name or Network Address) on those interfaces supporting the SIP protocol, (e.g. Gm, Mw, Mm, and Mg). These SIP URIs would be used when identifying these nodes in header fields of SIP messages. However this does not require that these URIs will be globally published in DNS.
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 RFC 3761 clause 1.2), 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 220.127.116.11. 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 18.104.22.168. 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 22.214.171.124 for handling of Tel URIs.
With the introduction of standardized presence, messaging, conferencing, and group service capabilities in IM CN subsystem, there is a need for Public Service Identities (PSIs). These identities are different from the Public User Identities in the respect that they identify services, which are hosted by Application Servers. In particular, Public Service Identities are used to identify groups, see clause 4.10. For example a chat-type service may use a Public Service Identity (e.g. sip:chatlist_X@example.com) to which the users establish a session to be able to send and receive messages from other session participants. As another example, local service may be identified by a globally routable Public Service Identity.
Public Service Identities shall take the form as defined in TS 23.003.
The IM CN subsystem shall provide the capability for users to create, manage, and use Public Service Identities under control of AS. It shall be possible to create statically and dynamically a Public Service Identity.
Each Public Service Identity is hosted by an Application Server, which executes the service specific logic as identified by the Public Service Identity.
The IM CN Subsystem shall provide capability of routing IMS messages using Public Service Identity.