Application Layer Protocols

The Internet of Things (IoT) does not start over. Things, constrained devices, or Objects (these names will be considered equivalent hereafter) were able to communicate even before the Internet we know nowadays existed. Each sector developed its solutions, more or less standardized. During this period, the telecommunication and computer industry converged toward a set of architectures and protocols, creating a globally distributed system including web and computer to computer exchanges.
At the application level, the current challenge for the Internet of Things is to solve the following equation: respect the rules established by the computer industry to easily integrate data coming from constrained devices. But this must be done differently since the existing protocols are too expensive in terms of energy, computing time, and volume of data.
The Internet Engineering Task Force (IETF) developed new protocols dedicated to constrained devices respecting the concepts that make the Internet successful. This chapter describes the IETF protocol stack dedicated to constrained objects, as the CoAP protocol, an HTTP compatible protocol with a limited footprint, or the CBOR data representation as an alternative to JSON. These new protocols allow building generic IoT-dedicated platforms such as LwM2M to manage a large fleet of Things.
To illustrate this architecture, we will focus on a location-oriented application. Location is an integral part of the sensing and actuating paradigm. Without any form of "location" (address, absolute or relative coordinates, or grid identifier), an observation can’t be related to a phenomenon on earth (or any other planet you might be sensing and actuating). It is the essential location information of an observation that brought sensors and actuators to the Open Geospatial Consortium (OGC) and sparked the Sensor Web Enablement (SWE) work. At the core sits the observations and measurements standard (ISO/DIS (2011) 19156:2011), defining a conceptual encoding for observations. OGC’s Sensor Web Enablement spawned a lot of operational services around the world: from environmental monitoring services to tasking satellites to make observations over an area that was hit by a disaster. As the World Wide Web evolved and became the new "operating system," so did the best practices that made application share their data on the web: using the RESTful approach to access and use data via HTTP. The OGC followed quickly with the SensorThings API standard, using the OASIS OData standard for this representational state transfer (REST) interface, offering easy navigation through the data model, powerful filtering functionality, and the ability to customize what data is returned to minimize the amount of data transferred and the number of requests required. The API also supports push messages, notifying clients of changes in the data (push messages are part of a publish and subscribe mode). Since its approval as a standard, SensorThings API has been operationally used in many parts of the world and has many implementation – in both open- and close-sourced application.