Customized Resource Types MAS-2015-0626 Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow,...

Customized Resource TypesMAS-2015-0626

Group Name: MAS + ARC + PRO WGsSource: Wolfgang Granzow, Qualcomm Inc., [email protected] Date: 2015-09-07Agenda Item: MAS Home Domain Enablement & Joint session MAS/ARC/PRO/(SEC)

Background on this contribution

• This contribution is related to the work in MAS WG on Home Domain Abstract Information Models (TR-0017) and mapping these onto oneM2M resource representations

• However, the approach proposed in this contribution is independent of a particular application domain– It applies equally to use cases in any other domains, e.g.

industrial, automotive, eHealth, smartCity, smartGrid– It also enables efficient interworking with other M2M

systems such as AllJoyn, OIC, LWM2M etc.

© 2014 oneM2M PartnersMAS-2015-0626

2

Problem addressed• Designing M2M applications for oneM2M systems or

designing interworking with applications developed for another technology, essentially need to answer the question: how to map an application or device model onto the resources standardized by oneM2M– Can this be accomplished efficiently using <container> and

<contentInstance> resources?– Should we introduce new resource types?


3

Proposed Solution • If oneM2M systems become widely accepted and deployed, it

is predictable that there will be strong demand by application developers for new application-specific resource types to be able to implement new applications efficiently

• Rather than trying to fulfill this demand by standardizing an ever-growing number of new resource types, it is proposed here to standardize a procedure which enables application developers to design and deploy their own customized resource types


4

Concept of resource type specialization • The concept of “specialization” applied to <mgmtObj>

resource type can be regarded as a first step towards “customized” resource types


5

Example of “standardized” <mgmtObj> specialization:

<mgmtObj> resource type definitionrepresenting a “template” for its specializations

<mgmtObj> specific attributes

<mgmtObj>

1mgmtDefinition

0..1 (L)mgmtLink

0..n[objectAttribute]

0..1description

<subscription>0..n

0..1 (L)objectIDs

0..1 (L)objectPaths

common attributes

[cmdhNwAccessRule]

1mgmtDefinition

objectPaths

0..1description

1targetNetwork

1minReqVolume

1backOffParameters

0..1 (L)otherConditions

1mgmtLink

0..1 (L)objectIDs

0..1 (L)

common attributescommon/universal attributes

specific attributes

child resource(s) by referencesubscription child resource(s)

Issues with resource type specializations

• <mgmtObj> specializations may be regarded as a sort of customized resource types defined to meet the objective of enabling efficient interworking with legacy Device Management protocols such as BBF TR-069, OMA-DM and LWM2M

• However, any such resource type specialization actually represents a oneM2M standardized (i.e. pre-defined) resource type itself– If there is a need to add a new management object, or add/change attributes

of an existing specialization, it requires oneM2M standardization activity before any such new or updated management object could be deployed into a M2M system

– It may even require a major SW upgrade of all deployed nodes of an M2M system to a new oneM2M-system release before it is possible to make use of new or updated resource types


6

Current oneM2M Approach

• OneM2M has focused on standardizing resource types required to enable the fundamental functions expected from a globally usable M2M system– Making oneM2M a general “operating system” for M2M services and apps

• Only two generic resource types have been defined which are intended to build applications upon– These are the <container> and <contentInstance> resource types

• Although building complex applications based on <container> and <contentInstance> resources is feasible, it quickly becomes extremely cumbersome and inefficient

• Using new resource types and specializations thereof, as proposed e.g. in MAS-2015-0608R01 (LGE) for Home Domain applications, would be one approach to derive more efficient representations of M2M nodes and applications


7

Suggested Approach

• We suggest that oneM2M defines a generic approach which enables flexible introduction of new customized resource types “on the fly” into already deployed oneM2M systems.

• Such dynamically defined resource types do not need to be standardized or registered system-wide – This gives M2M service providers and application developers the

highest degree of flexibility to introduce new resource types

• oneM2M just needs to define constraints on customized resource type to enable their use in the overall system


8

Potential Example Resource Type

<customResourceType>

1identification

0..n[customAttribute]

<subscription>0..n

1source

1description

common attributes

<customResourceType>0..n

<washer>

1identification

1status

<subscription>0..n

1source

1description

common attributes

1washerProgram

0..1optionalInfo

<powerConsumption>0..n

Standardized “template” for custom resource types:

Example custom resource type:

Attributes common to <customResourceType>

Common/universal attributes

custom resource-type specific attributes

child resource(s)


9

Suggested Approach

• We suggest that oneM2M defines a generic approach which enables flexible introduction of new customized resource types “on the fly” into already deployed oneM2M systems.

• Such dynamically defined resource types do not need to be standardized or registered system-wide – This gives M2M service providers and application developers the

highest degree of flexibility to introduce new resource types

• oneM2M just needs to define constraints on customized resource type to enable their use in the overall system


10

Outline how it could work

• The XML schema definition developed in the PRO WG for each standardized resource type essentially includes all information required to implement and handle the resource in a CSE

• Additionally needed might be the specification of resource-type specific procedures (if applicable)– For most resource types this however is not required and generic

CRUD procedures apply– This is especially the case for <container> and <contentInstance>

resource types


11

What’s needed to define a new resource type?• XML Schema definition (XSD) which defines

– presence and cardinality (min and max number of occurrences) of attributes– data types of each resource attribute and applicable child resource– allocation of a resource type identifier– Note: any instantiation of a resource can be validated against its XSD with respect to correct

representation of any resource attribute values or of any of their sub-elements.

• List of common and resource-specific attributes and definition of their presence in Create and Update primitives

• If applicable, a description of resource type specific procedures and definitions (e.g. default behavior when optional resource attributes are not supplied)

– done for each CRUD operation, in case any differences from the generic procedures apply

• Specification of the applicable parent and child resources of any resource type. This is specified in clause 9.6.1 of TS-0001. The applicable child resources are also reflected in each of the resource-specific XSD

• Mapping between long and short names used for resource attributes and of their complex type sub-elements


12

Message flow for Creation of a resource of type yet unknown to the hosting CSE

AE CSE

1) Create request(resourceType = 10000, resourceRef = http://myorg.com/customType.xsd,primitiveContent = {XML or JSON representation of resource attributes}

2) Download “customType.xsd” from http://myorg.com, auto-generate binding for resource class “customType” (root element name defined in XSD and applied in primitiveContent data)

4) responseprimitiveContent = {XML or JSON serialized resource representation}

3) Create an instance of the <customType> resource, e.g. denoted washer1 using the data supplied in primitiveContent. Store the instance in the local resource data base.


13

e.g. selected from a rangeof resoureType IDs reservedfor custom types

http://myorg.com/cusyomType.xsd

http://myorg.com/

Description of message flow1) Originator sends Create request for a resource type yet unknown to the receiver and

indicates a reference to an XSD file– Enumerated resourceType = 10000 (example) shall trigger creation of the new resource type.– New primitive parameter “resourceRef” provides a URI/URL of the XSD– Name of resource type is defined in both the XSD and the root element of the serialized

representation supplied in primitiveContent

2) Provided the CSE supports custom resource types (for the requesting originator) it downloads the XSD file from the location indicated by the resourceRef primitive parameter (using ordinary HTTP GET request)

3) The hosting CSE auto-generates binding code for the requested new resource type, validates the data supplied in primitiveContent against the XSD. Hosting CSE adds any common resource attributes which need to be created locally (e.g. resourceName, resourceID, resourceType (enumeration code), creation/expiration time, etc.), and stores the instance of the new resource type in its data base

4) Hosting CSE sends the response to the originator, indicating successful creation of the requested resource with custom resource type, the originator obtains the attributes assigned by the hosting CSE such as assigned resourceType ID and resourceID. Any future CRUD requests for this resource type will apply the assigned resource Type ID


14

What needs to be standardized?• Definition of a range of resource type IDs reserved for custom resource types• Addition of one optional parameter to request primitives, which provides the URI to the XML

Schema Definition file of the custom resource Type and definition of the procedure how to deal with this XSD

– This primitive parameter should be supported by any of the binding protocols (i.e. HTTP, CoAP, MQTT and WebSockets)

• Addition of a general description of custom resource types to clause 9.6 of TS-0001, similarly to the section which describes the <mgmtObj> attribute (and clause 7.3 of TS-0004)

• Addition of a generic procedure for CRUD operations on custom resource types to clause 10.2 of TS-0001 (and clause 7.3 of TS-0004)

• Definition of the applicable parent resources of customized resources• Possibly minor updates of resource discovery and subscription procedures to enable

discovery of and subscription to custom resource types• Specification of error handling (e.g. additional response status codes) for entities not

supporting custom resource types• Possibly addition of an informative Annex to TS-0004 which could define design guidelines for

custom resource types and outline potential example implementation(s)


15

Trusted Web Server:https://www.onem2m.org/xml

XSD repository

codegenerator

CSEcode

CSEcode

development platformM2M DeviceTarget HW

Trusted Web Server:https://www.qualcomm.com/xml

Custom XSD repository

codegenerator

CSEcode

M2M Device

AEcode

M2M Device

other CSEs

Use of XSD for customized resource types:

Possible use of XSD (examples) Current use of XSD for standardized resource types:


16

Proposal• We suggest to discuss the proposed concept in MAS,

ARC, and PRO WGs – There are also some SEC aspects related to secure handling

of the XSD

• If it can be agreed to spend more work into this, we should decide under which WI it primarily should be performed and which WG should have primary responsibility. Candidates include the following:– WI-0017 - Home Domain Enablement (MAS)– WI-0018 - oneM2M and AllJoyn Interworking (ARC)– WI-0039 - Release 2 Small Technical Enhancements (ARC + PRO)


17

Customized Resource Types MAS-2015-0626 Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow,...

Documents

Transcript of Customized Resource Types MAS-2015-0626 Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow,...