5.3 Principles of data flows

5.3.1 Preconditions on the communicating entity

Data flows between a communicating entity and the IPE involve oneM2M resources - specialized <flexContainer> s and possibly <AE> s - that were created by the IPE for the purpose of that communication.

Note

1: In this clause and in the subsequent clauses it is assumed that the communicating entity and the IPE uses the oneM2M subscribe/notify mechanism to become informed about UPDATEd resources.
It remains, however, an implementation option if subscribe/notify is used or other mechanisms (polling or other mechanisms, e.g. in case of IPE collocated/integrated in its hosting CSE) are used.

1. Any communicating entity, that:
   • a. wants to discover interworked non-oneM2M devices of the non-oneM2M system via the IPE needs to be subscribed to the <AE> resource of the IPE to get notified about newly created resources for Proxied Devices.
     These resources are created by the IPE to represent interworked non-oneM2M devices that were discovered by the IPE.
     • A communicating entity also needs to be subscribed to the <AE> resource of the IPE if it wants to use network services (e.g. broadcast services, registration services ...) that are offered by the IPE.

Note

2: Since the IPE, in addition to being a oneM2M AE , is part of the non-oneM2M system it contains a non-oneM2M device that can offer network services.

• b. wants to communicate with a specific interworked non-oneM2M device via the IPE needs to be subscribed to the <flexContainer> (or <AE>) resource that had been created by the IPE to represent that interworked non-oneM2M device as Proxied Device.
• c. wants to communicate with a sub-device of a Proxied Device, represented by a <flexContainer> that is a child-resource of the Device's <flexContainer> (or <AE>) resource the communicating entity needs also to be subscribed to that <flexContainer> child-resource.

1. The communicating entity needs also be subscribed to:
   • a. The <flexContainer> resources, representing Services, that have been created by the IPE as child resourses of the resource of the Proxied Device. The attribute notificationContentType of the <subscription> needs to be set to "modified-attributes".

   • b. The <flexContainer> resources for the Operation invocation. These resources are child-resources of their respective Service <flexContainer> resources.
     The eventNotificationCriteria conditions the notificationEventType needs to contain:

     • (B) Deletion of the subscribed-to resource
       ... to get notified when the operation becomes unavailable

     and, if the operation involves an answer (operation results). also

     • (C) Creation of a direct child of the subscribed-to resource
       ... to get notified about the creation of a <flexContainer> for the Operation result.
       • c. The <flexContainer> for the Operation result. The attribute notificationContentType of the <subscription > needs to be set to "all-attributes".

5.3.2 Data flows for communicating with the IPE using DataPoints of a Service

The following figures show the data flows for communicating with the IPE using DataPoints of a Service.

Figure 5.3.2-1: Data flow for an IPE involving dataPoints

When a communicating entity wants to invoke a command on the Interworked Device (e.g. an actuation command), using Datapoints of the related Service:

• The communicating entity UPDATEs the corresponding <flexContainer> that represents the service with the new value for customAttribute of the InputDatapoint.
• The CSE subsequently NOTIFYes the IPE about the changed value for customAttribute of the InputDatapoint.
• The IPE invokes the command at the Interworked Device that sends the data of the InputDatapoint to the Interworked Device.

When the Interworked Device wants to invoke a command (e.g. a reporting) on the IPE - or a subscribed communicating entity, using Datapoints of the related Service:

• The Interworked Device invokes the command at the IPE that sends the data of the OutputDatapoint to the IPE.
• The IPE UPDATEs the corresponding <flexContainer> that represents the Service with the new value for customAttribute of that OutputDatapoint.
• The CSE subsequently NOTIFYes subscribed communicating entities about the changed value for customAttribute of the OutputDatapoint.

5.3.3 Data flows for communicating with the IPE using Operations of a Service

The following figures show the data flows for communicating with the IPE using an Operation of a Service.

Figure 5.3.3-1: Data flow for a translating entity involving operations when initiated by a communicating entity

In contrast to DataPoints Operations allow grouping of input- and output parameters of a Command into a single transaction between the communicating entity and the target entity. It is permissible that no OperationInput and/or OperationOutput data exist for an Operation:

• When the communicating entity invokes an operation in the target entity it UPDATEs the <flexContainer> resource for the Operation invocation, potentially with OperationInput values for the related customAttributes . If the operation involves no OperationInput the UPDATE request contains no customAttributes.
• The CSE subsequently NOTIFYes the IPE about the updated <flexContainer> resource for the Operation invocation, potetially with OperationInput values for the related customAttributes.
• The IPE invokes the command at the Interworked Device.

If the Operation involves an (optional or mandatory) answer from the Interworked Device then:

• The Interworked Device returns the answer on the command, containing output data, to the IPE. The IPE needs to wait for that answer for a configurable maximum time that may depend on the technology of the interworked non-oneM2M solution.
• The IPE UPDATEs the corresponding <flexContainer> that represents the Operation result with OperationOutput values for the related customAttributes.
• The CSE subsequently NOTIFYes the communicating entity about the update of the <flexContainer> that represents the Operation result.