Skip to content
Snippets Groups Projects

SDS-2024-0141R02-ogc_ipe_communication_schema

Merged SDS-2024-0141R02-ogc_ipe_communication_schema
SDS-2024-0141-ogc_ipe_communication_schema into R5
Merged Ingo Friese requested to merge SDS-2024-0141-ogc_ipe_communication_schema into R5
Viewing commit 60238818
Prev Next
Show latest version
1 file
+ 2
− 2
Compare changes
  • Side-by-side
  • Inline
TS-0041-oneM2M-SensorThings_interworking.md
+ 2
− 2
@@ -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.
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)
@@ -179,7 +179,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 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)