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
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
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.
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
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.
Interesting!
ReplyDelete