Proposed design principles for modelling interworked devices

Slides:



Advertisements
Similar presentations
Access Control Mechanism Discussion
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.
Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
Discussion on oneM2M HTTP Binding Interoperability Test Spec.
App-ID Ad-Hoc Technical Issues TP AppID R02 Group Name: App-ID Ad-Hoc Group Source: Darold Hemphill, iconectiv,
On a Device Information Model for devices in oneM2M
Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.
Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:
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
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
PRO R01-URI_mapping_discussion Discussion on URI mapping in protocol context Group Name: PRO and ARC Source: Shingo Fujimoto, FUJITSU,
3GPP Rel-13 Interworking discussions
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
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.
Customized Resource Types MAS Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date:
Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
Ontology Resource Discussion
App-ID Use Cases, Syntax and Attributes ARC R01-App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,
Discussion on XSD implementation conventions (document number PRO R01) Group Name: PRO Source: Wolfgang Granzow, Meeting.
Credential Identifiers Group Name: SEC#14.2 Source: Phil Hawkes, Qualcomm Inc, Meeting Date:
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,
Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.
3GPP SCEF Interworking Discussions
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:
Issues about management Group Name: MAS9.2 Source: Jiaxin Yin, Huawei Technologies Co., Ltd., 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.
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
App-ID Ad-Hoc Technical Issues TP AppID R02
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
Proximal IoT Interworking discussion
Group multicast fanOut Procedure
2nd Interoperability testing issues
Possible options of using DDS in oneM2M
Issues of <locationPolicy> Discussion
Modbus interworking Group Name: ARC
NIDD Discussion Points
Discussions on Heterogeneous Identification Service
oneM2M Service Layer Protocol Version Handling
MAF&MEF Interface Specification discussion of the next steps
OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai,
Proximal IoT Interworking solution discussion
TS-0004 Data Representation Proposal Discussion
3GPP Interworking Abstraction
oneM2M Versioning Next Steps
ARC Proposed design principles for modelling services, datapoints and operations Group Name: ARC Source: Joerg Swetina, NEC
LWM2M Interworking with <mgmtObj> Resources
MinitorEvent(UE_Reachability)
Discussion on XSD open issues
Service Layer Dynamic Authorization [SLDA]
On Management, Abstraction & Semantics
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Summary of the MAF and MEF Interface Specification TS-0032
Presentation transcript:

Proposed design principles for modelling interworked devices ARC-2017-0285 Proposed design principles for modelling interworked devices Group Name: ARC Source: Joerg Swetina, NEC (joerg.swetina@neclab.eu) Meeting Date: 2017-07-05 Agenda Item: TBD

Backgroud It’s agreed in TP29 Devices should be represented in oneM2M uniformly for both oneM2M native device (ADN\ASN\MN) and oneM2M legacy device(NoDN) Is it possible to stick to this agreement? This contribution looks at some pros and cons and lists some open questions It proposes to use both, <AE>s and specialized <flexContainer>s to represent AEs

Data provided via the IPE An IPE is responsible for (the oneM2M view of) a complete area network, including NoDN devices. Not specific to an individual device are: Management information of the area network - if the area network is managed through the IPE and not through an external entity! Network services (broadcast-like, telegrams to all..) if they exist Specific to each individual device: Management information of the NoDN devices One or more Application Entities (i.e. service logic that is individually addressable) on the device.

Current state of the art (I) Application Entity: represents an instantiation of Application logic for end-to-end M2M solutions Node: logical entity that is identifiable in the oneM2M System <node> resources are always child-resources of some CSEBase <node> resources contain management information as child-resources (specializations of <mgmtObj>). E.g.: [areaNwkInfo] (describes the list of Nodes attached to the area NW) [areaNwkDeviceInfo], [deviceInfo], [firmware] … for individual devices where the managed entity is an NoDN, the managed entities' <mgmObj> resources are hosted by the CSE of the node to which the managed entity is attached ??? An optional nodelink may exist from the <AE> to the <node> resource of the node on which the AE resides. Note: In TS-0023 also mgmtLink exists from the <flexContainer> of a Device model to a [deviceInfo] resource that is a child of a <node> resource which one ?? hosted on the same hosting CSE of the <flexContainer>

Current state of the art (II) An <AE> resource – of some AE on a ASN, ADN and NoDN – contains service related data as child-resources: as (hierarchy of) <container>s and/or specializations of <flexContainer>s. Note that a ASN, ADN NoDN may contain multiple AEs on the same node! <AE> representation of AE requires certain mandatory attributes: Application Entity Identifier (AE-ID) uniquely identifies an AE within the M2M System. AE-ID is unique within that M2M Service Provider domain. AE-ID-Stem is assigned by the Registrar CSE of the AE or AE-ID-Stem is assigned by the M2M-SP. (unique within the M2M-SP Domain) Application Identifier (App-ID) uniquely identifies an M2M Application There are two types of App-ID: registration authority defined App-ID (registered App-ID) – which is globally unique Format: R{authority ID}.{reverseDNS}.{applicationName} non-registered App-ID. Format: N{non-registered-App-ID}

Service subscription - is it an issue? If AEs on a NoDN are represented by <AE>s can the IPE use its own <m2mServiceSubscriptionProfile> for registering allowed AEs ? <m2mServiceSubscriptionProfile> resource on CSEBase contains child-resources: <serviceSubscribedNode> <serviceSubscribedNode> contains a list of deviceIdentifiers that uniquely identify the device A list of ruleLinks to <serviceSubscribedAppRule>s <serviceSubscribedAppRule> resource on CSEBase represents a rule that defines allowed App-ID and AE-ID combinations that are acceptable for registering an AE on a Registrar CSE

How do we represent a oneM2M native device? Application Entity (AE) is the entity that executes all user defined logics Multiple AEs can exist per device Application is responsible for exposing the services and functions of a device Application is linked to <node> resource to indicate the execution environment that application is running on. Sub-Devices not forseen CSEBase AccessControlPolicy Services provided by the application Application Entity AE [flex] Container AE subscription AE Common Service [flex] container remoteCSE container Services provided by the common service entity contentInstance subscription flexContainer node device mgmtObj

How can we represent an interworked device using <AE>s ? IPE-<AE> has child resources for Network services Has nodeink to the IPE-<node> resource representing the area network <node> of IPE Links via areaNwInfo.listOfDevices and areaNwkDeviceInfo.devId to the <node>s of interworked devices <AE>s of interworked devices Have nodelink to their respective <node> MISSING: Links from the IPE-<AE> to its interworked <AE>s CSEBase AccessControlPolicy Network Services provided by the IPE IPE IPE-AE [flex] Container IPE-node subscription [flex] container AE node AE AE node

How can we represent an interworked device using <flexContainer>s ? AEs of NoDN devices are mapped by IPE into customized child-resource <flexContainers> of the IPE-<AE> The <flexContainer>s are linked to <mgmtObj> resources that are child-resources under the IPE-<node> ? or The IPE creates <node> resources not linked to any <AE> ? or <flexContainer>s link to <node>s ? CSEBase AccessControlPolicy AEs of devices IPE-AE moduleClasses Sub-devices flexContainer flexContainer flexContainer flexContainer flexContainer flexContainer flexContainer IPE-node device mgmtObj mgmtObj mgmtObj

Questions Assuming that interworked AEs can be represented both as <AE>s and customized <flexContainers>: If AEs on a NoDN are represented by <AE>s can the IPE use its own <m2mServiceSubscriptionProfile> for registering <AE>s ? How can we link the <AE>s to the IPE-<AE> ? if no AE of a NoDN is represented by an <AE> resource can the IPE create a <node> resource for that device? can that <node> be referenced by a <flexContainer> that represents the AE ? How can <flexContainer>s that represent AEs be differentiated from <flexContainer>s that represent network services Where are XSDs stored?