Constrained Application Protocol (CoAP)
The CoAP protocol is similar to HTTP but has been redesigned to meet the requirements of battery powered devices with limited CPU and RAM resources. The protocol uses UDP/IP as the transport layer. The result is a protocol that uses much smaller packets, is simpler compared to HTTP and has a smaller footprint (the smallest CoAP message is 4 bytes compared to 26 bytes of the smallest HTTP message). Moreover, CoAP has been designed to easily translate to HTTP for simplified integration with the web – the protocols interoperate through simple proxies.
Just like HTTP, CoAP is based on a client / server model. Client sends a request to server and server sends back a response. Clients may GET, PUT, POST and DELETE resources. Because CoAP uses UDP as the transport layer, there is no warranty that all the client’s messages will reach the server. The protocol balances QoS and resources by implementing two types of messages: “confirmable” and “non-confirmable”. Messages of “confirmable” type, must be acknowledged by the server with an acknowledgement (ACK) packet. If ACK is not received by the client, it will resent the same message. Non-confirmable messages are classed simply as “fire and forget”. This provides IoT developers with flexibility to decide, if it is crucial that a particular message reaches the server, or it’s ok to miss some data but increase the device’s battery life time. Based on our experience with various NB-IoT networks, Efento temperature sensor is on average in the active state (that’s when it consumes the most of the energy) for 8.5 seconds when sends a “confirmable” message compared to only 2.4 seconds, if the message is of “non-confirmable” type. At the same time, 99.95% of “non-confirmable” messages successfully reach the server.
CoAP cannot use SSL/TLS to provide communication security (this requires the TCP transport layer). Communication security is provided by the Datagram Transport Layer Security (DTLS) standard, which runs over UDP and provides a high level of security.
CoAP is an open protocol that has been standardized by The Internet Engineering Task Force Constrained RESTful Environments working group and the core of the protocol is specified in RFC 7252.
CoAP is one of the most popular protocols used by the battery powered IoT devices and wireless sensors. Currently there is a number of CoAP protocol implementations, with libraries for many popular programming languages including Java, Python, C, C++, C#, Ruby, .NET or JavaScript.
CoAP is an open, lightweight protocol tailored for battery powered IoT devices to communicate with servers in an efficient way.
Protocol Buffers (Protobuf)
Protocol buffers (or Protobuf) are a method of serializing the data that can be transmitted between microservices, applications or used in communication between IoT devices and servers. Protocol Buffers have the same function as well known and widely used JSON and XML. Like JSON and XML, the Protobufs are language-neutral and platform-neutral. The key differences between the three methods of serializing data are that unlike JSON and XML, Protobuf is optimised to be fast and use as little network bandwidth as possible by minimizing the size of transmitted data. Protobufs are 3 to 10 times smaller and 20 to 100 times faster than XML. This makes Protobuf a perfect choice for serializing the data sent by the battery powered IoT devices.
The Protobuf format was created by Google in 2001 and since then it is used in almost all Google’s inter-machine communication and for storing and interchanging all kinds of structured information. Since 2008 Protobuf is publicly available.
The Protobuf is a binary format. This increases the speed of data transmission because the message takes less space and network bandwidth. The only disadvantage of this approach, compared to JSON or XML, is that data serialized with Protobuf is not human readable.
Unlike JSON and XML, the data and context are separated in Protobuf. Context is defined in the configuration files called proto files (.proto). These files contain field names along with their types and identifiers (eg. string first_name = 1; string surname = 2;), based on the configuration fields Protobuf data is being serialized. So the Protbuf data contain: field identifier, field type, value length and the value (124John223Doe). In the result, the same data serialized in Protobuf is much smaller compared to XML and JSON but, as mentioned before, harder to read for a human. The proto files can be compiled to generate code in the user’s selected programming language – a class with setters and getters for all the fields defined in the proto file. Currently, Google provides a code generator for multiple languages including C++, C#, Dart, Go, Java and Python under an open source license.
To learn more about Protobuf, access the documentation and see examples visit Google’s Protocol Buffer page.
Protobuf is a method of serializing the data, which provides a small size of data packets. It is a substitute for JSON and XML.
How Efento uses CoAP and Protobuf?
Efento NB-IoT and LTE-M sensors send the data in Protobuf format using CoAP protocol. This guarantees fast transmissions and small size of data, which results in up to 10 years battery life time. Moreover, as both CoAP and Protobuf are popular standards, it’s easy to integrate Efento wireless sensors with any cloud platform or custom application.
You can unsubscribe at any time