Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
+
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
Se...
+
“Things” & Server Side Architecture
 The Internet of Things is an umbrella term that includes
multiple different catego...
+
A Reference Architecture for IoT
Distributed Service Layer
Service Bus & Message Broker
Business Activity Monitoring &
S...
+
IoT Communications & Devices
• Devices are independent &
distributed
• Multiple protocols
• Device network handoff invol...
+
IoT Protocols
 There are many different usable protocols
for communication with M2M devices for
the Internet of Things
...
+
IoT Devices
 Devices: Independent, Distributed,
Independently & Directly
Connected
 Purchased through different
channe...
+
Integration: Distributed Service Layer
 An IoT reference architecture is predicated on a distributed service layer capa...
+
BSS for IoT
 The BSS of IoT needs to be customer / family / business focused with emphasis on Average Revenue per Devic...
+
IoT Channels: Omni-Channel Key Use Cases
 Web / Portal for Self-Care / Account Mgmt Use Cases
 Self-care use cases for...
+
Identity & Device Management
 User / party identity and device identity management cascade
through an IoT architecture
...
+
But Where is the OSS?
 There is no need for single OSS because anybody can be the device
service provider
 The role of...
+
Conclusion: IoT Reference Architeture
 Any IoT reference architecture has to scale for the increasing number of interco...
Upcoming SlideShare
Loading in …5
×

A reference architecture for the internet of things

18,542 views

Published on

A reference architecture for the internet of things: including Devices, Protocols, massively Distributed Service Layer, Business Support Systems, Channels, Device Management and Identity Management.

Published in: Technology

A reference architecture for the internet of things

  1. 1. + Reference Architecture for the Internet of Things Charles Gibbons architect @ apicrazy.com 19th December 2014
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×