Chapter 5 content

TS-0041-oneM2M-SensorThings_interworking.md

@@ -76,7 +76,7 @@ The following referenced documents are necessary, partially or totally, for the
 - Use the **EX** style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).
 
 `EXAMPLE:`  
-- <a name="_ref_1">[1]</a>     ETSI TR 102 473: "&lt;Title>".
+- <a name="_ref_1">[1]</a>    OGC SensorThings API "Part 1: Sensing Version 1.1" (http://www.opengis.net/doc/is/sensorthings/1.1)
 
 ## 2.2 Informative references
 
@@ -87,7 +87,8 @@ The following referenced documents are not necessary for the application of the
 
 - Use the **EX** style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references).
 
-- <a href="#_ref_i.1">[i.1]</a>    oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)  
+- <a href="#_ref_i.1">[i.1]</a>    oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
+- <a href="#_ref_i.2">[i.2]</a>    OGC SensorThings API "Part 2 – Tasking Core" ( http://www.opengis.net/doc/IS/sensorthings-part2-TaskingCore/1.0)    
 
 
 # 3 Definition of terms, symbols and abbreviations
@@ -154,6 +155,28 @@ The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in
 # 5 Introduction to OGC SensorThings API
 &lt;Text>
 
+The SensorThings API (STA) is a standard of the Open Geospatial Consortium (OGC). It provides a framework for communication and exchanging data between sensors and applications. The standard is devided in two parts. SensorThings API Part 1 is dedicated to sensing and was published in 2016 and updated in 2021 <a href="#_ref_1">[1]</a>. Part 2 deals with tasking and was published in 2019 <a href="#_ref_i.2">[i.2]</a>.   
+A STA-based architecture works in client/server mode. A sensor device pushes data to the SensorThings Server via HTTP. A SensorThings Server may also support MQTT protocol to support publish and subscribe capabilities. An interested application can subscribe to the MQTT-Broker, in order to get notified about new sensor events.
+
+<figure>
+  <img src="media/sta_flow.png" alt="STA_message_flow">
+  <figcaption>Figure 5-1 STA message flow</figcaption>
+</figure>
+
+The data in the SensorThings server are organized as according to  “Sensing Entities” (see Figure 5.0-1: “Sensing Entities” data model).
+
+<figure>
+  <img src="media/data_model.jpg" alt="data_model">
+  <figcaption>Figure 5-1 STA Sensing Entities Data Model</figcaption>
+</figure>
+
+In the Sensing Entities Data Model events or sensor data are called "observations". Before a sensor is able to push an observation to the server it needs at least a 'Thing' and a 'Datastream' entity. This has to be created beforehand. One 'Thing' might have different 'Sensors', one 'Location' or many 'HistoricalLocations'.
+
+The Sensing Entities data model and the purpose of data within the data model discloses mainly two data characteristics, associated with a 'thing':
+-	Data observations originated by sensors or commands sent to interact with actuators may be seen as IoT data from oneM2M point of view.
+	While: 
+-	Data embedded in the Sensing Entities Data Model, like "historic locations" should be seen as data for documentation purposes.
+
 
 ## 5.1 User defined subdivisions of clause(s) from here onwards
 &lt;Text>