2

What if an IN-AE creates a group of lights with ADN-AE1 and ADN-AE2, controlling them by using just one request. The diagram shows that, it uses one request to control both of them but when I click the request example, its creates <contentInstances> one by one. Is there any example that I can control a group of resources with just one request or this is not in oneM2M's scope ?

Call flows for multiple light control are depicted in the figure below and are ordered as follows:

When the user updates a group of light states on her/his smartphone, the IN-AE creates a new contentInstance targeting a group of Light ADN-AE container resources hosted on the MN-CSE. Request shown here

For each contentInstances created successfully, the MN-CSE sends a notification to the corresponding Light ADN-AE.

enter image description here

---------------------- --------- EDITED -------------------------------

enter image description here

enter image description here

Andreas Kraft
  • 3,754
  • 1
  • 30
  • 39
Barış Velioğlu
  • 5,709
  • 15
  • 59
  • 105

1 Answers1

4

A <group> resource bundles and manages a number of resources (either of the same or of a mixed resource type), in your example the two <container>'s under ADN-AE1 and ADN-AE2.

In addition to its other attributes a <group> has a virtual resource called the <fanOutPoint>. This virtual resource multiplies internally every request it receives for all the fitting resources of the <group>, be it CREATE, READ, UPDATE or DELETE.

In the example, the <container>'s exist before they are organised in a group, and can be accessed and controlled independently. The <group> resource now bundles them together and makes them available for an application as a single entity. When this <group> receives a CREATE request for a <contentInstance> the group automatically creates a new <contentInstance> resource for all its resources. For the ADN-AE's, though, it doesn't matter who and how the <contentInstance>'s where created.

Interestingly, this decouples the IN-AE application from the actual deployment and orchestration of an infrastructure. Just imagine that a <group> bundles all the lights in a home. This <group> is managed by a home manager AE. Now, another AE, for managing the home when the inhabitants leave, doesn't need to know much about the actual devices in the home. It only needs to sends one request to the <group> resource to switch off all the lights.

Update

Check oneM2M's "TS-0001 - Functional Architecture", sections "9.6.13 - Resource Type group" for the <group> and "9.6.14 - Resource Type fanOutPoint" for the <fanOutPoint> for the specification of this behaviour.

Andreas Kraft
  • 3,754
  • 1
  • 30
  • 39
  • So I should only need to send a to the related then cse should take care how to process it. Do you know any OneM2M documents that gives a sample for this scenario ? – Barış Velioğlu Apr 15 '19 at 17:50
  • Exactly, the CSE is responsible to process and fan out the requests to the resources. You might want to check in TS-0001 the sections "9.6.13 - Resource Type group" for the <group> and "9.6.14 - Resource Type fanOutPoint" for the <fanOutPoint>. – Andreas Kraft Apr 15 '19 at 17:57
  • Hi Andreas. I know its a little bit late but I updated the question because of a misunderstanding. TS-0004 7.2.1.1-1 it says if the request is a create operation, request primitive must contain resource type (ty) but when we look at the fanout group operation, it is also a create operation but the resource type is not specified. So we have built a centralized check for request primitive that every create request needs to have resource type, but then this is a different case and I need to understand its a documentation mistake or something different than that ? – Barış Velioğlu May 07 '19 at 08:05
  • 1
    This is a good point. The group already "knows" the type of its resources through its 'memberType' attribute. There is no need to specify the type. It actually would be meaningless when the 'memberType' is mixed. The CSE would have to check the individual resource types anyway. But perhaps this should be made more clear in the spec. – Andreas Kraft May 07 '19 at 21:48
  • 1
    Actually I am not mentioning 'memberType' attribute of the . In TR-0025 guide, there is a message that updates the state of all lights using group fanout (8.7.11.4). The point is, the post request doesnt contain any 'ty' attribute in the Content-Type header in that example. However the spec says each post request must contain 'ty' attribute in their content-type attribute of header but the example doesnt. So is this an exception for group fanout ? – Barış Velioğlu May 09 '19 at 08:21
  • 2
    You are right, the 'ty' attribute **must** be present in a CREATE request. It looks like you have found an issue in TR-0025. I will forward this in oneM2M. – Andreas Kraft May 13 '19 at 09:51