the evolution from machine-to-machine (m2m) to the...

The Evolution from Machine-to-Machine (M2M) to the Internet of Everything: Technologies and Standards

BRKIOT-2020

Samer Salam

Principal Engineer, Cisco

© 2014 Cisco and/or its affiliates. All rights reserved. BRKIOT-2020 Cisco Public

2003: 0.5B Connected Devices

2005: IP Traffic: 29 exabytes

2005: First Smartphone

2008: Video Traffic: 21 exabytes

2012: 1B Smartphones

2010: 7B Connected Devices

2017: 300M Connected Vehicles

2010: 0.5B Smartphones

2016: IP Traffic: 1.3 zettabytes

2013: 10B Connected Devices

2012: 50M Connected Vehicles

2011: 90M Smartmeters

2020: 1B Smartmeters

2020: 4.5B New People, 37B New Things

Internet of Things Evolution Timeline

2008: Internet became Internet of Things Number of devices on the Internet exceeded the number of people on the Internet (Source: IDC Research, 2013)

3


Protocol Stack for the Internet of Everything

PHY

Link

Network

Application

Protocols

• Adapting IPv6 to LLN

• Routing for LLN

• Constrained Devices

• Determinism

• Constrained Applications, Diverse Communication Models

• APIs, Data Management, Semantic Interoperability Application

Services

4

•S

ecu

rity

•S

ca

lab

ility


Terms & Relationships

5

Internet of Things

Internet of Everything

Machine-to-Machine

Machine Type Communication


IoT… in the Eye of the Beholder

6

Credit: L. Atzori, A. Iera and G. Morabito, “The Internet of Things: A Survey”, Computer Networks, 54(15): 2787-2805, 2010.

RFID

UID

Spimes

Smart Items

Everyday

Objects

Wireless

Sensors &

Actuators

NFC

WISP

“Things”-oriented Visions

Semantic

Execution

Environments

Reasoning

Over Data

Semantic

Technologies

“Semantic”-oriented Visions

Smart

Semantic

Middleware

Internet 0

IPSO

(IP for Smart

Objects)

Communicating

Things

Connectivity

for Anything

Web of

Things

“Internet”-oriented Visions

Internet of

Things


En

ab

lers

B

arrie

rs

En

ab

lers

B

arrie

rs

Revenue opportunities for

Wireline Operators & MNOs

Adoption of Mobile

Technologies: 3G/LTE

Lack of ubiquitous standards

Complex Supply Chain

Costs of initial

deployment

IoT / M2M Enablers and Barriers

Government and

regulatory support

Ubiquitous Connectivity &

Compute:

Falling cost of M2M modules

and devices

Shift of business model

7

Cost & Efficiency

Improvement opportunity to

Enterprises


Today … the Intranets of Things

• Some M2M deployments date back to over 20 years.

• Fragmented, vertical solutions implemented in silos.

• Proprietary communication stacks.

• Tight application-to-device coupling.

• Dedicated networks, requiring protocol gateways for interconnection.

8

G G

1 Device – 1 Application Dedicated Networks


From… Vertical Communication Stacks

KNX

RF

IEEE

802.15.4

Z-Wave

PHY

Link

Network

Application

ANT /

ANT+

KNX LonWorks

ZigBee

Bluetooth Bluetooth

LE EnOcean

IEEE

802.11x

DASH7

ONE-NET NFC IEEE

1902.1

ONE-

NET BACnet

ModBus

IEEE

1609.4

DASH7

User / Device Monitoring Home Automation Large Building Automation Automotive

Example short range wireless protocols:

9


Towards … the Internet of Everything

• Any application to any device.

• Standard communication protocols and open APIs.

• Advantages:

– New services & applications

– Large developer community

– New roles in the business ecosystem

– Cost efficiency through converged networks

10

Converged Network as a Horizontal Platform


To …Convergence on Standards

IEEE 802.15.4 2.4GHz

DSSS

IEEE 802.15.4 MAC

IEEE P1901.2

PHY

IEEE P1901.2

MAC IEEE

802.11

Wi-Fi

IEEE 802.3

Ethernet

IEEE

802.16

WiMax

2G / 3G /

LTE Mobile IEEE

802.15.4g (FSK, DSSS, OFDM)

IEEE 802.15.4

MAC (including FHSS)

802.15.4e MAC enhancements

6LoWPAN (RFC 6282) RFC 2464 RFC 5121 RFC 5072

802.1x / EAP-TLS based Access Control

IPv6 / IPv4

TCP / UDP

ZigBee

NWK

ZigBee

ZAL (SE 2.0) CoAP

DDS-

RTPS MQTT XMPP

IEEE

1888 REST /

HTTPS SIP /

SIMPLE

IEC 61968 CIM

ANSI C12.19/C12.22

DLMS COSEM

IEC

61850

IEC

60870 MODBUS DNP

PHY

Link

Network

Application …

11

“The challenge is the way from silos to platforms.”

S. Tarkoma Academic Coordinator of Finland’s national Internet of Things Program

12

Physical & Link Layers

13


Challenges

14

• Wireless Wired

• Mobile Stationary

• Long-range Short-range

• Extremely large number of endpoints

•Deterministic Random

•Short, bursty Long-tailed

•Tight latency Relaxed

• Constrained Non-Constrained

Time Sensitive Networks Low Power Networks

Cellular Off-load Mesh & Long Range Wireless

Device Characteristics

Traffic Characteristics

Access Characteristics

Scalability


IEEE 802.15.4

• Scope: started with Personal Area Network (PAN) and grew beyond

• Range: 10’s m up to 1 km (802.15.4.g)

• Speeds: Kb/s to Gb/s

• Applications:

– “Specialty”, typically short range, communications

– Foundation for several protocol stacks Zigbee, Zigbee RF4CE, Zigbee Pro, Wireless HART, ISA 100.11a, RPL

• Features:

– Low BW, low transmit power, small frame size (127 bytes, up to 2047 bytes w/ 802.15.4g)

– Fully acknowledged for reliability

– Several Frequency Bands (vary by country/region)

– Secure & non-secure mode

15


IEEE 802.15.4

• Full Function Device (FFD)

– Operate as a PAN co-ordinator (allocates local addresses, relay messages, gateway to other PANs)

– Communicate with any other device (FFD or RFD)

• Reduced Function Device (RFD)

– Very simple device, modest resource requirements

– Only communicate with FFD

Node Types

16


Star Cluster Tree Mesh

IEEE 802.15.4 Topologies

• All devices communicate to PAN co-ordinator which uses mains power

• Other devices can be battery/scavenger

Single PAN co-ordinator for all topologies

• Devices can communicate directly if within range

P

R F

F

R

R

P

F F

F

R

F

R

F F

F

F

P

R

R

F

R

R

R

R R

• Higher layer protocols like RPL may create their own topology that do not follow 802.15.4 topologies

17


IEEE 802.11ah

• Scope: WiFi standard for IoT

• Range: up to 1 km

• Speeds: 150 Kbps – 340 Mbps

• Applications:

– Sensor network backhaul

– Extended range Wi-Fi

– Rural communication

– M2M Communication (metering, fleet management, security sensing…)

• Features: – 1,2,4,8,16 MHz BW modes for flexible deployment around the world.

– Large coverage area, one-hop reach, good propagation and penetration

– Sub GHz band, license-exempt or light licensing

– Low power: extended standby time, sensor traffic prioritization, short data transmission

18


IEEE 802.11ah Use-Cases

19

IEEE 802.11ah

AP

Backbone / WAN

IEEE 802.11ah

AP

802.15.4/802.11ah GW

802.15.4/802.11ah GW

Sensor / Actuator

Mesh with

802.15.4

802.11ah

Backhaul

Analog/Digital I/O

Analog/Digital I/O

Wireless

Remote I/O

Sensor/Actor

Network

Backhaul


IEEE 802.11ah

• Extended range Wi-Fi hotspots for cellular traffic offloading

Extended Range Wi-Fi

802.11a/g/n/ac

AP

20

802.11ah AP

Cellular Base Station

WLAN .11a/g/n/ac link

WLAN .11ah link

Cellular link

Cellular Coverage

802.11ah Coverage


IEEE 802.1 Time Sensitive Networking (TSN)

• IEEE 802.1 “Audio Video Bridging (AVB)” Task Group is now “Time-Sensitive Networking (TSN)” Task Group.

• Goal: Converge fixed-latency process control, low-latency audio or video streaming, and best-effort data on the same physical network.

• Applications:

– Industrial

– Automotive

– Avionics

21


IEEE 802.1 Time Sensitive Networking (TSN)

1. Time synchronization. Requirements vary: 10 nS – 10 µS.

2. Significant portion of total BW (≤ 75%) devoted to data streams that expect:

a. pre-configured or run-time registration & admission control;

b. guaranteed maximum (and relatively short) end-to-end latency; and

c. zero packet loss due to congestion.

3. Support time-scheduled transmission with extremely low jitter.

4. Other traffic classes (weighted, prioritized, etc.) must also be carried and provide their expected QoS.

5. Replicated data on multiple paths independent from topology protocol.

Requirements

22


IEEE 802.1Qca

• 802.1Qca allows for Explicit Paths computed via a Path Computational Element (PCE)

• Resiliency via explicit disjoint paths.

– IEEE 802.1CB will define mechanisms for frame redundant transmission/filtering

• IS-IS used for topology discovery, but NOT control.

• Path Reservation, Time synchronization and scheduling control via IS-IS.

Path Control & Reservation

23

Network Layer

24


Challenges

25

Low Power & Lossy Network

(LLN)

Operate with hard & very small bound

on state

Optimize for saving energy

Support p2p, p2mp &

mp2p traffic patterns

Operate over link layers

with restricted frame size

Operate over unreliable

‘lossy’ links


6LoWPAN (RFC 6282)

• IPv6 over Low power Wireless Personal Area Networks – Initially an adaptation layer for IPv6 over IEEE 802.15.4 links

– Now used by IEEE P1901.2 (PLC), Bluetooth Low Energy, DECT Ultra Low Energy

• Why is an adaption layer needed? – IEEE 802.15.4 MTU originally 127 bytes, IPv6 minimum MTU is 1280 bytes

– Although 802.15.4g enables larger frame size, BW optimization still required

– IPv6 does not do fragmentation, left to end nodes or lower layers

• Performs 3 functions each with its own 6LoWPAN header – IPv6 Header compression

– IPv6 packet fragmentation and re-assembly

– Layer 2 forwarding (also referred to as Mesh Under, for future use)

• RFC4919 - Overview, Assumptions, Problem Statement, and Goals

IPv6

and

Upper Layers

802.15.4 PHY

802.15.4 MAC

6LowPAN

26


6LoWPAN Header Stacks

• Several 6LoWPAN headers are included when necessary

– IPv6 compression header

– Fragmentation header (eliminated if single datagram can fit entire IPv6 payload)

– Mesh or Layer 2 forwarding header (currently not used/implemented)

Less max 25 bytes for frame overhead

MTU for 802.15.4

Less max 21 bytes link layer security Worst case leaves only 81 bytes

for headers and payload

IPv6 Fragmentation Multiple L2 Hops

No No

Yes No

Yes Yes (Future)

No Yes (Future)

IPv6 Payload

127 bytes

102 Bytes

81 bytes

IPv6 Payload

IPv6 Payload

IPv6 Payload

IPv6 Header

Compression

IPv6 Header

Compression

Fragment

Header

Fragment

Header

IPv6 Header

Compression

Mesh Header

Mesh Header

IPv6 Header

Compression

802.15.4 Header

802.15.4 Header

802.15.4 Header

802.15.4 Header

27


Network Layer

• IPv6 distance vector routing protocol

• Builds a Destination Oriented Directed Acyclic Graph (DODAG) based on an objective

• Supports shortest-path constraint based routing

• Proactive: builds alternate paths during topology setup

• Under-reactive: local repair preferred to global repair to cope with transient failures

• Supports MP2P, P2MP and P2P between leaves (devices) and root (border router)

RPL (RFC 6550)

28


Network Layer

• RPL instance honors a specific routing objective/constraint.

– Member DODAGs share the same Objective Function (OF)

• OF computes a device rank relative to distance from DODAG root.

• Upward and Downward routing from DODAG root.

RPL

29

5 5

4 5

3 3

3 2

1

4

4

3 3

3 2

1

4

RPL Instance Consists of one or more DODAGs sharing SAME service type

(Objective Function). Identified by RPL INSTANCE ID

DODAG

DODAG Root

Identified by DODAG ID

(Node IPv6 address) D

OW

N

To

wa

rds

DO

DA

G le

afs

Rank > 1

DODAG Root Rank = 1 (always)

Ra

nk in

cre

ase

s

Application Layer

30


IoT Application Protocols Landscape

31

HTTP

CoAP XMPP

MQTT

DDS

AMQP

SIP IEEE 1888 Req/Resp?


Protocol Comparison Protocol Functions Primary Use Transport Format SDO

CoAP • REST resource manipulation via CRUD

• Resource tagging with attributes

• Resource discovery through RD

LLNs UDP Binary IETF

XMPP • Manage presence

• Session establishment

• Data transfer (text or binary)

Instant Messaging TCP

HTTP

XML IETF

XSF

MQTT • Light weight Pub/sub messaging

• Message queuing for future subscribers

Enterprise Telemetry TCP Binary OASIS

AMQP • Message orientation, queuing & pub/sub

• Data transfer with delivery guarantees (at least

once, at most once, exactly once)

Financial services TCP Binary OASIS

SIP • Manage presence

• Session establishment

• Data transfer (voice, video, text)

IP Telephony TCP, UDP, SCTP XML IETF

IEEE 1888 • Read/write data into URI

• Handling time-series data

Energy & Facility

Management

SOAP / HTTP

XML IEEE

DDS

(RTPS)

• Pub/Sub messaging with well-defined data types

• Data Discovery

• Elaborate QoS

Real time distributed

systems (military, industrial,

…)

UDP Binary OMG


Constrained Application Protocol (CoAP) Motivation

33

Server

Client

Get /pressure

200 OK

Application/text

22kPa

REST Request

Client Server

HTTP Request

TCP 3-way Handshake

TCP 2-way Termination

Get /pressure

200 OK

Application/text

22kPa


Constrained Application Protocol (CoAP) • Lightweight version of HTTP for constrained environments

– UDP based – Small, simple header (< 10 bytes)

• Request / Response model (GET, POST, PUT, DELETE)

• Pub / Sub Model (OBSERVE)

• Supports: Block Transfer, Resource Discovery, Proxy (HTTP/CoAP), Caching 802.15.4 PHY

802.15.4 MAC

6LowPAN

UDP

IPv6

CoAP

Application

CON, ID=0x27

GET /temp

CON, ID=0x27

GET /temp

CON, ID=0x27

GET /temp

ACK, ID=0x27

22.5°

Client Server

Retransmit using Exponential

back off until reply

NON, ID=0x27

GET /temp

NON, ID=0x27

22.5°

Client Server

CON, ID=0x27

GET /weight

RST, ID=0x27

Client Server Confirm No Confirm Reset

coap://node12.com:5683/temp.xml

34


Constrained RESTful (CoRE) Architecture

35

Server

Server

Proxy

Client

C

C

C

C

C

HTTP

HTTP

CoAP

CoAP

CoAP

CoAP

Internet Constrained Environment

(e.g. LLN)

REST

Services Layer

36


Value Chain Evolution for Service Providers

Revenue distribution shift to:

• Support business decisions with M2M data intelligence.

• Secure and manage M2M data

• Identify and create new applications for M2M

“M2M Data to be Value-Added Service for Telcos”

M2M Magazine, March 2012

Revenue moving towards the service enablement layer & the support

of data access, storage, management and security.

Connectivity

Devices

Management

Services

Connectivity

Devices

Service

Enablement

Data

Management

Services

Connectivity

Devices

Connectivity Deployment Integration

Yesterday

Today

Tomorrow

37


Service Enablement Layer

• Store & Share Paradigm

– Devices push data to the platform

– Platform provides data to interested applications

• Strict access rights management for privacy & security.

• Industry Standards:

– ETSI M2M • Requirements: TS 102 689

• Architecture: TS 102 690

• Interfaces: TS 102 921

– oneM2M (specifications in progress)

38

Application

Layer

Management

Services (SIM,

Connectivity…)

Connectivity

Devices

Application

Layer

Management

Services

Connectivity

Devices

Service

Enablement

Data


ETSI M2M Network Architecture

39

M2M Area Networks

• 802.15.4

• 802.11

• PLC

• M-BUS, …

Access Networks

• xDSL

• WiMax

• FTTX

• 3GPP, ..

Core Networks

• IP NGN

• MPLS/IP

Applications

• Smart Energy

• eHealth

• Smart City

• Fleet Management

Based on existing technologies…


ETSI M2M Overview

40

• Defines a Service Capability Layer (SCL) on top of connectivity layers

– SCL performs registration, access rights, security & authentication, data-transfer, pub/sub, group management…

• RESTful Application APIs

– Bindings to CoAP & HTTP

• Re-use BBF TR-069 & OMA-DM for device management


ETSI M2M System Architecture

41

M2M Application Domain

M2M Network Domain

Based on existing standards & technologies, e.g.: MPLS/IP, 3GPP, etc.

M2M Device Domain

Based on existing standards & technologies, e.g.: ZigBee, M-BUS, KNX, etc.

Application (e.g. Smart Metering application)

ETSI M2M Service Capabilities

M2M D’

Device Application

M2M Device

Application

M2M Service

Capabilities

M2M Gateway

M2M Service

Capabilities

M2M Area Network

dIa

dIa

mIa

mId

User interface to application (monitoring, preferences, …)

M2M Core

M2M Devices / Gateways

Network (MAN, WAN)

Scope of ETSI M2M

M2M Server

M2M Device

M2M Gateway


ETSI M2M

• ETSI M2M uses a RESTful architecture – Data represented as Resources, uniquely addressable via URIs

– Manipulation through CRUD primitives

• ETSI M2M specifies organization of data into a resource tree – Provides data mediation function

– Describes how resources relate to each other

– Allows traversal/query of data in an efficient way

– Speeds up development of platforms

• The resource tree of an SCL includes: – Location of other SCLs in the network (in other devices or GWs)

– List of registered Applications

– Announced resources on remote elements

– Access rights to various resources

– Containers to store actual application data

Resources & their Organization

42


ETSI M2M Resource Structure

43


oneM2M Background

• Partnership project founded by 7 SDOs to minimize standards fragmentation

– USA: TIA, ATSI

– Japan: ARIB, TTC

– China: CCSA

– Europe: ETSI

– Korea: TTA

• Focus on M2M horizontal common services which may be offered by M2M Service Providers across multiple verticals.

• Founders agreed to transfer & stop their own overlapping M2M service layer work.

From Technical Bodies to Partnerships

ETSI TC M2METSI TC M2Mestablished 2008.

First set of M2M platformstandards to market in 2011.

oneM2M Partnershippproject establishedJuly 2012

© ETSI 2012. All rights reserved18

July 2012.

44


oneM2M Scope

Applications

Common Services

Underlying

Network Services

Other common

services

Reference point

Reference point

Reference point

oneM2M scope

Common Services Entity (CSE)

• Connectivity Handling

• Efficient, reliable, scalable use of

underlying network

• Remote Device Management

• Configuration & Diagnostics functions

• Data Exchange

• Storing & sharing data between apps;

event notification

• Security & Access control

• Access to data: Who, what, when,

why

Underlying Network provides value added services to

the CSEs. Such as QoS, device management, location

services and device triggering.

45


oneM2M Functional Architecture

• Application Entity (AE): provides Application logic

• Common Services Entity (CSE): sets of "service

functions”

• Infrastructure nodes ~ servers

• Middle Nodes ~ gateways

• Application Service Nodes: smart oneM2M devices

• Application Dedicated Nodes: dumb oneM2M

devices

• Non-oneM2M devices

• Mca reference point: communication flows between

AE & CSE

• Mcc reference point: communication flows between

two CSEs

• Mcn reference point: communication flows between

CSE & Underlying Network Services Entity (NSE)

• Mcc' reference point: goal to be as similar as possible

to Mcc reference point - some differences anticipated

46


oneM2M Common Service Functions

47


oneM2M Resources

• Entities in oneM2M System

(Applications, CSEs, "data", etc.)

are represented as "resources”.

• oneM2M will not define a static

Resource Structure, rather

provide means by which

Resources can be linked.

o Follows a REST constraint

known as Hypermedia as the

Engine of Application State

(HATEOAS)

Example:

• The Group resource

shall store information

about resources of the

same type that need to

be addressed as a

Group.

• Operations addressed

to a Group resource

shall be executed in a

bulk mode for all

members belonging to

the Group.

48


oneM2M Interface to Underlying Network

• Enable interaction between oneM2M services layer and underlying network (e.g. 3GPP)

• Allow access to network service functions:

– Requests for QoS and prioritization for M2M communication

– Requests related to specific M2M devices or gateways (Transmission scheduling, indication for small data, device triggering, etc.)

– Exchange data related to location of M2M devices or gateways

• 3GPP initiated Service Exposure and Enablement Support (SEES) Work Item for Release 13 (2015) “M2M service enablement, and exposure of a 3GPP network’s information and capabilities”

Mcn Reference Point

49

Research & Future Items

50


Semantics and Abstractions The Need for Semantics & Abstractions

51

RM Young 05103 Wind Sensor

Wind Speed vs. Output Frequency

m/s = 0.0980 x Hz

Vaisala WM30 Wind Sensor


m/s = -0.24 + 0.699 × Hz

Application

/Frequency = 20 Hz /Frequency = 20 Hz Raw data is useless to the application, unless the application understands device details.

But wait, that’s the problem with IoT today!


Semantics and Abstractions The Need for Semantics & Abstractions

52

RM Young 05103 Wind Sensor


m/s = 0.0980 x Hz

Vaisala WM30 Wind Sensor


m/s = -0.24 + 0.699 × Hz

Application

/Frequency = 20 Hz /Frequency = 20 Hz

Semantics & Abstraction Layer

/WindSpeed= 1.96 m/s /WindSpeed= 13.74 m/s

Translate device raw Data into Information that applications can consume, while being device agnostic.


Semantics & Abstractions

• Make the IoT data understandable without prior knowledge about the data or producing devices.

• Make IoT data & devices discoverable based on their description.

• Offer interaction on higher level of abstraction (physical / virtual entity modeling)

– E.g. “Give me the indoor temperature of the VNC2-Saturna conference room”

Benefits

53

Application provides high-level model of real world

entities (requires domain-specific semantic models)

Device Abstraction Layer

Technology specific device representations (ZigBee,

KNX, UPnP,…)

1. Business-level application communication

E.g. “get the indoor temperature of VNC2-Saturna

2. Abstract Device Communication

E.g. “get /Temperature from device with ID=0002

3. Technology specific device communication

E.g. “send the command <ZigBee Command> to endpoint ID <ZigBee ID>


Semantics & Abstractions Ontologies

54

• Ontology is a formal semantic model representing the knowledge of a specific domain in a machine interpretable format.

• Using ontologies, it is possible to describe the meaning of IoT data & associate it with a context.

• Simple IoT Ontolgy:

Device

Entity

Resource

Service

is attached to is associated

with

accesses HW Component

e.g. Temperature Sensor

“Thing” in IoT

e.g. VNC2-Saturna Conference

Room

SW Component

e.g. / VNC2-Saturna-Temp

API

e.g. HTTP Get


Semantics & Abstractions E.g. W3C Semantic Sensor Network (SSN) Ontology

55

A formal OWL-DL ontology for modeling:

• sensor devices

• sensor capabilities

• sensor systems

• sensing processes


Semantics & Abstractions

• Ontologies to be defined by domain experts (home automation, industrial, healthcare…)

– Leverage work from academia, W3C on semantic web & SSN

• Framework for using ontologies in the service layer needs to be standardized

Moving Forward

56


The Road Ahead

• Security & Privacy

– Key management at scale

– Anonymity of data

• Big Data Analytics

– Analytics of data-in-motion

57

Summary

58


Summary: Where are we on the road to a Horizontal Platform?

PHY

Link

Network

Application

Protocols

IP: the thin waist of the hourglass

6LowPAN: IPv6 Adaptation to LLN

RPL: Routing for LLN

Pragmatic number of protocols, divergence necessitated

by nature of endpoints (power, compute constraints…)

Enhancements to support Determinism & Time Sensitive applications

Multiple competing & occasionally functionally overlapping protocols

oneM2M CSE, Semantics Application

Services

59

PHY

Link

Network

Application

Protocols

Application

Services


Acronyms

60

Term Details

AMQP Advanced Message Queuing Protocol

CoAP Constrained Application Protocol

CSE Common Services Entity

CSF Common Services Function

DDS Distributed Data Services

DODAG Destination Oriented Directed Acyclic

Graph

FFD Full Function Device

IoE Internet of Everything

IoT Internet of Things

M2M Machine to Machine Communication

Term Details

MTC Machine Type Communication

MQTT Message Queuing Telemetry Transport

PAN Personal Area Network

REST Representational State Transfer

RFD Reduced Function Device

RPL Routing Protocol for Low Power & Lossy

Networks

RTPS Real Time Publish & Subscribe

SCL Service Capability Layer

SIP Session Initiation Protocol

TSN Time Sensitive Networking

XMPP Extensible Messaging & Presence

Protocol


Complete Your Online Session Evaluation

• Give us your feedback and you could win fabulous prizes. Winners announced daily.

• Complete your session evaluation through the Cisco Live mobile app or visit one of the interactive kiosks located throughout the convention center.

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

61

https://www.ciscolive.com/online


Continue Your Education

• Demos in the Cisco Campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

62

the evolution from machine-to-machine (m2m) to the...

Documents