Skip to content
Snippets Groups Projects
Commit 159317c3 authored by Andreas Neubacher's avatar Andreas Neubacher
Browse files

Contribution SDS-2024-0141R02-ogc_ipe_communication_schema merged into R5

Original contribution: SDS-2024-0141-ogc_ipe_communication_schema

See merge request !9
parents 2a7da3f2 5b35bbd5
No related branches found
No related tags found
1 merge request!9SDS-2024-0141R02-ogc_ipe_communication_schema
......@@ -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
......@@ -163,11 +164,11 @@ The Sensing Entities data model and the purpose of data within the data model di
# 6 Architecture Model of OGC/STA to oneM2M interworking
## 6.0 Introduction
## 6.0 Overview
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 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,12 +180,28 @@ 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 `<contentInstance>`, and vice versa as shown in Figure 6.1-1. The data type of the 'result' field of an "Observation" is according 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 stringified 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 `<contentInstance>` as "creationTime," shall be discarded. These timestamps are to be reset by the OGC /STA server and the CSE. 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**
## 6.2 Communication Flow
Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. In order to transfer data from a oneM2M sensor to the OGC/STA server the IPE creates a `<subscription>` to the `<container>` resource in the CSE containing the desired data. Triggered by a sensor event a new `<contentInstance>` is added to the `<container>` by the `<AE>`. The IPE gets a `<notification>` containing the `<contentInstance>` resource.
The IPE constructs an "Observation" creation request and copies the 'content' attribute of the `<contentInstance>` to the 'result' attribute of the "Observation" and sends it to a "Datastream" to be created as detailed in Section 6.3.1 at the OGC/STA server. The OGC/STA applcation gets the sensor data either by polling the OGC/STA server or subscribing to the corresponding "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. The IPE subscribes to the desired "Datastream" of the MQTT-Broker at the OGC/STA server. The OGC/STA server publishes a new "Observation" via the MQTT broker triggered by a OGC/STA sensor. The IPE creates a `<contentInstance>` in a container, to be created as detailed in Section 6.3.2 in the CSE and copies the 'result' attribute of the "Observation" to the 'content' attribute of the `<contentInstance>`. The oneM2M applcation gets the sensor data either by polling the CSE or subscribing to the desired `<container>` at the CSE.
![Figure 6.2-2: Communication OGC/STA-to-oneM2M direction](media/com_flow_2.png)
**Figure 6.2-2: Communication OGC/STA-to-oneM2M direction**
<mark>The following text is to be used when appropriate:</mark>
......
media/com_flow_1.png

73.8 KiB

media/com_flow_2.png

66 KiB

media/config.png

20.9 KiB

media/config_ogc.png

21.1 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment