The original idea of the internet had a decentralized approach: every internet host sends data packages along to its neighbors if they are not addressed to itself. Every host is a sender and a receiver at the same time. Nowadays we are moving towards Internet of Things (IoT) and again all the small devices and sensors get decentralized nature. They exchange data with their environment and neighbors next to them. Data exchange requires a mutual understanding of exchanged data. Semantic approaches, namely a vocabulary help which leads to a Semantic Web of Things. This paper describes a proposal for the Micro-Ontology Context-Aware Protocol (MOCAP). Sensors can use microontologies which are always context-aware and send this semantic information to other devices. The receivers gain valuable information using the semantic description and data about microontology. Implementing M2M protocols on limited devices like sensors is challenging. We introduce an extension to MQTT and CoAP that exchanges data based on Micro-Ontologies. That leads to semantic interoperability even on the level of sensor grids.
At the 12. Google I/O conference 2015 Google introduced the new operation system named Brillo for the smart home and the Internet of Things (IoT). Google is also working on the Weave API which should be used for communication in the IoT. This API can be used cross-platform even on top of the existing stack. The Google’s solution for the interoperability is furthermore a core set of schemas1 for data exchange. Developers can extend this schema in terms of certified program which should guaranty that devices can exchange data seamlessly. This should improve the user experience. Every Android device recognize automatically any Brillo OS or Weave API based device. Users can choose a device, set it up and use it immediately.
That seamless user experience is also the idea developed by the Physical Web Project2. Every smart device has an URL. Users ask for devices nearby and get the list. Then they can use the URL in order to get more information. The project uses the URI Beacons schema.
This paper describes the decentralized approach for data exchange between small devices on the IoT using the low level M2M protocols. We combine the common technologies like RDF with constrained devices and their networks. The transported data is enriched by semantic description. We introduce the common M2M protocols and apply the idea of context-aware microontology. M2M protocols has to follow some rules and restrictions.
There are several works on standardization of ontologies among
them for sensors, too. The SSN ontology [
Other work in [
The work presented in [
There is another work [
MQTT still in the telemetry market, and CoAP is more applicable for IoT and higher level standards.
The growth of the Internet of Things (IoT) has led to the spread of various small devices, including wearables, beacons, sensors etc. Every device can be seen as peer. Devices usually communicate directly – in a direct, a P2P manner. Devices don't have to be connected with Internet. Information exchange is usually performed between nearest devices with near-field protocols. Devices can be i.e. a couple sensors and a smartphone. Sensors are constrained devices. They have small processors and little storage. But they have an operation system and network access. And they are built and used for the certain purpose (e.g. measure temperature). That purpose is the context and the devices are context-aware. In our scenario, sensors can measure different environment data. The smartphone next to it should collect and combine these information and present it users. This can occur as well in the push as in the pull way. Either users scan for the nearest sensor or will be notified. Sensors measure the temperature, the humidity and the brightness in the house and environment etc. Users get the information on smartphone but also the automatic blinds for the windows in their home get these information and close or open automatically. Users can control the blinds with the smartphone, too. Devices need a common understanding of exchanged data to work in that way. This scenario is outlined in the Figure 1.
Sensors have only less context-aware information (e.g. position, measured values). Thus, even small devices have to describe and exchange their context. In our model, information are only merged if their context matches. Each information is enriched with a micro-ontology data that describes that context. This is a controlled vocabulary. It can be a part of the top-level ontology. Back to our scenario the sensor knows only the micro-ontology for its own measurement. Let’s assume it measures the temperature. The smartphone knows this temperature microontology either because users added it before or the smartphone has downloaded it from Internet in order to process the information. Now they can communicate.
In the home scenario the sensors measurement should tell what they measure and in which unit of measurement the results are. The micro-ontology of the sensor is a subset of the environment ontology. Thus the window blinds need to know this microontology for the measurement but also for its control. The smartphone has knowledge about the environment ontology and can process data from the other devices like temperature, humidity or brightness sensors. And the smartphone knows the microontology for the blinds control as a subset of home control ontology.
The way how these devices are going to exchange context-aware data based on micro-ontology we are calling MOCAP – microontology context-aware protocol.
In these scenarios we have a machine to machine (M2M)
communication. There are two M2M protocols specified for the
Internet of Things (IoT): the Message Queuing Telemetry
Transport (MQTT) and the Constrained Application Protocol
(CoAP). They both work on level four of the Open Systems
Interconnection model (OSI Model), which makes them better
suitable for constrained environments than HTTP. Both protocols
are open standards: MQTT v. 3.1.1 is an OASIS Standard [
We use the Resource Description Framework (RDF)3 as a data format for communication. This is a standard for Semantic Web. Alternative we could use JSON-LD4 as a standard for Linked Data, but for our home scenario is seems to be oversized. RDF use the URI for resource and properties identification. On the other hand RDF has several data representations among them NTriples and Turtle. N-Triples are used i.e. by DBpedia. Turtle format seems to be more appropriated for the small devices because it separates the data representation into two parts: a list of prefixes and a list of the triples as shown in the Table 1. The data representation is more compact.
are subscriber by the temperature sensor. The sensor must recognize the subscription Topic for micro-ontology. The subscription Topics should be the namespaces of the ontology and the micro-ontology. The PUBLISH packet may contain only one Topic. Therefore the sensor publishes the message twice: one with the ontology and one with the micro-ontology namespace. Our scenario with MQTT is shown in the Figure 2.
The PUBLISH Control Packet transports an Application Message.
This packet can be send from a client to server or from a server to
a client. The Application Message contains among others a
variable header and a payload. The Topic Name is one field from
the variable header. It identifies the topic of the payload. The
payload contains the publish message. The MQTT Control Packet
can have a size up to 256 MB [
The MQTT-SN is specified by IBM. The protocol is intended for
Wireless Sensor Networks (WSNs) and constrained devices with a
limited processing and power capacity. This protocol addresses
the lower transmission rate. In case of WSN based on IEEE
802.15.4 the packet length is limited to 128 bytes [
Due to this limited capacities the Topic is replaced by a short
topic id of two bytes. Clients must register their Topics with the
gateway to get the corresponding topic id. Gateways mediate
between MQTT-SN and MQTT. Furthermore pre-defined topic
ids and short topics are introduced which don’t require
registration. The pre-defined topic is two byte long. The short
topics have a fixed length of two octets. Both the pre-defined and
short topics are used by PUBLISH message. We propose to use
that structure to transmit prefixes of the micro-ontology
namespaces in RDF Turtle format. The publish message contains
only the triples of Turtle. MQTT-SN is more suitable for sensors
and the semantic data can be reduced by using the RDF Turtle.
4.3 CoAP
The Constrained Application Protocol (CoAP) was developed for
use with constrained networks and nodes [
The Constrained RESTful Environments (CoRE) [
For our scenario the sensor have a server role, and the smartphone and blinds have the client role to succeed the GET request for the temperature, see Figure 3.
The most common request is the GET request. It retrieves
information from the current resources. On success a 2.05
(Content) response code should be presented in the response. The
payload content has to indicate the content-format of the payload
in order to simplify the message processing. There is a
subregistry for the subset of Internet media types which can be used
by CoAP as a numeric identifier. For an example
“application/xml” has the identifier “41” [
Using the entry point clients get the response with a payload in
the CoRE Link Format. It consists of resources hosted by the
server, i.e. a list of environment sensors i.e. for temperature,
humidity, etc. There are several examples described in the
RFC6690 [
In the multicast CoAP the endpoints listen on the default CoAP
port in order to offer services to multicast endpoints. This process
is described by RFC 7390 [
This paper shows the feasibility of the concept. The constrained devices like sensors are context-aware because they have a certain purpose or task i.e. measure the temperature in degree Celsius and share it with other devices. This is their context. They only need to know their own micro-ontology and the namespace of the toplevel ontology.
The micro-ontology is a subset of the top-level ontology. As there are more capable devices like smartphones participating in data exchange, they have knowledge about the top-level ontology and can process the data. In our scenario the top-level ontology is about environment, and the micro-ontology is about the temperature.
The semantic data should be described in a standardized way i.e. by RDF or JSON-LD. The Turtle representation of data is more compact then other RDF formats. The length of a message is limited. The challenge is to reduce the overhead caused by semantic description. This can be done by splitting the Turtle in prefixes definition and the triples themselves. Assuming the more capable device knows the prefixes we transport only the triples. We took a closer look at three M2M protocols: MQTT, MQTTSN and CoAP. We applied the principles above. Every protocol follows another architecture paradigm or has a different intension in sense of nodes or networks. Anyway we could apply our principles to them all.
Summarizing we call this approach MOCAP – micro-ontology context-aware protocol. The next step will be a case study with some use cases and different device classes. We need to evaluate the micro-ontology, its size etc. We follow the work of RDF Stream Processing Community Group (RSP)5 and Web of Things (WoT)6 community groups at W3C.