Transcript Internet of Things

+
Reference Architecture for the
Internet of Things
+
IoT – need for a reference architecture
(roadmap)
Internet of
Content
•
•
•
•
•


Web 1.0
Web-sites
Search
eMail
HTML
Internet of
Services
• Web 2.0
• eCommerce /
eServices
• REST
Internet of
People
• Social Media
• Mobile
enablement
• HTML 5
No single definition for Internet of Things but common features:
Internet of
Things
• “Things”
semantically
represented in
the internet
• Active & Passive
• Device to device
communication

“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

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
+
IoT Scope
A Reference Architecture for IoT
Channels
+
Mobile Apps
Web / Portal
Contact Centre / IVR
Interactions
Interactions
Business Support
Systems
Interactions
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
Protocols
Device & 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
Communications: Protocols,
Networking & Addressing
TCP
UDP
HTTP
Web
Sockets
MQTT
MQTTSN
CoAP
protocols
• Device
network handoff involve
multiple protocols
• Communications involve
Devices: Independent &
Distributed
complex Networking and
Addressing
• One size
does not fit all
XMPP
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

Constrained Application Protocol (CoAP)

XMPP
TCP
UDP
MQTT
..
MQTT-SN
HTTP
Web
Sockets
CoAP
XMPP
Communications:
Protocols,
Networking &
Addressing
+
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
Home
Hubs
Mesh
.. Radio
Networks
SRF and
P2P
Radio
Links
3G / 4G /
Gateways
LTE
UART /
Coax /
Serial
Lines
Devices:
 Devices: Independent, Distributed,
Independent,
Independently & Directly
Distributed,
Connected
Independently
&
Directly Connected

Purchased through different
channels

Self-made with Arduino or
equivalent

Different versions
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 GSMA’s 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 Zigbee’s 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 providers’s 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 multi-channel


Devices rarely have setup UI and self-installed first
time connection via Bluetooth or device’s own first
time wifi network to laptop or mobile App
Apps mainly developed by vendor / internal API layer
enables operator service features

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 prospective
customers
Web / 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 user’s 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)

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 provider’s Distributed Service Layer