@@ -48,27 +48,27 @@ NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURA
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" [i.1].
GSMA TS. 34 [i.1] gives guidance, which IoT device applications need to consider, to safely- and efficiently cooperate with cellular networks.
To avoid such scenarios upfront, GSMA released TS.34, "IoT Device Connection Efficiency Guideline" <ahref="#_ref_1">[1]</a>.
GSMA TS. 34 <ahref="#_ref_1">[1]</a> 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 [i.1] are taken into account and Applications developed not considering requirements in GSMA TS.34 [i.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 [i.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.
This work aims to check and enhance oneM2M as an Embedded Service Layer in a way that the requirements formulated in GSMA TS.34 <ahref="#_ref_1">[1]</a> are taken into account and Applications developed not considering requirements in GSMA TS.34 <ahref="#_ref_1">[1]</a>, 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 <ahref="#_ref_1">[1]</a> 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 [i.1] (refer Figure 1X) aligns well with the oneM2M architecture shown in Fig 1-1.
The recommended evolved architecture in GSMA TS.34 <ahref="#_ref_1">[1]</a> (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 [i.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 [i.1] knowledge or compliance.
This TR is analysing which functionalities recommended by GSMA TS.34 [i.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 [i.1] functionality is missing from oneM2M, to identify it and enhance oneM2M accordingly to meet the GSMA TS.34 [i.1] recommendations.
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 <ahref="#_ref_1">[1]</a>, 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 <ahref="#_ref_1">[1]</a> knowledge or compliance.
This TR is analysing which functionalities recommended by GSMA TS.34 <ahref="#_ref_1">[1]</a> being in scope of an Embedded Service Layer are already covered by oneM2M functionality (e.g. like in CDMH), and which GSMA TS.34 <ahref="#_ref_1">[1]</a> functionality is missing from oneM2M, to identify it and enhance oneM2M accordingly to meet the GSMA TS.34 <ahref="#_ref_1">[1]</a> recommendations.
...
...
@@ -91,12 +91,12 @@ Not applicable.
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
# 3 Definition of terms, symbols and abbreviations
<mark>Delete from the above heading the word(s) which is/are not applicable.</mark>
...
...
@@ -137,7 +137,7 @@ For the purposes of the present document, the [following] abbreviations [given i
# 4 Conventions
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules <ahref="#_ref_i.1">[i.1]</a>
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules <ahref="#_ref_i.2">[i.2]</a>
# 5 Analysis of GSMA TS.34 Requirements
...
...
@@ -145,13 +145,13 @@ The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in
## 5.1 Introduction
GSMA TS.34 [i.1] represents a guideline and giving requirements for whole IoT Device, as defined in Figure X to ensure an efficient connection.
GSMA TS.34 <ahref="#_ref_1">[1]</a> represents a guideline and giving requirements for whole IoT Device, as defined in Figure X to ensure an efficient connection.
![Figure 5.1-1: Generalised IoT Device Architecture according to GSMA TS.34 [i.1]](media/Fig3.png)
**Figure 5.1-1: Generalised IoT Device Architecture according to GSMA TS.34 [i.1]**
**Figure 5.1-1: Generalised IoT Device Architecture according to GSMA TS.34<a href="#_ref_1">[1]</a>**
Requirements with regards to an efficient communication are grouped and categorized in TS.34 [i.1]. E.g. requirements are formulated for the following areas:
Requirements with regards to an efficient communication are grouped and categorized in TS.34 <ahref="#_ref_1">[1]</a>. E.g. requirements are formulated for the following areas:
- IoT Device Application Requirements
- Communication Module Requirements
...
...
@@ -162,23 +162,23 @@ Requirements with regards to an efficient communication are grouped and categori
oneM2M is most beneficially able to support an efficient communication in the area of the IoT Device Application, while other areas, like required support of "3GPP Connection Efficiency Features" can be considered out of scope of oneM2M, and hence out of scope of this WI.
With regards to "IoT Device Application Requirements", GSMA TS.34 [i.1] differentiates further between:
With regards to "IoT Device Application Requirements", GSMA TS.34 <ahref="#_ref_1">[1]</a> differentiates further between:
1. Monolithic IoT Device Application Requirements: Those requirements are applicable for devices without an embedded Service layer and hence are out of scope oneM2M anyway.
2. Tiered IoT Device Applications Requirements: Those requirements are applicable for applications providing the required functionality according to GSMA TS.34 [i.1], cooperatively together with the embedded Service layer.
2. Tiered IoT Device Applications Requirements: Those requirements are applicable for applications providing the required functionality according to GSMA TS.34 <ahref="#_ref_1">[1]</a>, cooperatively together with the embedded Service layer.
.
3. IoT Embedded Service Layer Requirements: Those requirements are applicable for the embedded Service layer, providing the required functionality according to GSMA TS.34 [i.1]
While the main focus of this work is primarily on 2) and 3) further requirements in GSMA TS.34 [i.1] have been screened, analysed and used to inspire functionality to be taken for oneM2M to ensure an efficient IoT communication.
While the main focus of this work is primarily on 2) and 3) further requirements in GSMA TS.34 <ahref="#_ref_1">[1]</a> have been screened, analysed and used to inspire functionality to be taken for oneM2M to ensure an efficient IoT communication.
The considered Requirements out of GSMA TS.34 [i.1] in the context of oneM2M are listed in the subsequent sections, with the respective numbering schema kept as used in TS.34 [i.1], for your reference.
The considered Requirements out of GSMA TS.34 <ahref="#_ref_1">[1]</a> in the context of oneM2M are listed in the subsequent sections, with the respective numbering schema kept as used in TS.34 <ahref="#_ref_1">[1]</a>, for your reference.
## 5.2 IoT Device Requirements
**Table 5.2-1: GSMA defined requirements from GSMA TS 34 [i.1]**
| Requirement ID | Description from GSMA TS 34 [i.1] | Reference clause |
**Table 5.2-1: GSMA defined requirements from GSMA TS 34 <a href="#_ref_1">[1]</a> **
| Requirement ID | Description from GSMA TS 34 <ahref="#_ref_1">[1]</a> | Reference clause |
| ------ | ------ | ------ |
|TS.34_3.0_REQ_001|The IoT Device SHOULD conform to all IoT Device Application requirements defined in TS.34, section 4.| 5.4 |
|TS.34_3.0_REQ_002|The IoT Device SHALL conform to all Communication Module requirements defined in TS.34, section 5.| Not within the scope of oneM2M|
...
...
@@ -187,7 +187,7 @@ The considered Requirements out of GSMA TS.34 [i.1] in the context of oneM2M are
## 5.3 IOT Device Application Requirements
This clause is derived from GSMA TS.34 [i.1], clause 4. Two architectures are described in GSMA TS.34 [i.1], where the IoT Device application can be a monolithic application that meets all the requirements in clause 4.0 or an evolved architecture that separates the device application requirements into clause 4.1 and the IoT embedded service layer requirements into clause 4.2. This technical report addresses the evolved architecture.
This clause is derived from GSMA TS.34 <ahref="#_ref_1">[1]</a>, clause 4. Two architectures are described in GSMA TS.34 <ahref="#_ref_1">[1]</a>, where the IoT Device application can be a monolithic application that meets all the requirements in clause 4.0 or an evolved architecture that separates the device application requirements into clause 4.1 and the IoT embedded service layer requirements into clause 4.2. This technical report addresses the evolved architecture.
The remainder of this section is organized by the components shown in figure 5.3-1.
...
...
@@ -199,7 +199,7 @@ The remainder of this section is organized by the components shown in figure 5.3
In the GSMA evolved architecture the Tiered IoT Device Application performs the business logic of the IoT solution. The GSMA requirements for such an application are captured in table 5.4-1.
**Table 5.4 1: Tiered IoT Device Requirements**
| Requirement ID | Description from GSMA TS 34 [i.1] | Reference clause |
| Requirement ID | Description from GSMA TS 34 <ahref="#_ref_1">[1]</a> | Reference clause |
| ------ | ------ | ------ |
|TS.34_4.1_REQ_001|If data speed and latency is critical to the IoT Service the IoT Device Application should be able to retrieve mobile network speed and connection quality information from the IoT Embedded Service Layer in order to request the appropriate quality of content from the IoT Service Platform.|See clause 6.1 |
|TS.34_4.1_REQ_002|The IoT Device Application should always be prepared to handle situations when communication requests fail, when such failure is reported by the IoT Embedded Service Layer.|See clause 6.2 |
