5.4.7A GRUU management

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

5.4.7A.1 Overview of GRUU operation

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs, unless "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] has been provisioned in the service profile of the registered public user identity. This is conducted as specified in RFC 5627 [93] and RFC 5628 [94]. Two kinds of GRUUs are assigned: public GRUUs and temporary GRUUs.

NOTE: If the UE performs the functions of an external attached network (e.g an enterprise network) the UE could have self allocated its own GRUUs. In this version of the specification only UE self allocated public GRUUs are supported. Routeing to a specific UE self-allocated public GRUUs requires that "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] is provisioned in the service profile of the served public user identity. Use of UE self-allocated temporary GRUUs is not supported in this version of the specification and requests addressed to UE self allocated temporary GRUUs will fail to be routed to the UE.

Each assigned GRUU represents an association between a public user identity and an instance ID provided by a registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a "+sip.instance" header field parameter containing the GRUU instance ID.

The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for subscriptions to the "reg" event package. The S-CSCF always issues GRUUs in pairs – a public GRUU and a temporary GRUU. In case of implicit registration the S-CSCF assigns a unique public GRUU and a unique temporary GRUU for each public user identity.

The S-CSCF may also support the procedures for allocating public GRUUs and supporting the generation of temporary GRUUs by the functionality within the UE that performs the role of registrar as specified in RFC 6140 [191] as well as the procedures to route requests containing such GRUUs.

5.4.7A.2 Representation of public GRUUs

Each public GRUU shall conform to all requirements specified in RFC 5627 [93].

If the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then the S-CSCF constructs a public GRUU by adding a "gr" SIP URI parameter to the canonical for m of the SIP URI which contains a public user identity.

If the Contact URI in the Contact header field contains a "bnc" URI parameter and if the S-CSCF supports RFC 6140 [191], then the S-CSCF constructs a public GRUU by adding both "bnc" and "gr" SIP URI parameters to the canonical form of the SIP URI from the To header field of the REGISTER request

The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU and if the "+sip.instance" header field parameter from the Contact address contains an IMEI URN or a MEID URN then it carries a value that encodes the IMEI based instance ID that is defined in 3GPP TS 23.003 [3] or the MEID based instance ID which is defined in RFC 8464 [187] otherwise it carries the value received in the "+sip.instance" header field parameter.

By default, the value of the "gr" SIP URI parameter is a copy of the value of the "+sip.instance" header field parameter from a Contact address registered with the S-CSCF, with escaping of special characters as specified in RFC3261 [26].

The public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the default public user identity.

NOTE 1: The default public user identity is always provisioned as a SIP URI.

If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in RFC 7254 [153] or an MEID URN, as specified in RFC 8464 [187], then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122 [154]. The following applies to the algorithm:

1) the "name space ID" shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154];

NOTE 2: If the generated UUID is changed, then newly created GRUUs will not match those that were created with the previous UUID. Therefore, the UUID needs to remain the same in order to create consistent GRUUs. This means that the namespace UUID needs to be the same for all S-CSCFs within the domain for which the public GRUU is hosted (it cannot be generated at run time by the S-CSCF as that would produce different values).

2) SHA-1 shall be used as the hash algorithm; and

3) the "name" is made up of a concatenation of the ASCII representation (see RFC 20 [212]) of:

a) if IMEI, the TAC and SNR portions of the IMEI; or

b) if MEID, the Manufacturer Code and the Serial Number portions of the MEID;

from the "+sip.instance" header field parameter.

Only the IMEI shall be use for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks, and the S-CSCF shall follow the procedures for an IMEI as described above.

The S-CSCF shall store the "gr" parameter used in a public GRUU and the associated value received in a "+sip.instance" header field parameter.

The public GRUU for a particular association of public user identity and instance ID is persistent. The same public GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance ID.

5.4.7A.3 Representation of temporary GRUUs

NOTE 1: For UEs performing the functions of an external attached network that support RFC 6140 [191] the S-CSCF does not allocate temporary GRUUs but assists the functionality within the UE that performs the role of registrar in allocating it’s own temporary GRUUs by providing to the UE the "temp-gruu-cookie" header field parameter that uniquely identifies the registration. The functionality within the UE that performs the role of registrar then is able to allocate its own temporary GRUUs as per RFC 6140 [191] procedures.

Each temporary GRUU shall conform to all requirements specified in RFC 5627 [93].

Because of the limited lifetime of an temporary GRUU, only the S-CSCF that created a temporary GRUU is required to understand how to translate that GRUU to the corresponsing public user identity and instance ID.

The temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the default public user identity.

NOTE 2: The default public user identity is always provisioned as a SIP URI.

The specific representation of a temporary GRUU may be decided by each S-CSCF implementation. Temporary GRUUs must route to the assigning S-CSCF without requiring each assigned GRUU to be stored in the HSS.

The S-CSCF may choose a representation of temporary GRUUs that requires no extra state to be retained, such as that specified in RFC 5627 [93]. Alternatively, the S-CSCF may choose a stateful representation. This is an implementation choice.

NOTE 3: One possible implementation is for the S-CSCF to have a statically configured wildcard PSI that routes to it, with each temporary GRUU being encoded so that it matches the wildcard.

5.4.7A.4 GRUU recognition and validity

The S-CSCF shall recognize those GRUUs it has assigned, verify their validity, and extract the associated public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar and instance ID. This is true for both public GRUUs and temporary GRUUs.

NOTE 1: The S-CSCF only validates and extracts the associated public user identity and instance ID for GRUUs that it assigned.

GRUUs are distinguished from other URIs by the presence of a "gr" SIP URI parameter. Public GRUUs are distinguished from temporary GRUUs by the presence of a value for the "gr" SIP URI parameter.

The instance ID is obtained from a public GRUU by using the "gr" parameter to retrieve the stored associated instance ID. The public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar is extracted from a public GRUU by removing the "gr" SIP URI parameter.

The S-CSCF can recognize a public GRUU as valid if the "gr" parameter contains a value that was stored in the S-CSCF during generation of the public GRUU, and the derived public user identity compares equal, according to the comparison rules of RFC3261 [26], to a public user identity active within the S-CSCF or a stored identity of the UE that represents the functionality within the UE that performs the role of registrar from which a public GRUU was created. When validating public GRUUs the S-CSCF shall ignore the presence of any "sg" SIP URI parameter when determining if a public GRUU is one allocated by the S-CSCF.

NOTE 2: The UE that supports RFC 6140 [191] and performs the functions of an external attached network, adds a unique "sg" SIP URI parameter value to the public GRUU supplied by the S-CSCF when generating public GRUUs for its registering UAs.

The public user identity and instance ID are derived from a temporary GRUU via implementation specific means consistent with the way temporary GRUUs are constructed. The S-CSCF shall determine the validity of a temporary GRUU in conformance with RFC 5627 [93], and if the GRUU was allocated using RFC 6140 [191] procedures then in conformance with RFC 6140 [191] or using implementation specific means.

The S-CSCF regards a UE self-allocated public GRUU as valid if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] is provisioned in the service profile of the served public user identity.