This clause describes the format of the parameters needed to access the IP multimedia core network subsystem. For further information on the use of the parameters see TS 23.228 and TS 29.163. For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document. For more information on the ".invalid" top level domain see RFC 2606.

The home network domain name shall be in the form of an Internet domain name, e.g. operator.com, as specified in RFC 1035 and RFC 1123. The home network domain name consists of several labels. Each label shall consist of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-) in accordance with RFC 1035. Each label shall begin and end with either an alphabetic character or a digit in accordance with RFC 1123. The case of alphabetic characters is not significant. For 3GPP systems, if there is no ISIM application, the UE shall derive the home network domain name from the IMSI as described in the following steps:

1. Take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see TS 31.102) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning.
2. Use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.3gppnetwork.org" domain name.
3. Add the label "ims." to the beginning of the domain.

An example of a home network domain name is: The Home Network Domain for a Stand-alone Non-Public Network (SNPN) subscriber with an IMSI-based SUPI type, shall use the IMSI-based derivation described above, and append nid<NID> of the SNPN, between the "ims." and "mnc<MNC>" labels. An example of a home SNPN network domain name using the above IMSI and NID 000007ed9d5 is ims.nid000007ed9d5.mnc015.mcc234.3gppnetwork.org. The Home Network Domain for a Stand-alone Non-Public Network (SNPN) subscriber identified by a SUPI containing a network-specific identifier that takes the form of an NAI consists of the string "ims." appended with the realm part of the NAI. For 3GPP2 systems, if there is no IMC present, the UE shall derive the home network domain name as described in Annex C of 3GPP2 X.S0013-004 [67].

The private user identity shall take the form of an NAI, and shall have the form username@realm as specified in Section 2.1 of RFC 4282. For 3GPP systems, the private user identity used for the user shall be as specified in clause 4.2 of TS 24.229 and in TS 23.228 Annex E.3.1. If the private user identity is not known, the private user identity shall be derived from the IMSI. The following steps show how to build the private user identity out of the IMSI:

1. Use the whole string of digits as the username part of the private user identity; and
2. convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in clause 13.2.

The result will be a private user identity of the form "<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org". For example: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identity then takes the form "234150999999999@ims.mnc015.mcc234.3gppnetwork.org". The private user identity for a Stand-alone Non-Public Network (SNPN) subscriber with an IMSI-based SUPI type, shall use the IMSI-based derivation described above, and append nid<NID> of the SNPN, between the "ims." and "mnc<MNC>" labels. For an SNPN, if IMSI is as above, and for a NID of 000007ed9d5, the private user identity takes the form "234150999999999@ims.nid000007ed9d5.mnc015.mcc234.3gppnetwork.org". The Private User Identity for a Stand-alone Non-Public Network (SNPN) subscriber identified by a SUPI containing a network-specific identifier that takes the form of an NAI is obtained as follows: the username is the same as the username in the NAI, and the realm portion is identical with the Home domain defined in clause 13.2. For 3GPP2 systems, if there is no IMC present, the UE shall derive the private user identity as described in Annex C of 3GPP2 X.S0013-004 [67].

A Public User Identity is any identity used by a user within the IMS subsystem for requesting communication to another user. The Public User Identity shall take the form of either a SIP URI (see RFC 3261) or a Tel URI (see RFC 3966). The 3GPP specifications describing the interfaces over which Public User Identities are transferred specify the allowed Public User Identity formats, in particular TS 24.229 for SIP signalling interfaces, TS 29.229 for Cx and Dx interfaces, TS 29.329 for Sh interface, TS 29.165 for II-NNI interface. In the case the user identity is a telephone number, it shall be represented either by a Tel URI or by a SIP URI that includes a "user=phone" URI parameter and a "userinfo" part that shall follow the same format as the Tel URI. According to TS 24.229, the UE can use either:

• a global number as defined in RFC 3966 and following E.164 format, as defined by ITU-T Recommendation E.164 [10] or
• a local number, that shall include a "phone-context" parameter that identifies the scope of its validity, as per RFC 3966.

According to TS 29.165 a global number as defined in RFC 3966 shall be used in a tel-URI or in the user portion of a SIP URI with the user=phone parameter when conveyed via a non-roaming II-NNI except when agreement exists between the operators to also allow other kinds of numbers. According to TS 29.229 and TS 29.329 the canonical forms of SIP URI and Tel URI shall be used over the corresponding Diameter interfaces. The canonical form of a SIP URI for a Public User Identity shall take the form "sip:username@domain" as specified in Section 10.3 of RFC 3261. SIP URI comparisons shall be performed as defined in Section 19.1.4 of RFC 3261. The canonical form of a Tel URI for a Public User Identity shall take the form "tel:+<CC><NDC><SN>" (max number of digits is 15), that represents an E.164 number and shall contain a global number without parameters and visual separators (see Section 3 of RFC 3966). Tel URI comparisons shall be performed as defined in Section 4 of RFC 3966. Public User Identities are stored in the HSS either as a distinct Public User Identity or as a Wildcarded Public User Identity. A distinct Public User Identity contains the Public User Identity that is used in routing and it is explicitly provisioned in the HSS.

Public User Identities may be stored in the HSS as Wildcarded Public User Identities. A Wildcarded Public User Identity represents a collection of Public User Identities that share the same service profile and are included in the same implicit registration set. Wildcarded Public User Identities enable optimisation of the operation and maintenance of the nodes for the case in which a large amount of users are registered together and handled in the same way by the network. The format of a Wildcarded Public User Identity is the same as for the Wildcarded PSI described in clause 13.5.

For 3GPP systems, if there is no ISIM application to host the Public User Identity, a Temporary Public User Identity shall be derived, based on the IMSI. The Temporary Public User Identity shall be of the form as described in clause 13.4 and shall consist of the string "sip:" appended with a username and domain portion equal to the IMSI derived Private User Identity, as described in clause 13.2. An example using the same example IMSI from clause 13.2 can be found below: EXAMPLE: The temporary public user identity for a Stand-alone Non-Public Network (SNPN) subscriber with an IMSI-based SUPI type, shall use the IMSI-based derivation described above, and append nid<NID> of the SNPN, in between the "ims." and "mnc<MNC>" labels. EXAMPLE for an SNPN: The temporary Public User Identity for a Stand-alone Non-Public Network (SNPN) subscriber identified by a SUPI containing a network-specific identifier that takes the form of an NAI consists of the string "sip:" appended with a username and realm portion equal to the NAI SUPI derived Private User Identity. For 3GPP2 systems, if there is no IMC present, the UE shall derive the public user identity as described in Annex C of 3GPP2 X.S0013-004 [67].

The public service identity shall take the form of either a SIP URI (see RFC 3261) or a Tel URI (see RFC 3966). A public service identity identifies a service, or a specific resource created for a service on an application server. The domain part is pre-defined by the IMS operators and the IMS system provides the flexibility to dynamically create the user part of the PSIs. The PSIs are stored in the HSS either as a distinct PSI or as a wildcarded PSI. A distinct PSI contains the PSI that is used in routing , whilst a wildcarded PSI represents a collection of PSIs. Wildcarded PSIs enable optimisation of the operation and maintenance of the nodes. A wildcarded PSI consists of a delimited regular expression located either in the userinfo portion of the SIP URI or in the telephone-subscriber portion of the Tel URI. The regular expression in the wildcarded PSI shall take the form of Extended Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.1-2004 Part 1 [60]. The delimiter shall be the exclamation mark character ("!"). If more than two exclamation mark characters are present in the userinfo portion or telephone-subscriber portion of a wildcarded PSI then the outside pair of exclamation mark characters is regarded as the pair of delimiters (i.e. no exclamation mark characters are allowed to be present in the fixed parts of the userinfo portion or telephone-subscriber portion). When stored in the HSS, the wildcarded PSI shall include the delimiter character to indicate the extent of the part of the PSI that is wildcarded. It is used to separate the regular expression from the fixed part of the wildcarded PSI. Example: The following PSI could be stored in the HSS - "sip:chatlist!.*!@example.com". When used on an interface, the exclamation mark characters within a PSI shall not be interpreted as delimiter.. Example: The following PSIs communicated in interface messages to the HSS will match to the wildcarded PSI of "sip:chatlist!.*!@example.com" stored in the HSS: Note that sip:chatlist1@example.com and sip:chatlist!1@example.com are regarded different specific PSIs, both matching the wildcarded PSI sip:chatlist!.*!@example.com. When used by an application server to identify a specific resource (e.g. a chat session) over Inter Operator Network to Network Interface (II-NNI), the PSI should be a SIP URI without including a port number.

The Private Service Identity is applicable to a PSI user and is similar to a Private User Identity in the form of a Network Access Identifier (NAI), which is defined in RFC 4282. The Private Service Identity is operator defined and although not operationally used for registration, authorisation and authentication in the same way as Private User Identity, it enables Public Service Identities to be associated to a Private Service Identity which is required for compatibility with the Cx procedures.

The Anonymous User Identity shall take the form of a SIP URI (see RFC 3261). A SIP URI for an Anonymous User Identity shall take the form "sip:user@domain". The user part shall be the string "anonymous" and the domain part shall be the string "anonymous.invalid". The full SIP URI for Anonymous User Identity is thus: For more information on the Anonymous User Identity and when it is used, see TS 29.163.

The Unavailable User Identity shall take the form of a SIP URI (see RFC 3261). A SIP URI for an Unavailable User Identity shall take the form "sip:user@domain". The user part shall be the string "unavailable" and the domain part shall be the string "unknown.invalid". The full SIP URI for Unavailable User Identity is thus: For more information on the Unavailable User Identity and when it is used, see TS 29.163.

An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration. When an IMEI is available, the instance-id shall take the form of a IMEI URN (see RFC 7254). The format of the instance-id shall take the form "urn:gsma:imei:<imeival>" where by the imeival shall contain the IMEI encoded as defined in RFC 7254. The optional <sw-version-param> and <imei-version-param> parameters shall not be included in the instance-id. RFC 7255 specifies additional considerations for using the IMEI as an instance-id. An example of such an instance-id is as follows: If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in RFC 4122. An example of such an instance-id is as follows: For more information on the instance-id and when it is used, see TS 24.229.

The Default Conference Factory URI for MMTel shall take the form of a SIP URI (see RFC 3261) with a host portion set to the home network domain name as described in clause 13.2 prefixed with "conf-factory.". The user portion shall be set to "mmtel". Examples of the Default Conference Factory URI for MMTel can be found below:

The Unknown User Identity shall take the form of a SIP URI (see RFC 3261). A SIP URI for an Unknown User Identity shall take the form "sip:user@domain". The user part shall be the string "unknown" and the domain part shall be the string "unknown.invalid". The full SIP URI for Unknown User Identity is thus: For more information on the Unknown User Identity and when it is used, see clauses 7.4.6 and 7.5.4 of TS 29.163.

The IMEI based identity shall take the form of a SIP URI (see RFC 3261). The IMEI based identity is included in P-Preferred-Identity header field of SIP INVITE request by the UE and used in cases of unauthenticated emergency sessions as specified in clause 5.1.6.8.2 of TS 24.229. A SIP URI for an IMEI based identity shall take the form "sip:user@domain" where by the user part shall contain the IMEI. The IMEI shall be encoded according to ABNF of imeival as defined in RFC 7254. The domain part shall contain the home network domain named derived as specified in clause 13.2. An example for the case when the UE has a home network domain name of operator.com is: