Internet of Things (IoT) Deployment Models

Communication world is chanting “Internet of Things” mantra for many good reasons. Most exciting reasons could be all electronics devices would be part of internet which opens up new business opportunities for Original Equipment Manufacturers (OEM), Cloud Service Providers and Internet Service Providers (ISP). A decade ago IoT was a thought, From a couple of years IoT is transforming into reality. Various products, services, analytics, intelligence, big data and monetization models have been designed and deployed in recent times. Various communication protocols strive to find their space in IoT and aligned to it.

While hinting a plethora of opportunities, IoT  throws few challenges to all stakeholders. Legacy communication devices (typical WiFi, Bluetooth, ZigBee, Z-Wave devices), interchangeability, security, scalablity, LPWAN (Low Power Wide Area Network), revenue model are the potential challenges which need immediate address. Nevertheless, these challenges are being addressed or partially addressed. By the time OCF (Open Connectivity Foundation) standard was released, many organizations parked their first leg into IoT (Smart Things, Alseen, Thread, Nest to name a few). This pro-activeness helped to prove the IoT concept thus expedite IoT deployments. On the other hand the same pro-activeness resulted into multiple deployments models.

Gateway Based Deployment

In this mode of deployment IoT devices (Things) in a WPAN (Wireless Personal Area Network) are connected to a gateway through proximity based connectivity protocols. And the gateway device is connected to cloud through internet or LPWAN. Things in this deployment are usually small or mid-size devices which run low power connectivity protocols such as ZigBee, Z-Wave, BLE, Low Power Wi-Fi, RF, IR etc. Legacy connectivity devices manufactured during pre IoT times can be used as Things in this type of deployment. Things are identified in the IoT space using a post-fix over gateways's identity. In other words, Things are identified using an URI (Uniform Resource Identifier) in which gateway's identity is integral part of the URI. Gateway possesses the hardware and software capabilities to  leverage the communication over internet and within the WPAN. Gateway translates the requests, responses and notifications over IP (Internet Protocol) into messages that Things can understand and triggers the intended action on them. RESTful methods are not executed end to end in this model.

This is the most prominent and scalable deployment for home automation. Alexa, (then)SmartThings, JoyLink hubs act as gateway devices to on-board the Things and claim the Things "Works With" them. Things manufacturers would have to comply to the hub's IoT protocol semantics, resource model and security aspects.

Proxy Based Deployment

In this mode of deployment,  Things are connected to IoT cloud via a proxy device or border router. Things in this deployment are usually small or mid-size devices and run IPv6 stack over 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) and low power radio links such as IEEE 802.15.4 or BLE. Things are uniquely identified with IPv6 address in the IoT space. The resources or endpoints hosted on the Things would be identified using an URI. In this deployment, Proxy device may also possess the capability to run a sub net and assign link local IP addresses to Things. In this case Things IP addresses are not globally unique but the URI could be. Proxy device facilitates the RESTFul communication between a Thing and the Cloud. If the Thing uses CoAP based RESTful methods and Cloud uses HTTP based RESTful methods, proxy has to run HTTP-CoAP proxy service. 

Thread protocol is based on this mode of deployment. Though 6LoWPAN is supported by IEEE 802.15.4 as well as Bluetooth (Internet Protocol Support Profile), this deployment is not as popular as gateway based deployment.

Direct Deployment using Back-haul

In this mode of deployment, Things are directly connected to the cloud through a Wi-Fi Access Point or through Ethernet cable. Direct connection with the cloud demands a rich protocol stack, considerable processing power and relatively higher energy source in the Thing. So these devices are unconstrained devices by nature. Each device is uniquely identifiable in the cloud through an IPv6 address. If the Thing supports IO (input and output) capability, cloud credentials would be entered manually to connect to the cloud. Otherwise a mediator device with IO capability shall be used to provision the Thing to cloud. Once the mediator device transfers the cloud credentials and delegates the cloud access , Thing would directly connect to the cloud. This process is called "Easy Setup".  Easy setup is widely used to provision a Thing which doesn't have IO capability.

This is another popular deployment for home automation where Smartphone plays the mediator role. OCF standardized easy setup to provision dumb devices to the cloud. MNOs (Mobile Network Operators) are mere ISPs (Internet Service Provider) in this deployment since user has a choice of choosing the ISP independent of  IoT cloud he is using.

Direct Deployment using LPWAN

In this mode of deployment, Things are directly connected to the cloud through LPWAN (Low  Power Wide Area Network). Multiple LPWAN protocols (NB-IoT, SigFix, LoRa, Neul etc) were emerged to leverage direct connection with the cloud. Though there is no clear winner among them, LoRa and NB-IoT are catching traction with the support of network operators. Direct connection with the cloud demands in-device electronic communication module (be it eUICC), communication protocol stack, considerable processing power and relatively higher energy source in the Thing. So these devices are unconstrained devices by nature and supports mobility. Each device is uniquely identifiable in the cloud with an IPv6 address or UICC Identifier. 

MNOs has more control over this deployment as eUICC is used for authenticating the user and authorizing the user to use a particular service or IoT cloud. This deployment if better fit for Smart City, Smart Agriculture, Smart Logistics, Connected car use cases.