Resource subscription using DDS in oneM2M

Slides:



Advertisements
Similar presentations
Microsoft ® System Center Configuration Manager 2007 R3 and Forefront ® Endpoint Protection Infrastructure Planning and Design Published: October 2008.
Advertisements

SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—1-1 Module Summary BGP has reliable transport provided by TCP, a rich set of metrics called BGP.
Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
70-290: MCSE Guide to Managing a Microsoft Windows Server 2003 Environment Chapter 1: Introduction to Windows Server 2003.
October 2003 Iosif Legrand Iosif Legrand California Institute of Technology.
RD-CSY /09 Distance Vector Routing Protocols.
On Persistent AE Identifiers Group Name: SEC#12.2 Source: Phil Hawkes, Qualcomm Inc (TIA), Francois Ennesser,
RoA and SoA Integration for Message Brokers Group Name: WG2-ARC Source: ALU Meeting Date: Agenda Item:
September, 2005What IHE Delivers 1 G. Claeys, Agfa Healthcare Audit Trail and Node Authentication.
App-ID Use Cases, Syntax and Attributes SEC App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,
oneM2M-OIC Interworking Technical Comparison
Common Service Entities
Professor OKAMURA Laboratory. Othman Othman M.M. 1.
ACAT 2003 Iosif Legrand Iosif Legrand California Institute of Technology.
(Business) Process Centric Exchanges
Authorization for IoT Group Name: oneM2M SEC WG Source: Francois Ennesser, Gemalto NV Meeting Date: Agenda Item:
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
1 University of California, Irvine Done By : Ala Khalifeh (Note : Not Presented)
Geo-distributed Messaging with RabbitMQ
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
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:
Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.
DHCP Vrushali sonar. Outline DHCP DHCPv6 Comparison Security issues Summary.
Issues of Current Access Control Rule and New Proposal Introduction Group Name: ARC 21 Source: Wei Zhou, Datang, Meeting Date:
Subscription and Notification Issue Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: ~23 Agenda Item:
Discussion on oneM2M and OSGi Interworking Group Name: ARC Source: Jessie, Huawei, Meeting Date: 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.
Background Data Transfer
Gijeong Kim ,Junho Kim ,Sungwon Lee Kyunghee University
Discussion on DDS protocol binding
3GPP MBMS protocol stack
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
Service Enabled AE (SAE)
Transport of Media Independent HO Messages over IP
Group multicast fanOut Procedure
3GPP interworking in R3 Group Name: ARC
Possible options of using DDS in oneM2M
Issues of <locationPolicy> Discussion
Discussion about Use Case and Architecture in Developer Guide
IEEE 802 OmniRAN Study Group: SDN Use Case
Modbus interworking Group Name: ARC
oneM2M Service Layer Protocol Version Handling
Proximal IoT Interworking solution discussion
What is Fibre Channel? What is Fibre Channel? Introduction
Goals of soBGP Verify the origin of advertisements
Peer-to-peer networking
LWM2M Interworking with <mgmtObj> Resources
Mobility And IP Addressing
MinitorEvent(UE_Reachability)
Client-Server Interaction
Introduction to Dynamic Routing Protocol
Chapter 3: Dynamic Routing
Tailor slide to customer industry/pain points
Choosing the Discovery Model Martin Forsberg
Introduction to Dynamic Routing Protocol
UDP based Publication Channel for Streaming Telemetry
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Securing Home IoT Environments with Attribute-Based Access Control
Summary of the MAF and MEF Interface Specification TS-0032
Data-Centric Networking
Peer-to-peer networking
Subscription to Multiple Stream Originators
Presentation transcript:

Resource subscription using DDS in oneM2M Group Name: ARC#29 Source: Sarah, Huawei, changhongna@huawei.com Echo, Huawei, echo.xubei@huawei.com Meeting Date: 2017-05-22

Summary of DDS Features The Data Distribution Service (DDS) is a middleware protocol for data-centric connectivity, providing many-to-many communication, extreme reliability, and a scalable architecture. 2

Applications DDS is used by many industries developing mission and business-critical smart applications, for example, transportation, industrial automation, military & aerospace, and so on. 3

Combined Scenario The application wants to subscribe to the temperature resource of device A and device B. Device A, device B and the application in oneM2M system support DDS protocol. Device A, device B and the application register to MN A, MN B, and MN C respectively.

Comparison of Resource Discovery and Subscription between DDS and oneM2M The process of subscription in oneM2M The process of dynamic discovery in DDS In oneM2M system, the implement of resource discovery and subscription depending on the application and the application needs to be preconfigured information about subscribed resources, which leads to inflexible network deployment. The establishment of communication entirely depends on the dynamic discovery mechanism, which leads to the unauthorized devices could access to the oneM2M network .

Overview of DDS Solution Architecture General Flow The DDS repository function can discovery the resources which can be permitted to be subscribe to for the subscriber and identify the communication list for the publishers (AEs and CSEs) according to the resource matching and other information (e.g. group information , ACP policy). DDS repository can be contained inside the MN-CSE or/and IN-CSE. The solution consists of 4 steps: registration, topic report, resource matching, resource subscription.

Solution – Topic Report Step 1: The topics defined by the DDS middleware can be considered a new resource type named <topicDirectory>. An AE/CSE can create this new resource to the remote CSE of its registrar CSE. Step 2: After creating the new resource, the registrar CSE adds its identifier to the new resource. If the registrar CSE has registered to another CSE and hasn’t the DDS Repository function, the registrar CSE shall send a CREATE request of the new resource to its Registrar CSE. Topic Report The name of the topics defined by the DDS. Represent that the topic can be published or subscribed. Represents the addresses to be used by other CSEs to connect to this CSE (e.g. IP address, Globally Unique Identifier (GUID defined by DDS). Records the IDs of the AE/CSEs which are included in topic report path Represents a list of addresses of remote CSEs/AEs which subscribe to this resource. The <topicDirectory> resource type

Solution – Resource Matching The CSE which contains the DDS repository function can match the resources received from oneM2M parties. Topic name match pubsubAttribute match Conform to configured rules(e.g.ACP) PUBLISHER SUBSCRIBER

Solution – Resource Subscription Step-1: The DDS repository creates the address list of matching parties and updates the peerList attribute of the <topicDirectory> resource. Then, DDS repository sends the UPDATE request to the resource publisher. Step-2: After receiving the UPDATE request, the MN CSE updates the peerList attribute of the <topicDirectory> resource. Then, the MN CSE sends the UPDATE request to the resource publisher. Step-3: The originator updates the peerList attribute of the <topicList> resource and configures the DDS middleware configuration according to the peerList attribute. Step-4: Then trigger the dynamic discovery procedure. Step-5: the device A sends the notification message to the APP directly.

The Advantages of Solution Dynamic discovery of resources No need to preconfigure information of peer nodes, which enables the network topology flexible and extensible. Data exchange directly Use dynamic discovery mechanism to establish pub-sub relationship to exchange data directly. The central control of resource discovery and subscription ensures the network more secure.

Thanks for your listening! Q & A