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

Contribution SDS-2025-0079-TS-0041-oneM2M-SensorThings_interworking-v5_3_0_baseline merged into R5 

Original contribution: SDS-2025-0079-TS-0041-oneM2M-SensorThings_interworking-v5_3_0_baseline

See merge request !13
parents 673f4b94 c0a3dfa6
No related branches found
No related tags found
1 merge request!13SDS-2025-0079-TS-0041-oneM2M-SensorThings_interworking-v5_3_0_baseline
Pipeline #2143 passed
Stage: publication
Stage: web
Stage: deploy
Hide whitespace changes
Inline Side-by-side
TS-0041-oneM2M-SensorThings_interworking.md
+ 9
− 8
View file @ 118117e8
......@@ -2,9 +2,9 @@
|oneM2M<br/>Technical Specification |oneM2M<br />Technical Specification |
|-|-|
|Document Number |TS-0041-V-5.2.0 |
|Document Number |TS-0041-V-5.3.0 |
|Document Name: |oneM2M-SensorThings Interworking<br /> |
|Date: |2025-03-27 |
|Date: |2025-04-04 |
|Abstract: |&lt; An abstract of the specification and information that may be used in subsequent electronic searches> |
|Template Version: | January 2020 (do not modify) |
......@@ -180,7 +180,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 `<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.
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)
......@@ -188,14 +188,14 @@ The IPE shall map the 'result' attribute of an OGC/STA 'Observation' to the 'con
## 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 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 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)
......@@ -208,7 +208,7 @@ Figure 6.2-2 shows the OGC/STA-to-oneM2M direction. The IPE subscribes to the de
### 6.3.0 Introduction
To enable interworking, preparation is required for both the oneM2M-CSE and the OGC/STA server (see Figure 6.3.0-1). As described in Section 6.0, the IPE maps data from an OGC/STA "Observation" to a oneM2M `<contentInstance>` and vice versa. This specification defines a 1-to-1 relationship in each direction between the "Datastream" associated with the "Observation" and the `<container>` associated with the `<contentInstance>`. An IPE may implement multiple 1-to-1 relationships.
To enable interworking, preparation is required for both the oneM2M-CSE and the OGC/STA server (see Figure 6.3.0-1). As described in Section 6.0, the IPE maps data from an OGC/STA "Observation" to a oneM2M *`<contentInstance>`* and vice versa. This specification defines a 1-to-1 relationship in each direction between the "Datastream" associated with the "Observation" and the *`<container>`* associated with the *`<contentInstance>`*. An IPE may implement multiple 1-to-1 relationships.
![Figure 6.3.0-1: Both sides of the IPE configuration](media/config.png)
......@@ -236,7 +236,7 @@ An "Observation" according to STA Sensing Entities Data Model <a href="#_ref_i.1
The IPE requires a destination-"Datastream" to send an "Observation" containing data from the oneM2M side. If no associated "Datastream" exists on the OGC/STA server, it shall be created. This can be done beforehand or at the IPE's start-up, depending on the implementation.
When a "Datastream" is created on the OGC/STA server, a reference ID (e.g. {"@iot.id:3635353"}) is returned. This reference is required by the IPE to associate an "Observation" with a "Datastream" and shall be available during IPE operation. In addition to the "Datastream" other entities of the STA Sensing Entities Data Model <a href="#_ref_i.1">[i.1]</a>, such as "Location" or "Sensor," may be created.
The creation of entities like "Datastream" and "Thing" requires several mandatory properties that shall be known at configuration time (e.g., 'name' and 'description'). These property fields may be automatically derived, for example, from the "Label" or "ResourceName" attributes of the corresponding oneM2M `<container>` resource or if existing, from the corresponding `<AE>` resource during IPE configuration. The OGC/STA procedures for creating OGC entities are described in SensorThing API documentation <a href="#_ref_i.1">[i.1]</a>.
The creation of entities like "Datastream" and "Thing" requires several mandatory properties that shall be known at configuration time (e.g., 'name' and 'description'). These property fields may be automatically derived, for example, from the "Label" or "ResourceName" attributes of the corresponding oneM2M *`<container>`* resource or if existing, from the corresponding *`<AE>`* resource during IPE configuration. The OGC/STA procedures for creating OGC entities are described in SensorThing API documentation <a href="#_ref_i.1">[i.1]</a>.
Once the destination-"Datastream" is created, the IPE can send an "Observation" to the OGC/STA server as HTTP POST message. An interested OGC/STA client can subscribe to the destination-"Datastream" at the MQTT Broker of the OGC/STA server to receive each "Observation" forwarded by the IPE (see Figure 6.3.1.2-1). Alternatively, the OGC/STA client may use an HTTP-GET request to retrieve the data as needed.
......@@ -391,6 +391,7 @@ OR
|V5.0.0 | 2024-03-01|Includes the following contributions agreed during SDS#58 meeting: SDS-2023-0219R01-initial_OGC_intro|
|V5.1.0 | 2024-09-13|Includes the following contributions agreed during SDS#66 meeting: SDS-2024-0064R02_architecture_model and editorials agreed during SD#S66|
|V5.2.0 | 2025-03-27|Includes the following contributions agreed during SDS#68 meeting: SDS-2024-0141R02-ogc_ipe_communication_schema and SDS-2025-0016R02-ogc_ipe_configuration_aspects agreed during SDS#68|
|V5.3.0 | 2025-04-04|Includes the following contributions agreed during SDS#69 meeting: SDS-2025-0017R04 ogc_ipe_configuration_aspects_supl agreed during SDS#69, Editorials: followed the convention to write Attributes in italics.|
| | | |
| | | |
| | | |
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment