In our initial internet of things (IoT) opening post,  we said that many of the existing IoT solutions shared a common architecture. This post looks at the challenges in using one of those pieces of the architecture – the ease of use of an “off-shelf” cloud compute platform.

The essentials of an IoT system comprise of a few basic epics/user stories:

1. As a system owner, I want to be able to give my individual IoT endpoints their own unique identities so I can discriminate between them.
2. As a system owner, I want to be able to secure & restrict access to my IoT system to the endpoints that belong to me (and vice-versa).
3. As a system owner, I want to be able to define both individual and bulk policies for what IoT endpoints are allowed to do with their data when they connect.
4. As a system owner, I want to be able to define on both an individual and bulk basis what actions are to be taken as a result of IoT endpoint data transactions.
5. As a system owner, I want to be able to remotely “maintain” all of my IoT endpoints in terms of configurations and software versions.

In this initial approach to the AWS IoT platform, I concentrated on topics 1-3 and left aside the practical deployment issues for the present.

In summary, I would say that I like the Amazon approach to addressing these issues, as in a way they are the table stakes, with the main IoT value creation around what is being measured/monitored and how the data obtained is being intelligently used and combined to provide benefits.

My experience of the Amazon IoT system has focused on the IoT SDK and backend, specifically the python and embedded C versions and trialling the basic data publish/subscription over MQTT. In terms of positives & negatives:

• No special setup required to start using AWS IoT, provided you already have an AWS account. It is also free to use (at present), provided you don’t go crazy and start using millions of messages per month.
• Good initial impression of the documentation & code samples, but this soured slightly over time as a LOT of the examples & setup are tailored for the AWS IoT button as opposed to e.g. linux desktop for doing a quick test drive.
• Bit of confusion over which “C” SDK to use for the desktop test drive. It seems it should be a separate download of linux_mqttmbedtls2.1.1.tar, which is a shame as I only found this out after downloading the embedded C SDK and discovering it within the readme file.
• Very easy to “create” a new IoT device as well as certificates and keys to associate with the device to enable authenticated access to system.
• Less great in terms of specifying precisely what to use in the header files for the code samples for the device ID and access points for pub/sub testing versus e.g. long identity string for the device shadow.
• Not too well explained IoT policy concept i.e. [3] in the user stories. It is absolutely mandatory to create one of these and associate it with the certificate in order even to get connected to the IoT server.
• IoT policies are poorly documented. I had to create a very permissive policy to enable the basic publish and subscribe examples to work: with ANY of my devices I can connect / publish/ subscribe to anything.
• Calling out on the policies:
  • The documentation on identifying *which* specific IoT node in the policy is somewhat lacking. I am not able to make restrictions adequately without affecting something else.
  • Also the documentation on *what/where* the IoT device can publish/subscribe to is also lacking. There needs to be a better definition of the vocabulary & syntax for the policy statement.

Other than these initial problems, probably due as much to my own specific knowledge base, the AWS offering looks good in terms of getting started fast and providing the basic plumbing for an IoT system. Ian Massingham gave a good presentation on AWS IoT at Hardware pioneers in October.

Naturally AWS are looking to monetise IoT through use of their other cloud assets, storage, processing, machine learning and it will be interesting to compare in another blog against Windows Azure IoT which requires a chargeable server reservation for the right to use IoT.

Jan 2017 – update

I can now take back some of what I said earlier about the difficulty of finding the allowable policy definitions for IoT devices interacting with AWS’s backend. They were there in the documentation if you looked for them.

Excluding the “shadow” (Amazon’s virtual copy of the IoT device to use when e2e connections are broken), there are 4 fundamental actions and 3 different types of resource to query the action against.

Action	Resource query
Iot: Connect (enable basic connection from iot device to backend)	Client ID ARN e.g. to enable iot device “clientid1” to connect. arn:aws:iot:us-east-1:123456789012:client/clientid1
Iot: Receive (permission checked for messages to be sent to the device, essential to enable subscription)	Topic ID ARN e.g. for receiving from foo/bar arn:aws:iot:us-east-1:123456789012:topic/foo/bar
Iot: Publish (enables the device to send data to a topic, and/or filter allowable topics)	Topic ID ARN e.g. for publishing to foo/bar arn:aws:iot:us-east-1:123456789012:topic/foo/bar
Iot: Subscribe (restricts allowable topics for iot devices to subscribe to)	Topic filter ID ARN e.g. for subscribing to foo/bar arn:aws:iot:us-east-1:123456789012:topicfilter/foo/bar

In summary of the policies:

• We can restrict connections according to the IoT device ID.
• We can prevent messages being sent to the IoT device(s) or limit them to certain topic groups.
• In a combined policy statement with connect, we can limit the IoT devices able to receive messages from certain topic groups.
• We can limit the topics where IoT devices are able to publish to.
• In a combined policy with connect, we can link the device id-topic pair publishing combination e.g. a destination specific to each client.
• Ditto for subscriptions.

And there seem to be plenty more policy resource query variations in the documentation available using “variables” for some more advanced use cases.

This article reviews the issues when considering the choice of radio technologies when building Internet of Things systems. Our previous article proposed there were two radio technology selections to be made:

• An ultra-low power technology to connect sensor nodes with gateway nodes to enable battery powering for ultra small devices.
• A longer range technology to connect gateway nodes with the internet.

Ultra low power radio technologies

Given that a typical sensor node will be battery powered without re-charge over a period of the order of years, there is massive requirement for an extremely low power solution. Several radio technologies have been developed with this application in mind – of particular note Bluetooth Low Energy and Zigbee/Thread.

The case for Bluetooth is built on the universal availability of this standard in smart phones so allowing these devices to act as either gateways to cloud application, control points for the IoT system or data aggregation/display nodes for non-cloud connected cases.

The case for Zigbee and its Thread variant is built on their optimised design for connecting sensors and particularly their ability to create a mesh network which potentially extends the effective operating range of a gateway node.

Bluetooth SIG is aiming to close these functional gaps in the Bluetooth 5 release which is due late 2016 early 2017, promising in addition to mesh networking increased range. Timing is often critical for the process of choosing winning technical standards, but in this case it seems the whole IoT market has been dormant in a state of great expectation already for a number of years and therefore not a critical issue for Bluetooth.

Ultimately the winning radio standard in this case is likely to be decided by the role of the smart phone in the IoT ecosystem – if it plays an important role then Bluetooth solutions will dominate, if not then it is likely there will be less consolidation into  a single radio type.

Longer range radio technologies

For the RF connection between the gateway node and the ‘internet’, the availability of a local WLAN network has typically between the key factor driving choices as a Wi-Fi signal will usually mean lower costs and power consumption than using cellular. Indeed, Ericsson has estimated that nearly 90% of IoT devices will NOT be connected over cellular. However 5G is being designed with IoT in mind and therefore it may offer a more cost effective and robust communication solution than today’s cellular solutions, yet expectations are that this technology will not be widely available until after 2020*.

Long range IoT is currently dominated by a number of proprietary solutions such as SigFox and LoRa which have emerged to fill a gap of combining long range and low power. The price of this combination is to really cutback on data rates offered to a single node, which suits a lot of the contemporary machine to machine applications. Because of the very low bandwidth per node and their relatively long range, these solutions can be made to be a very economic solution for many applications.

Looking at past experience with mobile telephony, standardised radio solutions drive opportunities to create economies of scale and if operators create economic packages of IoT users then it is likely 5G will dominate in the long term.

*Verizon in the USA is aggressively driving 5G wireless trials and targets some early commercial deployments in 2017 for fixed site application i.e. fibre/cable replacement role, not mobility and not necessarily the scope of 5G required for lowest power IoT.