Skip to content
Snippets Groups Projects
Commit 60238818 authored by Ingo Friese's avatar Ingo Friese
Browse files

Update file TS-0041-oneM2M-SensorThings_interworking.md

parent 95a6258e
No related branches found
No related tags found
1 merge request!9SDS-2024-0141R02-ogc_ipe_communication_schema
Pipeline #1768 passed
This commit is part of merge request !9. Comments created here will be created in the context of that merge request.
...@@ -167,7 +167,7 @@ The Sensing Entities data model and the purpose of data within the data model di ...@@ -167,7 +167,7 @@ The Sensing Entities data model and the purpose of data within the data model di
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. 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 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>. 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>.
![Figure 6.0-1: IPE architecture overview](media/STA_oneM2M_architekturbild_01.svg) ![Figure 6.0-1: IPE architecture overview](media/STA_oneM2M_architekturbild_01.svg)
...@@ -179,7 +179,7 @@ According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non- ...@@ -179,7 +179,7 @@ According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non-
- sensor (IoT-data); and - sensor (IoT-data); and
- administrative data (like historic locations or historic products IDs). - 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 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.
![Figure 6.1-1: OGC / STA-to-oneM2M data model mapping](media/data_mapping.svg) ![Figure 6.1-1: OGC / STA-to-oneM2M data model mapping](media/data_mapping.svg)
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment