diff --git a/TS-0041-oneM2M-SensorThings_interworking.md b/TS-0041-oneM2M-SensorThings_interworking.md index 070bbabfdb006fc1c76edc8c4ed0c6f21403f6e9..0fb00af55c184f935a721cd474fc884dd7db9820 100644 --- a/TS-0041-oneM2M-SensorThings_interworking.md +++ b/TS-0041-oneM2M-SensorThings_interworking.md @@ -198,7 +198,6 @@ This means that the OGC/STA data model is represented in the hosting CSE. The da The oneM2M structure for data models is a tree-structure where data are organized in containers or trees of containers. The OGC/STA data model is a relational one, as used in databases, and not hierarchical. Thus, it creates a challenge for full interworking of all data captured in the OGC/STA data model. In this technical specification, only a limited set of data is mapped between OGC/STA and oneM2M. - <figure> <img src="media/ogc_non_model.png" alt="non_mapping"> <figcaption>Figure 6.1-1: OGC data model cannot directly be mapped to oneM2M</figcaption> @@ -208,6 +207,31 @@ The SensorThings data model is comprehensive and may be regarded as a n:m relati - sensor (IoT-data); and - administrative data (like historic locations or historic products IDs). +## 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> diff --git a/media/content_copy.png b/media/content_copy.png new file mode 100644 index 0000000000000000000000000000000000000000..1c827727229e774d88c65281ba7615546c198351 Binary files /dev/null and b/media/content_copy.png differ diff --git a/media/ogc_to_onem2m_flow.png b/media/ogc_to_onem2m_flow.png new file mode 100644 index 0000000000000000000000000000000000000000..066824ab49939a0ed65ef53321195e03f914f495 Binary files /dev/null and b/media/ogc_to_onem2m_flow.png differ diff --git a/media/onem2m_to_ogc_flow.png b/media/onem2m_to_ogc_flow.png new file mode 100644 index 0000000000000000000000000000000000000000..45d6f7b2ff7cff3b79a7c7e1665476bcef07302a Binary files /dev/null and b/media/onem2m_to_ogc_flow.png differ