6 Location management procedures

24.5453GPPLocation managementProtocol specificationRelease 17Service Enabler Architecture Layer (SEAL)TS

6.1 General

6.2 On-network procedures

6.2.1 General

6.2.1.1 Authenticated identity in HTTP request

Upon receiving an HTTP request, the SLM-S shall authenticate the identity of the sender of the HTTP request is authorized as specified in 3GPP TS 24.547 [6], and if authentication is successful, the SLM-S shall use the identity of the sender of the HTTP request as an authenticated identity.

6.2.2 Event-triggered location reporting procedure

6.2.2.1 General

The SLM-C sends a location reporting configuration request when it needs to fetch location reporting configuration from the SLM-S.

The SLM-C sends a location report when at least one of the trigger criteria is fulfilled. To send the location report the SLM-C can use an appropriate HTTP request message.

If a location reporting trigger is met, the SLM-C checks if the minimum-report-interval timer is running. If the timer is running, the SLM-C waits until the timer expires. When the minimum-report-interval timer expires, the SLM-C:

a) shall send a location information report as specified in clause 6.2.2.2, if any of the reporting triggers are still met.

6.2.2.2 Client procedure

6.2.2.2.1 Fetching location reporting configuration

In order to fetch location reporting configuration, the SLM-C shall send an HTTP GET request message according to procedures specified in IETF RFC 7231 [16]. In the HTTP GET request message, the SLM-C:

a) shall set the Request-URI to the URI identifying the XML document to be fetched. In the Request-URI;

1) the "auid" is set to specific VAL service identity; and

2) the document selector is set to a document URI pointing to the location reporting configuration document; and

b) shall include an Authorization header field with the "Bearer" authentication scheme set to an access token of the "bearer" token type as specified in IETF RFC 6750 [13].

Upon receiving an HTTP 200 (OK) response from the SLM-S containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <configuration> element included in the <location-info> root element;

the SLM-C:

a) shall store the content of the <configuration> elements;

b) shall set the location reporting triggers accordingly; and

c) shall start the minimum-report-interval timer.

6.2.2.2.2 Location reporting

In order to report the location information, the SLM-C shall send an HTTP POST request message according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request message, the SLM-C:

a) shall set the Request-URI to the URI included in the received HTTP response message for location report configuration;

b) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user for location report; and

2) shall include a <report> element and, if the report was triggered by a location request, include the <report-id> attribute set to the value of the <request-id> attribute in the received request. The <report> element:

i) shall include a <trigger-id> child element set to the value of each <trigger-id> value of the triggers that have been met; and

ii) shall include the location reporting elements corresponding to the triggers that have been met;

d) shall set the minimum-report-interval timer to the minimum-report-interval time and start this timer; and

e) shall reset all the trigger criteria for location reporting.

6.2.2.3 Server procedure

6.2.2.3.1 Fetching location reporting configuration

Upon receiving of an HTTP GET request where the Request-URI of the HTTP GET request identifies a location reporting configuration document as specified in the specific vertical application, the SLM-S:

a) shall determine the identity of the sender of the received HTTP GET request as specified in clause 6.2.1.1, and:

1) if the identity of the sender of the received HTTP GET request is not authorized to fetch requested configuration document, shall respond with a HTTP 403 (Forbidden) response to the HTTP GET request and skip rest of the steps;

b) shall support handling an HTTP GET request from a SLM-C according to procedures specified in IETF RFC 4825 [9] "GET Handling".

c) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [16]. In the HTTP 200 (OK) response message, the SLM-S:

1) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

2) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

i) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user requesting for location reporting configuration;

ii) shall include a <configuration> element which shall include at least one of the followings:

A) the location reporting elements which are requested;

B) a <triggering-criteria> child element which provides the triggers for the SLM-C to request a location report as described in clause 7; and

C) a <minimum-interval-length>child element specifying the minimum time between consecutive reports. The value is given in seconds;

3) shall include the <trigger-id> attribute where defined for the sub-elements defining the trigger criterion; and

d) shall send the HTTP 200 (OK) response towards the SLM-C.

6.2.2.3.2 Location reporting

Upon reception of an HTTP POST request message containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <report> element included in the <location-info> root element;

where the Request-URI of the HTTP POST request identifies an element of a XML document as specified in application usage of the specific vertical application, the SLM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1; and

1) if the identity of the sender of the received HTTP POST request is not authorized to obtain location information of another VAL user, shall respond with a HTTP 403 (Forbidden) response to the HTTP POST request and shall skip rest of the steps; and

2) shall support handling an HTTP POST request from a SLM-C according to procedures specified in IETF RFC 4825 [9] where the Request-URI of the HTTP POST request identifies an element of XML document as specified in application usage of the specific vertical application. The SLM-S:

i) shall store the received location information of the reporting SLM-C; and

ii) shall use the location information as needed.

NOTE: The <report> element contains the event triggering identity in the location information report from the VAL client, and can contain location information.

6.2.3 On-demand location reporting procedure

6.2.3.1 Client procedure

Upon receiving an HTTP POST request containing:

a) an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

b) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) an application/vnd.3gpp.seal-location-info+xml MIME body with a <request> element included in the <location-info> root element;

the SLM-C:

a) may send a location report as specified in clause 6.2.2.2.2.

6.2.3.2 Server procedure

If the SLM-S needs to request the SLM-C to report its location, the SLM-S shall generate an HTTP POST request according to procedures specified in IETF RFC 7231 [16]. The SLM-S:

a) shall include a Request-URI set to the URI corresponding to the identity of the SLM-C;

b) shall include an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

d) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include a <requested-identity> element with a <VAL-user-id> child element set to the identity of the VAL user whose location is requested;

2) shall include a <request> element; and

e) shall send the HTTP POST request as specified in IETF RFC 7231 [16].

6.2.4 Client-triggered or VAL server-triggered location reporting procedure

6.2.4.1 Client procedure

Upon receiving a request from a VAL user to obtain the location information of another VAL user or to update the location reporting trigger, the SLM-C shall send an HTTP POST request according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request, the SLM-C:

a) shall set the Request-URI to the URI included in the received HTTP response message for location report configuration;

b) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user which requests the location report;

2) shall include a <requested-identity> element with a <VAL-user-id> child element set to the identity of the VAL user for which a location report is requested. The VAL user should belong to the same VAL service as the identity of the VAL user which requests the location report; and

3) a <report-request> element which shall include at least one of the followings:

i) an <immediate-report-indicator> child element to indicate that an immediate location report is required;

ii) the location reporting elements which are requested;

iii) a <triggering-criteria> child element which indicate a specified location trigger criteria to send the location report;

iv) a <minimum-interval-length>child element specifying the minimum time between consecutive reports. The value is given in seconds; and

v) if an <immediate-report-indicator> element is set to required, an <endpoint-info> child element set to the information of the endpoint of the requesting VAL server to which the location report notification has to be sent.

Upon reception of an HTTP POST request message containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <report> element included in the <location-info> root element;

where the Request-URI of the HTTP POST request identifies an element of a XML document as specified in application usage of the specific vertical application, the SLM-C shall follow the procedure as specified in clause 6.2.2.3.2.

6.2.4.2 Server procedure

Upon reception of an HTTP POST request where the Request-URI of the HTTP POST request identifies an element of a XML document as specified in application usage of the specific vertical application, the SLM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1 and;

1) if the identity of the sender of the received HTTP POST request is not authorized to obtain location information of another VAL user, shall respond with a HTTP 403 (Forbidden) response to the HTTP POST request and shall skip rest of the steps; and

2) shall support handling an HTTP POST request from a SLM-C according to procedures specified in IETF RFC 4825 [9] where the Request-URI of the HTTP POST request identifies an element of XML document as specified in application usage of the specific vertical application. Depending on the information specified by the HTTP POST request, the SLM-S initiates either an event-triggered location reporting procedure as specified in clause 6.2.2.2 or an on-demand location reporting procedure as specified in clause 6.2.2.3 for providing the SLM-C with the location of the requested VAL user; and

b) For on-demand location report request, upon receiving the location information of the SLM-C, the SLM-S sends location report to the requesting SLM-C or VAL server as specified in clause 6.2.2.2.

6.2.5 Location reporting triggers configuration cancel procedure

6.2.5.1 Client procedure

Upon receiving an HTTP POST request containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <configuration> element included in the <location-info> root element, which has none of child elements;

the SLM-C:

a) shall delete the content of the <configuration> elements;

b) shall stop the location reporting; and

c) shall generate an HTTP 200 (OK) response to the received HTTP POST request message according to IETF RFC 7231 [16] and shall send it towards SLM-S.

6.2.5.2 Server procedure

Upon receiving an HTTP POST request containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <configuration> element included in the <location-info> root element, which has none of child elements;

the SLM-S:

a) shall include a Request-URI set to the URI corresponding to the identity of the SLM-C;

b) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user for location reporting event triggers configuration cancellation;

2) shall include a <configuration> element which shall not include any child element; and

d) shall send the HTTP POST request as specified in IETF RFC 7231 [16].

Upon receiving response from the SLM-C, the SLM-S shall generate an HTTP 200 (OK) response to the received HTTP POST request message according to IETF RFC 7231 [16] and shall send it towards VAL server.

6.2.5.3 VAL Server procedure

The VAL Server (or authorized VAL user) may cancel the location reporting triggers configuration for the SLM-C by generatiing an HTTP POST request message according to procedures specified in IETF RFC 7231 [16]. The VAL server:

a) shall include a Request-URI set to the URI corresponding to the identity of the SLM-S;

b) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include a <VAL-user-id> element set to the identity of the VAL user for location reporting event triggers configuration cancellation;

2) shall include a <configuration> element which shall not include any child element; and

d) shall send the HTTP POST request as specified in IETF RFC 7231 [16].

6.2.6 Location information subscription procedure

The VAL service will use the same identity which has been authenticated by VAL service with SIP core using SIP based REGISTER message. If VAL service do not support SIP protocol, then HTTP based method needs to be used.

6.2.6.1 VAL server procedure

6.2.6.1.1 SIP based procedure

6.2.6.1.1.1 Create subscription

In order to subscribe location information of one or more VAL users or VAL UEs, if VAL server supports SIP, the VAL server shall generate an initial SIP MESSAGE request according to 3GPP TS 24.229 [5] and IETF RFC 3428 [14]. In the SIP MESSAGE request, the VAL server:

a) shall set the Request-URI to the public service identity identifying the originating SLM-S serving the VAL server;

b) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.seal" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [10];

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element;

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL server which requests the location information subscription;

2) shall include a <subscription> element which shall include:

i) an <identities-list> element with one or more <VAL-user-id> child elements set to the identities of the VAL users whose location information is requested;

ii) a <time-interval-length> element specifying the time between consecutive reports. The value is given in seonds; and

iii) an <expiry-time> element specifying the time when the VAL server wants to receive the current status and later notification; and

d) shall send the SIP MESSAGE request towards the SLM-S according to 3GPP TS 24.229 [5].

Upon receiving a SIP MESSAGE with an application/vnd.3gpp.seal-location-info+xml MIME body, the VAL server:

a) shall store the Subcription expiry value set in <expiry-time> element; and

b) may start subscription refresh timer and set expiry time for the subscription refresh timer to the 2/3 of Subcription expiry value.

NOTE: It is upto implementation to refressh subscribe upon expiry of subscription refresh timer.

6.2.6.1.1.2 Deleting subscription

In order to delete the subscription as identified by the subscription identifier, the VAL server:

a) shall generate a SIP MESSAGE request according to 3GPP TS 24.229 [5] and IETF RFC 3428 [14];

b) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element, the VAL server:

1) a <subscription-identifier> element set to the subscription identifier value which uniqly identified the subscription; and

2) set an <expiry-time> element to zero;

c) shall send the SIP MESSAGE request towards the SLM-S according to 3GPP TS 24.229 [5].

Upon receiving a SIP MESSAGE with an application/vnd.3gpp.seal-location-info+xml MIME body containing <subscription-identifier> element along with <expiry-time> element set to zero, the VAL server:

a) shall delete the subscription related data.

6.2.6.1.2 HTTP based procedure
6.2.6.1.2.1 Create subscription

If VAL server does not support SIP, the VAL server shall send an HTTP POST request to the SLM-S according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request message, the VAL server:

a) shall include a Request-URI set to the URI corresponding to the identity of the SLM-S;

b) shall include an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

d) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element;

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL server which requests the location information subscription; and

2) shall include a <subscription> element as described in clause 6.2.6.1.1.1; and

e) shall send the HTTP POST request towards the SLM-S as specified in IETF RFC 7231 [16].

Upon receiving an HTTP POST request with an application/vnd.3gpp.seal-location-info+xml MIME body, the VAL server:

a) shall store the Subcription expiry value set in <expiry-time> element; and

b) may start subscription refresh timer and set expiry time for the subscription refresh timer to the 2/3 of Subcription expiry value.

NOTE: It is upto implementation to refressh subscribe upon expiry of subscription refresh timer.

6.2.6.1.2.2 Delete subscription

In order to delete the subscription as identified by the subscription identifier, the VAL server shall generate an HTTP POST request according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request message, the VAL server:

a) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include a <subscription-identifier> element set to the subscription identifier value which uniqly identified the subscription; and

2) shall include an <expiry-time> element set to zero;

b) shall send the HTTP POST request towards the SLM-S as specified in IETF RFC 7231 [16].

Upon receiving an HTTP POST with an application/vnd.3gpp.seal-location-info+xml MIME body containing <subscription-identifier> element along with <expiry-time> element set to zero, the VAL server:

a) shall delete the subscription related data.

6.2.6.2 Server procedure

6.2.6.2.1 SIP based procedure

6.2.6.2.1.1 Create subscription

Upon receiving a SIP MESSAGE request such that:

a) Request-URI of the SIP MESSAGE request contains the public service identity identifying the SLM-S of the served VAL server;

b) the ICSI value "urn:urn-7:3gpp-service.ims.icsi.seal" (coded as specified in 3GPP TS 24.229 [5]), in a P-Asserted-Service header field according to IETF RFC 6050 [10]; and

c) the SIP MESSAGE request contains an application/vnd.3gpp.seal-location-info+xml MIME body with an <subscription> element included in the <location-info> root element;

the SLM-S:

a) shall identify the served VAL user ID in the <identity> element of the application/ vnd.3gpp.seal-location-info+xml MIME body of the SIP MESSAGE request;

b) if the Request-URI of the SIP MESSAGE request contains the public service identity identifying the SLM-S serving the VAL server, shall identify the originating VAL user ID from public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

c) if the originating VAL user ID is different than the served VAL user ID, shall send a 403 (Forbidden) response and shall not continue with the rest of the steps; and

d) shall generate a 200 (OK) response to the SIP MESSAGE request according to 3GPP TS 24.229 [5] and send it towards VAL server.

e) shall store all users information contained in <VAL-user-id> element of <identities-list> element;

f) shall store the expiry time for the subscription to the <expiry-time> value; if the expiry time value as present in <expiry-time> element is not acceptable to the SLM-S, the SLM-S may change the expiry time value to a lower value;

g) shall store the time interval value to the <time-interval-length> element;

h) shall generate and assign a unique integer as subscription identifier to the subscription request received from VAL server;

i) shall generate a SIP MESSAGE request according to 3GPP TS 24.229 [5] and IETF RFC 3428 [14].

j) In the SIP MESSAGE, the SLM-S shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element;

1) shall include a <subscription> element which shall include:

i) a <subscription-identifier> element set to the unique subscription identifier which is assigned to the subscription request;

ii) an <expiry-time> element set to the accepted expiry time value; and

iii) if the VAL users whose location information is requested as present in <identities-list> element is not fully acceptable to the SLM-S, the SLM-S may change the VAL users to a subset and shall include an <identities-list> with one or more <VAL-user-id> child elements set to the identities of the new VAL users;

k) shall send the SIP MESSAGE request towards the VAL server according to 3GPP TS 24.229 [5]; and

l) shall start the timer TLM-1 (subscription expiry) and set the expiry time of the timer to the expiry time for the subscription.

m) shall start the timer TLM-2 (notification interval) timer and set the internal time of the timer to the <time-interval-length> element value.

6.2.6.2.1.2 Delete subscription

Upon receiving a SIP MESSAGE with an application/vnd.3gpp.seal-location-info+xml MIME body containing <subscription-identifier> element along with <expiry-time> element set to zero, the SLM-S:

a) shall generate a SIP 200 (OK) response and send it towards VAL server;

b) shall delete all information related to subscription;

c) shall generate a SIP MESSAGE request according to 3GPP TS 24.229 [5] and IETF RFC 3428 [14].

d) In the SIP MESSAGE, the SLM-S shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element;

1) shall include a <subscription> element which shall include:

i) a <Subscription Identifier> element set to the unique subscription identifier which is assigned to the subscription request;

d) shall send the SIP MESSAGE request towards the VAL server according to 3GPP TS 24.229 [5];

e) shall stop TLM-1 (subscription expiry) timer if it is running; and

f) shall stop TLM-2 (notification interval) timer if it is running.

6.2.6.2.1.3 Expiry of TLM-1 (subscription expiry)

On expiry of TLM-1 (subscription expiry) timer, the SLM-S shall consider the subscription terminated and shall inform VAL server about subscription terminated. In order to notify the VAL server about the termination of the subscription, the SLM-S:

a) shall generate a SIP MESSAGE request according to 3GPP TS 24.229 [5] and IETF RFC 6086 [r6086];

b) shall include in the SIP MESSAGE request, an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element, the VAL server:

1) a <subscription-identifier> element set to the subscription identifier value which uniqly identified the subscription; and

2) set an <expiry-time> element to zero;

c) shall send the SIP MESSAGE request towards the VAL server according to 3GPP TS 24.229 [5].

6.2.6.2.1.4 Expiry of TLM-2 (notification interval) timer

On expiry of TLM-2 (notification interval) timer, the SLM-S shall check if any notification is pending to send or not. The SLM-S should follow procedure described in clause 6.2.7.2 to send notification if any pending notifications are present.

6.2.6.2.2 HTTP based procedure

Upon receiving an HTTP POST request containing:

a) an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

b) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) an application/vnd.3gpp.seal-location-info+xml MIME body with a <subscription> element included in the <location-info> root element;

the SLM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1; and

1) if the identity of the sender of the received HTTP POST request is not authorized to subscribe location information of another VAL user or VAL UE, shall respond with a HTTP 403 (Forbidden) response to the HTTP POST request and shall skip rest of the steps; and

2) shall support handling an HTTP POST request from a SLM-C according to procedures specified in IETF RFC 4825 [9] "POST Handling";

b) shall store the expiry time for the subscription to the <expiry-time> value. If the expiry time value as present in <expiry-time> element is not acceptable to the SLM-S, the SLM-S may change the expiry time value to a lower value;

c) shall store the time interval value to the <time-interval-length> element. if the time interval value as present in <time-interval-length> element is not acceptable to the SLM-S, the SLM-S may change the time interval value to a lower value;

d) shall generate and assign a unique integer as subscription identifier to the subscription request received from VAL server;

e) shall store the users information contained in the <VAL-user-id> elements of <identities-list> element. If the VAL users whose location information is requested as present in <identities-list> element is not fully acceptable to the SLM-S, the SLM-S may change the VAL users to a subset and store the identities of the new VAL users;

f

f) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [16]. In the HTTP 200 (OK) message, the SLM-S:

1) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

i) a <subscription-identifier> element set to the unique subscription identifier which is assigned to the subscription request;

ii) an <expiry-time> element set to the accepted expiry time value; and

iii) if the VAL users whose location information is requested as present in <identities-list> element is not fully acceptable to the SLM-S, the SLM-S may change the VAL users to a subset and shall include an <identities-list> with one or more <VAL-user-id> child elements set to the identities of the new VAL users;

g) shall send the HTTP 200 (OK) message towards the VAL server according to IETF RFC 7231 [16];

h) shall start the timer TLM-1 (subscription expiry) and set the expiry time of the timer to the expiry time for the subscription; and

i) shall start the timer TLM-2 (notification interval) timer and set the internal time of the timer to the <time-interval-length> element value.

Upon receiving an HTTP POST request with an application/vnd.3gpp.seal-location-info+xml MIME body containing <subscription-identifier> element along with <expiry-time> element set to zero, the SLM-S:

a) shall delete all information related to subscription;

b) shall generate an HTTP 200 (OK) message according to IETF RFC 7231 [16]. In the HTTP 200 (OK) message, the SLM-S shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element;

1) shall include a <subscription> element which shall include:

i) a <Subscription Identifier> element set to the unique subscription identifier which is assigned to the subscription request;

d) shall send the HTTP 200 (OK) message towards the VAL server according to IETF RFC 7231 [16];

e) shall stop TLM-1 (subscription expiry) timer if it is running; and

f) shall stop TLM-2 (notification interval) timer if it is running.

6.2.7 Event-triggered location information notification procedure

NOTE: The SLM-C will use the same identity which has been authenticated by VAL service with SIP core using SIP based REGISTER message. If VAL service do not support SIP protocol, then HTTP based method needs to be used.

6.2.7.1 Client procedure

Upon receiving a SIP NOTIFY request containing an application/vnd.3gpp.seal-location-info+xml MIME body with a <notification> element included in the <location-info> root element, or an HTTP POST request message containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <notification> element included in the <location-info> root element;

the SLM-C:

a) shall store the received location information; and

b) may share the information to a group or to another VAL user or VAL UE.

6.2.7.2 Server procedure

In order to nitify the subscriber about the location information report, the SLM-S:

a) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body containing:

1) an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user which subscribed to location of another VAL user or VAL UE; and

2) a <notification> element which shall include:

i) an <identities-list> element with one or more <VAL-user-id> child elements set to the identities of the VAL users whose location information needs to be notified;

ii) a <trigger-id> element set to the value of each <trigger-id> value of the triggers that have been met; and

iii) a <reports> element containing one or more <loc-info-report> elements. The <loc-info-report> shall include:

A) a <VAL-user-id> element set to the identity of the VAL user whose location information needs to be notified; and

B) the latest location information corresponding to the VAL user; and

b) if SLM-C supports SIP, shall send a SIP NOTIFY request according to 3GPP TS 24.229 [5] and IETF RFC 6665 [11] with the constructed application/vnd.3gpp.seal-location-info+xml MIME body;

c) if SLM-C does not support SIP, shall send an HTTP POST request message to the SLM-C according to procedures specified in IETF RFC 7231 [16] with the constructed application/vnd.3gpp.seal-location-info+xml MIME body and an Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml".

6.2.8 On-demand usage of location information procedure

6.2.8.1 VAL server procedure

If the VAL server needs to request UE location information, the VAL server shall send an HTTP POST request to the SLM-S according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request message, the VAL server:

a) shall include a Request-URI set to the URI corresponding to the identity of the SLM-S;

b) shall include an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

c) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

d) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the<location-info> root element:

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL server which requests the location information; and

2) shall include an <identities-list> element with one or more <VAL-user-id> child elements set to the identities of the VAL users whose location information is requested;

Upon receiving an HTTP 200 (OK) response from the SLM-S containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a <reports> element included in the <location-info> root element;

the VAL server:

a) shall store the received location information; and

b) may share the information to a group or to another VAL user or VAL UE.

6.2.8.2 Server procedure

Upon receiving an HTTP POST request containing:

a) an Accept header field set to "application/vnd.3gpp.seal-location-info+xml";

b) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

c) an application/vnd.3gpp.seal-location-info+xml MIME body with an < identities-list > element included in the <location-info> root element;

the SLM-S:

a) shall determine the identity of the sender of the received HTTP POST request as specified in clause 6.2.1.1; and

1) if the identity of the sender of the received HTTP POST request is not authorized to obtain location information of another VAL user, shall respond with a HTTP 403 (Forbidden) response to the HTTP POST request and shall skip rest of the steps; and

b) shall support handling an HTTP POST request from a SLM-C according to procedures specified in IETF RFC 4825 [9] "POST Handling";

c) shall generate an HTTP 200 (OK) response according to IETF RFC 7231 [16]. In the HTTP 200 (OK) response message, the SLM-S:

1) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml";

2) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

i) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the VAL user for location reporting configuration;

ii) an <identities-list> element with one or more <VAL-user-id> child elements set to the identities of the VAL users whose location information is requested;

iii) a <reports> element containing one or more <loc-info-report> elements. The <loc-info-report> contains a <VAL-user-id> element set to the identity of the VAL user in the requested-identity-list and the latest location information corresponding to the VAL user; and

d) shall send an HTTP 200 (OK) response towards the VAL server.

6.2.9 Query list of users based on location

6.2.9.1 Client procedure

The procedure defined in this clause can be used by SEAL server to query list of users based on given geolocation area.

In order to query the list of users based on given geolocation area, the client shall send an HTTP POST request message according to procedures specified in IETF RFC 7231 [16]. In the HTTP POST request message, the SLM-C:

a) shall set the Request-URI to the URI corresponding to the identity of the SEAL server;

b) shall include a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

c) shall include an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include an <identity> element with a <VAL-user-id> child element set to the identity of the SEAL server querying list of users; and

2) shall include an <location-based-query> element with a <polygon-area> child element or an <ellipsoid-arc-area> child element.

6.2.9.2 Server procedure

Upon reception of an HTTP POST request containing:

a) a Content-Type header field set to "application/vnd.3gpp.seal-location-info+xml"; and

b) an application/vnd.3gpp.seal-location-info+xml MIME body with a < location-based-query> element included in the <location-info> root element;

the SLM-S:

a) shall authorize the identity of the sender of the received HTTP POST request; and

1) if the identity of the sender of the received HTTP POST request is not authorized to obtain list of users based on given geolocation area, shall respond with a HTTP 403 (Forbidden) response to the HTTP POST request and shall skip rest of the steps;

b) shall generate the list of users who are currently available in requested geographical area; and

c) shall send an HTTP 200 (OK) response message to SLM-C. In the HTTP 200 (OK) response message, the SLM-S:

1) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body containing:

i) an <identity> element with a <VAL-user-id> child element set to the identity of the SEAL server querying list of users; and

ii) a <location-based-response> element which shall include:

A) an <identities-list> element with one or more <VAL-user-id> child elements set to the identities of the VAL users to be queried;

6.3 Off-network procedures

6.3.1 General

6.3.1.1 SEAL Off-network Location Management message transport

In order to send the request, response or acknowledgement, the SEAL location management client:

1) shall send the message as a UDP message to the local IP address of the VAL user, to UDP port XXX, with an IP time-to-live set to 255; and

2) shall treat UDP messages received on the port TBD as received messages.

The SEAL Off-network Location Management message is the entire payload of the UDP message.

Editor’s note: The exact UDP port number on which the message is sent, is FFS.

6.3.1.2 Basic Message Control

6.3.1.2.1 General

The figure 6.3.1.2.1-1 gives an overview of the main states and transitions on the UE for sending a SEAL Off-network Location Management message.

Figure 6.3.1.2.1-1: Basic state machine to send SEAL Off-network Location Management message

6.3.1.2.2 State: Start

This state exists for the SLM-C, when the SLM-C decides the SEAL Off-network Location Management message.

6.3.1.2.2.1 Send Message (With Ack/Response expected)

When SLM-C sends a SEAL Off-network Location Management message for which response or acknowledgement from the target UE is expected, the SLM-C:

a) shall set counter C101 to the value 1;

b) shall start the timer T101 (waiting for ack/resp);

c) shall send the message to the target UE; and

d) shall enter the state "Waiting for Ack/Resp".

Editor’s note: The definition of the timer T101 (waiting for ack/resp) and the counter C101 is FFS.

6.3.1.2.3 State: Waiting for Ack/Resp

This state exists for the SLM-C, when the SLM-C has already sent the SEAL Off-network Location Management message, and waiting to receive which response or acknowledgement.

6.3.1.2.3.1 Timer T101 Expired

Upon expiry of the timer T101 where current value of the counter C101 is less than N, the SLM-C:

a) shall increment the value of the counter C101 by 1;

b) shall restart the timer T101 (waiting for ack/resp);

c) shall send the message to the target UE; and

d) shall remain in the state "Waiting for Ack/Resp".

6.3.1.2.3.2 Timer T101 Expired (N times)

Upon expiry of the timer T101 where current value of the counter C101 is greater than or equal to N, the SLM-C:

a) shall consider the message sending as failure;

b) shall stop the timer T101 (waiting for ack/resp);

c) shall inform the VAL user about the failure of the message; and

d) shall enter the state "Stop".

6.3.1.2.3.2 Acknowledgement Received or Response Received

Upon receiving response of the message or acknowledgement of the message, the SLM-C:

a) shall stop the timer T101 (waiting for ack/resp);

b) shall enter the state "Stop"; and

c) shall inform the VAL user about the success of the message.

6.3.1.2.4 State: Stop

This state exists for the SLM-C, when the procedure to send the SEAL Off-network Location Management message is completed, and no further response or acknowledgement is expected.

6.3.1.3 Sending acknowledgement

The SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2 by setting:

i) the Message type IE to "LOCATION MANAGEMENT ACK";

ii) the Originating VAL user ID IE to its own VAL user ID;

iii) the Terminating VAL user ID IE to the VAL user ID of the target VAL user;

iv) the Message I D IE to the value of the Message ID of the received message; and

b) shall send the message as specified in clause 6.3.1.2.

6.3.2 Event-triggered location reporting procedure

6.3.2.1 Location reporting trigger configuration

6.3.2.1.1 Client originating procedure

Upon receiving a request from a VAL user to configure the location information trigger to another VAL user, the SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2. In the Off-network location management message:

i) shall set the Message type IE to "LOCATION REPORTING TRIGGER CONFIGURATION REQUEST";

ii) shall set the Originating VAL user ID IE to its own VAL user ID;

iii) shall set the Terminating VAL user ID IE to the VAL user ID of the target VAL user;

iv) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element including a <configuration> element with at least one of the followings:

1) the location reporting elements which are requested;

2) a <triggering-criteria> child element which indicate a specified location trigger criteria to send the location report; or

3) a <minimum-interval-length>child element specifying the minimum time between consecutive reports. The value is given in seconds; and

v) shall set the Location Management Data IE to the application/vnd.3gpp.seal-location-info+xml MIME body; and

vi) shall set the Message ID IE to the unique identity of this message; and

b) shall send the message as specified in clause 6.3.1.2.

Upon reception of Off-network location management message containing a Message type IE set to "LOCATION REPORTING TRIGGER CONFIGURATION RESPONSE", the SLM-C shall send the acknowledgement message as specified in clause 6.3.1.3.

6.3.2.1.2 Client terminating procedure

Upon reception of Off-network location management message containing a Message type IE set to "LOCATION REPORTING TRIGGER CONFIGURATION REQUEST", the SLM-C:

a) shall store the content of the <configuration> elements;

b) shall set the location reporting triggers accordingly;

c) shall start the minimum-report-interval timer;

d) shall generate the Off-network location management message according to clause 8.1.2 by setting:

i) the Message type IE to "LOCATION REPORTING TRIGGER CONFIGURATION RESPONSE";

ii) the Originating VAL user ID IE to its own VAL user ID; and

iii) the Terminating VAL user ID IE to the VAL user ID of the originating VAL user;

iv) the Message ID IE to the unique identity of this message; and

v) the Reply-to message ID IE to the value of the Message ID of the received message; and

e) shall send the message as specified in clause 6.3.1.2.

6.3.2.2 Location reporting

6.3.2.2.1 Client originating procedure

In order to report the location information, the SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2. In the Off-network location management message:

i) shall set the Message type IE to "LOCATION REPORT";

ii) shall set the Originating VAL user ID IE to its own VAL user ID;

iii) shall set the Terminating VAL user ID IE to the VAL user ID of the target VAL user;

iv) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include a <report> element and, in the <report> element:

A) shall include a <trigger-id> child element set to the value of each <trigger-id> value of the triggers that have been met; and

B) shall include the location reporting elements corresponding to the triggers that have been met; and

2) if the report was triggered by a location request, include the <report-id> attribute set to the value of the <request-id> attribute in the received request; and

v) shall set the Location Management Data IE to the application/vnd.3gpp.seal-location-info+xml MIME body; and

vi) shall set the Message ID IE to the unique identity of this message;

b) shall send the message as specified in clause 6.3.1.2;

c) shall set the minimum-report-interval timer to the minimum-report-interval time and start this timer; and

d) shall reset all the trigger criteria for location reporting.

6.3.2.2.2 Client terminating procedure

Upon reception of Off-network location management message containing a Message type IE set to "LOCATION REPORT", the SLM-C:

a) shall acknowledged by the acknowledgement message as specified in clause 6.3.1.3.

b) shall store the received location information of the reporting SLM-C; and

c) shall use the location information as needed.

6.3.2.3 Location reporting trigger cancel

6.3.2.3.1 Client originating procedure

Upon receiving a request from a VAL user to cancel the location information trigger to another VAL user, the SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2. In the Off-network location management message:

i) shall set the Message type IE to "LOCATION REPORTING TRIGGER CANCEL REQUEST";

ii) shall set the Originating VAL user ID IE to its own VAL user ID;

iii) shall set the Terminating VAL user ID IE to the VAL user ID of the target VAL user;

iv) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element including a <configuration> element which shall not include any child element;:

v) shall set the Location Management Data IE to the application/vnd.3gpp.seal-location-info+xml MIME body; and

vi) shall set the Message ID IE to the unique identity of this message; and

b) shall send the message as specified in clause 6.3.1.2.

Upon reception of Off-network location management message containing a Message type IE set to "LOCATION REPORTING TRIGGER CANCEL RESPONSE", the SLM-C shall acknowledge the acknowledgement message as specified in clause 6.3.1.3.

6.3.2.3.2 Client terminating procedure

Upon reception of Off-network location management message containing a Message type IE set to "LOCATION REPORTING TRIGGER CANCEL REQUEST", the SLM-C:

a) shall delete the content of the <configuration> elements;

b) shall stop the location reporting;

d) shall generate the Off-network location management message according to clause 8.1.2 by setting:

i) the Message type IE to "LOCATION REPORTING TRIGGER CANCEL RESPONSE";

ii) the Originating VAL user ID IE to its own VAL user ID;

iii) the Terminating VAL user ID IE to the VAL user ID of the originating VAL user;

iv) the Message ID IE to the unique identity of this message; and

v) the Reply-to message ID IE to the value of the Message ID of the received message; and

e) shall send the message as specified in clause 6.3.1.2.

6.3.3 On-demand location reporting

6.3.3.1 Client originating procedure

Upon receiving a request from a VAL user to request the location information from another VAL user, the SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2. In the Off-network location management message:

i) shall set the Message type IE to "LOCATION REQUEST (ON-DEMAND)";

ii) shall set the Originating VAL user ID IE to its own VAL user ID;

iii) shall set the Terminating VAL user ID IE to the VAL user ID of the target VAL user;

iv) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element shall include a <report-request> element which shall include at least one of the followings:

1) an <immediate-report-indicator> child element to indicate that an immediate location report is required; and

2) the location reporting elements which are requested;

v) shall set the Location Management Data IE to the application/vnd.3gpp.seal-location-info+xml MIME body;

vi) shall set the Message ID IE to the unique identity of this message; and

b) shall send the message as specified in clause 6.3.1.2.

Upon reception of Off-network location management message containing a Message type IE set to "ON-DEMAND LOCATION RESPONSE", the SLM-C shall send the acknowledgement message as specified in clause 6.3.1.3.

6.3.3.2 Client terminating procedure

Upon reception of Off-network location management message containing a Message type IE set to "ON-DEMAND LOCATION REQUEST", the SLM-C:

a) shall generate the Off-network location management message according to clause 8.1.2. In the Off-network location management message:

i) shall set the Message type IE to "LOCATION RESPONSE (ON-DEMAND)";

ii) shall set the Originating VAL user ID IE to its own VAL user ID;

iii) shall set the Terminating VAL user ID IE to the VAL user ID of the originating VAL user;

iv) shall generate an application/vnd.3gpp.seal-location-info+xml MIME body and in the <location-info> root element:

1) shall include a <report> element and, if the report was triggered by a location request, include the <report-id> attribute set to the value of the <request-id> attribute in the received request. The <report> element:

A) shall include a <trigger-id> child element set to the value of each <trigger-id> value of the triggers that have been met; and

B) shall include the location reporting elements corresponding to the triggers that have been met; and

v) shall set the Location Management Data IE to the application/vnd.3gpp.seal-location-info+xml MIME body;

vi) shall set the Message ID IE to the unique identity of this message; and

vii) shall set the Reply-to message ID IE to the value of the Message ID of the received message; and

b) shall send the message as specified in clause 6.3.1.2.