KR20200006367A - Method and apparatus for managing notification failture in m2m system - Google Patents

Abstract

The present invention may provide a method of a hosting system managing a notification failure in a machine-to-machine (M2M) system. According to the present invention, the method of a hosting system managing a notification failure may comprise the steps of: setting up subscription resources; detecting event triggering; transmitting a notification message to a target system according to a subscription request based on a triggered event; and detecting whether the notification message transmission failed. When the notification message is transmitted to a plurality of target systems, whether the notification message transmission has failed may be determined based on a first subscription attribute.

Description

METHOD AND APPARATUS FOR MANAGING NOTIFICATION FAILTURE IN M2M SYSTEM}

The present invention relates to a method and apparatus for managing notification failure in a machine-to-machine (M2M) system. More specifically, the present invention relates to a method and apparatus for managing a notification failure based on a notification failure type in an M2M system.

Recently, M2M (Machine-to-Machine) system has been actively introduced. M2M communication may mean communication performed between a machine and a machine without human intervention. M2M may refer to Machine Type Communication (MTC), Internet of Things (IoT), or Device-to-Device (D2D). However, hereinafter, for the convenience of description, the term is referred to as M2M uniformly, but is not limited thereto. The terminal used for M2M communication may be an M2M device. The M2M terminal may generally be a device having low mobility while transmitting less data. In this case, the M2M terminal may be used in connection with an M2M server that centrally stores and manages communication information between machines.

In addition, the M2M terminal may be applied in various systems such as object tracking, vehicle linkage, and power metering.

On the other hand, with respect to the M2M terminal, the oneM2M standardization organization provides the technology for requirements, architecture, API specifications, security solutions, interoperability for M2M communication, IoT, IoT technology. The specifications of the oneM2M standardization organization provide a framework to support a variety of applications and services such as smart cities, smart grids, connected cars, home automation, security and health.

It is an object of the present invention to provide a method for managing notification failures.

An object of the present invention is to provide a method for managing notification failure when a notification message is transmitted to a plurality of target systems.

It is an object of the present invention to provide a method for managing notification failures based on the type of notification failure.

According to an embodiment of the present invention, a hosting system in an M2M system may provide a method for managing a notification failure. In this case, the method for managing a notification failure by the hosting system may include setting a subscription resource, detecting event triggering, transmitting a notification message to a target system according to a subscription request based on the triggered event, and failing to transmit a notification message. It may include detecting whether or not. In this case, when the notification message is transmitted to the plurality of target systems, whether the notification message transmission has failed may be determined based on the first subscription attribute.

In addition, according to an embodiment of the present invention, it is possible to provide a hosting system for managing notification failure in the M2M system. In this case, the hosting system may include a transceiver to transmit and receive a signal and a processor to control the transceiver. In this case, the processor may set a subscription resource, detect event triggering, transmit a notification message to the target system according to the subscription request based on the triggered event, and detect whether the notification message transmission has failed. In this case, when the notification message is transmitted to the plurality of target systems, whether the notification message transmission has failed may be determined based on the first subscription attribute.

In addition, according to an embodiment of the present invention, a target system in an M2M system may provide a method for managing a notification failure. In this case, the method for managing notification failure by the target system may include setting a subscription resource to a hosting system, receiving a notification message sent by the hosting system according to a subscription request, detecting the event triggering, and detecting whether the notification message transmission has failed. It may include the step. In this case, when the notification message is transmitted to the plurality of target systems, whether the notification message transmission has failed may be determined based on the first subscription attribute.

In addition, according to an embodiment of the present invention, it is possible to provide a target system for managing notification failure in the M2M system. In this case, the target system may include a transceiver to transmit and receive a signal and a processor to control the transceiver. In this case, the processor sets a subscription resource to the hosting system, receives a notification message that the hosting system detects event triggering and transmits according to a subscription request, and detects whether the notification message transmission has failed, but the notification message is a plurality of target systems. In case of transmission, the notification message transmission failure may be determined based on the first subscription attribute.

In addition, the following may be applied in common in an M2M system.

In this case, according to an embodiment of the present invention, when the first subscription attribute indicates the first type, it may be determined that the notification message transmission has failed only when all of the plurality of target systems do not receive the notification message.

According to an embodiment of the present invention, when the first subscription attribute indicates the second type, when at least one or more target systems among the plurality of target systems do not receive the notification message, it may be determined that the notification message transmission has failed. have.

In addition, according to an embodiment of the present invention, when the first subscription attribute indicates the third type, it may be individually determined whether notification message transmission for a plurality of target systems has failed.

In addition, according to an embodiment of the present invention, whether transmission failed may be determined based on a maximum number of notification message transmissions.

Further, according to an embodiment of the present invention, when the first subscription attribute is the third type, the maximum number of notification message transmissions is counted for each of the plurality of target systems, and when the first subscription attribute is another type, the notification message. The maximum number of transmissions may be counted based on the entire plurality of target systems.

In addition, according to an embodiment of the present invention, second subscription attribute information indicating address information of the plurality of target systems may be further set.

In addition, according to an embodiment of the present invention, address information of the target system, which is determined that the notification message transmission has failed among the plurality of target systems, may be deleted from the second subscription attribute information.

In addition, according to an embodiment of the present invention, the second subscription attribute information may be “notificationURI”.

In addition, according to an embodiment of the present invention, the first subscription attribute information may be “notificationFailType”.

According to the present disclosure, a method of managing a notification failure can be provided.

According to the present disclosure, it is possible to provide a method for managing a notification failure when transmitting a notification message to a plurality of target systems.

According to the present disclosure, a method of managing notification failures may be provided based on the type of notification failure.

Effects obtained in the present disclosure are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

1 is a diagram illustrating a hierarchical structure of an M2M system according to the present disclosure.
2 is a diagram illustrating a reference point according to the present disclosure.
3 is a diagram illustrating each node according to the present disclosure.
4 illustrates a common service function according to the present disclosure.
5 is a diagram illustrating a method in which a sender and a receiver exchange messages according to the present disclosure.
6 is a diagram illustrating a subscription attribute according to the present disclosure.
7 is a diagram illustrating a method for transmitting a notification message to a target system by a hosting system according to the present disclosure.
8 is a diagram illustrating a method for transmitting a notification message to a plurality of target systems by a hosting system according to the present disclosure.
9 is a diagram illustrating a method for setting a timer for notification message transmission according to the present disclosure.
10 illustrates a method of determining whether a notification message transmission has failed based on a transmission failure type according to the present disclosure.
11 is a diagram illustrating a device configuration of an M2M terminal according to the present disclosure.

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present disclosure. However, the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.

In the present disclosure, the terms "first" and "second" are used only for the purpose of distinguishing one component from other components, and do not limit the order or importance between the components unless specifically mentioned. Thus, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and likewise, a second component in one embodiment may be referred to as a first component in another embodiment. It may also be called.

In the present disclosure, when a component is "connected", "coupled" or "connected" with another component, it is not only a direct connection, but also an indirect connection in which another component exists in the middle of the connection. It may also include. In addition, when a component "includes" or "having" another component, it means that it may further include another component, without excluding the other component unless otherwise stated. .

In the present disclosure, the components distinguished from each other are for clearly describing each feature, and do not necessarily mean that the components are separated. That is, a plurality of components may be integrated into one hardware or software unit, or one component may be distributed into a plurality of hardware or software units. Therefore, even if not mentioned otherwise, such integrated or distributed embodiments are included in the scope of the present disclosure.

In the present disclosure, components described in various embodiments are not necessarily required components, and some may be optional components. Accordingly, embodiments that consist of a subset of the components described in one embodiment are also included in the scope of the present disclosure. In addition, embodiments including other components in addition to the components described in the various embodiments are included in the scope of the present disclosure.

In describing the embodiments of the present disclosure, when it is determined that a detailed description of a known structure or function may obscure the gist of the present disclosure, a detailed description thereof will be omitted. In the drawings, parts irrelevant to the description of the present disclosure are omitted, and like reference numerals designate like parts.

In addition, the present specification describes a network based on M2M communication, and the work performed in the M2M communication network may be performed in the process of controlling the network and transmitting data in a system that manages the corresponding communication network.

In addition, in the present specification, the M2M terminal may be a terminal performing M2M communication, but may be a terminal operating in a wireless communication system in consideration of compatibility. That is, the M2M terminal may mean a terminal that can be operated based on the M2M communication network, but is not limited to the M2M communication network. The M2M terminal may also operate based on another wireless communication network, and is not limited to the above-described embodiment.

In addition, the M2M terminal may be fixed or have mobility. In addition, the M2M server refers to a server for M2M communication and may be a fixed station or a mobile station.

In addition, in this specification, an entity may refer to hardware such as an M2M device, an M2M gateway, or an M2M server. Also, as an example, an entity may be used to refer to a software configuration in a hierarchical structure of an M2M system, and is not limited to the above-described embodiment.

In addition, as an example, the present invention will be described based on the M2M system, but the present invention is not limited to the M2M system.

Also, the M2M server may be a server that communicates with an M2M terminal or another M2M server. In addition, the M2M gateway may serve as a connection point connecting the M2M terminal and the M2M server. For example, when the networks of the M2M terminal and the M2M server are different, they may be connected to each other through the M2M gateway. In this case, as an example, both the M2M gateway and the M2M server may be M2M terminals, and are not limited to the above-described embodiment.

1 is a diagram illustrating a hierarchical structure of an M2M system.

Referring to FIG. 1, the layered structure of the M2M system may include an application layer 110, a common service layer 120, and a network service layer 130. In this case, the application layer 110 may be a layer that operates based on a specific application. For example, the application may be a vehicle tracking application, a remote blood sugar monitoring application, a power metering application, a controlling application, or the like. That is, the application layer may be a layer for a specific application. In this case, the entity operating based on the application layer may be an application entity (AE).

The common service layer 120 may be a layer for a common service function. For example, the common service layer 120 may be a layer for providing common services such as data management, device management, M2M service subscription management, location services, and the like. Can be. For example, an entity operating based on the common service layer 120 may be a common service entity (CSE).

The network service layer 130 may provide services such as device management, location service, and device triggering to the common service layer 120. In this case, the entity operating based on the network layer 130 may be a network service entity (NSE).

2 is a diagram illustrating an M2M system structure.

Referring to FIG. 2, an M2M system structure may be classified into a field domain and an infrastructure domain. In this case, each entity in each domain may perform communication through a reference point. As an example, a reference point may represent a communication flow between each entity. In this case, referring to FIG. 2, an Mca reference point, which is a reference point between AE and CSE, an Mcc reference point, which is a reference point between different CSEs, and a Mcn reference point, which is a reference point between CSEs and NSEs, may be set.

3 is a diagram illustrating setting of an M2M system structure.

Referring to FIG. 3, an infrastructure domain of a specific M2M service provider may provide a specific infrastructure node 310 (Infrastructure Node, IN). At this time, the CSE of the IN may perform communication based on the AE and Mca reference points of other infrastructure nodes. In this case, one IN may be set for one M2M service provider. That is, the IN may be a node that communicates with an M2M terminal of another infrastructure based on the infrastructure structure. Also, as an example, the concept of a node may be a logical entity or may be a software configuration.

Next, the application designated node 320 may be a node including at least one AE and not including a CSE. In this case, the ADN may be set in the field domain. That is, ADN may be a dedicated node for AE. For example, the ADN may be a node configured in the M2M terminal in hardware. In addition, the application service node 330 may be a node including one CSE and at least one AE. ASN may be set in the field domain. That is, it may be a node including AE and CSE. In this case, the ASN may be a node connected to the IN. For example, the ASN may be a node configured in the M2M terminal in hardware.

The middle node 340 may also be a node including a CSE and including zero or more AEs. At this time, the MN may be set in the field domain. The MN may be connected based on a reference point with another MN or IN. Also, as an example, the MN may be configured in the M2M gateway in hardware.

In addition, as an example, the non-M2M terminal node 350 (Non-M2M device node, NoDN) is a node that does not include M2M entities may be a node that performs management or collaboration with the M2M system.

4 is a diagram illustrating a common service function.

Referring to FIG. 4, common service functions may be provided. For example, common service functions include application and service layer management, communication management and delivery handling, data management and storage, and device management. , Discovery, Group Management, Location, Network Service Exposure / Service Execution and Triggering, Registration, Security, Service Billing, and It may provide at least one or more functions of calculation (Service Charging and Accounting), Service Session Management (Service Session Management), and Subscription / Notification (Notification). At this time, M2M terminals may operate based on a common service function. In addition, the common service function may be possible in other embodiments, and is not limited to the above-described embodiment.

5 is a diagram illustrating a method in which a sender and a receiver exchange messages.

Referring to FIG. 5, an originator 510 may transmit a request message to a receiver 520. In this case, the transmitter 510 and the receiver 520 may be the M2M terminal described above. However, the present invention is not limited to the M2M terminal, and other terminals may be possible, and are not limited to the above-described embodiment. Also, as an example, the sender 510 and the receiver 520 may be the above-described node, entity, server, or gateway. That is, the sender 510 and the receiver 520 may be a hardware configuration or a software configuration, and are not limited to the above-described embodiment.

In this case, as an example, the request message transmitted by the sender 510 may include at least one parameter. In this case, as an example, the parameter may be an essential parameter or a selection parameter. For example, parameters related to a transmitter, parameters related to a receiver, an identification parameter, an operation parameter, and the like may be essential parameters. In addition, other information may be a selection parameter. In this case, the transmitter-related parameter may be a parameter for the sender 510. Also, the receiver related parameter may be a parameter for the receiver 520. In addition, the identification parameters may be parameters required for mutual identification.

In addition, the operation parameter may be a parameter for distinguishing an operation. As an example, the operation parameter may be set to at least one of Create, Retrieve, Update, Delete, and Notify. That is, it may be a parameter for distinguishing an operation.

In this case, when the receiver 520 receives the request message from the sender 510, the receiver 520 may process the request message. As an example, the receiver 520 may perform an operation included in the request message. For this, the receiver 520 may determine whether a parameter is valid and whether there is an authority. In this case, if the parameter is valid and the authority is authorized, the receiver 520 may check whether the resource to be requested exists and perform processing based on this.

For example, when an event occurs, the sender 510 may transmit a request message including a parameter for notification to the receiver 520. The receiver 520 may check the parameter for the notification included in the request message, perform an operation based on the request message, and send the response message back to the sender 510.

6 is a diagram illustrating attributes for a subscription resource.

Referring to FIG. 6, a subscription resource may include attributes. For example, although the attributes of the subscription resource are described in FIG. 6, this is only one example and may be added, deleted, or changed. At this time, information necessary for subscription-notification may be shared through an attribute of a subscription resource. In addition, as an example, information necessary for performing an operation required for subscription notification may be defined as attribute information, and is not limited to the above-described embodiment. For example, the subscription resource may include “notificationFailcounter”. In this case, “notificationFailcounter” may indicate the maximum number of notification messages that can transmit a notification. Also, as an example, “notificationURI” may indicate address information about a target system to receive notification. In addition, information necessary for subscription-notification may be defined as attribute information as shown in FIG. 6 and is not limited to the above-described embodiment.

7 is a diagram illustrating a method of performing notification based on a subscription resource.

Referring to FIG. 7, in an M2M system, M2M terminals may operate based on subscription-notification. In more detail, the M2M platform may register an event through a subscription resource and transmit a notification message when the event occurs.

For example, referring to FIG. 7, the target system 720 allocates a subscription resource to the hosting system 710, and the hosting system 710 notifies the target system when an event occurs. ) Can be delivered. In this case, the hosting system 710 and the target system 720 may be a system that operates based on the aforementioned M2M terminal. That is, each M2M terminal may be a terminal including a hosting system 710 and a target system 720.

In this case, when an event occurs, the hosting system 710 may notify the plurality of target systems 720 of the event information by a message. For example, when the parked car is the hosting system 710, an event such as an impact may occur. In this case, the event notification of the impact may be transmitted as a message to a plurality of terminals registered as the vehicle owner, a target system 720 such as a police system, an insurance company system, but is not limited to the above-described embodiment.

That is, the hosting system 710 may monitor the event and transmit a notification message when the event is detected based on the event. For example, the subscription resource may include event occurrence conditions and address information of the target systems 720. In this case, the address information of the target system 720 may be transmitted as “notificationURI” as an attribute of the aforementioned subscription resource. In this case, as an example, when there are a plurality of target systems 720, “notificationURI” may be in the form of a list, which will be described later.

Also, for example, in connection with a subscription notification, a situation in which a notification message may not be delivered due to a network problem or the like may occur. In this case, referring to FIG. 7, after the primary notification message is delivered, the secondary notification message may be notified, and the notification message may not be transmitted until the Nth notification message is transmitted. However, if the notification message is continuously transmitted as shown in FIG. 7, the system may be overloaded, and a method capable of handling an error situation may be required.

Also, as an example, when the hosting system 710 transmits a notification message, the hosting system 710 may receive an ACK message confirming whether or not the notification message is received from the target system 720. That is, if the hosting system 710 does not receive the ACK message after transmitting the notification message, it may transmit an additional notification message. That is, if the hosting system 710 does not receive the ACK message, it may recognize that the notification message transmission has failed implicitly.

Also, as an example, the target system 720 may transmit a NACK message to the hosting system 710 when the notification message is not properly received. Through this, the hosting system 710 may explicitly confirm that the notification message transmission failed.

In this case, attributes may be set in the subscription resource in consideration of the above-described situation, which may be the same as in FIG. 6.

For example, the attributes of a subscription resource may include “notificationURI” indicating a notification message transmission address, “eventNotificationCriteria” indicating an event occurrence criterion, “notificationFailcounter” counting notification message failures, and the like, as described above. Can be the same.

Example 1

8 is a diagram illustrating a method of transmitting a notification message to a plurality of target systems by a hosting system.

Referring to FIG. 8, as described above, a notification message may be transmitted to a plurality of target systems 820, 830, and 840. In this case, as an example, the notification message transmission transmitted by the hosting system 810 may fail, as described above. However, since the hosting system 810 transmits a notification message to the plurality of target systems 820, 830, and 840, the notification message transmission may succeed in some target systems, and the notification message transmission may fail in some target systems. .

In more detail, the network environment between the hosting system 810 and each target system 820, 830, 840 may be different from each other, and may be an operation based on different network systems.

In this case, as an example, if the transmission of the notification message to the plurality of target systems 820, 830, and 840 fails as described above, the subscription itself may be removed. That is, the operation based on the transmission failure for the notification message may be an operation of deleting the subscription itself. However, when there are a plurality of target systems 820, 830, and 840, success or failure of notification message transmission may be determined based on the entire plurality of target systems 820, 830, and 840, which may be inefficient. . That is, although the notification message transmission may be performed to the individual target system, the determination is made on the whole, and the operation may be hindered in terms of the individual target system. Thus, there is a need to distinguish the operations for each target system.

In this case, as an example, when the hosting system 810 transmits a notification message to the plurality of target systems 820, 830, and 840, a time period for receiving the notification message may be set as the notification waiting mode. In more detail, the hosting system 810 may have a standby mode for transmitting the notification message for a predetermined time after transmitting the notification message to the plurality of target systems 820, 830, and 840. The hosting system 810 may wait for a notification message to be sent for a period of time. At this time, if there is a temporary failure for the network, the network failure may be solved for a specific time, and the notification message transmission may be successful. That is, in consideration of the situation in which the hosting system 810 transmits a notification message to the plurality of target systems 820, 830, and 840, the hosting system 810 may allocate a time for which the notification message can be sufficiently delivered. have. The hosting system 810 may set a wait time mode such that a notification message is transmitted to the plurality of target systems 820, 830, and 840 for a predetermined period of time. In addition, as an example, the information on the wait time mode setting may be defined as an attribute of the aforementioned subscription resource, and the name thereof is not limited.

As another example, when transmission of a notification message to some target systems among the plurality of target systems 820, 830, and 840 fails, the subscription itself may be deleted without deleting the subscription itself. For example, when the hosting system 810 transmits a notification message to the plurality of target systems 820, 830, and 840, the “notificationURI” may be described in a list form. That is, the “notificationURI” may include addresses for the plurality of target systems 820, 830, and 840. In this case, when a notification message transmission to some target systems among the plurality of target systems 820, 830, and 840 fails, only the target system for which the notification message transmission fails in the “notificationURI” is deleted, and the address of the target system for which the notification message is successful is deleted. You can keep it as it is. Through this, the target system capable of receiving the notification message may avoid the situation in which the subscription itself is deleted and not receiving the notification. For example, the above-described operation may also be defined as an attribute of a subscription resource, and is not limited to the above-described embodiment.

As another example, an individual failure may be introduced as “notificationFailType” among the aforementioned subscription attributes. In more detail, in consideration of a failure to transmit a notification message, notificationFailType ”may include a type for at least one of“ all failures ”,“ some failures ”, and“ individual failures ”. In this case, the “all failures” type may be a method of determining that the transmission failed only when the notification message transmission fails to all the target systems. That is, if the notification message is sent only to some target systems, the transmission may be declared successful. However, when the “all failures” type is set as described above, if the network of some target systems continuously fails, and only some target systems operate normally, the notification message transmission succeeds continuously. Failure can not be confirmed. In an extreme case, the notification message transmission to the plurality of target systems continuously fails, and in the situation where the notification message transmission to one target system is successful, the above-described method may be determined to be the notification message transmission success. Therefore, in case of “all failures”, a notification message is continuously transmitted to the target system where notification failures occur, and it may not be possible to solve a network abnormality problem.

On the other hand, in the case of "partial failure" as the type of "notificationFailType", the case where delivery failed to any one of a plurality of target systems can be treated as notification delivery failure. At this time, for example, according to the "some failures" method, even though most target systems transmit a notification message, if one target system does not succeed in transmitting the notification message due to a network error, notification delivery failure may occur. That is, a situation in which the target system capable of receiving the notification message may not receive the notification message by one target system may occur. In this case, if the subscription itself is deleted based on the transmission failure in the above-described situation, the subscription itself may be deleted even for the target system that has successfully received the notification message, and thus the operation may be limited.

Therefore, if individual failures can be introduced according to the subscription type, it may be considered to set “notificationFailType” to “individual failure.” In this case, when the hosting system sends a notification message due to an event occurrence, the hosting system may have a plurality of failures. Each of the two target systems may be independently determined whether the notification message has failed, that is, whether the notification message has failed to be transmitted may be determined independently from other target systems. It may be determined based on “notificationFailcounter.” That is, in case of “individual failure,” “notificationFailcounter” may be generated and performed separately for each target system.

This solves the problems arising from “all failed” and “some failed”. More specifically, in the case of “all failures”, there was a problem that the target system receiving the notification failure continuously received the notification message, but through “individual failure”, it was determined individually whether or not the specific target system failed the transmission. Subscriptions can be deleted for individual target systems.

In addition, in the case of "some failures", it is possible to prevent the subscription to the target system where notification success is occurring. That is, as determined by the individual target systems, the subscription deletion may be performed only on the target system where the transmission failure has occurred, without performing the subscription deletion on the target system where the notification message is successfully completed.

In addition, as an example, "notificationFailType" may be determined based on the type of the subscription, for example, if only one of the target systems among the subscription types successfully transmits the notification message, it may be set to "all failure" if possible. For example, if a driving car transmits a message based on group chat, if only one of the plurality of target systems included in the group chat successfully transmits the notification message, other target systems may share information about the notification message transmission success. Thus, if only a successful transfer to any of the subscription types is required, then "all failures" may be set.

Also, for example, when it is necessary to transmit a notification message to all according to a subscription type, "notificationFailType" may be set to "some failures". In this case, the notification message transmission success may be determined as the notification message transmission success only when the transmission to all of the plurality of target systems is successful.

For example, when a driving car generates an event for checking a restaurant for a surrounding area, the driving car determines a target system for checking location information of a surrounding area, a target system including a restaurant list, and mobility of the car. Notification messages can all be sent to the target system. In this case, each of the plurality of target systems needs to provide comprehensive information in cooperation with each other, and thus, the hosting system needs to successfully transmit a notification message to all target systems. Therefore, in the above-described situation, it is necessary to set "notificationFailType" to "partial failure" in consideration of the type of subscription.

On the other hand, when an event called an impact occurs in a car parked, a notification message may be transmitted to a plurality of terminals registered as car owners. In this case, each of the plurality of terminals registered as the car owner may not be terminals connected to each other, and since there is no need for success in transmitting the notification message, it may be necessary to individually determine whether the notification message is successfully transmitted. That is, it is necessary to set "notificationFailType" to "individual failure" considering the type of subscription.

As described above, the “notificationFailType” may be set to “all failures”, “some failures”, or “individual failures”. In this case, for example, three types of “notificationFailType” may be used, and “notificationFailType” may be configured as 2 bits. Also, as an example, when “notificationFailType” is an individual failure, address information may be individually deleted from the above “notificationURI”. That is, since it has been determined that the individual transmission failure for each target system, "notificationURI" can be deleted only for the target system indicated the transmission failure, it is not limited to the above-described embodiment.

9 is a diagram illustrating a method of determining a transmission failure based on a transmission failure type.

Referring to FIG. 9, a subscription resource may be set in a hosting system (S910). In this case, the hosting system may detect an event based on the set subscription resource. (S920) When the hosting system detects an event, In operation S930, the hosting system may transmit a notification message to the target system. As described above with reference to FIGS. 1 to 8, an event may be set differently according to a subscription request, and an event condition set in a subscription resource is satisfied. If so, the hosting system may send a notification message to the target system, as described above.

For example, it may be considered that there are a plurality of target systems to which a notification message is transmitted (S940). In this case, when there is only one target system to which a notification message is transmitted, whether or not a notification message transmission fails is determined based on one target system. In this case, as described above with reference to FIGS. 1 to 8, whether the notification message transmission fails may be determined based on the maximum number of transmissions or a timer, as described above.

Next, when the notification message is transmitted to the plurality of target systems, it may be determined whether the first subscription attribute is an individual failure. (S960) As described above with reference to FIGS. 1 to 8, the first subscription attribute may be determined. May be “NotificationFailType”. In this case, "NotificationFailType" may be set to "all failure", "some failure" or "individual failure", as described above. In this case, when the “NotificationFailType” is not “individual failure,” the hosting system may determine whether the transmission fails based on the plurality of target systems. (S970) As described above with reference to FIGS. 1 to 8, “ All failed ”may be determined to be a failed transmission only when all of the notification messages have failed to be sent to the plurality of target systems. In addition, as an example, “some failures” may be determined as transmission failures when the notification message transmission to at least one target system among the plurality of target systems fails. That is, "all failures" and "some failures" may be determined as transmission failures as a plurality of target systems as a whole. In this case, as an example, the above-described maximum number of notification messages and the counter may operate based on the entire target system, as described above.

Next, when the first subscription attribute is an individual failure, it may be determined whether the notification message transmission has failed based on each target system. (S980) In this case, as described above with reference to FIGS. If the subscription is deleted by determining whether the transmission fails as a whole system, some target systems may be disadvantageous. That is, even a target system capable of transmitting a notification message may cause a problem because the subscription is deleted. Therefore, if the first subscription attribute is an individual failure, whether or not the notification message transmission is successful needs to be performed individually on the target system, as described above. In this case, as an example, the type of the first subscription attribute may be determined according to the subscription type, as described above.

Example 2

Based on the above-described "notificationFailcounter" it can be determined whether the notification message transmission failed.

In more detail, an initial setting value for the notification message transmission may be set in the “notificationFailcounter”. At this time, if the notification message transmission fails based on the initial setting value may be counted. For example, when the notification message transmission is successful, the counting may be reset, and again operate as the initial setting value. On the other hand, if the notification message transmission fails continuously and reaches the maximum number of transmissions, the notification message transmission failure may be declared and the subscription may be deleted. That is, the hosting system may transmit a notification message only for the maximum number of transmissions, and may declare a transmission failure when the notification message transmission fails for the maximum number of transmissions.

As another example, an attribute of a notification message transmission interval may be set. For example, “notificationFailperiod” may be set. However, the attribute name is not limited to the above-mentioned name.

In more detail, when the hosting system determines whether the notification message fails based only on the maximum number of transmissions, the determination on whether the notification message transmission failed may be performed for a long time. More specifically, if the maximum number of notification message transmissions is set to a high value, and each notification message transmission period is long, the hosting system may need a long time to declare the transmission failure. At this time, if the notification message transmission failure is obvious in consideration of the network environment, waiting for the notification message transmission failure until the maximum number of transmission may cause a network delay. In addition, determining the transmission failure by waiting until the maximum number of transmissions may be a problem in consideration of the possibility of collision with other messages and power consumption of the hosting system.

Therefore, it is necessary to set "notificationFailperiod" separately from "notificationFailcounter" which is the maximum number of transmissions.

More specifically, referring to FIG. 10, when the event is triggered (S1010), the hosting system may transmit a notification message to the target system and start a timer based on “notificationFailperiod” (S1020). The condition may be a condition to start a timer. In this case, the hosting system may transmit a notification message to the target system. At this time, if the hosting system successfully transmits the notification message to the target system (S1030), the above-described timer may be reset (S1040). That is, if the notification message transmission is successful to prevent the transmission failure from being declared by the timer. The timer can be reset.

On the other hand, when the notification message transmission fails (S1030), the hosting system may check whether the timer has expired (S1050). In this case, if the timer has not expired, the hosting system may transmit the notification message again. That is, when a notification message transmission failure occurs, the set timer may not be reset. On the other hand, if the timer expires, the hosting system may declare a transmission failure and delete the subscription resource (S1060). That is, the hosting system does not succeed in transmitting the notification message during the timer that can send the notification message in consideration of network delay. If not, it can declare a failed transfer and delete the subscription resource. Through this, the hosting system may declare the transmission failure even before the notification message transmission failure number reaches the maximum transmission number, and perform another operation based on this.

On the other hand, as an example, when the number of notification message transmission failures reaches the maximum number of transmissions before the timer expires, the transmission failure may be declared even before the timer expires, and the subscription resource may be deleted. That is, the hosting system may declare that the notification message transmission has failed and delete the subscription when any one of the situations in which the timer expires or reaches the maximum number of transmissions is satisfied.

11 is a diagram illustrating a configuration of an M2M terminal device according to the present disclosure.

The M2M terminal device 1100 may include a processor 1110 for controlling the device and a transceiver 1120 for transmitting and receiving a wireless signal. In this case, the processor 1110 may control the transceiver 1120. Also, the M2M terminal device 1100 may communicate with another M2M terminal device 1200. For example, the above-described sender and receiver may each be the M2M terminal of FIG. 11. The other M2M terminal device 1200 may also include a processor 1210 and a transceiver 1220 and may perform the same role. In addition, the device of FIG. 11 may be another device. For example, the device may be a device for performing communication, a vehicle, a base station, or the like. That is, the present invention refers to an apparatus capable of performing communication, and is not limited to the above-described embodiment.

Embodiments of the present invention described above may be implemented through various means. For example, embodiments of the present invention may be implemented by hardware, firmware, software, or a combination thereof.

The detailed description of the preferred embodiments of the invention disclosed as described above has been provided to enable any person skilled in the art to make and practice the invention. Although the above has been described with reference to the preferred embodiments of the present invention, those skilled in the art will variously modify and change the present invention without departing from the spirit and scope of the invention as set forth in the claims below. I can understand that you can. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. In addition, while the preferred embodiments of the present specification have been shown and described, the present specification is not limited to the specific embodiments described above, and the technical field to which the present invention pertains without departing from the gist of the present specification claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or prospect of the present specification.

In the present specification, both the object invention and the method invention are described, and the description of both inventions can be supplementarily applied as necessary.

In addition, the present invention has been described with reference to the preferred embodiments. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

M2M terminal: 1100 Processor: 1110
Transceiver: 1120 M2M Terminal: 1200
Processor: 1210 Transceiver: 1220

Claims (20)

In the M2M system, the hosting system manages the notification failure,
Setting a subscription resource;
Detecting event triggering;
Sending a notification message to a target system according to a subscription request based on the triggered event; And
Detecting whether the notification message transmission failed;
And when the notification message is transmitted to a plurality of target systems, determining whether the notification message transmission has failed is determined based on a first subscription attribute.
The method of claim 1,
And when the first subscription attribute indicates the first type, determining that the notification message transmission has failed only when all of the plurality of target systems do not receive the notification message.
The method of claim 1,
And when the first subscription attribute indicates a second type, determining that the notification message transmission has failed when at least one or more target systems of the plurality of target systems do not receive the notification message.
The method of claim 1,
And when the first subscription attribute indicates a third type, whether notification message transmission to the plurality of target systems has failed is individually determined.
The method of claim 4, wherein
The notification failure management method is determined based on the maximum number of notification message transmission failure.
The method of claim 5, wherein
When the first subscription attribute is the third type, the maximum number of notification message transmissions is counted for each of the plurality of target systems.
And when the first subscription attribute is another type, the notification message maximum number of transmissions is counted based on the entirety of the plurality of target systems.
The method of claim 4, wherein
And second subscription attribute information indicating address information for the plurality of target systems is further set.
The method of claim 7, wherein
The address information on the target system of the plurality of target systems determined to have failed to transmit the notification message is deleted from the second subscription attribute information.
The method of claim 8,
And the second subscription attribute information is “notificationURI”.
The method of claim 1,
And the first subscription attribute information is “notificationFailType”.
A hosting system that manages notification failures in an M2M system,
Transmitting and receiving unit for transmitting and receiving a signal;
And a processor for controlling the transceiver.
The processor is
Set up subscription resources,
Detect event triggering,
Send a notification message to a target system according to a subscription request based on the triggered event, and
Detect whether the notification message transmission failed,
And when the notification message is transmitted to a plurality of target systems, determining whether the notification message failed to be transmitted is determined based on a first subscription attribute.
The method of claim 11,
And if the first subscription attribute indicates a first type, determining that the notification message transmission has failed only if all of the plurality of target systems do not receive the notification message.
The method of claim 11,
If the first subscription attribute indicates a second type, determining that the notification message transmission has failed if at least one or more target systems of the plurality of target systems do not receive the notification message. .
The method of claim 11,
And when the first subscription attribute indicates a third type, whether notification message transmission failure for the plurality of target systems is individually determined.
The method of claim 14,
Hosting system for managing the notification failure is determined whether the transmission failure based on the maximum number of notification message transmission.
The method of claim 15,
When the first subscription attribute is the third type, the maximum number of notification message transmissions is counted for each of the plurality of target systems.
And when the first subscription attribute is another type, the notification message maximum number of transmissions is counted based on all of the plurality of target systems.
The method of claim 14,
And second subscription attribute information indicating address information for the plurality of target systems is further set.
The method of claim 17,
Address information for the target system of the plurality of target systems determined to have failed to transmit the notification message is deleted from the second subscription attribute information, Hosting system for managing notification failure.
In the M2M system, the target system manages the notification failure,
Setting a subscription resource in a hosting system;
Receiving a notification message that the hosting system detects event triggering and transmits according to a subscription request; And
Detecting whether the notification message transmission failed;
And when the notification message is transmitted to a plurality of target systems, determining whether the notification message transmission has failed is determined based on a first subscription attribute.
In the target system that manages notification failure in the M2M system,
Transmitting and receiving unit for transmitting and receiving a signal;
And a processor for controlling the transceiver.
The processor is
Set up a subscription resource on the hosting system,
Receive a notification message that the hosting system detects event triggering and sends according to a subscription request,
Detect whether the notification message transmission failed,
And when the notification message is transmitted to a plurality of target systems, whether the notification message transmission fails is determined based on a first subscription attribute.

Images