iot seminar (jan. 2016) - (1) dr omar elloumi - onem2m interworking and semanitcs framework
TRANSCRIPT
© 2015 oneM2M
Presenter: Omar Elloumi, oneM2M TP Chair, Alcatel-Lucent (acknowledgment: the author thanks oneM2M members who provided input to this presentation)
oneM2M www.oneM2M.org
ONEM2M INTERWORKING AND SEMANTICS FRAMEWORK
© 2015 oneM2M 4
M2M Common Service Layer in a nutshell
• It is a software layer • It sits between M2M applications and
communication HW/SW that provides data transport
• It normally rides on top of IP • It provides functions that M2M applications
across different industry segments commonly need. Those functions are exposed to Applications via developer friendly APIs.
• It allows for distributed intelligence (device, gateway, cloud apps)
© 2015 oneM2M 5
oneM2M Architecture approach
Pipe (vertical): 1 Application, 1 NW,
1 (or few) type of Device
Point to point communications
Horizontal (based on common Layer) Applications share common service and network infrastructure
Multipoint communications
Local NW
Business Application
Device
Communication Network (wireline, wireless,
Powerline ..)
Gateway
Communication Network 1
Communication Network 2
Local NW
Gateway IP
Application
A
Application Application Application
Common Service Layer
Device
Device
Device
A S
A A
Device
A S
S Common Service Layer
S
A
Common Service Layer
A Application
Things
Things representations (including semantics)
© 2015 oneM2M 6
Underlying Network
Underlying Network
AE
NSE
AE
NSE NSE NSE
Application Service Node Middle Node Infrastructure Node
Application Layer
Network Layer
Architecture
AE
Application Entity Provides application logic for the end-to-end M2M solutions
Network Services Entity Provides services to the CSEs besides the pure data transport
Node Logical equivalent of a physical (or possibly virtualized, especially on the server side) device
© 2015 oneM2M 7
Underlying Network
Underlying Network
CSE
AE
NSE
CSE
AE
NSE
CSE
AE
NSE NSE
Application Service Node Middle Node Infrastructure Node
Application Layer
Service Layer
Network Layer
Mca
Mcn
Mca Mca
Mcn Mcn Mcn Mcc Mcc
Reference Point One or more interfaces - Mca, Mcn, Mcc and Mcc’ (between 2 service providers)
Common Services Entity Provides the set of "service functions" that are common to the M2M environments
Application Entity Provides application logic for the end-to-end M2M solutions
Network Services Entity Provides services to the CSEs besides the pure data transport
Node Logical equivalent of a physical (or possibly virtualized, especially on the server side) device
Architecture
CSE
Mcc’
Inf. Node
© 2015 oneM2M 8
Ongoing collaborations
Guidelines & Ref. Arch.
Protocols Platforms
MQTT
OMADM LWM2M
HTTP CoAP TLS DTLS
Uses/interworks
uses
uses
interworks with
collaborations
Source: N Damour, Sierra Wireless
© 2015 oneM2M 10
Vision for building smart cities
2. Digitalize and «sensorise»
4. Expand the vision, Integrate
and Innovate
3. Build Dashboards
1. Build a
vision
Source: Based on discussions with Dr. Martin Serrano, Insight centre
© 2015 oneM2M 11
Smart cities: Challenge 1: integrate – role of open platforms
Source: CRYSTAL project/Philips
Platform based integration
Based on open standards
Provide interworking with underlying networks
Provide interworking with device technology
Home
Energy
Health
Automotive
Communication Devices & Hardware
Communication Technologies & Protocols
Common Service Layer
Communication Networks
Automotive Applications
Home Applications
Energy Applications
e-Health Applications
© 2015 oneM2M 12
Smart cities: Challenge 1: integrate – role of semantic interop
Common Service layer
things Things representation
Data (e.g. temperature)
Metadata
Semantic description
Other metada (e.g. digital right
management and privacy related)
instantiates
ontology
represents
Discovery – Consistency – Scalability - Efficiency
Source: AIOTI
© 2015 oneM2M 13
Smart cities: Challenge 2: innovate
How do I address the needs of app developers
• App developer focus on app logic: use of Restful APIs
• Hide WAN and Area Network technologies specificities (interworking exposed as a service by the platform)
• Hide device technology protocols (interworking exposed as a service by the platform)
• Free access to city open data – Controlled access to other data
© 2015 oneM2M 14
oneM2M Interworking example – home automation
Interworking Proxy Entity
AE AE
CSE CSE
Mca Mca
Mcc
IPE
Mca
OMA LWM2M
Source: Sierra Wireless
© 2015 oneM2M 15
Underlying network interworking example – 3GPP
Application Entity
oneM2M IN-CSE
Mca
Mcn(3GPP exposed
Interfaces)
Mcc NSSE
APIs APIs
OMA
SCEF
3GPP Network
Mcn (OMA APIs)
3GPP exposed
Interfaces
Trust
Domain
Other Underlying Network
TBD
Mcn (Other APIs)
APIs APIs
Other exposure
functionTrust Domain
(Mcn)
© 2015 oneM2M
LWM2M Interworking Reference Model
LWM2M Applications communicate with oneM2M Applications across
the Mca reference point.
LWM2M Application
CSE
LWM2M Protocol
LWM2M IPE
Mca
AE
Mca
ASN/MN/IN
CSE Mcc/Mcc’
MN/IN
2
• LWM2M Interworking aims at considering the association of a LWM2M Client and an Interworking Proxy Entity (IPE) as a oneM2M Application Entity (AE).
• oneM2M AEs discover LWM2M Objects and Object Instances as <container> or <flexContainer> resources using the labels associated with the resources.
© 2015 oneM2M 17
Take-away
• oneM2M progressed two aspects of interworking – Underlying network interworking – Device/technology interworking (via IPE)
• oneM2M interworking framework either relies (APIs) or considers OMA work (LWM2M)
• oneM2M has an objective to reuse and collaborate, we will continue to leverage existing technology
• OMA is a key player – provides thought leadership that is key to oneM2M – Device management – Network APIs
• We are already fully engaged together, let’s continue with the same spirit of collaboration