+

Reference Architecture for the

Internet of Things
+
IoT need for a reference architecture
(roadmap)
Internet of Internet of Internet of Internet of
Content Services People Things

Web 1.0 Web 2.0 Social Media Things

Web-sites eCommerce / Mobile semantically
Search eServices enablement represented in
REST HTML 5 the internet
eMail
Active & Passive
HTML
Device to device
communication
No single definition for Internet of Things but common features:
Things have semantic representation in the Internet
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
"Things may 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 Server Side
Internet-connected wearables Architecture
Low power embedded systems
RFID enabled tracking Protocols
Use of mobile phones to interact with the real world
(e.g. sensing) TCP UDP XMPP
Devices that connect via Bluetooth enabled mobile
phones to the Internet MQTT & HTTP Web
CoAP
MQTT-SN Sockets
Connected Homes & Connected Cars

Architecture: Devices
No single architecture will suffice
Home
A modular scalable architecture with distributed Hubs
capabilities is required
Reference architecture provides a starting point for
architects looking to enable Things and for new
operators ambitious to monetise the internet
+
IoT Scope
+
A Reference Architecture for IoT
Channels:
Channels

Mobile Apps Web / Portal Contact Centre / IVR API Gateway

Service exposition, self-
care, account & device
Interactions Interactions Interactions Interactions
management

BSS:
Business Support

Service activation &

Systems

mgmt, enrolment
services, contract &
device mgmt,
remediation, trouble
Fulfilment Assurance Billing ticketing, billing

Interactions

ESB & Messaging:

Distributed Service Layer protocol support,
Integration

Business Activity Monitoring & data transformation,

Service Bus & Message Broker Persistence & State Mgmt policy enforcement,
SLAs
messaging,
Communications & Protocols Security & AAA Scaling & Elasticity persistence

Protocols Interactions

Communications: Devices:
Protocols, Independent,
Networking & Home Distributed,
TCP UDP XMPP
Addressing Hubs Independently &
Device & Protocols

Directly Connected
UART /
Mesh
.. .. Radio Coax /
MQTT MQTT-SN
Serial
Networks
Lines
SRF and
HTTP
P2P 3G / 4G /
Web CoAP Gateways Other..
Radio LTE
Sockets
Links
+
IoT Communications & Devices

Communications: Protocols,
Devices are independent & Networking & Addressing
distributed
HTTP
TCP UDP Web XMPP
Multiple protocols Sockets

MQTT-
MQTT CoAP
Devicenetwork handoff involve SN
multiple protocols
Devices: Independent &
Distributed
Communications involve
complex Networking and Home
Hubs &
Addressing Gateways

UART /

One size does not fit all Coax / SRF and P2P
Serial Radio Links
Lines
+
IoT Protocols

There are many different usable protocols Communications:

for communication with M2M devices for Protocols,
the Internet of Things Networking &
TCP UDP XMPP
Addressing
Specific protocols are more appropriate for
different devices (e.g. memory & power
profiles) ..
MQTT MQTT-SN
Specific protocols are more appropriate for
different communication needs (e.g. State
Transfer Model & Event Based Model) HTTP
Web CoAP
Sockets
The most usable protocols are:
HTTP/HTTPS & WebSockets (and RESTful
approaches on those)
MQTT 3.1 / 3.1.1
MQTT -SN
Constrained Application Protocol (CoAP)
XMPP
 +
MQTT
MQTT is a publish/subscribe
messaging protocol designed for
lightweight M2M communications. It
was originally developed by IBM and
is now an open standard.

MQTT has a client/server model,

where every sensor is a client and
connects to a server, known as a
broker, over TCP.

MQTT is message oriented. Every

message is a discrete chunk of data,
opaque to the broker.

Every message is published to an

address, known as a topic. Clients may
subscribe to multiple topics. Every
client subscribed to a topic receives
every message published to the topic.
+
MQTT Example

For example, imagine a simple network with

three clients and a central broker.

All three clients open TCP connections with

the broker. Clients B and C subscribe to the
topic temperature

At a later time, Client A publishes a value of

22.5 for topic temperature . The broker
forwards the message to all subscribed
clients.

The publisher subscriber model allows

MQTT clients to communicate one-to-one,
one-to-many and many-to-one.
+
MQTT-SN

Even though MQTT is designed to be

lightweight, it has two drawbacks for very
constrained devices.

Every MQTT client must support TCP and will

typically hold a connection open to the
broker at all times. For some environments
where packet loss is high or computing
resources are scarce, this is a problem.

MQTT topic names are often long strings

which make them impractical for 802.15.4.

Both of these shortcomings are addressed

by the MQTT-SN protocol, which defines a
UDP mapping of MQTT and adds broker
support for indexing topic names.
+
IoT Devices

Devices: Independent, Distributed,

Devices:
Independent,
Independently & Directly
Home Distributed,
Hubs Connected
Independently &
Directly Connected
UART / Purchased through different
Mesh
.. Radio Coax /
Serial channels
Networks
Lines
SRF and Self-made with Arduino or
P2P 3G / 4G / equivalent
Gateways Other..
Radio LTE
Links
Different versions
+
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
BSS:
Service activation &
mgmt, enrolment
services, contract &
device mgmt,
remediation, trouble
Fulfilment Assurance Billing 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 multi-channel Apps mainly developed by vendor / internal API layer
enables operator service features
Devices rarely have setup UI and self-installed first
time connection via Bluetooth or devices own first Model more suited to blend rather than native apps
time wifi network to laptop or mobile App
Device self-registration with Network Operator Contact Centre / IVR
depending on eUICC partner
Voice recognition devices
User monetisation of installed capability (e.g.
Limited use cases (e.g. remote listening devices)
reselling wifi) requires channel for prospective
customers

Web / Portal for Self-Care / Account Mgmt Use Cases Service Enablement / Channels:
API Gateway Service exposition, self-
Self-care use cases for device & hierarchy mgmt
(different-protocol) care, account & device
Integration to BSS, Identity Mgmt & Device Mgmt management
Mobile Apps
Role for Distributed Service Layer
Device driven authentication / device authorisation
challenge Web / Portal
Support both API Gateway & HTML 5 for blended
app support
Contact Centre / IVR
+
Identity & Device Management

User / party identity and device identity management cascade

Channels through an IoT architecture

Identity & Access Management

The device identity is what allows Things to be semantically
BSS
represented in the internet

Device Management
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

Distributed Service Layer delivered at a BSS layer or via a trusted externalised identity
provider of the users choosing

An example of M2M Identity Mgmt is the Telecommunications

Industry Association functional standard for Authentication,
Authorization and Accounting for Smart Device (AAA-SD TIA)
Home
TCP UDP XMPP Hubs

An example of device management supporting M2M use cases

..
Mesh
UART /
Coax /
with no human intervention for secure over the air installation
MQTT MQTT-SN .. Radio
Networks
Serial
Lines of mobile operator credentials into a SIM requires two key
network elements have been specified by the GSMA:
HTTP SRF and
3G / 4G /
Web CoAP
Subscription Manager Data Preparation (SM-DP)
P2P Radio Gateways Other..
LTE
Links
Sockets

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