Skip to content

6.1 oneM2M resources for IPE communication

6.1.1 General design principles

For Ontology-based Interworking the oneM2M resource types <AE > and specializations of <flexContainer > are intended to hold data that can be used for data exchange with the IPE.

For Ontology-based Interworking a convention is needed how the IPE uses these resources to communicate with other oneM2M entities. This is described in the subsequent clauses.

Resources for RESTful communication style vs. procedure call (RPC) style.

A Ontology-based Interworking IPE needs to be able to communicate with systems that implement some form of RESTful communication style as well as other systems that communicate in a procedure call (RPC) style.

For RESTful systems the use of Input- or OutputDataPoints may be more appropriate.

On the other hand procedure calls that involve stateful transactions between the IPE and the Interworked Device can be better modelled using Operations (and their OperationInputs/-Outputs).

6.1.2 Resource structure for modelling devices, sub-devices, services and operations

Figure 6.1.2-1 and Figure 6.1.2-2 provide an overview of parent-child resource relationships that are used for communication with Interworked Devices in the context of Ontology-based Interworking.

It involves the oneM2M resource types:

  • <AE> - for the Interworking Proxy Entity (IPE).
  • A <container> child resource of the <AE> of the IPE - for holding XSD files (for the specializations of <flexContainers>) used in the interworking.

Interworked Devices are represented either by:

  • <flexContainer> - child- resource of <AE> of IPE; or
  • <AE> - child resources of the hosting CSE of the IPE.

Note

An IPE may, instead of creating <flexContainer> resources for Interworked Devices, also choose to represent them as <AE> s. This option should be chosen if the interworked devices need to be identifiable for the purpose of service subscription, charging, differentiation during access control enforcement, authentication, App-ID registry, etc.

  • <flexContainer> - for a sub-device
    (child-resource of the <flexContainer> or <AE> of its parent device).
  • <node> for the node of a Device or sub-device.
  • <flexContainer> - for a Service of a Device or sub-device.
    (child-resource of the <flexContainer> or <AE> of the device that offers the Service).
  • <flexContainer>s for network services (e.g. broadcast services, registration services ...) that are offered by the IPE are child-resources of the IPE's <AE>.
  • <flexContainer> - for an Operation (invocation) of a Service.
    (child-resource of the <flexContainer> of the Service).
  • <flexContainer> - for an Operation (result) of a Service.
    (child-resource of the <flexContainer> of the Operation invocation of the Service).

Figure 6.1.2-1: Resources used in the context of Ontology-based Interworking when Interworked Devices are represented as _<flexContainer>_ s

Figure 6.1.2-1: Resources used in the context of Ontology-based Interworking when Interworked Devices are represented as <flexContainer> s

Parent-child relationships when Interworked Devices are represented as <flexContainer> s:

  • A <container> resource, for holding XSD files, is created as child-resource of the <AE> resource of the IPE.
  • <flexContainer> resources, for representing (network) Services are created as child-resources of the <AE> of the IPE.
  • <flexContainer> resources for representing Interworked Devices are created by the Ontology-based Interworking IPE as child-resources of the IPE's <AE>.
  • <flexContainer> resources, for representing sub-devices are created as child-resources of the <flexContainer> resource that represents the device to which the sub-devices belong.
  • <flexContainer> resources, for representing Services are created as child-resources of the <flexContainer> resource that represents the device or sub-device to which the Service belongs. Input- or OutputDataPoints are modelled as customAttributes.
  • <flexContainer> resources, for representing Operations invocations are created as child-resources of the <flexContainer> resource that represents the Service to which the Operation belongs.
    Only OperationInputs are modelled as customAttributes.
  • <flexContainer> resources, for representing Operations results are created as child-resources of the <flexContainer> resource that represents the Operations invocation to which the Operation result belongs.
    Both, OperationInputs and -Outputs are modelled as customAttributes.
  • All of the above can contain a <semanticDescriptor> as child resource and may contain <subscription> resources.

Figure 6.1.2-2: Resources used in the context of Ontology-based Interworking when Interworked Devices are represented as _<AE>_ s

Figure 6.1.2-1: Resources used in the context of Ontology-based Interworking when Interworked Devices are represented as <AE> s

Parent-child relationships when Interworked Devices are represented as <AE> s:

  • A <container> resource, for holding XSD files, is created as child-resource of the <AE> resource of the IPE.
  • <flexContainer> resources, for representing (network) Services are created as child-resources of the <AE> of the IPE.
  • An <AE> resource, representing each Interworked Device is created by the IPE as child-resources of the IPE's hosting CSE.
  • <flexContainer> resources, for representing sub-devices are created as child-resources of the <AE> resource that represents the device to which the sub-devices belong.
  • <flexContainer> resources, for representing Services are created as child-resources of the <AE> that represents the device (or <flexContainer> that represents the sub-device) to which the Service belongs.
    Input- or OutputDataPoints are modelled as customAttributes.
  • <flexContainer> resources, for representing Operation invocations are created as child-resources of the <flexContainer> resource that represents the Service to which the Operation belongs.
    Only OperationInputs are modelled as customAttributes.
  • <flexContainer> resources, for representing Operation results are created as child-resources of the <flexContainer> resource that represents the Operations invocation to which the Operation result belongs.
    Both, OperationInputs and -Outputs are modelled as customAttributes.
  • All of the above can contain a <semanticDescriptor> as child resource and may contain <subscription> resources.

Link relationships:

  • The <AE >s and <flexContainer> resources, representing Interworked Devices / fs may have nodeLink attributes to their respective <node> resources.

Note

If Interworked Devices / sub-devices are resident on the same node their nodeLink attributes reference the same <node> resource.