diff --git a/TS-0041-oneM2M-SensorThings_interworking.md b/TS-0041-oneM2M-SensorThings_interworking.md
index 033c86b598120087a26a0a9f86965e75294078b5..72cd7f9b67827aff3b89e32199ea0ad1baecc1d0 100644
--- a/TS-0041-oneM2M-SensorThings_interworking.md
+++ b/TS-0041-oneM2M-SensorThings_interworking.md
@@ -61,6 +61,7 @@ References are either specific (identified by date of publication and/or edition
- <a name="_ref_1">[1]</a> OGC SensorThings API "Part 1: Sensing Version 1.1" (http://www.opengis.net/doc/is/sensorthings/1.1)
- <a name="_ref_2">[2]</a> oneM2M TS-0033 (V3.0.0): "Interworking Framework"
+- <a name="_ref_3">[3]</a> oneM2M TS-0001 (V4.23.0): "Functional Architecture"
## 2.2 Informative references
@@ -163,11 +164,11 @@ The Sensing Entities data model and the purpose of data within the data model di
# 6 Architecture Model of OGC/STA to oneM2M interworking
-## 6.0 Introduction
+## 6.0 Overview
Figure 6.0-1 shows an architecture approach for an Interworking Proxy Entity (IPE) between oneM2M and the OGC SensorThings API. The IPE is located between a oneM2M CSE and an OGC/SensorThings API (STA)-Server.
-The basic interworking enables applications that are connected to an oneM2M-based system to get data from sensors that are connected to an OGC/STA server. Furthermore, an application that is connected to an OGC/STA server will be able to get data from sensors that are connected to an oneM2M-based system.
+The basic interworking enables applications that are connected to an oneM2M-based system to get data from sensors that are connected to an OGC/STA server. Furthermore, an application that is connected to an OGC/STA server will be able to get data from sensors that are connected to an oneM2M-based system. The communication flow of the IPE shall rely on HTTP and MQTT. The MQTT protocol enables publish-subscribe functionality for the OGC side, as specified in the MQTT extension of the SensorThings API <a href="#_ref_i.1">[i.1]</a>.
@@ -179,12 +180,69 @@ According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non-
- sensor (IoT-data); and
- administrative data (like historic locations or historic products IDs).
-The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'content' attribute of a oneM2M <contentInstance>, and vice versa as shown in Figure 6.1-1.
+The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'content' attribute of a oneM2M `<contentInstance>`, and vice versa as shown in Figure 6.1-1. The data type of the 'result' field of an "Observation" is according to SensorThings API <a href="#_ref_i.1">[i.1]</a> 'any' and depends on the 'observationType' defined in the associated "Datastream". The 'content' attribute of an oneM2M instance may be stringified data <a href="#_ref_3">[3]</a> understandable with the help of the 'contentInfo' attribute. The 'contentInfo' attribute on the oneM2M side may be added by the IPE. The original timestamps, present in the "Observation" as 'phenomenonTime' and in the `<contentInstance>` as "creationTime," shall be discarded. These timestamps are to be reset by the OGC /STA server and the CSE. They may be transmitted for informational purposes as part of the 'result' or the 'content' fields.
**Figure 6.1-1: OGC / STA-to-oneM2M data model mapping**
+## 6.2 Communication Flow
+
+Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. In order to transfer data from a oneM2M sensor to the OGC/STA server the IPE creates a `<subscription>` to the `<container>` resource in the CSE containing the desired data. Triggered by a sensor event a new `<contentInstance>` is added to the `<container>` by the `<AE>`. The IPE gets a `<notification>` containing the `<contentInstance>` resource.
+The IPE constructs an "Observation" creation request and copies the 'content' attribute of the `<contentInstance>` to the 'result' attribute of the "Observation" and sends it to a "Datastream" to be created as detailed in Section 6.3.1 at the OGC/STA server. The OGC/STA applcation gets the sensor data either by polling the OGC/STA server or subscribing to the corresponding "Datastream" at the MQTT broker of the OGC/STA server.
+
+
+
+**Figure 6.2-1: Communication oneM2M-to-OGC/STA direction**
+
+Figure 6.2-2 shows the OGC/STA-to-oneM2M direction. The IPE subscribes to the desired "Datastream" of the MQTT-Broker at the OGC/STA server. The OGC/STA server publishes a new "Observation" via the MQTT broker triggered by a OGC/STA sensor. The IPE creates a `<contentInstance>` in a container, to be created as detailed in Section 6.3.2 in the CSE and copies the 'result' attribute of the "Observation" to the 'content' attribute of the `<contentInstance>`. The oneM2M applcation gets the sensor data either by polling the CSE or subscribing to the desired `<container>` at the CSE.
+
+
+
+**Figure 6.2-2: Communication OGC/STA-to-oneM2M direction**
+
+
+<mark>The following text is to be used when appropriate:</mark>
+
+## 6.3 Configuration Aspects
+
+### 6.3.0 Introduction
+
+To enable interworking, preparation is required for both the oneM2M-CSE and the OGC/STA server (see Figure 6.3.0-1). As described in Section 6.0, the IPE maps data from an OGC/STA "Observation" to a oneM2M `<contentInstance>` and vice versa. This specification defines a 1-to-1 relationship in each direction between the "Datastream" associated with the "Observation" and the `<container>` associated with the `<contentInstance>`. An IPE may implement multiple 1-to-1 relationships.
+
+
+
+
+**Figure 6.3.0-1: Both sides of the IPE configuration**
+
+### 6.3.1 Configuration of OGC/STA Server Side
+
+#### 6.3.1.0 Overview
+
+Both directions of the data flow between the OGC/STA server and the IPE require their own configuration steps.
+
+#### 6.3.1.1 Communication direction OGC/STA Server towards IPE
+
+In Figure 6.3.1.1-1, an OGC/STA client is connected to an OGC/STA server, and its data is forwarded to the IPE. The OGC/STA client publishes data to the OGC/STA server via an HTTP-POST message.
+
+An "Observation" according to STA Sensing Entities Data Model <a href="#_ref_i.1">[i.1]</a> belongs to a "Datastream" (see Figure 5-2). The IPE shall subscribe to the "Datastream" containing the observations to be forwarded to the oneM2M side at the MQTT broker of the OGC/STA server using its specific URL or topic, e.g., {sta-example-server-address.com/v1.0/Datastreams(8715)}. Upon successful subscription, the IPE will receive every "Observation" pushed to that "Datastream".
+
+
+
+**Figure 6.3.1.1-1: Message flow from OGC/STA Client to OGC/STA Server to IPE**
+
+#### 6.3.1.2 Communication direction IPE towards OGC/STA Server
+
+The IPE requires a destination-"Datastream" to send an "Observation" containing data from the oneM2M side. If no associated "Datastream" exists on the OGC/STA server, it shall be created. This can be done beforehand or at the IPE's start-up, depending on the implementation.
+When a "Datastream" is created on the OGC/STA server, a reference ID (e.g. {"@iot.id:3635353"}) is returned. This reference is required by the IPE to associate an "Observation" with a "Datastream" and shall be available during IPE operation. In addition to the "Datastream" other entities of the STA Sensing Entities Data Model <a href="#_ref_i.1">[i.1]</a>, such as "Location" or "Sensor," may be created.
+
+The creation of entities like "Datastream" and "Thing" requires several mandatory properties that shall be known at configuration time (e.g., 'name' and 'description'). These property fields may be automatically derived, for example, from the "Label" or "ResourceName" attributes of the corresponding oneM2M `<container>` resource or if existing, from the corresponding `<AE>` resource during IPE configuration. The OGC/STA procedures for creating OGC entities are described in SensorThing API documentation <a href="#_ref_i.1">[i.1]</a>.
+
+Once the destination-"Datastream" is created, the IPE can send an "Observation" to the OGC/STA server as HTTP POST message. An interested OGC/STA client can subscribe to the destination-"Datastream" at the MQTT Broker of the OGC/STA server to receive each "Observation" forwarded by the IPE (see Figure 6.3.1.2-1). Alternatively, the OGC/STA client may use an HTTP-GET request to retrieve the data as needed.
+
+
+
+**Figure 6.3.1.2-1: Message flow from IPE to OGC/STA Server to OGC/STA Client**
### 6.3.2 Configuration of the oneM2M CSE
@@ -234,7 +292,6 @@ The detailed configuration steps are shown in Figure 6.3.2.2-2:
5) The hosting CSE evaluates the requests, performs the appropriate checks, and creates the `<container>` resource.
6) The hosting CSE responds with a successful result message upon successful creation of the `<container>` resource; otherwise, it responds with an error.
-
# Proforma copyright release text block
<mark>This text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or template which is intended to be copied by the user. Such an element shall always start on a new page.</mark>
diff --git a/media/com_flow_1.png b/media/com_flow_1.png
new file mode 100644
index 0000000000000000000000000000000000000000..45d6f7b2ff7cff3b79a7c7e1665476bcef07302a
Binary files /dev/null and b/media/com_flow_1.png differ
diff --git a/media/config.png b/media/config.png
new file mode 100644
index 0000000000000000000000000000000000000000..7cee63584178a8d1f6390121ea0ddf3d337fae24
Binary files /dev/null and b/media/config.png differ
diff --git a/media/config_ogc.png b/media/config_ogc.png
new file mode 100644
index 0000000000000000000000000000000000000000..8c12246ccc79e918bb313447cc8eba244ce52b97
Binary files /dev/null and b/media/config_ogc.png differ
diff --git a/media/config_ogc2.png b/media/config_ogc2.png
new file mode 100644
index 0000000000000000000000000000000000000000..495b7136a792070cdad84b54c6399fa45da34f20
Binary files /dev/null and b/media/config_ogc2.png differ