The core idea is to recognize that IoT may not be Cloud and Internet based and over 200 different protocols, standards and deployment architectures are battling it out. IoT is so diverse that it would easily be possible for a dozen different methods to scale up and survive. So a healthy respect for diversity and suspension of push for standards as an end by itself may help.
a) Edge or Fog Computing
Majority of discussion assumes Big data and intelligence in the cloud. However increasingly solutions are bypassing this paradigm and computations closer to the device if not on the device is much more a consideration. The IoT is not just “ Internet of Data…”
b) IoT Network
The last mile is the domain of IoT networks or capillary networks. The last mile is evolving from wired ( Industrial Ethernet ) to wireless such as WirelssHART, ISA100.11a etc. Wireless is moving away from WiFi and Cellular ( 3G/4G/5G) that are proving unsuitable for the majority of IoT deployments. Spectrum bandwidth is also an issue with narrow band sub gigahertz radio solutions becoming more popular. HaLowis an extension of WiFi for more range using 900 MHz band. Low Power long range IoT networks like LoRa, SigFox, Ingenu, Weightless, NB-IOT etc are getting attention and likely to prevail.
c) Standards
There are a plethora of standards ( see http://www.postscapes.com/internet-of-things-protocols/) in existence or being evolved. Many are premature as the deployments are just about happening and too early a standard adoption will favor incumbents and head of disruptive innovation. For example for the city of Mumbai full scale deployment for 7 applications ( transport, water, power, pollution etc) requires around 1 billion sensors and 200MW power using 3G and a thousand time less using narrow band LoRa type approaches. We believe Interoperability especially at data and API level is more relevant then adoption of standards. Semantic standards like SensorML, Semantic Sensor Net Ontology - W3C, IPSO, are a good starting point. Existing standards like Transducer Electronic Data Sheets (TEDS IEEE 1451 family of Smart Transducer Interface Standards) have much to contribute.
This is a proposed 7 layer model for IoT with with motes, hubs, gateway, platform, application exposing functions thru touchpoints. The intention is to provide consistent model to discuss the roles and layers especially when exploring security and interoperability.
Figure 1 IoT Roles and Layers: Bare Bone Architecture
1.End nodes or devices or motes. There will be a variety from very basic like temperature sensor to richer like a door lock or equipment like clothes washing machine, CAT Scanners to autonomous drones. Motes may be mostly sleeping and may have radio off to preserve battery and occasionally broadcast some data. Motes are normally wireless sense nodes (WSN) but in some cases may be wired (Security camera, PLC in factory). Devices have a combination of sensors and actuators. Actuators can influence the state of a physical device like open a valve or start a pump.
2 Hubs or listener/repeater nodes in a mesh network . For wireless these are typically based on IEEE 802.15.4. These would listen or interact with motes. Hubs would need more power and higher duty cycle then motes as they need to listen and interact with many motes. WiFi and Ethernet are hub and spoke networks where all end nodes (leaf nodes) connect to a (master) node and messages are directly exchanged between the (master) and (leaf) nodes. The master node connects thru a backhaul with global internet In mesh networks intermediate nodes can relay messages and the message is carried over many hops ( 2-5 hops are typical). IoT networks such as IEEE 802.15.4 use a partial mesh network. Most motes are end leaves and are RFD (reduced function devices); they do not relay messages. Some nodes are FFD (fully function devices) and relay messages. 802.15.4 is the base of many IoT networks like Thread, Zigbee, WirelssHART, ISA100.11a etc.
3 IoT gateway or a node that can mediate with the IoT Platform or internet and cloud using Internet protocols and the proprietary non internet protocols ( IoT or Capillary network) between gateway to hub and between hubs to motes. These are network coordinators and manage a PAN (personal area network) or LAN( Local Area Network) .
4 The IoT Gateway acts as Customer Premise Equipment (CPE) for provisioning approaches supporting emerging standards like OneM2M. The number of devices/gateway is a crucial parameter to scalability and cost of deployment and management of the smart infrastructure. A field area network for a electricity utility may need to support a 1-3 Km cell and around 2,000 devices or much more in some cases around 40,000 +.
5 IoT platform On premise or cloud based software that controls device provisioning and collection of raw data. Features provided cover
- Connectivity hardware (Radio modules, cellular modules, etc.)
- Firmware development tools
- Communication protocols (CoAP, MQTT)
- Message brokers and message queueing
- Security and authentication
- Device administration (aka "fleet management")
- SDKs for developing complementary mobile apps, web apps, etc.
This again is a area of rapid evolution and many small providers and startups are being bought by larger providers like Amazon (2lemetry), Autodesk(SeeControl) ,Microsoft(Solair), SAP (Plat.one). Some Indian startups (not necessarily with SmartCity focus) are Altizone, DataGlen, Machinepulse.io, Preva Systems. The major vendors like IBM provide a complete stack.
Nontraditional sources are Bosch IoT Suite( open source ProSyst) and GE Predix.
6 Application
Exposes Functionality to end users, administrators thru a UI or API. City Dashboards, Request status, Alerts on failures or problems etc
7 Touch-Point : Supporting a large number of touchpoints helps engage a diverse user group with anytime convenience. Do consider chat interface using SMS or WhatsApp as well as Website and more traditional support. Call Centre ( IVR) should support transactions and not merrily be a way to lodge a complaint or check status of a request.
Hubs can also support many methods like Homey, by Athom ( 7 different radio) or OnHub by Google. In some scenarios motes can also be hubs ( true mesh network). The IoT gateway device becomes the main point of complexity in managing automatic configuration of devices, low battery or rogue operation and interfacing with the internet and cloud world. While Linux based devices were common for IoT gateway there is a move to low cost Android Smartphone’s for indoor usage . These are quiet adequate and offer Wi-Fi, cellular and Bluetooth connectivity out of the box.
Logical roles can co-exist in same physical device. Smartphone can use BLE to talk to motes ( IOT Hub) and GPRS to talk to IoT Platform. Smartphones may also provide applications and manage multiple connected devices (Performance athlete with multiple wearable’s like Fitbit, apple watch etc). In this scenario the IoT gateway, IoT platform and application as well as touch point are merged into one device.
Interoperability
What should be Interoperable
We anticipate major difficulty in interoperability and are being pragmatic. We therefore suggest parsing interoperability in what ( data, status or control) needs to be interoperable and what level( Across vendors or layers of the IoT Stack)
Measurement: Raw data being reported or smoothed, lagged or historical data
Monitoring: Status of device, Routers, battery usage and error condition etc
Operations: Switching on/off, configuring profile, adding to whitelist, changing resource usage and billing, firmware upgrade, setting Crypto keys or algorithms.
Interoperability at measurement level would be a minimal requirement and at operations level the maximum requirement.
Level of Interoperability
1 Mixing motes or Sensors. Different models or manufacturers devices should be deploy-able. Typically, this is done by the IoT platform supporting the device and model and making sure the communication between device and IoT gateway is operative.
2 Mixing IoT Hubs. This requires communication and API calls from gateway to devices or from devices to gateway to be supported in a transparent way
3 Mixing IoT gateway. This may be an important requirement as different connectivity may be used in different locations. Some devices may use cellular and some may use WiFi or LoRa.
4 Mixing a group of Sensors/motes+Hubs+gateways: This should be a requirement if the IoT platform is not proprietary and limited to a vendor’s own devices. This may require significant degree of coordination for large deployments as vendors have integrated a small number of devices into their platform and adding new device classes or models may not be easy.
5 Mixing IoT Platforms: In practice vendors have their own platforms and support a small set of manufacturers, models and communication methods and proprietary data and API. Data and API interoperability is the major challenge and plethora of standards are being attempted. The Industrial Internet Consortium is a particularly ambitious attempt.
Interoperability Scenarios
We illustrate some scenarios with simplified diagrams
Figure 2 Interoperability Case 1 Air Quality
Fig 3 Interoperability Case 2 Traffic monitoring
Fig 3 Interoperability Case 2 Surveillance
Fig 3 Interoperability Case 4 Smart Infrastructure
