Connectivity and the IoTUK Test Beds

Connectivity and the IoTUK Test Beds

This blog forms part of a series that looks at the technical experiences of three IoTUK projects that ran between 2016 and 2018.

Each of the three IoTUK projects implemented their own IoT technology platform and in this blog we’ll explore how they handled data communications between the various parts of the solution from sensors to cloud services. You will learn about wireless protocols that were used and how inter-cloud communications were managed.

Background

CityVerve is the UK’s smart cities demonstrator, based in Manchester. CityVerve explored how IoT technologies and the forging of new relationships between the public and private sector can make a city truly smart. The resulting solution was a Platform of Platforms connected by a central portal that exposed data from different elements of the city. The data was open to 3rd party developers allowing them to create new and innovative apps.

Diabetes Digital Coach (DDC) is an NHS IoT Test Bed project and has been developed by consortium of 10 technology and evaluation partners, led by the West of England Academic Health Science Network (AHSN). DDC offers an online service to help people with Type 1 and Type 2 diabetes manage their condition and cut the risk of complications. It is available via computer, smart phone and tablet and brings together a number of digital self-management tools, which provide personalised support. When people sign up for an account with the Diabetes Digital Coach, they provide information about themselves, their health, lifestyle, and how they currently manage their diabetes. The Coach then suggests the most appropriate tools to suit their individual needs. The Coach features five tools which have been carefully selected by both healthcare professionals and people with diabetes;  this ‘menu’ covers self-management education, dietitian support, optimising physical activity, insulin and glucose management, and a personal health record.

Technology Integrated Health Management (TIHM) is an NHS IoT test bed aiming to transform support for people with dementia and their carers. The collaboration involves partners from the health, voluntary and technology sectors. Each family in the trial was provided with a home technology pack that was suited to their particular needs. Like the DDC portal, TIHM connects different technology partners but here there is real-time correlation between different data points allowing insights to be gleaned. Any unusual signs are flagged to clinicians who will decide on the appropriate action to take.

Implementations

The three projects set out to explore the combinatorial benefits of bringing together an ecosystem of partners to understand the challenges and opportunities of large scale IoT deployments. Each technology partner integrated their own solution into a centralised platform. No new devices or sensors were created for these projects, instead, companies deployed their existing products and infrastructure to assist citizens with a more connected set of services.

At TIHM, most of the vendors used Bluetooth (or Bluetooth Low Energy BLE) to transmit data collected from their IoT devices. BLE is ideally suited to IoT devices as it uses considerably less power while maintaining a similar communication range to classic Bluetooth.

Devices typically used Bluetooth to connect with a user’s smartphone but dedicated gateways were also used bridge Bluetooth to the internet. 3G/4G cellular connections were also used by some vendors to connect with the internet, either directly from the device or via a gateway.

Gateways were used by many of the SMEs in the projects because they can perform the single function of bridging local communications with the public internet as in the case of a network router. They can also act as a hub for providing other features too:

  • Connectivity – for multiple wireless protocols
  • Reduced risk – adding a layer of security before data travels over the internet
  • Edge computing – Processing data locally before it travels to the cloud, e.g. aggregating streaming data. This is useful because many sensing devices will typically have very little computing power and will concentrate their resources on simply collecting and transmitting data. The gateway provides a more economical way to perform the local computation for a number of devices and can be easily upgraded too. The Raspberry Pi is often used as gateway device and formed the basis of some of the gateways in our three projects.

Where a gateway was required, each vendor used their own. Gateways were not consolidated for the project as this would have stretched the projects in terms of cost and time. Instead, the consolidation was done at a software level by building a centralised platform for each project.

Each vendor was responsible for transferring collected data from the field to their own cloud services. Vendors continued to use the mechanisms they already had in place which were typically HTTP API calls or messaging queuing technologies. Once data reaches clouds belonging to individual SMEs further processing takes place. For all three projects, data then travels over the public internet to reach the main portal which is hosted in a separate cloud. Some projects transferred more of their data than others.

TIHM required the highest percentage of the data collected to be sent to the central portal because they were performing analytics across different data sets to identify when patients needed assistance. If anomalies were discovered for an individual patient, alerts were sent to clinicians over the private NHS N3/HSCN network.

The DDC project had fewer device vendors in its consortium and measurements were limited to weight and activity. Again, as with TIHM, Bluetooth and Wi-Fi were the main mechanisms used to connect IoT devices to the internet because vendors were already using these protocols in their products.

The data passed through SME clouds before ultimately reaching the central portal. DDC had no need to use the NHS N3/HSCN network as the DDC platform did not interface with NHS clinical systems at this stage. Interfaces were developed so that this would be possible at a future stage and could then feed data into Personal Health Records as these become available across the NHS.

CityVerve’s use of wireless technologies was similar to TIHM with Bluetooth and 3G/4G primarily being used at the device end. Some sensors across the city had the ability to be hard wired too, this was typically where power, space, and networking where readily available and there was no need for mobility, i.e. monitoring city buildings.

A couple of the projects experimented using LPWAN technologies such as LoRa and Sigfox to connect devices onto the internet, but these networks were not widely used in the end. At the start of projects three years ago, LPWAN was still in its infancy and this explains why none of the partners in the projects had adopted it at that stage. Today, LPWAN networks are available in multiple cities across the UK. Digital Catapult’s Things Connected programme and IoTUK’s own Boost projects have increased access to LPWAN over the last two years.

Common patterns across the IoTUK projects

Fig 1 

Fig 1 shows the typical routes taken by information collected by IoT devices towards the centralised portals implemented by the three projects.

Bluetooth, 3G/4G and Wi-Fi were definitely the most common wireless protocols used across the three IoTUK projects. These protocols have been established longer than IoT specific protocols such as WPAN (eg Zigbee) and LPWAN. The IoTUK community has seen an increase in the use of the newer protocols recently and if the three projects were starting today, there would be a greater number of partners using the WPAN and LPWAN communications.

The communications between the SMEs clouds and the Portal clouds most commonly used restful API calls using HTTPS and JSON. TIHM was the only one of the three projects to deploy a message queuing system (AMQP) by using a RabbitMQ server as this is a more efficient way to publish high frequency streaming data.

Message queuing offered a number of benefits to the IoT deployments:

  • Reduced the size of the payload transmitted. The World Wide Web was built using a stack of protocols that were designed in the days of desktop computers. A new stack of IoT protocols reduces the size messages transmitted across networks as shown in Fig2.

Fig 2

  • Allowed real-time notification of events using a publish-and-subscribe model for exchanging messages.
  • Compensated for brittle networks. A message will be stored in the case of the network going down. The message will be automatically forwarded when the network connection is resumed. IoT devices are often deployed in areas of poor connectivity (patient’s broadband may be accidentally switched off) so message queuing provides an extra layer of reliability.
  • Provided secure and assured communications. Encryption is built in to message queuing systems and message delivery can be guaranteed using at-least-once and at-most-once delivery assurances.

In the next blog in this series, we’ll take a closer look at how data interoperability was addressed by the test beds.

Idris Jahn
idris.jahn.221@gmail.com
No Comments

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.