1. 3GPP interworking in R3 Group Name: ARC
Source: Jessie, Huawei,
Meeting Date:
Agenda Item: 3GPP interworking

2. 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
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

3. Backgrounds: 3GPP
The latest version of TS v 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.

4. 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.

5. Backgrounds: OMA
OMA ARC WG is working on the 3GPP network capability exposure APIs.
Communication pattern API has already been published:
Message Broadcast Network API is soon to be submitted for candidate approval (this set API is the implementation of 3GPP TS , and is not the same mechanism of MBMS based group message delivery specified in TS23.682):

6. 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.

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

8. 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 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 : Signalling sequence for provisioning of CP Parameters
TR-0024 Figure : Resource management for background data transfer

9. 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

10. 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.

11. 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.

12. Thank you