1) IoT protocol suite: This is the main direction supported by this project
and providing the best solution for interoperability;2) Ad-hoc proprietary solutions: Whenever the performance
requirements of the target application are more important than the
system versatility, ad hoc solutions may be the only way to go;3) Other standards: Depending on the target application domain,
regulations may exist forcing the system designer to adopt standards,
different from those suggested by the IoT protocol suite, that solved a
given past issue and have been maintained for continuity.After having selected the devices and their communication methods, the system
designer has to account for services and resources, as defined in the IoT
Service FG section. These are pieces of software that range from simple binary
application and increasing their complexity up to full-blown control software.
Both in the case of resources and for services the key point here is to choose
where to deploy the software related to a given device. The options are as
follows:
1) On smart objects: This choice applies to simple resource definitions and
lightweight services, such as web-services that may be realized in few
tens or hundreds of bytes;2) On gateways: Whenever the target devices are not powerful enough to
run the needed software themselves, gateways or other more capable
devices have to be deployed to assist the less capable ones;3) In the cloud: Software can be also deployed on web-farms. This solution
improves the availability of the services, but may decrease the
performance in terms of latency and throughput.Note that this choice has to be made per type of resource and service and
depending on the related device. As an example, a temperature sensor can be
deployed on a wireless constrained device, which is capable of hosting the
temperature resource with a simple service for providing it, but, if a more
complex service (for instance, when the Service Organisation FG is called in) is
needed, the software has to deployed on a more powerful device as per option
2) or 3).
On the same line, it is important to select where to store the information
collected by the system, let their data be gathered by sensor networks or
through additional information provided by users. In such a choice, a designer
must take into consideration the sensitiveness (e.g.: is the device capable of
running the security framework), the needed data availability and the degree of
redundancy needed for data resiliency. The foreseen options are the following:
- Local only: Data is stored on the device that produced it, only. In such a
case, the locality of data is enforced and the system does not require
complex distributed databases, but, depending on the location of a given