Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park

Slides:



Advertisements
Similar presentations
Access Control Mechanism Discussion
Advertisements

CMDH Refinement Contribution: oneM2M-ARC-0397
Summary on the M2M CMDH Policies Management Object (MCMDHMO)
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
COEN 445 Communication Networks and Protocols Lab 4
1 Fall 2005 Internetworking: Concepts, Architecture and TCP/IP Layering Qutaibah Malluhi CSE Department Qatar University.
The OSI Model and the TCP/IP Protocol Suite
Gursharan Singh Tatla Transport Layer 16-May
The OSI Model and the TCP/IP Protocol Suite
CECS 5460 – Assignment 3 Stacey VanderHeiden Güney.
Proposal for App Id and Service Provider Id registration Group Name: Shelby Kiewel Source: Shelby Kiewel, iconectiv / Ericsson,
Resource Announcement Procedures Group Name: WG2 Source: Rajesh Bhalla, Hao Wu - ZTE Meeting Date: Agenda Item: TBD.
Common Devices Used In Computer Networks
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
oneM2M-OIC Interworking Technical Comparison
Jozef Goetz, Application Layer PART VI Jozef Goetz, Position of application layer The application layer enables the user, whether human.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Mobile Communication The SMS implies of several additional elements in the network architecture There is also another Element called.
End-to-End security definition Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:
Review of the literature : DMND:Collecting Data from Mobiles Using Named Data Takashima Daiki Park Lab, Waseda University, Japan 1/15.
3GPP Rel-13 Interworking discussions
Home Media Centre Smart Interface Demonstration School of Information Technologies University of Sydney.
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.
Considerations on M2M URIs Group Name: WG2(ARC) Source: Yong-Suk Park, Sung-Chan Choi, Jaeho Kim, KETI, Meeting Date:
Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.
Experience and Discussion on Interworking Proxy Implementation Group Name: WG2 Source: Korea Electronics Technology Institute (KETI) Meeting Date: ~24.
Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.
Proposal for App Id and Service Provider Id registration Group Name: Shelby Source: Shelby, iconectiv / Ericsson,
Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.
Work for the next release Group Name: TP Source: JaeSeung Song, KETI, Jaeho Kim, KETI,
The Client-Server Model And the Socket API. Client-Server (1) The datagram service does not require cooperation between the peer applications but such.
FCM Workflow using GCM.
CSCD 218 : DATA COMMUNICATIONS AND NETWORKING 1
OIC device management interworking procedure
M2M Study Item 3GPP2 Orlett W. Pearson May | 3GPP2 M2M Study Item | May GPP2 M2M This study will include the following study targets: 
M2M Service Session Management (SSM) CSF
E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.
Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.
ARC R02 Modelling operations – problem statement and proposal Group Name: ARC#19.3 Source: Joerg Swetina, NEC,
OIC INTERWORKING Resource mapping
App End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:
Streaming Session Support in oneM2M Framework Group Name: WG2 Source: George Foti, Ericsson Meeting Date: Work Item :WI GPP_Rel13_IWK.
3GPP SCEF Interworking Discussions
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
© 2002, Cisco Systems, Inc. All rights reserved..
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.
Issues about management Group Name: MAS9.2 Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date: Agenda Item:
Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:
DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date:
Ch 3. Transport Layer Myungchul Kim
Antony Edwin Keane Inc Ltd
TS-0004 guideline for new resource type definition Group Name: PRO WG Source: SeungMyeong JEONG, LG Electronics Meeting Date: Agenda Item: TS.
Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
Resource subscription using DDS in oneM2M
Provisional Architecture for oneM2M
Bluetooth connection & GAIA protocol
Service Framework Proposal
Service Enabled AE (SAE)
End-to-End Security for Primitives
Group multicast fanOut Procedure
Proposed design principles for modelling interworked devices
3GPP Interworking Abstraction
Considering issues regarding handling token
CMDH Refinement Contribution: oneM2M-ARC-0397R01
HOW PROTOCOL GATEWAYS GET CONFIGURED
Notification Target Discussion
3GPP Interworking and Multicast retransmission
Presentation transcript:

Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park Meeting Date: Agenda Item: Discussion REQ R01-Usecase_for_multi-link_device

Motivation and Background One of the most widely used IoT/M2M applications is measuring energy consumption of a device (such as TV, fan, refrigerator, etc.) Because most of these devices do not have the capability to measure their own energy usage, a separate device is used to measure the energy usage Also, there are some devices that contain multiple small devices (sub-devices), but they register as a single device to the server (e.g. smart multi-tab serving multiple electric devices and measuring energy usage) Since a smart multi-tab is a single device and has a network connection to the server, the smart multi-tab can be registered as a node to the server. However, since the smart multi-tab sends packets containing energy usages of its connected devices, the measured values should be assigned to appropriate applications However, the current oneM2M architecture does not provide this kind of device and message handling The oneM2M specification standardizes a link between resources, but the link in the specification is only for simple child and parent relationship

IoT/M2M system CSE-Base CSEs CSE.1 applications GA.1 attributes applications GA.1 attributes applications GA.1 attributes applications GA.1 attributes for fan for toaster for refrigerator for smart multi-plug All measured data are stored under smart multi-plug resource although the values are for other devices Background and Motivation

Delivery of measured data If a smart multi-plug sends a packet, the packet contains measured data of the devices plugged-in There should be a mechanism to deliver measured values to the corresponding connected device For example, let’s assume that there are three devices (A: refrigerator, B: toaster and C: fan) plugged in sockets 1, 2 and 3 of a smart multi-plug, respectively, and that the smart multi-plug can send measured data regularly to the server The packet created by the smart multi-plug has to contain –all measured values from connected devices –an indication that this packet is coming from a device serving multiple devices –pair of values distinguishing devices and their measured values, for example, A:30.B:20.C:40 or A.B.C= This indicates that devices A, B and C consume 30, 20 and 40 watts, respectively If there is no indication in the packet, the server has to know about the type of devices when the device is registered. Therefore, if the value is delivered to the resource of such muti-homed devices, the server has to perform some actions, such as parsing and distributing values to the proper corresponding resources

Delivery of measured data For this purpose, CMDH (Communication Management and Delivery Handling) requires to perform additional functions as follows: –Option 1: Detect a message from MLD (Multi-Linked Device) If the message is coming from MLD, perform parsing based on the packet rules (such as msg type + device id + value + device id + value, etc.) After the parsing, CMDH stores the values to the appropriate resources –Option 2: Store the given value from a message from MLD to MLD’s resource In this case, we require an additional resource type called MLD resource Once a value is stored into the MLD resource, the IN-CSE parses the stored value and distributes the parsed values into the proper resources. The issue here is whether to perform parsing and distributing the values based on message type or resource type

Delivery of measured data - an indication that this packet is coming from a device serving multiple devices - pair of values to distinguish devices 1.A.30. indication delimiter Device id delimiter value IN-CSE CMDH -Parsing -Distributing