Notification aggregation in onem2m

Abstract

A method of communication in aggregating notifications in a oneM2M standard is disclosed The method comprises receiving (502) a first request from an originator, wherein the first request comprises an indication to perform a first event on plurality of members of the oneM2M. Further, a second request from the originator is received (504). The second request comprises an indication to perform a second event on plurality of members of the oneM2M. Further, the method comprises generating (506) first notifications in response to occurrence of the first event and generating second notifications in response to occurrence of the second event. The first notifications are collated and the second notifications are collated separately.

Description

NOTIFICATION AGGREGATION IN oneM2MFIELD OF INVENTION

[0001] Embodiments of the present application relate to notification aggregation in oneM2M, global standard for IoT / M2M.BACKGROUND OF THE INVENTION

[0002] oneM2M is a global partnership project founded in 2012 constituted by eight of the world's leading information and communication (ICT) standards development organizations.

[0003] oneM2M creates a common M2M service layer that can be easily implemented across various vertical industries and applications. This common service layer will enable interoperability between different M2M and loT devices, networks and platforms, and will allow seamless data exchange and communication between them.

[0004] A group management common service function (CSF) of oneM2M provides many advantages by allowing grouping of resources and performing various operation on these group of members using fanout request instead of sending individual request to each member. It also enables an application to take group subscription on a set of resources representing device or application on device etc. hence allowing an application to create subscriptions on multiple resources by sending single request.

[0005] A subscription & notification CSF of oneM2M specification provides advantage to an application developer by allowing them to define notification events, policies through subscription resource on set of devices, resources etc. and sending the notification when an event occurs.

[0006] An aggregated notification feature of oneM2M allows an application to receive a bunch of notifications in one message. The aggregation of notification can be indicated at the time of creation of subscription on the group members through afanout request. These notifications are aggregated on the basis of number or on the basis of duration when the notifications are received. Thus, a subscriber of such an application only receives a bunch of notifications and is not aware of which notifications are for which events. Such grouped notifications may not be of any use for subscribers. In the event, when multiple operations are being performed on a device then it may lead to a bunching of different set of notifications of different events hence leading to mixed information to be sent to application for processing.SUMMARY OF THE INVENTION

[0007] The following presents a simplified summary of the subject matter in order to provide a basic understanding of some of the aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key / critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.

[0008] The present subject matter discloses a method for aggregating notifications in a oneM2M standard.

[0009] The method for aggregating the notification comprises receiving a first request from an originator. In an example, the originator may be a computing device or an application running on the computing device. The first request comprises an indication to perform a first event on plurality of members / resources of the oneM2M. The plurality of the members may be hosted by a common service entity (CSE) of the oneM2M.

[0010] The method further comprises receiving a second request from the originator, wherein the second request comprises an indication to perform a second event on a plurality of members of the oneM2M.

[0011] In response to the occurrence of the first event on the plurality of members, first notifications are generated and in response to occurrence of the second event, second notifications are generated. According to the present subject matter, the first notifications based on first event is collated and the second notifications based on the second event is collated separately.

[0012] Thus, according to the present subject matter, notifications are collated based on the events. The notifications of the first event are collated together and the notifications for the second event are collated separately from the notifications for the first event. Such collated notifications may be then sent to a subscriber of the originator or any target application. Thus, the subscriber would receive collated notifications of every event separately would be able to efficiently analyze the notifications.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGSThe following drawings are illustrative of particular examples for enabling systems and methods of the present disclosure and are not intended to limit the scope of the invention. The drawings are not to scale (unless so stated) and are intended for use in conjunction with the explanations in the following detailed description.Figures 1 shows a system 100 for aggregating notifications in accordance with an example implementation of the present subject matter.Figures 2 shows the system 100 for aggregating notifications in another example implementation of the present subject matter.Figures 3 shows a flow diagram for aggregating notifications in an example implementation of the present subject matter.Figure 4 shows a flow diagram for aggregating notification in another example implementation of the present subject matter.Figure 5 shows a method for aggregating notifications in an example implementation of the present subject matter.Persons skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and may represent both hardware and software components of the system. Further, the dimensions of some of the elements in the figure may be exaggerated relative to other elements to help to improve understanding of various exemplary embodiments of the present disclosure. Throughout the drawings, it shouldbe noted that like reference numbers are used to depict the same or similar elements, features, and structures.DETAILED DESCRIPTION

[0013] Exemplary embodiments now will be described. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting. In the drawings, like numbers refer to like elements.

[0014] Figure 1 shows a system 100 in accordance with an example implementation of the present subject matter. The system 100 is implemented in a oneM2M architecture. The system 100 comprises a plurality of common service entity (CSE) 102-1, 102-2,..102-n. The CSE 102-1, 102-2,..102-n is a functional entity that provides a standardized interface for communication between M2M and internet of things (loT) devices, networks and applications. The CSE 102-1, 102-2,..102-n acts as an intermediary between M2M / IoT devices and applications, allowing them to interact with each other in a standardized manner, regardless of the specific underlying network or technology being used. The CSE 102-1, 102-2,..102-n provides a set of standardized Application Programming Interfaces (APIs) that enable M2M / IoT applications to access and manage devices and data across different networks and platforms.

[0015] In an example, the CSE 102-1, 102-2,..102-n can be deployed as a cloudbased service, a local gateway, or a dedicated server.

[0016] The CSE 102-1, 102-2,..102-n comprises a plurality of members. In an example, the plurality of members may be computing devices, loT devices etc. Each of the CSE 102-1, 102-2,... , 102-n comprises plurality of members, however, for sake of simplicity, only the CSE 102-1 is shown in fig. 1 to have plurality of members 104-1, 104-2,... ,104-n.

[0017] An originator is an entity which may provide instructions to perform various events on the plurality of the members 104-1, 104-2,... ,104-n. A target application is an entity which receives notifications for performance of an event on the plurality of members. The target application may subscribe to the members for which the target application requires to receive the notifications. In an example, the target application may subscribe to the members of same or different CSEs. For example, the target application may subscribe to one member of CSE 102-1 and two members of CSE 102-2. Further, in another example, two different target applications may subscribe to same members. For example, a target application may subscribe to the member 104-1 and 104-2 and another target application may also subscribe to a member 104-1 and 104-2. Based on the subscription, the target application receives notifications when events are performed on the plurality of members.

[0018] For performing an event on the plurality of the members, a request for performing the event is received from an originator. According to the present subject matter, an event module 106 receives a first request from an originator. The first request is for initiating a first event on the plurality of members. Further, the event module 106 receives a second request from the originator for initiating a second event on the plurality of members. In an example, the first event and the second event may be defined as performance of one or more operation on the plurality of members. In an example, the first event may be an operation of updating an operating system of plurality of members while the second event may be an operation of switching ON the plurality of members. The event module 106 transmits the first request and the second request to the respective CSE for performance of the events on the plurality of the members.

[0019] In response to occurrence of the first event on the plurality of members, first notifications are generated by a notification module 106 of the respective CSE. For example, if the first event is updating an operating system of the plurality of members, a notification may be generated for each of the members indicating whether the update was successful or not. The first notifications, thus, comprise notificationsgenerated for each member when a first event is performed on the plurality of the members. Similarly, for the second event, second notifications are generated. The generated first notifications and the second notifications are sent to a notification aggregation module 108.

[0020] The notification aggregation module 108 thereafter aggregates the first notification together and aggregate, separately, the second notifications. The aggregated first notifications and the aggregated second notification may be sent to a target application which has subscribed to the members for which the notifications are generated. Thus, the notifications for the first event are sent together and the notifications for the second event are sent together to the target application. Thus, as the notifications are sent based on the events, the notifications can be efficiently analyzed. A user / administrator of the target would receive together the first notifications based on the first event and would receive together the second notifications based on the second event. The user / administrator would be able take proper action based on the notifications as the notifications are received based on the events for which the notifications are generated.

[0021] Fig. 2 illustrates the system 100 in another example implementation of the present subject matter.

[0022] As explained with reference to Fig. 1, the system comprises CSE 102-1, 102- 2,..102-n. The system 100 communicates with an originator 202 via a communication link. In an example, the communication link, may be an internet, a Bluetooth network, an infrared network, a mobile network, local area network (LAN), wide area network (WAN) etc.

[0023] In an example, the originator 202 may be a computing system, a server, a mobile device, a laptop computer, a desktop computer, a tablet etc. The originator sends a request for performance an event on the plurality of the members of the CSE CSE 102-1, 102-2,..102-n.

[0024] A single originator 202 is shown in figure 1 for simplicity, however it should be understood that there may be multiple originators in communication with the system 100.

[0025] The originator 202 may instruct the CSE 102-1, 102-2,..102-n to perform various events on the plurality of members 104-1, 104-2, and 104-n. In an example, a target application (not shown) may require notifications about the events being performed on the plurality of members 104-1, 104-2, and 104-n. In an example, the target application may subscribe to one or more plurality of members 104-1, 104-2, and 104-n. of the CSE 102-1, 102-2,..102-n for which it requires the notifications. In an example, if a target application requires notifications of events performed on the member 104-1 and 104-2 of the CSE 102-1 and members of the CSE 102-2, the target application may subscribe to the members 104-1 and 104-2 of the CSE 102-1 and the members of CSE 102-2. In an example, there may be multiple target applications requiring notifications from plurality of the members regarding occurrence of an event on the plurality of members. Based on the requirements, a subscription may be created for each of the target applications. To create a subscription, the target application may indicate the members required for subscription to the originator 202 and the originator 202 may send a subscription creation request to a group hosting CSE 206 with an indication for notification aggregation. The subscription is thereafter created and hosted on the group hosting CSE 206. The CSE 206 may assign a subscription identifier to each of the subscription to uniquely identify the subscriptions.

[0026] Considering an example, the members 104-1, 104-2, and 104-3 are three loT streetlights of a city. Target applications, such as a city dashboard, a zone dashboard, and a local municipal require notifications when the three streetlights are switched ON or switched OFF. Thus, in this case, for each of the target applications, a subscription is created and each of the target applications are subscribed to the three members 104-1, 104-2, and 104-3 (three streetlights in the said example). Thesubscriptions are created by the CSE 206 based on indication received from the originator and the subscriptions are hosted on the CSE 206.

[0027] After the subscription is created, when an event is to be performed on the plurality of the members of the CSE 102-1, 102-2,..102-n, a request may sent by the originator 202 to the subscription hosing CSE 206 to perform the event on the plurality of the members. In an example embodiment, the originator 204 may send a first request to the CSE 206 to perform a first event on the member 104-1 and 104-2. Further, the originator 202 may send a second request to the CSE 206 to perform a second event on the members 104-3, 104-4. In an example, a user or administrator of the originator may send the first request and the second request.

[0028] In an example embodiment of the present subject matter, the originator 202 may include an aggregation indication in the first request and the second request. Basis this indication, the CSE 206 generates an aggregation identifier such that it identifies its original request and group. The aggregation identifier indicates to the CSE 206 that aggregation of notifications is required for the occurrence of the first event on the members 104-1, 104-2, and occurrence of the second event on the members 104-3 and 104-4. The first event is occurring on the members 104-1 and 104-2 and the second event is occurring on the members 104-3 and 104-4 should not be construed as a limitation as any event may occur on any or all of the members. The above example is only discussed for the ease of explanation.

[0029] After the group hosting CSE 206 receives the first request and the second request, an identifier module 204 appends a first identifier to the first request and a second identifier to the second request. Thereafter, the first request and the second request are sent to the respective CSE along with the first and second identifiers. In this case, the first request is received for members 104-1 and 104-2 and the second request is received for the members, 104-3, 104-4, and the members 104-1 to 104-4 reside within the CSE 102-1. Thus, in this case the first request and the second request are sent to the CSE 102-1. The event module 106 of the CSE 102-1 receivesthe first request and the second request along with the appended first identifier and the second identifier.

[0030] Based on the first and second request, the CSE 102-1 performs the first event on the members 104-1 and 104-2 and performs the second event on the members 104- 3 and 140-4. The notification module 108 generates notification for the member 104- 1 when the first event has been completed on the member 104-1 and generates a notification when the second event has been completed on the member 104-2. The notifications generated for member 104-1 and member 104-2 are referred to as first notifications. The notification module 106 includes the first identifier with each of the first notifications. The notification module 108 further generates a notification for the occurrence of second event on the member 104-3 and a notification for the occurrence of the second event on the member 104-4. The notifications generated for the occurrence of second event is referred to as second notifications. Each of the second notifications also includes the second identifier. The first notifications and the second notifications are sent to a notification aggregation module 206.

[0031] As discussed above, the originator 202 has indicated that the notifications need to be aggregated, the notification aggregation module 206 aggregates the first notification, generated for occurrence of first event. The first notifications are aggregated based on the first identifier appended with the first notifications. In other words, the notification module 206 collages together all the notifications having the first identifier. Similarly, the notification module 206 collates together the second notifications.

[0032] The aggregated notifications are sent to a target application by the sending module 208. The target applications thus receives the aggregated notifications based on the events and efficiently analyze the notifications to take proper action.

[0033] As understood, the aggregation of notification has been explained with reference to the CSE 102-1 for simplicity and the above described technique of aggregation of notification is applicable for the CSE 102-2, 102-3,... ,102-n.

[0034] Figure 3 shows a flow diagram for aggregating notification in an example implementation of the present subject matter. In the figure 3 a group hosting common service entity (CSE) 302 is shown. The group hosting CSE 302 is similar to the group hosting CSE 206 discussed with reference to figure 2. Further, in an example embodiment, the group hosting CSE 302 may also host members 304 and 306. Further, a CSE 308 is shown to host members 310 and 312. The CSE 302 and 308 may be a part of a system 300. The system 300 may be similar to the system 100 as shown with reference to figure 1 and figure 2.

[0035] An originator 314, similar to the originator 204, may send a first request 316 for performing a first event on the member 304 and the member 310. Further, the originator 314 sends a second request 318 for performing a second event on the member 406 and 310.

[0036] The CSE 302 receives the first request and the second request. The first request 316 and the second request 318 are also forwarded to the CSE 308. An identifier module may append a first identifier to the first request and a second identifier to the second request.

[0037] Thereafter, a first event is performed on the member 304 and the member 312 and the second event is performed on the member 406 and the member 310. After the first event is performed on the member 304, a notification N 11 is generated and after the first event is performed on the member 312 a notification N12 is generated. The notifications Ni l, N12 are referred to as first notifications. The first identifier is appended with the each of the notification Ni l and the notification N12.

[0038] Similarly, notifications N21, N22 are generated. The second identifier is appended with the second notifications N21 and N22. The notifications N21 and N22 are referred to as second notifications.

[0039] The notifications N22 and N12 are sent to the CSE 302. A notification aggregation module of the CSE 302, aggregates the notifications Ni l and N12 together based on the first identifier. Similarly, the notifications N21 and N22 are aggregated by the notification aggregation module based on the second identifier.Thus, the notifications Ni l and N12 that are generated based on the first event are aggregated together. Further, the notifications N21 and N22 that are generated based on the second event are aggregated together. The aggregated notifications Ni l, N12 & N21, N22 may be sent to a target application that has subscribed to the members 304, 406, 310, 312.

[0040] Figure 4 shows a flow diagram for aggregating notification in another example implementation of the present subject matter. In figure 4 a group hosting common service entity (CSE) 402 is shown. The group hosting CSE 402 is similar to the group hosting CSE 206 discussed with reference to figure 2. Further, in an example embodiment, the group hosting CSE 402 may also host members 404 and 406. Further, a CSE 408 is shown to host members 410 and 412. The CSE 402 and 408 may be a part of a system 400. The system 400 may be similar to the system 100 as shown with reference to figure 1 and figure 2.

[0041] An originator 414, similar to the originator 404, may send a first request 416 for performing a first event on the members 404, 406, 410, and 412. Further, the originator 414 sends a second request 418 for performing a second event on the member 404, 406, 410, and 412.

[0042] The CSE 402 receives the first request and the second request. The first request 416 and the second request 418 are also forwarded to the CSE 408. An identifier module may append a first identifier to the first request and a second identifier to the second request.

[0043] Thereafter, a first event is performed on the members 404, 406, 410, and 412 and the second event is also performed on the member 404, 406, 410, and 412. After the first event is performed on the member 404, 406, 410, and 412, notifications Ni l, N12, N13, and N14 are generated. The notifications Ni l, N12, N13, and N14 are referred to as first notifications. The first identifier is appended with the each of the notifications Ni l, N12, N13, and N14.

[0044] Similarly, notifications N21, N22, N23, and N24 are generated for occurrence of second event. The second identifier is appended with the second notifications N21,N22, N23, and N24. The notifications N21, N22, N23, and N24 are referred to as second notifications. The notifications N21, N22, N23, and N24 are sent to the CSE 402. A notification aggregation module of the CSE 402, aggregates the notifications Ni l, N12, N13, and N14 together based on the first identifier. Similarly, the notifications N21, N22, N23, and N24 are aggregated by the notification aggregation module based on the second identifier. Thus, the notifications Ni l, N12, N13, and N14 that are generated based on the first event are aggregated together. Further, the notifications N21, N22, N23, and N24 that are generated based on the second event are aggregated together. The aggregated notifications Ni l, N12, N13, and N14 and N21, N22, N23, and N24 may be sent to a target application that has subscribed to the members 404, 406, 410, and 412.

[0045] Figure 5 shows a method 500 for aggregating notifications in a one machine - to-machine (M2M) standard in an example implementation of the present subject matter. It should be understood that the method steps are shown as a reference only and sequence of the method steps should not be construed as limitation. The method steps can include any additional steps in any order. Although method 500 may be implemented in any system, the example method 500 is provided in reference to the system 100 for ease of explanation.

[0046] At block 502, a first request is received from an originator. The first request is received by common service entity (CSE), such as the CSE 302, 402. The first request comprises an indication to perform a first event on plurality of members of the oneM2M. As explained above, the CSE of oneM2M hosts a plurality of members.

[0047] At block 504 a second request is received from the originator. The second request comprises an indication to perform a second event on plurality of members of the oneM2M. A first identifier is appended with the first request and a second identifier is appended with the second request.

[0048] At block 506, first notifications are generated notifications in response to occurrence of the first event and second notifications are generated in response to occurrence of the second event. The first identifier received with the first request isincluded in each of the first notifications and the second identifier received with the second request is included in each of the of the second notifications.

[0049] At block 508, the first notifications, that based on the first event, are collated.Further, at block 510, the second notifications are also collated separately. The collated first notifications and the second notifications are sent to a target application.

[0050] In the specification, there has been disclosed exemplary embodiments of the invention. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation of the scope of the invention.

Claims

We claim:

1. A method for aggregating notifications in a oneM2M standard, the method comprising: receiving (502) a first request from an originator, wherein the first request comprises an indication to perform a first event on plurality of members of the oneM2M; receiving (504) a second request from the originator, wherein the second request comprises an indication to perform a second event on plurality of members of the oneM2M; generating (506) first notifications in response to occurrence of the first event and generating second notifications in response to occurrence of the second event; and collating (508) first notifications generated based on the first event; collating (510), separately, the second notifications generated based on the second event.

2. The method as claimed in claim 1 wherein aggregating the notification comprises: receiving the first request and appending a first identifier to the first request; receiving the second request and appending a second identifier to the second request; collating the first notifications based on the first identifier ; collating, separately, the second notifications based on the second identifier.

3. The method as claimed in claim 1, wherein the method comprises sending the collated first notifications and the collated second notifications to a target application of the plurality of the members (304, 306, 310, and 312).

4. A system (100) for aggregating notifications in a oneM2M standard, the system comprising: a plurality of common service entity (102-1, 102-2, 102-n) comprising plurality of members (104-1, 104-2,. .. ,,104-n); an event module (106) to: receive a first request from an originator (314, 414), wherein the first request initiates a first event on the plurality of members;receive a second request from the originator, wherein the second request initiates a second event on the plurality of members; the plurality of common service entity comprising: a notification module (106) to: generate first notifications for the first event in response to occurrence of the first event on the plurality of members and generating second notifications for the second event in response to occurrence of the second event on the plurality of members; and a notification aggregation module (108) to: aggregate the first notifications; aggregate, separately, the second notifications.

5. The system (100) as claimed in claim 5 wherein system comprises an identifier module to: append a first identifier to the first request; and append a second identifier to the second request.

6. The system (100) as claimed in claim 5 wherein each of the first request and the second request comprises an aggregation indication to indicate to the plurality of common service entity that aggregated notifications is requested.

7. The system (100) as claimed in claim 6, wherein the system comprises an identifier module to: append each of the first notifications with the first identifier; and append each of the second notifications with the second identifier.

8. The system (100) as claimed in claim 7 wherein the notification module (106) is to: aggregate the first notifications based on the first identifier; and aggregate, separately, the second notifications based on the second identifier.

9. The system (100) as claimed in claim 8 comprising a sending module (208) to: send the aggregated first notifications and the aggregated second notifications to a target application of the plurality of the members.

Images