The recording of the webinar is here: https://www.youtube.com/watch?v=SyDSB5VM2Bw&list=PLUSJC5mjKZ9SIASpVJNWKWCSS9hVzjiFA&index=2 This webinar discussed the differences between the two OGC standards for IoT data exchange, i.e., OGC Sensor Observation Service and the OGC SensorThings API. It compares the two specifications in terms of interoperability, feature list, developer experience, efficiency, scalability/discoverability, and security. In summary, SOS and SensorThings are both interoperable. SensorThings can interoperate with SOS but not the other way around. SensorThings offers more features, better developer experience, better efficiency, and better scalability. In terms of security, SensorThings API can leverage the XML/SOAP security mechanisms by offering an SOS interface.

1. Comparison between OGC SOS and
SensorThings API
sensorweb.geomatics.ucalgary.ca
www.sensorup.com
0.23 litre/minute
0.25 litre/minute
0.27 litre/minuteRH: 85 %
Temp: 18 Celsius
Dr. Steve Liang, Ph.D., P.Eng.
Associate Professor, University of Calgary
Founder and CEO, SensorUp Inc.

2. About Dr. Steve Liang
๏ Associate Professor, Geomatics Engineering, Uni. Calgary
๏ AITF-Microsoft Industry Research Chair on Open Sensor Web
(2011~2014)
๏ Chair OGC SensorThings API Standard Working Group
๏ Rapporteur, ITU-T SG12/11 on Internet of Things Test
Specifications
๏ Founder and CEO, SensorUp Inc
๏ Calgary’s Top 40 Under 40

3. About SensorUp
๏ We are a leader in Sensor Web and
IoT Platforms
๏ We are leading several international
IoT standard development efforts
(OGC and ITU-T)
๏ We are proud member of Eclipse
and Open Geospatial Consortium

4. News -
Whiskers
๏ Whiskers, a new
Eclipse open source
project proposal for
OGC SensorThings
API

5. News - Whiskers
๏ Whisker is
๏ a Javascript Client Library for SensorThings
๏ a light-weight SensorThings Server for IoT
gateways (e.g., Raspberry Pi)
๏ First release - 2016 Q2 or Q3

6. Background
๏ Sensor Observation
Service (SOS) v1.0
๏ results of OWS-3
(2005)
๏ SOS v2.0 (2012)

7. SensorThings API Background
๏ OGC conducted several IoT workshops in 2011
and 2012, and identified the needs for a new SWE
standard for IoT
๏ SWE for IoT SWG established in October 2012
๏ SWE for IoT SWG changed its name to
SensorThings API in September 2013
๏ SensorThings API approved in February 2016

8. Lessons learnt from SWE Implementations
๏ Our team implemented multiple SWE services
๏ SOS 1.0 server, SOS 2.0 server, A Worldwind-
based SWE client, a AJAX-based SWE client, a
Pivotviewer Sensor Web Browser, etc.
๏ Published more than 20 peer-reviewed papers
๏ We tried to apply the lessons learnt to the
development of SensorThings API

9. What are we comparing?
๏ Interoperability (between SOS and SensorThings)
๏ Features
๏ Developer Experience
๏ Efficiency
๏ Scalability
๏ Security

10. ๏ At a data exchange level, SensorThings and SOS
are interoperable.
๏ Both are based on O&M (OGC/ISO 19156:2011).
๏ At a service interface level
SensorThings API to SOS
SOS to SensorThings API
Interoperability

11. SensorThings to SOS
๏ You can build an SOS with SensorThings API interfaces. That
means function-wise you can find 1:1 mapping from SensorThings
API to SOS.
๏ SOS v.2.0 Example 9:
๏ SOS:
๏ GetObservations(observedProperty)
๏ SensorThings API:
๏ ~/ObservedProperties(id)/Datastreams?
$expand=Observations
๏ then converting JSON to XML, Voilà!

12. ๏ For example: find all Observations whose Features-of-
Interest’s descriptions contain ‘arctic’
๏ SensorThings API
๏ ~/FeaturesOfInterest?
$filter=substringof(‘arctic’,description)&
$expand=Observations
๏ SOS
๏ N/A
SOS to SensorThings

13. Feature Comparison

14. ๏ It is a choice of encoding
๏ SOS can have a JSON encoding extension
๏ Similarly SensorThings can have an XML
encoding extension (e.g., OASIS OData has
both JSON and XML)
JSON or XML?

15. Developer
Experience
๏ SensorThings
API provides a
much superior
developer
experience!

16. Developer Experience cont.
๏ Developer can explore SensorThings with any Web
browser
๏ The linking structure allow developers to explore
SensorThings even without reading the
specification
๏ The standard-based REST style provides consistent
HTTP verbs and status codes to CRUD entities

17. Developer Experience cont.
๏ Very compact code space for SensorThings
clients
๏ e.g., insert an Observation with Terminal
curl --request POST
--data '{"result": "2.11" }'
--header "Content-Type: application/json"
http://URL/Datastreams(id)/Observations

18. Developer Experience cont.
๏ Example, insert an Observation with SOS

19. ๏ At the Web Transfer Protocol Level
๏ SOS is based on HTTP
๏ SensorThings is designed for HTTP, CoAP, and MQTT
๏ At the Interface Level
๏ SensorThings offers efficient ways to get compact responses
(shorter response time, less data transmitted, less power
consumption)
๏ At the Encoding Level
๏ JSON vs XML
Efficiency

20. MQTT vs HTTPS (power consumption)
http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https

21. MQTT vs HTTPS (power consumption)
http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https

22. ๏ MQTT has a structure similar to URL path to
define pub/sub topics
๏ compatible with REST style!
๏ not compatible with Key Value Pair (KVP)
encodings
SOS over MQTT??

23. http://myserver.org:port/path
?service=SOS
&version=2.0.0
&request=GetObservation
&offering=http://example.org/offering1
&observedProperty=http://example.org/observedProperty1
http://myserver.org:port/path
?service=SOS
&version=2.0.0
&request=GetObservation
&observedProperty=http://example.org/observedProperty1
&offering=http://example.org/offering1
SOS over MQTT??
In the context of SOS, they are the same.
In the context of MQTT, they are different topics.

24. ๏ CoAP uses UDP
๏ A typical CoAP request header is 10~20 Bytes
๏ Response Code uses a single Byte
๏ Support pushing by introducing
๏ CoAP Observe
HTTP vs CoAP

25. ๏ GET Observations(id)/result
{
result: "19.19"
}
๏ GET Observations(id)/result/$value
19.19
SensorThings’ Efficient Interfaces
(URL Patterns)

26. ๏ GET Observations(id)?$select=result
{ "@iot.count": 10326,
"@iot.nextLink": "…",
"value": [
{"result": "20.79"},
{"result": "20.81"},
{…},{…}
]
}
Efficient Interfaces ($select)

27. ๏ SOS does not provide pagination.
๏ SensorThings provides advanced pagination
utilities.
๏ e.g., Observations(id)?$top=5&$skip=5
๏ e.g., Datastreams(id)?$expand=Observations
observations@iot.nextLink
observations@iot.count
Efficient Interfaces (pagination)

28. ๏ SensorThings API is all about links, and it’s
designed for easy discovery.
๏ selfLink - unique and shortest URI
๏ nextLink - short response time
๏ navigationLink - for relationships and
reuse of metadata
Discoverability and Scalability

29. ๏ SensorThings’ link-based structure
๏ also means easy sharding (i.e., scalability)
๏ crawler and search engine friendly (e.g., easy to
use ElasticSearch to index multiple
SensorThings)
there is no easy way to index an SOS
Discoverability cont.

30. ๏ Sensor delivers data streams
๏ SOS’ Request/Response model means many
unnecessary interactions between clients and
servers.
๏ In oder to know if there’s new Observations
inserted into an SOS, a client needs to send
requests very frequently.
Scalability - Pub/Sub vs Request/Response

31. ๏ MQTT Subscribe
Datastreams(id)/Observations?
$select=result
MQTT + OData URL Pattern + O&M
URL path tells you how
to find metadata, entity
name tells you how to
interpret the data
Query option allows you to receive
only the updates you want to receive

32. ๏ MQTT Subscribe:
Datastreams(id)/Observations?
$select=result,phenomenonTime
๏ Notification:
{result: "19.19",
phenomenonTime: "2016-03-24T01:57:54Z"}
MQTT + OData URL Pattern + O&M

33. Security
๏ XML vs JSON, which one is more secure?
๏ SOAP vs REST, which one is more secure?
๏ Don’t forget, SensorThings can easily provide a
SOS interface, but not the other way around.

34. Summary
๏ SensorThings can interoperate with SOS (not the
other way around)
๏ SensorThings API provides more features, better
developer experience, better efficiency, and better
scalability.
๏ While SOS can leverage the existing SOAP and XML
security mechanisms, a SensorThings service can
easily provide SOS interfaces if the SOAP and XML
security mechanisms are desired.