Content for  TS 29.122  Word version:  19.0.0

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 TS 29.154. 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 TS 29.154. 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. 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 TS 29.154. 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.

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 TS 29.214 or TS 29.201, 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. 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 TS 29.214 or TS 29.201. 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. 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 TS 29.214 or TS 29.201). 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).