2

My use case is the following: I have hundreds (if not thousands) of AE that are subscribed to 1 other AE that publish sensor data on a container. Each of these AE has the same POA. The issue is that for each sensor data, the same notification is sent in MQTT only to one subscriber: 1 new CIN triggers 1000 Notifications. Is it possible in the oneM2M spec to aggregate all those notifications as one, and for each subscribed AE to listen to the same topic and receive the same notification ?

It looks like groups and "notificationForwardingURI" may be what I'm looking for; but after reading TS0001 10.2.7.11 and 10.2.7.12; and table 9.6.8-2 I am not sure that it answer my issue.

achetv
  • 191
  • 7

2 Answers2

3

It sounds to me that the <subscription> resource may not be setup to do what you are attempting.

If you want to send the notification to multiple AE's, that should be configured by specifying the notificationURIs with the AE-ID of each receiver. From what you have described, it sounds like their is only 1 AE specified in the notificationURIs.

So if you have 1000 notificationURIs then there will be 1000 notifications.

If I understand what you are attempting to do, you want a single notification to be delivered using the MQTT message delivery mechanism. That is possible, but not defined in oneM2M. The oneM2M MQTT bindings are intended to create a one-to-one message flow between the CSE and the AE. You are trying to use MQTT in its intended method of 1 to many. So while not defined by oneM2M, this can be done in the following manner. 1) create 1 AE (notification receiver)
2) create a <subscription> with the notificationURI set to the AE.

Externally have all of your other listeners subscribe to the MQTT topic of the AE. Ensure that only 1 AE responds to the notification request.

Bob
  • 116
  • 3
  • 1
    My thought as well. This "notification receiver" AE could then send a single MQTT request to which all the other AEs are listen. The problem, however, is that security and access control, subscription handling of all the other AEs etc cannot be handled by the CSE. – Andreas Kraft Jul 03 '19 at 20:51
  • Bob & Andreas thanks I see, but in this case the "listeners" are not actually OneM2M nodes, they just have an access to the same broker and listen to a topic, right ? That would be something like this https://imgur.com/xWo07nq – achetv Jul 04 '19 at 08:59
  • Yes, I believe that if you have multiple listeners to the mqtt topic, that will occur outside the oneM2M domain, and should work just fine. – Bob Jul 08 '19 at 12:13
2

Using the notificationForwardingURI attribute might be the right way to implement your scenario. You also want to check TS-0001 (Functional Architecture), section "10.2.7.10 Subscribe and Un-Subscribe of a group" and TS-0004 (Service Layer Core Protocol Specification), section "7.4.14.2.3 Assign URI for aggregation of notification" and the following sections.

Also check in TS-0010 (MQTT Protocol Binding), section "6.6 URI format" for the format of the notification URI for MQTT.

Andreas Kraft
  • 3,754
  • 1
  • 30
  • 39
  • Thanks for your answer. I forgot to add that I'm implementing Release 2. I am still unsure of the functional end result. In my previous exemple, is it a group composed of 1000 AE listener that subscribe to the lone AE sensor ? – achetv Jul 03 '19 at 16:16
  • I just checked TS-0001, Version 2.24.0 (see http://www.onem2m.org/technical/published-drafts/release-2). The "notificationFowardingURI" is specified in this version as well. However, it might not be available in the implementation you are using. – Andreas Kraft Jul 03 '19 at 20:45
  • I'm in the process of implementing oneM2M, and have not implemented anything regarding groups/notificationFowardingURI yet. However I am not sure how implementing that would help me with the exemple I provided. After reading "Subscribe and Un-Subscribe of a group", "Aggregate the Notification by Group", "Assign URI for aggregation of Notification" things are not quite clear to me. Functionally, how should a Subscription be created so that a set of AE receive a unique Notification every time a ContentInstance is created ? How should "notificationForwardingURI" be used in this context ? – achetv Jul 03 '19 at 22:39
  • 1
    You are implementing a CSE, not using? You might want check TS-0001, "Table Table 10.2.7.10-1: Subscribe/Un-subscribe" and following that describes the process in detail. – Andreas Kraft Jul 04 '19 at 08:57
  • Thanks again Andreas. Yes am implementing a CSE. I read this table but this is what I understand "fanOutPoint" would allow me to do : https://imgur.com/KH4U9cL But this is what i would want to do : https://imgur.com/dLKT7CO – achetv Jul 04 '19 at 09:37
  • Please also see in TS-0001 "Table 10.2.7.11-1: Aggregation of Notifications by group", the row with "Processing at Group Hosting CSE": "Upon successful validation, aggregate the notifications which have the same notificationForwardingURI..." and "Send the aggregated notification to the subscriber according to the notificationForwardingURI in the notification." I think this is the behaviour you want, right? – Andreas Kraft Jul 04 '19 at 14:02
  • -10.2.7.11 Aggregate the Notifications by group : "This procedure shall be used for the group Hosting CSE to aggregate the notifications from member hosting CSEs and forward the aggregated notification to the subscriber." So this is this behaviour right : https://imgur.com/KH4U9cL ? My issue is the other way arround : a lot of subscriber to the same AE. – achetv Jul 04 '19 at 14:09
  • Yes, but the CSE is supposed to aggregate (according to some parameters) all notifications into one. You wanted to forward the notifications as single one to an MQTT server, right? – Andreas Kraft Jul 04 '19 at 17:26