Each interface has a processing unit that includes, e.g., the pro-
tocol drivers. A central engine controls the server operation and
the access to the main database. It is written in Java, uses a
MySQL database and runs on a Linux operating system.
Two protocols are used to interface with the field nodes (gate-
ways) for an energy-efficient communication over unreliable
connections: normal and service (boot loader) operation.
The normal operation protocol acknowledges each event
upon reception for an incremental release of gateway memory
even for prematurely interrupted communications. Messages
and acknowledges can be sent asynchronously to improve the
utilization of high latency communication channels.
Time synchronization overhead is avoided at every commu-
nication level. The gateways timestamp the field messages and
events using their relative time and the server converts it to
real-world time using an offset calculated at the begin of the
gateway communication session.
The protocol for the boot loader mode is stateless, optimized
for large data block transfers and does not use acknowledges.
The gateway maintains the transfer state and incrementally
checks and builds the firmware image. An interrupted transfer
can also be resumed with minimal overhead.
IoT applications often produce large amounts of data that are
typically synthesized in synoptic views by the servers [25], [26]
(see Fig. 11). The server also uses high-availability techniques
for a high quality of service, e.g., a shadow server automatically
takes over the service if the main server fails.
The integration with IoT applications is supported by pro-
viding remote access to historical and real-time field data.