3GPP interworking in R3 Group Name: ARC Source: Jessie, Huawei, lijing80@huawei.com Meeting Date: 2016-07-08 Agenda Item: 3GPP interworking

Backgrounds of this contribution The objective of WI-0037 is to study and specify interworking options between oneM2M architecture and 3GPP Rel-13 architecture for Service Capability Exposure as defined in TS 23.682. There are several service capability exposure features defined in 3GPP Rel-13 (listed as below), but due to the limited time in R2, only two features (green ones) are specified in TS-0001 and few features are studied in TR-0024 (red ones). Device triggering procedures Information Storage Group message delivery procedures Monitoring Procedures High latency communications procedures Informing about Potential Network Issues Background data transfer Communication Pattern parameters provisioning procedure Setting up an AS session with required QoS procedure Change the chargeable party at session set-up or during the session Non-IP Data Delivery procedures for NB-IoT It is expected to continue the work in R3 and this contribution is to provide some input to kickoff the discussion about how this work could be done in R3. This contribution includes the following content: Some 3GPP interworking related information about other SDOs are provided for oneM2M reference Some consideration and proposals about the work scope and priority

Backgrounds: 3GPP The latest version of TS 23.682 v13.6.0 are released in June. Compared to the old version, the main changes are: The 3GPP Architecture for Machine-Type Communication is updated. SCEF is explicitly drawn in the architecture and it is clear stated that SCEF is in the trusted 3GPP operator network domain. NIDD (non-IP data delivery) are enhanced in several aspects, for example: new interface T6a/b between SCEF and MME/SGSN are added to implement the device triggering function, and correspondingly the T5 interface is deleted. High Latency Communication procedure is added to the NIDD procedure to handle both both PSM (Power Saving Mode) and eDRX. The interfaces T5a/b/c between MTC-IWF and SGSN/MME/MSC are deleted and new interface T6a/b between SCEF and MME/SGSN are added in the architecture. The reason is that T5 device triggering functionality can be provided using mobile terminated NIDD procedure over T6a/b reference points. Therefore there is no need to specify T5a/b/c. SCEF, not MME, is responsible for buffering data exchanged for PDN connection. High Latency Communication procedure is added to the NIDD procedure to handle both both PSM (Power Saving Mode) and eDRX.

Backgrounds: GSMA NB-IoT Forum The GSMA NB-IoT Forum is working on a white paper to study the device management and service enablement requirements for NB-IoT low power wide area technology. The first version of the white paper is going to be published at the end of July. The white paper will figure out the API requirements for NB-IoT device management and NB-IoT service enablement to expose 3GPP network service capabilities to the application server.

Backgrounds: OMA OMA ARC WG is working on the 3GPP network capability exposure APIs. Communication pattern API has already been published: http://member.openmobilealliance.org/ftp/Public_documents/ARCH/REST_ComPatt/Permanent_documents/OMA-TS-REST_NetAPI_CommunicationPatterns-V1_0-20160416-D.zip Message Broadcast Network API is soon to be submitted for candidate approval (this set API is the implementation of 3GPP TS29.199-15, and is not the same mechanism of MBMS based group message delivery specified in TS23.682): http://member.openmobilealliance.org/ftp/Public_documents/ARCH/REST_MsgBCast/Permanent_documents/OMA-TS-REST_NetAPI_MsgBCast-V1_0-20160708-D.zip

Backgrounds: oneM2M 3GPP interworking WI R2 have been completed with the specification of two features: Device triggering Configuration of Traffic Patterns oneM2M IN-CSE is considered as the SCS entity defined in the 3GPP specification. The IN-CSE communicates with the 3GPP network either directly via the reference points of the applicable nodes within the 3GPP network, or via SCEF provided APIs.

What should be done in oneM2M R3 While NB-IoT and other 3GPP network capabilities are heated discussed in other SDOs, oneM2M should also consider to choose some important 3GPP network capabilities and to complete the standardization work as soon as possible, in order to enhance the ability to integrate the telecommunication network and reflect the unique value of oneM2M platform compared to other IoT platforms.

Proposal 1: update R2 to ensure the alignment with 3GPP The concepts of SCS and SCEF are confused and misleading in R2 specifications. According to 3GPP TS 23.682 and the consensus of oneM2M, oneM2M IN-CSE should be mapped to SCS, but in many figures in TS-0001 and TR-0024, IN-CSE is always mapped to SCEF and SCS is illustrated as another separate entity which is mapped to AS. TS-0001 Figure B.2.2.2-1: Signalling sequence for provisioning of CP Parameters TR-0024 Figure 8.4.2-1: Resource management for background data transfer

Proposal 2: The priority of the 3GPP interworking features The 3GPP interworking features not specified in R2 are classified to two categories and highlighted to two different colors. The green colored features are either are NB-IoT related or pre-studied features in R2, so it is proposed to specify these features in a higher priority. NB-IoT support NB-IoT device Management on oneM2M platform (IP/Non-IP)) Non-IP Data Delivery UE context information storage for device trigger and NIDD (PSM/eDRX timer) (related to NB-IoT) High latency communications (related to NB-IoT) Monitoring (related to NB-IoT) Group message delivery Informing about Potential Network Issues Setting up an AS session with required QoS procedure Resource management of background data transfer Change the chargeable party at session set-up or during the session procedure

Proposal 3: keep align with 3GPP and OMA on Mcn interface Either the 3GPP network exposed interface or the OMA provided API are considered as the Mcn interface from the oneM2M point of view and are not in the specification scope of oneM2M. oneM2M mainly focuses on the APIs of the northbound Mca interface toward applications. But Whether the APIs provided by OMA are sufficient to support the service capabilities exposed to the application on the Mca interface Whether this is a gap between the Mca interface and the Mcn interface Whether there are new requirements to the Mcn interface, from the view of the service enablement platform These questions have not been studied in R2 and may be we should have a look on this in R3. The 3GPP interworking feature will not work, if there is any misalignment between Mca and Mcn interface.

Proposal 4: the unique value of the Mca APIs The SCEF APIs provided by OMA abstracts the services from the underlying 3GPP network interfaces and protocols. Compared to the OMA APIs, Mca APIs specified by oneM2M should be a more higher level API, not only reflecting some necessary 3GPP network capabilities but also integrating some value added service capabilities provided by oneM2M platform. This is the competitive advantages to promote oneM2M Mca APIs in the industry.

Thank you