KR101492006B1 - Network Management Brokering Method and System - Google Patents

Abstract

The network management mediation system according to an embodiment of the present invention includes an MMP communication unit for receiving 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 for receiving network failure occurrence information from an NMP (Network Management Platform) collecting network management information of the access network and the core network; And a controller for controlling the MMP communication unit or the NMP communication unit to inquire whether another one of the MMP and the NMP is an occurrence of an M2M failure or a network failure when receiving the failure occurrence information from any one of the NMP and the MMP, (M2M & Network Management Brokering Platform).

Description

[0001] Network Management Brokering Method and System [

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network management intermediation method and system, and more particularly, to a network management intermediation method and system using M2M and a network management brokering platform (M2M).

The development of modern information and communication technology is changing not only for computers but also for networking of smart phones and portable multimedia devices. However, small devices such as computation and communication networking functions used in such computers, smart phones, and the like enable a communication network between objects that are used not only in information devices but also in various objects around human beings to acquire and share information around them. In such a network environment, it is possible to communicate information between people and objects, and furthermore, between objects and objects as well as communication between people, and this is referred to as M2M (Machine-to-Machine) communication.

In the past, when the M2M in the late 1990s meant a one-to-one or many-to-many communication for simple point-to-point (P2P) connections, the meaning of M2M communication nowadays is to collect information read from sensors or wireless communication modules It defines the communication between the machines at the controlling level and the communication between the machines and the devices in which the people operate. However, ultimately, the goal of M2M communication is aiming at the quality and stability of improved M2M communication service by automatically operating without any human control by personal or situation customized by location recognition, situation recognition, introduction of augmented reality.

Currently, research and development for successfully standardizing M2M communication continues in the standardization groups of the world including European Telecommunication Standard Institute (ETSI). FIG. 1 shows ETSI TS (Technical Specification) 102 690 [Machine- to-Machine Communications (M2M); Functional architecture], and the architecture for a M2M service that includes the network domain and the device and gateway domains provided in Chapter 4.

Referring to FIG. 1, the M2M devices 10 and 10 'are terminals for communicating with no human input or intervention, or minimizing the input and interruption thereof. Type of device.

When the M2M device 10 'directly connects to the access network 40, the M2M application 12 (M2M application) 12' of the M2M device is accessed using the M2M service capability 11 of the M2M device 10 ' And when the M2M device 10 accesses the access network 40 through the M2M gateway 30, the M2M gateway 10 uses the M2M service capability 31 of the M2M gateway 30 to access the M2M gateway 10 30 of the M2M application 32 are used.

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 include a Personal Area Network (PAN) or a Wireless Local Area Network (LAN) such as IEEE 802.15.x, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, Area Network (hereinafter, referred to as 'WLAN'), PLC, M-BUS, Wireless M-BSU, and KNX.

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

The access network 40 is a network that allows the M2M devices 10 'through M2M gateways 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 include 3GPP CN, ETSI TISPAN CN, 3GPP2 CN, and IMS.

The M2M service capability 60 of the network domain provides functions that can be shared by different applications and provides an environment for accessing other service capabilities through an open interface. Using M2M service capabilities, it enables the development and deployment of optimal applications without taking into account the characteristics of the subnetwork layer.

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

Meanwhile, according to FIG. 1, the network domain is defined to include M2M management functions and network management functions. Here, the M2M management functions 80 are configured with all the functions required to manage M2M service capabilities in the network domain, and the management of the M2M devices to the M2M gateway utilizes a specific M2M service capability . Network management functions 90 are also comprised of all the functions required to manage the access network 40 and the core network 50 and include provisioning, supervision, fault management, And the like.

The reason why the M2M management function and the network management function are separated from the ETSI standard as described above is that the operator who installs and operates the M2M device and / or the M2M gateway or the provider that provides the M2M service (hereinafter referred to as the 'M2M service provider' , Or a user using the M2M service provides the M2M service using the existing access and core network is a general configuration of the M2M network. Hereinafter, a service provider that manages and manages an existing access and core network is identified as a network service provider.

Although the M2M management functions and the network management functions required to provide the M2M service are defined according to the ETSI standard according to the above-described conventional technology, the procedures for providing and using the functions are detailed And that provision of management functions is also not mandatory to provide M2M services. Accordingly, when the network service provider does not provide the network management functions, the M2M service provider can not accurately grasp the network status, and there is a problem that there is an error in the M2M service failure response. Also, there is a problem that the management functions of the mobile device can not be used when the mobile device capable of managing the M2M device is not registered as the M2M device in the specific area.

2 shows a prior art disclosed in Korean Patent Publication No. 10-2005-0071761, filed as " Method and system for providing after-sales service for network devices ". According to the related art, the central management center system 440 receives information from a plurality of network devices 410, ..., 415 (corresponding to M2M devices of M2M communication), which are information collecting devices 420, It is possible to continuously receive and analyze the status information of each network device via the network 430 to determine whether the cause of the failure exists in the network device or not in the network and provide the result to the A / S center system 460, And improving service accuracy.

However, according to the above-described conventional technology, the presence or absence of a network failure is indirectly checked from the information collected by the plurality of network devices 410, ..., and 425, so that the cause and problem of the network failure can not be accurately grasped, There is a problem that there is an error in service processing. In addition, when a failure occurs in the network, it is impossible to confirm whether or not a failure occurs in the M2M device or the M2M gateway until the network is restored, and there is a problem that it is impossible to manage and analyze an additional failure occurrence. In addition, even when a failure occurs in the entire power supply system and the network device and the gateway can not connect to the access network, there is a problem that it is impossible to distinguish whether the failure is caused by a network, a network device, a gateway, or a power supply system.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problems of the related art, and it is an object of the present invention to collect management information of an M2M device and an M2M gateway from an M2M management platform, A network management mediation system including an M2M and a network management mediation platform (MNMBP) that collects information to accurately analyze the location and cause of a failure in case of a failure of the M2M service and provide the analysis result to the M2M service provider or the user, The present invention is directed to providing a method for providing a service to a user.

When a failure occurs in the first network to which the M2M device or the M2M gateway is connected, the second network is accessed using the device information, the location information, or the subscriber information of the M2M device or the mobile device collected from the M2M management platform and the network management platform And an M2M Failover Platform (FRP) for activating these capable devices and allowing M2M devices to maintain M2M services over a second network.

According to an embodiment of the present invention, there is provided a network management mediation method for managing an MMC (M2M Management Platform) for collecting M2M management information and an NMP (Network Management Platform) for collecting network management information Receiving fault occurrence information; And inquiring whether another one of the MMP and the NMP has an M2M failure or a network failure and analyzing the cause of the failure.

According to another aspect of the present invention, there is provided a network management mediation system comprising: an MMP (M2M Management Platform) for collecting M2M management information of an M2M device or an M2M gateway, A communication unit; An NMP communication unit for receiving network failure occurrence information from an NMP (Network Management Platform) collecting network management information of the access network and the core network; And a controller for controlling the MMP communication unit or the NMP communication unit to inquire whether another one of the MMP and the NMP is an occurrence of an M2M failure or a network failure when receiving the failure occurrence information from any one of the NMP and the MMP, (M2M & Network Management Brokering Platform).

Wherein the MNMBP is an FRP (Fault) that asks the MMP or NMP if there is an MFRD that is capable of connecting to the second access network or to the second core network if the M2M device can not connect to the first access network or the first core network. Recovery Platform) communication unit.

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

In addition, according to the network management mediation method and system according to the embodiments of the present invention, when a failure occurs in the first network to which the M2M device to the M2M gateway are connected, the M2M service can be continuously maintained through the second network.

Figure 1 illustrates an architecture for providing M2M services according to the prior art of the ESTI standard.
2 illustrates a method of providing an after-sales service for a network device according to another prior art.
3A is a schematic configuration diagram of a network management mediation system 380 including an M2M and a network management mediation platform (MNMBP) 384 according to an embodiment of the present invention, and FIG. 3B is a block diagram of a MN management system Fig.
FIG. 4 illustrates a network management mediation method according to an exemplary embodiment of the present invention. In FIG. 4, when a failure occurs in the M2M device to the M2M gateway, MNMBP analyzes the failure cause and provides analysis results.
FIG. 5 shows a specific application example of a network management mediation system in which the MNMBP analyzes a failure cause and provides analysis results according to an embodiment described with reference to FIG. 4 when a failure occurs in the M2M device to the M2M gateway.
6 is a flowchart illustrating a network management mediation method in which the MNMBP analyzes a failure cause and provides analysis results according to an embodiment of the present invention when a failure occurs in a network other than the M2M device to the M2M gateway and the M2M service is not provided. to be.
FIG. 7 shows a specific application example of a network management mediation system in which the NMBP analyzes the failure cause and provides analysis results according to the embodiment described with reference to FIG. 6 when a failure occurs in the network.
8A and 8B are flowcharts of a network management mediation method for providing an M2M failover service so that the M2M service can continue to be provided according to an embodiment of the present invention when a failure occurs in an M2M gateway or a network.
9 is a specific application example of a network management mediation system that provides an M2M fail-over service so that the M2M service can be continued according to the embodiment described with reference to FIGS. 8A and 8B when a failure occurs in the M2M gateway to the first network / RTI >
FIG. 10 shows a flowchart of a network management mediation method in which an MNMBP analyzes a failure cause and provides analysis results according to an embodiment of the present invention when a failure occurs in a power supply system in an area where an M2M device to an M2M gateway are installed.
11 shows a specific application example of the network management mediation system in which the MNMBP analyzes the cause of the failure and provides the analysis result according to the embodiment described with reference to FIG. 10 when the failure of the power supply system causes the M2M service to become impossible Respectively.

Best Mode for Carrying Out the Invention Preferred embodiments of the present invention are described below with reference to the drawings. Note that like reference numerals in the drawings indicate similar configurations.

3A is a schematic configuration diagram of a network management mediation system 380 including an M2M and a network management mediation platform (MNMBP) 384 according to an embodiment of the present invention, and FIG. 3B is a block diagram of a MN management system Fig.

3A, the M2M devices 1 to N (301, 302, 303, 304, ... 305), the M2M regional networks 310 and 311, the M2M gateway 320, the access networks 330 and 331, 342, M2M Servive Capabilities 360, and M2M application 370 are the same as those described above with reference to FIG. 1, and a detailed description thereof will be omitted. 3A, it is described that the M2M devices 301, 302, 303, 304, and 305 access the access network 330 through the M2M gateway 320. However, as shown in FIG. 1, Or access the direct access network without going through. However, the network indicated by reference numeral 350 is separately shown to indicate that it is a network providing inter-network interconnection, IP connection, connection with a service platform, and the like, and may include ATM, IP network, and the like.

The M2M management platform 381 (hereinafter referred to as the 'MMP') is a platform that can be constructed either by the M2M service provider in general or separately for the M2M service provider, as M2M devices 301, 302, 303, 304 , 305) to the M2M gateway 320 (hereinafter, referred to as 'M2M management information'). The MMP 381 provides the M2M management information to the M2M and the Network Management Brokering Platform (MNMBP) 384. The MMP 381 may collect the 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 information about the M2M device information (device ID, resource, location, subscriber, authentication, security, fault management, access network, access M2M device, information about the connected M2M gateway, (Information on the ID, resource, location, subscriber, authentication, security, fault management, access network, access M2M device, etc.) of the gateway.

A network management platform 382 (hereinafter referred to as an 'NMP') is a platform that can be deployed by a network service provider or separately constructed for a network service provider, as an access network 320, 321 and a core network 340, and 341) (hereinafter, referred to as 'network management information'). The NMP 382 may collect and provide network management information at the request of the MNMBP 384 or irrespective of the request of the MNMBP 384. [ The network management information collected by the NMP 382 includes access network status information (traffic status, failure management, subscriber access status, access network device status, and the like) and core network status information (traffic status, Device status, etc.).

The NMP 382 also collects information and subscriber information about mobile devices (e.g., mobile phones, mobile pads, mobile gateways, etc.) in the M2M service area that are not registered in the MMP 381, You can also provide this if you have a request. In addition, in a situation where the subscriber of the M2M service agrees, it may provide necessary functions to remotely control the mobile device through another platform.

The M2M fault recovery device 321 is capable of communicating with the M2M devices 301, 302, 303, 304 and 305 through the M2M local network 311, Is a device capable of providing an M2M gateway function by being able to connect to the first access network 330 connected to the M2M gateway 310 or a second access network 331 other than the first access network 330. [ In addition, if the MFRD is equipped with a separate independent power source such as a battery, the access network and the M2M local network connection may be possible even if the power supply system of the M2M device and the gateway installation area fails. Examples of MFRDs may include second M2M gateways, mobile phones, mobile pads, mobile gateways (e.g., WiBro EGG, etc.) that provide the same functionality as M2M gateway 320. If the user does not register the MFRD 321 as an M2M device, the MMP 381 can not directly collect management information on the MFRD 321 as an M2M device. However, the MFRD 321 must register The NMP 382 can acquire the MFRD management information even if the MFRD 321 is not registered as the M2M device.

The failure recovery platform 383 (hereinafter referred to as 'FRP') is a system in which a failure occurs in the first network (the first access network and the first core network) 330 and 340, The MMP 381 to the NMP 382 confirm whether the MFRD 321 is in the fault occurrence area and then the MFRD 321 activates the M2M local network when the MFRD 321 is in the fault occurrence area And provides M2M device information of the failure occurrence area so that the M2M devices in the failure occurrence 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 via the MNMBP 384 as described below.

The MNMBP 384 correctly analyzes the failure location and the cause of failure occurring when using the M2M service using the M2M management information provided by the MMP 381 and the network management information provided by the NMP 382, To the service provider (M2M device installer / operator 391 or M2M service provider 392), network service provider 393 or user, thereby enabling quick and accurate failure response and after-service. In addition, when the M2M service provider requests the failure recovery service for the network failure, the MNMBP 384 provides the failure recovery service using the FRP 383 and the MFRD 321. The MNMBP 384 may need a trust relationship with the MMP provider (i.e., the M2M service provider) to use the M2M management information of the MMP 381. In order to use the network management information of the NMP, Network service provider) may need a trust relationship.

3B, 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, a service provider 3846 And a service receiving unit 3847, as shown in FIG.

The MMP communication unit 3842 carries out communication with the MMP 381 and receives M2M management information from the MMP 381 or requests the MMP 381 to provide M2M management information. The NMP communication unit 3843 takes charge of communication with the NMP 381 and receives network management information from the NMP 382 or requests the NMP 382 to provide network management information. The FRP communication unit 3844 takes charge of communication with the FRP 383 for providing a fault recovery service.

The analysis unit 3845 analyzes the cause of the failure 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 failure recovery service using the subscriber information subscribed to the failover service, the location information of the MFRD, and the M2M device information.

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

The service receiving unit 3847 provides a function of receiving a fault analysis service or a fault recovery service from an M2M service provider, a network service provider, or a user and processing the received fault analysis service or fault recovery service.

The control unit 3841 controls all the components as described above by the MNMBP 384 to perform a failure analysis result through the MNMBP and a series of procedures related to the provision of the failback service.

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

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

In step S402, the NMP communicates with the access network constituting apparatuses and the core network constituting apparatuses, or the network of the access network or the core network, frequently communicating with network management systems (hereinafter, referred to as 'NMS' It is possible to collect management information and also collect information about mobile devices not registered in the MMP.

If no failure occurs in the M2M device to the M2M gateway in step S403, the MMP and the NMP respectively continue collecting the M2M management information and collecting the network management information (steps S403 and S401). If a failure occurs in the M2M device to the M2M gateway, Receives the communication abnormality with the generated M2M device or M2M gateway, or receives the status abnormality information provided by the M2M device or M2M gateway, and notifies the MNMBP of the occurrence of the failure (steps S403 and S404). The failure information provided by the MMP to the MNMBP may include information about the failed device, information about the location of the failure, and subscriber information.

In step S405, the MNMBP, using 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 sends the related information from the NMP as a response thereto .

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

In step S406, upon receiving the information that the network is normal from the NMP, the MNMBP requests latest management information of the other M2M devices or other M2M gateways located in the area where the failure occurred, in step S407.

In step S408, the MMP requesting the latest management information of another M2M device or another M2M gateway from the MNMBP requests latest management information from the other M2M device or another M2M gateway, receives the latest management information, and provides the latest management information to the MNMBP. The reason for additionally checking the latest management information of the other M2M devices or other M2M gateways in step S408 is to improve the accuracy of the failure cause analysis.

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

In the case of the above-described embodiment, it is possible to accurately know that a failure has occurred in the network and that a failure has occurred in the M2M device or the M2M gateway. Therefore, the network service provider can provide the M2M service provider To provide a failover service of the failed M2M device to the M2M gateway.

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

FIG. 5 shows a specific application example of a network management mediation system in which, when a failure occurs in the M2M device to the M2M gateway, the MNMBP analyzes the failure cause and provides analysis results 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, 560, and is a wired network 540, including an access and core network, an M2M gateway 520, and a WLAN 510 as an M2M local network, and wherein the M2M service provider uses a power meter Installer / operator 591 or a utility company 592. [

Hereinafter, a case where the MMP 581 detects a failure that the power meter reading information is not received from the power meter reader 501 will be described.

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

Upon receiving the notification of the occurrence of the failure, the MNMBP (583) inquires the NMP (582) whether a failure has occurred in the area network where the power meter (501) is installed.

When the MNMBP 584 receives information indicating that the network is normal from the NMP 582, the MNMBP 584 informs the MMP 581 of the other M2M devices in the area where the power meter 501 is installed (for example, the gas meter 502, The refrigerator 504, the other home appliances 505, etc.). 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 that has confirmed that the other M2M devices are normal provides failure occurrence information of the power meter 51 to the power meter installer / operator 591 to the power company 592 or the like.

Therefore, the electric power meter installer / operator 591 to the electric power company 592 are not notified of the failure of the electric power meter but the after-service according to the notification.

6 is a flowchart illustrating a network management mediation method in which the MNMBP analyzes a failure cause and provides analysis results according to an embodiment of the present invention when a failure occurs in a network other than the M2M device to the M2M gateway and the M2M service is not provided. to be.

Referring to FIG. 6, the MMP collects M2M management information by frequently communicating with the M2M device and the M2M gateway through the core network and the access network, and for the M2M devices which are not directly connected to the access network, And collects the M2M management information (step S601).

In addition, the NMP collects network management information for the access network and the core network (step S602) while frequently communicating with the NMSs established by the network service providers for the network constituent devices or the networks constituting the access network and the core network.

Thereafter, when a failure occurs in the access network or the core network, the NMP collects the network failure information and notifies the MNMBP of the failure occurrence and provides failure information (steps S603 and S604). The failure occurrence information that the NMP provides to the MNMBP may include information about the failed network configuration device, information about the failure location in the network, and subscriber information.

In step S605, the MNMBP checks whether the M2M failure occurrence information is received from the M2M device or the M2M gateway from the MMP. If the M2M failure occurrence information is received from the MMP, the MNMBP comprehensively analyzes the management information received from the MMP and the NMP And provides the analysis result to the M2M service provider, the network service provider, or the user (steps S605 and S608).

In step S605, if the MNMBP does not receive the M2M failure occurrence information from the MMP as a result of checking whether the M2M failure information is received from the M2M device or the M2M gateway from the MMP, the MNMBP uses the network failure occurrence information received from the NMP In step S606, the MMP inquires as to whether a failure has occurred in the M2M device or the M2M gateway existing in the network where the failure occurs.

The MMP requesting the M2M management information of the M2M device or the M2M gateway at the location of the failed network from the MNMBP requests the latest M2M management information to the M2M device or the M2M gateway at the above location and provides the latest M2M management information to the MNMBP Step S607).

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

In this case, since the M2M device and the M2M gateway can not know that the failure has occurred in the network, the M2M service provider is not required to request recovery according to the failure, The accuracy of the service can be increased, and the M2M service provider can respond accurately to customer inquiries about the disability, thereby increasing the reliability of the service.

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

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 of the network domain has the M2M service capability 760, And the WLAN 710 is used as the M2M local network, and the M2M service provider uses the home appliance application 770, which includes the access and core network, An operator 791 or a home appliance service provider 792. [

Hereinafter, an example in which a failure has occurred in the wired network 740 of a subscriber who subscribes to a home appliance service will be described as an example.

First, the NMP 782 notifies MNMBP 783 of the occurrence of a failure in the wired network 740 when it detects that a failure has occurred in the wired network 740 of the subscriber.

The MNMBP 783 uses the failure occurrence information in the wired network 740 received from the NMP 783 to recognize that a fault has occurred in the wired network of the subscriber and notifies the M2M device connected to the wired network of the subscriber and the M2M The MMP 782 inquires whether the gateway has failed.

The MMP 782 confirms that the home appliance such as the smart TV 701 at the failure occurrence position of the subscriber is registered as the M2M device using the network failure information received from the MNMBP 783, (701) to the home appliance.

The MMP 781 will not be able to receive the M2M management information from the home appliance such as the smart TV 701 because the wired network has failed. Therefore, the MMP 781 transmits the malfunction information of the home appliance such as the smart TV 701 to the MNMBP 783). The MNMBP 783 which correctly confirms that the cause of the failure exists in the network is connected to the home appliance installer / operator 791, home appliance service provider 792, network service provider 793 or user 794 such as the smart TV 701 Notifies that the M2M service is suspended due to a network failure.

The network service provider 793 that has confirmed the M2M service failure due to the network failure from the MNMBP 783 can restore the failure of the failed network. The home appliance installer / 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 failure cause information and informs the customer center about the customer claim So that it can be appropriately responded.

8A and 8B are flowcharts of a network management mediation method for providing an M2M failover service so that the M2M service can continue to be provided according to an embodiment of the present invention when a failure occurs in an M2M gateway or a network.

First, the M2M service provider or the user requests the MNMBP for a fail-over service so that the M2M service can be continuously used even if a failure occurs in the M2M gateway or the network (step S801). Such a request may be made in advance in the form of an M2M Failover Service Agreement with the user.

In step S802, the MMP collects M2M management information by communicating with the M2M device and the M2M gateway through the core network and the access network from time to time, and information about the M2M devices that are not directly connected to the access network includes the M2M gateway and the M2M local network Collect M2M management information through

Further, in step S803, the NMP collects network management information for the access network and the core network from time to time, for example, with respect to the network constituent devices constituting the access network and the core network, and the NMS constructed by the network service provider do.

If no failure occurs in the M2M gateway or the network, the MMP and the NMP continue to collect the M2M management information and the network management information, respectively (steps S804 and S802).

When a failure occurs in the M2M gateway or the network, the MMP or NMP receives the failure occurrence information and notifies the MNMBP of the failure occurrence (steps S804 and S805). The failure occurrence information provided by the MMP or NMP to the MNMBP may include information on the failed device, information on the failure occurrence location, subscriber information, and the like.

Upon receiving the failure occurrence, the MNMBP determines whether there is an M2M service or a subscriber who subscribed to the failure recovery service from the failure occurrence information, and then requests the FRP to recover the failure if there is an M2M service or a subscriber subscribed to the failure recovery service (step S806) . At this time, MNMBP can provide M2M device information, subscriber information, M2M service information, and the like necessary for providing a failover service together with FRP.

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

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

The FRP that has received the MFRD information notifies the MFRD via the MMP or the NMP via the network to which the MFRD is connectable (hereinafter referred to as a 'second network') instead of the faulty network (hereinafter referred to as the 'first network' Requesting activation of an M2M local network that can be activated and requesting 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 the MMP or the communication between the FRP and the NMP may be performed directly or through the MNMBP. When the M2M area network is activated by the MFRD, in step S811, the M2M device requests access to the M2M devices through the M2M area network in which the MFRD is activated by using the information of the M2M devices subscribed to the failure recovery service from the FRP.

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

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

If the failure of the M2M gateway or the first network is restored, the M2M devices providing the M2M service through the MFRD and the second network may perform the M2M service through the first network with the M2M gateway according to 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 a default value set at the time of requesting a fail-over service subscription or a fail-over service, or may use the value requested by the M2M service provider or the user depending on the situation.

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

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

The MNMBP that has confirmed that the failure of the failed M2M gateway or the first network has been restored can provide the M2M service through the first network or the second network according to the request of the M2M service provider or the user.

If the M2M service provider or the user continuously wishes to provide the M2M service to the MFRD and the second network even if the failure of the M2M gateway or the first network is restored, the MNMBP sends the failure recovery result and management information of the M2M gateway / To the M2M service provider or user subscribed to the failover service (steps S816 and S824).

If the failure of the M2M gateway or the first network is restored and it is desired to provide the M2M service through the M2M gateway and the first network, the FRP may request the M2M devices connected to the MFRD through the MMP or NMP and the second network to the M2M gateway (Step S817).

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

In step S821, the FRP confirms that the M2M service is normally provided through the first network. The FRP requests the MFRD to disable the M2M local network using the MMP or the NMP and the second network. In step S822, the MFRD requests the M2M local network And then transmits the deactivation result of the M2M local network to the FRP, the MMP or the NMP through the second network.

Finally, MNMBP receives M2M service status information, network status information, MFRD status information from MMP, NMP and / or FRP, analyzes it, and transmits analysis result and recovery result to M2M service provider or user (Steps S823 and S824).

9 is a specific application example of a network management mediation system that provides an M2M fail-over service so that the M2M service can be continued 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 / RTI >

9, the M2M device is one or more patient status monitoring devices 901, the M2M application in the network domain is a patient status monitoring application 970 using the M2M service capability 960, and the M2M gateway 920 A WLAN 910 is used as an M2M local network capable of connecting to a wired network 940, an M2M gateway 920, and an M2M gateway 920 as a first network including an access and core network that can be accessed . The MFRD is also a smartphone 921 and assumes a WLAN 911 as an M2M local 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 a patient condition monitoring device installation / operator 991 or a patient condition monitoring service provider 992.

Here, the patient condition monitoring service monitors a patient's condition through a patient condition monitoring device (blood pressure meter, blood glucose meter, heart rate monitor, etc.) installed in a patient's body or a patient's activity area, and informs emergency authorities of emergency situations when an emergency occurs . Since the patient condition monitoring service is an important service related to the life of the user, it is desirable that the service can be continued even when a failure occurs in the M2M gateway or the wired network.

An M2M service provider 991 or 992 or a user 994 providing a patient condition monitoring service first requests the MNMBP 984 for an M2M failover service.

When a failure occurs in the wired network 940 providing the patient condition monitoring service, the NMP 981 to the MMP 982 confirm the occurrence of the failure and notify the MNMBP 984 of the occurrence of the failure.

When the MNMBP 984 recognizes that a failure occurs in the M2M service subscribed to the failure recovery service, the MNMBP 984 requests the FRP 983 to recover the failure.

The FRP 983, which has verified the fault recovery service type and subscriber information from the MNMBP 984, requests the MMP 981 for MFRD information.

If it is confirmed from the MMP 981 that there is no MFRD in the first network in which the failure occurs, the FRP 983 requests the NMP 982 for MFRD information of the smartphone 921 capable of performing the function as the MFRD. The NMP 982 provides the smartphone information to the FRP 983 that can perform the function as the MFRD based on the failure related information received from the FRP 983. [

The FRP 983 receiving the smartphone information from the NMP 982 communicates with the smartphone 921 through the NMP 982 and the mobile network 941 and transmits the WLAN-based M2M local network 911). The FRP 921, which has received information indicating that the WLAN activation is completed from the smart phone 921, provides information of the patient condition monitoring devices 901 to the smartphone 921.

The smartphone 921 receiving the information of the patient condition monitoring devices communicates with surrounding patient condition monitoring devices using the activated WLAN 911 to allow their connection. Thus, the patient condition monitoring devices 901 can be connected to the patient condition monitoring application 970 via the smartphone 921 and the mobile network 941 to continuously provide patient condition monitoring services.

The MNMBP 984 that has recovered from the failure of the wired network 920 has confirmed that the patient status monitoring devices 901 are connected to the M2M gateway 920 and the wired network 940 ) To provide patient condition monitoring services.

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

FIG. 10 shows a flowchart of a network management mediation method in which, when a failure occurs in a power supply system in an area in which an M2M device to an M2M gateway are installed, the MNMBP analyzes the cause of the failure and provides analysis results to another embodiment of the present invention.

First, from the process of collecting M2M management information and collecting network management information in steps S1001 to S1006, the MNMBP inquires the NMP about the occurrence of a network failure and receives the related information as a response regarding the same, as in steps S401 to S406 of FIG. The detailed description will be omitted.

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

Meanwhile, if it is determined in step S1006 that no failure has occurred in the network, MNMBP receives a failure in the M2M device or the M2M gateway despite the normal network. Therefore, in order to analyze the cause of the failure correctly, MNMBP Provides the fault related information to the FRP, searches for an MFRD having a separate independent power source, and requests the M2M devices to access the MFRD having the separate independent power source. Thereafter, in step S1008, the FRP requests the MMP to inquire whether there is an MFRD having a separate independent power source at the failure occurrence position.

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

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

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

Finally, the MNMBP receives and analyzes the current M2M management information, network management information and MFRD management information from the MMP, NMP and / or FRP, and then transmits the analysis results (failure location, failure occurrence time, , Network operator or user (steps 1014 and S1015).

As described above, when a failure occurs in a network and a plurality of M2M devices to M2M gateways fail, and only M2M devices having independent power sources can communicate with the MMP via the MFRD, So that it can be accurately grasped that it is in the system.

11 shows a specific application example of the network management mediation system in which the MNMBP analyzes the cause of the failure and provides the analysis result according to the embodiment described above with reference to FIG. 10 when the failure of the power supply system occurs and the M2M service becomes impossible Respectively.

11, the M2M device is a smart TV 1101, a refrigerator 1102, a power meter 1103, a gas meter 1104, and other home appliances 1105, and the M2M application 1170 in the network domain is an M2M As a local network of the wired network 1140, the M2M gateway 1120, and the M2M gateway, as the first network, including the access and core network, which can be accessed via the M2M gateway 1120 using the service capabilities 1160 WLAN 1110 is used. The MFRD is a smartphone 1121, and assumes a WLAN 1111 as an M2M area network and a mobile network 1141 as a second network to which an MFRD can be connected. And the M2M service provider is the M2M device installer / operator 1191 or the M2M service provider 1192.

11, when the MMP detects an abnormality in 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, And notifies the occurrence of the failure.

The MNMBP queries the NMP 1182 if there is a problem with the wired network 1140 in the area where the failure occurred. The MNMBP 1184 receiving the information that the wired network 1140 is normal from the NMP 1182 searches the FRP 1183 for an MFRD having a separate independent power source to analyze the cause of the correct failure, 1101, the refrigerator 1102 and other appliances 1105, the electric power meter 1103 and the gas meter 1104 to be connected to the MMP.

The FRP 1183 inquires of the MMP 1181 whether there is an MFRD having a separate independent power source and when the MMP 1181 is informed that there is no MFRD having a separate independent power source from the MMP 1181, Inquires whether the mobile device 1121 exists.

The FRP 1183 transmits the WLAN 1111 to the corresponding smartphone 1121 via the NMP 1182 and the mobile network 1141 when confirming that the smartphone 1121 exists as the MFRD at the fault occurrence position from the NMP 1182 Activate. The smartphone 1121 activating the WLAN 1111 at the request of the FRP 1183 is connected to the surrounding smart TV 1101 and the refrigerator 1102 and other home appliances 1105 and the power meter 1103 and the gas meter 1104 ) Through the wireless network 1141. [0064]

If the M2M device having a separate power source among the smart TV 1101, the refrigerator 1102 and other home appliances 1105, the power meter 1103 and the gas meter 1104 is only the gas meter 1104, 1104 only connect to the smartphone 1121 and transmit M2M management information to the MMP 1181. In this case, only the gas meter 1104 communicates normally, and the MMP confirms that the smart TV 1101, the refrigerator 1102, the other home appliances 1105 and the power meter 1103 are not in communication, and sends the related information to the MNMBP to provide.

After the MNMBP has correctly identified that the cause of the failure is in the power supply system, the MNMBP provides information on the occurrence of the failure and the cause of the failure to the M2M service provider (in this case, the power supply provider, the electricity meter reader, or the gas meter reader) Thus, it is possible to provide prompt and accurate after-sales service.

While the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims. As a result, the scope of the present invention should be defined by the following claims.

380, 580, 780, 980, 1180: Network management mediation system
381, 581, 781, 981, 1181: MMP
382, 581, 781, 981, 1182: NMP
383, 983, 1183: FRP

Claims (13)

Receiving failure occurrence information from any one of an MMP (M2M Management Platform) for collecting M2M management information and an NMP (Network Management Platform) for collecting network management information; And
When receiving the M2M failure occurrence information from the MMP, further inquires the NMP about whether or not a failure has occurred in the network related to the occurrence position of the M2M failure,
When the network failure occurrence information is received from the NMP, the MMP further inquires of the M2M device or the M2M gateway regarding the occurrence of the failure related to the occurrence position of the network failure and analyzes the cause of the failure occurrence. Network management brokerage method. The method according to claim 1,
Wherein the failure occurrence information includes at least one of information on a failure occurrence device, a failure occurrence location, and information on a subscriber at the failure occurrence location. delete The method according to claim 1,
And requesting management information of another M2M device or another M2M gateway at the M2M failure location with the MMP if it is determined from the NMP that no failure has occurred in the network. delete The method according to claim 1,
And requesting and receiving the latest management information of the M2M device or the M2M gateway by the MMP. The method according to claim 1,
Further comprising: requesting the FRP to continue servicing the M2M device using a second network via the MFRD,
Wherein the FRP requests information of the MFRD to the MMP or the NMP based on the failure occurrence information. 8. The method of claim 7,
And if the information of the MFRD is not received from the MMP, the information of the MFRD is received from the NMP. 8. The method of claim 7,
Wherein the MFRD requesting the MMP is an MFRD with an independent power source. 8. The method of claim 7,
Wherein when the M2M device is connected to the M2M device via the MFRD only, the power supply system of the M2M device or the M2M gateway fails. An MMP communication unit for receiving M2M failure occurrence information from an MMP (M2M Management Platform) that collects M2M management information of the M2M device or the M2M gateway;
An NMP communication unit for receiving network failure occurrence information from an NMP (Network Management Platform) collecting network management information of the access network and the core network; And
When receiving the M2M failure occurrence information from the MMP, further inquires the NMP about whether or not a failure has occurred in the network related to the occurrence position of the M2M failure,
And a control unit for controlling the MMP communication unit or the NMP communication unit to further inquire whether the M2M device or the M2M gateway related to the occurrence of the network failure has occurred in the MMP when the network failure occurrence information is received from the NMP (M2M & Network Management Brokering Platform). ≪ / RTI > 12. The method of claim 11,
If the M2M device is unable to connect to the first access network or the first core network, the MNMBP determines whether there is an MFRD that can access the second access network or the second core network, Platform) communication unit. 13. The method of claim 12,
Wherein the FRP communication unit inquires whether the MFRD is present in the NMP if the MMP receives a response indicating that no MFRD exists in the failure occurrence area.

Images