Apparatus and method for subscription and notification services

Abstract

The present disclosure relates to subscription and notification services. The mechanisms for subscription and notification may include dynamically changing notification behavior based on notification target status or supporting access to notification history information.

Description

[0001] This application is a divisional application of the invention patent application with application date of July 14, 2017, application number 201780045942.3, and invention name “Subscription and Notification Service”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 362,266, filed on July 14, 2016, entitled “SUBSCRIPTION AND NOTIFICATION SERVICE,” the contents of which are hereby incorporated by reference herein. Background Art

[0004] From the perspective of the protocol stack, the service layer usually sits above the application protocol layer and provides value-added services to the application. Therefore, the service layer is often classified as a "middleware" service. For example, Figure 1 An exemplary service layer between the IP network stack and the application is shown.

[0005] The M2M service layer is an example of a type of service layer that is specifically targeted at providing value-added services for M2M type devices and applications. Recently, several industry standard organizations (e.g., the oneM2M functional architecture) have been developing the M2M service layer to address the challenges associated with integrating M2M type devices and applications into deployments such as the Internet / Web, cellular, enterprise, and home networks.

[0006] The M2M service layer can provide applications and devices with access to a set of M2M-oriented capabilities supported by the service layer. Some examples include security, billing, data management, device management, discovery, configuration, and connection management. These capabilities are provided to applications through application programming interfaces (APIs) that utilize message formats, resource structures, resource representations, and function calls defined by the M2M service layer. For example, the M2M service layer can maintain a large amount of M2M data, and the M2M application can retrieve or subscribe to the large amount of M2M data based on its access rights. Subscription-based data access may be more efficient than retrieval-based data access because it does not introduce any messages to the M2M application before the desired changes are made to the subscribed resources. However, the cost is that the M2M application needs to subscribe first to receive automatic notifications from the M2M service layer.

[0007] oneM2M is a standard that provides technical specifications that address the need for a common M2M service layer that can be easily embedded in a variety of hardware and software, and can be relied upon to connect various devices in the field with M2M application servers around the world.

[0008] The oneM2M public service layer supports a set of public service functions (CSFs) (e.g., service capabilities), such as Figure 2 As shown. A set of one or more specific types of CSFs are called public service entities (CSEs), which can be hosted on different types of network nodes (e.g., infrastructure nodes (INs), middle nodes (MNs), application service nodes (ASNs)). CSFs provide a set of services to application entities (AEs) or other CSEs.

[0009] oneM2M developed Figure 3 Resource Oriented Architecture (ROA) as shown in . In the ROA architecture, resources are uniquely addressable elements in the architecture, with representations that can be manipulated through RESTful methods such as create, retrieve, update, and delete. These resources are addressable using Uniform Resource Identifiers (URIs). Resources can contain sub-resources and properties. A sub-resource is a resource that has a containment relationship with a parent resource. The parent resource representation contains references to its child resources. The life cycle of a child resource is constrained by the life cycle of the parent resource. Each resource supports a set of "properties" that store resource information.

[0010] A CSE can register with another CSE. For example, an M2M gateway (e.g., MN-CSE) registers itself with an M2M server (e.g., IN-CSE), and the M2M server becomes the registered CSE of the M2M gateway. Similarly, when an IN-AE registers with an IN-CSE, the IN-CSE is called the registered CSE of the IN-AE.

[0011] The oneM2M functional architecture defines a set of CSFs that can be provided by a CSE such as an M2M Server oneM2M functional architecture to other CSEs or AEs. One of the defined CSFs is Subscription and Notification (SUB), which provides notifications related to subscriptions that track changes on resources (e.g., deletion of resources).

[0012] SUB CSF manages subscriptions to resources according to the Access Control Policy (ACP) and sends corresponding notifications to the addresses where the resource subscriber wants to receive them. AE or CSE is a subscribing resource subscriber. AE and CSE subscribe to the resources of other CSEs. The subscribing hosting CSE sends notifications to one or more addresses (or notification targets) specified by the resource subscriber when modifications are made to the resource. The scope of a resource subscription includes tracking changes and operations on the attributes and direct child resources of the subscribed resource. It does not include tracking changes to the attributes of child resources. Each subscription may include notification criteria, which specify which notifications are sent, when they are sent, and how they are sent. These notification criteria can be used in conjunction with the Communication Management and Delivery Handling (CMDH) policies of oneM2M. Subscriptions are represented as resources in the CSE resource structure. <subscription>.

[0013] In summary, the functions supported by SUB CSF are as follows: oneM2M functional architecture: 1) Contains ID; 2) Ability to subscribe to resources; 3) Request by subscriber to send notifications; 4) Request to cache lost notifications; 5) Request rate limit for receiving notifications; or 5) Notification target is removed from CSE.

[0014] In more detail, the inclusion of a resource subscriber ID, a hosting CSE-ID and a subscribed resource address may be completed in accordance with a resource subscription request. It may also include other criteria (e.g., resource modifications of interest and notification policies) and one or more addresses to send notifications.

[0015] Ability to subscribe to a single resource through a single subscription, or to subscribe to multiple resources when they are grouped and represented as a single group resource. When a subscriber subscribes to a group of resources, the same event notification criteria is used for all resources in the group; in turn, the hosting CSE can generate notifications whenever changes to individual (not all) resources occur.

[0016] A subscriber can request the hosting CSE to send out notification messages in batches instead of sending them one at a time. A subscriber can indicate how many notification messages should be batched together.

[0017] A subscriber may request that the hosting CSE cache missed notifications due to periods of unavailable connectivity (e.g., to the subscriber). After connectivity becomes available, the hosting CSE may send the latest pending notifications or all pending notifications to the subscriber. A subscriber may indicate a rate limit for receiving notifications. Also, a notification target may request that the hosting CSE remove it from the list of targets for receiving notifications.

[0018] In oneM2M, a subscriber can be either an AE or a CSE, while a hosting node must be a CSE. For example, an IN-AE as a subscriber can subscribe to resources hosted by an IN-CSE (i.e., a hosting node). Figure 4 An example process according to the oneM2M specification is shown, in which IN-AE1 accesses resources on IN-CSE (e.g., <subscribed-to-resource>) to subscribe. To do this, IN-AE1 issues a CREATE request to <subscribed-to-resource>Create <subscription>Resources (i.e., step A); IN-AE1 can indicate eventNotificationCriteria and multiple notificationURIs in this step. eventNotificationCriteria shows that IN-AE1 is interested in <subscribed-to-resource>Notifications can be sent to a subscriber (e.g., IN-AE1) or a notification target as indicated by the notificationURI (i.e., notificationURI1 for the subscriber and notificationURI2 for another notification target in this example). IN-CSE, as the hosting CSE, will first create a subscription request after receiving it from step A. <subscription>As <subscribed-to-resource>. Afterwards, when the event occurs and satisfies the eventNotificationCriteria contained in step A, the IN-CSE will automatically send two notifications to the subscriber and the notification target respectively (i.e., step E and step F). Note that the subscription request in step A may contain multiple notificationURIs, which means that the subscriber is requesting that future notifications be sent to multiple notification targets. In this case, the eventNotificationCriteria is the same and applies to all notificationURIs. Although not shown in the figure, oneM2M supports the hosted CSE to perform batch notifications when the batchNotify attribute is used, where the hosted CSE can send multiple notifications to the same notificationURI in one message. Summary of the invention

[0019] In the M2M / IoT domain, resource subscription provides a mechanism to receive automatic notifications when changes occur on subscribed resources. Traditional M2M service layers (e.g., oneM2M) support sending subscription notifications to a list of nodes (e.g., notification targets). Subscribing entities may or may not be included as notification targets. Traditional M2M service layers do not include access to information about past notifications, which may be problematic when the subscriber is not among the notification targets. Another problem may be that the service layer also does not have contextual information about the notification targets. Based on the above issues, there may be inefficiencies, such as sending unnecessary notifications to unavailable or overloaded notification targets.

[0020] Methods and systems for subscription and notification services are disclosed herein. For example, the disclosed subject matter can allow for dynamically changing notification behavior based on notification target state to reduce the number of lost or unnecessary notifications, or support access to notification history information at different granularities, etc.

[0021] In a first exemplary method, the service layer records published notifications by creating a new notification resource proactively or in response to a subscriber's request. Subscribers and notification targets can access the created notification resource to obtain information about past notifications. Subscribers are also free to stop or change notification records. In a second exemplary method, the service layer maintains statistics of published notifications. Subscribers can access such notification statistics. Based on this information, subscribers can request the service layer to remove existing notification targets or add new notification targets. In a third exemplary method, for example, after a notification is issued and sent to a notification target, the service layer sends a notification confirmation message to the subscriber under certain conditions.

[0022] In a fourth exemplary method, subscribers interact directly with notification targets to request them to calculate notification statistics or send notification confirmations back to subscribers. In a fifth exemplary method, the service layer may contact notification targets before fully executing the subscription request so that the notification targets are aware of the subscribers and the corresponding subscriptions. In addition, the notification targets may actively or passively report their contextual state information to the service layer so that the service layer is aware of its latest state and can determine an efficient way to send future notifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] A more detailed understanding may be obtained through the following description given by way of example in conjunction with the accompanying drawings, in which:

[0024] Figure 1 An exemplary IP network stack with a service layer is shown;

[0025] Figure 2 An exemplary Common Services Entity (CSE) and Common Services Function (CSF) are shown;

[0026] Figure 3 An exemplary oneM2M service layer functional architecture (ROA) is shown;

[0027] Figure 4 An exemplary method according to the oneM2M specification is shown, wherein IN-AE1 subscribes to resources on IN-CSE;

[0028] Figure 5 An exemplary system for a smart healthcare use case is shown;

[0029] Figure 6 An overview of an exemplary method discussed herein is shown, for example, wherein a subscriber first indicates its requirements for a service layer to log notifications, calculate notification statistics, and acknowledge notifications during a subscription request;

[0030] Figure 7 An exemplary overview of a method for subscription and notification services is shown;

[0031] Figure 8 An exemplary method for recording and accessing information about past notifications is shown;

[0032] Fig. 9 An exemplary method of stopping or changing a notification log is shown;

[0033] Fig.10 An exemplary method for maintaining and accessing notification statistics is shown;

[0034] Fig.11 An exemplary method for sending a notification confirmation from a service layer to a subscriber is shown;

[0035] Fig.12 An exemplary method in which a subscriber directly requests a notification target to calculate notification statistics is shown;

[0036] Fig.13 An exemplary method for a subscriber to request a notification confirmation from a notification target is shown;

[0037] Fig.14 An exemplary method for achieving awareness between notification targets and subscribers and between notification targets and service layers is shown;

[0038] Fig.15 An exemplary enhanced subscription and notification (eSUB) CSF is shown;

[0039] Fig.16 An exemplary <notification>resource;

[0040] Fig.17 An exemplary <notiftarget>resource;

[0041] Fig.18 An exemplary user interface is shown;

[0042] Fig.19 shows an exemplary display (e.g., a graphical user interface) that may be generated based on the methods and systems discussed herein;

[0043] Fig. 20A is a system diagram of an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which the disclosed subject matter may be implemented;

[0044] Fig. 20B Yes, you can Fig. 20A A system diagram of an example architecture used within an M2M / IoT communication system as shown in;

[0045] Fig. 20C Yes, you can Fig. 20A A system diagram of an example M2M / IoT terminal or gateway device used within the communication system shown in ; and

[0046] Fig.20D It can be reflected in Fig. 20A A block diagram of an example computing system that illustrates aspects of a communication system. DETAILED DESCRIPTION

[0047] Mechanisms for subscription and notification are disclosed herein, which may include: dynamically changing notification behavior based on notification target state to reduce the number of lost or unnecessary notifications or supporting access to notification history information at different granularities, etc. The disclosed subscription and notification services may have an impact on subscribers, service layers, or notification targets. As discussed herein, resource subscription and notification mechanisms in traditional M2M service layers (e.g., oneM2M) have problems such as: 1) subscribers or notification targets have no way or in an inefficient way to access information about notifications generated in the past; or 2) notification targets are unaware of subscriptions, and the service layer is unaware of the contextual information of notification targets. These problems may result in unnecessary notifications and make resource subscription and notification mechanisms inefficient. In one example, a notification may be a message generated by the M2M service layer when a subscribed resource that meets the event notification criteria changes; the notification message is sent to subscribers or notification targets to notify them of the change.

[0048] Figure 5 A smart healthcare scenario is shown, where health data from a patient's body sensors 151 are collected. The health data may be uploaded to an M2M server 153 (or alternatively, stored locally on a mobile device 152 associated with the patient), which may be referred to as a hosting node. Through device 155, the patient's guardian may subscribe 160 to the health data so that the patient's doctors, caregivers, relatives, insurance companies, and other related devices (devices 156, 157, 158, and 159, respectively) that are notification targets receive automatic notifications 161 about changes in the patient's health data. For example, if the patient is currently receiving treatment at home, a sudden increase in the patient's heart rate may be something that is critical for the doctor to know.

[0049] In this smart healthcare scenario, there may be the following requirements for resource subscription and notification: 1) Requirement (Req) 1: Verify that notifications are sent by the M2M server 153 and received by the notification target (e.g., devices 156-159) whenever an event of interest occurs (the guardian-device 155 may request this requirement); 2) Requirement 2: The amount of notifications sent to each notification target and successfully received by each notification target (the guardian-device 155 may request this requirement); 3) Requirement 3: Do not cause the device 156 (e.g., doctor's device) to lose any notifications when the notification target is not connected to the Internet or the M2M server 153; 4) Requirement 4: Receive notifications about patients (or even some selected patients), no other unknown patients or individuals (e.g., may only apply to doctor's devices); 5) Req5: It is expected that each sent notification is received by the notification target (this can be requested by the M2M server 153). Req5 may be required because if every notification is not received, bandwidth may be wasted, resulting in overhead, and significantly affecting the usefulness of the notification.

[0050] oneM2M as a service layer technology has limited capabilities in supporting requirements such as the above five requirements in healthcare scenarios. For example, in traditional oneM2M, subscribers such as AEs do not know whether the notification target has issued and successfully received the notification. In addition, regardless of which subscriber the subscription comes from, the notification target in traditional oneM2M passively receives notifications (e.g., response messages) from the service layer.

[0051] The subscription or notification mechanism in the traditional M2M service layer (e.g., oneM2M) may have the following problems. The first problem may be that although the M2M service layer (e.g., M2M server 153) can automatically generate notifications, it does not provide any access to information about notifications issued in the past to the subscriber (e.g., device 155) or the notification target (e.g., device 156). The inability to access past notifications may be a problem because the subscriber (e.g., device 155) may want to know whether all or selected notification targets have indeed issued and received the emergency notification; in addition, the offline notification target (e.g., device 156) may want to know and obtain any missing notifications after it becomes online. For example, in a smart healthcare scenario, device 155 wants to know whether device 156 has successfully received the notification about the patient's sudden heart rate increase. This first problem is related to the above requirements of Req1-Req3.

[0052] A second problem may be that the M2M service layer is unaware of contextual information about the notification targets (e.g., their availability, their new IP addresses, etc.). For example, such ignorance may result in unnecessary notifications from the M2M service layer to overloaded notification targets. This second problem relates to the above requirements of Req3-Req5.

[0053] It should be understood that executing Figure 6-Figure 14 The entities of the steps shown in this article can be logical entities. These steps can be stored in such as Fig. 20C or Fig.20D In one example, further details about the interaction of M2M devices are used below. Figure 6-Figure 14 The subscriber 173 or notification target 175 may reside in Fig. 20A On the M2M terminal device 18, Figure 6-Figure 14 The service layer 171 may reside on Fig. 20A On the M2M gateway device 14.

[0054] The following discusses different means for subscribers and notification targets to access information about past notifications and methods to support notification target status awareness. Figure 6 An overview of an exemplary method associated with the first question is shown. At step 181, a service layer 171 (e.g., an M2M server 153) may receive a subscription request from a subscriber 173 (e.g., a guardian-device 155). The subscription request 181 may indicate a requirement for the service layer 171 to record notifications, maintain notification statistics, and confirm notifications about a notification target 175 (e.g., a doctor-device 156). At step 182, the service layer 171 receives an indication of an event. At step 183, which may be responsive to step 182, the service layer 171 sends a notification to the notification target 175. Steps 184 to 185 (which will be discussed in more detail herein) involve service layer actions based on the requirements from the subscriber 173 sent in step 181. At step 184, there is a record of notifications. At step 185, statistics associated with the notifications are calculated. At step 186, the notification sent to the subscriber 173 is confirmed. At step 187 or step 188, past notifications or notification statistics are accessed from the subscriber 173 or notification target 175, respectively.

[0055] Continue to refer Figure 6 In summary, the methods discussed herein may include where the subscriber 173 first indicates its requirement for the service layer to log notifications, calculate notification statistics, and confirm notifications during a subscription request. When an event occurs, the service layer 171 may take an action (e.g., log a notification), and a notification message is sent. If the service layer 171 logs notifications or maintains notification statistics, the subscriber 173 or notification target 175 may actively access them.

[0056] In a fifth method, the subscriber 171 directly requests the notification target 175 to calculate notification statistics or send notification confirmations when it receives one or more notification messages from the service layer 171 . Figure 7 An exemplary summary of the method flow is shown. Subscriber 173 first indicates its requirement for subscription confirmation according to which service layer 171 will contact notification target 175 to confirm the subscription request from the subscriber (step 191); this makes the notification target 175 aware of the subscription (step 192). In step 192, service layer 171 receives an indication of the event. In step 193, which can be responsive to step 182, service layer 171 sends a notification to notification target 175. Notification target 175 can then report its status or context information to service layer 171, which can be included in the response message (step 195) or in a separate message (step 196); this (step 195 or step 196) enables service layer 171 to know the status of notification target 175.

[0057] References Figure 6 In the method associated with step 184 of , although the hosted CSE in oneM2M can cache the lost notifications, the hosted CSE does not expose them to the subscriber 173 or the notification target 175, so the subscriber 173 or the notification target 175 is not aware that the notification has been lost. In other words, the subscriber 173 or the notification target 175 may not actively retrieve or delete the lost notifications from the hosted CSE in the traditional oneM2M system.

[0058] References Figure 6 In the method associated with step 185, oneM2M does not support calculating and exposing notification statistics to the user 173 or notification target 175. Figure 6 In the method associated with step 186, oneM2M does not support sending notification confirmation to subscriber 173. Conventional oneM2M does not support direct interaction between subscriber 173 or notification target 175. In addition, reference Figure 7 , conventional oneM2M does not support recognition between subscribers 173 or notification targets 175 .

[0059] Methods for accessing information associated with notifications are discussed below. A subscriber 173 or a notification target 175 may want to access information about previous notifications for a variety of purposes. The methods here can work independently or work together for services associated with subscriptions and notifications.

[0060] Figure 8 An exemplary method for recording and accessing information about past notifications is shown. In summary, for this method, the service layer 171 can actively record each published notification for later retrieval by the subscriber 173 and the notification target 175. Alternatively, the subscriber 173 can request the service layer 171 to record the selected notification (e.g., record all notifications to a specific notification target 175, record a list of notification targets that have successfully received the notification message). It can generally work in the following manner. First, the subscriber 173 indicates its requirement for recording notifications in a subscription request. Subsequently, whenever the service layer 171 issues a notification, the service layer 171 determines whether the notification needs to be recorded based on the requirements from the subscriber 173. If the answer is yes, the service layer 171 creates a new resource for recording the notification. The new resource can be called a notification resource. The notification resource has some attributes about the published notification (e.g., its generation time, its generation conditions, a reference to the corresponding subscription, a list of notification targets that have successfully received the notification, etc.). Finally, the subscriber 173 or the notification target 175 can access this notification resource created and maintained by the service layer 171. The service layer 171 may use specific access control policies to authorize whether subscribers 173, notification targets 175, or other service layer entities can access these notification resources. For subscribers 173, access to notification resources may allow them to know how many notifications have been issued and successfully received by notification targets 175. For notification targets 175, the features provided by the service layer 171 provide notification targets 175 with an opportunity to later retrieve lost notifications when notification targets 175 are offline or unavailable (e.g., notification targets 175 become unreachable due to changes in their addresses or loss of connection with the service layer 171). In addition, after retrieving and knowing information about past notifications, if subscribers 173 do not receive notifications within a period of time, subscribers 173 may send a request to the service layer 171 to remove notification targets 175 so that the service layer 171 does not send more notifications in the future, which may avoid or reduce unnecessary notifications. In addition, subscribers 173 may send request messages to the service layer 171 to stop logging notifications or change how notifications should be logged.

[0061] Continue to refer Figure 8 , the following is an exemplary step-by-step discussion for recording and accessing information about past notifications. In step 201, subscriber 171 may send a subscription request message to service layer 171. In addition to information such as event notification criteria, the message may contain a composite parameter "notifRecordReq", which is composed of several other parameters or fields. The composite parameter includes multiple fields - each field is a parameter, as defined and shown in Table 1. The parameter can tell service layer 171 when, how, or which published notifications should be recorded. Table 1 defines "notifRecordReq". For example, subscriber 173 may update its resource subscription with service layer 171 after step 203. In such resource subscription update, subscriber 173 may also include "notifRecordReq". Whenever service layer 171 receives a new "notifRecordReq", service layer 171 can be used to determine future notifications to be recorded. If subscriber 173 does not provide enough information about notification recording requirements, service layer 171 may decide to record the notification based on its local policy. In step 202, the service layer 171 may accept the request and create a subscription resource accordingly. In step 203, the service layer 171 sends a response to the subscriber 173 to notify it of the created subscription resource. In step 204, an event occurs, which satisfies the event notification criteria provided in step 201.

[0062] Continue to refer Figure 8 In step 205, the service layer 171 issues a notification message, which is sent to the notification target 175. In step 206, the notification target 175 sends back a response. In step 206, based on the information associated with the "notifRecordReq" of step 201, the service layer 171 determines whether to create a new notification resource to record the notification message sent in step 206. For example, if notifRecordReq requires that each notification message be recorded, the service layer 171 can create a notification resource for any published notification. Each created notification resource may have attributes, such as the time when the notification message is published, the notification condition that triggers the notification message, the subscription resource associated with the notification message, the list of notification targets 175 that have successfully received the notification message, or the list of notification targets 175 that have lost the notification message, and so on. Each created notification resource may have an expiration time; when the expiration time expires, the created notification resource will be automatically deleted. Once a notification resource is created, it can be retrieved by a subscriber or a notification target. For example, Figure 8 Step 208 in FIG. 1 shows that the notification target 175 retrieves the created notification resource.

[0063] exist Figure 8 In step 208, assuming, for example, that the notification target 175 is offline for a period of time, when the notification target 175 is back online, it can actively retrieve any missing notifications from the service layer 171. Since the notification target 175 may not know whether there is a notification resource being created, it can only send a resource discovery request to the service layer 171 to ask, for example, whether a notification has been published for it (the notification target 175) in the past time interval. If the notification target is offline and does not receive step 205, it does not know whether the notification resource has been created in step 207. The notification target 175 can also provide additional discovery criteria (for example, discover any notification messages that have been published but not successfully received, which are triggered by a specific notification condition). In step 209, the service layer 171 can send a response message to the notification target 175. The response message may contain multiple notification messages that have been published but have not been successfully received by the notification target 175, or a list of notification messages that meet the discovery criteria indicated by the notification target 175 in step 208. In step 210, the subscriber 173 sends a request to actively retrieve (or delete) the notification resource created by the service layer 171. This step is similar to step 208. The difference is that in step 210, the subscriber 173 can request to delete the notification resource to reduce the storage at the service layer 171 after the subscriber 173 discovers the notification resource from the service layer 171 and under some conditions (for example, the corresponding notification message is successfully received by all or preferred notification targets 175). In step 211, the service layer 171 sends a response to the subscriber 173. If the request in step 210 is to retrieve the notification resource, step 211 will be similar to step 209, and the response may contain multiple notification messages. If the request in step 210 is to delete the notification resource, the response in step 211 may only notify the result of the deletion request (for example, approval or rejection).

[0064] Table 1. Composite parameters notifRecordReq

[0065]

[0066]

[0067] Figure 8 173 can request the service layer 171 to log notifications. Subscriber 173 can also request the service layer 171 to stop or change notification logging, such as Fig. 9 As shown. It is understood that other entities can also request to stop or change the notification record when they have access rights. There may be different reasons for limiting access, such as certain privacy issues.

[0068] Continue to refer Fig. 9 , in step 221, subscriber 173 sends a request message to service layer 171 to stop recording notifications. The message may simply indicate the corresponding or associated subscription. Alternatively, subscriber 173 may include a parameter, such as an invalid notifRecordTimeDuration, as part of notifRecordReq (e.g., [-20, -10]) in the message indicating to stop recording notifications. In step 222, service layer 171 sends a response to subscriber 173 indicating whether the request in step 221 is approved or rejected. In step 223, subscriber 173 may also send a request message to service layer 171 to change how future notifications should be recorded. The message may contain a new value for the parameter "notifRecordReq". If notification recording was previously stopped, the request at step 223 may indirectly resume notification recording. The recorded notification resources may be actively deleted by subscriber 173 or expire because each notification resource has an associated expiration time. In step 224, service layer 171 sends a response to subscriber 173, the response indicating whether the request in step 223 is approved or denied.

[0069] The following discusses methods and systems for maintaining notification statistics at the service layer 171. The service layer 171 can maintain statistics about past notifications issued during a time window instead of each individual notification. Note that the time window can be a real-time window based on the time when the notification message is published, or a virtual time window that only contains a fixed number of notification messages. Examples of statistical information can include the average number of notifications published in the time window, the number of notifications successfully received by the notification target 175 in the time window, the maximum number of consecutive unsuccessful notifications of the notification target 175 in the time window, or the number of unsuccessful notification attempts of a particular notification target 175, etc. The subscriber 173 can request that the service layer 171 calculate one or more parameters of the notification statistics during the subscription request. Then, the service layer 171 can continue to recalculate the notification statistics whenever a new notification is issued and sent to the notification target 175. Once service layer 171 generates notification statistics, subscriber 173 can retrieve it and based on the notification statistics, it can decide to remove notification targets 175 (e.g., if notification targets 175 have lost all or a high percentage of recently sent notifications) or add new notification targets 175 (e.g., if all or a high percentage of notification targets 175 cannot receive any notifications). In this way, a separate request message will be sent from subscriber 173 to service layer 171 to adjust (remove or add) notification targets 175. In another example, service layer 171 can perform a one-time on-demand calculation of notification statistics for a specific subscription based on a request from subscriber 173 or other entity; if requests for notification statistics are very rare, such on-demand notification statistics calculation may be more efficient.

[0070] Fig.10 An exemplary method for maintaining and accessing notification statistics is shown. In step 231, subscriber 173 sends a subscription request message to service layer 171. The request of step 231 may include information such as event notification criteria and a parameter "notifStatReq". The notifStatReq parameter may include instructions for notification statistics to be calculated or maintained. Table 2 defines notifStatReq. Subscriber 173 may update its resource subscription through service layer 171 after step 233. In the resource subscription update, subscriber 173 may include "notifStatReq", even if it is included in step 231. Whenever service layer 171 receives a new "notifStatReq", service layer 171 will use it to calculate future notification statistics. In step 232, service layer 171 accepts the request and creates the subscription resource accordingly. In step 233, service layer 171 sends a response to subscriber 173, which provides information about the creation of the subscription resource. The response message may also include the address of “notifStatInfo”, although it will be (re)calculated in step 237 , so that subscriber 173 can directly retrieve “notifStatInfo” using this address in step 238 .

[0071] In step 234, an event occurs that meets the event notification criteria provided in step 231. In step 235, the service layer 171 sends a notification message to the notification target 175. In step 236, the notification target 175 sends a response back. In step 237, the service layer 171 (re)calculates the notification statistics according to the requirements of the subscriber 173 indicated by the parameter "notifStatReq". The calculated notification statistics are maintained in a new parameter "notifStatInfo", which can be created as a new resource or added as a new attribute to the subscription resource created in step 232. Alternatively, the service layer 171 can maintain all calculated notification statistics, not just the latest ones, for example if it has enough storage.

[0072] In step 238, subscriber 173 retrieves (or discovers if it does not know the address of "notifStatInfo") "notifStatInfo" from service layer 171. In step 239, service layer 171 sends a response back to subscriber 173 (e.g., the value of "notifStatInfo"). In step 240, subscriber 173 may decide to remove or add any notification targets 175 based on the notification statistics. In an example, subscriber 173 may decide to remove a notification target 175 if the notification target 175 has lost all or a threshold percentage of notifications issued within the current time window. In another example, a new notification target 175 may be added if all or a threshold percentage of notification targets fail to receive any notifications within the current time window. In step 241, subscriber 173 may send a request to service layer 171 to adjust (e.g., remove, add, or otherwise adjust) notification targets 175 based on the decision made in step 240. In step 242, service layer 171 sends a result (e.g., accept or reject the adjustment) to subscriber 173.

[0073] Table 2. Definition of notifStatReq

[0074]

[0075] Discussed below is notification confirmation from the service layer 171 to the subscriber 173. In addition to recording notifications or calculating notification statistics, another approach is to allow the subscriber 173 to access information about past notifications. When a notification is sent to one or all notification targets, the service layer 171 can proactively send a notification confirmation to the subscriber 173. Basically, after the notification target 175 successfully receives the notification message, the service layer 171 can send a notification confirmation message to the subscriber 173 to notify it of the notification message. If there are multiple notification targets, the same notification message can be sent multiple times. In order to reduce the number of notification confirmation messages, the service layer 171 can send only one notification confirmation message to the subscriber 173 after sending the same notification message to all notification targets. In addition, when a certain number of notification messages have been sent to one or all notification targets, the subscriber 173 can request the service layer 171 to send a notification confirmation message. Similar to the above method, the subscriber 173 can adjust (e.g., remove, add, or otherwise adjust) the notification target based on the information from the notification confirmation.

[0076] Fig.11 An exemplary method for sending notification confirmation from service layer 171 to subscriber 173 is shown. In step 251, subscriber 173 sends a subscription request message to service layer 171. In addition to information such as event notification criteria, the message of step 251 may include: a parameter "notifConfirmReq". The notifConfirmReq parameter tells service layer 171 which notifications should be confirmed with subscriber 173. Table 3 defines this composite parameter. Subscriber 173 may update its resource subscription with service layer 171 after step 253. In the resource subscription update, subscriber 173 may also include "notifConfirmReq", even if it is included in step 251. Whenever service layer 171 receives a new "notifConfirmReq", service layer 171 may use it to confirm future notifications. In step 252, service layer 171 accepts the request and creates the subscription resource accordingly. In step 253, service layer 171 sends a response to subscriber 173 to notify it of the created subscription resource.

[0077] refer to Fig.11 , in step 254, an event occurs that satisfies the event notification criteria contained in step 251. In step 255, service layer 171 sends a notification message to notification target 175. In step 256, notification target 175 sends back a response that informs service layer 171 that the notification in step 255 was successfully received. In step 257, service layer 171 stores the notification message and determines whether a notification confirmation needs to be sent to subscriber 173 based on "notifConfirmReq". In step 258, service layer 171 sends a notification confirmation message to subscriber 173. The message may contain one or more notification messages that have been successfully sent to the notification target.

[0078] At step 259, subscriber 173 sends a response back to service layer 171; the response at step 259 simply tells service layer 171 that the notification confirmation of step 258 was successfully received. At step 260, subscriber 173 may decide to remove or add notification targets 175. In the example of removing notification targets 175, notification targets 175 may be removed if notification targets 175 have lost all or a threshold percentage of notifications sent within a time window. In the example of adding notification targets 175, notification targets 175 may be added if all or a high percentage of other notification targets cannot receive any notifications within the current time window. At step 261, subscriber 173 sends a request to service layer 171 to adjust the notification targets based on the decision made in step 260. At step 262, service layer 171 sends the result (e.g., accept or reject the adjustment) to subscriber 173.

[0079] Table 3. Definition of notifConfirmReq

[0080]

[0081]

[0082] The previous approach introduces new features to the service layer 171 and relies on it to provide access to information about notifications to the subscriber 173 or notification target. The following discloses direct interactions between the subscriber and the notification target. These interactions can be considered application-level interactions because the subscriber 173 and the notification target will be applications in most cases. However, this alternative approach may not help the service layer 171 avoid sending unnecessary notifications, and may not provide instructions for the notification target 175 to retrieve lost notifications. The direct interaction between the subscriber 173 and the notification target 175 may include: 1) the subscriber 173 requests the notification target 175 to calculate statistics about the notifications it receives from the service layer 171, and the calculated statistics may be actively reported back to the subscriber 173 or passively reported waiting for the subscriber 173 to retrieve; and, 2) the subscriber 173 requests the notification target 175 to send a notification confirmation for each or more notifications it receives from the service layer 171.

[0083] Fig.12 An exemplary method is shown in which a subscriber 173 directly requests a notification target 175 to calculate notification statistics. In step 270, it is assumed that a subscription request has been completed between the subscriber 173 and the service layer 171. In step 271, the subscriber 173 sends a request message to the notification target 175 to inform it which notification statistics need to be calculated. In the message, a parameter notifStatReq is included to indicate the subscriber 173's requirement for notification statistics calculation. notifStatReq is defined in Table 2. In step 271, the notification target 175 sends a response back to the subscriber 173. In the message of step 271, the notification target 175 may include the URI of the notification statistics to be calculated in step 274, so that the subscriber 173 can actively retrieve the notification statistics later (for example, in step 277). In step 273, when an event of interest occurs on the subscribed resource at the service layer 171, the service layer 171 sends a notification message to the notification target 175.

[0084] In step 274, the notification target 175 (re)computes the notification statistics according to the notifStatReq received in step 271. The computed notification statistics may be stored in a composite parameter or placeholder, called "notifStatInfo". In step 275, the notification target 175 reports the computed statistics to the subscriber 173. In the message, the notification target 175 may include a URI for the notification statistics so that the subscriber 173 may later actively retrieve the notification statistics (e.g., in step 277).

[0085] Continue to refer Fig.12 In step 276, subscriber 173 sends a response as confirmation back to notification target 175. In step 277, subscriber 173 actively retrieves notification statistics from notification target 175 using the URI of the notification statistics obtained from step 272 or step 275. In step 277, notification target 175 sends a response back to subscriber 173.

[0086] Fig.13 An exemplary method for a subscriber 173 to request a notification confirmation from a notification target 175 is shown. The main idea is that once the notification target 175 receives one or more notification messages from the service layer 171, it will send a notification confirmation message to the subscriber 173. In step 280, it is assumed that the subscription request has been completed between the subscriber 173 and the service layer 171. In step 281, the subscriber 173 sends a message to the notification target 175, requesting it to send back a notification confirmation when it receives a notification message from the service layer 171. The message may include a parameter notifConfirmReq to indicate the subscriber 173's requirement for notification confirmation. notifConfirmReq has been defined in Table 3. For this example, there is one notification target 175, and the "listOfNotifTargetsForConfirm" field of notifConfirmReq will be the notification target 175 that receives the message in this step. In step 282, the notification target 175 sends a response message to the subscriber 173 as a confirmation. At step 283, when an event of interest occurs to a subscribed resource at service layer 171, service layer 171 sends a notification message (e.g., an event notification message) to notification target 175. At step 284, notification target 175 sends a notification confirmation to subscriber 173. This message may be similar to Fig.11 The notification target 175 may send this message after it receives a notification or notifications from the service layer 171, which notification is specified in the received parameter notifConfirmReq. In step 285, the subscriber 173 sends a response back to the notification target 175 as a confirmation.

[0087] The problem described here is that the service layer 171 is unaware of the state of the notification targets. The following discloses methods and systems associated with keeping the service layer 171 aware. In summary, first, after receiving a new subscription request from the subscriber 173, the service layer 171 checks the corresponding notification targets and makes them aware of this new subscription to be created; during this process, the notification target 175 can ask the service layer 171 to remove it from the new subscription or indicate how the service layer 171 should appropriately send notifications to it. This helps to solve the lack of knowledge of the notification targets 175 about the subscription. Secondly, after creating a new subscription, the notification targets can actively report their status (e.g., availability, expected notification rate, etc.) to the service layer 171 and piggyback their status in the response message to the service layer 171; in turn, the service layer 171 can adjust how future notifications should be sent based on the latest status of the notification targets.

[0088] Fig.14 An exemplary method for enabling awareness between notification targets and subscribers 173 and between notification targets and service layer 171 is shown. In step 291, subscriber 173 sends a subscription request message to service layer 171. In addition to information such as notification (e.g., event notification) criteria, the message may include a parameter "subConfirmReq". The subConfirmReq parameter tells the service layer 171 which notification target 175 should be contacted to confirm the subscription request. Table 4 defines subConfirmReq. In step 292, if the subConfirmType in subConfirmReq is not equal to zero, the service layer 171 sends a subscription confirmation message to the corresponding notification target. The message may include the following parameters or only the subscription request message in step 291: 1) the address or identifier of the subscriber 173; 2) the address or identifier of the subscription resource; 3) the address of the notification target 175 to receive notifications; or 4) the event notification criteria.

[0089] In step 293, the notification target 175 sends a response back to the service layer 171. If the notification target 175 is unwilling to receive notifications for the subscription, it can request the service layer 171 to remove it from the notification target list provided by the subscriber 173 in step 291. In addition, the notification target 175 can also piggyback its current status (e.g., "notifTargetStatus") in its response message. "notifTargetStatus" may include the following contextual information about the notification target 175: 1) the new network (e.g., IP) address of the notification target 175 for receiving future notifications; 2) the maximum allowed notification arrival rate (e.g., 2 notifications / second); or 3) schedule information for the notification target 175 (e.g., will be available in the next 30 days, will be unavailable in the next 2 days, etc.). In step 294, the service layer creates the subscription resource. In step 295, the service layer 171 sends a response to the subscriber 173 to notify it of the created subscription resource. If the notification target 175 requested to be removed during step 293, the service layer 171 may include the address or identifier of the notification target 175 in step 295. In step 296, an event occurs that satisfies the event notification criteria included in step 291. In step 297, the service layer 171 sends a notification message to the notification target 175. Note that if the notification target 175 indicated a "maximum notification rate allowed" in step 293, the service layer 171 may not send the notification message to it if the "maximum notification rate allowed" is violated. Also note that if the notification is the first notification issued to the notification target 175, the subscription confirmation message in step 292 may alternatively be included in step 297. In this case, steps 292 and 293 may be skipped.

[0090] Continue to refer Fig.14 , in step 298, the notification target 175 sends back a response, which may include notification target 175 status information (e.g., notifTargetStatus). In step 299, the status of the notification target 175 may change. For example, the address it previously used to receive notifications becomes unavailable. In step 300, the notification target 175 updates the service layer 171 about its new status. The message includes "notifTargetStatus". Step 300 can be considered active and step 298 can be considered passive. Step 298 is the result of receiving step 297, while step 300 can occur at almost any time. In step 301, the service layer 171 sends a response back to the notification target 175. In step 302, the service layer maintains the status of each notification target 175 and adjusts how notifications are sent to them in the future accordingly.

[0091] Table 4. Definition of subConfirmReq

[0092]

[0093] The following is an example for implementing the oneM2M architecture method for subscription and notification, as disclosed herein.

[0094] Fig.15 An exemplary CSF is shown for implementing a method for subscription and notification services for a traditional oneM2M SUB CSF to form an enhanced subscription and notification (eSUB) CSF 305 based on the traditional oneM2M functional architecture. The eSUB supports the procedures and processing between the service layer 171, the subscriber 173, and the notification target 175 as described herein. The eSub may reside in an IN-CSE, an MN-CSE, or an ASN-CSE. Resources and procedures related to the service layer 171 may be implemented in a CSE, and the subscriber 173 may be an AE or a CSE (e.g., respectively). Fig. 20A M2M terminal equipment 18 and Fig. 20A Gateway device 14).

[0095] The following are deployment examples. For the logging notification at the service layer method, the service layer 171 can be a CSE (e.g., IN-CSE) and the subscriber 173 can be an AE (e.g., IN-AE) or a CSE (e.g., ASN-CSE). For the method based on maintaining notification statistics at the service layer, the service layer 171 can be a CSE (e.g., MN-CSE) and the subscriber 173 can be an AE (e.g., ADN-AE). For the method based on notification confirmation from the service layer, the service layer can be a CSE (e.g., IN-CSE) and the subscriber 173 can be an AE (e.g., IN-AE). For the method based on notification target state awareness, the service layer 171 can be a CSE (e.g., IN-CSE) and the subscriber 173 can be an AE (e.g., IN-AE) or a CSE (e.g., MN-CSE). As disclosed herein, the method for notification target awareness (e.g., Fig.14 ) may include obtaining a first subscription request from a subscriber to receive event notifications of a resource by a subscriber device, the first subscription request including a first parameter, which tells which notification target should be contacted to confirm the first subscription request; based on the first subscription request, sending a message to the notification target, the message including an identifier of the subscriber, an identifier of the subscription resource, an identifier of the notification target to receive the notification or an event notification standard; and generating a resource based on the first subscription request to record the notification message.

[0096] like Fig.16 As shown, to support the methods discussed here, new resources are disclosed ( <notification>307). When a notification message is published and sent to the notification target 175 (or created in other cases depending on the parameter notifRecordReq), the service layer 171 can automatically create <notification>Resource 307. Once created <notification>Resource 307, it can be retrieved by subscriber 173 or notification target. Subscriber 173 can also delete <notification>307 messages.

[0097] [notification] Resource 307 has several new attributes, such as Fig.16 As shown in and described in Table 5. Note that <notification>307 can also be implemented as oneM2M <flexcontainer>or <container>The type of resource; thus, Fig.16 As shown in <notification>The 307 attribute can be introduced as <flexcontainer>or <container>The new properties of . <notification>Resources 307 can be placed in a variety of locations (e.g., <subscription>subresources of a resource, <ae>subresources of a resource, <remotecse>resource, etc.). <notification>307 placed in <subscription>When it is a sub-resource under a resource, <notification>307 The actual record is this <subscription>Notification message generated by the resource. <notification>307 placed in <ae>resource as its sub-resource and the <ae>The resource is subscriber 173, in this case <notification>Resource 307 represents the <ae>Generated <subscription>Notification message for the resource.

[0098] Table 5. New <notification>Resource properties

[0099]

[0100] As previously described, the service layer 171 may automatically create a Notify message when it is sent out or upon request of the subscriber 173 as indicated by the notifRecordReq parameter during a subscription request. <notification>Resources. Create <notification>After the resource is created, it can be retrieved by the subscriber 173 or notification target 175, or deleted by the subscriber 173. <notification>The allowed operations for the resource.

[0101] Table 6. <notification>Allowed operations on resources

[0102]

[0103] Based on the requirements from the subscriber 173 (e.g., the notifRecordReq parameter submitted during the subscription request), the service layer 171 (e.g., CSE) automatically determines to create a new record when it issues a notification to the notification target 175. <notification>Message. When creating <notification>When creating a resource, the service layer 171 will generate all its attributes listed in Table 5.

[0104] This process can be used to retrieve <notification>Attributes of the resource (eg, by the subscriber 173 or notification target). The general retrieval process is described in section 10.1.2 of 10.1M-TS-0001, oneM2M functional architecture, V-2.6.0 (hereinafter referred to as the oneM2M functional architecture).

[0105] Table 7. <notification>RETRIEVE

[0106]

[0107]

[0108] Subscribers 173 can use <notification>DELETE method to remove <notification>Resources. The generic deletion procedure is described in section 10.1.4.1 of the oneM2M functional architecture.

[0109] Table 8. <notification>DELETE

[0110]

[0111] like Fig.18 As shown, a new resource is disclosed ( <notiftarget>315) to maintain state information about each notification target 175. A subscriber 173 or a notification target can request to create a <notiftarget>Resource 315 (eg, hosting corresponding <subscription>Once created, <notiftarget>Resource 315, which can be retrieved / updated / deleted by subscriber 173 or notification target (even other AE and CSE).

[0112] <notiftarget>Resource 315 has several new attributes, such as Fig.17 and described in Table 9, and it can be placed in various places (e.g., a subresource of a <Subscription> resource, <ae>subresources of a resource, <remotecse>resource, etc.). <notiftarget>315 is placed <subscription>When it is a sub-resource under a resource, <notiftarget>315 means <subscription>Resource associated notification target 175. <notiftarget>315 placed in <ae>resource as its sub-resource and the <ae>When the resource is subscriber 173, <notiftarget>Resource 315 represents the <ae>Subscriber 173 <subscription>Resource associated notification target 175.

[0113] Table 9. New <notiftarget>Resource properties

[0114]

[0115]

[0116] for <notiftarget>Resources, allowing operations including CREATE, RETRIEVE, UPDATE, and DELETE to implement the disclosed interactions between subscribers 173, service layer 171, and notification targets, as summarized in Table 10.

[0117] Table 10. <notiftarget>Allowed operations on resources

[0118]

[0119] Create <notiftarget>Can be used to create <notiftarget>resource.

[0120] Table 11. <notiftarget>CREATE

[0121]

[0122] Retrieve <notiftarget>Can be used to search <notiftarget>Attributes of a resource (eg, by a subscriber 173 or a notification target 175). The generic retrieval process is described in section 10.1.2 of the oneM2M functional architecture.

[0123] Table 12. <notiftarget>RETRIEVE

[0124]

[0125]

[0126] Update <notiftarget>Available for update <notiftarget>The properties and actual data of the resource.

[0127] Table 13. <notiftarget>UPDATE

[0128]

[0129]

[0130] Delete <notiftarget>Can be used to delete <notiftarget>Resources. The generic deletion procedure is described in section 10.1.4.1 of the oneM2M functional architecture.

[0131] Table 14. <notiftarget>DELETE

[0132]

[0133] The existing oneM2M can be extended by adding several new attributes as described in Table 15. <subscription>Resources to support the disclosed subscription and notification methods and systems. Note that <notiftarget>and <notification>Can be added for <subscription>Alternatively, these new attributes can be added as new sub-resources of the existing oneM2M <notificationtargetpolicy>A new attribute or a new subresource of a resource.

[0134] Table 15. <subscription>New properties for resources

[0135]

[0136] The status (e.g., availability) of a notification target 175 captured in the notifTargetStatus attribute (Table 15) may be maintained through an UPDATE operation by the subscribing hosting CSE, subscriber, or any other entity with access control rights (including the notification target 175 itself). The additional mechanism for a notification target 175 to update its status (i.e., the notifTargetStatus attribute) uses the following new virtual resource (proposed as <subscription>resource). These mechanisms may be alternatives to each other or may co-exist in a given implementation.

[0137] <notiftargetstatusreference>: Notification target 175 can be sent to <subscription>The virtual resource of the resource issues an UPDATE operation request with a payload containing its new state (e.g., an entry of the "notifTargetStatus" attribute in Table 15); in turn, the service layer 171 updates the <subscription>The "notifTargetStatus" property of the resource.

[0138] <notiftargetonline>:Notification target can send <subscription>The virtual resource of the resource issues an UPDATE operation request to notify the service layer 171 that it has become online; in turn, the service layer 171 marks the notification target 175 as online and available to receive notifications.

[0139] <notiftargetoffline>:Notification target can send <subscription>The virtual resource of the resource issues an UPDATE operation request to notify the service layer 171 that it has gone offline; in turn, the service layer 171 marks the notification target 175 as offline and unavailable to receive notifications.

[0140] Alternatively, existing oneM2M virtual resources can be used <notificationtargetselfreference>In other words, the notification target 175 can send a payload containing its new state to the <subscription>Resources <notificationtargetselfreference>Issue an UPDATE operation request. Therefore, the service layer 171 updates the same <subscription>The "notifTargetStatus" property of the resource.

[0141] Fig.18 An exemplary user interface is shown. From the perspective of a subscriber 173 (e.g., oneM2M AE or M2M terminal device 18), a user interface 325 can be displayed and used to configure parameters such as notifRecordReq (requirement for recording notifications), notifStatReq (requirement for calculating notification statistics), notifConfirmReq (requirement for notification confirmation), and subConfirmReq (requirement for subscription confirmation), and display results regarding notifStatInfo (calculated notification statistics) and notifTargetStatus (obtained notification target 175 status). Note that these parameters have been described and defined here. The same user interface 325 can also be added as an application to the service layer 171 (e.g., hosting CSE or M2M gateway device 14).

[0142] Fig.19 An exemplary display (e.g., a graphical user interface) that can be generated based on the methods and systems discussed herein is shown. Display interface 901 (e.g., a touch screen display) can provide text associated with the subscription and notification service in box 902, such as the values ​​of the parameters of Tables 1 to 15. In another example, the progress of any step discussed herein (e.g., a message sent or a step successful) can be displayed in box 902. In addition, graphical output 903 can be displayed on display interface 901. Graphic output 903 can be a topology of devices associated with the subscription and notification service, a graphical output of the progress of any method or system discussed herein, etc.

[0143] Fig. 20A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or World Wide Web of Things (WoT) communication system 10 in which one or more disclosed concepts associated with subscription and notification services (e.g., Figure 6-Figure 14 and accompanying discussion). In general, M2M technologies provide building blocks for IoT / WoT, and any M2M device, M2M gateway, or M2M service platform can be a component of IoT / WoT as well as an IoT / WoT service layer, etc.

[0144] like Fig. 20A As shown, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN or cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include multiple access networks that provide content such as voice, data, video, message, or broadcast to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), and single carrier FDMA (SC-FDMA). In addition, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0145] like Fig. 20A As shown, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the regional network usually behind the M2M gateway. The field domain includes an M2M gateway 14 and a terminal device 18. It is understood that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M / IoT / WoT communication system 10 as needed. Each of the M2M gateway device 14 and the M2M terminal device 18 is configured to send and receive signals via a communication network 12 or a direct radio link. The M2M gateway device 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate through an operator network such as a communication network 12 or a direct radio link. For example, the M2M device 18 can collect data and send the data to the M2M application 20 or the M2M device 18 via the communication network 12 or a direct radio link. The M2M devices 18 may also receive data from the M2M applications 20 or from the M2M devices 18. In addition, data and signals may be sent to and received from the M2M applications 20 via the M2M service layer 22, as described below. The M2M devices 18 and the gateway 14 may communicate via various networks including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio links, and wirelines.

[0146] refer to Fig. 20B , the M2M service layer 22 shown in the field domain (e.g., CSE or M2M server 153 as described herein) provides services for M2M applications 20 (e.g., guardian 155 or subscriber 173), M2M gateway devices 14, M2M terminals 18, and communication networks 12. It is understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12 as needed. The M2M service layer 22 can be implemented by one or more servers or computers, etc. The M2M service layer 22 provides service capabilities applicable to M2M terminal devices 18, M2M gateway devices 14, and M2M applications 20. The functions of the M2M service layer 22 can be implemented in various ways, such as as a web server, in a cellular core network, in the cloud, etc.

[0147] Similar to the illustrated M2M service layer 22, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12' in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateway device 14 and the M2M terminal device 18 in the field domain. It will be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateway devices, and M2M terminal devices. The M2M service layer 22' can interact with the service layer through different service providers. The M2M service layer 22' can be implemented by one or more servers, computers or virtual machines (e.g., cloud / computing / storage farms, etc.), etc.

[0148] Also refer to Fig. 20B As shown, the M2M service layers 22 and 22' provide a core set of service delivery capabilities that various applications and verticals can utilize. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Basically, these service functions relieve the application of the burden of implementing these functions, thereby simplifying application development and reducing costs and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate over various networks 12 and 12' in association with the services provided by the service layers 22 and 22'.

[0149] In some examples, the M2M applications 20 and 20' may include desired applications that communicate using subscription and notification services, as discussed herein. The M2M applications 20 and 20' may include applications in a variety of industries, such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As described above, the M2M service layer that runs across devices, gateways, and other servers of the system supports functions such as data collection, device management, security, billing, location tracking / geofencing, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0150] The method and system for subscription and notification services of the present application can be implemented as part of a service layer. The service layer is a middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying network interfaces. M2M entities (e.g., M2M functional entities such as devices, gateways, or services / platforms implemented on hardware) can provide applications or services. Both ETSIM2M and oneM2M use a service layer, which may include the method and system for subscription and notification services of the present application. The oneM2M service layer supports a set of common service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is called a common service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). In addition, the method and system for subscription and notification services of the present application can be implemented as part of an M2M network that uses a service-oriented architecture (SOA) or a resource-oriented architecture (ROA) to access services such as subscription and notification services of the present application.

[0151] As disclosed herein, a service layer may be a functional layer within a network service architecture. The service layer is typically located above an application protocol layer such as HTTP, CoAP, or MQTT, and provides value-added services to client applications. The service layer also provides an interface to the core network at lower resource layers, such as the control layer and the transport / access layer. The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standard organizations (e.g., oneM2M) have been developing an M2M service layer to address challenges associated with the integration of M2M-type devices and applications into deployments such as the Internet / Web, cellular, enterprise, and home networks. The M2M service layer may provide access to a collection or group of the above-mentioned capabilities or functions supported by the service layer to applications and various devices, which may be referred to as a CSE or SCL. Some examples include, but are not limited to, security, billing, data management, device management, discovery, provisioning, and connection management, which may be used in common by various applications. These capabilities or functions are made available to these various applications through APIs that utilize message formats, resource structures, and resource representations defined by the M2M service layer. A CSE or SCL is a functional entity that can be implemented by hardware or software, and that provides (service) capabilities or functions that are exposed to various applications or devices (i.e., functional interfaces between these functional entities) so that they use such capabilities or functions.

[0152] Fig. 20C is a system diagram of an example M2M device 30, such as an M2M terminal device 18 (which may include a subscriber 173) or an M2M gateway device 14 (which may include Figure 5 or Figure 6 one or more components of a Fig. 20C As shown, the M2M device 30 may include a processor 32, a transceiver 34, a transmit / receive element 36, a speaker / microphone 38, a keypad 40, a display / touchpad 42, a non-removable memory 44, a removable memory 46, a power supply 48, a global positioning system (GPS) chipset 50 and other peripherals 52. It should be understood that the M2M device 30 may include any sub-combination of the foregoing elements while remaining consistent with the disclosed subject matter. The M2M device 30 (e.g., the M2M server 153, the device 155, the device 156 to the device 159, the subscriber 173 and the notification target 175, etc.) may be an exemplary implementation of the disclosed system and method for subscription and notification services.

[0153] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and a state machine, etc. The processor 32 may perform signal coding, data processing, power control, input / output processing, or any other function that enables the M2M device 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit / receive element 36. Although Fig. 20C The processor 32 and the transceiver 34 are depicted as separate components, but it should be understood that the processor 32 and the transceiver 34 can be integrated together in an electronic package or chip. The processor 32 can execute application layer programs (e.g., a browser) or radio access layer (RAN) programs or communications. The processor 32 can perform security operations such as authentication, security key negotiation, or encryption operations, for example, at the access layer or application layer.

[0154] The send / receive element 36 may be configured to send or receive signals to or from the M2M service platform 22. For example, the send / receive element 36 may be an antenna configured to send or receive RF signals. The send / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, and cellular, etc. In an example, the send / receive element 36 may be a transmitter / detector configured to, for example, send or receive IR, UV, or visible light signals. In yet another example, the send / receive element 36 may be configured to send and receive RF and optical signals. It should be understood that the send / receive element 36 may be configured to send or receive any combination of wireless or wired signals.

[0155] In addition, despite Fig. 20C 30 depicts the transmit / receive element 36 as a single element, but the M2M device 30 may include any number of transmit / receive elements 36. More specifically, the M2M device 30 may employ MIMO technology. Therefore, in an example, the M2M device 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0156] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and demodulate signals received by the transmit / receive element 36. As described above, the M2M device 30 may have multi-mode functionality. Therefore, the transceiver 34 may include multiple transceivers for enabling the M2M device 30 to communicate via multiple RATs such as UTRA and IEEE 802.11.

[0157] The processor 32 may access information from and store data therein any type of suitable memory, such as a non-removable memory 44 or a removable memory 46. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other examples, the processor 32 may access information from and store data therein a memory that is not physically located on the M2M device 30, such as on a server or a home computer. The processor 32 may be configured to control a lighting pattern, image, or color on a display or indicator 42 in response to whether a subscription or notification is successful or unsuccessful (e.g., subscription) in some examples described herein, or otherwise indicate the status of a subscription and notification service and related components. The controlled lighting pattern, image, or color on the display or indicator 42 may reflect the status of the subscription and notification service and related components described herein (e.g., Figure 6-Figure 14 The states of any method flow or component in the figures shown or discussed in the examples, etc. are disclosed herein. Messages and procedures for subscription and notification services are disclosed herein. The messages and procedures may be extended to provide an interface / API for a user to request subscription and notification resources via an input source (e.g., speaker / microphone 38, keypad 40, or display / touchpad 42), and to request, configure, or query resource subscriptions and notifications that may be displayed on display 42, etc.

[0158] The processor 32 may receive power from the power source 48 and may be configured to distribute the power to other components in the M2M device 30 or to control the power. The power source 48 may be any suitable device for powering the M2M device 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li ion), etc.), solar cells, fuel cells, etc.

[0159] Processor 32 may also be coupled to GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of M2M device 30. It should be appreciated that M2M device 30 may obtain location information by any suitable location determination method while remaining consistent with the information disclosed herein.

[0160] The processor 32 may also be coupled to other peripherals 52, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripherals 52 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, (Bluetooth) modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules and Internet browsers, etc.

[0161] The transmit / receive element 36 may be embodied in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or electronic health equipment, robots, industrial equipment, drones, transportation vehicles such as cars, trucks, trains, or airplanes. The transmit / receive element 36 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 52.

[0162] Fig.20D is a block diagram of an exemplary computing system 90 on which, for example, Fig. 20A and Fig. 20B The M2M service platform 22. The computing system 90 (e.g., the M2M terminal device 18 or the M2M gateway device 14) may include a computer or a server and may be controlled primarily by computer-readable instructions through any means of storing or accessing these instructions. Such computer-readable instructions may be executed within a central processing unit (CPU) 91 to cause the computing system 90 to perform work. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor, different from the main CPU 91, which performs additional functions or assists the CPU 91. The CPU 91 or the coprocessor 81 may receive, generate, and process data related to the disclosed system and method for subscription and notification services, such as receiving a subscription request and indicating a notification target status.

[0163] In operation, the CPU 91 fetches, decodes and executes instructions, and transmits information to and from other resources via the computer's main data transmission path, the system bus 80. Such a system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0164] Memory devices coupled to the system bus 80 include random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 typically contains stored data that is not easily modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. A memory controller 92 can control access to RAM 82 or ROM 93. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0165] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the CPU 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0166] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components necessary to generate the video signals sent to the display 86.

[0167] In addition, the computing system 90 may include a network adapter 97, which may be used to connect the computing system 90 to an external communication network, such as Fig. 20A and Fig. 20B network12.

[0168] It should be understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, which, when executed by a machine such as a computer, a server, an M2M terminal device, or an M2M gateway device, may execute or implement the systems, methods, and processes described herein. Specifically, any of the above steps, operations, or functions may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, but such computer-readable storage media themselves do not include signals. It is apparent from the description herein that storage media should be interpreted as statutory subject matter. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, tapes, disk storage or other magnetic storage devices, or any other physical medium that can be used to store the desired information and can be accessed by a computer. The computer-readable storage medium may have a computer program stored thereon, which may be loaded into a data processing unit and adapted to cause the data processing unit to perform the method steps when the data processing unit runs the computer program.

[0169] In describing the preferred method, system or apparatus of the subject matter of the present disclosure - subscription and notification service - as shown in the figure, specific terminology is used for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0170] The various techniques described herein can be implemented in conjunction with hardware, firmware, software, or combinations thereof where appropriate. Such hardware, firmware, and software can reside in devices located at various nodes of a communication network. Devices can operate alone or in combination with each other to implement the methods described herein. As used herein, the terms "device," "network device," "node," "equipment," or "network node," etc., can be used interchangeably. In addition, unless otherwise specified herein, the use of the term "or" is generally inclusive.

[0171] This written description uses examples to disclose the invention, including the best mode, and also enables those skilled in the art to practice the invention, including making and using any device or system and performing any combined methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein). These other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements that are not substantially different from the literal language of the claims.

[0172] Methods, systems, devices, etc. as described herein can provide devices for subscription or notification services. A method, system, computer-readable storage medium, or device has a device for obtaining (e.g., passively receiving or actively retrieving) a first subscription request to receive event notifications of a resource by a subscriber device; and generating a resource based on the first subscription request to record a notification message. The method, system, computer-readable storage medium, or device has a device for obtaining a second subscription request (e.g., a subsequent subscription request) to retrieve event notifications associated with a notification target based on a discovery criterion; and when the discovery criterion is met, a response including a notification message is sent. The method, system, computer-readable storage medium, or device has a device for obtaining a second subscription request to retrieve event notifications associated with a notification target based on a discovery criterion, wherein the discovery criterion includes a request that has been sent but not yet confirmed as obtained by the notification target; and when the discovery criterion is met, a response confirming the second subscription request is sent. The method, system, computer-readable storage medium, or device has a device for obtaining a second subscription request to delete notifications associated with a notification target based on the discovery criterion; and when the discovery criterion is met, a response confirming the second subscription request is sent. The method, system, computer-readable storage medium or device has a device for obtaining a second subscription request to delete notifications associated with a notification target based on discovery criteria, wherein the discovery criteria include messages sent within a time period; and when the discovery criteria are met, a response confirming the second subscription request is sent. The first subscription request may include an instruction to record each notification issued within a time period. The first subscription request may include instructions to record notifications published during a time period, delivered to a notification target in a list, and generated by conditions in the list. The first subscription request includes instructions to record notifications when a specific number of failures have occurred for a specific notification target. A method, system, computer-readable storage medium or device has a device for obtaining an indication of an expiration time of a notification resource to be created. The device may be a service layer. A method, system, computer-readable storage medium, or apparatus having means for obtaining a first subscription request from a subscriber to receive event notifications of a resource by a subscriber device, the first subscription request including a first parameter that tells which notification target should be contacted to confirm the first subscription request; based on the first subscription request, sending a message to the notification target, the message including an identifier of the subscriber, an identifier of the subscribed resource, an identifier of the notification target to receive the notification, or an event notification criterion; and generating a resource based on the first subscription request to log notification messages. All combinations (including removal or addition of steps) in this paragraph are considered consistent with other parts of the detailed description.< / subscription> < / notificationtargetselfreference> < / subscription> < / notificationtargetselfreference> < / subscription> < / notiftargetoffline> < / subscription> < / notiftargetonline> < / subscription> < / subscription> < / notiftargetstatusreference> < / subscription> < / subscription> < / notificationtargetpolicy> < / subscription> < / notification> < / notiftarget> < / subscription> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / notiftarget> < / subscription> < / ae> < / notiftarget> < / ae> < / ae> < / notiftarget> < / subscription> < / notiftarget> < / subscription> < / notiftarget> < / remotecse> < / ae> < / notiftarget> < / notiftarget> < / subscription> < / notiftarget> < / notiftarget> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / notification> < / subscription> < / ae> < / notification> < / ae> < / ae> < / notification> < / subscription> < / notification> < / subscription> < / notification> < / remotecse> < / ae> < / subscription> < / notification> < / container> < / flexcontainer> < / notification> < / container> < / flexcontainer> < / notification> < / notification> < / notification> < / notification> < / notification> < / notiftarget> < / notification> < / subscription> < / subscription> < / subscription>

Claims

1. A device for subscription and notification services, comprising: processor; as well as A memory coupled to the processor, the memory comprising executable instructions, which when executed by the processor cause the processor to perform operations, the operations comprising: receiving a subscription request for a first resource from a subscriber device, wherein the first resource is a uniquely addressable element in a resource-oriented architecture (ROA) having a representation that can be manipulated through a RESTful method; Based on receiving the subscription request, detecting that the first resource has satisfied an event notification criterion, wherein the event notification criterion defines when a notification event is generated; generating an event notification for the first resource; Send a notification message to the notification target; calculate and record notification statistics according to instructions in the subscription request regarding which statistics about notification events should be calculated and maintained; receiving a retrieval request to retrieve notification statistics; and Based on the retrieval request, a response is sent, wherein the response includes the recorded notification statistics. 2 . The apparatus of claim 1 , wherein the subscription request includes a time window for calculating notification statistics. 3 . The apparatus of claim 1 , wherein the subscription request includes a list of notification targets for which notification statistics are to be calculated.

4. The apparatus according to claim 1, wherein the operation further comprises: Get a request from a subscriber to adjust the notification target; as well as A response including the adjustment results is sent to the subscriber.

5. The apparatus of claim 1, wherein the statistical information comprises a number of notifications successfully received by notification targets in the ROA.

6. The apparatus of claim 5, wherein the statistical information further comprises a number of unsuccessful notifications sent to notification targets in the ROA.

7. A method for subscription and notification services, comprising: receiving a subscription request for a first resource from a subscriber device, wherein the first resource is a uniquely addressable element in a resource-oriented architecture (ROA) having a representation that can be manipulated via RESTful methods; Based on receiving the subscription request, detecting that the first resource has satisfied an event notification criterion, wherein the event notification criterion defines when a notification event is generated; generating an event notification for the first resource; Send a notification message to the notification target; calculate and record notification statistics according to instructions in the subscription request regarding which statistics about notification events should be calculated and maintained; receiving a retrieval request for retrieving notification statistics; as well as A response is sent in response to the retrieval request, wherein the response includes the recorded notification statistics.

8. The method of claim 7, wherein the statistical information includes the number of notifications successfully received by notification targets in the ROA.

9. The method of claim 8, wherein the statistical information further comprises a number of unsuccessful notifications sent to notification targets in the ROA.

10. The method according to claim 9, further comprising: Receive requests to stop logging notifications or to change notification logging settings.

11. The method according to claim 9, further comprising: Whether a subscriber device, a notification target, or one of other service layer entities is authorized to access the recorded notifications is determined based on an access control policy.

12. A device for subscription and notification services, the device comprising: processor; and A memory coupled to a processor, the memory comprising executable instructions that, when executed by the processor, cause the processor to perform operations including: Sending a subscription request for a first resource, where the first resource is a uniquely addressable element in a resource-oriented architecture (ROA) having a representation that can be manipulated through a RESTful method, wherein the subscription request includes: event notification criteria that define when subscriptions and notification services generate notification events, and instructions regarding which statistics about notification events should be calculated and maintained; Send a retrieval request to retrieve notification statistics; and A response is received that includes the requested notification statistics.

13. A method for subscription and notification services, comprising: Sending a subscription request for a first resource, where the first resource is a uniquely addressable element in a resource-oriented architecture (ROA) having a representation that can be manipulated through a RESTful method, wherein the subscription request includes: event notification criteria that define when subscriptions and notification services generate notification events, and instructions regarding which statistics about notification events should be calculated and maintained; Send a retrieval request to retrieve notification statistics; and A response is received that includes the requested notification statistics.

14. The method according to claim 13, further comprising: Determining adjustments to notification targets based on received notification statistics; as well as Sends a request to adjust the notification target.

15. The method of claim 13, wherein the statistical information comprises the number of notifications successfully received by notification targets in the ROA.

16. The method of claim 15, wherein the statistical information further comprises a number of unsuccessful notifications sent to notification targets in the ROA.

17. The method according to claim 16, further comprising: Send a request to stop logging notifications or change notification logging settings.

Images