6.3 Configuration Aspects
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.
Figure 6.3.0-1: Both sides of the IPE configuration
6.3.1 Configuration of OGC/STA Server Side
6.3.1.0 Overview
Both directions of the data flow between the OGC/STA server and the IPE require their own configuration steps.
6.3.1.1 Communication direction OGC/STA Server towards IPE
In Figure 6.3.1.1-1, an OGC/STA client is connected to an OGC/STA server, and its data is forwarded to the IPE. The OGC/STA client publishes data to the OGC/STA server via an HTTP-POST message.
An "Observation" according to STA Sensing Entities Data Model [i.1] belongs to a "Datastream" (see Figure 5-2). The IPE shall subscribe to the "Datastream" containing the observations to be forwarded to the oneM2M side at the MQTT broker of the OGC/STA server using its specific URL or topic, e.g., {sta-example-server-address.com/v1.0/Datastreams(8715)}. Upon successful subscription, the IPE will receive every "Observation" pushed to that "Datastream".
Figure 6.3.1.1-1: Message flow from OGC/STA Client to OGC/STA Server to IPE
6.3.1.2 Communication direction IPE towards OGC/STA Server
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 [i.1], 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 [i.1].
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.
Figure 6.3.1.2-1: Message flow from IPE to OGC/STA Server to OGC/STA Client
6.3.2 Configuration of the oneM2M CSE
6.3.2.0 General Configuration Aspects
The IPE needs to perform configuration steps on the hosting CSE.
The IPE shall register itself as an Application Entity (AE) that is represented as an <AE> resource in a oneM2M resource tree.
The CSE uses notifications to communicate new events to the IPE (AE). Therefore, the <AE> resource shall have the requestReachability (rr) attribute set to 'true'.
The <AE> resource shall have a pointOfAccess (poa) attribute giving the protocol and address that the IPE is going to use to receive notifications from the CSE.
The message flow for the creation of an <AE> resource is shown in Figure 6.3.2.0-1:
1) The IPE requests to register an <AE> resource on the hosting CSE.
2) The hosting CSE evaluates the request, performs the appropriate checks, and registers the <AE> resource.
3) The hosting CSE responds with a successful result response upon successful creation of the <AE> resource; otherwise, it responds with an error.
Figure 6.3.2.0-1: Message flow of an <AE> resource creation in oneM2M
6.3.2.1 Communication direction oneM2M CSE towards IPE
It needs two <container> resources in the CSE for the operation of the IPE, one for outgoing data and one for incoming data.
The <container> resource that is appointed to hold the data to be forwarded to the OGC/STA side (outgoing data) has to be created, if not already existing.
The message flow for the creation of a <container> resource is shown in Figure 6.3.2.1-1:
1) The IPE sends a request to create a <container> resource.
2) The hosting CSE evaluates the request, performs the appropriate checks, and creates the <container> resource.
3) The hosting CSE responds with a successful result response upon successful creation of the <container> resource; otherwise, it responds with an error.
Figure 6.3.2.1-1: Message flow of an <container> resource creation in oneM2M
A <subscription> resource shall be created under this <container> resource.
The <subscription> resource shall have the notificationURI attribute set to the resourceID of the <AE> resource.
The message flow for the creation of an <subscription> resource is shown in Figure 6.3.2.1-2:
1) The IPE sends a creation request for a <subscription> resource to the <container> resource that is appointed to hold the data to be forwarded to the OGC/STA side.
2) The hosting CSE evaluates the request and performs the appropriate checks and creates the <subscription> resource.
3) The hosting CSE responds with a successful result response of the <subscription> resource creation; otherwise, it responds with an error.
Figure 6.3.2.1-2: Message flow of an <subscription> resource creation in oneM2M
The CSE is now prepared to send data from oneM2M to OGC / STA via the IPE. As shown in Figure 6.3.2.1-3, a oneM2M Application Entity (AE), triggered by a sensor, sends data to the CSE by creating a <contentInstance> resource under the <container> resource that was appointed for outgoing data.
Since the IPE has subscribed to this <container> resource it receives a notification message along with all attributes of the <contentInstance> resource when new data arrives. The IPE maps the data from oneM2M to OGC / STA as described in 6.1 .
Figure 6.3.2.1-3: Message flow from AE to CSE to IPE
6.3.2.2 Communication direction IPE towards oneM2M CSE
The <container> resource that is appointed to hold the data from the OGC/STA side (incoming data) has to be created, if not already existing.
The message flow for the creation of a <container> resource is shown in Figure 6.3.2.1-1.
The CSE is now prepared to receive data from OGC / STA via the IPE. The IPE sends data as <contentInstance> resources to the dedicated <container> resource. If other oneM2M Application Entities are interested in this data, they may subscribe to the dedicated <container> resource. Alternatively, they can retrieve <contentInstance> resources from it in polling mode.
In Figure 6.3.2.2-1, the IPE (AE) sends data as <contentInstance> resources to the dedicated <container> resource. Subsequently, the AE receives a notification along with data contained in a <contentInstance> resource every time when the IPE creates new data.
Figure 6.3.2.2-1: Data message flow from IPE to CSE to AE