ARC-2017-0286 Proposed design principles for modelling services, datapoints and operations Group Name: ARC Source: Joerg Swetina, NEC (joerg.swetina@neclab.eu)

Slides:

Advertisements

Similar presentations

Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.

Advertisements

Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.

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.

REQ WG Reuse of underlying networks, 3GPP

REQ WG Reuse of underlying networks, 3GPP

On a Device Information Model for devices in oneM2M

Device Management using mgmtCmd resource

Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.

oneM2M-OIC Interworking Technical Comparison

Discussions for oneM2M Semantics Standardization Group Name: WG5 Source: InterDigital Communications Meeting Date: Agenda Item: WI-0005 ASN/MN-CSE.

3GPP Rel-13 Interworking discussions

TS0001 Identifiers way forward Group Name: WG2 Source: Elloumi, Foti, Scarrone, Lu (tbc), Jeong (tbc) Meeting Date: Agenda Item: ARC11/PRO11.

What and Why? Next steps for oneM2M Semantics Group Name: WG5 Source: Joerg Swetina, Martin Bauer (NEC) Meeting Date: Agenda Item: WI-0005 oneM2M-MAS

App-ID Discussion Group Name: ARC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 31 July 2014 Agenda Item: TBD.

Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.

Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.

Ontology Resource Discussion

3GPP Rel-13 Interworking discussions

OIC device management interworking procedure

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:

ARC R02 Modelling operations – problem statement and proposal Group Name: ARC#19.3 Source: Joerg Swetina, NEC,

Architectural Considerations for Semantic Support Group Name: WG5 Source: Martin Bauer (NEC), Joerg Swetina (NEC) Meeting Date: Agenda Item:

Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

3GPP SCEF Interworking Discussions

LWM2M Interworking Proxy Procedures ARC Considerations

Example mapping of KNX to oneM2M base Ontology

Issues of Current Access Control Rule and New Proposal Introduction Group Name: ARC 21 Source: Wei Zhou, Datang, Meeting Date:

WG1 status report to TP#20 Group Name: oneM2M TP20 Source: Joerg Swetina (NEC) Meeting Date: to Agenda Item: TP#19, Item 10.4, Reports.

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:

Subscription and Notification Issue Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: ~23 Agenda Item:

WG5 – MAS#22 Status Report Group Name: WG5 MAS (Management, Abstraction & Semantics) Source: Tim Carey(Alcatel-Lucent, WG5 Vice Chair) Meeting Date:

DM Execute Group Name: WG2/WG5 Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date: Agenda Item: TBD.

Discussion on oneM2M and OSGi Interworking Group Name: ARC Source: Jessie, Huawei, Meeting Date: Agenda Item:

TS-0004 guideline for new resource type definition Group Name: PRO WG Source: SeungMyeong JEONG, LG Electronics Meeting Date: Agenda Item: TS.

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.

3GPP Rel-13 Interworking discussions Group Name: TP #18 Source: Rejesh Bhalla, ZTE Corporation, Meeting Date: Agenda Item:

WG5 – MAS#23 Status Report Group Name: WG5 MAS (Management, Abstraction & Semantics) Source: Yongjing Zhang (Huawei, WG5 Chair) Meeting Date:

How does Generic Interworking work?

3GPP R13 Small Data Delivery

Overview of oneM2M Home Appliances Information Model

Resource subscription using DDS in oneM2M

CSE Retargeting to AE, IPE, and NoDN Hosted Resources

CSE Retargeting to AE, IPE, and NoDN Hosted Resources

Service Enabled AE (SAE)

End-to-End Security for Primitives

Group multicast fanOut Procedure

Possible options of using DDS in oneM2M

Modbus interworking Group Name: ARC

Discussion on Abstraction Application Entity

Proposed design principles for modelling interworked devices

3GPP Rel-13 Interworking discussions

OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai,

Proximal IoT Interworking solution discussion

How does Generic Interworking work? (R01 based on SAREF discussion)

3GPP Interworking Abstraction

Group multicast Group Name: ARC

Discussion on feature catalogue

LWM2M Interworking with <mgmtObj> Resources

MinitorEvent(UE_Reachability)

Discussion on XSD open issues

3GPP V2X Interworking Potential Impact

3GPP Interworking and use of <schedule> resource

Presentation transcript:

ARC-2017-0286 Proposed design principles for modelling services, datapoints and operations Group Name: ARC Source: Joerg Swetina, NEC (joerg.swetina@neclab.eu) Meeting Date: 2017-07-05 Agenda Item: TBD

Backgroud Independent of the question whether devices are native oneM2M devices or interworked devices, services, datapoints and operations are needed to communicate with the device's applications: In the case of native oneM2M devices (ASN, ADN) a communicating entity communicates with a oneM2M AE of the device In the interworked case a communicating entity communicates with the oneM2M IPE-AE that translates and proxies the communication with the AE on the device

Terminology (I) Datapoint: Operation: Stateless communication according to REST principles The AE (native AE or IPE) or the communicating entity communicates by reading from- or writing to a Datapoint Datapoints can be simple (integer, bool) or can be structured (lists, named sub-structures) Operation: Communication that requires to keep a state till the communication has ended The AE or the communicating entity sends data and expects an answer back Multiple, independent data need to be sent at the same time SDT (TS-0023) calls an Operation: Action / Event

Terminology (II) Service: Application Entity (AE): Device: Groups Datapoints and Operations that belong together Different Services can have the same Datapoints and Operations SDT calls a Service: Module or ModuleClass Application Entity (AE): Indididually addressable entity in the network that exposes Services Device: Physical thing that can communicate electronically A Device has 1..n AEs

Representation: oneM2M resources AE / device CSEBase <AE> or <flexContainer> Service Datapoint Datapoint (customAttributes) <flexCont> Datapoint Copy Operation (SDT: Action, Event) InputData <flexCont> InputData OperationResult - if operation has output (currently not in SDT) InputData InputData <flexCont> OutputData OutputData

Communication principle (I) Creation of resources Communicating entity subscribes to <AE> of AE (e.g. IPE) it wants to communicate with. AE (e.g. IPE) creates <flexContainer>s for Services and Operations and subscribes to them Communicating entity subscribes to newly created <flexContainer>s.

Communication principle (II) Sending data CE => AE using DataPoints Communicating entity UPDATEs the Service <flexContainer> with a changed Datapoint = customAttribute of Service <flexContainer>. AE (e.g. IPE) gets NOTIFYed about the changed customAttribute Sending data AE => CE using DataPoints AE UPDATEs Service <flexContainer> with a changed Datapoint = customAttribute. CE gets NOTIFYed about the changed customAttribute

Communication principle (III) Sending data CE => AE using Operations Communicating entity UPDATEs an Operation <flexContainer> with InputData (= customAttributes of Operation <flexContainer>). AE (e.g. IPE) gets NOTIFYed about the updated Operation <flexContainer> == If no OutputData are created the flow stops here == otherwise, if OutputData are created: AE computes OutputData. AE CREATEs OperationResult <flexContainer> as child of Operation <flexContainer> InputData are copied into OperationResult <flexContainer> OutputData are added as customAttributes CE gets NOTIFYed about creation of OperationResult <flexContainer> and retrieves OutputData Sending data AE => CE using Operations works analogous