oneM2M architecture
principles and benefits
Presenter: O. Elloumi, Architecture WG Chair (Alcatel-Lucent Bell Labs)
Contributors: Jozef Blanz (Qualcomm), Yongjing Zhang (Huawei), Hogbeom Ahn (LG
Electronics), Nicolas Damour (Sierra Wireless), Rajesh Bhalla (ZTE), François Ennesser
(Gemalto)
Outline
1. Introduction to oneM2M
2. ETSI M2M vs. oneM2M
3. Why oneM2M architecture
4. Zoom on key capabilities and principles
Introduction to oneM2M
Mission
oneM2M is working to unify the Global
M2M Community, by enabling the
federation and interoperability of M2M
systems, across multiple networks and
topologies.
Global Partners
ETSI M2M vs. oneM2M
ETSI M2M vs. oneM2M
1.
2.
3.
4.
5.
6.
oneM2M architecture IS NOT an extension of ETSI M2M
Curent oneM2M architecture USE SIMILAR, to ETSI M2M, architecture style :
RESTFul, but oneM2M adopts full HATEOAS principles, no mandated
resource structure
However, other Service Oriented approches ARE NOT EXCLUDED, in
particular for componentization of the service layer.
oneM2M leverages underlying network capabilities: triggering, location,
charging. While ETSI M2M assumes an IP capable network.
Extended capability set include: delivery handling, device triggering, location,
Role based access control, M2M service subscription, etc.
Protocol binding include MQTT (in addition to HTTP and CoAP)
However an ETSI M2M platform could easily be upgraded to become oneM2M
compliant. Interworking is also possible.
Why oneM2M architecture
Why oneM2M architecture
• Combat fragmentation => Healthy eco system with economies of scale
• Standards help lowering CAPEX for M2M Services:
– Standardized protocols / APIs => simplifies application development
– Cross-vertical standards => same devices and back-ends in different industries, etc.
• Standards help lowering OPEX for M2M Services:
– Standard features to use networks more efficiently => get better tariffs
– Flexibility for verticals => utilize best transport network meeting business needs,
etc.
• Faster time to market due to reduced development/test/deployment time
• Address use cases and markets where cost was prohibitive so far
• Allow M2M users to focus on their core business and not worry about solving
M2M communication challenges on their own
Zoom on key capabilities and
principles
oneM2M simplified Architecture
M2M Applications
AE
AE
Mca
M2M Service layer
Mcn
Network Service Entity
Underlying Transport
Mca
Mcc
CSE
Mca
Mcc
CSE
Mcn
NSE
AE
CSE
Mcc’
Mcn
Mcn
NSE
11
Service components
AE
Mca
Service
Exposure
Component
CSE
Service
Component 1
Service
Component N
Msc
Network
Service
Utilization
Component
Mcn
Remote Service
Exposure
Component
Mcc’
NSE
Remote
Service
Exposure
Delivrey Handling (introduction)
Source: KPN
Delivery Handling
IN (Infrastructure)
MN (Gateway)
3G Network
ADN (Device)
Local
Connectivity
MN-CSE
IN-CSE
C
M2M customer’s
AE
ADN-AE
CMDH
New
CMDH
IN-CSE
measurement
in
(DMR)
MN-CSE
IN-CSE
notifies
unwraps
decides
#1
#2M2M
#24
taken
taken
the
toCustomer’s
forward
contained
buffered
AE
requests,
ec=3
passes
requests
Originator:
Bundles
them
aboutto
new
them
other
data
AND-AE;
in
CSFs
in
a single
C(DMR)
Receiver:
payload,
MN-CSE;
sendsTarget:
RequestIN-CSE
to IN-CSE
Update
IN-CSE
CREATEproduces
//IN/C,
ty=<delivery>,
ecall= the
3, rqet
attributes:
requested
= 4:00 event
am
UPDATES
category=3,
to C
Policies
lifespan={soonest
on MN say:ofFor
all ec=3
buffered}
=> only from 2 am to 5 am
MN-CSE
IN-CSE finds
accepts
out itand
is the
buffers
finalrequest
target in CMDH
Accepts request in IN-CSE’s CMDH
CMDH
10:05
11:55
10:00 pm
02:00
am
Container
Resource
14
Full REST with HATEOAS
•
•
•
•
Resource structure not hardcoded in the URIs
Loose coupling of resources through links
Allows extensibility in the future
One can now have:
– /cse01/app01/container02
– /container_63eb90a2
Location Capability (1/3)
• <locationPolicy> Resource Type
– Configuration information how to obtain location information of a
target M2M node
– Obtained location information is stored in a corresponding
<container> resource
<locationPolicy>
locationSource
•
Basic Information
- Source (Network/Device/Sharing)
- Period to obtain location information
•
For Network-based Location
- ID of the Target M2M Node
- ID of Location Server located in U/N
•
How to link with a <container> resource
- URI of the created <container>
- Name of the <container>
locationUpdatePeriod
locationTargetID
locationServer
locationContainerID
locationContainerName
© 2014 oneM2M Partners
<Document number>
16
Location Capability (2/3)
• 3 Ways of Obtaining Location Information
– Network-Based / Device-Based / Sharing-Based
<cont_loc_10.213.32.101
>
Content = (x,y)
AE
Create <locationPolicy>
Location
Requestor
CSE
Location Request
(OMA API for Terminal Location)
Location Response
Location
Server
IN
<locationPolicy>
locationSource = ‘Network’
locationTargetID = ’10.213.32.101’
locationServer = ‘locserver.lg.org’
AE
CSE
Target M2M Node
(10.213.32.101)
Performing Location
(e.g., Cell-ID, OTDOA)
Location Capability (3/3)
• 3 Ways of Obtaining Location Information
– Network-Based / Device-Based / Sharing-Based
AE
Create <locationPolicy>
Topology Information
AE
(Obtained though DM Technology)
<locationPolicy>
MN
CSE
Location
Requestor – ADN_0
(Location of itself)
MN
AE
ADN_1
Location = (x1,y1)
(Stored in the MN-CSE)
Location information of AND_1 shall
be stored as location information
of the requestor
AE
ADN_2
locationSource = ‘Sharing’
ADN_
1
ADN_
0
AE
ADN_3
Location = (x3,y3)
(Stored in the MN-CSE)
ADN_
2
ADN_
3
Underlying Network Services
• oneM2M architecture focuses on the “services” provided by the
Underlying (UL) Network
• NSEs represent the “services” provided to the CSEs by UL Network over
Mcn reference point
• UL Network provides data transport services between CSEs as well. Such
data transport services are not included in services over Mcn though
• Services provided by NSEs to CSEs over Mcn reference point include:
– Location Management
– Device Management
– Device Triggering
• Such services may be provided by the use of:
– Messaging Services
– Network APIs (e.g., those specified by OMA, GSMA) used by UL Network Operators for
UL Network specific services
Device Triggering
•
•
•
•
•
Communication between Nodes uses IP transport services of the UL Network
IP address for a Node in the Field Domain (e.g., ASN-CSE/MN-CSE) may become
unreachable due to factors such as device going to “sleep”, device movement, NAT
traversal in the UL Network etc.
A Node in the Infrastructure Domain (e.g., IN-CSE) can use Device Triggering
service to “wake up” the Node in the Field Domain, and cause it to establish
communication towards the Node in Infrastructure Domain, if required, thereby
establishing IP connectivity.
Device Triggering may use alternate means of communication over the UL Network
(other than IP connectivity) to “wake up” the Node in the Field Domain (e.g., SMS).
Each UL Network type may provide different means for performing Device
Triggering:
–
–
3GPP/3GPP2 have specified a dedicated interface (Tsp) for device triggering.
Network APIs are other examples for performing Device Triggering.
Device Triggering Illustration
•
•
•
•
IN-AE needs to perform a CRUD operation on
a resource in ASN/MN-CSE. IP address of
target CSE is not known or not reachable
IN-CSE selects the UL Network for reaching
the ASN/MN-CSE and delivers Device Trigger
Request to associated NSE
UL Network specific Device Triggering
procedure is performed between the UL
Network and the target Node that hosts the
ASN/MN-CSE
Device Trigger Request is delivered to the
target Node
–
•
Device Triggering Handler function in target Node is
UL Network Specific
If required, connectivity is established
between the ASN/MN-CSE and the IN-CSE,
thereby renewing the ASN/MN-CSE IP
address as well
Field Domain
Infrastructure Domain
Mcc
ASN/MN
-CSE
Device
Triggering
Handler
NSE
Mcn
IN-CSE
Mca
1. Request to
targeted ASN/
MN-CSE
2. Underlying Network
selection
.
3. Device
Triggering
request
4. Underlying Network
Specific Device
Triggering Procedure
6. ASN/MN-CSE
receives trigger
5. Device Triggering
response
7. Connection establishment
IN-AE
Device Triggering and Reference Point Mapping
•
•
•
UL Network specific NSE receives Device Trigger Request over Mcn
UL Network specific procedures are performed to "wake up" the target Node. If
required, IP connectivity established between target CSE and IN-CSE.
Mcc communication over IP transport provided by the UL Network.
Device Management
•
TR0006-Study of the management
capability APPROVED
•
•
•
•
Introduction and gap analysis
6 Potential Deployment Scenarios
Generalized Management
Architecture specified in ARC TS
Management Resources Template
and procedures
•
•
CSE
DMG
Out-of-scope
CSE
DMG
Management
Adapter
Device in M2M Area
Network
Proxy
Management
Client
Mcc
ms
la
mp
Management
Proxy
Management
Client
Management
Adapter
mc
Management
Server
Generalized Management Architecture
<mgmtObj>
•
•
IN
MN/ASN
12 oneM2M specific mgmt resources
derived
<mgmtCmd>
Stage 3 work for technology-specific
mapping started:
•
TS-0005 (OMA)
•
•
TS-0006 (BBF)
•
–
DM 1.X, DM 2.0, LWM2M
BBF TR069
Stage 3 common primitives will be specified in
TS0004 (core protocol)
© 2013 oneM2M Partners
Management Resources and the Work Split
<Document number>
23
Security
• ETSI TC M2M only addressed the security needs of M2M Service
Providers: Protection of the M2M service infrastructure only
• Yet the purpose of an M2M Service Platform is to provide services
to M2M Applications: Why not “Security as a Service”?
– The goal in oneM2M is to leverage on security capabilities present in the
M2M infrastructure (Service Layer or Underlying Network) to provide
Security Services for M2M applications
• Some oneM2M Security Services:
– Credentials deployments and management
– Secure connection establishment and management
– Authorization and Access Control, supporting roles and context attributes
• oneM2M Security Solutions:
– Support of Symmetric (Pre-Shared Keys) and Asymmetric (PKI) credentials
– Support of static trust scenarios, based on pre-provisioned credentials
– Support of dynamic configurations, involving a Centralized Key Distribution
© Copyright 2024 ExpyDoc
