o CoAP based applications

CoAP is based on the wildly successful REST model: Servers make resources available
under a URL, and clients access these resources using methods such as GET, PUT, POST,
and DELETE.

COAP:

Building sensor application in OpenWSN is not much different from building a REST API.
Developers make resources available; and within each of these resource, all 4 RESTful
request (GET, PUT, POST, and DELETE) can be handled.
Once a request to a particular resource is received and parsed, the corresponding
application will either perform an action and/or send a response to the sender in the form of a
binary packet. There are 5 types of responses supported in OpenWSN (CREATED,
DELETED, CHANGED, CONTENT, and VALID), plus numerous other type of error reponse
(REQTOOLAGRE, UNAUTHORIZED, etc)
CoAP Packet has low parsing complexity thanks to its binary protocol. OpenWSN firmware
already supported the building and parsing of CoAP packets, but we had to build the protocol
from scratch for our WSNManager windows application. This protocol follows the
implementation of RFC 7252 as follow:

Figure 1 (c) www.eclipsecon.org

Acknowledgement mechanism

Like mentioned before, CoAp uses UDP as its transport protocol; because of that,
most reliability-related mechanism, such as acknolwedgment, restransmission, and
time out, are missing and has to be artificially reproduced using the coAP layer. We
only apply this mechanism to essential messages such as neighbor table update
messages.

In detail, when an essential update such as a neighbor table addition is being sent to
WSNManager, the identity of the new neighbor (its location on the motes neighbor table),
will be kept in a cache and will only be removed once the corresponding ACK is received.
While it is in the cache, a periodic timer fires every 4 seconds and resend the any update in
the cache to WSNManager. The timer is stoped when the cache becomes empty.

o Self-healing topology
o Resource discovery
o Real-time active neighbor updates