IoT Open-Source Architecture

Architecture Overview
The OpenIoT architecture comprises seven main elements [7] as depicted in Fig. 1.

• The Sensor Middleware (Extended Global Sensor Networks, X-GSN) collects, filters and combines data
streams from virtual sensors or physical devices. The Sensor Middleware is deployed on the basis of one
or more distributed instances

Fig. 1. Overview of OpenIoT Architecture and Main Components

(nodes), which may belong to different administrative entities. The OpenIoT prototype implementation
uses X-GSN (Extended GSN), an extended version of the GSN middleware [5]. Furthermore, a mobile
broker (publish/subscribe middleware) is used for the integration of mobile sensors.
• The Cloud Data Storage (Linked Stream Middleware Light, LSM-Light) acts as a cloud database which
enables storage of data streams stemming from the sensor middleware. The cloud infrastructure stores
also metadata required for the operation of OpenIoT. The OpenIoT prototype implementation uses the
Linked Stream Middleware (LSM) [8], which has been re-designed with push-pull data functionality and
cloud interfaces.

• The Scheduler processes requests for on-demand deployment of services and ensures their proper
access to the resources (e.g. data streams) that they require. It discovers sensors and associated data
streams that can contribute to a given service. It also manages a service and activates the resources
involved in its provision.

The Service Delivery & Utility Manager (SD&UM) combines data streams as indicated by service
workflows within the OpenIoT system in order to deliver the requested service (typically expressed as an
SPARQL query). The SD&UM acts also as a service metering facility which keeps track of utility metrics
for each service.

The Request Definition component enables on-the-fly specification of service requests to the OpenIoT
platform. It comprises a set of services for specifying and formulating such requests, while also
submitting them to the Scheduler. This component is supported by a GUI (Graphical User Interface).

The Request Presentation component is in charge of the visualization of the outputs of a service. This
component selects mash-ups from an appropriate library in order to facilitate service presentation.

The Configuration and Monitoring component enables visual management and configuration of
functionalities over sensors and services that are deployed within the OpenIoT platform.
Introduction of
Open Interconnect Consortium

Open Interconnect Consortium, Inc.

Introduction to OIC – Optimized for IoT

RESTful
Architecture

Common Certification
Platform Program

CoAP for
Full Stack
Constrained
Interop. Test
Devices

12
OIC Key Concepts (1/2)

• Free IPR License (Code: Apache 2.0 & Spec: RAND-Z)

License covers both code, standards and related IPR
License applies to members and affiliates of members
• Dedicated and optimized protocols for IoT (e.g. CoAP)
Specific considerations for constrained devices
Fully compliant towards RESTful architecture
Built-in discovery and subscription mechanisms
• Standards and Open Source to allow flexibility creating solutions
Able to address all types of devices, form-factors, companies and markets
with the widest possibility of options
Open Source is just one implementation to solve a problem

13
OIC Key Concepts (2/2)

• Full stack definition for maximum interoperability

Connectivity, Platform and Vertical Services defined
License applies to members and affiliates of members
• Certification and Logo program
Guarantees all devices work together
Consistent user awareness for interoperability

14
OIC Structure
OIC
Board of Directors

Standard IoTivity
Specification & Certification Open Source Project

Open Source Coordination Steering Group

Membership
Sponsored (funded) by OIC
Technology
Planning Develops reference implementation
of OIC standard
Ecosystem
Marketing
Communications
http://www.iotivity.org
OIC Specification Overview
Core Framework Specification

Open Interconnect Consortium, Inc.

Specification Structure

Infrastructure
• Core Framework
• Security
• Remote Access
• Certification Test Plans and Test Cases

Resource Model
• Resource Specification (Domain agnostic)

Per Vertical Domain

• Device Specification
• Domain Specific Resource Specification

20
Core Framework Specification
Overview

Open Interconnect Consortium, Inc.

Objectives

• Core Framework Specification Scope

• Specifies the technical specification(s) comprising of the core
architectural framework, messaging, interfaces and protocols
based on approved use-case scenarios
• Enables the development of vertical profiles (e.g. Smart
Home) on top of the core
• Architect a core framework that is scalable from resource
constrained devices to resource rich devices
• Evaluate technical specification(s) for maximum testability
and interoperability
• Ensure alignment with OIC open source releases

22
OIC Roles

• OIC Client
– i) Initiate an transaction (send a request) & ii) access
an OIC Server to get a service

• OIC Server
– i) host OIC Resource & ii) send a response & provide
service

23
OIC Architecture

• OIC adopted RESTful Architecture

• Current OIC Architecture defines 2 logical roles that devices
can take
- OIC Server : A logical entity that exposes hosted resources
- OIC Client : A logical entity that accesses resources on an OIC Server

OIC OIC
Client Server
R

Model 1

24
Organization of an OIC Device

• OIC Device concept

Resource URI: /oic/p
rt: oic.wk.p

/oic/p if: oic.if.r

n: homePlatform
policy: bm:11
/oic/res /oic/res
pi: at1908
/oic/d /oic/d mnmn: Samsung

/oic/mnt /oic/prs

OIC Device 1 OIC Device 2

Physical Device e.g. light bulb Mandatory

Optional

25
 2. Hardware Internet of Things

IOT DEVICES

The hardware utilized in IoT systems includes devices for a remote dashboard, devices for
control, servers, a routing or bridge device, and sensors. These devices manage key tasks and
functions such as system activation, action specifications, security, communication, and
detection to support-specific goals and actions.

The most important hardware in IoT might be its sensors. These devices consist of energy
modules, power management modules, RF modules, and sensing modules. RF modules manage
communications through their signal processing, WiFi, ZigBee, Bluetooth, radio transceiver,
duplexer, and BAW.

The sensing module manages sensing through assorted active and passive measurement
devices. Here is a list of some of the measurement devices used in IoT:

Devices

accelerometers temperature sensors

magnetometers proximity sensors

gyroscopes image sensors

acoustic sensors light sensors

pressure sensors gas RFID sensors

humidity sensors micro flow sensors

3
 Internet of Things

Wearable electronic devices are small devices worn on the head, neck, arms, torso, and feet.

Smartwatches not only help us stay connected, but as a part of an IoT

system, they allow access needed for improved productivity.

Current smart wearable devices include:

Head Helmets, glasses

Neck Jewelry, collars
Arm Watches, wristbands, rings
Torso Clothing, backpacks
Feet Socks, shoes

4
 Internet of Things

Smart glasses help us enjoy more of the media and services we value, and
when part of an IoT system, they allow a new approach to productivity.

The desktop, tablet, and cellphone remain integral parts of IoT as the command center and
remotes.

The desktop provides the user with the highest level of control over the system and its
settings.

The tablet provides access to the key features of the system in a way resembling the
desktop, and also acts as a remote.

The cellphone allows some essential settings modification and also provides remote
functionality.

Other key connected devices include standard network devices like routers and switches.

5
 IoT Deployment Models
Communication world is chanting “Internet of Things” mantra for many good reasons. Most exciting reasons

could be all electronic devices would be part of internet which opens up new business opportunities for Original

Equipment Manufacturers (OEM), IoT Service Providers and Internet Service Providers (ISP). A decade ago,

IoT was a thought, from a couple of years IoT is transforming into reality. Various products, services, analytics,

intelligence, big data and monetization models have been designed and deployed in recent times. Various

communication protocols strive to find their space in IoT and aligned to it.

While hinting a plethora of opportunities, IoT throws abundant challenges to all stakeholders. Legacy

communication devices (typical Wi-Fi, Bluetooth, ZigBee, Z-Wave devices), interoperability, security,

scalability, LPWAN (Low Power Wide Area Network) and revenue model are the potential challenges which

need immediate attention and address. Nevertheless, these challenges are being addressed or partially addressed.

By the time OCF (Open Connectivity Foundation) standard was released, many organizations parked their first
leg into IoT (Smart Things, Al seen, Thread, Nest to name a few). This pro-activeness helped to prove the IoT

concept thus expedite IoT deployments. On the other hand, the same pro-activeness resulted into plurality of

deployments models.

Gateway Based Deployment

In this mode of deployment IoT devices (Things) in a WPAN (Wireless Personal Area Network) are connected to

a gateway through short range connectivity protocols. And the gateway device is connected to cloud through

internet or LPWAN. Things in this deployment are usually small or mid-size devices which run low power

connectivity protocols such as ZigBee, Z-Wave, BLE, Low Power Wi-Fi, RF, IR etc. Legacy connectivity

devices manufactured during pre IoT times can be used as Things in this type of deployment. Things are

identified in the IoT space using a post-fix over gateway’s identity. In other words, Things are identified using an

URI (Uniform Resource Identifier) in which gateway's identity is integral part of the URI. Gateway possesses the

hardware and software capabilities to leverage the communication over internet and within the WPAN. Gateway

translates the requests, responses and notifications over IP (Internet Protocol) into messages that Things can

understand and triggers the intended action on them. RESTful methods are not executed end to end in this model.

This is the most prominent and scalable deployment for home automation. Alexa, (then)SmartThings, Joy Link

hubs act as gateway devices to on-board the Things and claim the Things "Works With" them. Things

manufacturers would have to comply to the hub's IoT protocol semantics, resource model and security aspects.

Proxy Based Deployment

In this mode of deployment, Things are connected to IoT cloud via a proxy device or border router. Things in

this deployment are usually small or mid-size devices and run IPv6 stack over 6LoWPAN (IPv6 over Low power

Wireless Personal Area Networks) and low power radio links such as IEEE 802.15.4 or BLE. Things are

uniquely identified with IPv6 address in the IoT space. The resources or endpoints hosted on the Things would

be identified using an URI. In this deployment, Proxy device may also possess the capability to run a sub net and

assign link local IP addresses to Things. In this case Things IP addresses are not globally unique but the URI
could be. Proxy device facilitates the RESTFul communication between a Thing and the Cloud. If the Thing uses

CoAP based RESTful methods and Cloud uses HTTP based RESTful methods, proxy has to run HTTP-CoAP

proxy service. Thread protocol is based on this mode of deployment. Though 6LoWPAN is supported by IEEE

802.15.4 as well as Bluetooth (Internet Protocol Support Profile), this deployment is not as popular as gateway-

based deployment.

Direct Deployment over Internet

In this mode of deployment, Things are directly connected to the cloud through a Wi-Fi Access Point or wired

internet. Direct connection with the cloud demands a rich protocol stack, considerable processing power and

relatively higher energy source in the Thing. So these devices are unconstrained devices by nature. Each device

is uniquely identifiable in the cloud through an IPv6 address. If the Thing supports IO (input and output)

capability, cloud credentials would be entered manually to connect to the cloud. Otherwise, a mediator device

with IO capability shall be used to provision the Thing to cloud. Once the mediator device transfers the cloud

credentials and delegates the cloud access, Thing would directly connect to the cloud. This process is called

"Easy Setup". Easy setup is widely used to provision a Thing which doesn't have IO capability.This is another

popular deployment for home automation where Smartphone plays the mediator role. OCF standardized easy

setup to provision dumb devices to the cloud. MNOs ( Mobile Network Operators) remain mere ISPs (Internet

Service Provider) in this deployment since user has a choice of choosing the ISP independent of IoT cloud he is

using.

Direct Deployment over Cellular Radio

In this mode of deployment, Things are directly connected to the cloud through GPRS/3G/4G/5G or LPWAN (

Low Power Wide Area Network). Multiple LPWAN protocols (NB-IoT, SigFix, LoRa, Neul etc) were emerged

to leverage direct connection with the cloud. Though there is no clear winner among them, LoRa and NB-IoT are

catching traction with the support of network operators. Direct connection with the cloud demands on-device

electronic communication module (be it eUICC), communication protocol stack, considerable processing power
and relatively higher energy source in the Thing. So these devices are unconstrained devices by nature and

supports mobility. Each device is uniquely identifiable in the cloud with an IPv6 address or UICC Identifier.

MNOs have more control over this deployment as eUICC is used for authentication, authorization and avails IoT

services through operator core network. This deployment is better fit for Smart City, Smart Agriculture, Smart

Logistics, Connected car use cases.