Machine-oriented solutions form the bulk of the interesting new areas that people talk about when discussing M2M and the IoT. Unfortunately, neither of these terms is accurate. These are machines sending readings to a central database or computer that can take action – such as sending an electricity bill or scheduling a garbage truck. This is not really “machine to machine” but rather sensor to database. This may seem to be a pedantic use of semantics but there is an important point here that there is little reason for one “machine” – for example a device such as a smart meter – to talk directly to another. Equally it is not really an Internet of Things. The Internet implies an interconnected network where one computer can access information on another computer. Instead, typically, only the “owner” of the machine, such as the electricity company, will be able to access its readings and communicate with the device. Consumers that wish to read this data will then retrieve it from a cloud-based server, not direct from the machine. It is more like the Intranet of Things” where connectivity is restricted to self-contained groups rather than the “Internet’. Again, this may seem pedantic, but it has important implications for installation, security and network architecture.
Most applications envisaged are self-contained in that the data generated is used just for that application. So, for example, in smart metering the meters report to electricity companies or with
parking the car park sensors talk to parking applications.
While the original version of Metcalfe’s law stated that, the value of a telecommunications network is proportional to the square of the number of compatible communicating devices (n2), it did not
specify what protocol it should run on.
Today, many people believe that, for IoT to be a reality, all devices must run the IP protocol so that they can form an interconnected network where all devices can share and access information. Research shows that the IP protocol may not be the best fit for Internet of Things. The question is therefore: How do we make a network for PCs, servers and constrained battery-driven devices that allows for the IoT vision to be a reality.
The requirements
A successful IoT network architecture has the following requirements:
- Devices in an IoT network must be able to access and share content in near real-time
- Devices must be able to send content to groups of devices
- Content must be secured so that only authorized parties can access it
- Offline devices must be able to pull content from the network when they wake up
- Content must be accessible across different types of physical communication mediums, be it
wired or wireless, using the same naming scheme - Communication standard MUST be open and royalty-free for anyone to implement and use
- Transmission rate must be fast enough to support firmware updates, sub-GHz included
Managing the devices, the data and the data-security is important for organizations deploying IoT
networks. A successful IoT networking protocol therefore need to implement these features.
Requirements here are:
- Devices and security must be centrally managed
- Being able to centrally manage what device sends content and which receives that content
The rapid growth in Internet of Things (IoT) deployment has posed unprecedented challenges to the underlying network design. Tomorrow’s global-scale IoT systems will focus on service-oriented data sharing and processing rather than point-to-point data collection. Requirements such as global reachability, mobility, communication diversity, and security will also develop naturally along with the change in the communication patterns. However, existing (IP-based)networks focus only on locations and point-to-point channels. The mismatch between the dynamic requirements and the functionalities provided by the network renders IoT communication inefficient and inconvenient.