WO2014017720A1 - Network management brokering method and network management brokering system - Google Patents

Abstract

A network management brokering system, according to one embodiment of the present invention, comprises an M2M and network management brokering platform (MNMBP) including: an M2M management platform (MMP) communication unit for receiving M2M fault generation information from an MMP that collects M2M management information on an M2M device or an M2M gateway; a network management platform (NMP) communication unit for receiving network fault generation information from an NMP that collects network management information on an access network and a core network; and a control unit for controlling the MMP communication unit or the NMP communication unit to inquire, if fault generation information is received from the NMP and/or the MMP, whether an M2M fault or a network fault is generated from the other one between the MMP and the NMP.

Description

Network management mediation method and system

The present invention relates to a network management brokering method and system, and more particularly, to a network management brokering method and system using M2M and Network Management Brokering Platform.

The development of modern information and communication technology is changing to networking centering not only computers but also smart phones and portable multimedia devices. However, such small devices with computing and communication networking functions used in computers, smart phones, etc. are used not only for information devices but also for various things around humans to enable communication networks between things to obtain and share information about each other. In such a network environment, not only communication between people but also information sharing between people and things and, moreover, things and things, is called M2M (Machine-to-Machine) communication.

In the early 1990s, M2M used to mean one-to-one or one-to-many communication for simple point-to-point (P2P) connections. Today, M2M communication means collecting information read from sensors or wireless modules. At the level of control, it defines the communication between machines and the communication between devices and machines on which people operate. Ultimately, however, the goal of M2M communication is location recognition, situational awareness, and augmented reality, which aims to improve the quality and stability of M2M communication services while automatically operating without personal control.

Currently, standardization groups around the world, including the European Telecommunication Standard Institute (ETSI), are continuing research and development for the standardization of successful M2M communication. FIG. 1 shows the ETSI Technical Specification (TSSI) 102 690 [Machine-] in the ESTI standard document. to-Machine Communications (M2M); Functional architecture shows architecture for M2M services including device and gateway domains and network domains.

Referring to FIG. 1, the M2M devices 10 and 10 ′ are terminal devices that communicate with minimal or no human input and intervention, and transmit or transmit their own data on request or automatically. It is a kind of device.

When the M2M device 10 'directly connects to the access network 40, the M2M application M12M of the M2M device 12 using the M2M service capability 11 of the M2M device 10'. ), And when the M2M device 10 connects to the access network 40 through the M2M gateway 30, the M2M gateway (M2M gateway 30) may be used using the M2M service capability 31 of the M2M gateway 30. It is prescribed to use the M2M application 32 of 30).

The M2M Area Network 20 provides a connection between the M2M device 10 and the M2M gateway 30. Examples of the M2M local area network 20 may include a personal area network (hereinafter referred to as "PAN") such as IEEE 802.15.x, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, or a wireless local area network (Wireless Local). Area Network (hereinafter referred to as "LAN"), PLC, M-BUS, Wireless M-BSU, KNX may include a LAN.

The M2M gateway 30 is a gateway that executes the M2M application 32 using the M2M service capability 31 and serves as a proxy between the M2M device 10 and the access network 40.

The access network 40 is a network that allows the M2M device 10 'to M2M gateway 30 to communicate with the core network 50. Examples of the access network 40 include xDSL, HFC, FTTH, PLC, Satellite network, GERAN, UTRAN, eUTRAN, Wireless LAN, WiMAX (WiBro), and the like.

The core network 50 is a network that provides IP connectivity, access network control and network service control functions, interconnection with other networks, roaming functions, and the like. Examples of the core network 50 are 3GPP CN, ETSI TISPAN CN, 3GPP2 CN, IMS, and the like.

The M2M service capability 60 of the network domain provides a function that can be shared by different applications, and provides an environment for accessing other service capabilities through an open interface. By using M2M service capabilities, it is possible to develop and deploy optimal applications without considering the characteristics of lower network layers.

M2M applications 70 in the network domain use M2M service capabilities 60 through an open interface to execute and provide M2M service logic in the M2M system.

Meanwhile, according to FIG. 1, the network domain is defined to include M2M Management Functions and Network Management Functions. Here, M2M Management Functions (80) is composed of all the functions required to manage M2M service capabilities in the network domain, the management of the M2M device to M2M gateway uses a specific M2M service capability. . In addition, the network management functions 90 are composed of all functions required to manage the access network 40 and the core network 50, and provide provisioning, supervision, and fault management. And other features.

The reason why the ETSI standard separates the M2M management function from the network management function is that an operator installs and operates an M2M device and / or M2M gateway, or an operator providing M2M service (hereinafter referred to as "M2M service provider" for convenience). Or, the user using the M2M service is because the configuration of the general M2M network to provide the M2M service using the existing access and core network. In the following description, a service provider operating and managing an existing access and core network is classified as a network service provider.

According to the prior art according to the ETSI standard described above, M2M management functions and network management functions required to provide M2M services are defined, but the procedures for providing and using each function are not defined in detail. And provision of management functions is not mandatory to provide M2M service. Accordingly, when the network service provider does not provide network management functions, the M2M service provider may not accurately grasp the network state, and thus there may be an error in the M2M service failure response. In addition, when a mobile device which may have a management function for the M2M device is not registered as an M2M device in a specific region, there is a problem in that the management functions of the mobile device cannot be used.

On the other hand, Figure 2 shows a prior art disclosed in Korean Patent Publication No. 10-2005-0071761 filed under the name of the invention "method and system for providing after-sales service for a network device". According to the prior art, the central management center system 440 is a gateway from a plurality of network devices 410, ..., 415 (that is, corresponding to M2M devices in M2M communication), which are information collection devices 420, ..., 425. Receiving and analyzing the status information of each network device continuously through the (430), to determine whether the cause of the failure is in the network device or the network and provide to the A / S center system 460, reducing the after-sales service provision cost And improving service accuracy.

However, according to the above-described conventional technology, since the network failure is indirectly checked from the information collected by the plurality of network devices 410,..., 425, the cause and problem of the network failure cannot be accurately identified, and thus the failure response and the after There is a problem that there may be an error in service processing. In addition, when a failure occurs in the network, there is a problem in that the failure of the M2M device or the M2M gateway cannot be confirmed until the network is restored, and management and analysis of additional failures are impossible. In addition, even when a failure occurs in the entire power supply system and the network device and the gateway cannot access the access network, there is a problem that it is not possible to distinguish whether the failure is a network, a network device and a gateway, or a power supply system.

The present invention has been made to solve the problems of the prior art as described above, to collect the management information of the M2M device to M2M gateway from the M2M management platform, the management of the access network and core network of the wired to mobile network from the network management platform Network management mediation system, including M2M and Network Management Mediation Platform (MNMBP), which can collect information to accurately analyze the location and cause of failures and provide the analysis results to M2M service providers or users in the event of a failure of M2M services; and Its purpose is to provide a method.

In addition, when a failure occurs in the first network to which the M2M device to the M2M gateway is connected, the second network is connected to the second network using device information, location information, or subscriber information of the M2M device to mobile device collected from the M2M management platform and the network management platform. It is an object of the present invention to provide a network management brokerage system and method comprising an M2M Failover Platform (FRP) that activates these possible devices and allows the M2M devices to maintain M2M services over the second network.

Network management mediation method according to an embodiment of the present invention for solving the above problems, from any one of the M2 (M2M Management Platform) to collect M2M management information and the Network Management Platform (NMP) to collect network management information Receiving failure occurrence information; And inquiring whether the M2M failure occurs or whether a failure occurs in the network to the other one of the MMP and the NMP, and analyzing the cause of the failure.

In addition, the network management mediation system according to an embodiment of the present invention for solving the above problems, MMP receiving M2M failure occurrence information from the M2M management platform (MMP) collecting M2M management information of the M2M device or M2M gateway Communication unit; An NMP communication unit configured to receive network failure occurrence information from an NMP (Network Management Platform) for collecting network management information of an access network and a core network; And a controller configured to control the MMP communication unit or the NMP communication unit to inquire whether one of the MMP and the NMP has an M2M failure or a network failure when receiving failure occurrence information from any one of the NMP and the MMP. It characterized in that it comprises a M2M & Network Management Brokering Platform (MNMBP) including.

Wherein the MNMBP is a FRP (FRP) that inquires the MMP or NMP whether there is an MFRD that can connect to the second access network or the second core network when the M2M device cannot connect to the first access network or the first core network Recovery Platform) may further include a communication unit.

According to the network management intermediation method and system according to the embodiments of the present invention, it is possible to increase the speed and reliability of failure response and after service processing of the M2M service provider and the network service provider.

Further, according to the network management intermediation method and system according to the embodiments of the present invention, when a failure occurs in the first network to which the M2M device or the M2M gateway is connected, the M2M service may be continuously maintained through the second network.

1 illustrates an architecture for providing M2M services according to the prior art of the ESTI standard.

2 illustrates another after-sales service providing method for a network device according to the related art.

FIG. 3A is a schematic diagram of a network management mediation system 380 including M2M and Network Management Mediation Platform (MNMBP) 384 in accordance with one embodiment of the present invention, and FIG. 3B is an MNMBP 384 of FIG. 3A. ) Is a detailed configuration diagram.

FIG. 4 is a diagram illustrating a network management brokering method according to an embodiment of the present invention, in which a MNMBP analyzes a cause of a failure and provides an analysis result when a failure occurs in an M2M device or an M2M gateway.

FIG. 5 illustrates a specific application example of a network management intermediation system in which an MNMBP analyzes a cause of a failure and provides an analysis result according to an embodiment described with reference to FIG. 4 when a failure occurs in an M2M device or an M2M gateway.

FIG. 6 is a flowchart illustrating a network management intermediation method in which an MNMBP analyzes a cause of a failure and provides an analysis result according to an embodiment of the present invention when a failure occurs in a network other than an M2M device or an M2M gateway. to be.

FIG. 7 illustrates a specific application example of a network management intermediation system in which an NMBP analyzes a cause of a failure and provides an analysis result according to an embodiment described with reference to FIG. 6 when a network failure occurs.

8A and 8B are flowcharts of a network management intermediation method for providing an M2M failover service to continue providing M2M service when an M2M gateway or network fails in accordance with an embodiment of the present invention.

FIG. 9 illustrates a specific application example of a network management intermediation system that provides an M2M failover service to continue providing M2M service according to an embodiment described with reference to FIGS. 8A and 8B when a failure occurs in an M2M gateway to a first network. Shows.

FIG. 10 is a flowchart illustrating a network management intermediation method in which an MNMBP analyzes a cause of a failure and provides an analysis result when a failure occurs in a power supply system in a region where an M2M device to an M2M gateway is installed.

FIG. 11 illustrates a specific application example of a network management intermediation system in which an MNMBP analyzes a cause of a failure and provides an analysis result according to an embodiment described with reference to FIG. 10 when a power supply system fails to provide an M2M service. Illustrated.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings. Note that like reference numerals in the drawings show similar configurations.

FIG. 3A is a schematic diagram of a network management mediation system 380 including M2M and Network Management Mediation Platform (MNMBP) 384 in accordance with one embodiment of the present invention, and FIG. 3B is an MNMBP 384 of FIG. 3A. ) Is a detailed configuration diagram.

Referring to FIG. 3A, M2M devices 1 to N (301, 302, 303, 304,... 305), M2M regional networks 310, 311, M2M gateway 320, access networks 330, 331, and core network 341. 342, the M2M Servive Capabilities 360, and the M2M application 370 are the same as described above with reference to FIG. 1, and thus, detailed description thereof will be omitted. In addition, in FIG. 3A, the M2M devices 301, 302, 303, 304, and 305 are described as connecting to the access network 330 through the M2M gateway 320. However, as shown in FIG. You can also access a direct access network without going through it. However, the network shown at 350 is separately indicated to indicate that the network provides the interconnection between the networks, the IP connection, the connection with the service platform, and may include an ATM and an IP network.

The M2M Management Platform 381 (hereinafter referred to as "MMP") is generally a platform that can be built directly by an M2M service provider or separately for an M2M service provider, and is an M2M device 301, 302, 303, 304. , 305) to collect information for managing the M2M gateway 320 (hereinafter, referred to as "M2M management information"). The MMP 381 provides the M2M management information to the M2M and network management broker platform 384 (M2M & Network Management Brokering Platform; hereinafter referred to as "MNMBP"). In addition, the MMP 381 may collect M2M management information at the request of the MNMBP 384 and provide it to the MNMBP 384. The M2M management information collected by the MMP 381 includes M2M device information (device ID, resource, location, subscriber, authentication, security, fault management, access network, access M2M device, access M2M gateway, etc.) to M2M gateway information. (Information about gateway ID, resource, location, subscriber, authentication, security, fault management, access network, access M2M device, etc.).

Network Management Platform 382 (hereinafter referred to as "NMP") is generally a platform that can be built by network service providers or separately for network service providers and includes access network 320, 321 and core network ( Information for managing the 340 and 341 (hereinafter referred to as "network management information") is collected. The NMP 382 may collect and provide network management information at the request of the MNMBP 384 or regardless of the request of the MNMBP 384. Network management information collected by the NMP 382 includes access network status information (traffic status, fault management, subscriber access status, access network device status, etc.) and core network status information (traffic status, fault management, subscriber access status, core network). Device status, etc.).

In addition, the NMP 382 collects information and subscriber information about mobile devices (eg, mobile phones, mobile pads, mobile gateways, etc.) in M2M service areas that are not registered with the MMP 381, and on other platforms. If requested, it can also be provided. In addition, the M2M service subscriber may provide the necessary functions to remotely control the mobile device through another platform.

The M2M Fault Recovery Device 321 (hereinafter referred to as “MFRD”) is capable of communicating with the M2M devices 301, 302, 303, 304, and 305 through the M2M local network 311. The M2M gateway 310 may be connected to the first access network 330 or another second access network 331 to which the M2M gateway 310 is connected, thereby providing an M2M gateway function. In addition, when the MFRD has a separate independent power source such as a battery, access to the access network and the M2M area network may be possible even if the power supply system of the M2M device and the gateway installation area fails. Examples of MFRDs may include secondary M2M gateways, mobile phones, mobile pads, mobile gateways (eg, WiBro EGG, etc.) that provide the same functionality as the M2M gateway 320. If the user does not register the MFRD 321 as an M2M device, the MMP 381 may not directly collect management information about the MFRD 321 as an M2M device, but the MFRD 321 is registered to a network service. Since the MFRD 321 is not registered as an M2M device, the NMP 382 can obtain MFRD management information.

Fault Recovery Platform 383 (hereinafter referred to as "FRP"), for example, fails in the first network (first access network and first core network) 330, 340 to provide M2M service. If it is not possible, check the MMP 381 to NMP 382 to see if the MFRD 321 is in the failing region, and if the MFRD 321 is in the failing region, have the MFRD 321 activate the M2M regional network. By requesting and providing M2M device information of the failure area, M2M devices in the failure area can continuously use the M2M service through the MFRD 321. Communication between the FRP 383 and the MMP 381 or communication between the FRP 393 and the NMP 382 may be performed directly or through the MNMBP 384 as described below.

The MNMBP 384 accurately analyzes the location of the failure and the cause of the failure when using the M2M service by using the M2M management information provided by the MMP 381 and the network management information provided by the NMP 382, and then analyzes the result of the analysis. It is provided to a service provider (M2M device installer / operator 391 or M2M service provider 392), network service provider 393, or user to enable fast and accurate fault response and after-sales service. In addition, when the M2M service provider requests a disaster recovery service for a network failure, the MNMBP 384 provides a failure recovery service using the FRP 383 and the MFRD 321. The MNMBP 384 may need a trust relationship with an MMP provider (ie, an M2M service provider) in order to use M2M management information of the MMP 381, and an NMP provider (ie, in order to use NMP network management information). A trust relationship with the network service provider) may be required.

As described above, the MNMBP 384 includes a control unit 3841, an MMP communication unit 3842, an NMP communication unit 3843, an FRP communication unit 3844, an analysis unit 3845, and a service provider 3846. ), And a service receiver 3847.

The MMP communication unit 3842 is responsible for communication with the MMP 381, receives M2M management information from the MMP 381, or requests the MMP 381 to provide M2M management information. The NMP communication unit 3843 is in charge of communicating with the NMP 381, receives network management information from the NMP 382, or requests the NMP 382 to provide network management information. The FRP communication unit 3844 is in charge of communicating with the FRP 383 to provide a failover service.

The analyzer 3845 analyzes the cause of the failure by using the M2M management information or the network management information received through the MMP communication unit 3842 or the NMP communication unit 3843. In addition, an analysis function may be provided to provide a disaster recovery service by using subscriber information, MFRD location information, M2M device information, and the like, subscribed to the disaster recovery service.

The service provider 3846 provides the location of the failure and the cause of the failure analysis to the M2M service provider, the network service provider, or the user.

The service receiver 3847 receives a failure analysis service or a failure recovery service from an M2M service provider, a network service provider, or a user and provides a function of processing the same.

The controller 3841 controls all of the components described above by the MNMBP 384 to perform a series of procedures related to failure analysis results and failure recovery service through the MNMBP.

FIG. 4 is a diagram illustrating a network management brokering method according to an embodiment of the present invention, in which a MNMBP analyzes a cause of a failure and provides an analysis result when a failure occurs in an M2M device to an M2M gateway.

In step S401, the MMP collects M2M management information while frequently communicating with the M2M device or the M2M gateway through the core network and the access network, and the information of the M2M devices not directly connected to the access network is managed through the M2M gateway and the M2M local area network. Collect information.

In step S402, the NMP frequently communicates with the access network configuring device and the core network configuring device to the network management system (not shown) (hereinafter referred to as "NMS") built in each network, and the network of the access network or the core network. The management information may be collected and information about a mobile device not registered in the MMP may be collected.

In step S403, if the M2M device or the M2M gateway does not fail, the MMP and NMP continue to collect the M2M management information and the network management information, respectively (steps S403 and S401), and if the M2M device or the M2M gateway fails, the MMP fails. Receiving a communication error with the generated M2M device or M2M gateway or receiving state abnormality information provided by the M2M device or M2M gateway, the MNMBP is notified of the failure (steps S403 and S404). The failure information provided by the MMP to the MNMBP may include information about a device where the failure occurs, information about a location where the failure occurs, subscriber information, and the like.

Subsequently, in step S405, the MNMBP, which has received the failure, uses the failure occurrence information received from the MMP, inquires of the NMP whether the failure occurred in the access network or the core network related to the location where the failure occurred, and in response thereto, provides the relevant information from the NMP. Receive.

In step S406, when the MNMBP receives information that a network failure has occurred from the NMP, the MNMBP analyzes management information and failure information received from the MMP and the NMP comprehensively and analyzes the result (the location of the failure, the time of the failure, the cause of the failure, etc.). ) Is provided to the M2M service provider, the network service provider or the user (step S409).

When receiving the information that the network is normal from the NMP in step S406, the MNMBP requests the MMP the latest management information of another M2M device or another M2M gateway located in the region where the failure occurs (step S407).

In step S408, the MMP that has received the latest management information of another M2M device or another M2M gateway from the MNMBP requests the latest management information from the other M2M device or another M2M gateway and receives the latest management information, and provides the same to the MNMBP. The reason for additionally checking the latest management information of another M2M device or another M2M gateway in step S408 is to increase the accuracy of failure cause analysis.

Thereafter, the MNMBP comprehensively analyzes the management information received from the MMP and the NMP and provides an analysis result to an M2M service provider (step S410).

In the above embodiment, since the network does not have a failure and the M2M device or the M2M gateway can know exactly that, the M2M service provider without spending a manpower and time for network failure recovery It is possible to enable the failure recovery service of the failed M2M device to M2M gateway.

Therefore, according to the present embodiment, the M2M service provider receiving the exact cause of failure result from the MNMBP can respond quickly and accurately to the M2M service failure, thereby increasing the accuracy of the after-sales service.

FIG. 5 illustrates a specific application example of a network management intermediation system in which an MNMBP analyzes a cause of a failure and provides an analysis result when a failure occurs in an M2M device or an M2M gateway according to an embodiment of the present invention.

In the application example of FIG. 5, the M2M device is a power meter 501, a gas meter 502, a smart TV 503, a refrigerator 504, and other home appliances 505, and the M2M application in the network domain is the M2M service capability ( 560 is a power metering application 570 using a wired network 540 including an access and core network, an M2M gateway 520, and a WLAN 510 as an M2M regional network, the M2M service provider using a power meter The case of an installer / operator 591 or a power company 592 is shown.

Hereinafter, a case in which the MMP 581 detects a failure in which power metering information is not received from the power meter 501 will be described as an example.

First, the MMP 581 notifies the MNMBP 583 of the occurrence of a failure that the power meter reading information is not received based on the collected M2M management information.

The MNMBP 583, which is notified of the failure occurrence, inquires of the NMP 582 whether a failure has occurred in the network of the region where the power meter reader 501 is installed.

When receiving information from the NMP 582 that the network is normal, the MNMBP 584 sends the MMP 581 to another M2M device (eg, gas meter 502, smart TV) in the region where the power meter 501 is installed. 503, refrigerator 504, other home appliances 505, and the like. The MMP 581 requests and receives the latest management information from the other M2M devices, and provides the information to the MNMBP 584.

If the other M2M devices are normal, the MNMBP 584 checks this and provides failure occurrence information of the power meter 501 to the power meter installer / operator 591 to the power company 592.

Accordingly, the power meter reader / operator 591 to the power company 592 may be accurately notified of the occurrence of the failure of the power meter rather than the failure of the network, thereby taking measures such as after-sales service.

FIG. 6 is a flowchart illustrating a network management intermediation method in which an MNMBP analyzes a cause of a failure and provides an analysis result according to an embodiment of the present invention when a failure occurs in a network other than an M2M device or an M2M gateway. to be.

Referring to FIG. 6, first, the MMP collects M2M management information while frequently communicating with an M2M device or an M2M gateway through a core network and an access network, and for an M2M device not directly connected to an access network, an M2M gateway and an M2M local area network. Collect M2M management information through (step S601).

In addition, the NMP collects network management information for the access network or the core network while frequently communicating with the NMS established by the network service provider for each of the network component devices or the network constituting the access network and the core network (step S602).

Then, when a failure occurs in the access network or the core network, the NMP collects network failure information to notify the MNMBP of the failure and provides the failure information (steps S603 and S604). The failure information provided by the NMP to the MNMBP may include information about a network configuration device in which the failure occurs, information about a location where a failure occurs in the network, subscriber information, and the like.

Thereafter, in step S605, the MNMBP confirms whether M2M failure occurrence information is received from the M2M device or the M2M gateway from the MMP, and when M2M failure occurrence information is also received from the MMP, the management information received from the MMP and the NMP is comprehensively analyzed. The result of the analysis is provided to the M2M service provider, the network service provider, or the user (steps S605 and S608).

Meanwhile, in step S605, when the MNMBP confirms whether M2M failure occurrence information is received from the M2M device or the M2M gateway from the MMP, and if the M2M failure occurrence information is not received from the MMP, the MNMBP uses the network failure occurrence information received from the NMP. The MMP is queried as to whether the M2M device or the M2M gateway existing at the location of the network where the failure has occurred (step S606).

The MMP, which has received M2M management information of the M2M device or M2M gateway at the location of the failed network from the MNMBP, requests and receives the latest M2M management information from the M2M device or M2M gateway at the location and provides it to the MNMBP. Step S607).

Thereafter, the MNMBP comprehensively analyzes the management information received from the MMP and the NMP and provides an analysis result to an M2M service provider, a network service provider or a user (steps S608 and S609).

In this case, since the M2M device and the M2M gateway have not failed and the network can be identified accurately, the M2M service provider does not need to request for recovery in the event of a failure. The accuracy of services can be increased, and M2M service providers can respond accurately to customer inquiries about failures, thereby increasing the reliability of services.

FIG. 7 illustrates a specific application example of a network management intermediation system in which an NMBP analyzes a cause of a failure and provides an analysis result according to the embodiment described above with reference to FIG. 6 when a network failure occurs.

In the application example of FIG. 7, the M2M device is the smart TV 701, the refrigerator 702, the computer 703, the door lock 704, and other home appliances 705, and the M2M application in the network domain is the M2M service capability 760. Is a home appliance application 770 using a wired network 740 including an access and core network, an M2M gateway 720, and a WLAN 710 as an M2M local area network, and an M2M service provider installs / applies a home appliance. The case of the operator 791 or the home appliance service provider 792 is illustrated.

Hereinafter, an example of detecting that a failure has occurred in the wired network 740 of the subscriber subscribed to the home appliance service will be described.

First, when the NMP 782 detects that a failure occurs in the subscriber's wired network 740, the NMP 782 notifies the MNMBP 783 of the failure of the wired network 740.

The MNMBP 783 recognizes that a failure occurs in the wired network of the subscriber by using the failure occurrence information in the wired network 740 received from the NMP 783, and the M2M device and the M2M connected to the wired network of the subscriber. Ask the MMP 782 if the gateway has failed.

The MMP 782 confirms that household appliances such as the smart TV 701 at the failure location of the subscriber are registered as the M2M device by using the network failure information received from the MNMBP 783. The M2M management information is requested to the home appliance such as 701.

In this example, since a failure occurs in the wired network, the M2M management information may not be received from the home appliance such as the smart TV 701. Therefore, the MMP 781 may receive the failure information of the home appliance such as the smart TV 701. 783). The MNMBP 783, which correctly confirms that the cause of the failure is present in the network, may contact the home appliance installer / operator 791, the home appliance service provider 792, the network service provider 793, or the user 794, such as the smart TV 701. Notify that the M2M service is suspended due to network failure.

The network service provider 793 which has confirmed the M2M service failure due to the network failure from the MNMBP 783 may recover the failure of the failed network. In addition, the home appliance installation / operator (791) or home appliance service provider (792) that has confirmed the M2M service failure due to the network failure from the MNMBP (783) informs the customer center of the cause of the failure, and the customer claim to the customer center. Can respond appropriately.

8A and 8B are flowcharts of a network management intermediation method for providing an M2M failover service to continue providing M2M service when an M2M gateway or network fails in accordance with an embodiment of the present invention.

First, the M2M service provider or user requests a failure recovery service from the MNMBP to continuously use the M2M service even when a failure occurs in the M2M gateway or the network (step S801). This request may be made in advance in the form of an M2M failover service provision contract with the user.

In step S802, the MMP collects M2M management information while frequently communicating with the M2M device or the M2M gateway through the core network and the access network, and information on M2M devices that are not directly connected to the access network includes the M2M gateway and the M2M local area network. Collect M2M management information through.

Further, in step S803, the NMP collects network management information on the access network or the core network while frequently communicating with NMSs established by, for example, a network service provider, for each of the network constituent devices constituting the access network and the core network. do.

If a failure does not occur in the M2M gateway or the network, the MMP and the NMP continue to collect M2M management information and network management information, respectively (step S804 and step S802).

If a failure occurs in the M2M gateway or the network, the MMPs to NMPs receive the failure occurrence information and notify the MNMBP of the failure (steps S804 and S805). The failure occurrence information provided by the MMP to the NMP to the MNMBP may include information on a device on which the failure occurs, information on a location of a failure, subscriber information, and the like.

After receiving the failure, the MNMBP checks whether there is an M2M service or a subscriber that has subscribed to the failure recovery service among the failure occurrence information, and requests a failure recovery from the FRP if there is an M2M service or a subscriber who has subscribed to the failure recovery service (step S806). . In this case, the MNMBP may provide the FRP with M2M device information, subscriber information, M2M service information, and the like, necessary to provide a failback service.

The FRP, which has been requested to recover from the MNMBP, requests MFRD information from the MMP through the MNMBP using the failure occurrence information and the recovery subscriber information (step S808).

If the MFRD information is not registered in the MMP, the FRP requests the NMP through the MNMBP for MFRD information capable of performing the MFRD role (step S809). The MFRD in step S809 may be a mobile device located at a location where a failure occurs or a mobile device searched based on subscriber information. Therefore, the MFRD can be searched even when the failure is not at the location where the failure occurs.

Receiving the MFRD information through the MMP or NMP, the FRP to the MFRD through the network that the MFRD is accessible (hereinafter referred to as "the second network"), not the network where the failure (hereinafter referred to as "first network") Request the M2M local area network to be activated and request M2M devices to connect through the activated M2M local network and the second network (step S810). At this time, the communication between the FRP and MMP or the communication between the FRP and NMP may be made directly or through the MNMBP. After the M2M local network by the MFRD is activated, in step S811 requests the M2M devices to access the M2M local area network through the MFRD activated M2M devices using the information of the M2M devices subscribed to the failover service from the FRP.

Thereafter, M2M devices connected to the MFRD through the M2M local area network activated in step S812 continue to provide M2M services using the MFRD and the second network.

In step S813, the MNMBP may provide an analysis result and a recovery result of a cause of a failure to an M2M service provider, a network service provider, or a user who has subscribed to a failure recovery service.

After the failure of the failed M2M gateway or the first network is restored, M2M devices that provided M2M services through the MFRD and the second network may regain the M2M service through the M2M gateway and the first network at the request of the M2M service provider or the user. It is also possible to provide. The request of the M2M service provider or the user as described above may use the default value set at the time of subscription or failure recovery service request or use the value requested by the M2M service provider or user depending on the situation.

FIG. 8B is an illustration of a flowchart for providing M2M service after failure of the M2M gateway to the first network is continued in the example related to FIG. 8A.

When the failure of the M2M gateway to the first network where the failure occurred is recovered, the MMP to NMP provides the MNMBP with the result of failure recovery and the latest management information of the M2M gateway to the first network (steps S814 and S815).

The MNMBP, which has confirmed that the failure of the M2M gateway or the first network that has failed, has been recovered, may provide the M2M service through the first network or the second network at the request of the M2M service provider or the user.

If the M2M service provider or the user wants to continue to provide M2M service to the MFRD and the second network even if the M2M gateway to the first network fails, the MNMBP provides information on the failure recovery result and management information of the failed M2M gateway to the first network. Provided to the M2M service provider or user who has subscribed to the failover service (steps S816 and S824).

If the failure of the M2M gateway to the first network is desired to provide M2M services through the M2M gateway and the first network, the FRP may be used as an M2M gateway for M2M devices connected to the MFRD through the MMP or NMP and the second network. A request is made to connect (step S817).

Thereafter, M2M devices that are requested to access the M2M gateway are connected to the M2M gateway to receive M2M service through the M2M gateway and the first network (step S818). In addition, the M2M devices and the M2M gateway provide the latest management information to the MMP through the first network (step S819), and the MMP manages the result of the M2M device or the M2M gateway connected to the first network to the MNMBP and the FRP. Information is provided (step S820).

In step S821, after confirming that the M2M service is normally provided through the first network, the FRP requests the MFRD to deactivate the M2M local network using the MMP or NMP and the second network, and in step S822, the MFRD deactivates the M2M local network. After deactivation, the deactivation result of the M2M local network is transmitted to the FRP, MMP or NMP through the second network.

Finally, MNMBP receives M2M service status information, network status information, MFRD status information, etc. from MMP, NMP and / or FRP and analyzes them, and then analyzes the analysis results and recovery results with the M2M service provider or user who subscribed to the failover service. (Steps S823 and S824).

FIG. 9 illustrates a specific application example of a network management intermediation system that provides an M2M failover service to continue providing M2M service according to the embodiment described above with reference to FIGS. 8A and 8B when a failure occurs in the M2M gateway to the first network. Shows.

In the application example of FIG. 9, the M2M device is one or more patient condition monitoring devices 901, the M2M application in the network domain is a patient condition monitoring application 970 using the M2M service capability 960, and via an M2M gateway 920. The WLAN 910 is used as a wired network 940 as a first network including an access and core network that can be connected, an M2M gateway 920, and an M2M local area network that can connect to the M2M gateway 920. . Also assume that the MFRD is a smartphone 921 and assume a WLAN 911 as an M2M local area network to which the MFRD can be connected and a mobile network 941 as a second network (including access and core networks). It is also assumed that the M2M service provider is the patient condition monitoring device installer / operator 991 or the patient condition monitoring service provider 992.

Here, the patient condition monitoring service is a service that monitors the patient's condition through a patient condition monitoring device (blood pressure monitor, blood glucose meter, heart rate monitor, etc.) installed in the patient's body or the patient's active area and informs relevant organizations of the emergency situation in case of an emergency. . Since the patient condition monitoring service is an important service related to the user's life, it is desirable to allow the service to continue even in the event of a failure of the M2M gateway or the wired network.

First, an M2M service provider 991 or 992 or a user 994 providing a patient condition monitoring service requests an M2M failover service from the MNMBP 984.

When a failure occurs in the wired network 940 that provides the patient condition monitoring service, the NMP 981 to MMP 982 confirms the occurrence of a failure and notifies the MNMBP 984 of the failure situation.

Recognizing that a failure has occurred in the M2M service subscribed to the failure recovery service, the MNMBP 984 requests FRP 983 for failure recovery.

The FRP 983 which has confirmed the type of the disaster recovery service and the subscriber information from the MNMBP 984 requests MFRD information from the MMP 981.

If it is confirmed from the MMP 981 that there is no MFRD in the failed first network, the FRP 983 requests the NMP 982 MFRD information of the smartphone 921 that can perform the function as an MFRD. The NMP 982 provides the FRP 983 with smartphone information that can perform a function as an MFRD based on the failure related information received from the FRP 983.

Receiving smartphone information from the NMP 982, the FRP 983 communicates with the smartphone 921 via the NMP 982 and the mobile network 941, and transmits the smartphone 921 to a WLAN-based M2M local network ( Request to activate 911). Receiving information from the smartphone 921 that WLAN activation is complete, the FRP 921 provides the smartphone 921 with information of the patient condition monitoring devices 901.

The smartphone 921, having received the information of the patient condition monitoring devices, communicates with the surrounding patient condition monitoring devices to allow their connection using the activated WLAN 911. Accordingly, the patient condition monitoring devices 901 may be connected to the patient condition monitoring application 970 through the smartphone 921 and the mobile network 941 to continuously provide the patient condition monitoring service.

After the failure of the wired network 920 has been repaired and confirmed, the MNMBP 984 may be configured such that the patient condition monitoring devices 901 are connected to the M2M gateway 920 and the wired network 940 as requested by the patient condition monitoring service providers 991 and 992. ) To provide patient condition monitoring services.

As described above, in case of important patient condition monitoring service related to user's life, even if a failure occurs in the M2M gateway or the wired network, the service provision can be continued without interruption.

FIG. 10 is a flowchart illustrating a network management intermediation method in which an MNMBP analyzes a cause of a failure and provides an analysis result when a failure occurs in a power supply system in a region where an M2M device to an M2M gateway is installed.

First, from the process of collecting M2M management information and collecting network management information of steps S1001 to S1006, the process of MNMBP inquiring NMP of network failure and receiving related information as a response thereto is the same as that of steps S401 to S406 of FIG. 4. Therefore, detailed description will be omitted below.

If it is determined in step S1006 that the network has a failure, the MNMBP comprehensively analyzes the M2M management information and network management information received from the MMP and the NMP and provides the analysis result to an M2M service provider, a network service provider, or a user (step S1006). And S1015).

On the other hand, if it is determined that the network does not have a failure in step S1006, even if the network is normal, it is the case that the failure of the M2M device to the M2M gateway is received, the MNMBP is to analyze the cause of the failure, MNMBP as in step S1007 The FRP provides the fault related information, searches for an MFRD having a separate independent power supply, and requests M2M devices to connect through the MFRD having the independent independent power supply. Thereafter, in step S1008, the FRP requests the MMP for information on whether there is an MFRD having a separate independent power source at the failure location.

Here, if there is an MFRD having a separate independent power source, the FRP requests to activate an M2M regional network to which the MFRD having the separate independent power source can connect through the MMP and the second network (steps S1009 and S1011), and the M2M region. After the network is activated, M2M devices request to access the MFRD having the separate independent power source (step S1012).

In step S1009, if the MMP is notified from the MMP that there is no separate independent power source, the FRP requests the NMP the mobile device information to perform the function as the MFRD (steps S1009 and S1010) and the function as the MFRD from the NMP. The FRP receiving the mobile device information capable of performing the request requests the mobile device to activate the M2M local area network through the NMP and the second network (step S1011), and the mobile device as the MFRD receiving the request from the FRP receives the M2M local area. The network is activated, and a request for connection of surrounding M2M devices through the activated M2M local area network (step S1012).

Subsequently, in step S1013, M2M devices having a separate independent power source and capable of communicating with the M2M local area network may access an MFRD (MFRD or mobile device having a separate independent power source) to provide M2M management information to the MMP through the second network.

Finally, MNMBP receives and analyzes the current state of M2M management information, network management information and MFRD management information from MMP, NMP and / or FRP, and then analyzes the analysis results (location of failure, time of failure, cause of failure) and M2M service provider. To the network operator or the user (steps 1014 and S1015).

As described above, when the network does not fail and a plurality of M2M devices or M2M gateways fail, and only M2M devices having a separate independent power source can communicate with the MMP through the MFRD, the MNMBP is powered by a failure source. You will know exactly what you are in the system.

FIG. 11 illustrates a specific application example of a network management intermediation system in which an MNMBP analyzes a cause of a failure and provides an analysis result according to the embodiment described above with reference to FIG. 10 when a power supply system fails to provide M2M service. Illustrated.

In the application example of FIG. 11, the M2M device is a smart TV 1101, a refrigerator 1102, a power meter 1103, a gas meter 1104, other household appliances 1105, and the M2M application 1170 in the network domain is an M2M. As a local network of a wired network 1140, an M2M gateway 1120, and an M2M gateway as a first network utilizing a service capability 1160 and including access and core networks that may be connected through an M2M gateway 1120. This is the case when WLAN 1110 is used. It is also assumed that the MFRD is a smartphone 1121, and the WLAN 1111 as the M2M local area network to which the MFRD can be connected and the mobile network 1141 as the second network. In addition, the case where the M2M service provider is an M2M device installer / operator 1191 or an M2M service provider 1192 is illustrated.

Referring to FIG. 11, when the MMP detects an abnormal communication between the M2M gateway 1120, the smart TV 1101, the refrigerator 1102, other home appliances 1105, the power meter 1103, and the gas meter 1104, the MNMBP is detected. Notify the occurrence of the failure.

The MNMBP inquires of the NMP 1182 if there is a problem with the wired network 1140 in the region where the failure occurred. The MNMBP 1184 receiving the information that the wired network 1140 is normal from the NMP 1182 finds an MFRD having an independent power supply to the FRP 1183 to analyze the exact cause of the failure, and then provides a smart TV ( 1101, refrigerator 1102, other home appliances 1105, power meter 1103, and gas meter 1104 request to connect to MMP.

The FRP 1183 asks the MMP 1181 if there is an MFRD with a separate independent power source, and upon receiving a notification from the MMP 1181 that there is no MFRD with a separate independent power source, the FMP 1183 may request that the NMP 1118 have an MFRD enabled. Inquire about whether there is a mobile device 1121.

If the NMP 1182 determines that there is a smartphone 1121 as an MFRD at the location of the failure, the FRP 1183 sends the WLAN 1111 to the smartphone 1121 via the NMP 1182 and the mobile network 1141. Ask to be activated. The smartphone 1121, which activates the WLAN 1111 according to the request of the FRP 1183, includes a peripheral smart TV 1101 and a refrigerator 1102, other home appliances 1105, a power meter 1103, and a gas meter 1104. Request a connection through the wireless network 1141.

On the other hand, if the M2M device having a separate power source of the smart TV 1101 and the refrigerator 1102, other home appliances 1105, the power meter 1103 and the gas meter 1104 is only a gas meter 1104, a gas meter ( Only 1104 connects to the smartphone 1121 and transmits M2M management information to the MMP 1181. In this case, the MMP confirms that only the gas meter 1104 is normally communicated and that the smart TV 1101 and the refrigerator 1102, other home appliances 1105 and the power meter 1103 are not in communication, and transmits the relevant information to the MNMBP. to provide.

The MNMBP then correctly determines that the source of the failure is in the power supply system and then provides information on the failure and cause of the failure to the M2M service provider, which in this case may also include the power provider, power meter operator, or gas meter operator. By doing so, it is possible to provide fast and accurate after-sales service.

Although the exemplary embodiments of the present invention have been described in detail, it is not intended to limit the scope of the present invention, and various modifications can be made by those skilled in the art. After all, the scope of the present invention will be defined by the claims that follow.

Claims (13)

1. Receiving failure occurrence information from any one of an M2M Management Platform (MMP) collecting M2M management information and a Network Management Platform (NMP) collecting network management information; And

   And inquiring whether one of the MMP and the NMP has an M2M failure or a network failure and analyzing a cause of the failure.
2. The method of claim 1,

   The failure occurrence information includes at least one of information on a failure occurrence device, a failure location, and information on a subscriber of the failure location.
3. The method of claim 1,

   When receiving M2M failure occurrence information from the MMP, the network management mediation method, characterized in that the query for whether the network failure occurs to the NMP whether the failure occurs in the network associated with the location of the M2M failure.
4. The method of claim 3, wherein

   Requesting management information of another M2M device or another M2M gateway at the M2M failure location from the NMP, when it is determined that the failure does not occur in the network from the NMP.
5. The method of claim 1,

   In the case of receiving network failure occurrence information from the NMP, the inquiry about whether the M2M failure occurs to the MMP is a network management inquiry about whether a failure of an M2M device or an M2M gateway related to the location of the network failure occurs. Mediation method.
6. The method of claim 5,

   And requesting and receiving the latest management information of the M2M device or the M2M gateway from the MMP.
7. The method of claim 1,

   Requesting an FRP to continue service for the M2M device using a second network via an MFRD;

   The FRP is a network management brokerage method, characterized in that for requesting information of the MFRD to the MMP or the NMP based on the failure occurrence information.
8. The method of claim 7, wherein

   And when the MFRD information is not received from the MMP, receiving the MFRD information from the NMP.
9. The method of claim 7, wherein

   The MFRD requesting the MMP is an MFRD having an independent power source.
10. The method of claim 7, wherein

    If only M2M devices having independent power of the M2M device is connected through the MFRD, it is determined that the failure of the power supply system of the M2M device or the M2M gateway.
11. An MMP communication unit configured to receive M2M failure occurrence information from an M2M Management Platform (MMP) that collects M2M management information of an M2M device or an M2M gateway;

    An NMP communication unit configured to receive network failure occurrence information from an NMP (Network Management Platform) for collecting network management information of an access network and a core network; And

    A control unit which controls the MMP communication unit or the NMP communication unit to inquire whether one of the MMP and the NMP has an M2M failure or a network failure when receiving the failure occurrence information from any one of the NMP and the MMP; Network management brokerage system comprising a M2M & Network Management Brokering Platform (MNMBP) comprising a.
12. The method of claim 11,

    The MNMBP is a FRP (Fault Recovery) that inquires of the MMP or NMP whether there is an MFRD capable of connecting to a second access network or a second core network if the M2M device cannot connect to the first access network or the first core network. Platform) Network management mediation system further comprising a communication unit.
13. The method of claim 12,

    And when the FRP communication unit receives a response from the MMP that the MFRD does not exist in the failure area, the FRP communication unit inquires whether the MFRD exists in the NMP.

Images