# Virtual Replication of IoT Hubs in the Cloud:
## 3 Architecture
### The IoT Hub  
As anticipated in Section 1, the proposed architecture is based on a network element component, denoted as \"IoT Hub\". The IoT Hub does not have the same strict requirements on energy consumption and processing capabilities as other smart objects and is thus expedient to provide relevant features to a constrained network. The IoT Hub is placed at the edge of the constrained network and plays a fundamental role by implementing the following functions, as summarized in the functional plane, mapped in the protocol stack, shown in Figure 2.  
* Service and Resource Discovery: the IoT Hub is able to discover which SOs are available in the network and, subsequently, to discover the resources that they host;
* LoWPAN Border Router: at the network layer, the IoT Hub is the gateway between one or more constrained networks (e.g., IEEE 802.15.4) it belongs to (through some radio interfaces it is equipped with).
* CoAP/CoAP (C2C) Proxy: at the application layer, it provides proxying capabilities for CoAP requests coming from external clients that should reach internal constrained nodes.
* HTTP/CoAP (H2C) Proxy: at the application layer, it provides cross-proxying (protocol translation) between HTTP and CoAP in order to let external HTTP clients access CoAP resources hosted by smart objects.
* Resource Directory: the IoT Hub maintains a list of all CoAP resources available in the constrained network. These resources may have been gathered through several mechanisms, such as those described in [23].
* Cache: in order to avoid unnecessary load on smart objects and to minimize latencies, a cache is kept with the representation of most recently accessed resources.
* Replica Manager: a software module responsible for the coordination and the synchronization between the IoT Hub and its replicas.  
Moreover, due to the constrained nature of smart objects, they cannot typically implement strong security mechanisms and access policies, for instance, those related to authorization, whereby the IoT Hub may act as a filter for incoming requests in order to limit access to specific resources. Because of all the functionalities outlined above, the IoT Hub may suffer from the following critical issues, which may undermine the lifecycle of a constrained IoT network:  
* the IoT Hub is a bottleneck of the architecture, since all traffic must pass through it even if it is not a communication endpoint;
* failure of the IoT Hub would make the resources hosted by smart objects temporarily or permanently unavailable.  
It is necessary to relieve the IoT Hub from some of this load in order to guarantee that resources can be accessed with high availability in a secure and seamless way.  
In this work, we propose to rely on the Cloud by providing virtual replicas of the IoT Hub. Replicas of the IoT Hub are fully functional clones, which may be used by any external client to access resources in the same way as they would do with the actual IoT Hub. Interacting with resources through the replicas allows to provide an access point different from the real (physical) IoT Hub, thus decoupling the constrained network management function and granting access to external clients. Replicas of the IoT Hub are synchronized through a dedicated MQTT-based protocol, which is used to transfer copies of the resources from the IoT Hub to the replicas in a pub/sub model. Replicas can be instantiated on-the-fly, according to particular needs, thus also providing load balancing (according to policies which may depend on the number of connected clients and smart objects) and acting as recovery facilities, in the presence of temporary failure of the real IoT Hub.