An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API
<p>A high-level Sensor Web and Internet of Things (SW-IoT) architecture [<a href="#B4-sensors-19-00495" class="html-bibr">4</a>].</p> "> Figure 2
<p>The SensorThings API UML diagram [<a href="#B14-sensors-19-00495" class="html-bibr">14</a>].</p> "> Figure 3
<p>The data model of tasking capability [<a href="#B4-sensors-19-00495" class="html-bibr">4</a>].</p> "> Figure 4
<p>Thing metadata of an example description file.</p> "> Figure 5
<p>Sensing capability of an example description file.</p> "> Figure 6
<p>Tasking capability of an example description file.</p> "> Figure 7
<p>The workflow of the sensing capability registration procedure.</p> "> Figure 8
<p>The workflow of the tasking capability registration procedure.</p> "> Figure 9
<p>Arduino Uno.</p> "> Figure 10
<p>Digi XBee serial 2.</p> "> Figure 11
<p>The indoor monitoring device.</p> "> Figure 12
<p>The temperature observations from the indoor monitoring device.</p> "> Figure 13
<p>The humidity observations from the indoor monitoring device.</p> "> Figure 14
<p>The remotely-controllable Liquid-crystal Display (LCD) and Light-emitting Diode (LED) device.</p> "> Figure 15
<p>LED turned on.</p> "> Figure 16
<p>LCD showing the corresponding text.</p> "> Figure 17
<p>The mobile luminosity-monitoring device.</p> "> Figure 18
<p>The luminosity observations of the mobile luminosity-monitoring device.</p> "> Figure 19
<p>The remotely-controllable buzzer device.</p> "> Figure 20
<p>The distribution of the sensors and the gateway of the real-world experiment.</p> "> Figure 21
<p>Photos of the deployed devices.</p> "> Figure 22
<p>The temperature observations from the device 24 between 12 October 2018 to 2 November 2018.</p> "> Figure 23
<p>The humidity observations from the device 24 between 12 October 2018 to 2 November 2018.</p> ">
Abstract
:1. Introduction
- (1)
- Sensing capability: SW-IoT devices can monitor their latest status or use embedded sensors to observe properties of their surrounding environment. With the help of communication technologies, users can remotely access these observations for further analysis or decision-making.
- (2)
- Tasking capability: Tasking capabilities allow users to remotely control SW-IoT devices. For example, a client can send tasks to turn on/off a device, adjust the sensor’s sampling rate, schedule an observation event, etc.
2. Related Work
3. Methodology
3.1. Device Description Data Model and Encoding
3.1.1. OGC SensorThings API Data Model
3.1.2. Extended SensorThings API
3.1.3. Description File
Description File—Thing Metadata
Description File—Sensing Capability
Description File—Tasking Capability
3.2. Communication Protocol for the Gateway Layer and the Device Layer
3.2.1. ZigBee Configuration
3.2.2. Communication Operations on Gateways and Devices
Gateway Operations
Device Operations
3.2.3. Tasking Protocol Translation and Task Forwarding
Algorithm 1. An httpProtocol example. |
"httpProtocol": { "httpMethod": "POST", "absoluteResourcePath": "http://example.com/Gateway", "messageDataType": "application/json", "messageBody": "{\"on\":{on},\"TC_name\":\"LED\",\"device_ID\":\"DEVICE00001\"}" } |
Algorithm 2. A Task from a user to the service. |
{ "TaskingCapability": { "@iot.id": 1 }, "input": [ { "ParameterID": "on", "Value": true } ] } |
Algorithm 3. The task forwarded to the gateway. |
POST http://example.com/Gateway HTTP/1.1 { "on": true, "TC_name": "LED", "device_ID": "DEVICE00001" } |
Algorithm 4. The task forwarded to the device. |
MY_DEVICE00010:LightBulb:true |
3.3. Automatic Registration Procedure
3.3.1. Scenarios
3.3.2. Registration Procedure for the Sensing Capability
- First of all, the registration procedure is triggered when a device tries to upload observations or new locations by sending an UploadObs operation (Arrow 1) to the connected gateway. The UploadObs operation contains the observations or locations in the msg_body (Table 3).
- Once the gateway receives the UploadObs operation, the gateway will check if the device has been registered in its lookup table according to the device UID.
- If the device has been registered in the lookup table, the gateway can directly upload the observations or new locations to the service (Arrow 2) as the device’s virtual identities have also been also stored in the lookup table, and then the gateway sends a Confirm operation (Arrow 12) to the device to confirm the end of the procedure.
- However, if the device has not been registered in the lookup table (i.e., a new device, a new gateway, or a mobile device), the gateway will send the GetServURL operation (Arrow 3) to the device to ask for the service URL that the device wants to be registered to.
- The device responds with the SendServURL operation (Arrow 4) containing the service URL. With the service URL, the gateway can query the service based on the device UID, to check whether the device has been registered in the service or not.
- If the device has been registered in the service (i.e., a new gateway or a mobile device), the gateway can collect the device’s sensing capabilities and virtual identities from the service to update its lookup table (Arrow 5), and finally upload the observations or locations to the service (Arrow 11).
- If the device has not been registered to the service (i.e., a new device), the gateway will send a GetDesc operation (Arrow 6) to the device to ask for the description file of the device.
- The device responds with the SendDesc operation (Arrow 7) containing the description file.
- Based on the description file, the gateway helps the device register to the service and create necessary entities, including Thing (Arrow 8), Datastream, or TaskingCapability (Arrow 9), etc. In this step, the gateway checks if there is already the same ObservedProperties registered on the service. If the ObservedProperties have been registered, the gateway will retrieve the IDs and link new Datastreams to the existing ObservedProperties.
- Finally, after the gateway uploads the observations or locations to the service, the gateway sends a Confirm operation (Arrow 12) to the device to confirm the end of the procedure.
3.3.3. Registration Procedure for the Tasking Capability
- First of all, if a device supports any tasking capability, the device should periodically send an UpdateStatus operation (Arrow 1) to the currently-connected gateway.
- The gateway will first check its lookup table. If the tasking capability of the device has been recorded in the lookup table, which means that this device has been registered to this gateway before, the gateway will directly update the gateway’s IP address and its httpProtocol on the service (Arrow 2) and send a Confirm operation (Arrow 3) to the device to confirm the end of the procedure. The reason of updating the gateway IP address and its httpProtocol even if the device is known to the gateway is that if the device has connected with other gateways (e.g., a mobile device or nearby gateways), the gateway IP address and httpProtocol on the service could have been changed. Therefore, this seen-to-be redundant procedure is to ensure that the service can successfully forward tasks to the gateway.
- If the gateway cannot find the tasking capability of the device in the lookup table, all three scenarios are possible (i.e., a new device, a new gateway, or a mobile device). However, unlike that gateways can collect devices’ sensing capabilities by querying the service, device protocols (e.g., the zigbeeProtocol) are not stored in the service because of security concerns. Therefore, the gateway needs to send a GetServURLandDesc operation (Arrow 4) to the device to ask for both the service URL and the description file. The device then responds with the SendServURLandDesc operation (Arrow 5).
- Afterward, the gateway checks if the device has been registered to the service. If the device has been registered (i.e., a new gateway or a mobile device), the gateway will update the gateway’s IP address and its httpProtocol to the service (Arrow 6) and record the device’s sensing and tasking capability in its lookup table (Arrow 10), and finally send a Confirm operation (Arrow 11) to the device to confirm the end of the procedure.
- If the device has not been registered to the service (i.e., a new device), the gateway will help the device register its sensing and tasking capability to the service (Arrow 7, 8) and its lookup table (Arrow 9), and finally send a Confirm operation (Arrow 11) to the device to confirm the end of the procedure.
4. Results
4.1. In situ Sensing Application
4.2. In situ Tasking Application
Algorithm 5. An example task to turn on the LED. |
{
"TaskingCapability": {
"@iot.id": 33
},
"input": [
{
"ParameterID": "on",
"Value": true
}
]
}
|
Algorithm 6. An example task to display text on the LCD monitor. |
{
"TaskingCapability": {
"@iot.id": 34
},
"input": [
{
"ParameterID": "msg",
"Value": "Hello world!!!"
}
]
}
|
4.3. Mobile Sensing Application
4.4. Mobile Tasking Application
Algorithm 7. An example task to ring the buzzer five times. |
{ "TaskingCapability":{ "@iot.id":41 }, "input":[ { "ParameterID": "buzz_time", "Value": 5 } ] } |
4.5. A Real-world Experiment—Underground Metro Mall Environment Monitoring
5. Conclusions and Future Work
Author Contributions
Funding
Conflicts of Interest
Appendix A
Algorithm A1. The description file of the indoor monitoring device. |
{ "name": "IndoorMonitoring_device", "description": "CSRSR’s sensor", "properties": { "UID": "MY_DEVICE00001" }, "Locations": [ { "name": "CSRSR", "description": "CSRSR", "encodingType": "application/vnd.geo+json", "location": { "type": "Point", "coordinates": [ 24.967765, 121.187035 ] } } ], "Datastreams": [ { "name": "sensor1", "description": "Temperature", "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement", "unitOfMeasurement": { "name": "degree Celsius", "symbol": "degree Celsius", "definition": "http://unitsofmeasure.org/ucum.html#para-30" }, "Sensor": { "name": "tempSensor", "description": "Thermometer", "encodingType": "text/html", "metadata": "DHT22" }, "ObservedProperty": { "name": "air_temperature", "description": "Temperature of air in situ.", "definition": "http://mmisw.org/ont/ioos/parameter/air_temperature" } }, { "name": "sensor2", "description": "Humidity", "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement", "unitOfMeasurement": { "name": "Percentage", "symbol": "%", "definition": "http://unitsofmeasure.org/ucum.html#para-29" }, "Sensor": { "name": "humiSensor", "description": "Hygrometer", "encodingType": "text/html", "metadata": "DHT22" }, "ObservedProperty": { "name": "humidity", "description": "Humidity of air in situ.", "definition": "http://mmisw.org/ont/ioos/parameter/relative_humidity" } } ] } |
Algorithm A2. The description file of the remotely-controllable LCD and LED device. |
{ "name": "remotelyControlled_LCD_device", "description": "CSRSR’s sensor", "properties": { "UID": "MY_DEVICE00002" }, "Locations": [ { "name": "CSRSR", "description": "CSRSR", "encodingType": "application/vnd.geo+json", "location": { "type": "Point", "coordinates": [ 24.967765, 121.187035 ] } } ], "TaskingCapabilities": [ { "name": "LightBulb", "description": "", "parameters": [ { "parameterID": "on", "description": "turn on or off", "use": "Mandatory", "definition": { "inputType": "Boolean", "unitOfMeasurement": "Status", "allowedValues": [ { "value": true, "description": "turn on" }, { "value": false, "description": "turn off" } ] } } ], "zigbeeProtocol": { "extendedAddressHigh": "0013A200", "extendedAddressLow": "40BF8550", "messageDataType": "application/text", "messageBody": "MY_DEVICE00002:LightBulb:{on}" }, "Actuator": { "name": "LED", "description": "a controllable LED.", "encodingType": "application/text", "metadata": "LED" } }, { "name": "LCD", "description": "A LCD monitor that can display text messages.", "parameters": [ { "parameterID": "msg", "description": "text", "use": "Mandatory", "definition": { "inputType": "String", "unitOfMeasurement": "Status", "allowedValues": [ { "description": "String" } ] } } ], "zigbeeProtocol": { "extendedAddressHigh": "0013A200", "extendedAddressLow": "40BF8550", "messageDataType": "application/text", "messageBody": "MY_DEVICE00002:LCD:{msg}" }, "Actuator": { "name": "Paralax LCD monitor", "description": "a controllable LCD monitor which can print text.", "encodingType": "application/text", "metadata": "Parallax 2*16 Serial LCD" } } ] } |
Algorithm A3. The description file of the mobile luminosity-monitoring device. |
{ "name": "mobileLuminosityMonitoring_device", "description": "CSRSR’s sensor", "properties": { "UID": "MY_DEVICE00003" }, "Locations": [ { "name": "CSRSR", "description": "CSRSR", "encodingType": "application/vnd.geo+json", "location": { "type": "Point", "coordinates": [ 24.967757, 121.187112 ] } } ], "Datastreams": [ { "name": "sensor1", "description": "Luminosity", "observationType": "http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement", "unitOfMeasurement": { "name": "Lux", "symbol": "lux", "definition": "http://unitsofmeasure.org/ucum.html#para-30" }, "Sensor": { "name": "TSL2561", "description": "Luminosity_Sensor", "encodingType": "text/html", "metadata": "TSL2561" }, "ObservedProperty": { "name": "Luminosity", "definition": "https://ci.mines-stetienne.fr/seas/ZoneLightingOntology-1.0#luminosity", "description": "Luminosity." } } ] } |
Algorithm A4. The description file of the remotely-controllable buzzer device. |
{ "name": "remotelyControlledBuzzer_device", "description": "CSRSR’s sensor", "properties": { "UID": "MY_DEVICE00004" }, "Locations": [ { "name": "CSRSR", "description": "CSRSR", "encodingType": "application/vnd.geo+json", "location": { "type": "Point", "coordinates": [ 24.967757, 121.187112 ] } } ], "TaskingCapabilities": [ { "name": "buzzer", "description": "", "parameters": [ { "parameterID": "buzz_time", "description": "ring buzzer several times", "use": "Mandatory", "definition": { "inputType": "Integer", "unitOfMeasurement": "times", "allowedValues": [ { "Max": 10, "Min": 1 } ] } } ], "zigbeeProtocol": { "addressingSH": "0013A200", "addressingSL": "40BF8550", "messageDataType": "application/text", "messageBody": "MY_DEVICE00024:buzzer:{buzz_time}" }, "Actuator": { "name": "MH-FMD buzzer module", "description": "a controllable buzzer.", "encodingType": "application/text", "metadata": "MH-FMD" } } ] } |
References
- Delin, K.A.; Jackson, S.P. The Sensor Web: A New Instrument Concept; SPIE: Bellingham, WA, USA, 2001; Volume 4282, pp. 1–9. [Google Scholar]
- Botts, M.; Percivall, G.; Reed, C.; Davidson, J. OGC® sensor web enablement: Overview and high level architecture. In GeoSensor Networks; Springer: Berlin/Heidelberg, Germany, 2008; pp. 175–190. [Google Scholar]
- Liang, S.H.; Croitoru, A.; Tao, C.V. A distributed geospatial infrastructure for Sensor Web. Comput. Geosci. 2005, 31, 221–231. [Google Scholar] [CrossRef]
- Huang, C.Y.; Wu, C.H. A Web Service Protocol Realizing Interoperable Internet of Things Tasking Capability. Sensors 2016, 16, 1395. [Google Scholar] [CrossRef] [PubMed]
- Atzori, L.; Iera, A.; Morabito, G. The internet of things: A survey. Comput. Netw. 2010, 54, 2787–2805. [Google Scholar] [CrossRef]
- Bormann, C.; Castellani, A.P.; Shelby, Z. Coap: An application protocol for billions of tiny internet nodes. IEEE Internet Comput. 2012, 16, 62–67. [Google Scholar] [CrossRef]
- Lu, G.; Krishnamachari, B.; Raghavendra, C.S. Performance evaluation of the IEEE 802.15.4 MAC for low-rate low-power wireless networks. In Proceedings of the IEEE International Conference on Performance, Computing, and Communications, Phoenix, AZ, USA, 15–17 April 2004; pp. 701–706. [Google Scholar]
- Jirka, S.; Bröring, A.; Stasch, C. Applying OGC Sensor Web Enablement to risk monitoring and disaster management. In Proceedings of the GSDI 11th World Conference, Rotterdam, The Netherlands, 15–19 June 2009. [Google Scholar]
- Chung, L.K.; Fang, Y.M.; Chang, Y.H.; Chou, T.Y.; Lee, B.J.; Yin, H.Y.; Baranski, B. A SOA based debris flow monitoring system. In Proceedings of the 17th International Conference on Geoinformatics, Fairfax, VA, USA, 12–14 August 2009; pp. 1–6. [Google Scholar]
- Rouached, M.; Baccar, S.; Abid, M. RESTful Sensor web enablement services for wireless sensor networks. In Proceedings of the 2012 IEEE Eighth World Congress on Services (SERVICES), Honolulu, HI, USA, 24–29 June 2012; pp. 65–72. [Google Scholar]
- Schade, S.; Díaz, L.; Ostermann, F.; Spinsanti, L.; Luraschi, G.; Cox, S.; De Longueville, B. Citizen-based sensing of crisis events: Sensor web enablement for volunteered geographic information. Appl. Geomat. 2013, 5, 3–18. [Google Scholar] [CrossRef]
- Bröring, A.; Stasch, C.; Echterhoff, J. OGC® Sensor Observation Service Interface Standard Implementation Specification 12-006: Version2.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2012. [Google Scholar]
- Simonis, I.; Echterhoff, J. OGC® Sensor Planning Service Implementation Standard 09-000: Version2.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2011. [Google Scholar]
- Liang, S.; Huang, C.Y.; Khalafbeigi, T. OGC® SensorThings API Part 1: Sensing 15-078r6 Version 1.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2016. [Google Scholar]
- Cox, S. OGC® Observations and Measurements-XML Implementation 10-025r1: Version 2.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2011. [Google Scholar]
- Botts, M.; Robin, A. OpenGIS Sensor Model Language (SensorML) Implementation Specification 07-000 Version 1.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2007. [Google Scholar]
- Pizzot, M.; Handl, R.; Zurmuehl, M. Information Technology Open Data Protocol (OData) v4.0 Part 1: Core, OAISI Open Data Protocol (OData) TC. Available online: https://www.oasis-open.org/standards#odatav4.0 (accessed on 24 January 2019).
- O’Reilly, T. OGC® Puck Protocol Standard 09-127r2 Version 1.4; Open Geospatial Consortium: Wayland, MA, USA, 2010. [Google Scholar]
- Broering, A.; Below, S.; Foerster, T. Declarative sensor interface descriptors for the sensor web. In Proceedings of the WebMGS, 1st International Workshop on Pervasive Web Mapping, Geoprocessing and Services, Como, Italy, 26–27 August 2010. [Google Scholar]
- Guinard, D.; Trifa, V.; Pham, T.; Liechti, O. Towards physical mashups in the Web of Things. In Proceedings of the Sixth International Conference on Networked Sensing Systems (INSS), Pittsburgh, PA, USA, 17–19 June 2009; pp. 1–4. [Google Scholar]
- Jaffey, T.; Davies, J.; Beart, P. Hypercat 3.00 Specification. Available online: http://www.hypercat.io/uploads/1/2/4/4/12443814/hypercat_specification_3.00rc1-2016-02-23.pdf (accessed on 24 January 2017).
- Soldatos, J.; Kefalakis, N.; Hauswirth, M.; Serrano, M.; Calbimonte, J.P.; Riahi, M.; Skorin-Kapov, L. Openiot: Open source internet-of-things in the cloud. In Proceedings of the Interoperability and Open-Source Solutions for the Internet of Things: International Workshop, FP7 OpenIoT Project, Split, Croatia, 18 September 2014; pp. 13–25. [Google Scholar]
- Calbimonte, J.P.; Sarni, S.; Eberle, J.; Aberer, K. XGSN: An Open-source Semantic Sensing Middleware for the Web of Things. In Proceedings of the 7th International Workshop on Semantic Sensor Networks, Riva del Garda, Italy, 19 October 2014; TC/SSN@ ISWC. pp. 51–66. [Google Scholar]
- oneM2M-TS-0001, oneM2M Functional Architecture Specification v2.10.0. August 2016. Available online: http://www.onem2m.org/ (accessed on 24 January 2019).
- Martínez, E.; Toma, D.M.; Jirka, S.; del Río, J. Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web. Sensors 2017, 17, 2923. [Google Scholar] [CrossRef] [PubMed]
- Miller, B.A.; Nixon, T.; Tai, C.; Wood, M.D. Home networking with universal plug and play. IEEE Commun. Mag. 2001, 39, 104–109. [Google Scholar] [CrossRef]
- ZigBee, A. Zigbee-2006 Specification. Available online: http://www.zigbee.org/ (accessed on 24 January 2019).
- Howitt, I.; Gutierrez, J.A. IEEE 802.15. 4 low rate-wireless personal area network coexistence issues. In Proceedings of the 2003 IEEE Wireless Communications and Networking, New Orleans, LA, USA, 16–20 March 2003; pp. 1481–1486. [Google Scholar]
Parameter | Configuration |
---|---|
extended PAN ID (64-bit) | 14,647 |
destination extended address (64-bit) | Coordinator: 0xFFFF |
Router/End device: 0 |
Property | Description |
---|---|
operation | The operation name that a gateway or a device tries to invoke |
device_ID | The unique identifier (UID) of the device |
service_URL | The service URL to register device resources |
msg_body | The corresponding content of each operation |
Operation | UploadObs |
---|---|
functionality | 1. Initiate registration procedure of sensing capability 2. Receive sensor observations or new locations from a device |
request format | { "operation": "UploadObs", "device_ID": "<device_ID>", "msg_body": [ { "name": "<datastream_1>", "observation": <obs1> }, { "name": "<datastream_2>", "observation": <obs2> }, { "lat": "<latitude>", "lon": <longitude> } ] } |
Operation | UpdateStatus |
---|---|
functionality | 1. Initiate registration procedure of tasking capability 2. Update the gateway URL to the service |
request format |
{
"operation": "UpdateStatus",
"device_ID": "<device_ID>"
}
|
Operation | SendServURL |
---|---|
functionality | Receive the service URL from a device |
request format | { "operation": "SendServURL", "device_ID": "<device_ID>", "service_URL": "<service_URL>" } |
Operation | SendDesc |
---|---|
functionality | Receive the description file from a device |
request format | { "operation": "SendDesc", "device_ID": "<device_ID>", "msg_body ": "<description_file>" } |
Operation | SendServURLandDesc |
---|---|
functionality | Receive the service URL and the description file from a device |
request format | { "operation": "SendServURLandDesc", "device_ID": "<device_ID>", "service_URL": "<service_URL>", "msg_body ": "<description_file>" } |
Operation | GetServURL |
---|---|
functionality | A gateway asks for the service URL that this device should be registered to |
request format |
{
"operation": "GetServURL",
"device_ID": "<device_ID>"
}
|
Operation | GetDesc |
---|---|
functionality | A gateway asks for the description file of this device |
request format |
{
"operation": "GetDesc",
"device_ID": "<device_ID>"
}
|
Operation | GetServURLandDesc |
---|---|
functionality | A gateway asks for the service URL and the description file |
request format |
{
"operation": "GetServURLandDesc",
"device_ID": "<device_ID>"
}
|
Operation | Confirm |
---|---|
functionality | A gateway acknowledges that the registration procedure is finished |
request format |
{
"operation": "Confirm",
"device_ID": "<device_ID>"
}
|
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Huang, C.-Y.; Chen, H.-H. An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API. Sensors 2019, 19, 495. https://doi.org/10.3390/s19030495
Huang C-Y, Chen H-H. An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API. Sensors. 2019; 19(3):495. https://doi.org/10.3390/s19030495
Chicago/Turabian StyleHuang, Chih-Yuan, and Hsin-Hsien Chen. 2019. "An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API" Sensors 19, no. 3: 495. https://doi.org/10.3390/s19030495
APA StyleHuang, C. -Y., & Chen, H. -H. (2019). An Automatic Embedded Device Registration Procedure Based on the OGC SensorThings API. Sensors, 19(3), 495. https://doi.org/10.3390/s19030495