1 Scope

Mass deployment of IoT devices, is causing an increased risk of signalling floods e.g. by concurrently transmitting IoT devices and hence causing a risk for the stability- and the efficient use of their mobile networks. One of the reasons is that IoT customers or integrators, often do not considering the specifics of mobile networks in their IoT device application design, subsequently causing inefficient communication or even loss of reachability. Operators are increasingly reporting problems from their live networks, like masses of concurrently resetting and reattaching devices within a small geographical region. Such events may cause their networks to collapse. GSMA has already flagged such events and has started to address the subject of badly behaving IoT devices / Applications. To avoid such scenarios upfront, GSMA released TS.34, "IoT Device Connection Efficiency Guideline" [1] . GSMA TS. 34 [1] gives guidance, which IoT device applications need to consider, to safely- and efficiently cooperate with cellular networks. However, the drawback of guidelines is the fact that the target audience: a.) needs to be aware of the existence of such guidelines and b.) needs to read, understand and follow such guidelines. This work aims to check and enhance oneM2M as an Embedded Service Layer in a way that the requirements formulated in GSMA TS.34 [1] are taken into account and Applications developed not considering requirements in GSMA TS.34 [1] , do not create adverse effects in the network, because the oneM2M as Embedded Service Layer is shielding the network from badly behaving applications. GSMA TS. 34 [1] is already referring towards an evolution of an IoT Service Architecture, where the IoT Device Applications are becoming disaggregated from an Embedded Service Layer. Such an Embedded Service Layer is providing several generic IoT functionalities (e.g. device management, security, location, application framework…). The common service layer specified by oneM2M complies to this IoT Service Architecture.

Figure 1-1: Generalised “Layered” IoT Service Architecture, as depicted GSMA TS 34 Figure 3

Applications being deployed on top of a common service layer are less critical to the network, because the common service layer takes over a protection role for the network. Inefficient or even harmful activities of applications would be prevented upfront and can’t hit the network. On the other hand, oneM2M provides functionality for the applications, e.g. scheduling transmissions according to the service needs. The recommended evolved architecture in GSMA TS.34 [1] (refer Figure 1X) aligns well with the oneM2M architecture shown in Fig 1-1.

Figure 1 2: oneM2M architecture for CIoT devices

oneM2M with the CSE functionality in between the IoT Application and the network connectivity, is well suited to enforce the requirements being addressed in GSMA TS.34 [1] , and hence protect the network from unwanted signalling floods and enforces an efficient communication, even if the Application (AE) has been created without GSMA TS.34 [1] knowledge or compliance. This TR is analysing which functionalities recommended by GSMA TS.34 [1] being in scope of an Embedded Service Layer are already covered by oneM2M functionality (e.g. like in CDMH), and which GSMA TS.34 [1] functionality is missing from oneM2M, to identify it and enhance oneM2M accordingly to meet the GSMA TS.34 [1] recommendations.