+

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

• Social Media

• Mobile enablement

• HTML 5

Internet of Things

• “Things” semantically represented in the internet

• Active & Passive

• 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

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

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

TCP UDP

MQTT & MQTT-SN

CoAPHTTP Web

Sockets

XMPP

Home Hubs

Server Side

Architecture

Devices

Protocols

+A Reference Architecture for IoT

Distributed Service Layer

Service Bus & Message BrokerBusiness Activity Monitoring &

SLAsPersistence & State Mgmt

Communications & Protocols Security & AAA Scaling & Elasticity

..

Fulfilment Assurance Billing

Mobile Apps Web / Portal Contact Centre / IVR API Gateway Channels:Service exposition, self-care, account & device management

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

Interactions Interactions Interactions Interactions

TCP UDP

MQTT MQTT-SN

CoAP

HTTP

Web

Sockets

XMPP

Communications: Protocols, Networking & Addressing

Devic

e &

Pro

toco

ls

ESB & Messaging: protocol support, data transformation, policy enforcement, messaging, persistenceIn

teg

ratio

nB

usin

ess S

up

po

rt

Syste

ms

Ch

annels

Interactions

Interactions

Mesh Radio

Networks

UART / Coax / Serial Lines

SRF and P2P

Radio Links

Home Hubs

3G / 4G / LTE

Gateways Other..

Devices: Independent, Distributed, Independently & Directly Connected

..

Protocols

+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

Devices: Independent &

Distributed

SRF and P2P Radio Links

UART / Coax / Serial Lines

Home Hubs & Gateways

TCP UDP

MQTTMQTT-

SNCoAP

HTTP

Web

Sockets

XMPP

+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

CoAP

HTTP

Web

Sockets

XMPP

Communications: Protocols, Networking & Addressing

+IoT Devices

Devices: Independent, Distributed, Independently & Directly Connected

Purchased through different channels

Self-made with Arduino or equivalent

Different versions

Things are not just for Christmas

Mesh Radio

Networks

UART / Coax / Serial Lines

SRF and P2P

Radio Links

Home Hubs

3G / 4G / LTE

Gateways Other..

Devices: Independent, Distributed, Independently & Directly Connected

..

+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

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)

Fulfilment Assurance Billing

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

+IoT Channels: Omni-Channel Key Use Cases

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

Mobile Apps

Apps mainly developed by vendor / internal API layer enables operator service features

Model more suited to blend rather than native apps

Contact Centre / IVR

Voice recognition devices

Limited use cases (e.g. remote listening devices)

Service Enablement / API Gateway

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

Device self-registration with Network Operator depending on eUICC partner

User monetisation of installed capability (e.g. reselling wifi) requires channel for prospective customers

Mobile Apps

Web / Portal

Contact Centre / IVR

Service Enablement / API Gateway

(different-protocol)

Channels:Service exposition, self-care, account & device management

+Identity & Device Management

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)

Distributed Service Layer

..

TCP UDP

MQTT MQTT-SN

CoAP

HTTP

Web

Sockets

XMPP

Mesh Radio

Networks

UART / Coax / Serial Lines

SRF and P2P Radio

Links

Home Hubs

3G / 4G / LTE

Gateways Other..

..

Ide

ntity

& A

ccess M

an

ag

em

en

t

De

vic

e M

an

ag

em

en

t

BSS

Channels

+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