+

Reference Architecture
for the Internet of Things
Charles Gibbons
architect @ apicrazy.com
19th December 2014

+
IoT need for a reference
architecture
Internet
of
Content

Web 1.0
Web-sites
Search
eMail
HTML

Internet
of
Services
Web 2.0
eCommerce /
eServices
REST

Internet
of
People

Internet
of
Things

Social Media
Mobile
enablement
HTML 5

Things
semantically
represented
in the internet
Active &
Passive
Device to
No single definition for Internet of Things but common features:
device
communicatio
Things have semantic representation in the Internet
n

Things can be acted upon in a structured manner (e.g., status, capabilities,

location, measurements) or can report in structured data or can communicate
directly with other Things

"Thingsmay be active (e.g., Zigbee sensor) or passive (e.g. RFID tag)

Different Things may use multiple protocols to communicate with each other
and the internet

The Internet of Things needs a Reference Architecture NB: this ppt is not meant to
be definitive but a point of view on a very interesting domain

+
Things & Server Side
Architecture

The Internet of Things is an umbrella term

that includes multiple different categories:

Wireless Sensor Networks

Internet-connected wearables

Low power embedded systems

RFID enabled tracking

Use of mobile phones to interact with the

real world (e.g. sensing)

Devices that connect via Bluetooth

enabled mobile phones to the Internet
Connected Homes & Connected Cars

Server Side
Architecture
Protocols
TCP

UDP

XMPP

MQTT &
MQTT-SN

CoAP

HTTP Web
Sockets

Devices

Architecture:

No single architecture will suffice

A modular scalable architecture with

distributed capabilities is required

Reference architecture provides a starting

point for architects looking to enable
Things and for new operators ambitious
to monetise the internet

Home
Hubs

Mobile Apps

Web / Portal

Contact Centre / IVR

Interactions

Interactions

Interactions

Business Support
Systems

Channels

+
A Reference Architecture for IoT

Fulfilment

API Gateway

Interactions

Assurance

Channels:
Service exposition, selfcare, account & device
management
BSS:
Service activation &
mgmt, enrolment
services, contract &
device mgmt,
remediation, trouble
ticketing, billing

Billing

Integration

Interactions

Distributed Service Layer

Service Bus & Message Broker

Business Activity Monitoring &

SLAs

Persistence & State Mgmt

Communications & Protocols

Security & AAA

Scaling & Elasticity

Interactions

Device & Protocols

Protocols

TCP

MQTT

HTTP
Web
Sockets

UDP

XMPP

Communications:
Protocols,
Networking &
Addressing

Home
Hubs

..
MQTT-SN

CoAP

ESB & Messaging:

protocol support,
data transformation,
policy enforcement,
messaging,
persistence

SRF and
P2P
Radio
Links

Mesh
.. Radio
Networks

UART /
Coax /
Serial
Lines

3G / 4G /
Gateways
LTE

Other..

Devices:
Independent,
Distributed,
Independently &
Directly Connected

+
IoT Communications & Devices
Devices

are independent
& distributed

Multiple

protocols

Device

network handoff
involve multiple protocols

Communications

involve
complex Networking and
Addressing

One

size does not fit all

Communications: Protocols,
Networking & Addressing
TCP

UDP

HTTP
Web
Sockets

MQTT

MQTTSN

CoAP

XMPP

Devices: Independent &

Distributed
Home
Hubs &
Gateways
UART /
Coax /
Serial
Lines

SRF and P2P

Radio Links

+
IoT Protocols

There are many different usable

protocols for communication with
M2M devices for the Internet of
Things
Specific protocols are more
appropriate for different devices
(e.g. memory & power profiles)
Specific protocols are more
appropriate for different
communication needs (e.g. State
Transfer Model & Event Based
Model)
The most usable protocols are:

HTTP/HTTPS & WebSockets (and

RESTful approaches on those)

MQTT 3.1 / 3.1.1

MQTT -SN

TCP

UDP

MQTT

..
MQTT-SN

HTTP
Web
Sockets

CoAP

XMPP

Communications:
Protocols,
Networking &
Addressing

+
IoT Devices

Home
Hubs
Mesh
.. Radio
Networks
SRF and
P2P
Radio
Links

3G / 4G /
Gateways
LTE

UART /
Coax /
Serial
Lines

Devices: Independent,
Devices:
Distributed, Independently
Independent,
Distributed,
& Directly Connected
Independently &
Directly Connected
Purchased through different

channels

Self-made with Arduino or

equivalent

Different versions

Things are not just for

Christmas

Other..

+
Integration: Distributed Service
Layer

An IoT reference architecture is predicated on a distributed service layer capable of integrating IoT BSS
with Devices

The DSL can replace more traditional mobile network OSS by providing transactional idempotent
processes for massively distributed Things

The DSL itself would need to be massively distributed with different capabilities provided by multiple
parties

For example the GSMAs two network elements for secure over the air installation of mobile operator
credentials into a SIM: Subscription Manager Data Preparation (SM-DP) & Subscription Manager
Secure Routing (SM-SR)

Another example would be Zigbees own Gateway which provides a local service layer / service bus
to Zigbee devices

DSL ownership will be either native or procured by the BSS provider as DSL provides standardised
capabilities for ESB & Messaging capabilities and all of the Protocol support, data transformation, policy
enforcement, messaging & persistence necessary to support that service providerss offerings

A service providers will require a DSL connecting to their customer focused BSS domain

+
BSS for IoT
Fulfilment

Assurance

Billing

BSS:
Service activation &
mgmt, enrolment
services, contract &
device mgmt,
remediation, trouble
ticketing, billing

The BSS of IoT needs to be customer / family / business focused with emphasis on Average Revenue
per Device (ARPD). IoT ARPD or the sum IoT ARPU is considerably lower than traditional mobile ARPU.
The cost is also front-loaded into the device rather than the contract. For these reasons the BSS of IoT
must therefore focusing on a low cost device enablement operating model

Key BSS capabilities:

Fulfilment

Order decomposition, orchestration & fallout

Reliable messaging, self-care operations, up-sell / cross-sell, product mgmt

Assurance:

Customer relationship mgmt, identity mgmt, operations

QoS, Service Delivery, Trouble Ticketing

Billing:

Billing per device or bulk service offering for larger customers

Remediated billing across different networks, for example M2M (handoff / backhaul / roaming)

+
IoT Channels:

Omni-Channel Key Use

Cases

Service Enablement / API Gateway

Mobile Apps

Device registration & usage is multichannel

Apps mainly developed by vendor / internal API

layer enables operator service features

Devices rarely have setup UI and selfinstalled first time connection via
Bluetooth or devices own first time wifi
network to laptop or mobile App

Model more suited to blend rather than native

apps

Device self-registration with Network

Operator depending on eUICC partner

User monetisation of installed capability

(e.g. reselling wifi) requires channel for
customers
Webprospective
/ Portal for Self-Care
/ Account Mgmt Use Cases

Self-care use cases for device & hierarchy mgmt

Integration to BSS, Identity Mgmt & Device Mgmt

Role for Distributed Service Layer

Device driven authentication / device

authorisation challenge

Support both API Gateway & HTML 5 for blended

app support

Contact Centre / IVR

Voice recognition devices

Limited use cases (e.g. remote listening

devices)

Service Enablement / Channels:

Service exposition, selfAPI Gateway
care, account & device
(different-protocol)
management
Mobile Apps
Web / Portal
Contact Centre / IVR

+
Identity & Device Management

Distributed Service Layer

TCP

UDP

MQTT

..
MQTT-SN

HTTP
Web
Sockets

CoAP

Home
Hubs

XMPP

..

SRF and
P2P Radio
Links

3G / 4G /
LTE

Mesh
Radio
Networks

UART /
Coax /
Serial
Lines

Gateways

Other..

Device Management

BSS

Identity & Access Management

Channels

User / party identity and device identity

management cascade through an IoT architecture

The device identity is what allows Things to be

semantically represented in the internet

User / party identity is necessary for channels &

BSS usage but can cascade to the device for
lowest level authorisation

User / party identity to device identity mapping

can be delivered at a BSS layer or via a trusted
externalised identity provider of the users
choosing

An example of M2M Identity Mgmt is

theTelecommunications Industry Association
functional standard forAuthentication,
Authorization and Accounting forSmart Device
(AAA-SD TIA)

An example of device management supporting

M2M use cases with no human intervention for
secure over the air installation of mobile operator
credentials into a SIM requires two key network
elements have been specified by the GSMA:
Subscription Manager Data Preparation (SM-DP)
Subscription Manager Secure Routing (SM-SR)

+
But Where is the OSS?

There is no need for single OSS because anybody can be the

device service provider

The role of the Mobile Network Operator will change because the
Things are connected to the internet rather than to a walled
network

OSS should become commoditised supporting different protocols

on top of which a semantic service layer can be defined

BSS will make use of the semantic service layer and provide
aggregating functions for a complete family of devices

Even though the devices will continually change the standard

protocols and structured services will remain

+
Conclusion: IoT Reference
Architeture

Any IoT reference architecture has to scale for the increasing number of interconnected devices:

Smart Things (e.g. Internet-connected wearables)

Interconnected Things (e.g. Smart Home)

System of Things (e.g. Smart City / national grid)

Communication between Interconnected Things which aggregate to form a System of Things

will not always necessarily communicate through the centralised service layer. Devices will
standardise towards providing their own communication layer (e.g. Zigbee Gateway, SM-SR/-SD).

Interconnected devices will use the most appropriate protocol (e.g. memory & power profiles) and
the most appropriate communication mechanism (e.g. State Transfer Model & Event Based Model)

Intelligent devices will seek to hand-off to the lowest cost network (RFID, Bluetooth, Wifi, Mobile
Network) while maintaining the QoS

The role of the service provider will be to provide intelligence on top of a massively distributed
service layer

Traditional mobile network OSS will be replaced by core capabilities on a service providers
Distributed Service Layer