4 T8 reference point

29.1223GPPRelease 18T8 reference point for Northbound APIsTS

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

4.1 Overview

The T8 reference point is between the SCS/AS and the SCEF. It specifies APIs that allow the SCS/AS to access the services and capabilities provided by 3GPP network entities and securely exposed by the SCEF.

This document also specifies the procedures triggered at the SCEF by API requests from the SCS/AS and by event notifications received from 3GPP network entities.

The stage 2 level requirements and signalling flows for the T8 reference point are defined in 3GPP TS 23.682 [2].

The T8 reference point supports the following procedures:

– Monitoring Procedures

– Procedures for resource management of Background Data Transfer

– Procedures for changing the chargeable party

– Procedures for Non-IP Data Delivery

– Procedures for Device Triggering

– Procedures for Group Message Delivery

– Procedures for Reporting of Network Status

– Procedures for Communication Pattern Parameters Provisioning

– Procedures for PFD Management

– Procedures for Enhanced Coverage Restriction Control

– Procedures for Network Parameter Configuration

– Procedures for setting up an AS session with required QoS

– Procedures for MSISDN-less Mobile Originated SMS

– Procedures for RACS Parameter Provisioning

4.2 Reference model

The T8 reference point resides between the SCEF and the SCS/AS as depicted in figure 4.2.1. The overall SCEF architecture is depicted in clause 4.2 of 3GPP TS 23.682 [2].

NOTE: The SCS/AS can be provided by a third party.

Figure 4.2.1: T8 reference model

4.3 Functional elements

4.3.1 SCEF

The SCEF is a functional element which provides means to securely expose the services and capabilities provided by 3GPP network interfaces. The SCEF provides access to network capabilities through homogenous application programming interfaces.

Individual instances of SCEF may vary depending on what service capabilities are exposed and what API features are supported.

The SCEF shall protect the other PLMN entities (e.g. HSS, MME) from requests exceeding the permission arranged in the SLA with the third-party service provider.

When needed, the SCEF supports mapping between information exchanged with SCS/AS (e.g. geographical identifiers) and information exchanged with internal PLMN functions (e.g. cell-Id, eNB-Id, TAI, MBMS SAI, etc.). This mapping is assumed to be provided by the SCEF based on local configuration data.

4.3.2 SCS/AS

The SCS is the entity which connects MTC application servers to the 3GPP network to enable them to communicate through specific 3GPP defined services with UEs used for MTC and with the SCEF in the HPLMN. The SCS offers capabilities for use by one or multiple MTC application servers. The MTC applications in the external network are hosted on one or more ASs.

An SCS/AS can get services from multiple SCEFs, and an SCEF can provide services to multiple SCS/ASs.

The SCS is controlled by the operator of the HPLMN or by a MTC Service Provider.

The AS can be controlled by a 3^rd party.

4.4 Procedures over T8 reference point

4.4.1 Introduction

All procedures that operate across the T8 reference point, as specified in 3GPP TS 23.682 [2], are specified in the following clauses.

4.4.2 Monitoring Procedures

4.4.2.1 General

These procedures are used to perform event monitoring functions via the T8 interface, which include:

– Monitoring event configuration as specified in clause 4.4.2.2;

– Reporting of monitoring event as specified in clause 4.4.2.3;

– Network initiated notifications of monitoring event cancellation, as specified in clause 4.4.2.4 ; and

– Network initiated notifications of applied parameter configuration, as specified in clause 4.4.2.5.

4.4.2.2 Monitoring Events Configuration

4.4.2.2.1 General

In order to subscribe to a new monitoring event configuration, the SCS/AS shall send an HTTP POST message to the SCEF targeting the resource "Monitoring Event Subscriptions". The body of the HTTP POST message shall include:

– SCS/AS Identifier;

– Monitoring Type;

– Notification Destination Address; and

– One of External Identifier, MSISDN or External Group Identifier. The External Identifier or the MSISDN identifies the subscription of an individual UE and the External Group Identifier points to a group of UEs.

– In addition, the HTTP POST request may include:

– Maximum Number of Reports;

– Monitoring Duration indicated by the property "monitorExpireTime";

– Group Reporting Guard Time.

– Additional Monitoring Type(s), if the subscription request targets multiple event(s).

If the Subscription_modification feature is supported, the SCS/AS may send an HTTP PUT message in order to update an existing monitoring event subscription. The HTTP PUT request targets the resource "Individual Monitoring Event Subscription" replacing all properties in the existing configuration.

For one-time monitoring type of requests, the SCS/AS shall include the Maximum Number of Reports with a value set to 1 and not include the Monitoring Duration in the HTTP request message sent to the SCEF.

If the Subscription_Patch feature is supported, the SCS/AS may send an HTTP PATCH request to request the modification of an existing "Individual Monitoring Event Subscription" resource, with the request body including the modification instructions which may include any applicable attributes (e.g. "notificationDestination" and/or "monitorExpireTime"), except the provided UE Identifier (e.g. "msisdn", "externalId" or "externalGroupId"), "mtcProviderId" and "supportedFeatures" attributes;

For a group of UEs, if the Partial_group_modification feature is supported, the SCS/AS may send an HTTP PATCH message in order to cancel or add certain UE(s) within an active group. The HTTP PATCH request targets the resource "Individual Monitoring Event Subscription" updates with the corresponding "excludedExternalIds" and/or "excludedMsisdns" attributes in the existing configuration for partial group cancellation, or updates with the corresponding "addedExternalIds" and/or "addedMsisdns" attributes in the existing configuration for partial group addition.

Upon receipt of the HTTP POST, PUT or PATCH request message, if the SCS/AS is authorized to perform such request, the SCEF shall check whether the parameters (e.g. Maximum Number of Reports, Monitoring Duration, Maximum Latency, Maximum Response Time, Suggested number of downlink packets in POST or PUT request message) in the HTTP request body are within the range defined by operator policies. If one or more of these parameters are not within the range, the SCEF shall:

– either reject the request message by sending an HTTP response to the SCS/AS with a status code set to 403 Forbidden and may include the "PARAMETER_OUT_OF_RANGE" error in the "cause" attribute of the "ProblemDetails" structure and indicate which parameters are out of the range in the "invalidParams" attribute of the "ProblemDetails" structure; or

– modify the parameters which are not within the range by selecting different values which are in the range.

For individual UE configuration requests, the SCEF shall also check whether the Idle Status Indication is included for UE reachability event. If the Idle Status Indication is received in the request but not supported by the network, the SCEF may reject the request message by sending an HTTP response to the SCS/AS with a status code set to 403 Forbidden and may include the "IDLE_STATUS_UNSUPPORTED" error in the "cause" attribute of the "ProblemDetails" structure.

If the SCEF receives an HTTP POST request to create a subscription resource for a monitoring event, but without an indication of the support for the feature corresponding to the requested monitoring event, the SCEF shall reject the request by sending a "400 Bad Request" HTTP error response with the application error "EVENT_FEATURE_MISMATCH".

If the SCEF receives an HTTP POST request to create a subscription resource for a monitoring event that it does not support, the SCEF shall reject the request by sending a "500 Internal Server Error" HTTP error response with the application error "EVENT_UNSUPPORTED".

If the "enNB" feature is supported and the SCEF receives an HTTP POST request to create a subscription resource for a monitoring event and determines that no more subscriptions are allowed for this client, the SCEF shall reject the request by sending a "403 Forbidden" HTTP error response with the application error "RESOURCES_EXCEEDED".

If the "enNB" feature is supported and the SCEF receives an HTTP POST request to create a subscription resource for a monitoring event and determines that a duplicate subscription already exists for this client, the SCEF shall reject the request by sending a "400 Bad Request" HTTP error response with the application error "DUPLICATE_REQUEST".

After validation, the SCEF shall store the parameters and

– may assign an SCEF Reference ID related to the created monitoring event subscription resource; and based on operator policies, shall

– map the accuracy into permissible granularity for location reporting event;

– map the location area into a list of cells, eNodeB(s) and/or RAI(s)/TAI(s) and derive the corresponding MME(s)/SGSN(s), for number of UEs present in a geographic area event.

In order to delete a previous active configured monitoring event subscription at the SCEF, the SCS/AS shall send an HTTP DELETE message to the SCEF targeting the resource "Individual Monitoring Event Subscription" which is previously received in the response to the request that has created the monitoring events subscription resource. The SCEF shall detemine the SCEF Reference ID related to the active monitoring subscription resource.

4.4.2.2.2 Monitoring Events Configuration via HSS

4.4.2.2.2.1 General

The following monitoring events are applicable for the monitoring event configuration via HSS for an individual UE or a group of UEs:

– Loss of connectivity;

– UE reachability;

– Location Reporting;

– Change of IMSI-IMEI(SV) Association;

– Roaming Status;

– Communication Failure;

– PDN connectivity status;

– Availability after DDN Failure; and

– API support capability.

Only one-time reporting is supported if the "reachabilityType" attribute sets to "SMS" for the event "UE reachability" or if the "locationType" attribute sets to "LAST_KNOWN_LOCATION" for the event "Location Reporting" in the monitoring event request.

4.4.2.2.2.2 Configuration Request for an individual UE

Upon receipt of a configuration request from the SCS/AS for an individual UE, the SCEF shall interact with the HSS via S6t, as specified in 3GPP TS 29.336 [11].

Upon receipt of a successful response from the HSS,

– if it is a one-time monitoring request and the monitoring event report is received, the SCEF shall delete the associated configuration, send an HTTP response message to the SCS/AS with a "200 OK" status code and including the received monitoring event report(s) (more than one report may be provided if the "enNB" is supported).

– otherwise, the SCEF shall,

– for an HTTP POST request, create a new "Individual Monitoring Event Subscription" resource addressed by the URI that contains the SCS/AS identifier and an SCEF-created subscription identifier, and send an HTTP response to the SCS/AS with a "201 Created" status code, containing the final suggested configuration parameter(s) (if modified), indication(s) of the discarded parameter(s) (if discarded), the monitoring event report(s) (more than one report may be provided if the "enNB" is supported), if received, and a location header field containing the URI of the created resource.

– for an HTTP PUT request, update the active "Individual Monitoring Event Subscription" resource addressed by the request URI and send an HTTP response to the SCS/AS with a "200 OK" status code, containing the final suggested configuration parameter(s) (if modified), indication(s) of the discarded parameter(s) (if discarded) and the monitoring event report(s) (more than one report may be provided if the "enNB" is supported), if received, or a "204 No Content" status code.

– for an HTTP DELETE request, delete the active "Individual Monitoring Event Subscription" resource addressed by the request URI and send an HTTP response to the SCS/AS with a "204 No Content" status code, or a "200 OK" status code and including the monitoring event report(s) (more than one report may be provided if the "enNB" is supported), if received.

If the SCEF receives a response with an error code from the HSS, the SCEF shall not create, update nor delete the concerned resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

4.4.2.2.2.3 Configuration Request for a group of UEs

Upon receipt of a request from the SCS/AS including an External Group Identifier, then the monitoring configuration is for a group of UEs. The SCEF shall interact with the HSS via S6t as specified in 3GPP TS 29.336 [11].

Upon receipt of a successful response from the HSS indicating that group processing is in progress and before beginning the processing of individual UEs, the SCEF shall,

– for an HTTP POST request, create a new "Individual Monitoring Event Subscription" resource addressed by a URI that contains the SCS/AS identity and an SCEF-created subscription identifier, store the number of UEs received in the response message from the HSS within the resource and send an HTTP response to the SCS/AS with "201 Created" status code and a location header field containing the URI of the created resource, in order to acknowledge the SCS/AS of the successful group processing request.

– for an HTTP PUT request, update the active "Individual Monitoring Event Subscription" resource addressed by the request URL and send an HTTP response with "200 OK" status code to acknowledge the SCS/AS of the successful group processing request, or a "204 No Content" status code.

– for an HTTP DELETE request, delete the active "Individual Monitoring Event Subscription" resource addressed by the request URI and send an HTTP response to the SCS/AS with "204 No Content" status code.

Upon receipt of the processing result of the individual UEs from the HSS, the SCEF shall behave as follows:

– if no Group Reporting Guard Time is received, the SCEF shall send an HTTP POST request message to the SCS/AS including a reference to the related monitoring subscription, a list of configuration failure result if received for the group members, and the "monitoringEventReports" attribute including a list of monitoring event reports if received for the group members;

– otherwise, the SCEF shall accumulate all of the configuration results and/or monitoring event reports received from the HSS for the group members until the Group Reporting Guard Time expires. Then the SCEF shall send an HTTP POST request message to the SCS/AS including a reference to the related monitoring subscription, and a list of configuration failure result if received for the group members, and the "monitoringEventReports" attribute including a list of monitoring event reports at the Group Reporting Guard Time.

– If the Partial_group_modification feature is supported,

– upon the cancellation of UE(s) within the active group identified by the "excludedExternalIds" and/or "excludedMsisdns" attributes is successful, the SCEF shall,

– if the maximum number of reports applies to the monitoring event configuration of the cancelled UE(s), set the stored number of reports of the indicated UE(s) to the maximum number of reports;

– still consider the rest of UE(s) as applicable within the active group based monitoring subscription to the group based Monitoring Event Report identified by the External Group Identifier;

– determine whether the reporting for the group based event subscription is completed or not. If completed, the SCEF shall delete the corresponding "Individual Monitoring Event Subscription" resource with procedures as described in clause 4.4.2.3.

– If the cancellation of UE(s) within the active group is unsuccessful, the SCEF shall respond with proper error code indicating the error and should return the appropriate additional error information in the POST response body.

– upon the addition of UE(s) within the active group identified by the "addedExternalIds" and/or "addedMsisdns" attributes is successful, the SCEF shall,

– still consider the existing of UE(s) as applicable within the active group based monitoring subscription to the group based Monitoring Event Report identified by the External Group Identifier;

– subsequently apply monitoring event subscription to the new group member UEs.

– If the addition of UE(s) within the active group is unsuccessful, the SCEF shall respond with proper error code indicating the error and should return the appropriate additional error information in the POST response body.

The SCS/AS shall send an HTTP response to acknowledge the SCEF about the handling result of the received HTTP POST request.

4.4.2.2.3 Monitoring Events Configuration directly via MME/SGSN

The monitoring event "Number of UEs in a geographic area" is applicable for the monitoring event configuration via MME/SGSN. Only one-time reporting is supported for this event with the value of Maximum Number of Reports indicated by "maximumNumberOfReports" set to 1.

Upon receipt of an HTTP POST request from the SCS/AS, the SCEF shall

– resolve the location area to the involved SGSN(s)/MME(s) by local configuration;

– interact with the HSS via the S6t interface as specified in 3GPP TS 29.336 [11] if the External Group ID(s) is included; and

– interact with the SGSN(s)/MME(s) via the T6a/b inteface as specified in 3GPP TS 29.128 [12].

NOTE: The SCEF uses local configuration to resolve the involved SGSN(s)/MME(s) if the location area is not received.

After collecting responses from the SGSN(s)/MME(s), if the SCEF does not receive any successful response from the involved SGSN(s)/MME(s), the SCEF shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6; otherwise the SCEF should send a response with 200 OK status code to acknowledge the SCS/AS with one aggregated report in the requested area by including the total count of the number of UEs in the "ueCount" attribute and the External Identifier(s) (if available) or the MSISDN(s) (if available) associated with the External Group ID.

NOTE: It is possible that the number of UEs does not reflect the actual number of UEs in the designated area (e.g. some SGSN(s)/MME(s) do not respond successfully). The SCEF still provides the result to the SCS/AS if at least one SGSN/MME returns a successful response.

4.4.2.2.4 Monitoring Events Configuration via PCRF

4.4.2.2.4.1 General

The following monitoring events: the location reporting event and communication failure event are applicable for the monitoring event configuration via PCRF for an individual UE.

If monitoring event configuration via PCRF is used for a subscription resource, the Subscription_modification feature cannot be supported.

Only the location reporting event is applicabe for the monitoring event configuration via PCRF for a group of UEs.

Only one-time reporting is supported for the monitoring event configuration via PCRF.

HTTP PUT is not supported for the monitoring event configuration via PCRF. If it is received, the SCEF shall reject the HTTP PUT message with 403 Forbidden during monitoring and may indicate the "OPERATION_PROHIBITED" error in the "cause" attribute of the "ProblemDetails" structure.

4.4.2.2.4.2 Configuration Request for an individual UE

Upon receipt of an HTTP POST request from the SCS/AS for an individual UE, the SCEF shall:

– interact with the PCRF via the Rx inteface by using an existing AF session or establishing a new AF session as specified in 3GPP TS 29.214 [10];

NOTE 1: The SCEF can derive the service information over the Rx interface based on SCS/AS ID for communication failure event.

– after receiving the AAA message from the PCRF, create a resource which represents the monitoring event configuration addressed by a URI that contains the SCS/AS identifier and an SCEF-created subscription identifier; and

– send a corresponding status code to acknowledge the SCS/AS of the successful processing of the request in the HTTP response message.

Then the SCEF shall wait for the reporting from the PCRF as specified in 3GPP TS 29.214 [10].

NOTE 2: Different events can be reported in different messages according to 3GPP TS 29.214 [10], e.g. STR/RAR for communication failure.

During configuration resource deletion, the SCEF shall also terminate the AF session if it was established and used only for event monitoring.

4.4.2.2.4.3 Configuration Request for a group of UEs

Upon receipt of an HTTP POST request from the SCS/AS for a group of UEs, the SCEF shall:

– interact with all PCRFs in the same PLMN via Nta application of Nt interface as specified in 3GPP TS 29.154 [9];

– after collecting ECA message from all PCRFs, create a resource which represents the monitoring event configuration addressed by a URI that contains the SCS/AS identifier and an SCEF-created subscription identifier; and

– send a corresponding status code to acknowledge the SCS/AS of the successful processing of the request in the HTTP response message.

Then the SCEF shall wait for the reporting from the PCRF(s) as specified in 3GPP TS 29.154 [9].

4.4.2.3 Reporting of Monitoring Event Procedure

Upon receipt of a Monitoring Event Report from the HSS or the MME/SGSN as defined in clause 5.6.3 or clause 5.6.8 of 3GPP TS 23.682 [2], from the PCRF as defined in clause 5.6.5 or from the IWK-SCEF as defined in clause 5.6.8 of 3GPP TS 23.682 [2], the SCEF shall determine the monitoring event subscription associated with the corresponding Monitoring Event Report.

If the monitoring event subscription refers to a Monitoring Event Configuration for a single UE or to a group-based Monitoring Event configuration, and no Group Reporting Guard Time was set, then the SCEF shall send an HTTP POST message including a link to the SCEF-created subscription resource and the received Monitoring Event Report to the identified destination. If the monitoring event subscription refers to a group-based Monitoring Event Configuration and Group Reporting Guard Time was provided during the Monitoring Event configuration procedure, then the SCEF shall accumulate all of the received Monitoring Event reports for the group of UEs until the Group Reporting Guard Time expires or the monitoring duration indicated by the property "monitorExpireTime" is reached.

Upon expiration of Group Reporting Guard Time or expiration of the monitoring duration, the SCEF shall send an HTTP POST message to the identified destination including a link to the SCEF-created subscription resource and the list of accumulated Monitoring Event Reports for each UE identified by either its External Identifier or MSISDN. The destination URL of the HTTP POST message is provided by the SCS/AS during the Monitoring Event Configuration procedure.

If the monitoring event subscription refers to a one-time monitoring request or a continuous monitoring request, but the maximum number of reports is reached, the SCEF shall consider the reporting as completed, delete the corresponding "Individual Monitoring Event Subscription" resource and send an HTTP POST message including the subscription identifier and a cancellation indication to the identified destination. The cancellation indication shall set to "true" indicating to cancel the configured monitoring subscription. The destination URL of the HTTP POST is provided by the SCS/AS during the Monitoring Event Configuration procedure. In addition, the SCEF shall interact with the HSS to delete the event configuration if the latter was performed via the HSS whereas event reports were performed via the SGSN/MME. The SCEF determines that the reporting for a group is completed by comparing the total number of received reports with the number of UEs of the group (received from the HSS during event configuration for a group of UEs) multiplied by the maximum number of reports.

If the Partial_group_modification feature is supported and one or more MSISDN(s) or External Identifier(s) within the active group based monitor subscription have been cancelled or added, the existing UE(s) within the active group based monitoring subscription are still applicable to the group based Monitoring Event Report identified by the External Group Identifier, the added group member(s) shall be subsequently applied with the monitoring event subscription.

When the monitoring duration indicated by the property "monitorExpireTime" is reached, the SCEF shall delete the related event subscription and event configuration locally. The SCS/AS shall no longer address the corresponding "Individual Monitoring Event Subscription" resource.

4.4.2.4 Network-initiated Explicit Monitoring Event Deletion Procedure

Upon receipt of an SCEF Reference ID for the event to be deleted from the HSS as defined in 3GPP TS 29.336 [11], the SCEF shall determine the subscription identifier associated with the indicated active monitoring subscription. Then the SCEF shall delete the related resource "Individual Monitoring Event Subscription", send an HTTP POST message including the subscription identifier and a cancellation indication to the identified destination. The cancellation indication shall set to "true" indicating to cancel the configured monitoring subscription. The destination URL of the HTTP POST is provided by the SCS/AS during the Monitoring Event Configuration procedure.

If the Partial_group_cancellation feature is supported, upon receipt of one or more MSISDN(s) or External Identifier(s) for the group member(s) to be cancelled within the active group based event subscription from the HSS as defined in 3GPP TS 29.336 [11], the SCEF shall,

– if the maximum number of reports applies to the monitoring event configuration, set the stored number of reports of the indicated UE(s) to the maximum number of reports;

– include the MSISDN(s) or External Identifier(s) to be cancelled in the MonitoringNotification Request to the destination URL provided by the SCS/AS during the Monitoring Event Configuration procedure; and

NOTE: The above procedure can be triggered from the HSS due to parameter overwritten by Network Parameter Configuration.

4.4.2.5 Network initiated notification of applied parameter configuration

For "LOSS_OF_CONNECTIVITY" and "UE_REACHABILITY" events, if the "Enhanced_param_config" feature is supported and the SCEF receives the currently applied parameter configuration from the HSS, the SCEF shall notify the SCS/AS via an HTTP POST message including the parameter changes in the "appliedParam" attribute.

4.4.3 Procedures for resource management of Background Data Transfer

These procedures are used by an SCS/AS to perform the resource management of background data transfer (BDT) to a set of UEs, i.e. the SCS/AS requests a time window and related conditions from the SCEF via the T8 interface.

In order to create a resource for the background data transfer policy, the SCS/AS shall send an HTTP POST message to the SCEF for the "BDT Subscriptions" resource to negotiate the transfer policy. The body of the HTTP POST message shall include SCS/AS Identifier, Volume per UE (total volume for both DL and UL or separate volume for DL and/or UL), Number of UEs, Desired Time Window and optionally a location area information.

After receiving the HTTP POST message, if the SCS/AS is authorized, the SCEF shall map the SCS/AS Identifier to ASP Identifier and negotiate the transfer policy with the PCRF as defined in 3GPP TS 29.154 [9]. After receiving the response including the determined transfer policies from the PCRF, the SCEF shall create a resource "Individual BDT Subscription" which represents the BDT subscription, addressed by a URI that contains the SCS/AS identifier and an SCEF-created subscription identifier, and shall respond to the SCS/AS with a 201 Created message, including a Location header field containing the URI for the created resource and a message body, which may also include Reference ID and a set of transfer policies. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this background data transfer subscription. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

The SCS/AS may also send an HTTP PUT message to the SCEF for the "Individual BDT Subscription" resource to request starting an update for negotiation of background data transfer policy. The body of the HTTP PUT message shall include data as described in the POST message. The external group identifier shall remain unchanged from previously provided value. After receiving such request, if the SCS/AS is authorized, the SCEF shall negotiate the transfer policy with the PCRF as defined in 3GPP TS 29.154 [9]. After receiving the response including the determined transfer policies from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK" status code and shall include the Bdt data type in the response body, or with a "204 No Content" status code. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

NOTE 1: The SCEF starts a new BDT policy negotiation in the Nt interface by sending the request to the PCRF without the previously associated BDT Reference ID.

If more than one policy is included in the HTTP response, the SCS/AS shall send an HTTP PATCH message to inform the SCEF for the "Individual BDT Subscription" resource of the transfer policy selected by the SCS/AS. After receiving the HTTP PATCH message, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK" status code and shall include the Bdt data type in the response body, or with a "204 No Content" status code, then the SCEF shall interact with the PCRF as defined in 3GPP TS 29.154 [9]. If the SCEF identifies any error (e.g. selected policy is not within the set of transfer policies), the SCEF shall not update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

The SCS/AS may also send an HTTP DELETE message to the SCEF for the "Individual BDT Subscription" resource requesting to remove an individual resource identified by the URI received in the response to the request that has created resource a URI. After receiving such request, the SCEF shall delete the resource and send an HTTP response to the SCS/AS with a corresponding status code.

NOTE 2: The SCEF can also remove the resource when the last window end time in transfer policies expires.

4.4.4 Procedures for changing the chargeable party at session set up or during the session

This procedure is used by an SCS/AS to either request to sponsor the traffic from the beginning or to request becoming the chargeable party at a later point in time via the T8 interface.

When setting up the connection between the AS and the UE via the SCEF, the SCS/AS shall send an HTTP POST request to the SCEF, targeting the "Chargeable Party Transactions" resource, to become the chargeable party for the session to be set up. The body of the HTTP POST message shall include the SCS/AS Identifier, UE IP address, IP Flow description, Sponsor ID, ASP ID, Sponsoring Status, notification destination URI identifying the recipient of notifications within the "notificationDestination" attribute and may include the time period and/or traffic volume used for sponsoring. The SCS/AS may also request to activate a previously selected policy of background data transfer by including the associated Reference ID in the body of the HTTP POST message. If the feature AppId is supported, either the Flow description or an external Application Identifier shall be included.

After receiving the HTTP POST request, if the authorization performed by the SCEF is successful, the SCEF shall act as an AF and interact with the PCRF via the Rx interface, as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13], to trigger a PCRF initiated IP-CAN Session Modification. The SCEF may map the SCS/AS Identifier to AF Application Identifier if the external Application Identifier is not provided and only one AF Application Identifier is mapped and may request to be notified about the traffic plane status based on local configuration. If the time period and/or traffic volume are received from the SCS/AS, the SCEF should subscribe with the PCRF to the USAGE_REPORT event.

If the "enNB" feature is supported, the SCEF may explicitly receive a list of event(s) that the SCS/AS requests to subscribe to. The SCEF shall subscribe to the corresponding PCRF event(s) (e.g. INDICATION_OF_SUCCESSFUL_RESOURCE_ALLOCATION) for the received event(s) (e.g. SUCCESSFUL_RESOURCES_ALLOCATION) except for SESSION_TERMINATION.

NOTE 1: PCRF does not need explicit subscription in order to notify Rx session termination.

After receiving a successful response from the PCRF, the SCEF shall create a new "Individual Chargeable Party Transaction" resource, which represents the chargeable party transaction, addressed by a URI that contains the SCS/AS identity and an SCEF-created transaction identifier, and shall respond to the SCS/AS with a 201 Created status code, including a Location header field containing the URI of the created resource. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this chargeable party transaction. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create a resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

In order to update the sponsoring status of an established AS session, the SCS/AS shall send an HTTP PATCH message to the SCEF targeting the associated "Individual Chargeable Party Transaction" resource requesting to partial update a chargeable party transaction resource (e.g. change the Sponsoring Status, update the list of event(s) if the "enNB" feature is supported). When receiving the HTTP PATCH message, the SCEF shall make the change and interact with the PCRF to modify the Rx session as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13]. After receiving a response with successful result code from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK" status code and the result if any in the body of the HTTP response or a "204 No Content" status code. The accumulated usage received from the PCRF shall be included in the HTTP response with the "200 OK" status code if the SCS/AS requested to disable the sponsoring. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

NOTE 2: The SCS/AS can assume a successful resource allocation upon receipt of the POST/PATCH response until the FAILED_RESOURCES_ALLOCATION event is received.

NOTE 3: The SCS/AS can update the list of user plane event(s) only for one time specific events, i.e. INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION, INDICATION_OF_FAILED_RESOURCES_ALLOCATION and USAGE_REPORT events, as specified in clause 5.3.13 of 3GPP TS 29.214 [10].

If the SCEF receives a traffic plane notification (e.g. the usage threshold is reached or transmission resource lost) or gets informed that the Rx session is terminated (e.g. due to the release of PDN connection), the SCEF shall send an HTTP POST message including the notified event (e.g. session terminated) and the accumulated usage to the SCS/AS identified by the notification destination URI received during session set up. The SCS/AS shall respond with an HTTP response to confirm the received notification.

In order to remove an established AS session, the SCS/AS shall send an HTTP DELETE message to the SCEF targeting the associated "Individual Chargeable Party Transaction" resource. After receiving the HTTP DELETE message, the SCEF shall remove all properties of the resource and interact with the PCRF to terminate the Rx session (as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13]). After receiving the response from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code and the accumulated usage (if received from the PCRF).

4.4.5 Procedures for Non-IP Data Delivery

4.4.5.1 General

This procedure is used by an SCS/AS to support the Non-IP Data Delivery (NIDD) via SCEF. It performs the NIDD configuration via the T8 interface. It also includes the mobile terminated (MT) and mobile originated (MO) communication with UEs via the T8 interface. It also includes the group message delivery via MT NIDD via the T8 interface and management of port numbers on UE and SCEF and their dynamic association with different applications.

Error handling for the procedures in this clause shall be handled based on clause 5.2.6.

4.4.5.2 NIDD Configuration

4.4.5.2.1 NIDD Configuration for a single UE

For a NIDD configuration creation, the SCS/AS shall send an HTTP POST message to the SCEF for the "NIDD configurations" resource. The body of the HTTP POST message shall include External Identifier or MSISDN, SCS/AS Identifier, notification destination URI identifying the recipient of notification within the "notificationDestination" attribute and may include NIDD Duration, PDN Connection Establishment Option and Reliable Data Service Configuration. In addition, the SCS/AS may send non-IP data and its associated parameters (e.g. Priority) as described in clause 4.4.5.3.1 in the NIDD configuration creation request. The Reliable Data Service Configuration includes port numbers on UE and SCEF that are used to identify specific applications for data transfer between UE and SCS/AS and an indication if reliable data service acknowledgement is enabled or not.

Upon receipt of the HTTP POST request from the SCS/AS to create a NIDD configuration, the SCEF shall check whether the SCS/AS is authenticated and authorized to create NIDD configuration, and also authorize the NIDD configuration. If authorization is successful, the SCEF shall interact with the HSS via S6t as specified in 3GPP TS 29.336 [11]. Upon receipt of the successful response from the HSS, the SCEF shall store the UE identity (IMSI and External Identifier or MSISDN) which is associated with the External Identifier or MSISDN and create a resource "Individual NIDD configuration", which represents the NIDD configuration, addressed by a URI that contains the SCS/AS identity and an SCEF-created NIDD configuration identifier, and shall respond to the SCS/AS with a 201 Created message, including a Location header field containing the URI for the created resource. The body of the response message shall include Maximum Packet Size and may include Reliable Data Service Indication. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this NIDD configuration.

If the SCS/AS includes a downlink non-IP data together with the NIDD configuration creation, the SCEF shall also create the corresponding "Individual NIDD downlink data delivery" sub-resource(s) and send each of the sub- resource(s) within the "self" attribute in the "niddDownlinkDataTransfers" attribute together with the created resource "Individual NIDD configuration" which included in the Location header field in the HTTP POST response. When the SCS/AS receives the URI the "self" attribute in the "niddDownlinkDataTransfers" attribute, it shall use this URI in subsequent requests to the SCEF to refer to this downlink data delivery transfer.

After sending the HTTP response to NIDD configuration request, the SCEF shall perform the procedure for individual MT NIDD as described in clause 4.4.5.3.1.

NOTE: Any further interaction with the SCS/AS for the piggybacked individual MT NIDD is performed by the notification of NIDD downlink data delivery status.

For a NIDD configuration modification, the SCS/AS shall send an HTTP PATCH message to the SCEF for the "Individual NIDD configuration" resource, using the URI received in the response to the request that has created the NIDD configuration resource. Upon receipt of the HTTP PATCH request from the SCS/AS to update the parameters of the NIDD configuration, the SCEF shall check whether the SCS/AS is authenticated and authorized to update NIDD configuration. If the authorization is successful, the SCEF shall verify that the resource to be modified already exists as identified by the URI. If the NIDD configuration resource is found, the SCEF shall update the NIDD configuration as requested. Upon successful update of the requested NIDD configuration including the interaction with the HSS via S6t as specified in 3GPP TS 29.336 [11], the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that the NIDD configuration resource was successfully updated, or with a 204 No Content success message if the NIDD configuration modification is successful updated with no content in the PATCH response message body.

For a NIDD configuration cancellation, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual NIDD configuration" resource, using the URI received in the response to the request that has created the NIDD configuration resource. Upon receipt of the HTTP DELETE message from the SCS/AS, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete NIDD configuration. If the authorization is successful, the SCEF shall verify that the NIDD configuration resource identified by the URI already exists. If the configuration resource exists, the SCEF shall delete the requested configuration, and perform related NIDD procedure to EPC network elements if applicable. Upon successful deletion of requested NIDD configuration, the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that the NIDD configuration was successfully cancelled. As an alternative to the 200 OK success message, the SCEF may send a 204 No Content success message without any message content to the SCS/AS.

When the NIDD Duration expires, the SCEF may remove the associated NIDD configuration resource and all individual downlink data delivery resources under such NIDD configuration.

4.4.5.2.2 NIDD Configuration for a group of UEs

The NIDD configuration procedure for a single UE as described in clause 4.4.5.2.1 shall be applicable for a group of UEs with the following differences:

– The External Group Identifier shall be included in the POST request instead of MSISDN or External Identifier.

– After receiving the response message from the HSS, the SCEF shall store the list of UE identifiers (IMSI and External Identifier or MSISDN) which are associated with the External Group Identifier.

– The downlink non-IP data is not supported to be handled together with the NIDD configuration.

4.4.5.3 Mobile Terminated NIDD procedure

4.4.5.3.1 Mobile Terminated NIDD for a single UE

If the SCS/AS needs to perform a downlink non-IP data delivery for a single UE, the SCS/AS shall send an HTTP POST message to the SCEF for the "NIDD downlink data deliveries" resource, identifying an existing NIDD configuration resource as parent resource. The body of the HTTP POST message shall include External Identifier or MSISDN and non-IP data and may include PDN Connection Establishment Option, Reliable Data Service Configuration, Maximum Latency and Priority. The Reliable Data Service Configuration includes port numbers on UE and SCEF that are used to identify a specific application for data transfer between UE and SCS/AS and an indication if reliable data service acknowledgement is enabled or not.

Upon receipt of a HTTP POST request from the SCS/AS for a downlink data delivery for a single UE, the SCEF shall:

– verify the NIDD configuration resource already exists based on the URI passed, if the configuration resource does not exist, the SCEF shall respond with a 404 Not Found response to reject the downlink data delivery, and

– check whether the SCS/AS is authorised to send NIDD requests, if not authorized, the SCEF shall respond with a 401 Unauthorized response to reject the downlink data delivery, and

– check whether the non-IP packet size is larger than the Maximum Packet Size that was provided to the SCS/AS during NIDD Configuration. If the packet is oversized, the SCEF shall respond with a 403 Forbidden response with a cause value "DATA_TOO_LARGE" in the "cause" attribute of the "ProblemDetails" data structure indicating received non-IP packet size is larger than "maximumPacketSize" of the NIDD configuration.

– if the Rds_port_verification feature is supported, check whether the RDS port numbers are within the configured RDS port list. If the RDS port numbers are unknown in the SCEF, the SCEF shall respond with a 403 Forbidden response with a cause value "RDS_PORT_UNKNOWN" in the "cause" attribute of the "ProblemDetails" data structure.

If all above checks are successful, the SCEF shall determine the EPS Bearer Context based on the APN associated with the NIDD configuration and the User Identity. If the SCEF EPS bearer context is not found in the SCEF, depending on PDN Connection Establishment Option received in the POST request or from NIDD configuration, the SCEF may:

– reject the request with an error message to the SCS/AS;

– send a Device Trigger to the UE as described in clause 4.4.6 without buffering the non-IP data and respond the SCS/AS with a 500 Internal Server Error response and a cause value "TRIGGERED" in the "cause" attribute of the "ProblemDetails" data structure; or

– buffer the non-IP data and create the "Individual NIDD downlink data delivery" sub-resource, then send a 201 Created response to the SCS/AS. The response message also includes an indication of whether the Device Trigger procedure (as described in clause 4.4.6) was performed by the SCEF. A Location header shall be included in the response message that provides the URI of the resource identifying this individual downlink data delivery. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this individual downlink data delivery for possible replacement or cancellation. The non-IP data shall be delivered when the non-IP PDN connection is established.

If the SCEF EPS bearer context is found in the SCEF, the SCEF shall check if the SCS/AS has exceeded the quota or rate of data submission considering the number of existing buffered non-IP data and restriction in APN and serving PLMN rate control. If quota is reached, the SCEF shall respond the SCS/AS with a 403 Forbidden response and a cause value "QUOTA_EXCEEDED" in the "cause" attribute of the "ProblemDetails" data structure indicating the reason for the failure condition. If rate limit is reached, the SCEF shall respond the SCS/AS with a 429 Too Many Requests response.

If the check is passed, the SCEF shall continue the downlink non-IP data delivery procedure as the defined 3GPP TS 29.128 [12].

If the non-IP data delivery was successful, the SCEF shall send a 200 OK response to the HTTP POST request indicating the downlink non-IP data delivery is successful along with the acknowledge information; otherwise the SCEF may:

– send a 500 Internal Server Error response and a cause value indicating the reason for the delivery failure within the "cause" attribute of the "ProblemDetails" data structure, i.e.:

1. if delivery was unsuccessful due to timeout, the cause value "TIMEOUT"; or

2. if delivery to the next hop was unsuccessful with the cause value "NEXT_HOP"; or

– if the MME/SGSN indicates UE is temporary not reachable, either:

1. buffer the non-IP data and create the "Individual NIDD downlink data delivery" sub-resource, then send a 201 Created response to the SCS/AS. The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCEF re-transmits the buffered non-IP data; or

2. send a 500 Internal Server Error response without buffering the non-IP data, and include a cause value "TEMPORARILY_NOT_REACHABLE" in the "cause" attribute of the "ProblemDetails" data structure indicating the downlink non-IP data delivery is performedbut stopped since UE is temporarily unreachable. The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCS/AS may prepare any re-transmission.

If the MT_NIDD_modification_cancellation feature is supported and the SCS/AS decides to replace the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP PUT message to the SCEF, using the URI received in the response to the request that has created the individual downlink data delivery resource. The External Identifier or MSISDN shall remain unchanged from previous values. Upon receipt of the HTTP PUT request from the SCS/AS, the SCEF shall check whether a pending non-IP data exists with the same URI (i.e. resource exists). If it is found, the SCEF shall replace it with the new non-IP data and continue waiting for any message from the MME/SGSN for the UE indicating either the non-IP PDN connection is being established or the UE is reachable (such message may be an MO NIDD); otherwise the SCEF shall respond with a 409 Conflict response with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" data structure indicating replacement failure. If the buffered data is already delivered, the SCEF shall respond with a 404 Not Found response and include a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" data structure indicating replacement failure. If delivery was unsuccessful due to timeout, the SCEF shall respond with a 500 Internal Server Error response with a cause value "TIMEOUT" in the "cause" attribute of the "ProblemDetails" data structure. If delivery to the next hop was unsuccessful, the SCEF shall respond with a 500 Internal Server Error response with a cause value "NEXT_HOP" in the "cause" attribute of the "ProblemDetails" data structure.

If the "PatchUpdate" feature defined in clause 5.6.4 is supported and the SCS/AS decides to partially modify the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP PATCH message to the SCEF to the URI received in the response to the request that has created the concerned individual downlink data delivery resource. The request body shall contain the NiddDownlinkDataTransferPatch data structure including only the attributes that shall be updated. Upon reception of this HTTP PATCH request from the SCS/AS, the SCEF shall check whether a pending non-IP data with the received URI exists (i.e. the resource exists). If it is found, the SCEF shall apply the requested modifications and continue waiting for any message from the MME/SGSN for the UE indicating either the non-IP PDN connection is being established or the UE is reachable (such message may be an MO NIDD); otherwise the SCEF shall respond with a "409 Conflict" status code including a cause value "SENDING" within the "cause" attribute of the "ProblemDetails" data structure to indicate modification failure. If the buffered data is already delivered, the SCEF shall respond with a "404 Not Found" status code including a cause value "ALREADY_DELIVERED" within the "cause" attribute of the "ProblemDetails" data structure to indicate modification failure. If delivery was unsuccessful due to timeout, the SCEF shall respond with a 500 Internal Server Error status code with a cause value "TIMEOUT" in the "cause" attribute of the "ProblemDetails" data structure. If delivery to the next hop was unsuccessful, the SCEF shall respond with a 500 Internal Server Error status code with a cause value "NEXT_HOP" in the "cause" attribute of the "ProblemDetails" data structure.

If the MT_NIDD_modification_cancellation feature is supported and the SCS/AS decides to cancel the pending downlink data delivery in the SCEF, the SCS/AS shall send an HTTP DELETE message to the SCEF, using the URI received in the response to the request that has created the individual downlink data delivery resource. Upon receipt of the HTTP DELETE request from the SCS/AS, the SCEF shall check whether a pending request exists with the same URI. If such non-IP data has not been delivered, the SCEF shall remove the individual downlink data delivery resource and respond with an HTTP 204 No Content response; otherwise the SCEF shall respond with a 404 Not Found response (i.e. data already delivered) with a cause value "ALREADY_DELIVERED" in the "cause" attribute of the "ProblemDetails" data structure or 409 Conflict (i.e. data delivery ongoing) response with a cause value "SENDING" in the "cause" attribute of the "ProblemDetails" data structure, and include a cause value indicating cancellation failure.

If a pending non-IP data is delivered by the SCEF (e.g. due to non-IP PDN connection establishment), and the SCEF gets the delivery result from the MME/SGSN, the SCEF shall remove the "Individual NIDD downlink data delivery" sub-resource and send an HTTP POST message to the SCS/AS, identified by the notification destination URI received during the NIDD configuration, to notify the delivery result for the pending non-IP data. Upon receipt of the request, the SCS/AS shall acknowledge the notification with an HTTP 200 OK or 204 No Content response.

During MT NIDD delivery, if the UE indicates no support for RDS and the SCEF previously indicated RDS is enabled to the SCS/AS, the SCEF shall stop sending the non-IP data and send MT NIDD delivery notification with "FAILURE_RDS_DISABLED" delivery status.

4.4.5.3.2 Mobile Terminated NIDD for a group of UEs

If the SCS/AS needs to perform a downlink non-IP data delivery to a group of UEs and if both the SCS/AS and the SCEF support GroupMesageDelivery feature as defined inclause 5.6.4, the SCS/AS shall send an HTTP POST request message to the SCEF for the "NIDD downlink data deliveries" resource, identifying an existing NIDD configuration resource as parent resource. The body of the HTTP POST request message shall include the External Group Identifier and the non-IP data, and may include Reliable Data Service Configuration, PDN Connection Establishment Option and Maximum Latency.

Upon receipt of such an HTTP POST request from the SCS/AS requesting the group message delivery, the SCEF checks whether the SCS/AS is authorised to send NIDD requests, whether the non-IP packet size is larger than the Maximum Packet Size that was provided to the SCS/AS during NIDD Configuration and if the Rds_port_verification feature is supported whether the RDS port numbers are recognized. If any of those checks fails, the SCEF shall respond with a HTTP response with a cause value indicating the reason for the failure condition. If all checks are successful, the SCEF shall create an "Individual NIDD downlink data delivery" resource and sends a 201 Created response to the SCS/AS to acknowledge acceptance of the HTTP POST request.

Then for each authorized External Identifier associated to the External Group Identifier which is retrieved from the HSS during preceding NIDD configuration procedure (as specified in clause 4.4.5.2.2), the SCEF shall determine the EPS Bearer Context based on the APN associated with the NIDD configuration and the User Identity and continue the procedure as described for MT NIDD for a single UE in clause 4.4.5.3.1 without sending downlink data delivery status notification for any individual UE to the SCS/AS.

At the end of buffering (duration determined by the Maximum Latency or local policy) or after processing data delivery for all UEs in the group, the SCEF shall send an HTTP POST message to SCS/AS to indicate the aggregated result of data delivery of each UE. The body of the HTTP POST request message shall include MSISDN or External Identifier, Retransmission Time (optional) and delivery result for each UE. Upon receipt of the request, the SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.

The MT_NIDD_modification_cancellation feature is not supported for the group message delivery via NIDD. If a PUT or DELETE request is received for the "Individual NIDD downlink data delivery" resource which was created for a group of UEs, the SCEF shall reject the message with a 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" data structure.

During MT NIDD delivery, if the UE indicates no support for RDS and the SCEF previously indicated RDS is enabled to the SCS/AS, the SCEF shall stop sending the non-IP data for the indicated UE. In the aggregated MT NIDD delivery notification, the SCEF shall send "FAILURE_RDS_DISABLED" delivery status for each failed UE.

4.4.5.4 Mobile Originated NIDD procedure

When the SCEF receives the non-IP data from MME/SGSN (or IWK-SCEF) as defined in 3GPP TS 29.128 [12], and finds an SCEF EPS bearer context and the associated NIDD configuration, the SCEF shall determine the SCS/AS by the corresponding NIDD configuration, and send an HTTP POST request to the SCS/AS identified by the Notification Destination Address received in the NIDD configuration to notify the uplink non-IP data. The body of the HTTP POST message shall include External Identifier or MSISDN, non-IP data, NIDD configuration identifier, Reliable Data Service Configuration (if available). The Reliable Data Service Configuration includes port numbers on UE and SCEF that are used to identify a specific application for data transfer between UE and SCS/AS and an indication if reliable data service acknowledgement is enabled or not.

Upon receipt of the request, if the SCS/AS knows the NIDD configuration identified by the NIDD configuration identifier, the SCS/AS shall acknowledge a 200 OK or 204 No Content message to the SCEF.

4.4.5.5 NIDD Authorisation Update procedure

When the SCEF receives a NIDD Authorisation Update Request message from HSS to update a user’s NIDD authorisation as defined in 3GPP TS 29.336 [11], the SCEF shall determine the SCS/AS with the corresponding NIDD Configuration, and send an HTTP POST message to the SCS/AS to notify it of the NIDD Authorisation Update. The body of the HTTP POST message shall include External Identifier or MSISDN, NIDD configuration identifier and the NIDD configuration status.

Upon receipt of the request, if the SCS/AS knows the corresponding NIDD configuration, then the SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.

If the NIDD configuration is revoked by the HSS within the received NIDD Authorisation Update Request, the SCEF shall release the corresponding T6a/b PDN connection as specified in 3GPP TS 29.128 [12]. In this case, the SCEF shall reject any subsequent MT NIDD deliveries with a 403 Forbidden response. Or 404 Not Found is returned, if the SCEF locally removed the associated NIDD configuration resource when the configuration was revoked.

If the RDS capability is changed, e.g. when the T6a/b PDN connection is established, the UE indicates no support for RDS but the SCEF previously indicated RDS is supported to the SCS/AS in the NIDD configuration procedure, the SCEF shall send an HTTP POST message to notify the SCS/AS that the NIDD status is active and RDS capability indication. The SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.

If the Rds_port_verification feature is supported, before sending the MO NIDD to the SCS/AS as specified in clause 4.4.5.4, the SCEF shall check RDS port numbers (decoded from the uplink non-IP data according to 3GPP TS 24.250 [31]). If the RDS port numbers are not within the configured RDS port list, the SCEF shall notify the SCS/AS with NIDD status set to "RDS_PORT_UNKNOWN" and the unknown RDS port numbers. The SCS/AS shall acknowledge the request with an HTTP 200 OK or 204 No Content response.

4.4.5.6 Port Management Configuration

4.4.5.6.1 Port Reservation and Release

As part of the Port Management configuration, operations to reserve a combination of port numbers, release a combination of port numbers, query the list of port numbers that are reserved and notification of reservation of a port number may be performed, if the Rds_dynamic_port feature is supported.

Indication of the supported serialization formats by the SCS/AS, query of the supported and configured serialization formats by the SCS/AS, and notification of the supported and configured serialization formats by the SCS/AS may be performed if the Rds_serialization_format feature is supported.

If the SCS/AS needs to reserve port numbers and associate them with an application, the SCS/AS shall send an HTTP PUT message to the SCEF, using the URI received in the response to the request that has created the NIDD configuration resource and the specific part of "/rds-ports/{portId}" as described in clause 5.6.3.9.2. The SCS/AS may use this operation to reserve port numbers on the UE and SCEF and associate them with an application. The SCS/AS may also use this operation to indicate the serialization formats that are supported by the SCS/AS on the port. Upon receipt of the HTTP PUT request from the SCS/AS,

– if the "skipUeInquiry" is set to "false" and if the "individual ManagePort Configuration" resource already exists in the same NIDD configuration, the SCEF shall respond with a 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" data structure; otherwise, the SCEF shall interact with the UE via the SGSN/MME to reserve the port and optionally configure the serialization format by using RDS protocol as specified in 3GPP TS 24.250 [31] and return a 202 Accept response to the SCS/AS if successful response is received from the SGSN/MME. Then if the SCEF receives successful UE response, the SCEF shall create the "individual ManagePort Configuration" resource and notify the SCS/AS with the reserved port and configured serialization format as specified in clause 4.4.5.6.2, the SCEF shall also mark the resource is created by the SCS/AS; otherwise, the SCEF shall notify the SCS/AS about the currently reserved ports as specified in clause 4.4.5.6.2.

– if the "skipUeInquiry" is set to "true" and if the requested SCEF port already exists in an NIDD configuration within the same APN, the SCEF shall respond with a 403 Forbidden response with a cause value "PORT_NOT_FREE" in the "cause" attribute of the "ProblemDetails" data structure; otherwise, the SCEF shall create the "individual ManagePort Configuration" resource and send an HTTP 201 Created response to the SCS/AS, the SCEF shall also mark the resource is created by the SCS/AS and notify the UE by using RDS protocol as specified in 3GPP TS 24.250 [31].

If the SCEF is not able to configure a serialization format for the port and if the Rds_serialization_format feature is supported, the SCEF shall respond with a 500 Internal Server Error response with a cause value "SERIALIZATION_FORMAT_NOT_SUPPORTED" in the "cause" attribute of the "ProblemDetails" data structure.

If the SCS/AS needs to release port numbers associated with an application, the SCS/AS shall send an HTTP DELETE message to the SCEF, using the URI received in the response to the request that has created the "individual ManagePort Configuration" resource. Upon receipt of the HTTP DELETE request from the SCS/AS, if the "individual ManagePort Configuration" resource does not exist in the same NIDD configuration, the SCEF shall respond with a 404 Not Found response with a cause value "PORT_NOT_ASSOC_WITH_APP" in the "cause" attribute of the "ProblemDetails" data structure; otherwise if the "individual ManagePort Configuration" resource was created by the SCS/AS and

– if the "skipUeInquiry" is set to "false", the SCEF shall interact with the UE via the SGSN/MME to release the port by using RDS protocol as specified in 3GPP TS 24.250 [31] and return 202 Accept to the SCS/AS if successful response is received from the SGSN/MME. Then upon receipt of the UE response, the SCEF shall notify the SCS/AS with the currently reserved ports as specified in clause 4.4.5.6.2.

– if the "skipUeInquiry" is set to "true", the SCEF shall delete the individual ManagePort Configuration resource and respond with an HTTP 204 No Content response to the SCS/AS. The SCEF shall also notify the UE by using RDS protocol as specified in 3GPP TS 24.250 [31].

If the HTTP DELETE request is received for the "Individual ManagePort Configuration" resource which was created by the UE, the SCEF shall reject the message with a 403 Forbidden response with a cause value "OPERATION_PROHIBITED" in the "cause" attribute of the "ProblemDetails" data structure.

If the "skipUeInquiry" is set to "false" and the SCEF is not able to interact with the UE because:

– PDN connection is not established, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error response with a cause value "NO_PDN_CONNECTION";

– UE is not reachable, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error response with a cause value "TEMPORARILY_NOT_REACHABLE". The response may include a Requested Re-Transmission time to indicate the SCS/AS when the UE is expected to be reachable so that the SCS/AS may prepare any re-configuration for the RDS port; or

– the interaction with the SGSN/MME is not successful, the SCEF shall reject the HTTP PUT/DELETE request with a 500 Internal Server Error and a proper cause value indicating the reason for the delivery failure.

If the SCS/AS needs to read the port numbers and serialization formats that are associated with an application, the SCS/AS shall send an HTTP GET message to the SCEF, using the URI received in the response to the request that has created the NIDD configuration resource and the specific part of "/rds-ports/{portId}" as described in clause 5.6.3.9.2.

4.4.5.6.2 Port Notification

If the SCEF needs to send the information about reserved ports and their configuration to the SCS/AS (e.g. due to 3GPP network created or released "individual ManagePort Configuration" resource upon UE triggered RDS port management procedures as specified in 3GPP TS 24.250 [31]), the SCEF shall send an HTTP POST message to the SCS/AS, using the URI received within the "notificationDestination" attribute in the NiddConfiguration resource. The body of the message is encoded in JSON format with the data structure defined in table 5.6.2.1.9-1. The SCS/AS shall acknowledge the HTTP POST request with an HTTP 200 OK or 204 No Content response.

4.4.6 Procedures for Device Triggering

The procedures are used by the SCS/AS to deliver the device trigger via T8 interface.

In order to create a new device trigger, the SCS/AS shall send an HTTP POST message to the SCEF for the "Device Triggering Transactions" resource. The body of the HTTP POST message shall include the External Identifier or MSISDN, validity period, priority, Application Port ID and trigger payload.

Upon receipt of the corresponding HTTP POST message, the SCEF shall check if the SCS/AS is authorised to send a trigger request and if the SCS/AS has exceeded its quota or rate of trigger submission. The SCEF shall also resolve the External Identifier or MSISDN to IMSI and retrieve the "Routing Information" from HSS for the triggering delivery. If the authorisation check fails, or if the quota or rate of trigger submission was exceeded, or if there is no valid subscription information or if the "Routing Information" cannot be found, then the SCEF shall reject the request with an error message to the SCS/AS. Otherwise, the SCEF shall perform the device trigger procedure over Tsp as defined in 3GPP TS 29.368 [24] and T4 as defined in 3GPP TS 29.337 [25]. Upon completion of this procedure, the SCEF shall create a resource "Individual Device Triggering Transaction" which represents the triggering transaction, addressed by a URI that contains the SCS/AS identity and an SCEF-created transaction identifier, and shall respond to the SCS/AS with a 201 Created message, including the trigger and a Location header field containing the URI for the created resource. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this device triggering transaction.

In order to replace an existing device trigger, the SCS/AS shall send an HTTP PUT message to the SCEF for the "Individual Device Triggering Transaction" resource, using the URI received in the response to the request that has created the device triggering transaction resource. The body of the HTTP PUT message shall include the DeviceTriggering data structure containing the requested updates. The properties "msisdn" or "externalId" shall remain unchanged from the previously provided value.

If the "PatchUpdate" feature defined in clause 5.7.4 is supported, in order to partially modify an existing Individual Device Triggering Transaction resource, the SCS/AS shall send an HTTP PATCH message to the SCEF targeting the concerned "Individual Device Triggering Transaction" resource, using the URI received in the response to the request that has created the concerned Individual Device Triggering Transaction resource. The body of the HTTP PATCH message shall include the DeviceTriggeringPatch data structure containing the requested modifications.

After receiving the corresponding HTTP PUT / HTTP PATCH message from the SCS/AS, the SCEF shall check if the SCS/AS is authorised to replace/modify an existing device trigger and if the SCS/AS has not exceeded its quota or rate of trigger submission. If any of these checks fail, then the SCEF shall reject the message with a corresponding failure code as described in clause 5.2.6. Otherwise, the SCEF shall replace the device triggering with the SMS-SC by performing the device trigger replace procedure over Tsp as defined in 3GPP TS 29.368 [24] and T4 as defined in 3GPP TS 29.337 [25]. Upon completion of this procedure, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK"status code and include the result in the body of the HTTP response or a "204 No Content" status code to indicate a successful trigger replacement/modification; otherwise, the SCEF shall send a corresponding failure code as described in clause 5.2.6.

In order to recall an existing device trigger, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual Device Triggering Transaction" resource, using the URI received in the response to the request that has created the device triggering transaction resource.

After receiving the corresponding HTTP DELETE message from the SCS/AS, the SCEF shall check if the SCS/AS is authorised to send a recall trigger request and if the SCS/AS has not exceeded its quota or rate of trigger submission. The SCEF shall also check if the device triggering transaction resource referenced by the URI exists. If any of these checks fail, then the SCEF shall reject the message with an error. Otherwise, the SCEF shall recall the device triggering with the SMS-SC by performing the device trigger recall procedure over Tsp as defined in 3GPP TS 29.368 [24] and T4 as defined in 3GPP TS 29.337 [25]. Upon completion of this procedure, the SCEF shall send an HTTP response to the SCS/AS to indicate trigger recall success or failure.

When it receives the Message Delivery Report from the SMS/SC, the SCEF shall send an HTTP POST message to the SCS/AS to report the trigger delivery result. The body of the HTTP POST message shall include the identifier if the transaction and cause. The SCS/AS shall respond with an HTTP 200 OK or 204 No Content response.

4.4.7 Procedures for Group Message Delivery

4.4.7.1 General

This procedure is used by an SCS/AS to deliver a payload to a group of UEs. Two methods of Group Message Delivery via the T8 are specified:

– Group Message Delivery via MBMS which is intended to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used. This method further includes two varieties:

– the MB2 interface (see stage 2 in 3GPP TS 23.468 [55] and stage 3 in 3GPP TS 29.468 [36]) is used as southbound interface;

– the xMB interface (see stage 2 in 3GPP TS 26.348 [56] and stage 3 in 3GPP TS 29.116 [37]) is used as southbound interface.

– Group Message Delivery via unicast MT NIDD for UEs which are part of the same External Group Identifier.

NOTE: Group Message Delivery via MT NIDD is defined in clause 4.4.5.3.2.

Error handling for the procedures in the subsequent clauses shall be handled based on clause 5.2.6.

4.4.7.2 Group Message Delivery via MBMS

4.4.7.2.1 General

This procedure is used by an SCS/AS to deliver a payload to a group of UEs via the T8 interface. The SCEF use the Group Message Delivery via MBMS to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used.

The procedure of Group message Delivery via MBMS and MB2 used as southbound interface is described in caluse 4.4.7.2.2 and the procedure of Group message Delivery via MBMS and xMB used as southbound interface is described in caluse 4.4.7.2.3.

4.4.7.2.2 Group Message Delivery via MBMS by MB2

4.4.7.2.2.1 TMGI Allocation

If the SCS/AS acts as a GCS AS in the application level and if there is no assigned TMGI for an External Group Identifier, the SCS/AS shall send an HTTP message to the SCEF to the resource "TMGI Allocation". The body of the HTTP POST request message shall include the External Group Identifier. The SCS/AS may also include the location information in the body.

Upon receipt of the HTTP POST request from the SCS/AS to allocate a TMGI, the SCEF shall check whether the SCS/AS is authorized to request TMGI allocation. If authorization is successful, the SCEF shall initiate TMGI allocation by the BM-SC as defined in clause 5.2.1 of 3GPP TS 29.468 [36]. Upon successful allocation of a TMGI, the SCEF shall create the resource which represents the TMGI allocation, addressed by a URI that contains the SCS identity and TMGI, and shall respond to the SCS/AS with a 201 Created message including the TMGI and the TMGI expiration time.

In order to renew the TMGI expiration time, the SCS/AS shall send an HTTP PUT or PATCH message to the SCEF to the resource "Individual TMGI Allocation". Upon receipt of the HTTP PUT or PATCH request from the SCS/AS to renew TMGI expiration time, the SCEF shall initiate TMGI expiration time renewal to the BM-SC as defined in clause 5.2.1 of 3GPP TS 29.468 [36]. Upon successful result, the SCEF shall update the resource and respond to the SCS/AS by sending an HTTP response with 200 OK including the new TMGI expiration time or 204 No Content if the required TMGI expiration time renewal is successful with no content in the HTTP PUT or PATCH response message body.

If the SCEF receives the response with an error code from the BM-SC for the allocation of TMGI or renewal of expiration time for the existing TMGI, the SCEF shall not create or update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

Upon the TMGI expiration, the SCEF may delete the resource of the TMGI locally.

Upon receipt of the notification of TMGI expiration by the BM-SC as defined in clause 5.2.3 of 3GPP TS 29.468 [36], the SCEF shall delete the resource if not yet deleted.

4.4.7.2.2.2 TMGI Deallocation

In order to deallocate the TMGI, the SCS/AS shall send an HTTP DELETE message to the SCEF to the resource "Individual TMGI Allocation". Upon receipt of the HTTP DELETE request from the SCS/AS to deallocate the TMGI, the SCEF shall initiate TMGI deallocation by the BM-SC as defined in clause 5.2.2 of 3GPP TS 29.468 [36]. Upon successful deallocation of a TMGI, the SCEF shall delete the resource "Individual TMGI Allocation" together with all sub-resouces "GMD via MBMS by MB2" if available,and shall respond to the SCS/AS by sending an HTTP response with 204 No Content.

4.4.7.2.2.3 Creation of group message delivery

If the SCS/AS acts as a GCS AS in the application level and if the SCS/AS has an assigned TMGI for the External Group Identifier, in order to perform the group message delivery, the SCS/AS shall sends an HTTP POST request message to the SCEF to the resource "GMD via MBMS by MB2". The body of the HTTP POST request message shall include the External Group Identifier and notification destination URI identifying the recipient of notification within the "notificationDestination" attribute. The SCS/AS may also include the Group Message Payload, the location information and a Message Delivery Start Time in the body.

The SCS/AS may also send an HTTP POST message to the SCEF directly to the resource "TMGI Allocation" without previously requesting TMGI allocation as defined in clause 4.4.7.2.2. The SCEF shall create the resource "Individual TMGI Allocation" and perform the procedure as define in clause 4.4.7.2.2, and shall also create resource "GMD via MBMS by MB2" and perform the procedure as mentioned in this subcaluse for MBMS bearer creation.

Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by MB2", addressed by a URI that contains Transaction Id allocated by the SCEF and respond to the SCS/AS by sending an HTTP response with a 201 Created status code, including a Location header field containing the URI for the created resource. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this active MBMS bearer. If the Group Message Payload was not include in the HTTP POST above, the HTTP response sent from the SCEF shall also include the SCEF message delivery Ipv4 address or Ipv6 address and port number.

If the SCEF receives the response with an error code from the BM-SC for the activation of MBMS bearer, the SCEF shall not create the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in 3GPP TS 29.468 [36] at Message Delivery Start Time.

If the Group Message Payload was not include in the HTTP POST above, the SCEF shall transfer the contents received from the SCS/AS to the BM-CS at or after the requested Group Message Start Time, but before the TMGI Expiration time. In this case, when the SCEF detects the group message delivery was triggered successful, the SCEF shall send an HTTP POST request message to the SCS/AS.

NOTE: If Group Message Payload was included, then at Message Delivery Start Time, the SCEF delivers to BM-SC the Group Message Payload(s) to corresponding to MB2-U IP address and port number associated with respective TMGI.

4.4.7.2.2.4 Modification of previous submitted group message delivery

If the SCS/AS determines that modification of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP PATCH or HTTP PUT request message to the SCEF to the resource "Individual GMD via MBMS by MB2". The body of the HTTP PATCH request message shall include the Message Delivery Start Time. The SCS/AS may also include the External Group Identifier, the Group Message Payload and the location information in the body. The body of the HTTP PUT request message shall include the information as the information provided in the HTTP POST in clause 4.4.7.2.2.2.3. The body of the HTTP PATCH request message shall include the information defined in the data type of GMDViaMBMSByMb2Patch as defined in clause 5.8.2.1.1.6.

Upon receipt of the HTTP PATCH or HTTP PUT request from the SCS/AS to modify the previous group message delivery subscription, the SCEF shall check whether the SCS/AS is authenticated and authorized to modify the submitted group message delivery. If the authorization is successful, the SCEF shall initiate the Modify MBMS Bearer procedure as defined in clause 5.3.4 of 3GPP TS 29.468 [36] with the difference that the SCEF acts as a GCS AS. The SCEF shall include the location information based on the local configuration if the location information is not provided in the HTTP PATCH or HTTP PUT request message.

Upon successful modification of MBMS bearer, the SCEF shall update the resource and respond to the SCS/AS with a 200 OK success message indicating that previous group message delivery subscription is successfully updated, or 204 No Content if the updates or replacement is successful with no content in the HTTP PATCH or HTTP PUT response message body.

If the SCEF receives the response with an error code from the BM-SC for the modification of MBMS bearer, the SCEF shall not update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

4.4.7.2.2.5 Cancellation of previous submitted group message delivery

If the SCS/AS determines that deletion of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP DELETE request message to the SCEF.

Upon receipt of the HTTP DELETE request from the SCS/AS to delete the previous group message delivery, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete an existing group message delivery subscription. If the authorization is successful, the SCEF shall initiate the Delete MBMS Bearer procedure as defined in clause 5.3.3 of 3GPP TS 29.468 [36] with the difference that the SCEF acts as a GCS AS.

Upon successful deletion of MBMS bearer, the SCEF shall respond to the SCS/AS with a 204 No Content message indicating that submitted group message delivery is successfully deleted.

4.4.7.2.3 Group message Delivery via MBMS by xMB

4.4.7.2.3.1 Service Creation

If the SCS/AS acts as a content provider in the application level and if there is no assigned Service ID for an External Group Identifier, the SCS/AS shall send an HTTP POST message to the SCEF to the resource "xMB Services". The body of the HTTP POST request message shall include the External Group Identifier.

Upon receipt of the HTTP POST request from the SCS/AS to create a service, the SCEF shall check whether the SCS/AS is authorized to request service creation. If authorization is successful, the SCEF shall initiate service creation by the BM-SC as defined in clause 5.2.1.2.2 of 3GPP TS 29.116 [37]. Upon successful service creation, the SCEF shall create the resource which represents the service creation, addressed by a URI that contains the SCS identity and Service Id, and shall respond to the SCS/AS with a 201 Created message which may include the service announcement information.

If the SCEF receives the response with an error status code from the BM-SC for the service creation, the SCEF shall not create or update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

4.4.7.2.3.2 Service Deletion

In order to delete the service, the SCS/AS shall send an HTTP DELETE message to the SCEF to the resource "Individual xMB Service". Upon receipt of the HTTP DELETE request from the SCS/AS to delete the service, the SCEF shall initiate service deletion by the BM-SC as defined in clause 5.2.1.2.4 of 3GPP TS 29.116 [37]. Upon successful deletion of a service, the SCEF shall delete the resource "Individual xMB Service" together with all sub-resouces "GMD via MBMS by xMB" if available, and shall respond to the SCS/AS by sending an HTTP response with 204 No Content.

4.4.7.2.3.3 Creation of group message delivery

If the SCS/AS acts as a content provider in the application level, the SCS/AS may sends an HTTP POST request message to the SCEF to the resource "GMD via MBMS by xMB". The body of the HTTP POST request message shall include the External Group Identifier and notification destination URI identifying the recipient of notification within the "notificationDestination" attribute. The SCS/AS may also include the Group Message Payload, the location information, a Message Delivery Start Time and Message Delivery Stop Time in the body.

Upon receipt of the HTTP POST request from the SCS/AS to deliver the group message, the SCEF shall check whether the SCS/AS is authorized to send a group message request. It also checks to see if the Message Delivery Start Time doesn’t start after the Message Delivery Stop Time. If authorization is successful, the SCEF shall initiate the Create Session procedure as defined in clause 4.4.5.2 of 3GPP TS 29.116 [37] and the Update Session procedure as defined in clause 4.4.5.3 of 3GPP TS 29.116 [37] with the difference that the SCEF acts as a Content Provider, Session Start is set accordiong to the Message Delivery Start Time and the Session Stop is set according to the Message Delivery Stop Time. The SCEF shall include the location information based on the local configuration if the location information is not provided and include the session type set to "Files" in the HTTP POST request message.

Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by xMB ", addressed by a URI that contains Transaction Id allocated by the SCEF and respond to the SCS/AS by sending an HTTP response with a 201 Created status code, including a Location header field containing the URI for the created resource. When the SCS/AS receives the URI in the Location header, it shall use this URI in subsequent requests to the SCEF to refer to this active MBMS bearer. If the Group Message Payload was not included in the HTTP POST above, the HTTP response sent from the SCEF shall also include the SCEF message delivery Ipv4 address or Ipv6 address and port number.

If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in 3GPP TS 29.468 [36] at Message Delivery Start Time.

If the Group Message Payload was not included in the HTTP POST above, the SCEF shall transfer the contents received from the SCS/AS to the BM-CS at or after the requested Message Delivery Start Time, but before the Message Delivery Stop Time. In this case, when the SCEF detects the group message delivery was triggered successful, the SCEF shall send an HTTP POST request message to the SCS/AS.

4.4.7.2.3.4 Modification of previous submitted group message delivery

If the SCS/AS determines that modification of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP PATCH or HTTP PUT request message to the SCEF to the resource "Individual GMD via MBMS by xMB ". The body of the HTTP PATCH request message shall include the Message Delivery Start Time and Message Delivery Stop Time. The SCS/AS may also include the External Group Identifier, the Group Message Payload and the location information in the body. The body of the HTTP PUT request message shall include the information as the information provided in the HTTP POST in clause 4.4.7.2.3.3. The body of the HTTP PATCH request message shall include the information defined in the data type of GMDViaMBMSByxMBPatch as defined in clause 5.8.3.1.1.4.

Upon receipt of the HTTP PATCH or HTTP PUT request from the SCS/AS to modify the previous group message delivery subscription, the SCEF shall check whether the SCS/AS is authenticated and authorized to modify the submitted group message delivery. If the authorization is successful, the SCEF shall initiate the Update Session procedure as defined in clause 4.4.5.3 of 3GPP TS 29.116 [37] with the difference that the SCEF acts as a Content Provider, Session Start is set accordiong to the Message Delivery Start Time and the Session Stop is set according to the Message Delivery Stop Time. The SCEF shall include the location information based on the local configuration if the location information is not provided in the HTTP PATCH or HTTP PUT request message.

Upon successful modification of MBMS bearer, the SCEF shall respond to the SCS/AS with a 200 OK success message indicating that previous group message delivery subscription is successfully updated or with a 204 No Content success message if no content in the HTTP PUT or PATCH response message body.

4.4.7.2.3.5 Cancellation of previous submitted group message delivery

If the SCS/AS determines that deletion of previous accepted Group Message Delivery Request is required, the SCS/AS shall send an HTTP DELETE request message to the SCEF.

Upon receipt of the HTTP DELETE request from the SCS/AS to delete the previous group message delivery, the SCEF shall check whether the SCS/AS is authenticated and authorized to delete an existing group message delivery subscription. If the authorization is successful, the SCEF shall initiate the Delete Session procedure as defined in clause 4.4.5.4 of 3GPP TS 29.116 [37] with the difference that the SCEF acts as a Content Provider.

Upon successful deletion of MBMS bearer, the SCEF shall respond to the SCS/AS with a 204 No Content message indicating that submitted group message delivery is successfully deleted.

4.4.8 Procedures for Reporting of Network Status

4.4.8.1 General

These procedures are used by an SCS/AS to perform reporting of network status via the T8 interface in one time or continuous reporting cases. The SCEF uses the reporting procedures based on the network status information from one or more RCAF(s). These procedures can also be used by the SCS/AS to indicate the removal of a previously subscribed reporting request.

4.4.8.2 Network Status Reporting Subscription

In order to create a new subscription to request for notifications on network status, the SCS/AS shall send an HTTP POST request message to the SCEF on the "Network Status Reporting Subscriptions" resource. The body of the HTTP POST request shall include a Notification destination address and Location area information, and may include the time duration and threshold(s).

Upon receiving the HTTP POST request message from the SCS/AS, the SCEF shall check:

– if the SCS/AS is authorized to perform the request. If not, the SCEF shall respond to the SCS/AS with an HTTP "401 Unauthorized" status code.

– if the SCS/AS has exceeded its quota of submitting requests. If so the SCEF shall respond to the SCS/AS with an HTTP "403 Forbidden" status code and may indicate the failure reason "QUOTA_EXCEEDED" (i.e. the quota exceeded) within the "cause" attribute of the ProblemDetails data structure in the HTTP POST response.

– if the SCS/AS has exceeded its rate of submitting requests. If so the SCEF shall respond to the SCS/AS with an HTTP "429 Too Many Requests" status code in the HTTP POST response.

After the SCEF authorized the HTTP request message, the SCEF shall create an "Individual Network Status Reporting Subscription" resource which represents the subscription, addressed by a URI that contains the SCS/AS identity and an SCEF-created subscription identifier, and shall respond to the SCS/AS with an HTTP "201 Created" status code, including a Location header field containing the URI for the created resource, to acknowledge to the SCS/AS the successful subscription creation. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this network status reporting subscription. Then, the SCEF shall trigger the network status reporting procedure with the RCAF over Ns interface as defined in 3GPP TS 29.153 [30].

In order to update an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP PUT request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. After receiving the HTTP PUT request message, the SCEF shall send an HTTP PUT response to the SCS/AS with an HTTP "200 OK" status code including a representation of the updated "Individual Network Status Reporting Subscription" resource in the response body, or a "204 No Content" status code. Then, the SCEF shall apply the requested updatesand interact with the RCAF as defined in 3GPP TS 29.153 [30].

If the "PatchUpdate" feature defined in clause 5.9.4 is supported, in order to partially modify an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP PATCH request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. The request body shall contain the NetStatusRepSubsPatch data structure including only the attributes that shall be updated. After receiving the HTTP PATCH request message, the SCEF shall send an HTTP response to the SCS/AS with an HTTP "200 OK" status code including a representation of the modified "Individual Network Status Reporting Subscription" resource in the response body, or a "204 No Content" status code. Then, the SCEF shall apply the requested changes and interact with the RCAF as defined in 3GPP TS 29.153 [30].

NOTE: In order to update an existing subscription, the SCEF needs to send a cancellation to the previously associated RCAF(s) to remove the related SCEF instructions and then send a new request with updated parameters.

In order to remove an existing subscription of continuous network status reporting, the SCS/AS shall send an HTTP DELETE request message to the SCEF on the "Individual Network Status Reporting Subscription" resource, using the URI received in the response to the request that has created the network status reporting subscription resource. Upon reception of the HTTP DELETE request message, the SCEF shall send an HTTP DELETE response to the SCS/AS with an HTTP "204 No Content" status code. Then, the SCEF shall interact with the RCAF to terminate the continuous reporting of network status as defined in 3GPP TS 29.153 [30].

4.4.8.3 Network Status Reporting Notification

After receiving reports from all the involved RCAF(s) as defined in 3GPP TS 29.153 [30], the SCEF shall send an HTTP POST message to the SCS/AS using the identified destination URL, which is provided by the SCS/AS during the network status reporting subscription. The body of HTTP POST message shall include the NSI.

4.4.9 Procedures for Communication Pattern Parameters Provisioning

One or more set of CP parameters may be provisioned by the SCS/AS for a single UE or a group of UEs.

In order to create resources for one or more CP parameter set(s), the SCS/AS shall send an HTTP POST message to the SCEF for the "CP Provisioning Subscriptions" resource, including one or more new provisioned CP parameter set(s). The body of HTTP POST message shall include External Identifier or MSISDN for a single UE or External Group ID for a group of UEs, SCS/AS Identifier and one or more set of CP information associated with CP parameter set Id(s).

After receiving the HTTP POST message, the SCEF shall check if the SCS/AS is authorised. The SCEF may also check if the number of CP parameter sets(s) reaches the limitation based on operator policy or configuration.

After validation, the SCEF shall for each received CP parameter set Id, assign an SCEF Reference ID which may be derived from the CP parameter set Id, and send Update CP Parameter Request message to the HSS for delivering the CP parameter set(s) as specified in 3GPP TS 29.336 [11].

After receiving result from the HSS, if the result is successful, the SCEF shall create a resource "Individual CP Provisioning Subscription" and the corresponding sub-resources "Individual CP Set Provisioning" each represents a successfully provisioned CP parameter set indicated by the HSS and respond to the SCS/AS with a "201 Created" including Location header field containing the URI for the created subscription resource "Individual CP Provisioning Subscription" and the sub-resource(s) "Individual CP Set Provisioning" corresponding to each successful CP parameter set within the "self" attribute in the "cpParameterSet" attribute; otherwise, the SCEF shall not create any resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If not all CP parameters sets are provisioned successfully (i.e. the HSS indicates failure for some or all CP parameter sets and/or the SCEF does not accept the CP parameter provisioning (e.g. one or more CP Set Identifiers in the request are already present in existing subscriptions)), the SCEF shall also include CP report(s) within attribute "cpReports" with a list of failed CP Set Identifier(s) and the corresponding failure code as specified in table 5.10.2.3.5-1 in the body of the HTTP response.

In order to add new CP parameter set(s), update and/or remove the existing CP parameter set(s) for one or more CP parameter set Id(s), the SCS/AS may send an HTTP PUT message to the SCEF for the "Individual CP Provisioning Subscription" resource requesting to add new CP parameter set(s) by creating new resource(s), change some created properties (e.g. Validity Time) of the existing resource(s), and/or remove some or entire properties of the existing resource(s). After receiving the HTTP PUT message, the SCEF shall send the CP parameter changes to the HSS as specified in 3GPP TS 29.336 [11]. After receiving the response from the HSS with a successful code, if the HSS indicates all CP parameter sets or some CP parameter sets are provisioned successfully, the SCEF shall create or update the corresponding sub-resource(s) "Individual CP Set Provisioning" each represents a successfully provisioned CP parameter set indicated by the HSS and send an HTTP response to the SCS/AS with a "200 OK" status code and include a list of successful CP parameter set(s) in the body of the HTTP response, or a "204 No Content" status code. Otherwise, the SCEF shall not create or update the resource(s) and shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If not all CP parameters sets are provisioned successfully (i.e. the HSS indicates failure for some or all CP parameter sets and/or the SCEF does not accept the CP parameter provisioning (e.g. one or more CP Set Identifiers in the request are already present in existing subscriptions)), the SCEF shall also include CP report(s) within attribute "cpReports" with a list of failed CP Set Identifier(s) and the corresponding failure code as specified in table 5.10.2.3.5-1 in the body of the HTTP response.

The SCS/AS may send a HTTP PUT message to the SCEF for the "Individual CP Set Provisioning" resource requesting to replace an individual resource identified by the CP parameter set Id. The body of the HTTP PUT message shall include set of CP information. After receiving such request, the SCEF shall interact with the HSS as specified in 3GPP TS 29.336 [11]. After receiving the response from the HSS with a successful code, the SCEF shall update the resource and send an HTTP response to the SCS/AS with a "200 OK" status code or a "204 No Content" status code; otherwise, the SCEF shall not update the resource and shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.2.6. If the provisioning of the CP set fails (i.e. the HSS returns failure for the CP set or the SCEF does not accept the CP set provisioning), the SCEF shall reject the request with a corresponding status code, and include the attribute "cpReports" with the corresponding failure code as specified in table 5.10.2.3.5-1 and the CP Set Identifier for which the provisioning has failed.

The SCS/AS may send an HTTP DELETE message to the SCEF requesting to delete an individual CP set resource "Individual CP Set Provisioning". After receiving such request, the SCEF shall determine the SCEF Reference ID for Deletion associated with the CP parameter set Id, and interact with the HSS as specified in 3GPP TS 29.336 [11]. After receiving the response from the HSS, the SCEF shall delete the addressed resource and send an HTTP response to the SCS/AS with a "204 No Content" status code.

The SCS/AS may send an HTTP DELETE message to the SCEF requesting to delete an individual subscription resource "Individual CP Provisioning Subscription". After receiving such request, the SCEF shall determine the SCEF Reference ID (s) for Deletion associated with the CP parameter set Id(s) and interact with the HSS as specified in 3GPP TS 29.336 [11]. After receiving the response from the HSS, the SCEF shall delete the addressed resource and its sub-resources addressed by "Individual CP Set Provisioning" and send an HTTP response to the SCS/AS with a "204 No Content" status code.

4.4.10 Procedures for PFD Management

The PFDs associated with application identifier(s) may be created, updated or removed by the third party SCS/AS as defined in 3GPP TS 23.682 [2].

In order to create PFDs resources for one or more external Application Identifier(s), the SCS/AS shall send an HTTP POST message to the request URI of the resource "PFD Management Transactions" including one or more set of PFDs for external Application Identifier(s). The body of the HTTP POST message shall include external Application Identifier(s) and PFDs associated with its PFD Identifier(s), an Allowed Delay may be included for the external Application Identifier(s) as well.

After receiving the HTTP POST message, if the SCS/AS is authorized, the SCEF shall provision the PFDs to the PFDF as defined in 3GPP TS 29.250 [26]. When receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. If one or more external application identifiers are provisioned successfully, the SCEF shall create an "Individual PFD Management Transaction" resource for the request and he corresponding sub-resources "Individual Application PFD Management" each represents a successfully provisioned external application identifier. The SCEF shall respond to the SCS/AS with a 201 Created including Location header field containing the URI for the created transaction resource "Individual PFD Management Transaction" and the sub-resource(s) "Individual Application PFD Management" corresponding to each external application identifier within the "self" attribute in the "PfdData" data type, the SCEF shall also include PFD report(s) with a list of external Application Identifier(s) and result(s) in the body of the HTTP response if some application(s) are not provisioned successfully (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)).

In order to update the PFDs for an existing individual transaction, the SCS/AS shall send an HTTP PUT message to URI of the resource "Individual PFD Management Transaction" including one or more set of PFDs for external Application Identifier(s). After receiving the HTTP PUT message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in 3GPP TS 29.250 [26]. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. The SCEF shall create or update the corresponding sub-resource(s) "Individual Application PFD Management" each represents a successfully provisioned external application identifier, and also include PFD report(s) with a list of external Application Identifier(s) and result(s) in the body of the HTTP response if some application(s) are not provisioned successfully (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)).

NOTE 1: When the PUT for "Individual PFD Management Transaction" is received in the SCEF, SCEF can use partial update or full update towards the PFDF.

If the "PatchUpdate" feature defined in clause 5.11.4 is supported, in order to partially modify an existing PFD Management Transaction, the SCS/AS shall send an HTTP PATCH request message to the SCEF on the "Individual PFD Management Transaction" resource, using the URI received in the response to the request that has created the concerned PFD Management Transaction resource. The request body shall contain the PfdManagementPatch data structure including only the attributes that shall be updated. After receiving the HTTP PATCH request, the SCEF shall apply the requested modifications and interact with the concerned PFDF to add/update/remove PFD(s) as defined in 3GPP TS 29.250 [26]. After receiving the response of the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code. The SCEF shall then create or update the corresponding "Individual Application PFD Management" sub-resource(s), with each represents a successfully provisioned external application identifier. If some application(s) are not provisioned successfully (i.e. the PFDF returns a failure and/or the SCEF does not accept the PFD provisioning (e.g. one or more external Application Identifiers in the request are already present in existing transactions)), the SCEF shall also include PFD report(s) containing a list of external Application Identifier(s) and result(s) in the body of the HTTP response.

In order to remove the PFDs for an existing individual transaction, the SCS/AS shall send an HTTP DELETE message to the URI of the resource "Individual PFD Management Transaction". After receiving such request, the SCEF shall delete the "Individual PFD Management Transaction" resource and its "Individual Application PFD Management" sub-resouce(s), and shall interact with the PFDF as defined in 3GPP TS 29.250 [26]. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

For the POST message to the resource "PFD Management Transactions" or the PUT message to the resource "Individual PFD Management Transaction", if the provisioning of all application(s) fails (i.e. the PFDF returns failure and/or the SCEF does not accept the PFD provisioning), the SCEF shall respond with 500 Internal Server Error status code, and include the attribute "pfdReports" with the corresponding failure reason as specified in table 5.11.2.2.3-1 and the external Application Identifier(s) for which the provisioning has failed.

In order to update the PFDs for an existing external Application Identifier, the SCS/AS shall send an HTTP PUT message to the resource "Individual Application PFD Management" to update the full set of PFDs of an existing resource. After receiving the HTTP PUT message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in 3GPP TS 29.250 [26]. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

NOTE 2: When the PUT for "Individual Application PFD Management" is received in the SCEF, SCEF can use partial update or full update towards the PFDF.

In order to update the PFDs for an existing external Application Identifier, the SCS/AS may also send an HTTP PATCH message to URI of the resource "Individual Application PFD Management" to partially update PFDs. After receiving the HTTP PATCH message, the SCEF shall make the change and send the change to the PFDF (i.e. add/update/remove PFDs) as defined in 3GPP TS 29.250 [26]. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

In order to remove the PFDs for an existing individual application, the SCS/AS shall send an HTTP DELETE message to the resource "Individual Application PFD Management". After receiving such request, the SCEF shall delete the resource and interact with the PFDF as defined in 3GPP TS 29.250 [26]. After receiving the response from the PFDF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code.

For the PUT/PATCH message to the resource "Individual Application PFD Management", if the provisioning of the application fails (i.e. the PFDF returns failure or the SCEF does not accept the PFD provisioning), the SCEF shall reject the request with a corresponding status code, and include the attribute "pfdReports" with the corresponding failure code as specified in table 5.11.2.2.3-1 and the external Application Identifier for which the provisioning has failed.

If the SCEF receives PFD management notification including the PFD failure report from the PFDF (as defined in 3GPP TS 29.250 [26]) and if the feature PfdMgmtNotification is supported, the SCEF shall notify the SCS/AS with an HTTP POST message, identified by the notification destination URI received during the PFD provisioning, to notify the failure result for the PFD management by including the PfdReport data type in the body of the message. Within the PfdReport data type, the SCEF shall include the impacted application id(s) within the "externalAppIds" attribute, the "failureCode" attribute set to "PARTIAL_FAILURE". In addition, if the SCEF receives the location area(s) of PCEF/TDF(s) which are unable to enforce the PFD(s) from the PFDF, the SCEF shall include the location area(s) within the "locationArea" attribute of the PFD report(s). After receiving the HTTP POST message, the SCS/AS shall send a HTTP response with "204 No Content" status code.

NOTE 3: How the SCS/AS reacts to the failed PFD provisioning is left to implementation.

NOTE 4: The SCEF maps the 3GPP network area(s) to the geographic area(s) or civic address(es) if the 3GPP network area(s) is not allowed to be exposed to the 3rd party according to the operator policy.

4.4.11 Procedures for Enhanced Coverage Restriction Control

The procedures are used by an SCS/AS to query the status of, or to configure the enhanced coverage restriction for a UE via the T8 interface as defined in 3GPP TS 23.682 [2].

In order to query the current status of enhanced coverage restriction, the SCS/AS shall send an HTTP POST message to the SCEF using the query custom operation as defined in clause 5.12.13.2. The body of the HTTP POST message shall include External Identifier or MSISDN.

In order to configure the enhanced coverage restriction, the SCS/AS shall send an HTTP POST message to the SCEF using the configure custom operation as defined in clause 5.12.13.3. The body of the HTTP POST message shall include External Identifier or MSISDN and the Enhanced Coverage Restriction setting (i.e. allowed-PLMN-List or restricted-PLMN-List).

Upon receiving the HTTP POST message from the SCS/AS, the SCEF shall check:

– if the SCS/AS is authorized to perform the request. If not the SCEF shall respond to the SCS/AS with a status code set to 401 Unauthorized.

– if the request is malformed. If it is malformed, the SCEF shall respond to the SCS/AS with a status code set to 400 Bad Request.

– if the SCS/AS has exceeded its quota of submitting requests. If so the SCEF shall respond to the SCS/AS with a status code set to 403 Forbidden and may indicate the failure reason "QUOTA_EXCEEDED" (i.e. the quota exceeded) within the "cause" attribute of the "ProblemDetails" structure in the HTTP POST response.

– if the SCS/AS has exceeded its rate of submitting requests. If so the SCEF shall respond to the SCS/AS with a status code set to 429 Too Many Requests in the HTTP POST response.

The SCEF shall send a Configuration Information Request to the HSS to query or configure the setting of Enhanced Coverage Restriction as defined in 3GPP TS 29.336 [11].

Upon receipt of the response from the HSS, the SCEF shall send an HTTP response to the SCS/AS with a 200 OK message for query or configure custom operation and include the Enhanced Coverage Restriction Data from HSS into the HTTP response.

If the SCEF receives a response with an error code from the HSS, the SCEF shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

4.4.12 Procedures for Network Parameter Configuration

4.4.12.1 General

The procedures are used by an SCS/AS to request that the network consider setting the suggested network parameter values which can influence certain aspects of UE/network behaviour. The procedures are applicable for an individual UE or a group of UEs.

In order to create a new network parameter configuration to configure suggested network parameters, the SCS/AS shall send an HTTP POST request message to the SCEF to the resource "NP Configurations". The body of the HTTP request message shall include External Identifier or MSISDN or External Group Identifier, SCS/AS Identifier, and may include Maximum Latency, Maximum Response Time and Suggested Number of Downlink Packets and Group Reporting Guard Time, wherein, the External Identifier or MSISDN indicates the configuration for an individual UE and the External Group Identifier indicates for a group of UEs. If the External Group Identifier is included, the SCS/AS shall provide the Notification Destination Address in the request.

NOTE: The Notification Delivery as described in clause 5.2.5 is not supported for individual UE configuration case.

In order to update an existing Network Parameter Configuration, the SCS/AS may send an HTTP PUT message to the resource "Individual NP Configuration" requesting the SCEF to replace all properties in the existing resource.

The SCS/AS may also use an HTTP PATCH message to request to change some properties in the existing resource.

Upon receipt of the HTTP POST, PUT or PATCH message, if the SCS/AS is authorized to perform the request, the SCEF shall check whether the Maximum Latency, Maximum Response Time and/or Suggested Number of Downlink Packets in the HTTP request body are within the range defined by operator policies, if one or more of these parameters are not within the range, the SCEF shall:

– either reject the request message by sending an HTTP response to the SCS/AS with a status code set to "403 Forbidden" , in which it may indicate the "PARAMETER_OUT_OF_RANGE" application error in the "cause" attribute of the "ProblemDetails" data structure and it may also indicate which parameters are out of the range in the "invalidParams" attribute of the "ProblemDetails" structure in the response body; or

– modify the parameters which are not within the range by selecting different values which are in the range.

After validation, the SCEF shall perform the Network Parameter Configuration as described in clause 4.4.12.2 for an individual UE or in clause 4.4.12.3 for a group of UEs.

In order to delete an existing Network Parameter Configuration at the SCEF, the SCS/AS shall send an HTTP DELETE message to the corresponding resource "Individual NP Configuration" at the SCEF. The SCEF shall determine the SCEF Reference ID for deletion and interact with the HSS via S6t as defined in 3GPP TS 29.336 [11]. Upon receipt of the response from the HSS, the SCEF shall delete active resource "Individual NP Configuration" addressed by the URI and send an HTTP response to the SCS/AS with a "204 No Content" status code.

4.4.12.2 Configuration Request for an individual UE

If the configuration request from the SCS/AS is for an individual UE, the SCEF shall send the Configuration Information Request command to the HSS via S6t as defined in 3GPP TS 29.336 [11].

Upon receipt of the response from the HSS, the SCEF shall,

– for the HTTP POST message, create a new resource "Individual NP Configuration" addressed by a URI that contains the SCS/AS identifier and an SCEF-created configuration identifier, and send an HTTP POST response to the SCS/AS with "201 Created" status code, the final suggested configuration parameter(s) (if modified), the indication(s) for the discarded parameter(s) (if discarded), and a location header field containing the URI for the created resource.

– for the HTTP PUT or PATCH message, update the active resource "Individual NP Configuration", and send an HTTP response to the SCS/AS with "200 OK" status code, the final suggested network parameter(s) (if modified), the indication(s) for the discarded parameter(s) (if discarded), or a "204 No Content" status code.

If the SCEF receives a response with an error code from the HSS, the SCEF shall not create or update the resource and shall respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

4.4.12.3 Configuration Request for a group of UEs

If the configuration request from the SCS/AS is for a group of UEs, the SCS/AS shall provide the Notification Destination Address, the SCEF shall send the Configuration Information Request command to the HSS via S6t as defined in 3GPP TS 29.336 [11].

Upon receipt of the successful response indicating that group processing is in progress from the HSS before beginning the processing of individual UEs, the SCEF shall,

– for the HTTP POST message, create a resource "Individual NP Configuration" addressed by a URI that contains the SCS/AS identity and an SCEF-created configuration identifier. The SCEF shall send an HTTP POST response to the SCS/AS including a location header field containing the URI for the created resource and a "201 Created" status code to acknowledge the SCS/AS of the successful group processing request.

– for the HTTP PUT or PATCH message, update the resource "Individual NP Configuration" addressed by the requested URL, and shall send "200 OK" status code or a "204 No Content" status code to acknowledge the SCS/AS of the successful group processing request in the HTTP response message.

Upon receipt of the processing result of the individual UEs from the HSS, the SCEF shall send an HTTP POST request message with a reference to the related network parameter configuration and a list of processing result for the group members to the SCS/AS.

The SCS/AS shall send an HTTP response to acknowledge the SCEF about the handling result of the received request.

4.4.12.4 Notification of applied parameter configuration

If the Enhanced_param_config feature is supported and the SCEF receives currently applied parameter configuration from the HSS, the SCEF shall notify the SCS/AS by the HTTP POST message including the parameter changes in the "appliedParam" attribute.

4.4.13 Procedures for setting up an AS session with required QoS

This procedure is used to set up an AS session with required QoS for the service as defined in 3GPP TS 23.682 [2].

For initial AS session creation, the SCS/AS shall send an HTTP POST message to the SCEF for the "AS Session with Required QoS Subscriptions" resource. The body of HTTP POST message shall include SCS/AS Identifier, UE IP address, IP Flow description, QoS reference and notification destination address. And it may also include time period and/or traffic volume for sponsored data connectivity purpose. If the feature AppId is supported, either the Flow description or an external Application Identifier shall be included.

After receiving the HTTP POST message, the SCEF shall authorize the request and may check if the total number of requested QoS reference has exceeded the limit for the SCS/AS. If the authorization is successful, the SCEF shall map the SCS/AS Identifier to AF Application Identifier if the external Application Identifier is not provided and only one AF Application Identifier is mapped, and if required, map the SCS/AS Identifier to ASP Identity and Sponsor Identity.

NOTE 1: Before the QoS reference is mapped to Rx parameters, the SCEF can perform a mapping from the name space of the 3rd party SCS/AS to the name space of the operator.

NOTE 2: The QoS reference referring to pre-defined QoS information in the SCEF can be mapped to media component descriptions (e.g. bandwidth, media type) according to SLA.

If the authorization performed by the SCEF is successful, then the SCEF shall act as an AF to interact with the PCRF via the Rx interface as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13] and trigger a PCRF initiated IP-CAN Session Modification. Based on local configuration, the SCEF may also request to be notified about the transmission resource status, i.e. INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION, INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_FAILED_RESOURCES_ALLOCATION, and optionally INDICATION_OF_LOSS_OF_BEARER and INDICATION_OF_RECOVERY_OF_BEARER. If the time period and/or traffic volume are received from the AF, the SCEF should subscribe to the PCRF on the USAGE_REPORT event.

If the "enNB" feature is supported, the SCEF may explicitly receive a list of user plane event(s) that the SCS/AS requests to subscribe to. The SCEF shall subscribe to the corresponding PCRF event(s) (e.g. INDICATION_OF_SUCCESSFUL_RESOURCE_ALLOCATION) for the received event(s) (e.g. SUCCESSFUL_RESOURCES_ALLOCATION), except for the SESSION_TERMINATION event.

NOTE 3: The PCRF does not need explicit subscription in order to notify Rx session termination.

The SCEF, after receiving the AAA message or HTTP 201 Created message over the Rx interface from the PCRF with successful result code, shall create a resource "Individual AS Session with Required QoS Subscription" which represents AS session, addressed by a URI that contains the SCS/AS identity and an SCEF-created AS session identifier, and shall respond to the SCS/AS with a 201 Created message, including the result in the body of the HTTP response and a Location header field containing the URI for the created resource. The SCS/AS shall use the URI received in the Location header in subsequent requests to the SCEF to refer to this AS session. Otherwise, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code and include the result in the body of the HTTP response. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not create the resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

In order to update the established AS session, the SCS/AS may send an HTTP PUT message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource requesting to replace all properties (e.g. new usage threshold, Flow Description or external Application Identifier) in the existing resource, addressed by the URI received in the response to the request that has created the resource. The UE IP or MAC address shall remain unchanged from previously provided values. After receiving such message, the SCEF shall make the change (e.g. if the usage threshold within the "usageThreshold" attribute is included in the HTTP PUT request and the accumulated usage report for the previously provided usage threshold is not received yet, the SCEF shall completely replace the previously provided one), and interact with the PCRF to modify the Rx session (as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13]). After receiving the response with successful result code from the PCRF, the SCEF shall replace all properties of the existing resource, send an HTTP response to the SCS/AS with a "200 OK"status code, and include the result in the body of the HTTP response or a "204 No Content" status code. If the SCEF receives a response with an error code from the PCRF, the SCEF shall not update the resource and respond to the SCS/AS with a corresponding failure code as described in clause 5.2.6.

The SCS/AS may also send an HTTP PATCH message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource requesting to change some created properties (e.g. new usage threshold, Flow Description or external Application Identifier, updated list of user plane event(s) if the "enNB" feature is supported). After receiving the HTTP PATCH message, the SCEF shall make the change (e.g. if the usage threshold within the "usageThreshold" attribute is included in the HTTP PATCH request and the accumulated usage report for the previously provided usage threshold is not received yet, the SCEF shall completely replace the previously provided one), and interact with the PCRF to modify the Rx session (as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13]). After receiving the response from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a "200 OK"status code and include the result in the body of the HTTP response, or a "204 No Content" status code.

NOTE 4: The SCS/AS can assume a successful resource allocation upon receipt of the POST/PUT/PATCH response, until the FAILED_RESOURCES_ALLOCATION event is received.

NOTE 5: The SCS/AS can update the list of user plane event(s) only for one time specific events, i.e. INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION, INDICATION_OF_FAILED_RESOURCES_ALLOCATION and USAGE_REPORT events, as specified in clause 5.3.13 of 3GPP TS 29.214 [10].

If the SCEF receives a traffic plane notification (e.g. the usage threshold is reached or transmission resource lost), or if the SCEF gets informed that the Rx session is terminated (e.g. due to a release of PDN connection), the SCEF shall send an HTTP POST message including the notified event (e.g. session terminated) and the accumulated usage (if received from the PCRF) to the callback URI "notificationUri" provided by the SCS/AS during the creation of individual AS Session with Required QoS Subscription. The SCS/AS shall respond with an HTTP response to confirm the received notification.

In order to remove the established AS session, the SCS/AS shall send an HTTP DELETE message to the SCEF for the "Individual AS Session with Required QoS Subscription" resource. After receiving the HTTP DELETE message, the SCEF shall remove all properties and interact with the PCRF to terminate the Rx session (as defined in 3GPP TS 29.214 [10] or 3GPP TS 29.201 [13]). After receiving the response from the PCRF, the SCEF shall send an HTTP response to the SCS/AS with a corresponding status code and include the accumulated usage (if received from the PCRF).

4.4.14 Procedures for MSISDN-less Mobile Originated SMS

4.4.14.1 General

The procedures are used by the SCEF to send the MSISDN-less MO-SMS to the SCS/AS via T8 interface.

4.4.14.2 Delivery of MSISDN-less MO SMS

If the SCEF receives an MSISDN-less MO-SMS via T4 including an destination SME address (long/short code of the SCS/AS), the SCEF will use the IMSI of the UE and application port ID received over T4 to query the HSS/HLR for an external ID, and the SCEF shall then determine the notification destination URL of an SCS/AS based on configured information on the mapping of SME addresses to destination URLs. The SCEF shall send to the determined destination URL an HTTP POST request that shall include an MsisdnLessMoSmsNotification data type with:

– the short message transfer protocol data unit as received on the T4 interface.

– the Application Port as received on the T4 interface, and

– the external identifier of the UE that send the SMS, as received from the HSS/HLR.

NOTE: The Notification Delivery using Websocket (see clause 5.2.5.4) and the Notification Test Event (see clause 5.2.5.3) are not supported for the present API.

4.4.15 Procedures for RACS Parameter Provisioning

The procedures are used by an SCS/AS to request that the network to provision manufacturer specific UE radio capability information.

In order to create a new parameter provisioning, the SCS/AS shall send an HTTP POST request message to the SCEF to the resource "RACS Parameter Provisionings". The body of the HTTP POST request message shall include a list of RACS IDs, and for each provided RACS ID, its radio capability parameters and the related UE model(s) IMEI-TAC value(s).

In order to fully replace an existing RACS Parameter Provisioning, the SCS/AS may send an HTTP PUT message to the resource "Individual RACS Parameter Provisioning" requesting the SCEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include a list of RACS IDs, and for each provided RACS ID, its radio capability parameters and the related UE model(s) IMEI-TAC value(s).

In order to partial update an existing RACS Parameter Provisioning, the SCS/AS may send an HTTP PATCH message to the resource "Individual RACS Parameter Provisioning" requesting the SCEF to change some properties in the existing resource.

Upon receipt of the HTTP POST, PUT or PATCH message, if the SCS/AS is authorized to perform the request, the SCEF shall interact with the UCMF as described in 3GPP TS 29.675 [61]. After receiving the response from the UCMF, if at least one RACS ID is succesfully provisioned, the SCEF shall create or update the resource "Individual RACS Parameter Provisioning" and respond with 201 Created or 200 OK to the SCS/AS respectively with the successfully provisioned RACS information or 204 No Content if the updates or replacement is successful with no content in the PATCH or PUT response message body, the SCEF may include RACS report(s) within attribute "racsReports" with a list of RACS ID(s) and the corresponding failure code for which the provisioning has failed as specified in table 5.16.2.2.3-1 in the body of the HTTP response. Otherwise, the SCEF shall send an HTTP response to the SCS/AS with a corresponding failure code as described in clause 5.16.5. If all the RACS IDs failed to be provisioned succeessfully, the SCEF may send a "500 Internal Server Error" HTTP response and may include in the response body failure reports as specified in clause 5.16.3.

In order to delete an existing RACS Parameter Provisioning at the SCEF, the SCS/AS shall send an HTTP DELETE message to the corresponding resource "Individual RACS Parameter Provisioning" at the SCEF. Upon receipt of the DELETE request message, the SCEF shall interact with the UCMF as described in 3GPP TS 29.675 [61]. After receiving the response from the UCMF, the SCEF shall remove the resource and respond with 204 No Content to the SCS/AS.