Minor updates to 6.3.2 and 6.3.3

### 6.3.2	oneM2M Architecture

The oneM2M service layer is a general-purpose standard that applies to all industry verticals. It brings together all components in the IoT solution stack and specifies a distributed software/middleware layer, sitting between applications and underlying communication networking HW/SW. 

oneM2M service layer can be integrated into devices, gateways, and servers. This figure shows a simplified oneM2M simplified architecture:

<img src="/media/oneM2M architecture.png" width="900" height="500">

oneM2M service layer can be integrated into devices, gateways, and servers. Figure 6.3.2-1 shows a simplified oneM2M architecture:

![Figure 6.3.2-1: oneM2M architecture.](/media/oneM2M architecture.png)

**Figure 6.3.2-1: oneM2M architecture**

This architecture is composed of the following entities:

- *Common Services Entity (CSE)*: Provides the set of "service functions" that are common to the IoT domains

- *Application Entity (AE)*: Represents application logic for the end-to-end IoT solutions. This includes device firmware, gateway logic or backend applications

- *Interworking Proxy application Entity (IPE)*:  An AE that is used to interface between oneM2M and an external system

- *Network Services Entity*: Provides services to the CSEs beyond the data transport

- *Node*: Logical equivalent of a physical (or possibly virtualized) server or device

- *IPE*: Logical equivalent of a physical (or possibly virtualized) server or device

In particular, oneM2M defines several different kinds of nodes, which are named based on the specific instantiation option considered:

In particular, oneM2M defines several different kinds of node, which are named based on the specific instantiation option considered:

- *Application Service Node* (ASN) at the Edge device / Gateway (GW)

- *Middle Node (MN)* An Edge Node / Gateway (GW)

- *Infrastructure Node (IN)* A Cloud provider / company server

- *Infrastructure Node (IN)* A ervers belonging to other companies or cloud providers

In addition, the oneM2M architecture supports another type of node, the so-called “Non-oneM2M Node” (NoDN), not shown in the figure above. This is a node that does not contain native 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 or agents.

In addition, the oneM2M architecture supports another type of node, the so-called “Non-oneM2M Node” (NoDN), not shown in Figure 6.3.2-1. This is a node that does not contain native 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 or agents.

The principal *Reference Points* defined by oneM2M are:

- *Mca*: The interface used by an AE to use the common services provided by the CSE

- *Mcn*: Communication flows between a Common Services Entity (CSE) and the Network Services Entity (NSE) allowing the CSE to use the network services (other than transport and connectivity) provided by the NSE.

### 6.3.3    oneM2M Architecture oneM2M Common Service Layer Functions

From a functional perspective, oneM2M has defined fourteen common service functions (CSFs) as shown in the figure below. These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies.

<img src="/media/oneM2M CSFs.png" width="900" height="500">

From a functional perspective, oneM2M has defined fourteen common service functions (CSFs) as shown in Figure 6.3.3-1 below. These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies.

![Figure 6.3.3-1: Common Service Functions.](/media/oneM2M CSFs.png)

**Figure 6.3.3-1: Common Service Functions**

These oneM2M services are defined so that application developers can focus on application-specific functionality (e.g., turning a switch on or off), while relying on abstractions provided by oneM2M to mask the underlying technology-specific details, thus allowing bindings to different communications stacks and protocols such as HTTP, CoAP and MQTT. For example, a simple switch might use a fixed or Wi-Fi network, a CoAP or HTTP transport. It might use a JSON or XML serialization, an Open Connectivity Foundation (OCF) or thread service enablement, or an ontology based on Smart Appliances REFerence (SAREF) or W3C’s Thing Description.