5.12 Location Retrieval Function (LRF)

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.12.1 General

The LRF can receive URIs for a domain for which the operator running the LRF is not responsible. Where RFC 3261 [26] specifies a requirement that the SIP entity has to be responsible for the domain for particular functionality to occur, the LRF may ignore this restriction.

NOTE: The LRF would normally implement this override if the P-CSCF is configured to pass on URIs (e.g. Request-URI) that are outside the responsible domain of the LRF, otherwise emergency calls might not be routed to a PSAP. If the P-CSCF does not do this, then the override need not be applied.

The LRF shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field if required by local policy.

When sending a failure response to any received request, depending on operator policy, the LRF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "lrf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.

5.12.2 Treatment of incoming initial requests for a dialog and standalone requests

The LRF shall respond to all received initial requests for a dialog, and to all standalone requests, as a redirect server as defined in subclause 8.3 of RFC 3261 [26] with the following additions:

1) the LRF shall generate a 300 (Multiple Choices) response to all such requests;

2) the LRF shall set the Contact header field of the response to a list (one or more) address(es) of PSAP(s), selected according to network operator policy;

NOTE 1: The mechanisms for selection of PSAP addresses are outside the scope of this specification, but can be based on a variety of input information including the value of the URN included in the Request-URI of the request, the value of the Geolocation header field and Geolocation-Routing header field received in the request, the value of the P-Access-Network-Info header field received in the request, any location known at the LRF for the requesting user as identified by the P-Access-Network-Info header field.

2A) if the location is retrieved using information from the Geolocation header field, and if:

– the Geolocation-Routing header field is present, and includes a value not allowing routing of the request based on user location information;

– the Geolocation-Routing header field is present, and includes a value unknown to the LRF; or

– the Geolocation-Routing header field is not present;

the LRF shall not use the location retrieved from the Geolocation header field when selecting PSAP(s);

3) the LRF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The LRF shall set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request;

4) optionally, generate a reference identifier and set the P-Asserted-Identity header field encoded as a header field of the URI in the Contact header field to this value in each included Contact header field URI associated with a PSAP. The LRF shall maintain state for any generated reference identifier. If the LRF uses a SIP URI (or any other permitted URI scheme other than tel URI) as the reference identifier, the LRF has the responsibility of ensuring (e.g. by configuration) that the emergency request is being routed to an IP connected PSAP. Subclause 5.12.3.1 defines a means of maintaining the state of the reference identifier. If required by operator policy governing the indication to PSAPs that a UE does not have sufficient credentials (e.g. determined by national regulatory requirements applicable to emergency services), the reference identifier shall not be equal to a non-dialable callback number used to indicate the UE does not have credentials;

NOTE 2: The reference identifier is used to correlate information requested over the Le interface (see 3GPP TS 23.167 [4B]) and is not needed if the Le interface is not used. The protocol at the Le interface is not defined in this release.

NOTE 3: The reference identifier is managed by the RDF or the LRF. If the RDF manages the reference identifier, the LRF obtains the a reference identifier from the RDF. In some regional systems, this reference identifier is the ESQK.

5) if required by operator local policies, the LRF shall include a message/external-body MIME type as specified in RFC 4483 [186] with:

a) "access-type" MIME type parameter containing "URL"; and

b) "URL" MIME type parameter containing an HTTP or HTTPS URI identifying a PIDF location object as defined in RFC 4119 [90] and RFC 5491 [267]; and

6) if required by operator local policies, the LRF shall include geographical information, encoded as header fields of the URI in a Contact header field of the 300 (Multiple Choices) response, in the following way:

a) if operator policy indicates location-by-reference is to be used:

i. a Geolocation-Routing header field with value "yes"; and

ii. a Geolocation header field that contains an HTTP URI or a HTTPS URI associated with a location-by-reference, as defined in RFC 6442 [89]; and

b) if operator policy indicates location-by-value is to be used:

i. a Geolocation-Routing header field with value "yes";

ii. Geolocation header field with value associated with the location-by-value;

iii. a header field with hname "body" and with a value that contains an escape encoded MIME body of multipart/mixed MIME type containing:

– the MIME body from the received request; and

– the geographical location information as PIDF location object in accordance with RFC 4119 [90] and RFC 5491 [267]; and

iv. a Content-Type header field with multipart/mixed MIME type.

NOTE 4: The mechanisms for selection of PSAP addresses are outside the scope of this specification. See note 1.

NOTE 5: The body of the received request can include a PIDF location object and SDP.

5.12.3 Subscription and notification

5.12.3.1 Notification about dialog state

Based on operator policy, the LRF can either subscribe to all dialog information on an E-CSCF or individually subscribe to each dialog as it receives the requests.

NOTE 1: Subscription to dialog information is dependent on the use of Le interface as described in subclause 5.12.2.

In the case that the LRF is subscribing to all dialogs at the E-CSCF, the LRF shall generate a SUBSCRIBE request to the dialog state event package in accordance with RFC 6665 [28] and RFC 4235 [171]. The LRF shall include the following additional information in the SUBSCRIBE request:

a) the Request-URI set to an E-CSCF address;

NOTE 2: In this case, it is expected that the LRF will be configured with a set of E-CSCF addresses, and the LRF will subscribe to all of them.

b) no header field parameters in the Event header field;

c) an Expires header field set to 600 000 seconds; and

d) a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The LRF shall not include the type 3 "term-ioi" header field parameter.

Upon generation of a 300 response to an incoming dialog forming request that contains a reference identifier, and in the case that the LRF is subscribing to individual dialogs at the E-CSCF, the LRF shall generate a SUBSCRIBE request to the dialog state event package in accordance with RFC 6665 [28] and RFC 4235 [171]. The LRF shall include the following additional information in the SUBSCRIBE request:

a) the Request-URI set to the value of the P-Asserted-Identity in the original request to which the response was generated;

b) a Route header field that addresses the request to the E-CSCF. How such a value is determined depends on deployment;

NOTE 3: A number of mechanisms exist for identifying the required E-CSCF, however all suffer some restrictions. It is therefore a matter of configuration at deployment time to identify the solution that works for that particular deployment. Mechanisms that exist include:

i) if there is only one E-CSCF in the network, using the address of that E-CSCF preconfigured into the system;

ii) using the last entry in the Via header field of the original request to which the 3xx response was generated. If the deployment however includes some intermediate SIP proxy or B2BUA not otherwise included in the emergency call architecture this will not provide the desired result; or

iii) using the IP address from which the original request was received to which the 3xx response was generated. The request is sent to the same port number and IP address as the 3xx response was generated. If the deployment however includes some intermediate SIP proxy or B2BUA not otherwise included in the emergency call architecture this will not provide the desired result, and additionally, if the system is set up to use port numbers in a unidirectional manner, i.e. one port number for requests and another port number for responses, it will also not operate correctly.

c) the "call-id" and "to-tag" header field parameters in the Event header field set to the values in the original request to which the 3xx response was generated. No "from-tag" header field parameter can be included as it is not known by the LRF;

d) an Expires header field set to 86400 seconds; and

e) a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The LRF shall not include the type 3 "term-ioi" header field parameter.

In the case that the LRF is subscribing to individual dialogs at the E-CSCF, and a NOTIFY request is received indicating a state of "terminated", the LRF shall end the subscription to the dialog event package.

NOTE 4: Such NOTIFY requests will normally be accompanied by the Subscription-State header field set to the value of "terminated".

When, as a result of successful subscription to the dialog event package, the LRF receives a notification containing dialog updates, the LRF shall update its record for each dialog included in the event package information.

5.12.3.2 Notification about UE location

Based on operator policy, the LRF can subscribe to UE location as it receives the requests.

Upon generation of a 300 response to an incoming dialog forming request that contains a reference identifier, the LRF shall generate a SUBSCRIBE request to the presence event package in accordance with RFC 6665 [28] and RFC 3856 [74]. The LRF shall include the following additional information in the SUBSCRIBE request:

a) the Request-URI set to an E-CSCF address;

b) a Target-Dialog header field with the callid portion and the "remote-tag" header field parameter set to the values in the original request to which the 3xx response was generated. No "local-tag" header field parameter can be included as it is not known by the LRF;

c) an Expires header field set to 86400 seconds or to 0 seconds; and

When, as a result of successful subscription to the presence event package, the LRF receives a notification containing the UE location, the LRF shall update its record for the dialog indicated in the Target-Dialog header field of the SUBSCRIBE request.