add chaper 6.2 architecture approach

TS-0041-oneM2M-SensorThings_interworking.md

@@ -198,7 +198,6 @@ This means that the OGC/STA data model is represented in the hosting CSE. The da
 The oneM2M structure for data models is a tree-structure where data are organized in containers or trees of containers. 
 The OGC/STA data model is a relational one, as used in databases, and not hierarchical. Thus, it creates a challenge for full interworking of all data captured in the OGC/STA data model. In this technical specification, only a limited set of data is mapped between OGC/STA and oneM2M.
 
-
 <figure>
   <img src="media/ogc_non_model.png" alt="non_mapping">
   <figcaption>Figure 6.1-1: OGC data model cannot directly be mapped to oneM2M</figcaption>
@@ -208,6 +207,31 @@ The SensorThings data model is comprehensive and may be regarded as a n:m relati
 - sensor (IoT-data); and 
 - administrative data (like historic locations or historic products IDs).
 
+## 6.2 Architecture Approach
+
+In order to transfer data from a oneM2M sensor to OGC/STA the IPE creates a <subscription> to the <container> resource with the desired data and when a new <contentInstance> is added it gets a <notification> message containing the <contentInstance> resource.
+Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. Based upon the creation of the <contentInstance> in the hosting CSE, the IPE gets a <notification> message including the <contentInstance>. The IPE constructs an "Observation" creation request and copies the 'content' attribute of the <contentInstance> to the 'result' attribute of the "Observation" shown in Figure 6.2-2 and sends it to the OGC/STA server.
+
+<figure>
+  <img src="media/onem2m_to_ogc_flow.png" alt="onem2m_to_ogc_flow">
+  <figcaption>Figure 6.2-1: IPE oneM2M-to-OGC/STA direction</figcaption>
+</figure>
+
+<figure>
+  <img src="media/content_copy.png" alt="content_to_observation_copy">
+  <figcaption>Figure 6.2-2: Copying content from CIN to observation</figcaption>
+</figure>
+
+Figure 6.2-3 shows the OGC/STA-to-oneM2M direction. OGC/STA does not provide a publish/subscribe mechanism on HTTP protocol level, but OGC allows an optional MQTT extension for STA services <a href="#_ref_1">[1]</a>. The IPE subscribes to the MQTT-Broker of the OGC/STA server. The OGC/STA server publishes its new "Observation" via the MQTT broker. The IPE creates a <contentInstance> using a HTTP request and copies the 'result' attribute of the "Observation" to the 'content' attribute of the <contentInstance>. The <container> should be created beforehand at the hosting CSE where the IPE <contentInstance> resources are stored. All interested applications may subscribe to this <container> resource.
+
+<figure>
+  <img src="media/ogc_to_onem2m_flow.png" alt="ogc_to_onem2m_flow">
+  <figcaption>Figure 6.2-3: IPE OGC/STA-to-oneM2M direction</figcaption>
+</figure>
+
+This approach is simple and sufficient in cases that only require translating "Observation" to <contentInstances> and vice-versa. Data are stored in the hosting CSE, but this is just a subset of the non-oneM2M proximal IoT function. These are only data that are being actually exchanged. The oneM2M client application is not able to gain additional information that are linked to an incoming "Observation" like "Location" or "Sensor". This kind of information would need to be exchanged upfront in the configuration phase described in clause 6.3. 
+
+
 <mark>The following text is to be used when appropriate:</mark>