6 Location management procedures

24.5453GPPLocation Management - Service Enabler Architecture Layer for Verticals (SEAL)Protocol specificationRelease 17TS

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

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.1.2 Boot up procedure

Upon device boot up, the SLM-C in the UE shall send HTTP POST message to SLM-S containing the call back URI (where the SLM-S can send request message to SLM-C) in a JavaScript Object Notation (JSON) structure as specified in IETF RFC 7159 [19].

6.2.1.3 Authenticated identity in CoAP request

Upon receiving an CoAP request, the SLM-S shall authenticate the identity of the sender of the CoAP request 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 CoAP 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 or CoAP 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 for HTTP and in 6.2.2.4 for CoAP if any of the reporting triggers are still met.

6.2.2.2 SLM client HTTP 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 SLM server HTTP 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

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.2.4 SLM client CoAP procedure

6.2.2.4.1 Fetching location reporting configuration

In order to fetch trigger configuration, the SLM-C shall send a CoAP GET request message to the SLM-S according to procedures specified in IETF RFC 7252 [21]. In the CoAP GET request, the SLM-C:

a) shall set the CoAP URI identifying the trigger configuration to be fetched according to the resource definition in Annex B.3.1.2.2;

1) the "apiRoot" is set to the SLM-S URI;

2) the "valServiceId" is set to specific VAL service; and

3) the "val-tgt-ue" query option is set to either the VAL user identity or VAL UE identity for which the trigger configuration is applicable;

b) shall include an Accept option set to "application/vnd.3gpp.seal-location-configuration+cbor"; and

c) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

Upon receiving a CoAP 2.05 (Content) response from the SLM-S containing:

a) a Content-Format option set to "application/vnd.3gpp.seal-location-configuration+cbor"; and

b) including a "LocationReportConfiguration" object,

the SLM-C:

a) shall store the content of the "LocationReportConfiguration" object;

b) shall set the location reporting triggers accordingly; and

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

6.2.2.4.2 Location reporting

In order to report the location information, the SLM-C shall send a CoAP PUT request message according to procedures specified in IETF RFC 7252 [21]. In the CoAP PUT request message, the SLM-C:

a) shall set the CoAP URI identifying the location report to be sent according to the resource definition in Annex B.3.1.2.3;

1) the "apiRoot" is set to the SLM-S URI; and

2) the "valTgtUe" is set to either the VAL user identity or VAL UE identity for which the location is reported; and

b) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor";

c) shall include a "LocationReport" object:

1) shall include a "triggerIds" attribute set to the value of each trigger ID value of the triggers that have been met; and

2) shall include a "locInfo" object corresponding to the triggers that have been met;

d) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

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

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

6.2.2.5 SLM server CoAP procedre

6.2.2.5.1 Fetching location reporting configuration

Upon receiving of a CoAP GET request where the CoAP URI of the CoAP GET request identifies a trigger configuration as specified in Annex B.3.1.2.2.3.1, the SLM-S:

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

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

b) shall generate a CoAP 2.05 (Content) response according to IETF RFC 7252 [21]. In the CoAP 2.05 (Content) response message, the SLM-S:

1) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-configuration+cbor"; and

2) shall include a "LocationReportConfiguration" object:

i) shall include a "locationType" attribute which is requested; and

ii) shall include at least one of the followings:

A) a "triggeringCriteria" object which provides the triggers for the SLM-C to request a location report; and

B) a "minimum-interval-length" attribute specifying the minimum time between consecutive reports. The value is given in seconds; and

c) shall send the CoAP 2.05 (Content) response towards the SLM-C.

6.2.2.5.2 Location reporting

Upon reception of a CoAP PUT request message where the CoAP URI of the CoAP PUT request identifies a location report as specified in Annex B.3.1.2.3.3.1, and containing:

a) a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor"; and

b) a "LocationReport" object;

the SLM-S:

a) shall determine the identity of the sender of the received CoAP PUT request as specified in clause 6.2.1.2; and

1) if the identity of the sender of the received CoAP PUT request is not authorized to report location information, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP PUT request and shall skip rest of the steps; and

2) shall support handling a CoAP PUT request from a SLM-C:

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

ii) shall use the location information as needed.

NOTE: The "LocationReport" object 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 SLM client HTTP 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 SLM server HTTP 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].

NOTE: Push notification service can be used to send HTTP POST request to the client. Details about the push notification service is out of scope this specification.

6.2.3.3 SLM client CoAP procedure

Upon receiving an CoAP GET request where the CoAP URI of the CoAP GET request identifies the location resource as specified in Annex B.4.1.2.2.3.1, and containing:

a) an Accept option set to "application/vnd.3gpp.seal-location-info+cbor",

the SLM-C shall generate a CoAP 2.05 (Content) response according to IETF RFC 7252 [21]. In the CoAP 2.05 (Content) response message, the SLM-C:

a) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor";

b) shall include a "LocationReport" object:

1) shall include a "locInfo" object containing the location information; and

c) shall send the CoAP 2.05 (Content) response towards the SLM-S.

6.2.3.4 SLM server CoAP procedure

If the SLM-S needs to request the SLM-C to report its location, the SLM-S shall generate a CoAP GET request according to procedures specified in IETF RFC 7252 [21]. The SLM-S:

a) shall set the CoAP URI identifying the location to be retrieved according to the resource definition in Annex B.4.1.2.2.3.1;

1) the "apiRoot" is set to the SLM-C URI;

b) shall include an Accept option set to "application/vnd.3gpp.seal-location-info+cbor"; and

c) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

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

6.2.4.1 SLM client HTTP 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 SLM server HTTP 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;

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.4.3 SLM client CoAP procedure

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

a) if trigger configuration is provided, send a CoAP FETCH request according to procedures specified in IETF RFC 8132 [24] to SLM-S to observe the location information of another VAL user; and

b) otherwise, send a CoAP GET request according to procedure specified in in IETF RFC 7252 [21] to SLM-S to retrieve the location information of another VAL user.

In the CoAP FETCH request, the SLM-C shall:

a) set the CoAP URI identifying the location information to be observed according to the resource definition in Annex B.3.1.2.4.3.1;

1) the "apiRoot" is set to the SLM-S URI;

b) include an Accept option set to "application/vnd.3gpp.seal-location-info+cbor";

c) set an Observe option to 0 (Register);

d) set a Content-Format option set to "application/vnd.3gpp.seal-location-configuration+cbor";

e) include a "LocationReportConfiguration" object:

1) shall include a "valTgtUes" object set to the identity of the observed VAL users;

2) shall include a "locationType" attribute which is requested; and

3) shall include at least one of the following:

i) a "triggeringCriteria" object which provides the triggers for the SLM-C to request a location report as described in Annex X; and

ii) a "minimum-interval-length" attribute specifying the minimum time between consecutive reports. The value is given in seconds; and

f) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

In the CoAP GET request, the SLM-C shall:

a) set the CoAP URI identifying the location information to be fetched according to the resource definition in Annex B.3.1.2.4.3.2;

1) the "apiRoot" is set to the SLM-S URI; and

2) the "val-tgt-ue" query option is set to either the VAL user identity or VAL UE identity for which the location is requested;

b) include an Accept option set to "application/vnd.3gpp.seal-location-info+cbor"; and

c) send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

Upon receiving a CoAP 2.05 (Content) response from the SLM-S containing:

a) a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor"; and

b) including one or more "LocationReport" objects,

the SLM-C:

a) shall store the content of the received "LocationReport" object(s).

6.2.4.4 SLM server CoAP procedure

Upon reception of a CoAP FETCH request message where the CoAP URI of the CoAP FETCH request identifies a location resource as specified in B.3.1.2.4.3.1, and containing:

a) an Accept option set to "application/vnd.3gpp.seal-location-info+cbor";

b) a Content-Format option set to "application/vnd.3gpp.seal-location-configuration+cbor";

c) an Observe option; and

d) a "LocationReportConfiguration" object;

the SLM-S:

a) shall determine the identity of the sender of the received CoAP FETCH request as specified in clause 6.2.1.2; and

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

2) shall generate a series of CoAP 2.05 (Content) response according to IETF RFC 8132 [24]. In the CoAP 2.05 (Content) response message, the SLM-S:

i) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor"; and

ii) shall include one or more "LocationReport" objects corresponding to the triggers that have been met; and

b) shall send the CoAP 2.05 (Content) response towards the SLM-C.

Upon reception of a CoAP GET request message where the CoAP URI of the CoAP GET request identifies a location resource as specified in B.3.1.2.4.3.2, and containing:

a) an Accept option set to "application/vnd.3gpp.seal-location-info+cbor"; and

b) a Content-Format option set to "application/vnd.3gpp.seal-location-configuration+cbor".

the SLM-S:

a) shall determine the identity of the sender of the received CoAP GET request as specified in clause 6.2.1.2; and

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

b) shall generate a CoAP 2.05 (Content) response according to IETF RFC 7252 [21]. In the CoAP 2.05 (Content) response message, the SLM-S:

1) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-info+cbor"; and

2) shall include a "LocationReport" object corresponding to the triggers that have been met; and

c) shall send the CoAP 2.05 (Content) response towards the SLM-C.

6.2.5 Location reporting triggers configuration cancel procedure

6.2.5.1 SLM client HTTP 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 SLM server HTTP 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.5.4 SLM client CoAP procedure

Upon receiving an CoAP DELETE request where the CoAP URI of the CoAP DELETE request identifies a location reporting configuration resource as specified in B.4.1.2.2.3.3, the SLM-C:

a) shall delete the content of the trigger configuration object;

b) shall stop the location reporting; and

c) shall generate a CoAP 2.02 (Deleted) response to the received CoAP DELETE request message according to IETF RFC 7252 [21] and shall send it towards SLM-S.

6.2.5.5 SLM server CoAP procedure

Upon receiving an HTTP POST request containing from VAL server:

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 shall send a CoAP DELETE request message to the SLM-C. In the CoAP DELETE request, the SLM-S:

a) shall set the CoAP URI identifying the trigger configuration to be deleted according to the resource definition in Annex B.4.1.2.2.3.3;

1) the "apiRoot" is set to the SLM-C URI; and

2) "valServiceId" is set to the specific VAL service identity; and

b) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

Upon receiving a 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.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;

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

3) may initiate location reporting configuration with the location management client of the UE for immediate reporting as specified in clause 6.2.3.2; and

4) may subscribe for the location of the UE as specified in clause 4.4.2.2.2 of 3GPP TS 29.122 [17];

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) 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

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 SLM client HTTP or SIP 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 SLM server HTTP or SIP 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.7.3 SLM client CoAP procedure

Upon receiving a CoAP 2.05 (Content) response to a CoAP FETCH request message used to observe a location resource as specified in Annex B.3.1.2.4.3.1, and containing:

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

b) one or more "LocationReport" object,

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.4 SLM server CoAP procedure

In order to notify the subscriber about the location information report, the SLM-S shall send a CoAP 2.05 (Content) response to SLM-C in response to a CoAP FETCH request message used to observe a location resource as specified in Annex B.3.1.2.4.3.1. In the CoAP 2.05 (Content) response, the SLM-S:

a) shall include one or more "LocationReport" objects, each "LocationReport" object containing:

1) "valTgtUe" attribute set to the identity of the VAL user whose location information is notified;

2) "triggerId" attribute set to the value of each "triggerId" value of the triggers that have been met; and

3) "locInfo" attribute set to the location information.

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

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 SLM client HTTP 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 SLM server HTTP 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.2.9.3 SLM client CoAP procedure

In order to query the list of users based on given geolocation area, the SLM-C shall send an CoAP FETCH request message to SLM-S according to procedures specified in IETF RFC 8132 [24]. In the CoAP FETCH request message, the SLM-C:

a) shall set the CoAP URI identifying the UE information to be fetched according to the resource definition in Annex B.3.1.2.5.3.1;

1) the "apiRoot" is set to the SLM-S URI;

b) shall include an Accept option set to "application/vnd.3gpp.seal-location-area-info+cbor";

c) shall include a Content-Format option set to "application/vnd.3gpp.seal-location-area-query+cbor;

d) shall include a "LocationAreaQuery" object including the geolocation area; and

e) shall send the request protected with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [6].

6.2.9.4 SLM server CoAP procedure

Upon reception of an CoAP FETCH request where the CoAP URI of the CoAP GET request identifies a location area information resource as specified in Annex B.3.1.2.5.3.1, and containing:

a) an Accept option set to "application/vnd.3gpp.seal-location-area-info+cbor";

b) a Content-Format option set to "application/vnd.3gpp.seal-location-area-query+cbor"; and

c) a "LocationAreaQuery" object,

the SLM-S:

a) shall authorize the identity of the sender of the received CoAP FETCH request; and

1) if the identity of the sender of the received CoAP FETCH request is not authorized to obtain list of users based on given geolocation area, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP FETCH 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 CoAP 2.05 (Content) response message to SLM-C. In the CoAP 2.05 (Content) response message, the SLM-S:

1) shall generate an "application/vnd.3gpp.seal-location-area-info+cbor" MIME body with a "UeInfos" object containing a "ueList" object with one or more "UeInfo" objects set to the identities of the VAL users and their corresponding locations.

6.2.10 Location area monitoring information procedure

In order to subscribe for monitoring location area, the SLM-C sends subscription requrest as specified in clause 5.2.6 and clause 6 of 3GPP TS 29.549 [18].

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.