Why are INs usually deployed in Cloud -IOT

Question 1: Why are INs usually deployed  in Cloud? 

Infrastructure Node (IN): a Node that contains one CSE and could also contain AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider.

Question 2: Can you explain "interworking" in the oneM2M Network by the picture  given below?

Application Service Node (ASN): a Node that contains one CSE and contains at least one Application Entity (AE), located in the Field Domain. An ASN could be implemented on a range of different devices ranging from resource constrained devices up to more powerful hardware. Examples of devices that could be represented by ASNs include data collection devices, more capable sensors and actuators including simple server functions.

Application Dedicated Node (ADN): a Node that contains at least one AE and does not contain a CSE. It is located in the Field Domain. An ADN would typically be implemented on a resource constrained device that may not have access to ample storage or processing resources and – therefore – may be limited to only host a oneM2M AE and not a CSE. Examples for devices that could be represented by ADNs include simple sensor or actuator devices.

Middle Node (MN): a Node that contains one CSE and could also contain AEs. MNs are located in the Field Domain. There could be several MNs in the Field Domain of the oneM2M System.

 Typically an MN would reside in an M2M Gateway. MNs would be used to establish a logical tree structure of oneM2M nodes, e.g. to hierarchically aggregate data of buildings / neighborhoods / cities / counties / states etc.

Infrastructure Node (IN): a Node that contains one CSE and could also contain AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider.

Non-oneM2M Node (NoDN): A Node that does not contain oneM2M Entities (neither AEs nor CSEs). Typically such Nodes would host some non-oneM2M IoT implementations or legacy technology which can be connected to the oneM2M system via interworking proxies.

 

Question 3: Can you explain the TS-0009?

TS-0009 (HTTP Protocol Binding)

Overview

HTTP binding specifies the equivalence between oneM2M request and response primitives and HTTP request and response messages, respectively. This clause provides a brief overview on the mapping relationship between oneM2M and HTTP message parameters. This clause describes how oneM2M request/response primitives can be mapped to HTTP request/response messages and vice versa.

Introduction

Figure 5.1-1 illustrates an example oneM2M system configuration and its correspondence to an HTTP-based information system if HTTP binding as defined in this specification is applied. The upper diagram in figure 5.1-1 shows with solid line arrows the flow of a request primitive originating from an AE which is registered to an MN-CSE (Registrar of AE). The request primitive is assumed to address a resource which is hosted by another MN-CSE (Host of Resource). Both MN-CSEs are registered to the same IN-CSE. When applying HTTP binding, the oneM2M entities of the upper diagram take the roles outlined in the lower diagram of a corresponding HTTP information system as defined in IETF RFC 7230 [1]. The AE takes the role of an HTTP client, the MN-CSE (Registrar of AE) takes the role of a HTTP Proxy Server, and both the IN-CSE and MN-CSE (Host of Resource) take the role of a HTTP server for this particular request message.

CSEs may also issue unsolicited request messages, shown with dashed line arrows in figure 5.1-1, and receive associated response messages. Therefore, for HTTP protocol binding, CSEs generally provides capability of both HTTP Server and HTTP Client. AEs may provide HTTP Server capability optionally in order to be able to serve Notification request messages (see TS-0004 [3] and TS-0001 [7]).

Each individual request primitive will be mapped to single HTTP request message, and each individual response primitive will be mapped to a single HTTP response message, and vice-versa. An HTTP request message consists of Request-Line, headers and message-body. An HTTP response message consists of Status-Line, headers and message-body [1]. HTTP header names are case-insensitive and a Receiver shall accept headers that are either lower or upper or any mixture thereof. This clause describes how oneM2M request/response primitives are mapped to HTTP messages at a high level. Corresponding details are specified in clause 6.

Request-Line

The HTTP method of a request message is mapped to the Operation parameter, and vice-versa. At the message originator side the HTTP Request-Target is derived from the To parameter of the request primitive, including a query string which carries other specific primitive parameters. HTTP-Version is specified in clause 6.

Status-Line HTTP Version is specified in clause 6.

The Status-Code of HTTP response messages is derived from the Response Status Code parameter of the response primitive. The Reason-Phrase is not applicable to oneM2M systems and is omitted.

Question 4: Can you explain the TS-0008?

TS-0008 (CoAP Protocol Binding)

Abbreviations and acronyms

For the purposes of the present document, the following abbreviations and acronyms apply:

DTLS Datagram Transport Layer Security

HTTP Hyper Text Transfer Protocol

IP Internet Protocol

TCP Transport Control Protocol

TLS Transport Layer Security

TLV Tag - Length - Value (data structure)

UDP User Datagram Protocol

URI Uniform Resource Identifier

Required Features

This clause explicitely specifies the required features of the CoAP layer for oneM2M to propery bind oneM2M primitives into CoAP messages.

• The 4-byte binary CoAP message header is defined in Section 3 of [1].

• Confirmable (CON), Acknowledgement (ACK) and Reset (RST) messages shall be supported. The Reset message is used to send a error message in response to a malformed Confirmable message in CoAP layer.

• GET, PUT, POST and DELETE methods shall be supported. oneM2M primitives map to these methods.

• A subset of Response Code specified in clause 6.2.4 shall be supported for oneM2M Response Status Code parameter mapping.

• The Uri-Host, Uri-Port, Uri-Path, and Uri-Query shall be supported

• The Content-Type Option shall be used to indicate the media types of the payload.

• The Token Option may be used.

• Block-wise transfers feature may be supported to carry large payloads.

• Caching feature may be supported.

Quesyion 5: Can you explain the TS-0010?

TS-0010 (MQTT Protocol Binding). 

Abbreviations For the purposes of the present document, the abbreviations given in oneM2M TS-0001 [2] and the following apply:

ADN Application Dedicated Node

ADN-AE AE which resides in the Application Dedicated Node

AE Application Entity

ASN Application Service Node

CSE Common Service Entity

IN Infrastructure Node

IN-AE Application Entity that is registered with the

CSE in the Infrastructure Node

IN-CSE CSE which resides in the Infrastructure Node

MN Middle Node MN-CSE CSE which resides in the Middle Node

TLS Transport Level Security

Use of MQTT

 This binding makes use of MQTT to provide reliable two-way communications between two parties (AEs and CSEs). It uses the following features of MQTT:

• Durable Sessions, providing Store and Forward in cases where network connectivity is not available.

• MQTT's "QoS 1" message reliability level. This provides reliability without incurring the overhead implied by QoS 2.

---