cleanup communication flow

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
 
@@ -179,7 +180,7 @@ 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 &lt;contentInstance&gt;, and vice versa as shown in Figure 6.1-1. The data type of the 'result' field of an "Observation" is acording 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 opaque data 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 &lt;contentInstance&gt; as "creationTime," shall be discarded. These timestamps are to be reset by the OGC/STA server and the CSE, respectively. They may be transmitted for informational purposes as part of the 'result' or the 'content' fields.
+The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'content' attribute of a oneM2M &lt;contentInstance&gt;, and vice versa as shown in Figure 6.1-1. The data type of the 'result' field of an "Observation" is acording 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 opaque 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 &lt;contentInstance&gt; as "creationTime," shall be discarded. These timestamps are to be reset by the OGC/STA server and the CSE, respectively. 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](media/data_mapping.svg)
 
@@ -187,14 +188,14 @@ The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'con
 
 ## 6.2 Communication Flow
 
-In order to transfer data from a oneM2M sensor to OGC/STA the IPE creates a &lt;subscription&gt; to the &lt;container&gt; resource with the desired data and when a new &lt;contentInstance&gt; is added it gets a &lt;notification&gt; message containing the &lt;contentInstance&gt; resource.
-Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. Based upon the creation of the &lt;contentInstance&gt; in the hosting CSE, the IPE gets a &lt;notification&gt; message including the &lt;contentInstance&gt;. The IPE constructs an "Observation" creation request and copies the 'content' attribute of the &lt;contentInstance&gt; to the 'result' attribute of the "Observation" shown in Figure 6.1-1 and sends it to the OGC/STA server.
+Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. In order to transfer data from a oneM2M sensor to OGC/STA the IPE creates a &lt;subscription&gt; to the &lt;container&gt; resource in the CSE containing the desired data. Triggert by a sensor event a new &lt;contentInstance&gt; is added to the &lt;container&gt; by the &lt;AE&gt;. The IPE gets a &lt;notification&gt; message containing the &lt;contentInstance&gt; resource.
+The IPE constructs an "Observation" creation request and copies the 'content' attribute of the &lt;contentInstance&gt; to the 'result' attribute of the "Observation" and sends it to the OGC/STA server. The OGC / STA applcation gets the sensor data either by polling the OGC / STA server or subscribing to the regarded "Datastream" at the MQTT broker of the OGC / STA server.
 
 ![Figure 6.2-1: Communication oneM2M-to-OGC/STA direction](media/com_flow_1.png)
 
 **Figure 6.2-1: Communication oneM2M-to-OGC/STA direction** 
 
-Figure 6.2-2 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_i.1">[i.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 &lt;contentInstance&gt; using a HTTP request and copies the 'result' attribute of the "Observation" to the 'content' attribute of the &lt;contentInstance&gt;. The &lt;container&gt; may be created beforehand at the hosting CSE where the IPE &lt;contentInstance&gt; resources are stored. All interested applications may subscribe to this &lt;container&gt; resource.
+Figure 6.2-2 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_i.1">[i.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 &lt;contentInstance&gt; using a HTTP request and copies the 'result' attribute of the "Observation" to the 'content' attribute of the &lt;contentInstance&gt;.
 
 ![Figure 6.2-2: Communication OGC/STA-to-oneM2M direction](media/com_flow_2.png)