oneM2M-OIC Interworking Technical Comparison

Slides:



Advertisements
Similar presentations
oneM2M and AllJoyn Interworking
Advertisements

SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.
OneM2M-ARC Service_examples_and_evolution Service examples and evolution Group Name: WG2 Source: Philip Jacobs, Cisco Systems,
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
Common Service Entities
Step by step approach Group Name: WG2
Certificate Enrolment STEs Group Name: SEC#17.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
End-to-End security definition Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:
3GPP Rel-13 Interworking discussions
Answer the Questions Regarding Pending Issues on Access Control Group Name: WG4 SEC Source: LG Electronics Meeting Date: Agenda Item: SEC#11.4.
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: Agenda Item: Message.
Fuctional Procedure for oiC interworking
Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.
Proposal for WG3 & WG5 work area split
AllJoyn-Interworking Discussion Group Name: TP WG2 ARC Source: Josef Blanz, Phil Hawkes, Qualcomm Inc., Meeting Date:
1 ECE453 - Introduction to Computer Networks Lecture 1: Introduction.
Step by step approach Group Name: WG2 Source: Michael hs. Yang, LG uplus, Jaeseung Song, NEC Europe, Meeting.
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
MQTT Compliance Test Necessary Items TST (WG6) Source: Seon, Dt&C (TTA), Meeting Date: TST MQTT_Compliance_Test_Features_Skeleton.
Primitive End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting.
Matching Resources with CSFs Group Name: WG2 (ARC) Source: Hongbeom Ahn, LG Electronics, Meeting Date:
Scenarios for oneM2M and OIC Interworking
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
Management of Semantic Instances in resources using SPARQL update operation with HTTP verbs Group Name: MAS 19 Source: Minwoo Ryu, jaeho Kim, Sungchan.
OIC device management interworking procedure
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
M2M Service Session Management (SSM) CSF
Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.
M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:
OIC INTERWORKING Resource mapping
Status of Active Work Items Level of Completeness Group Name: WPM Source: Roland Hechwartner, WPM Convenor Updated:
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Introduction to oneM2M OMA - oneM2M Meeting, San Diego, Jan. 19th 2016
Introduction to IETF CoRE Link Format Soumya Kanti Datta Mobile Communications Department
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
Authorization Architecture Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 28 MAY, 2014 Agenda.
FUCTIONAL ARCHITECTURE FOR OIC INTERWORKING Group Name: Architecture WG Source: Jieun Keum, Samsung Electronics,
Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:
Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:
DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date:
Discussion on oneM2M and OSGi Interworking Group Name: ARC Source: Jessie, Huawei, Meeting Date: Agenda Item:
Possible Solution of Interworking between oneM2M and OSGi
Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
FUCTIONAL ARCHITECTURE FOR OIC INTERWORKING Group Name: Architecture WG Source: Jinhyeock Choi, Samsung Electronics,
OCF Data Model Michael J Koster.
Resource subscription using DDS in oneM2M
Discussion on DDS protocol binding
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
Service Enabled AE (SAE)
2nd Interoperability testing issues
Possible options of using DDS in oneM2M
Discussion about Use Case and Architecture in Developer Guide
NIDD Discussion Points
Proposed design principles for modelling interworked devices
MAF&MEF Interface Specification discussion of the next steps
Proximal IoT Interworking solution discussion
3GPP Interworking Abstraction
Considering issues regarding handling token
CMDH Refinement Contribution: oneM2M-ARC-0397R01
An introduction to oneM2M
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Presentation transcript:

oneM2M-OIC Interworking Technical Comparison ARC-2015-2138-oneM2M-OIC_Interworking_Technical_Comparison oneM2M-OIC Interworking Technical Comparison Group Name: WG2 ARC #19 Source: Sung-Chan Choi, Jaeho Kim, Minu Ryu KETI, csc@keti.re.kr Jieun Keum, Samsung Electronics, je.keum@samsung.com Seonhyang Kim, DT&C, shkim@dtnc.net Bahareh Sadeghi, Intel, bahareh.sadeghi@intel.com Lionel Florit, Cisco, lflorit@cisco.com Meeting Date: <2015-09-07> Agenda Item: oneM2M & OIC Interworking (WI-0044)

Overview Overview of oneM2M vs. OIC Framework RESTful Architecture oneM2M-OIC Technical Comparison New proposed text in TR-0023 Technical Comparison Resource Representation Communication Model

Connectivity & messaging oneM2M vs. OIC Framework Network Common Service Entity Smart Home Industry … Identification Discovery Device Management Messaging Group CRUDN Security Location Connectivity CoAP HTTP MQTT Registration Network Exposure Resource Model Application profile Smart Home Industry … … OIC Core Framework Identification CRUDN Security Resource Model Core Framework Discovery Messaging Streaming Device Management Group Management Protocol Bridge CoAP HTTP Network Connectivity & messaging Connectivity

Resource-oriented Architecture Entity handler Client Server Entity Request { "n": “MyRoomTemperature", "rt": "oic.r.temperature", "if": "oic.if.a", "id": "temp_TF38_3", "unit": “Celcius", “Current_value": 18, “Set_value": 25 } Response CRUD & N operation Resource (representation) OIC Architecture is based on Resource-oriented Architecture Resources are addressable and Services are exposed using CRUD&N operations

oneM2M vs. OIC Resources Both oneM2M and OIC adopt ROA (resource-oriented architecture) model where services are exposed through resource representation oneM2M exposes M2M Common Service functionalities through various resources, e.g., AE, remoteCSE, container, group, node, delivery, etc. OIC’s resources are mainly related with device representation and its status/control information Including device type property (mandatory) which describes OIC device type (e.g., fan, light, thermostat, air conditioner, etc.) as well as device specific application data Comparing with OIC, oneM2M uses <container>, <contentInstance> resources for the device specific application data Each OIC device usually keeps only its own application data

Common Service Functions oneM2M Resource Model Common Service Functions CSF oneM2M Resource Type REG <CSEBase>, <remoteCSE>, <AE> DMR <container>, <contentInstance> SUB <subscription> GMG <group>, <fanOutPoint> LOC <locationPolicy> SEC <accessControlPolicy> DIS <Annc> DMG <mgmtObj>,<mgmtCmd>, <execInstances>, <execInstance>, <parameters>, <node> CMDH <delivery>, <request> NSSE <schedule>, <cmdhNwAccessRule> SCA <statsConfig>, <statsCollect> Registration Discovery Security Group Management Data Mgmt. & Repository Subscription & Notification Device Management Application & Service Mgmt. Communication Management Network Service Exposure Location Service Charging & Accounting

OIC Resource Model OIC Device Core resources + Device specific resources Core resources (with fixed URI) oic/res: core resource with device type oic/d: core resource for device discovery Device specific resources (with free URI) For example, light device shall have “binary switch” Device specific resource /oic/res /oic/d /resource1URI /resource2URI oic/d (with “rt”=“oic.d.<device type>” * oic core resource with fixed URI Resource2 * Device specific resource with free URI oic/res Resource1 Link relationship

Light Bulb Resource Example Example overview Smart light device with i) binary switch & ii) brightness resource Device type: Light device (oic.d.light) Associated resources Core resources ① oic/res, ② oic/d Device specific resources ③ Binary switch (oic.r.switch.binary), ④ Brightness resource (oic.r.light.brightness) Example: Smart light device with 4 resources oic/res Device Title Device Type Associated Resource Type M/O Light oic.d.light oic/res (oic.wk.core) M oic/d (oic.d.light) Binary switch (oic.r.swtich.binary) Brightness (oic.r.light.brightness) O oic/d Binary switch Brightness

Light Bulb Resource Example Set of links in oic/res resource /oic/res [{ "di": "example_device_id", "links": [ { "href": "/oic/d", "rt": "oic.d.light", "if": "oic.if.r", "rel": "hosts"}, { "href": "/myLightSwitch", "rt": "oic.r.switch.binary", "if": "oic.if.a", { "href": "/myLightBrigtness", "rt": "oic.r.light.brightness", "rel": "hosts"} ] }] /oic/d { "n": "myRoomLightDevice", "rt": “oic.d.light", “di": "example_device_id“, "icv": "oic.1.5" } /myLightBrightness "n": MyRoomLightBrightness", "id": “light_brightenss_TF38_3", "value": 30 /myLightSwitch "n": MyRoomLightSwitch", "id": "b.switch_TF38_3", "value": "true"

oneM2M vs. OIC Communication oneM2M CSE/AE shall perform registration with another CSE to be able to use M2M Services offered by the CSE Registration establishes a relationship between CSEs/AE allowing them to exchange information. Therefore, data delivery path mainly occurred along with the registration-based relationship configuration OIC devices mainly support peer-to-peer communication in local area network (home, industry) OIC supports remote access using a connection broker server OIC does not have a concept of data collection yet as in oneM2M <container> which could be related with its registered devices’ application data

oneM2M Registration IN AE CSE IN-AE MN AE CSE AE AE AE AE ADN CSE ADN ASN ASN

oneM2M Communication AE1 CSE1 CSE2 CSE3 Originator Registrar CSE = Transit CSE Transit CSE Hosting CSE Registration Registration Registration AE1 CSE1 CSE2 CSE3 Request(op=UPDATE, to=/{CSE3}/c01, fr=AE1, ri=01, cn, rt=blockingRequest) Internal processing (forwarding to CSE2) Request(op=UPDATE, to=/{CSE3}/c01, fr=AE1, ri=01, cn, rt=blockingRequest) Internal processing (forwarding to CSE3) Request(op=UPDATE, to=/{CSE3}/c01, fr=AE1, ri=01, cn, rt=blockingRequest) Internal processing (hosting CSE) Response(“successfully updated”) Response(“successfully updated”) Response(“successfully updated”)

Remote Access Connection OIC Communication OIC Device OIC Device OIC Connection Broker OIC Server/Client OIC Server/Client Remote Access Connection Peer-to-peer OIC Server/Client OIC Server/Client OIC Device Local (LAN) OIC Device Remote (WAN)

OIC Communication Client Server (OIC Smartphone) (OIC Light Bulb) n=bedlight of=false Client (OIC Smartphone) Server (OIC Light Bulb) GET(oic/res) Response (list{res uri, rt, if}) GET(/light) Response (content) of=true POST(/light, {of=true}) Response (Success/ Failure)

Conclusion Both oneM2M and OIC architecture are based on ROA (resource-oriented architecture) model OIC resources represent Device Specific Characteristics But, oneM2M focuses on Common Service Functionalities oneM2M and OIC communication models are different Peer-to-Peer (plus remote access feature) vs. Registration-oriented data delivery (hop by hop) TR-0023 Proposed text oneM2M-OIC technical comparison