Background Data Transfer Group Name: WG2, ARC #27 Source: Catalina Mladin, Convida Wireless, Mladin.Catalina@convidawireles.com Quiting Li, ZTE, li.qiuting@zte.com.cn Meeting Date: 2017-02-13

Benefits of Background Data Transfer Network applications often need to send non-time-critical traffic to a set of field nodes that are communicating via an underlying network These network applications have a good idea about the amount of traffic that needs to be sent, but rarely know when is the best time to reach these field nodes At the same time, underlying networks, such as the 3GPP network, often have significant non-busy periods. These underlying networks may even provide some preferential treatment to encourage transmissions during these non-busy periods

Benefits of Background Data Transfer Pushing the non-time-critical traffic to these non-busy periods benefits both the network applications and the underlying network. The traffic is essentially transferred in the background

3GPP Background Data Transfer Through its capability exposure functionality, 3GPP has defined a mechanism that allows 3rd party applications to initiate a background transfer to a set of mobile UEs in a geographical area. For the 3GPP network, the preferential treatment offered is a reduction in transmission cost For the 3GPP network, the time windows are referred to as transfer policies The main use case they envisioned during the development of the feature was one where the application needs to initiate a push service (such as software upgrade or a music/video transfer) to a set of field nodes Note 1 Note: As part of their study, 3GPP concluded that this feature was different from OMA RESTful network API for QoS Note 2. “OMA API enables the application to tell the [3GPP] network in advance the time at which the application estimates there will be data transfer.” Note 1: TR 22.853 Note 2: OMA-TS-REST_NetAPI_QoS-V1_0-20151023-C

3GPP Background Data Transfer Step 1: SCS/AS determines that it has background data to send. It issues a Background Data transfer request message to SCEF. Request includes Volume of data to be transferred to the UEs Number of UEs participating in the transfer Desired time window for transfer Geographic area (optional) Note: TS 23.682

3GPP Background Data Transfer Step 2: SCEF authorizes the SCS/AS request Step 3: SCEF selects an available PCRF and then begins the negotiation of the future background data transfer procedure within the core network . PCRF provides SCEF a Reference ID and a list of transfer policies Note: TS 23.682

3GPP Background Data Transfer Step 4: SCEF uses a Background data transfer response to forward the Reference ID and the transfer policies to the SCS/AS Step 5-6: If more than one transfer policy is provided to the SCS/AS in Step 4, the SCS/AS selects one and notifies the network of its selection through the SCEF Note: TS 23.682

3GPP Background Data Transfer Step 7: SCEF continues the negotiation of background data transfer. Selected transfer policy is stored in SPR Step 8: SCS/AS uses the SCEF to trigger PCC procedures to provide the respective policing and charging information to the PCEF for the background data transfer of each specific UE. Note: TS 23.682

oneM2M using 3GPP Background Data Transfer Option 1 which we covered in the Tdoc from TP26 which shows that some IN-AE may be “smart” enough to negotiate the background transfer directly with the core network. So these AEs can understand transfer policies. Option 2, which is covered in companion Tdoc in TP27, shows the case where the negotiation is abstracted from the AE. The AE lets the IN-CSE negotiate with the core network

Appendix OMA RESTful Network API for Quality of Service As of version 1.0, supports the following operations: Retrieve a list of predefined QoS features available to an end user Request to apply a predefined QoS feature on an end user connection on a temporary basis Request to apply a specific QoS feature on an end user connection on a temporary basis Retrieve QoS features currently applied on an end user connection Update a QoS feature currently applied on an end user connection Update an individual attribute (e.g. duration) for QoS feature applied on an end user connection Manage subscriptions to notifications on availability of a predefined QoS feature(s) to an end user Notify a client when a predefined QoS feature(s) became available again to an end user Manage subscriptions to notifications about events occurring for QoS feature applied on an end user connection Notify a client about an event occurred for QoS feature applied on an end user connection OMA API can be used to allow applications to tell the network about the QoS that end user will transmit (priority, duration, volume of data). Network should react accordingly to meet this QoS. Background Data Transfer can be used to allow applications to tell the network about the QoS that end user wants to transmit. Network can suggest to the application the best time for this transmission.