Skip to content
Snippets Groups Projects

SDS-2024-0064R02-architecture_model

Merged SDS-2024-0064R02-architecture_model
SDS-2024-0064-architecture_model into R5
Merged Ingo Friese requested to merge SDS-2024-0064-architecture_model into R5
Compare
and
Show latest version
1 file
+ 1
− 29
Compare changes
  • Side-by-side
  • Inline
TS-0041-oneM2M-SensorThings_interworking.md
+ 1
− 29
@@ -191,9 +191,7 @@ The basic interworking enables applications that are connected to an oneM2M-base
## 6.1 OGC/STA-to-oneM2M Data Model Mapping
According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non-oneM2M Proximal IoT function/device in a oneM2M-specified resource instance is to be synchronized with the entity that it represents.
Thus the OGC/STA data model has to be represented in the hosting CSE. The SensorThings data model is comprehensive and may be regarded as a n:m relational database structure, holding both:
According to oneM2M TS-0033 <a href="#_ref_2">[2]</a> a representation of a non-oneM2M Proximal IoT function/device in a oneM2M-specified resource instance is to be synchronized with the entity that it represents. Thus the OGC/STA data model has to be represented in the hosting CSE. The SensorThings data model is comprehensive and should be regarded as a n:m relational database structure, holding both:
- sensor (IoT-data); and
- administrative data (like historic locations or historic products IDs).
@@ -205,32 +203,6 @@ The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'con
</figure>
## 6.2 Architecture Approach
In order to transfer data from a oneM2M sensor to OGC/STA the IPE creates a <subscription> to the <container> resource with the desired data and when a new <contentInstance> is added it gets a <notification> message containing the <contentInstance> resource.
Figure 6.2-1 shows the oneM2M-to-OGC/STA direction. Based upon the creation of the <contentInstance> in the hosting CSE, the IPE gets a <notification> message including the <contentInstance>. The IPE constructs an "Observation" creation request and copies the 'content' attribute of the <contentInstance> to the 'result' attribute of the "Observation" shown in Figure 6.2-2 and sends it to the OGC/STA server.
<figure>
<img src="media/onem2m_to_ogc_flow.png" alt="onem2m_to_ogc_flow">
<figcaption>Figure 6.2-1: IPE oneM2M-to-OGC/STA direction</figcaption>
</figure>
<figure>
<img src="media/content_copy.png" alt="content_to_observation_copy">
<figcaption>Figure 6.2-2: Copying content from CIN to observation</figcaption>
</figure>
Figure 6.2-3 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_1">[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 <contentInstance> using a HTTP request and copies the 'result' attribute of the "Observation" to the 'content' attribute of the <contentInstance>. The <container> should be created beforehand at the hosting CSE where the IPE <contentInstance> resources are stored. All interested applications may subscribe to this <container> resource.
<figure>
<img src="media/ogc_to_onem2m_flow.png" alt="ogc_to_onem2m_flow">
<figcaption>Figure 6.2-3: IPE OGC/STA-to-oneM2M direction</figcaption>
</figure>
This approach is simple and sufficient in cases that only require translating "Observation" to <contentInstances> and vice-versa. Data are stored in the hosting CSE, but this is just a subset of the non-oneM2M proximal IoT function. These are only data that are being actually exchanged. The oneM2M client application is not able to gain additional information that are linked to an incoming "Observation" like "Location" or "Sensor". This kind of information would need to be exchanged upfront in the configuration phase described in clause 6.3.
<mark>The following text is to be used when appropriate:</mark>