6 Network slice capability enablement procedures

24.5493GPPNetwork slice capability enablement- Service Enabler Architecture Layer for Verticals (SEAL)Protocol specificationRelease 17Stage 3TS

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

6.1 General

The network slice capability enablement procedures is a SEAL service providing capabilities for network slice re-mapping from one VAL service to one or more other VAL services, 3GPP TS 23.434 [2]. The network server entity, providing the functionality for the network slice re-mapping, acts as an AF communicating with 5GCN to provide guidance to update and modify the S-NSSAIs and the DNNs of the route selection descriptors of the URSP rules, 3GPP TS 24.526 [3], for one or more application traffics per UE.

NOTE: In this release, S-NSSAI and DNN are only used as the route selection descriptor.

6.2 On-network procedures

6.2.1 General

6.2.1.1 Authenticated identity in HTTP request

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

6.2.1.2 Authenticated identity in CoAP request

Upon receiving a CoAP request from SNSCE-C, the SNSCE-S shall authenticate the identity of the sender of the CoAP request is authorized as specified in 3GPP TS 24.547 [4], and if authentication is successful, the SNSCE-S shall use the identity of the sender of the CoAP request as an authenticated identity.

6.2.2 Event triggered network slice adaptation

6.2.2.1 General

These clauses describes the procedures on the client and server side when a request for network slice configuration is sent by the client to the server. The network slice configuration request may cause a network slice adaptation and sent by the SNSCE-C acting as application client requesting a new or a change in network slice configuration.

6.2.2.2 SNSCE client HTTP procedure

In order to request for the network slice adaptation, the SNSCE-C shall send an HTTP PUT request message according to procedures specified in IETF RFC 7231 [8]. In the HTTP PUT request message, the SNSCE-C:

NOTE: How the requested network slice is known by the SNSCE-C is out of scope of this release.

a) shall set the Request-URI to the URI identifying the SNSCE-S according to the pattern"{apiRoot}/su_nsc/val-services/{valServiceId}/configurations/{configurationId}", where:

1) {valServiceId} set to the identity of "VAL service ID" of the VAL application; and

2) {configurationId}set to the identity of "slice adaptation" configuration,

b) shall set the "Host" header field to the URI identifying of SNSCE-S and the port information;

c) 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 [7];

d) shall include the parameters for:

1) VAL UEs of the VAL UE List; and

2) requested S-NSSAI,

as specified in table A.2-1 of annex A serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 8259 [10]; and

e) may include the parameters for:

1) requested DNN; and

2) configuration cause,

as specified in table A.2-1 of annex A serialized into a JavaScript Object Notation (JSON) structure as specified in IETF RFC 8259 [10].

6.2.2.3 SNSCE server HTTP procedure

Upon receipt an HTTP PUT request:

a) with a Request-URI according to "{apiRoot}/su_nsc/val-services/{valServiceId}/configurations/{configurationId} identifying:

1) "valServiceId" identifying the VAL application; and

2) "configurationId" identifying the slice adaptation configuration; and

b) with a body containing:

1) VAL UE list with one or more VAL UEs;

2) requested S-NSSAI;

3) optionally requested DNN; and

4) optionally configuration cause,

, the SNSCE-S shall determine the sender identity 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 SNSCE-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 SNSCE-S:

1) shall attempt to update the network S-NSSAI for one or more VAL UEs with the identities listed in the VAL UE list for the VAL service, identified by VAL service ID by using the parameters for requested S-NSSAI, requested DNN and configuration cause from the HTTP PUT request message;

NOTE 1: To update the application traffic, the SNSCE-S can act as an AF and use the reference point N33 as shown in 3GPP TS 23.434 [2] to influence a VAL UE’s URSP rules for the application traffic by providing a guidance on the route selection parameters S-NSSAI and DNN as described in clause 4.15.6.10 of 3GPP TS 23.502 [2A].

NOTE 2: Whether and how the SNSCE-S can update the network S-NSSAI for all VAL UEs for the VAL service, is out of the scope of this release.

2) shall send the updated network S-NSSAI and any DNN to the PCF, if the update is successful, 3GPP TS 23.434 [2]; and

3) shall send an HTTP 200 response message containing the successful status or an error response for the failure status of the requested network slice adaptation to the SNSCE-C.

6.2.2.4 SNSCE client CoAP procedure

In order to request for the network slice adaptation, the SNSCE-C shall send a CoAP POST request message. In the CoAP POST request message, the SNSCE-C:

NOTE: How the requested network slice is known by the SNSCE-C is out of scope of this release.

a) shall set the CoAP URI identifying a network configuration e.g. the network slice adaptation for a given VAL group containing one or more VAL UEs for a given VAL service according to the API URI definition in Annex B.2, by setting:

1) the "apiRoot" to the SNSCE-S URI;

2) the "valServiceId" to the value identifying the given VAL service;

3) the "ConfigId" to the value identifying the network slice adaptation; and

3) the "configuration" to include:

i) the VAL group ID of the VAL group containing one or more VAL UEs;

ii) the requested S-NSSAI;

iii) optionally the requested DNN; and

iv) optionally the requested configuration cause;

b) shall set the "Uri-Host" and "Uri-Port" Options to the URI identifying of SNSCE-S and the port information; and

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

6.2.2.5 SNSCE server CoAP procedure

Upon receiving a CoAP PUT request, where the CoAP URI of the request identifies a network slice configuration as the network slice adaptation of one or more VAL UEs for a given VAL service as described in Annex B.2, the SNSCE-S shall determine the identity of the sender as specified in clause 6.2.1.2 to confirm whether the sender is authorized or not. If:

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

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

NOTE 1: To update the application traffic, the SNSCE-S can act as an AF and use the reference point N33 as shown in 3GPP TS 23.434 [2] to influence a VAL UE’s URSP rules for the application traffic by providing a guidance on the route selection descriptors S-NSSAI and DNN as described in clause 4.15.6.10 of 3GPP TS 23.502 [2A].

NOTE 2: Whether and how the SNSCE-S can update the network S-NSSAI for all VAL UEs for the VAL service, is out of the scope of this release.

2) shall send the updated network S-NSSAI and any DNN to the PCF, if the update is successful, 3GPP TS 23.434 [2]; and

3) shall send a CoAP 2.04 (Changed) response message indicating the successful status or an error response for the failure status of the requested network slice adaptation to the SNSCE-C.

6.3 Off-network procedures

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

Annex A (normative):
HTTP resource representation and encoding