6 Network resource management procedures

24.5483GPPNetwork Resource 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 SNRM-S shall authenticate the identity of the sender of the HTTP request is authorized as specified in 3GPP TS 24.547 [9], and if authentication is successful, the SNRM-S shall use the identity of the sender of the HTTP request as an authenticated identity.

6.2.1.2 Authenticated identity in CoAP request

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

6.2.2 Unicast resource management

6.2.2.1 General

This clause describes the procedures used for unicast resource management. The unicast resource management comprises procedures for:

a) activation and deactivation of bearers;

b) modification of the QoS characteristics of a bearer; and

c) modification of GBR due to application requirement.

The VAL client can request the VAL server to provide unicast resources (see clause 6.2.2.2), to modify or to release unicast resources (see clause 6.2.2.3) or to perform network resource adaptation (see clause 6.2.2.4).

NOTE: A VAL service communication can consist of both unicast and multicast bearers which can all need modification due to the same event.

VAL specific pre-requisites and resultant behaviour by functional entities in performing the unicast resource management procedures are specified in the respective VAL TS (e.g. for V2X application layer, see 3GPP TS 24.486 [7]).

Unicast resource management is supported with PCRF interactions with SIP core and PCC interactions with the SNRM-S. The PCRF procedures are specified in 3GPP TS 29.214 [12] and the PCF procedures are specified in 3GPP TS 29.514 [14].

6.2.2.2 Request for unicast resource at VAL service communication establishment procedure with SIP core

6.2.2.2.1 VAL server procedure

If the VAL client requests VAL service communication with the VAL server, the VAL server shall generate an HTTP POST request message according to procedures specified in IETF RFC 7231 [22]. 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 SNRM-S;

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

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

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

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

i) a <requester-identity> element set to the identity of the VAL server performing the request;

ii) an <identity> element set to the identity of the VAL user or VAL UE which requests the VAL service communication; and

iii) an optional <requirement-info> element set to the requested unicast resource information; and

e) shall send the HTTP POST request message towards the SNRM-S according to IETF RFC 7231 [22].

NOTE: Before terminating connection due to no response from the SNRM-S, the VAL server allows sufficient time for the SNRM-S to reserve resources and respond. It is up to implementation to decide how long the VAL server waits for receiving response.

6.2.2.2.2 Server procedure

Upon receiving an HTTP POST request message containing:

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

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

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

the SNRM-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 request unicast resource, 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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall evaluate the need for network resources and use of resource sharing, and then send a SIP MESSAGE request containing request for resources according to procedures specified in 3GPP TS 29.214 [12] for EPS and/or 3GPP TS 29.514 [14] for 5GS.

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, the SNRM-S:

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

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

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

i) shall include a <request-result> element set to "success" indicating success of the resource request operation; andb) shall send the HTTP 200 (OK) response message towards the VAL server according to IETF RFC 7231 [22].

6.2.2.3 Request for modification of unicast resources procedure with SIP core

6.2.2.3.1 VAL server procedure

To modify unicast bearers, the VAL server shall generate an HTTP POST request according to procedures specified in IETF RFC 7231 [22]. 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 SNRM-S;

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

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

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

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

i) a <requester-identity> element set to the identity of the VAL server performing the request;

ii) an <identity> element set to the identity of the VAL user or VAL UE which requests the VAL service communication; and

iii) an <requirement-info> element set to the modified unicast resource information; and

e) shall send the HTTP POST request message towards the VAL server according to IETF RFC 7231 [22].

6.2.2.3.2 Server procedure

Upon receiving an HTTP POST request message containing:

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

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

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

the SNRM-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 modify unicast resource, 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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling";

b) if the media bearer modification is not required, shall generate an HTTP 200 (OK) response message according to IETF RFC 7231 [22]. In the HTTP 200 (OK) response message, the SNRM-S:

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

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

i) shall include a <modification-result> element set to "failure" indicating failure of the resource modification request operation; and

4) shall send the HTTP 200 (OK) response message towards the VAL server according to IETF RFC 7231 [22]; and

c) if the media bearer modification is required, shall send a SIP MESSAGE request containing the modified parameters of the unicast bearer according to procedures specified in 3GPP TS 29.214 [12] for EPS and/or 3GPP TS 29.514 [14] for 5GS.

Upon receiving a SIP 200 (OK) response to the SIP MESSAGE request, the SNRM-S:

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

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

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

i) shall include a <modification-result> element set to "success" indicating success of the resource modification request operation; and

b) shall send the HTTP 200 (OK) response message towards the VAL server according to IETF RFC 7231 [22].

6.2.2.4 Network resource adaptation procedure with SIP core

6.2.2.4.1 VAL server procedure

In order to request unicast resources or modify already allocated unicast resources to VAL communications, the VAL server shall generate an HTTP POST request according to procedures specified in IETF RFC 7231 [22]. 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 SNRM-S;

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

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

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

1) shall include an <adaptation> element which shall include:

i) a <requester-identity> element set to the identity of the VAL server performing the request;

ii) an <identity> element which shall include one of the following elements:

A) a <VAL-ue-id-list> element with one or more <VAL-ue-id> child elements set to the identities of the VAL UEs for whom the network resource adaptation occurs; or

B) a <VAL-group-id> element set to the identity of the VAL group for whom the network resource adaptation occurs; and

iii) a <requirement> element set to the VAL service QoS requirements as applied for the corresponding VAL UEs or group of UEs; and

e) shall send the HTTP POST request message towards the VAL server according to procedures specified in IETF RFC 7231 [22].

6.2.2.4.2 Server procedure

Upon receiving an HTTP POST request message containing:

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

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

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

the SNRM-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 adapt unicast resource, 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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall apply/enforce the resource adaptation per VAL UE, and then initiate the PCC procedures for each VAL UE as described in 3GPP TS 29.214 [12] for EPS and/or 3GPP TS 29.514 [14] for 5GS. After the PCC procedures, the SNRM-S shall generate an HTTP 200 (OK) response message according to IETF RFC 7231 [22]. In the HTTP 200 (OK) response message, the SNRM-S:

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

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

i) shall include an <adaptation-result> element set to "success" or "failure" indicating success or failure of the network resource adaptation with the underlying network; and

4) shall send the HTTP 200 (OK) response message towards the VAL server according to procedures specified in IETF RFC 7231 [22].

6.2.3 Multicast resource management

6.2.3.1 General

6.2.3.2 Use of pre-established MBMS bearers procedure

6.2.3.2.1 VAL server procedure

When a user originates a request for a VAL service group communication session for one of these areas, in order to use the pre-established MBMS bearers, the VAL server shall generate an HTTP POST request according to procedures specified in IETF RFC 7231 [22]. 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 SNRM-S;

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

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

1) shall include an <request> element which shall include:

i) a <requester-identity> element set to the identity of the VAL server performing the request;

ii) a <VAL-group-id> element set to the identity of the VAL group that the MBMS bearer is requested for;

iii) a <service-anouncement-mode> indicating whether the request is sent by NRM server or by the VAL server;

iv) a <QoS> element indicating the requested QoS for the bearer;

v) an optional <broadcast-area> element indicating the area where the MBMS bearer is requested for; and

vi) an <endpoint-info> element set to the information of the endpoint of the VAL server to which the user plane notifications have to be sent; and

d) shall send the HTTP POST request message towards the SNRM-S according to IETF RFC 7231 [22].

6.2.3.2.2 SNRM server HTTP procedure

Upon receiving an HTTP POST request message containing:

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

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

the SNRM-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 request mbms resource, 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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall determine to activate MBMS bearer, and then generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-S:

1) shall set the Request-URI to the URI corresponding to the identity of the SNRM-C;

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

3) shall include in a MIME body with Content-Type header field set to "application/vnd.3gpp.seal-info+xml", the <seal-request-uri> element set to the VAL user ID of the user;

4) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with the <version> element set to "1" and one or more <announcement> elements associated with the pre-activated MBMS bearers in the <mbms-info> root element. Each set of an <announcement> element:

i) shall include a <TMGI> element set to a TMGI value;

NOTE 1: The same TMGI value can only appear in one <announcement> element. The TMGI value is also used to identify the <announcement> when updating or cancelling the <announcement> element.

NOTE 2: The security key active for the general purpose MBMS subchannel on which the mapping (i.e. the Map Group To Bearer message) of media or media control to this MBMS bearer was indicated, is used for MBMS subchannels on this MBMS bearer, unless a different key or an indication of not using encryption is in place.

ii) may include an <alternative-TMGI> element set to a list of additional alternative TMGI used in roaming scenarios;

iii) may include the QCI value in the <QCI> element;

iv) shall include one or more MBMS service area IDs in <mbms-service-area-id> elements in the <mbms-service-areas> element;

NOTE 3: Initial mappings of groups to MBMS subchannels on an MBMS bearer for the purpose of carrying media or media control can occur only where the MBMS service area for this bearer and the MBMS service area for the bearer carrying the general purpose MBMS subchannel on which the Map Group To Bearer message is sent intersect. However, once media or media control were successfully mapped to this bearer, the reception by the SNRM-C can continue (until Unmap Group To Bearer is received or until timeout) throughout the entire MBMS service area of this bearer.

v) if multiple carriers are supported, shall include the frequency to be used in the <frequency> element;

NOTE 4: In the current release if the <frequency> element is included, the frequency in the <frequency> element is the same as the frequency used for unicast.

vi) shall include a <seal-mbms-sdp> element set to the SDP with media and application control information applicable to groups that can use this bearer;

vii) may include a <monitoring-state> element set to "monitoring" or "not-monitoring" used to control if the client is actively monitoring the MBMS bearer quality or not;

viii) may include an <announcement-acknowlegement> element set to "true" or "false" indicating if the NRM server requires an acknowledgement of the MBMS bearer announcement;

ix) may include an <unicast-status> element set to "listening" or "not-listening" indicating if the listening status of the unicast bearer is requested;

x) if the packet headers are compressed with ROHC specified in IETF RFC 5795 [20] in this MBMS bearer, shall include a <seal-mbms-rohc> element; and

5) shall send the HTTP POST request message towards the SNRM-C according to IETF RFC 7231 [22].

Upon receiving an HTTP POST request message containing:

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

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status-report> element;

the SNRM-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 report mbms listening status, 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 SNRM-C according to procedures specified in IETF RFC 4825 [19] "POST Handling";

b) shall generate an HTTP 200 (OK) response message according to the VAL server to IETF RFC 7231 [22]. In the HTTP 200 (OK) response message, the SNRM-S:

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

2) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-bearers> element in the <mbms-info> root element which:

i) shall include a <result> element set to "success" or "failure" indicating success or failure of the MBMS bearers request operation;

ii) may include a <TMGI> element set to a TMGI value;

iii) shall include a <user-plane-address> element set to the BM-SC user plane IP address and port; and

iv) may include a <service-description> element indicating MBMS bearer related configuration information as defined in 3GPP TS 26.346 [10]; and

c) shall send the HTTP 200 (OK) response message towards the VAL server according to IETF RFC 7231 [22].

6.2.3.2.3 SNRM client HTTP procedure

Upon receiving an HTTP POST request message containing:

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

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with one or more <announcement> element(s);

the SNRM-C:

a) shall store the content of the <announcement> elements and generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-C:

1) shall set the Request-URI to the URI corresponding to the identity of the SNRM-S;

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

3) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status-report> subelement which:

i) shall include an <identity> element set to the identity of the VAL user or VAL UE who wants to report the MBMS listening status;

ii) shall include one or more <TMGI> elements for which the listening status applies;

iii) shall include an <mbms-listening-status> element set to "listening" if the SNRM-C is listening to the MBMS bearer or "not-listening" if the SNRM-C is not listening; and

iv) may include an <mbms-reception-quality-level> element set to the reception quality level per TMGI; and

b) shall send the HTTP POST request towards the SNRM-S according to IETF RFC 7231 [22].

6.2.3.2.4 SNRM server CoAP procedure

Upon receiving an HTTP POST request message containing:

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

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

the SNRM-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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall determine to activate MBMS bearer, and then generate a CoAP PUT request according to IETF RFC 7252 [23]. In the CoAP PUT request, the SNRM-S:

1) shall set the CoAP URI to the MBMS Resource Configuration resource URI according to the resource definition in clause A.3.1.2.2.3:

a) the "apiRoot" is set to the SNRM-C URI;

b) the "valServiceId" is set to the identity of the VAL service; and

c) the "tmgi" is set to a TMGI value;

2) shall include Content-Format option set to “application/vnd.3gpp.seal-mbms-config+cbor”;

3) shall include "MbmsResourceConfig" object in the payload:

i) may include an "alternativeTmgis" attribute set to a list of additional alternative TMGIs used in roaming scenarios;

ii) may include the QCI value in the "qci" attribute;

iii) shall include one or more MBMS service area IDs in the "serviceAreas" attribute;

NOTE 1: Initial mappings of groups to MBMS subchannels on an MBMS bearer for the purpose of carrying media or media control can occur only where the MBMS service area for this bearer and the MBMS service area for the bearer carrying the general purpose MBMS subchannel on which the Map Group To Bearer message is sent intersect. However, once media or media control were successfully mapped to this bearer, the reception by the SNRM-C can continue (until Unmap Group To Bearer is received or until timeout) throughout the entire MBMS service area of this bearer.

iv) if multiple carriers are supported, shall include the frequency to be used in the "frequency" attribute;

NOTE 2: In the current release if the "frequency" attribute is included, the frequency in the "frequency" attribute is the same as the frequency used for unicast.

v) shall include the "sdp" attribute set to the SDP with media and application control information applicable to groups that can use this bearer;

vi) shall include the "monitorConfig" object:

a) may include the "receptionQuality" attribute set to "true" or "false" used to control if the client is actively monitoring the MBMS bearer quality or not; and

b) may include the "unicastResource" set to "true" or "false" indicating if the listening status of the unicast bearer is requested or not; and

vii) if the packet headers are compressed with ROHC specified in IETF RFC 5795 [20] in this MBMS bearer, shall include the "rohcEnabled" attribute set to "true"; and

4) shall send the CoAP PUT request protected towards the SNRM-C with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [9].

Upon receiving a response to the CoAP PUT request, the SNRM-S:

a) shall generate an HTTP 200 (OK) response message to the VAL server according to IETF RFC 7231 [22]. In the HTTP 200 (OK) response message, the SNRM-S:

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

2) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-bearers> element in the <mbms-info> root element which:

i) shall include a <result> element set to "success" or "failure" indicating success or failure of the MBMS bearers request operation depending on whether the CoAP response is a successful response or a failure response;

ii) may include a <TMGI> element set to a TMGI value;

iii) shall include a <user-plane-address> element set to the BM-SC user plane IP address and port; and

iv) may include a <service-description> element indicating MBMS bearer related configuration information as defined in 3GPP TS 26.346 [10]; and

b) shall send the HTTP 200 (OK) response message towards the VAL server according to IETF RFC 7231 [22].

6.2.3.2.5 SNRM client CoAP procedure

Upon reception of a CoAP PUT request where the CoAP URI of the request identifies MBMS Resource Configuration resource as described in clause A.3.1.2.2.3.2, the SNRM-C:

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 create or update requested MBMS resource configuration resource, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP PUT request and skip rest of the steps;

b) shall support handling an CoAP PUT request from a SNRM-C according to procedures specified in IETF RFC 7252  [23];

c) shall create or update the MBMS resource configuration resource pointed at by the CoAP URI with the content of "MbmsResourceConfig" object received in the request and return a CoAP 2.01 (Created) or a CoAP 2.04 (Changed) response; and

d) if monitoring configuration is included in the "monitorConfig" attribute, shall start the monitoring accordingly.

6.2.3.3 MBMS bearer announcement over MBMS bearer procedure

6.2.3.3.1 General

The availability of a MBMS bearer is announced to SNRM-Cs by means of an MBMS bearer announcement message. One or more MBMS bearer announcement elements are included in an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body.

An MBMS bearer announcement message can contain new MBMS bearer announcements, updated MBMS bearer announcements or cancelled MBMS bearer announcements or a mix of all of them at the same time in an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body. Each initial MBMS bearer announcement message announces one MBMS bearer intended to carry a general purpose MBMS subchannel used for application level multicast signalling in a specified MBMS service area and additionally, the message could also announce zero or more extra MBMS bearers intended to carry media and media control.

NOTE 1: A new MBMS bearer announcement does not implicitly remove previously sent MBMS bearer announcements if the previously sent MBMS bearer announcement is not included in an MBMS bearer announcement message.

NOTE 2: The SNRM-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.

NOTE 3: The VAL service can select appropriate procedure(s) based on service specific requirements. If the VAL service supports HTTP, CoAP and SIP, HTTP is prior.

When CoAP is used the availability of an MBMS bearer is announced to SNRM-C by creating an MBMS Resource Config resource at the SNRM-C. A single announcement is included in the "application/vnd.3gpp.seal-mbms-config+cbor" MIME body.

When and to whom the SNRM-S sends the MBMS bearer announcement is based on local policy in the SNRM-S.

6.2.3.3.2 SNRM server SIP and HTTP procedures

6.2.3.3.2.1 Generate MBMS bearer announcement message in XML

For each SNRM-C that the SNRM-S is sending an MBMS bearer announcement to, the SNRM-S:

a) shall generate an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with the <version> element set to "1" and one or more <announcement> elements associated with the pre-activated MBMS bearers. Each set of an <announcement> element:

1) shall include a <TMGI> element set to a TMGI value;

NOTE 1: The same TMGI value can only appear in one <announcement> element. The TMGI value is also used to identify the <announcement> when updating or cancelling the <announcement> element.

2) may include an <alternative-TMGI> element set to a list of additional alternative TMGI used in roaming scenarios;

3) may include the QCI value in the <QCI> element;

4) shall include one or more MBMS service area IDs in <mbms-service-area-id> elements in the <mbms-service-areas> element;

5) if multiple carriers are supported, shall include the frequency to be used in the <frequency> element;

NOTE 4: In the current release if the <frequency> element is included, the frequency in the <frequency> element is the same as the frequency used for unicast.

6) shall include a <seal-mbms-sdp> element set to the SDP with media and application control information applicable to groups that can use this bearer;

7) may include a <monitoring-state> element set to "monitoring" or "not-monitoring" used to control if the client is actively monitoring the MBMS bearer quality or not;

8) may include an <announcement-acknowlegement> element set to "true" or "false" indicating if the NRM server requires an acknowledgement of the MBMS bearer announcement;

9) may include an <unicast-status> element used to indicate the listening status of the unicast bearer which is requested; and

10) if the packet headers are compressed with ROHC specified in IETF RFC 5795 [20] in this MBMS bearer, shall include a <seal-mbms-rohc> element.

6.2.3.3.2.1.1 SIP based procedure

If the VAL service supports SIP, the SNRM-S shall generate an SIP MESSAGE request in accordance with 3GPP TS 24.229 [6] and IETF RFC 3428 [17] with the constructed application/vnd.3gpp.seal-mbms-usage-info+xml MIME body as specified in clause 6.2.3.3.2.1. In the SIP MESSAGE request, the SNRM-S:

a) shall set the Request-URI to the URI received in the To header field in a third-party SIP REGISTER request;

b) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media-feature tag with the value of "urn:urn-7:3gpp-service.ims.icsi.seal" along with parameters "require" and "explicit" according to IETF RFC 3841 [18];

c) shall include a P-Asserted-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.seal";

d) shall include the MBMS public service identity of the SNRM-S in the P-Asserted-Identity header field;

e) shall include in a MIME body with Content-Type header field set to "application/vnd.3gpp.seal-info+xml", the <seal-request-uri> element set to the VAL user ID of the user; and

f) shall send the SIP MESSAGE request towards the SNRM-C according to 3GPP TS 24.229 [6].

6.2.3.3.2.1.2 HTTP based procedure

If the VAL service does not support SIP, the SNRM-S shall generate an HTTP POST request message in accordance with IETF RFC 7231 [22] with the constructed application/vnd.3gpp.seal-mbms-usage-info+xml MIME body as specified in clause 6.2.3.3.2.1. In the HTTP POST request message, the SNRM-S:

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

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

c) shall include in a MIME body with Content-Type header field set to "application/vnd.3gpp.seal-info+xml", the <seal-request-uri> element set to the VAL user ID of the user; and

d) shall send the HTTP POST request towards the SNRM-C according to IETF RFC 7231 [22].

6.2.3.3.2.2 MBMS bearer de-announcement procedure

When the SNRM-S wants to cancel an MBMS bearer announcement associated with an <announcement> element, the SNRM-S sends an MBMS bearer announcement as specified in clause 6.2.3.3.2.1 where the SNRM-S in the <announcement> element to be cancelled. The SNRM-S:

a) shall include the same TMGI value as in the <announcement> element to be cancelled in the <TMGI> element; and

b) shall not include an <mbms-service-areas> element.

6.2.3.3.3 SNRM client SIP and HTTP procedures

Upon receiving a SIP MESSAGE request containing:

a) a P-Asserted-Service header field containing the "urn:urn-7:3gpp-service.ims.icsi.seal"; and

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body containing one or more <announcement> element(s);

or an HTTP POST request message containing:

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

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body containing one or more <announcement> element(s);

the SNRM-C for each <announcement> element in the application/vnd.3gpp.seal-mbms-usage-info+xml MIME body:

a) if the <mbms-service-areas> element is present:

1) if an <announcement> element with the same value of the <TMGI> element is already stored:

i) shall replace the old <announcement> element with the <announcement> element received in the application/vnd.3gpp.seal-mbms-usage-info+xml MIME body;

2) if there is no <announcement> element with the same value of the <TMGI> element stored:

i) shall store the received <announcement> element;

3) shall store the MBMS public service identity of the SNRM-S received in the P-Asserted-Identity header field and associate the MBMS public service identity with the new <announcement> element;

4) if there is an <announcement-acknowlegement> element set to "true", shall send an acknowledgement of the MBMS bearer to the SNRM-S; and

5) shall check the condition for sending a listening status report;

b) if no <mbms-service-areas> element is present:

1) shall discard a previously stored <announcement> element identified by the value of the <TMGI>; and

2) check the condition for sending a listening status report;

c) if the <monitoring-state> element is present:

1) if the <monitoring-state> is set to "monitor", shall start to monitor the MBMS bearer quality; and

2) if the <monitoring-state> is set to "not-monitor", shall stop monitoring the MBMS bearer quality; and

d) if the <unicast-status> element is present, shall include the <unicast-listening-status> element in the MBMS listening status report message.

6.2.3.3.4 SNRM Server CoAP procedures

6.2.3.3.4.1 MBMS bearer announcement procedure

For each SNRM-C that the SNRM-S is sending an MBMS bearer announcement to, the SNRM-S:

a) shall generate a CoAP PUT request according to IETF RFC 7252 [23]. In the CoAP PUT request, the SNRM-S:

1) shall set the CoAP URI to the MBMS Resource Configuration resource URI according to the resource definition in clause A.3.1.2.2.3:

a) the "apiRoot" is set to the SNRM-C URI;

b) the "valServiceId" is set to the identity of the VAL service; and

c) the "tmgi" is set to a TMGI value;

2) shall include Content-Format option set to “application/vnd.3gpp.seal-mbms-config+cbor”;

3) shall include "MbmsResourceConfig" object in the payload:

i) may include an "alternativeTmgis" attribute set to a list of additional alternative TMGIs used in roaming scenarios;

ii) may include the QCI value in the "qci" attribute;

iii) shall include one or more MBMS service area IDs in the "serviceAreas" attribute;

iv) if multiple carriers are supported, shall include the frequency to be used in the "frequency" attribute;

NOTE 2: In the current release if the "frequency" attribute is included, the frequency in the "frequency" attribute is the same as the frequency used for unicast.

v) shall include the "sdp" attribute set to the SDP with media and application control information applicable to groups that can use this bearer;

vi) shall include the "monitorConfig" object:

a) may include the "receptionQuality" attribute set to "true" or "false" used to control if the client is actively monitoring the MBMS bearer quality or not; and

b) may include the "unicastResource" set to "true" or "false" indicating if the listening status of the unicast bearer is requested or not; and

vii) if the packet headers are compressed with ROHC specified in IETF RFC 5795 [20] in this MBMS bearer, shall include the "rohcEnabled" attribute set to "true"; and

4) shall send the CoAP PUT request protected towards the SNRM-C with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [9].

6.2.3.3.4.2 MBMS bearer de-announcement procedure

When the SNRM-S wants to cancel an MBMS bearer announcement, the SNRM-S shall send a CoAP DELETE request to the SNRM-C to delete the MBMS Resource Config resource in the SNRM-C. The SNRM-S:

a) shall generate a CoAP DELETE request according to IETF RFC 7252 [23]. In the CoAP DELETE request, the SNRM-S:

1) shall set the CoAP URI to the MBMS Resource Configuration resource URI of the resource to be deleted according to the resource definition in clause A.3.1.2.2.3:

a) the "apiRoot" is set to the SNRM-C URI;

b) the "valServiceId" is set to the identity of the VAL service; and

c) the "tmgi" is set to a TMGI value; and

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

6.2.3.3.5 SNRM Client CoAP procedures

6.2.3.3.5.1 MBMS bearer announcement procedure

Upon reception of an CoAP PUT request where the CoAP URI of the request identifies an MBMS Resource Configuration resource as described in clause A.3.1.2.2.3.2, the SNRM-C:

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 update the requested VAL group document, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP PUT request and skip rest of the steps;

b) shall support handling an CoAP PUT request from a SGM-C according to procedures specified in IETF RFC 7252 [23];

d) if monitoring configuration is included in the "monitorConfig" attribute:

1) if the "receptionQuality" attribute is present and is set to "true", shall start monitoring the MBMS bearer quality;

2) if the "receptionQuality" attribute is not present or is present and is set to "false", shall stop monitoring the MBMS bearer quality;

3) if the "unicastResource" attribute is present and is set to "true", shall start monitoring the associated unicast resource; and

4) if the "unicastResource" attribute is not present or is present and is set to "false", shall stop monitoring the associated unicast resource; and

e) shall check the condition for sending a listening status report.

6.2.3.3.5.2 MBMS bearer de-announcement procedure

Upon reception of an CoAP DELETE request where the CoAP URI of the request identifies MBMS Resource Configuration resource as described in clause A.3.1.2.2.3.3, the SNRM-C:

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

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

b) shall support handling an CoAP DELETE request from a SNRM-S according to procedures specified in IETF RFC 7252 [23];

c) shall delete the MBMS resource pointed at by the CoAP URI];

d) if monitoring configuration was included in the "monitorConfig" attribute, shall stop the monitoring accordingly; and

e) shall check the condition for sending a listening status report.

6.2.3.4 MBMS bearer quality detection procedure

NOTE 1: The SNRM-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 or CoAP based method needs to be used.

NOTE 2: The VAL service can select appropriate procedure(s) based on service specific requirements. If the VAL service supports both HTTP, CoAP and SIP, HTTP is prior.

6.2.3.4.1 SNRM client SIP and HTTP procedures

Upon determining the MBMS bearer quality, if the MBMS bearer quality reaches a certain threshold, the SNRM-C shall report the MBMS listening status. The SNRM-C:

NOTE 1: The SNRM-C may determine the MBMS bearer quality by using the BLER of the received data. When no data is received, the quality estimation can consider the reference signals and the modulation and coding scheme (MCS). The UE may also use predictive methods to estimate the expected MBMS bearer quality (e.g. speed and direction) to proactively inform the NRM server of an expected loss of the MBMS bearer quality.

NOTE 2: The threshold used to indicate MBMS bearer quality depends on VAL service type and the metrics used. The metrics used and the associated thresholds are out of scope of this specification.

NOTE 3: The application/vnd.3gpp.seal-mbms-usage-info+xml can contain both the listening status "listening" and "not listening" at the same time.

a) shall generate an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status-report> element in the <mbms-info> root element which;

1) shall include an <identity> element set to the identity of the VAL user or VAL UE who wants to report the MBMS listening status;

2) shall include an <mbms-listening-status> element set to "listening" if the SNRM-C is listening to the MBMS bearer or "not-listening" if the SNRM-C is not listening;

3) shall include one or more <TMGI> elements for which the listening status applies;

4) may include an <mbms-reception-quality-level> element set to the reception quality level per TMGI; and

5) if the <unicast-status> element is present in the MBMS announcement message, shall include an <unicast-listening-status> element set to "listening" or "not-listening" indicating the unicast listening status.

6.2.3.4.1.1 SIP based procedure

If the VAL service supports SIP, the SNRM-S shall generate a SIP MESSAGE request according to 3GPP TS 24.229 [6] and IETF RFC 3428 [17] with the constructed application/vnd.3gpp.seal-mbms-usage-info+xml MIME body as specified in clause 6.2.3.4.1 and the application/vnd.3gpp.seal-info+xml MIME body. In the SIP MESSAGE request, the SNRM-C:

a) shall include a Request-URI set to the MBMS public service identity of the SNRM-S received in the P-Asserted-Identity header field of the announcement message;

c) should include a public user identity in the P-Preferred-Identity header field as specified in 3GPP TS 24.229 [6];

d) shall include a P-Preferred-Service header field with the value "urn:urn-7:3gpp-service.ims.icsi.seal";

e) shall send the SIP MESSAGE request according to 3GPP TS 24.229 [6].

6.2.3.4.1.2 HTTP based procedure

If the VAL service does not support SIP, the SNRM-S shall generate an HTTP POST request message in accordance with IETF RFC 7231 [22] with the constructed application/vnd.3gpp.seal-mbms-usage-info+xml MIME body as specified in clause 6.2.3.4.1 and the application/vnd.3gpp.seal-info+xml MIME body. In the HTTP POST request message, the SNRM-C:

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

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

c) shall send the HTTP POST request towards the SNRM-S according to IETF RFC 7231 [22].

6.2.3.4.2 SNRM server SIP and HTTP procedure

6.2.3.4.2.1 SIP based procedure

Upon receiving a SIP MESSAGE request containing:

a) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status> element and an <mbms-reception-quality-level> element;

the SNRM-S:

a) shall verify that the public user identity in the P-Asserted-Identity header field is bound to theVAL user ID in the <seal-request-uri> element in the application/vnd.3gpp.seal-info+xml MIME body;

b) may send an MBMS bearer announcement message as specified in clause 6.2.3.3 with additional proposal for measurements, e.g. information about neighbouring MBMS bearers; and

c) may send user plane delivery mode to VAL server based on the MBMS listening status to preserve the service continuity as described in clause 6.2.3.5.

6.2.3.4.2.2 HTTP based procedure

Upon receiving an HTTP POST request message containing:

a) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status> element and an <mbms-reception-quality-level> element;

the SNRM-S:

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

1) if the identity of the sender of the received HTTP POST request is not authorized to detect MBMS bearer quality, shall respond with an HTTP 403 (Forbidden) response to the HTTP POST request and skip rest of the steps;

b) may send an MBMS bearer announcement message as specified in clause 6.2.3.3 with additional proposal for measurements, e.g. information about neighbouring MBMS bearers; and

c) may send user plane delivery mode to VAL server based on the MBMS listening status to preserve the service continuity as described in clause 6.2.3.5.

6.2.3.4.3 SNRM client CoAP procedure

Upon determining the MBMS bearer quality, if the MBMS bearer quality reaches a certain threshold, the SNRM-C shall report the MBMS listening status. The SNRM-C:

NOTE 2: The threshold used to indicate MBMS bearer quality depends on VAL service type and the metrics used. The metrics used and the associated thresholds are out of scope of this specification.

NOTE 3: As a precondition, the SNRM-S must be observing the MBMS Resource State resource at the SNRM-C as described in clause 6.2.3.4.4.

a) shall send a CoAP 2.05 (Content) response to the extended CoAP GET request according to IETF RFC 7641 [25]:

1) shall include Content-Format option set to “application/vnd.3gpp.seal-mbms-state+cbor”; and

2) shall include "MbmsResourceState" object in the payload:

i) shall include the "tmgi" attribute set to the TMGI of the MBMS resource;

ii) shall include the "monitorConfig" set to the current montoring configuration at the SNRM-C;

iii) may include the "receptionQualityLevel" set to the measured reception quality level;

iv) if the "unicastResource" attribute of the "monitorConfig" object is set to "true", shall include the "unicastListeningState" set to "true" or "false" indicating the unicast listening status of "listening" or "not-listening" respectively; and

v) if the "suspension" attribute of the "monitorConfig" object is set to "true", shall include the "suspensionState" set to "true" or "false" indicating the suspension status of "suspending" or "not-suspending" respectively.

6.2.3.4.4 SNRM server CoAP procedure

In order to obtain listening status reports from the SNRM-Cs, for each SNRM-C which has been configured to monitor the MBMS Resource, the SNRM-S shall send an extended CoAP GET request as specified in IETF RFC 7641 [25] with the CoAP URI set to the URI of the observable MBMS Resource State resource described in clause A.3.1.2.3.3.1 with the Observe option set to 0 (Register).

Upon receiving a CoAP 2.05 (Content) response that matches the extended CoAP GET request and which contains the Observe option, the SNRM-S:

a) shall handle the response according to IETF RFC 7641 [25];

b) may send an MBMS bearer announcement message as specified in clause 6.2.3.3 with additional proposal for measurements, e.g. information about neighbouring MBMS bearers; and

c) may send user plane delivery mode to VAL server based on the MBMS listening status to preserve the service continuity as described in clause 6.2.3.5.

6.2.3.5 Service continuity in MBMS scenarios

6.2.3.5.1 SNRM client procedures

If the VAL UE is located in MBSFN 1 and can listen to TMGI 1, where no additional MBMS bearers that the SNRM-C is interested in are active in the current cell, the SNRM-C shall send an MBMS listening status report with information related to TMGI 1 as specified in clause 6.2.3.4.1 towards the SNRM-S.

If the VAL UE moves into a new cell in which both TMGI 1 and TMGI 2 are active, the SNRM-C shall send a location information report as specified in 3GPP TS 24.545 clause 6.2.2.2.2 [8] towards the SNRM-S.

If the SNRM-C receives TMGI 1 and TMGI 2, the SNRM-C shall send an MBMS listening status report with information related to TMGI 1 and TMGI 2 as specified in clause 6.2.3.4.1 towards or in clause 6.2.3.4.3 the SNRM-S.

If the VAL UE moves into a new cell in MBSFN area 2, where only TMGI 2 is active, the SNRM-C shall send an MBMS listening status report with information related to TMGI 2 as specified in clause 6.2.3.4.1 or in clause 6.2.3.4.3 towards the SNRM-S.

6.2.3.5.2 SNRM server HTTP procedure

Upon receiving an HTTP POST request message containing:

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

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-listening-status-report> elment;

the SNRM-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 SNRM-C according to procedures specified in IETF RFC 4825 [19] "POST Handling";

b) shall generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-S:

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

3) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with a <user-plane-delivery-mode> element in the <mbms-info> root element which shall include:

i) a <delivery-mode> element indicating whether to deliver the user data to the UE(s) via unicast mode or multicast mode;

ii) an <MBMS-media-stream-id> element indicating the MBMS media stream to be used to deliver the media currently over unicast, or the MBMS media stream currently being used.; and

iii) one or more <unicast-media-stream-id> element(s), each element indicating the unicast media stream to be used to deliver the media currently over multicast, or the unicast to be stopped and switched to multicast; and

c) shall send the HTTP POST request towards the VAL server according to IETF RFC 7231 [22].

Upon receiving an HTTP POST request message containing:

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

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

the SNRM-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 report location information, 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 SNRM-C according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall send an MBMS bearer announcement message with information related to TMGI 2 as specified in clause 6.2.3.3 towards the SNRM-C.

6.2.3.5.3 SNRM server CoAP procedure

Upon receiving a CoAP 2.05 (Content) response with a listening status report as described in clause 6.2.3.4.4, the SNRM-S:

a) shall generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-S:

1) shall include a Request-URI set to the URI corresponding to the identity of the VAL server;

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

3) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with a <user-plane-delivery-mode> element in the <mbms-info> root element which shall include:

i) a <delivery-mode> element indicating whether to deliver the user data to the UE(s) via unicast mode or multicast mode;

ii) an <MBMS-media-stream-id> element indicating the MBMS media stream to be used to deliver the media currently over unicast, or the MBMS media stream currently being used.; and

b) shall send the HTTP POST request towards the VAL server according to IETF RFC 7231 [22].

Upon reception of a CoAP PUT request message where the CoAP URI of the CoAP PUT request identifies a location report as specified in in 3GPP TS 24.545 clause 6.2.2.5.2 , and containing:

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

b) a "LocationReport" object;

the SNRM-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 according to IETF RFC 7252 [23]; and

b) shall send an MBMS bearer announcement message with information related to TMGI 2 as specified in clause 6.2.3.3 towards the SNRM-C.

6.2.3.6 MBMS suspension notification procedure

6.2.3.6.1 SNRM client HTTP procedure

Upon receiving an HTTP POST request message containing:

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

b) an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-suspension-reporting-instruction> elment in the <mbms-info> root element;

the SNRM-C shall send an HTTP 204 (No Content) response according to IETF RFC 7231 [22] towards the SNRM-S.

If the SNRM-C detects the MBMS suspension and has not received a <suspension-reporting> element set to "disable", the SNRM-C shall generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-C:

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

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

c) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-suspension-report> element in the <mbms-info> root element which:

1) shall include an <identity> element set to the identity of the VAL user or VAL UE that reports MBMS suspension;

2) if at least one MBMS bearer is about to be suspended:

i) shall include an <mbms-suspension-status> element set to "suspending";

ii) shall set the <number-of-reported-bearers> element to the total number of the included <suspended-TMGI> elements and <other-TMGI> elements;

iii) shall include <suspended-TMGI> element(s) set to the TMGI value for each of the MTCHs on the same MCH corresponding to the MBMS bearers about to be suspended; and

iv) may include <other-TMGI> elements, if available, corresponding to the TMGI values for other MTCHs on the same MCH as the MBMS bearers to be suspended; and

3) if the MBMS bearer is no longer about to be suspended, shall include:

i) an <mbms-suspension-status> element set to "not-suspending";

ii) a <number-of-reported-bearers> element set to the number of included <suspended-TMGI> elements; and

iii) a <suspended-TMGI> element set to the corresponding TMGI value for each of the MTCHs of the MBMS bearers that are no longer about to be suspended; and

d) shall send the HTTP POST request message towards the SNRM-S according to IETF RFC 7231 [22].

6.2.3.6.2 SNRM server HTTP procedure

If the SNRM-S decide on a subset of all VAL UEs in the MBMS broadcast area that shall report on MBMS bearer suspension, the SNRM-S shall generate an HTTP POST request message according to IETF RFC 7231 [22]. In the HTTP POST request message, the SNRM-S:

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

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

c) shall include an application/vnd.3gpp.seal-mbms-usage-info+xml MIME body with an <mbms-suspension-reporting-instruction> element in the <mbms-info> root element which:

1) if a unicast bearer is used for MBMS suspension reporting, shall include:

i) an <identity> element set to the identity of the VAL user or VAL UE that shall report MBMS suspension; and

ii) a <suspension-reporting> element indicating to enable or disable the suspension reporting for the SNRM-C; and

2) if a multicast bearer is used for MBMS suspension reporting, shall include:

i) a <suspension-reporting-client-subset> element containing a uniquely defined subset of NRM clients that shall report MBMS suspension; and

d) shall send the HTTP POST request message towards the SNRM-C according to IETF RFC 7231 [22].

6.2.3.6.3 SNRM client CoAP procedure

When the SNRM-C detects a change in the MBMS suspension state, the SNRM-C shall notify the SNRM-S of the change. The SNRM-C:

NOTE 1: As a precondition, the SNRM-S must be observing the MBMS Resource State resource at the SNRM-C as described in clause 6.2.3.6.4.

a) shall send a CoAP 2.05 (Content) response to the extended CoAP GET request according to IETF RFC 7641 [25]:

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

2) shall include "MbmsResourceState" object in the payload:

i) shall include the "tmgi" attribute set to the TMGI of the MBMS resource;

ii) shall include the "monitorConfig" set to the current montoring configuration at the SNRM-C;

iii) may include the "receptionQualityLevel" set to the measured reception quality level; and

6.2.3.6.4 SNRM server CoAP procedure

If the SNRM-S decides on a subset of all VAL UEs in the MBMS broadcast area that shall report on MBMS bearer suspension, the SNRM-S shall update the monitoring configuration of the identified SNRM-Cs to enable MBMS bearer suspension monitoring.

The SNRM-S:

a) shall ensure that it is already observing the MBMS Resource State resource of the MBMS bearer for which a suspension report is required. To start observing, the SNRM-S shall send an extended CoAP GET request as specified in IETF RFC 7641 [25] with the CoAP URI set to the URI of the observable MBMS Resource State resource described in clause A.3.1.2.3.3.1 with the Observe option set to 0 (Register);

b) shall generate a CoAP PUT request according to IETF RFC 7252 [23]. In the CoAP PUT request, the SNRM-S:

1) shall set the CoAP URI to the MBMS Resource Configuration resource URI according to the resource definition in clause A.3.1.2.2.3:

i) the "apiRoot" is set to the SNRM-C URI;

ii) the "valServiceId" is set to the identity of the VAL service;

iii) the "tmgi" is set to a TMGI value;

2) shall include Content-Format option set to "application/vnd.3gpp.seal-mbms-config+cbor"; and

3) shall include "MbmsResourceConfig" object in the payload set to a modified MBMS resource configuration which shall include the "monitorConfig" object:

i) may include the "receptionQuality" attribute set to the existing value;

ii) may include the "unicastResource" attribute set to the existing value; and

iii) shall include the "suspension" attribute set to set to "true"; and

c) shall send the CoAP PUT request protected towards the SNRM-C with the relevant ACE profile (OSCORE profile or DTLS profile) as described in 3GPP TS 24.547 [9].

6.2.3.7 MBMS bearer event notification procedure

6.2.3.7.1 SNRM server procedure

NOTE The details between the SNRM-S and EPS (BM-SC) are defined in 3GPP TS 29.468 [13].

Upon receiving an MBMS bearer event notification as described in the clause 6.4.5 of 3GPP TS 29.468 [13], the SNRM-S shall send a user plane delivery mode as described in clause 6.2.2.4.2 towards the VAL server.

6.2.3.8 Switching between MBMS bearer bearer and unicast bearer procedure

6.2.3.8.1 SNRM client HTTP and CoAP procedure

If the VAL UE detects changing MBMS bearer condition (good or bad MBMS coverage) for the corresponding MBMS service, the SNRM-C shall send an MBMS listening status report as specified in clause 6.2.3.4.1 or in clause 6.2.3.4.3 towards the SNRM-S.

6.2.3.8.2 SNRM server HTTP and CoAP procedure

Upon receiving an MBMS listening status report from SNRM-C as specified in clause 6.2.3.4.2 or in clause 6.2.3.4.4, the SNRM-S shall send a user plane delivery mode as described in clause 6.2.2.4.2 towards the VAL server.

6.2.3.9 Use of dynamic MBMS bearers procedure

6.2.3.9.1 VAL server procedure

If the VAL server uses a unicast bearer for communication with the UE on the DL at the start of the group communication session, in order to trigger to use an MBMS bearer in EPS for the DL VAL service communication, the VAL server shall send an MBMS bearer request message as described in clause 6.2.3.2.1 towards the SNRM-S.

6.2.3.9.2 SNRM server HTTP and CoAP procedures

Upon receiving an HTTP POST request message containing:

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

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

the SNRM-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 VAL server according to procedures specified in IETF RFC 4825 [19] "POST Handling"; and

b) shall determine to activate MBMS bearer, and then send an MBMS bearer announcement message as described in clause 6.2.3.2.2 or in clause 6.2.3.2.3 towards the SNRM-C.

Upon receiving an MBMS bearer response from the SNRM-C as specified in clause 6.2.3.2.2 or in clause 6.2.3.2.3, the SNRM-S shall send an MBMS bearers response message as decribed in clause 6.2.3.2.2 or in clause 6.2.3.2.3 towards the VAL server.

6.2.3.9.3 SNRM client HTTP and CoAP procedures

Upon receiving an MBMS bearer announcement from the SNRM-S, the SNRM-C shall act on the announcement as described in clause 6.2.3.2.3 or in clause 6.2.3.2.4.

6.2.4 Network assisted UE-to-UE communications resource managment

6.2.4.1 General

This clause describes the QoS management procedures by a server and clients, while the clients are in communications with each other. The QoS management consists of fulfilling the requirements for the QoS parameters i.e. latency, throughput, reliability and jitter, while the clients communicating with each other via the server. The network assisted QoS management procedures may be performed by a VAL server and VAL clients for a VAL application. The network assisted QoS management may be performed by the SNRM-S acting as application server and to manage QoS in a communication between two or more SNRM-Cs acting as application clients.

The network assisted UE-2-UE communications resource management contains of the following steps:

a) network assisted QoS management initiation, where an SNRM-C initiates the procedure by providing an SNRM-S a set of end-to-end QoS requirements for a service area and a validity period and requesting a QoS management for communications with one or more SNRM-Cs; and

b) network assisted QoS management provisioning, where the S-NRM-S receives a QoS downgrade information from one or more SNRM-Cs engaged in a communication and therefore notifies the SNRM-Cs with a QoS change. The SNRM-S may also get the downgrade information from 5GCN and may act upon it by communicating to 5GCN to modify the QoS profile or update the PCC rules to apply new traffic policy for the ongoing communications based on subscription information.

6.2.4.2 Network assisted QoS management initiation

6.2.4.2.1 SNRM client HTTP procedure

In order to initiate the network assisted QoS management for UE comminications, the SNRM-C shall send an HTTP POST request message according to procedures specified in IETF RFC 7231 [7]. In the HTTP POST request message, the SNRM-C:

a) shall set the Request-URI to the URI identifying the SNRM-S;

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

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

d) shall include an application/vnd.3gpp.seal-network-QoS-managment-info+xml MIME body with the <network-QoS-management-info> root element including the <QoS-management-initiation-request> element which:

1) shall include a <VAL-ue-id> element set to the identity or IP address of the SNRM-C acting as the VAL UE and performing the request;

2) shall include a <VAL-ue-list> element with one or more <VAL-ue-id> child elements set to the identities of the VAL UEs which are nodes for the end-to-end application within the VAL service, for which the end-to-end QoS management applies;

3) may include a <VAL-service-id> element set to the VAL service identity of the VAL application;

4) may include <end-to-end-QoS-requirements> element set to the QoS requirements for latency, throughput, reliability and jitter for the VAL application for the end-to-end session;

5) may include a <service-area> element set to the geographical area or topological area where an end-to-end QoS management request applies; and

6) may include a <validity-period> element set to the period of time during which an end-to-end requirement is valid.

6.2.4.2.2 SNRM server HTTP procedure

Upon receipt an HTTP POST request from the SNRM-C for the network assisted QoS management for UE communications, the SNRM-S shall determine the identity of the sender as specified in clause 6.2.1.1 to confirm whether the sender is authorized or not. If:

a) the sender is not an authorized user, the SNRM-S shall respond with an HTTP 403 (Forbidden) response message and avoid the rest of steps; or

b) the sender is an authorized user, the SNRM-S:

1) shall initiate the network assisted QoS management for the communications between the SNRM-C acting as the VAL UE and is identified by the value of the <VAL-ue-id> element with SNRM-Cs of the VAL UEs with the identities listed as values in the <VAL-ue-list> element for the VAL service, identified by the value of the <VAL-service-id > element by using the values for the <end-to-end-QoS-requirements> element, <service-area> element and <validity-period> element from the HTTP POST request message; and

2) shall send an HTTP 200 (OK) response message according to procedures specified in IETF RFC 7231 [15], where the HTTP 200 (OK) response message:

i) shall set the Request-URI to the URI identifying the SNRM-S;

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

iii) shall include an application/vnd.3gpp.seal-network-QoS-managment-info+xml MIME body with the <network-QoS-management-info> root element including the <QoS-management-initiation-response> element which:

A) shall include a <result> element set to the outcome of the end-to-end QoS management response which indicates either a success or a failure; and

B) may include a <QoS-configuration> element set to QoS downgrade reported by the SNRM-C or for QoS change requested by SNRM-S.

6.2.4.2.3 SNRM client CoAP procedure

In order to initiate the network assisted QoS management for UE comminications, the SNRM-C shall create a QoS Session resource by sending a CoAP POST request to the SNRM-S. In the CoAP POST request, the SNRM-C:

a) shall set the CoAP URI to the QoS Sessions resource URI to according to the resource definition in clause A.2.1.2.2.2:

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

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

c) shall include "QosSession" object:

1) shall set "requiredQoS" attribute to the required end-to-end QoS requirement;

2) shall include a list of VAL UEs which are requested to participate in the QoS session in the "participants" attribute, and for each participant, shall add a "SessionParticipant" object in which:

i) shall set "id" attribute to the VAL UE ID; and

ii) if the participant object represents the requesting VAL UE, shall include the "state" object and set its "active" attribute to "true"; and

3) may include "valServiceId" attribute set to the identity of the VAL service enabled by the QoS session;

4) may include one or more geographical area identifiers in "serviceArea" attribute; and

5) may include "validPeriod" attribute set to the time period when the QoS session is valid; and

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

Upon receiving a CoAP 2.01 (Created) response, the SNRM-C shall store the newly created QoS Session and shall check if it contains a reporting configuration to be applied.

6.2.4.2.4 SNRM server CoAP procedure

Upon reception of an CoAP POST request where the CoAP URI of the request identifies the QoS Sessions resource URI according to the resource definition in clause A.2.1.2.2.2, the SNRM-S:

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

1) if the identity of the sender of the received CoAP POST request is not authorized to create the QoS session, shall respond with a 4.03 (Forbidden) response to the CoAP POST request and skip rest of the steps;

b) shall support handling an CoAP POST request from a SNRM-C according to procedures specified in IETF RFC 7252  [23]; and

c) shall create a new Individual QoS Session resource and for each VAL UE in the list of participants shall create a new Individual Session Participant resource and shall return a CoAP 2.01 (Created) response with the "QosSession" object including its resource URI in "resUri" attribute, and optionally a reporting configuration in "reportConf" attribute.

6.2.4.3 Network assisted QoS management provisioning

6.2.4.3.1 SNRM client HTTP procedure

In order to provision the network assisted QoS management for UE communications, the SNRM-C shall send an HTTP POST request message according to procedures specified in IETF RFC 7231 [15]. In the HTTP POST request message, the SNRM-C:

a) shall set the Request-URI to the URI identifying the SNRM-S;

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

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

d) shall include an application/vnd.3gpp.seal-network-QoS-managment-info+xml MIME body and with the <network-QoS-management-info> root element including the <QoS-management-provision-request> element which:

1) shall include a <VAL-ue-id> element set to the identity of the SNRM-C acting as the VAL UE and performing the request; and

2) may include <QoS-downgrade-report> element set to the report indicating a QoS downgrade of the end-to-end QoS parameters (latency, throughput, reliability and jitter) which may be reported based on QoS configuration parameter from the end-to-end QoS management response.

6.2.4.3.2 SNRM server HTTP procedure

Upon receipt an HTTP POST request from the SNRM-C for provisioning the network assisted QoS management for UE communications, the SNRM-S shall determine the identity of the sender as specified in clause 6.2.1.1 to confirm whether the sender is authorized or not. If:

a) the sender is not an authorized user, the SNRM-S shall respond with an HTTP 403 (Forbidden) response message and avoid the rest of steps; or

b) the sender is an authorized user, the SNRM-S:

1) shall provision the network assisted QoS management for SNRM-C acting as the VAL UE and is identified by the value of the <VAL-ue-id> element by using the value for <QoS-downgrade-report> element from the HTTP POST request message; and

2) shall send an HTTP 200 (OK) response message according to procedures specified in IETF RFC 7231 [15], where the HTTP 200 (OK) response message:

i) shall set the Request-URI to the URI identifying the SNRM-S;

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

A) shall include a <server- id> element set to the identity of the VAL server; and

B) shall include a <requested-QoS-parameters> element set to change request for the end-to-end QoS management, imposed by the VAL server on one or more VAL UEs, engaged in a network-assisted communication.

6.2.4.3.3 SNRM client CoAP procedure

In order to provision the network assisted QoS management for UE communications, the SNRM-C shall send a CoAP PUT request to the SNRM-S to update the reported QoS of the QoS session participant. In the CoAP PUT request, the SNRM-C:

a) shall set the CoAP URI to the "resUri" of the QoS session participant corresponding to the VAL UE, so that the CoAP URI of the request identifies the Individual Session Participant resource to be updated according to the resource definition in clause A.2.1.2.4.3.2:

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

2) the "qosSessionId" is set to point to the QoS session; and

3) the "participantId" is set to the VAL UE ID;

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

c) shall include "SessionParticipant" object which:

1) shall include "state" object with the "active" attribute set to "true"; and

2) shall include "reportedQoS" attribute with the experienced or expected QoS; and

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

6.2.4.3.4 SNRM server CoAP procedure

Upon reception of a CoAP PUT request where the CoAP URI of the request identifies Individual QoS Session Participant resource as described in clause A.2.1.2.4.3.2, the SNRM-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 update requested QoS session participant resource, shall respond with a CoAP 4.03 (Forbidden) response to the CoAP PUT request and skip rest of the steps;

b) shall support handling an CoAP PUT request from a SNRM-C according to procedures specified in IETF RFC 7252  [23]; and

c) shall update the individual QoS session paritcipant resource pointed at by the CoAP URI with the content of "SessionParticipant" object received in the request and return a CoAP 2.04 (Changed) response; and

d) if reported QoS is included in "reportedQoS" attribute, shall determine any needed actions to fulfill the end-to-end QoS for the QoS session.

6.3 Off-network procedures

The off-network procedures are out of scope of the present document in this release of the specification.