The document proposes a reference architecture for the Internet of Things (IoT). It consists of distributed devices that communicate using various protocols. These devices are supported by a distributed service layer that provides functions like messaging, data transformation and protocol support. This service layer connects to business support systems providing capabilities like fulfilment, assurance and billing. The architecture supports various channels for device management and integration with identity management systems.

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

2. +
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

3. +
“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
CoAP
HTTP Web
Sockets
XMPP
Home
Hubs
Server Side
Architecture
Devices
Protocols

4. +
A Reference Architecture for IoT
Distributed Service Layer
Service Bus & Message Broker
Business Activity Monitoring &
SLAs
Persistence & 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
Device&Protocols
ESB & Messaging:
protocol support,
data transformation,
policy enforcement,
messaging,
persistence
Integration
BusinessSupport
Systems
Channels
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

5. +
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
MQTT
MQTT-
SN
CoAP
HTTP
Web
Sockets
XMPP

6. +
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

7. +
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
..

8. +
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

9. +
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

10. +
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

11. +
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..
..
Identity&AccessManagement
DeviceManagement
BSS
Channels

12. +
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

13. +
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