Internet of Things Architecture

recovery strategy

Preventive measures

(DC A.15)

Requires data-

replication

functionality

Requires consistency

among replicated data

Replicated and archived

data are stored off-site

in the cloud

an

d disaster

Detective

measures

(DC A.16)

Requires monitoring

of indicators for

disastrous events

Requires modelling of

disastrous events to

be looked for and

propagation of those

Disaster monitoring

needs to be operated

independently of

components to be

monitored

Identify backup

(^) Corrective
measures
(DC A.17)
Requires restoring of
previously back-
upped configurations
Requires storage of
configuration history
Disaster recovery needs
to be operated
independently of
components to be
recovered
Table 29 : Design Choices addressing availability and resilience
Use high availability clustering
For design choice ̳VE Resolution location-oriented (DC A.1)‘ a resolution server
(RS) is responsible for indexing all connected things in a certain geographical
area, called indexing scope. A catalogue server then creates the Catalogue
Index of every RS‘ indexing scope. A resolution request is redirected towards
the RS whose indexing scope intersects the search scope of the request.
Large-scale IoT systems are expected to have multiple administrative domains
that must be handled by a federated resolution infrastructure. Different domains
interact with each other by the means of a central domain directory or domain
catalogue. Communication between framework domains needs to be secured.
The framework performs faster through a divided search space. Indexing scope
can be adjusted according to usage load. The framework scales by adding
more RSs. With this approach it is impossible to retrieve things based on
identifiers. Fault tolerance is achieved through data distribution and index data
replication. The central domain directory is potential single point of failure.
There is no theoretical limit on indexed things, but indexing scope is bound to
geographic location [De 2012b].
In design choice ̳VE Resolution domain-oriented (DC A.2)‟ a domain-oriented
VE Resolution approach organises the resolution framework in hierarchically
organised domains similar to Domain Name System (DNS). The hierarchy is
built according to the hierarchy of things captured by Virtual Entities from higher
granularity to lower granularity, e.g. country  city  district  building 
room. The resolution framework performs faster than an unclustered resolution
solution through divided search space; its complexity is of O(log n) in best case,
and O(n) in worst case, where n is the number of VEs hosted by the resolution
framework. Load balancing is supported through replication, and a Resource
can be member of different domains at a time. Fault tolerance is supported