IoT Training for Research Staff and Students - PolyU

IoT Training for Research Staff and StudentsSpeaker: Ray Ho [ITS]

Introduction to IoT What is the Internet of Things (IoT)? Internet of Things (IoT) overview How IoT benefits to us? IoT architecture and components

Considerations on the adoption of IoT technologies in research project Device selection Device registration and management IoT infrastructure IoT communication protocol Network segmentation Data streaming and collection Data visualization and analytics Security and privacy

What ITS can assist in IoT project? Shared IoT infrastructure LoRaWAN Network on Campus Related services provided by ITS

Demo sessions

Q & A and takeaways

Agenda

The Internet of Things (IoT) refers to a network of interrelated, internet-connected objects that are able to gather and share data over a wireless network without human intervention.

The Internet of Things includes a wide variety of “smart” devices, from industrial machines that transmit data about the production process to sensors that track environmental monitoring remotely.

What make a device “smart”? The answer is that it includes a computer processor and associated hardware. IoT devices can provide edge computing functionality, data storage, and network connectivity which reduce the need for central processing load as well as contain the amount of traffic to backend.

The IoT is making the fabric of the world around us more smarter and more responsive, merging the digital and physical universes.

What is the Internet of Things (IoT)?

Internet of Things (IoT) overview

https://www.youtube.com/watch?v=uEsKZGOxNKw&t=4s

How IoT benefits to us?

Efficient resource

utilization

Reduced human efforts

Lowers the cost and

bring productivity

Real-time marketing

Decision analytics

Better customer

experiences

High-quality data

IoT architecture and components

Devices

Gatew

ays

Processing Unit

User Interface

Application Tier

Network Tier

Data Processing Tier

Sensing Tier

IoT architecture and components – Sensing Tier

Devices

Gatew

ays

Processing Unit

User Interface

Application Tier

Network Tier


Sensing Tier

IoT architecture and components – Network Tier

Devices

Gatew

ays

Processing Unit

User Interface

Application Tier

Network Tier


Sensing Tier

IoT architecture and components – Data Processing Tier

Devices

Gatew

ays

Processing Unit

User Interface

Application Tier

Network Tier


Sensing Tier

IoT architecture and components – Application Tier

Devices

Gatew

ays

Processing Unit

User Interface

Application Tier

Network Tier


Sensing Tier

Areas to be considered in an IoT deployment

IoT

Device selection

Device registration and

management

IoT infrastructure

IoT communication

protocol

Network segmentation

Data streaming and collection

Data visualization and analytics

Security and privacy

Aspects Checklist questions

Data to be collected 1. What type of data will be sampled in the physical environment?2. What is the metadata for the sensory data?3. How accurate the sampled data is required?4. What is the noise tolerance level accepted for the application?5. What level of resolution is required? What is the smallest incremental change in the

input signal that the device requires to sense and report a change in the output signal?

Control actions 6. What control actions are required to be performed by the devices?

Deployment location, operating environment of the devices and mobility

7. Where will the devices to be deployed? How does the physical environment impact the devices? Will the devices be exposed to weather extremes (temperature, wind, moisture, vibration, etc.?)

8. Whether the devices will be a fixed location or be mobile?

Projected growth rate and density of devices

9. What is projected growth rate of the devices to be deployed?

Areas to be considered in an IoT deployment – Device selection

Areas Checklist questions

Projected data volume 10. What is the projected volume of data generated by the device (e.g. bytes per second)?

Integration with exiting operational technology and other IoT devices

11. Will the devices be integrated with existing operational technology?12. Will the devices be connected with other IoT devices?

Repeatability 13. Could the device consistently report the same response when subjected to the same input under constant environmental conditions?

Operation range 14. What is operation range of the device?

Power source 15. What is power source of the device?

Interoperability 16. Is interoperability important in heterogeneous IoT device system?

Security vs. Usability 17. Is data sensitivity more important than device usability?

Areas to be considered in an IoT deployment – Device selection

Areas to be considered in an IoT deployment – Device registration and management

Few points are important on device registration:

Unmanaged IoT devices could pose significant threats to other systems on the campus network.

Device registration is very important to security of the IoT infrastructure.

When connecting the IoT devices to the network, departments should inform ITS to assign the appropriate network segment for the IoT devices.

Two types of device registration and activation are supported in LoRaWAN:

Over-the-Air Activation (OTAA)

Activation by Personalization (ABP)

Areas to be considered in an IoT deployment – Device registration and management

OTAA ABPDescription OTAA is the preferred and most secure way to connect with LoRaWAN

network.

Devices are performed a join-procedure with the network, during which a dynamic DevAddr is assigned and session keys are negotiated with the device.

In some cases, the DevAddr and session keys are needed to hardcode in the device.

This strategy might seem simpler because the join-procedure is skipped, but it has some downsides related to security.

Information required for device registration

AppEUI – Application EUI identifies the end application.

DevEUI – Device EUI set by manufacturer, unique per device.

AppKey – Application Key used in OTAA to generate session keys.

DevAddr – Device Address identifies a device on a particular network.

NwkSKey – Network Session Key encrypts the packet metadata.

AppSKey – Application Session Key encrypts the packet payload.

Advantages • Session keys are only generated when required, so cannot be compromised prior to activation.

• If the device changes to a new network, it can re-join to generate the new session keys - rather than having to be re-programmed.

• Some network settings can be specified at join time.

• The device does not need the capability or resources to perform a join procedure.

• The device does not need to decide whether a join is necessary at any point, since it is never necessary.

• No scheme is necessary to specify a unique DevEUI or AppKey.

Disadvantages • A scheme is required to pre-program each device with a unique DevEUI and AppKey, and the correct AppEUI.

• The device must support the join function and be able to store dynamically generated session keys.

• The scheme to generate the NwkSKey and AppSKey must ensure they are unique, to prevent a widespread breach if a single device is compromised. And the scheme must be secure to prevent the session keys being obtained or derived by rogue parties.

• If the device is compromised at any time, even before activation, the session keys may be discovered.

• Network settings cannot be specified at join time.• Events that warrant a change of session keys (for example, moving to a

new network, the device being compromised, or the session keys being expired) require a re-programming of the device.

Areas to be considered in an IoT deployment – Device registration and managementWhen selecting an IoT device, users should ensure the devices are equipped with the following device management capabilities:

Device Identification

[Type of device].[Dept].[Location].[Measurement]

For example, a sensor is deployed in Room ZS501e by ITS for measuring the temperature. Its name will be as follows:

S.ITS.ZS501E.TEMPERATURE

Device Configuration

It is preferred that IoT device should support remote configuration and software upgrade.

Software and Firmware Update

The software and firmware of the IoT device should be updatable using a secure and configurable mechanism.

Description Example

[Type of device] This field indicates the type of the device. The device can be either a sensor or gateway. S – Sensor

G – Gateway[Dept] This field indicates which department captures the telemetry data Department abbreviation e.g. ITS

[Location] This field indicates where the device is deployed. If possible, please indicate the room number. GH202

[Measurement] This field indicates what kind of telemetry data is being captured Temperature, humidity…etc.

Areas to be considered in an IoT deployment – IoT infrastructure

A proper disaster recovery strategy in place.

Can grow with your business and easily adapt to changing requirements.

SCALABILITY

DISASTER RECOVERY

APPLICATIONS ENVIRONMENT

USABILITYMust be easy to use and easy to integrate with existing processes.

Make sure that the development environment is compatible with your in-house development processes.

Important Capabilities of an IoT Platform

The following are the common communication technologies that are frequently used in IoT:

Personal Area Network (PAN) – e.g. Bluetooth Smart

Local Area Network (LAN) – e.g. Ethernet or WiFi

Low Power Wide Area Network (LPWAN) – e.g. LoRaWAN, Sigfox, NB-IoT or ZigBee

The following aspects should be considered to determine which communication technologies to be used:

1. Communication patterns of the IoT devices

2. Throughput and range requirement

3. Impact to existing IT infrastructure

Areas to be considered in an IoT deployment – IoT communication protocol

1. Communication Patterns


Areas How could this information help to determine the communication

technology?

Deployment location, operating

environment of the sensors

The deployment location of the sensors could help to identify whether

the coverage of communication technology is good enough to cover

the planned deployment areas in the campus.

Mobility of IoT devices This information could help to determine whether a fixed LAN

connection should be used for the deployment.

Projected growth rate, density of sensors

and data volume

The figures could help to provide a forecast of the number of data

messages generated from the IoT devices. The projected figures could

help to determine whether it is cost effective to adopt public

communication services.

2. Throughput and range requirement


3. Impact to existing IT infrastructure

As Zigbee is using the same frequency band as PolyUWLAN WiFi service, it is not recommended to use Zigbee for the device connection if wi-fi service is available around the location.


The following IoT components will sit on a separate network segment with access control is applied:

IoT gateway (e.g. LoRaWAN gateway)

IP-enabled IoT devices

MQTT broker and LoRa network server

No ingress traffic from the Internet is allowed to this subnet to ensure this segment is contained from any

cyber attack from external world .

The private IP addresses are assigned to these IoT components through DHCP server based on the

registered MAC addresses. From this IP address assignment process, we could build an inventory of the

devices which are attached to the IoT segment.

Areas to be considered in an IoT deployment – Network segmentation

Two data communication models are commonly used in IoT:

Areas to be considered in an IoT deployment – Data streaming and collection

Request-response Publish-subscribe

Request-response communication model is one of the most basic communication paradigms. It represents a message exchange pattern especially common in client/server architecture.

Publish-subscribe communication model is an alternative to the traditional request/response model. In this model, there are three parties i.e. publisher, subscriber and a broker.

Comparison between communication protocols:


Protocol Model Standard Transport QoS Security Developer’s Choice

REST HTTP Request/Response IETF TCP - TLS / SSL

MQTT Publish/Subscribe OASIS TCP 3 levels1 TLS / SSL

CoAP Request/Response IETF UDP Limited DTLS

AMQP Publish/Subscribe OASIS TCP 3 levels TLS / SSL

DDS Publish/Subscribe OMG TCP / UDP Extensive TLS / DTLS

XMPP Both IETF TCP - TLS / SSL

HTTP/2.0 Both IETF TCP - TLS / SSL

1 3 different levels quality of service 0, 1 and 2 (QoS):• At most once (0) - the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).• At least once (1) - the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).• Exactly once (2) - the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).

The following naming convention for the topic is recommended to be adopted:

[Dept].[Purpose].[Measurement].[Access]

All topic name is case sensitive so we will use capital letters only.

For example, FMO.OPS.TEMPERATURE.PUBLIC and LSGI.RES.VIBRATION.RESTRICTED.

The maximum length of the topic name is 255 characters.


Description Example

[Dept] This field indicates which department captures the telemetry data Department abbreviation e.g. ITS

[Purpose] This field indicates what the purpose the telemetry data is collected for. There are three categories:

1. Operation (OPS) – this category indicates that the data is used for administrative function of theUniversity. For example, monitoring the temperature and humidity level in general teaching roomfor detecting the potential failure of the air conditioner is categorized under “Operation”

2. Research (RES) – this category indicates the telemetry data is captured for research purpose.3. Teaching / Learning (TL) – this category indicates the data is captured for teaching and learning

purpose.

OPS or RES or TL

[Measurement] This field indicates what kind of telemetry data is being captured Temperature, humidity…etc.

[Access] This field indicates the accessibility of the data. It can be open to all departments in the University or justrestricted to specific department.

Public / Restricted

When choosing data visualization and analytics platform, it is ideal to support below capabilities:

Areas to be considered in an IoT deployment – Data visualization and analytics

OWASP Internet of Things Top 10

Areas to be considered in an IoT deployment – Security and privacy

Risks Description

1 Weak, guessable, or

hardcoded passwords

Use of easily brute forced, publicly available, or unchangeable credentials, including backdoors in firmware or client

software that grants unauthorized access to deployed system.

2 Insecure Network Services Unneeded or insecure network services running on the device itself, especially those exposed to the internet, that

compromise the confidentiality, integrity/authenticity, or availability of information or allow unauthorized remote

control.

3 Insecure Ecosystem

Interfaces

Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows

compromise of the device or its related components. Common issues include a lack of authentication/authorization,

lacking or weak encryption, and a lack of input and output filtering.

4 Lack of Secure Update

Mechanism

Lack of ability to securely update the device. This includes lack of firmware validation on device, lack of secure

delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due

to updates.

5 Use of insecure or outdated

components

Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This

includes insecure customization of operation system platforms, and the use of third-party software of hardware

components from a compromised supply chain.

OWASP Internet of Things Top 10

According to Deployment Guideline for Internet of Things in the University [section 5.4.2] which is published in ITS website, there are 27 security measures among 11 areas are recommended to implement in IoT security.

Areas to be considered in an IoT deployment – Security and privacy

Risks Description

6 Insufficient Privacy

Protection

User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without

permission.

7 Insecure data transfer and

storage

Lack of encryption or access control of sensitive data anywhere within the ecosystem, including at rest, in transit, or

during processing.

8 Lack of device management Lack of security support on devices deployed in production, including asset management, update management,

secure decommissioning, systems monitoring, and response capabilities.

9 Insecure Default Settings Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by

restricting operations from modifying configurations.

10 Lack of Physical Hardening Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a

future remote attack or take local control of the device.

What ITS can assist in IoT project - Shared IoT infrastructureSensing Layer Network & Communication Layer Data Streaming &

Collection Layer Data Visualization & Analytics Layer

Network & Communication Layer

Gateway Bridge

Gateway Bridge is a service which converts LoRa Packet Forwarder protocols into a ChirpStack Network Server common data-format (JSON and Protobuf). This component is part of the ChirpStack open-source LoRaWAN Network Server stack.

Application Server

Application Server is part of the ChirpStack open-source LoRaWAN Network Server stack. It is responsible for the device "inventory" part of a LoRaWAN infrastructure, handling of join-request and the handling and encryption of application payloads.

What ITS can assist in IoT project - Shared IoT infrastructure

Network Server

Network Server is part of the ChirpStack stack. The responsibility of the Network Server component is the de-duplication of received LoRaWAN frames by the LoRa gateways and for the collected frames handle the:

Authentication

LoRaWAN mac-layer (and mac-commands)

Communication with the ChirpStack Application Server

Scheduling of downlink frames

Network & Communication Layer

It is necessary to have a message broker for publish/subscribe data. The broker is primarily responsible for receiving all messages, filtering the messages, decide who is interested in them and then publishing the messages to all subscribed clients. The broker is the server that handles the data transmission between the clients. The broker also holds the sessionsof all persisted clients, including subscriptions and missed messages.

VerneMQ MQTT Broker

VerneMQ is a high-performance, distributed MQTT broker. It scales horizontally and vertically on commodity hardware to support a high number of concurrent publishers and consumers while maintaining low latency and fault tolerance. VerneMQ is the reliable message hub for IoT infrastructure.


Data Streaming & Collection Layer

Confluent Kafka

Confluent Kafka is an open-source data streaming platform which is a high-throughput, low latency platform for handling real-time data feeds. It is using a publish/subscribe model with access control implemented.

The cluster could provide system resilience as the replica of the data collected will be stored in various partitions.

The key capabilities are:

Publish and subscribe to streams of records

Store streams of records in a fault tolerant way

Process streams of records


Data Visualization & Analytics Layer

ThingsBoard

ThingsBoard is an open-source IoT platform for data collection, processing, visualization, and device management.

It enables device connectivity via industry standard IoT protocols - MQTT, CoAP and HTTP. ThingsBoard combines scalability, fault-tolerance and performance.


Provision and manage devices and assets

Collect and visualize data

Process and React

Microservices



Splunk

Splunk is a software platform to search, analyze and visualize the machine-generated data gathered from the websites, applications, sensors, devices etc. which make up your IT infrastructure and business.


Dashboards and Visualizations

Monitoring and Alerting

Reporting

Metrics

Machine Learning Toolkit (MLTK)

Scale and Manageability



The Machine Learning Toolkit (MLTK) is an app available for Splunk Enterprise users through Splunkbase.

acts like an extension to the Splunk platform.

includes new Search Processing Language (SPL) search commands, macros, and visualizations.

Machine learning is a process for generalizing from examples. These generalizations, typically called models, are used to perform a variety of tasks, such as

predicting the value of a field,

forecasting future values,

identifying patterns in data,

detecting anomalies from new data.

The Machine Learning Toolkit (MLTK) enables users to create, validate, manage, and operationalize machine learning models through a guided user interface.



Machine Learning Toolkit features:

Showcase – A Showcase of different sample datasets to help new users explore machine-learning concepts.

Assistants – Guided modelling Assistants to manage your data source, selected algorithm, and any additional parameters used to configure that algorithm.

Algorithms – Over 30 common algorithms and access to more than 300 popular open-source algorithms through the Python for Scientific Computing library.

SPL – Search Processing Language (SPL) search command extensions to perform machine learning analytics on data, such as fitting and applying a model, as well as commands to list, summarize, and delete learned models.

Graphics – Reusable information graphics for viewing and analyzing data in a particular format.


3D Scatter Plot Boxplot Chart Distribution Plot DownsampledLine Chart

Forecast Chart Heatmap Plot Histogram Chart Outliers Chart Scatter Line Chart Scatterplot Matrix



1. Collect available data. 4. Build a model on training data.

2. Clean and transform that data. 5. Evaluate the model test data.

3. Explore and visualize the data. 6. Deploy the model on un-seen data.

The machine learning process follows those steps in theory, but in practice it's rarely linear:


There are different types of machine learning, including:

Regression

Classification

Forecasting

Clustering

Anomaly detection


Each type of machine learning has an accompanying Assistant:


There are 8 examples of Showcase in IoT:


LoRaWAN coverage for PolyU campus open area

7 outdoor LoRa gateways installation is completed in October of this year.

Estimated coverage:

What ITS can assist in IoT project - LoRaWAN Network on Campus

Outdoor gateways

What ITS can assist in IoT project - Related services provided by ITSService Description

Data capturing and provisioning • Provision shared IoT infrastructure for registration of IoT devices.• Provision devices for data capture and communication with gateway.• Provision data storage for collected data.

Data visualization and alerting • Develop simple dashboards to visualize the telemetry data collected.• Setup alert for anomalies detection.• Knowledge transfer on dashboard development.

Data analytics platform as a service • Provide the Splunk platform to perform predictive analysis.

One-stop shop IoT solution deployment • Provide consulting service if a business problem can be resolved by IoT technologies.

• Help to implement the solution riding on the shared IoT infrastructure.

IoT device deployment mode: Within Campus

What ITS helped on this project? Register devices to LoRa network server. Publish data to MQTT broker. Subscribe the topics from MQTT broker and collect data to Kafka cluster. Forward collected data to Thingsboard cluster. Develop dashboards on Thingsboard for visualization.

Data flow diagram

Demo case 1 – GSH environmental monitoring

Kafka ThingsBoardDevice LoRa Gateway MQTT Broker

IoT device deployment mode: Mixed campus and Internet

What ITS helped on this project? Register devices to LoRa network server.

Publish data to MQTT broker.

Collect data from vendor IoT cloud platform through Splunk HTTP Event Collector (HEC).

Subscribe the topics from MQTT broker and collect data to Kafka cluster.

Forward collected data from both Kafka and Splunk to Thingsboard cluster.

Develop dashboards on Thingsboard for visualization.

Develop email and mobile alerts for anomaly detection..

Develop monthly scheduled reports.

Data flow diagram

Demo case 2 – Animal lab environmental monitoring

Kafka ThingsBoardDevice B LoRa Gateway MQTT Broker

Vendor IoT cloud platformDevice A

Vendor LoRa Gateway

Splunk

IoT device deployment mode: Internet only

What ITS helped on this project? Configure MQ settings on vendor IoT cloud platform. Collect data from IoT cloud to Kafka cluster. Forward collected data to Splunk cluster. Perform data transformation on Splunk. Correlate and group raw data. Develop dashboards on Splunk for visualization. Develop an alert on Splunk for anomaly detection.

Provide technical advice on how to use big data analysis of research data on Splunk.

Data flow diagram

Demo case 3 – IoT on research project

Device Vendor IoT cloud platform

Base StationKafka Splunk

Deployment Guideline for Internet of Things in the University

https://www.polyu.edu.hk/its/images/web/Policies_and_Standards/PolyU_IoT_Deployment_Guideline.pdf

For any enquiries please email us: [email protected]

IoT Training for Research Staff and Students - PolyU

Documents

Transcript of IoT Training for Research Staff and Students - PolyU