+
Reference Architecture
for the Internet of Things
Charles Gibbons
architect @ [Link]
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
