WO2014017720A1 - Procédé et système de courtage de gestion de réseau - Google Patents

Procédé et système de courtage de gestion de réseau Download PDF

Info

Publication number
WO2014017720A1
WO2014017720A1 PCT/KR2013/001232 KR2013001232W WO2014017720A1 WO 2014017720 A1 WO2014017720 A1 WO 2014017720A1 KR 2013001232 W KR2013001232 W KR 2013001232W WO 2014017720 A1 WO2014017720 A1 WO 2014017720A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
failure
mmp
information
nmp
Prior art date
Application number
PCT/KR2013/001232
Other languages
English (en)
Korean (ko)
Inventor
손의승
박재형
구범모
장덕문
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Publication of WO2014017720A1 publication Critical patent/WO2014017720A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • 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.
  • M2M Machine-to-Machine
  • M2M used to mean one-to-one or one-to-many communication for simple point-to-point (P2P) connections.
  • 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.
  • 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.
  • FIG. 1 shows the ETSI Technical Specification (TSSI) 102 690 [Machine-] in the ESTI standard document.
  • TSSI ETSI Technical Specification
  • M2M to-Machine Communications
  • Functional architecture shows architecture for M2M services including device and gateway domains and network domains.
  • 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.
  • the 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).
  • PAN personal area network
  • LAN wireless local area network
  • PLC 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.
  • the network domain is defined to include M2M Management Functions and Network Management Functions.
  • 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.
  • 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.
  • M2M service provider 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).
  • M2M service provider an operator providing M2M service
  • 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.
  • a service provider operating and managing an existing access and core network is classified as a network service provider.
  • 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.
  • 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".
  • 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.
  • 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.
  • 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.
  • 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.
  • M2M and Network Management Mediation Platform MNMBP
  • 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.
  • FRP M2M Failover Platform
  • Network management mediation method 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.
  • M2M Management Platform M2M Management Platform
  • NMP Network Management Platform
  • the network management mediation system 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.
  • MNMBP M2M & Network Management Brokering Platform
  • 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.
  • FRP FRP
  • the network management intermediation method and system 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.
  • the M2M service 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.
  • FIG 1 illustrates an architecture for providing M2M services according to the prior art of the ESTI standard.
  • FIG. 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
  • FIG. 3B is an MNMBP 384 of FIG. 3A.
  • MNMBP Network Management Mediation Platform
  • 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.
  • 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
  • FIG. 3B is an MNMBP 384 of FIG. 3A.
  • MNMBP Network Management Mediation Platform
  • 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.
  • M2M servicingve 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.
  • the M2M devices 301, 302, 303, 304, and 305 are described as connecting to the access network 330 through the M2M gateway 320.
  • 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").
  • 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").
  • MNMBP M2M & Network Management Brokering Platform
  • 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.).
  • 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.
  • mobile devices eg, mobile phones, mobile pads, mobile gateways, etc.
  • 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.
  • 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.
  • FRP Fault Recovery Platform 383
  • FRP Fault Recovery Platform 383
  • the FRP 383 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).
  • MMP provider ie, an M2M service provider
  • NMP provider ie, in order to use NMP network management information.
  • a trust relationship with the network service provider may be required.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the MNMBP 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.
  • 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.
  • 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).
  • the MNMBP 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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
  • 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
  • an installer / operator 591 or a power company 592 is shown.
  • 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.
  • the MNMBP 584 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • 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).
  • the M2M service provider 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the MMP and the NMP continue to collect M2M management information and network management information, respectively (step S804 and step S802).
  • 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.
  • the MNMBP 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).
  • 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).
  • 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.
  • 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”)
  • the second network not the network where the failure
  • the communication between the FRP and MMP or the communication between the FRP and NMP may be made directly or through the MNMBP.
  • step S811 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • the M2M service provider is the patient condition monitoring device installer / operator 991 or the patient condition monitoring service provider 992.
  • 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.
  • a patient condition monitoring device blood pressure monitor, blood glucose meter, heart rate monitor, etc.
  • 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.
  • the NMP 981 to MMP 982 confirms the occurrence of a failure and notifies the MNMBP 984 of the failure situation.
  • 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.
  • the FRP 983 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • step S1006 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.
  • 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.
  • M2M devices request to access the MFRD having the separate independent power source (step S1012).
  • 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).
  • 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.
  • MFRD MFRD or mobile device having a separate independent power source
  • 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).
  • 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.
  • 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.
  • 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.
  • WLAN 1110 is used.
  • 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.
  • the M2M service provider is an M2M device installer / operator 1191 or an M2M service provider 1192 is illustrated.
  • 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.
  • the FRP 1183 sends the WLAN 1111 to the smartphone 1121 via the NMP 1182 and the mobile network 1141.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Selon un mode de réalisation, la présente invention concerne un système de courtage de gestion de réseau qui comporte une plate-forme M2M et de courtage de gestion de réseau (MNMBP) comprenant : une unité de communication de plate-forme de gestion M2M (MMP) pour recevoir les informations de génération de défaillance M2M depuis une MMP qui recueille les informations de gestion M2M sur un dispositif M2M ou sur une passerelle M2M ; une unité de communication de plate-forme de gestion de réseau (NMP) pour recevoir les informations de génération de défaillance de réseau d'une NMP qui recueille les informations de gestion de réseau sur un réseau d'accès et sur un réseau central ; une unité de commande pour commander l'unité de communication de la MMP ou l'unité de communication de la NMP à demander, si les informations de génération de défaillance sont reçues depuis la NMP et/ou la MMP, si une défaillance M2M ou une défaillance de réseau est générée à partir de l'une ou l'autre de la MMP et de la NMP.
PCT/KR2013/001232 2012-07-27 2013-02-18 Procédé et système de courtage de gestion de réseau WO2014017720A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2012-0082471 2012-07-27
KR20120082471A KR101492006B1 (ko) 2012-07-27 2012-07-27 네트워크 관리 중개 방법 및 시스템

Publications (1)

Publication Number Publication Date
WO2014017720A1 true WO2014017720A1 (fr) 2014-01-30

Family

ID=49997506

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/001232 WO2014017720A1 (fr) 2012-07-27 2013-02-18 Procédé et système de courtage de gestion de réseau

Country Status (2)

Country Link
KR (1) KR101492006B1 (fr)
WO (1) WO2014017720A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102485368B1 (ko) * 2018-01-15 2023-01-05 삼성전자주식회사 전자 장치, 그 제어 방법 및 컴퓨터 판독가능 기록 매체

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006319683A (ja) * 2005-05-13 2006-11-24 Mitsubishi Electric Corp ネットワークシステム監視方式およびネットワークシステム監視装置
KR20090034433A (ko) * 2007-10-04 2009-04-08 한국전자통신연구원 유비쿼터스 장애처리 시스템 및 방법
KR20090035152A (ko) * 2007-10-05 2009-04-09 한국전자통신연구원 홈 네트워크 환경을 위한 자율적인 오류 처리 시스템 및 그방법
US20120100847A1 (en) * 2010-10-26 2012-04-26 At&T Intellectual Property I, L.P. Performance diagnosis of wireless equipment and a wireless network over out-of-band communication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006319683A (ja) * 2005-05-13 2006-11-24 Mitsubishi Electric Corp ネットワークシステム監視方式およびネットワークシステム監視装置
KR20090034433A (ko) * 2007-10-04 2009-04-08 한국전자통신연구원 유비쿼터스 장애처리 시스템 및 방법
KR20090035152A (ko) * 2007-10-05 2009-04-09 한국전자통신연구원 홈 네트워크 환경을 위한 자율적인 오류 처리 시스템 및 그방법
US20120100847A1 (en) * 2010-10-26 2012-04-26 At&T Intellectual Property I, L.P. Performance diagnosis of wireless equipment and a wireless network over out-of-band communication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Organizations Information and Communication Standard (TTAS) TTAE.ET-TS 102 690", M2M SERVICE FUNCTIONAL ARCHITECTURE, 12 June 2012 (2012-06-12) *

Also Published As

Publication number Publication date
KR101492006B1 (ko) 2015-02-12
KR20140017050A (ko) 2014-02-11

Similar Documents

Publication Publication Date Title
WO2020197288A1 (fr) Procédé et dispositif pour fournir une connectivité à un terminal afin d'utiliser un service informatique périphérique
EP3542566B1 (fr) Procédés et appareil de capture et/ou d'utilisation de paquets permettant de faciliter une détection de défaillance
WO2020036366A1 (fr) Procédé et appareil de prise en charge d'une tranche de réseau lorsqu'un équipement utilisateur se déplace entre des réseaux 4g et 5g
WO2021086157A1 (fr) Procédé et système de gestion de la découverte de serveurs d'application périphériques
KR101737110B1 (ko) 무선 네트워크 고장들의 진단 및 해결
WO2011043571A2 (fr) Procédé de contrôle d'accès local pour terminaux qui supportent des communications m2m dans un système de communication sans fil
WO2014109597A1 (fr) Procédé de changement de passerelle dans un système machine à machine (m2m) et dispositif correspondant
WO2012157941A2 (fr) Procédé permettant d'effectuer un transfert dans un système d'accès sans fil prenant en charge la communication entre dispositifs, et appareil prenant en charge ledit procédé
WO2022005170A1 (fr) Procédé et dispositif d'interfonctionnement entre un réseau de communication mobile et un système informatique de bord pour fournir un service informatique de bord
WO2012044072A2 (fr) Procédé d'attribution de clé utilisateur dans un réseau convergent
WO2022019676A1 (fr) Procédé et appareil de sélection d'un serveur cible d'application de périphérie dans un environnement informatique de périphérie
WO2017155299A2 (fr) Procédé et appareil pour prendre en charge un transfert
WO2015139296A1 (fr) Stations de base, dispositif de commande de réseau et procédé de transfert intercellulaire direct
WO2014088146A1 (fr) Système de communication de machine à machine qui utilise un service de réseau social (sns), procédé de communication de machine à machine et serveur de communication de machine à machine pour ces derniers
WO2022216049A1 (fr) Procédé et appareil pour configurer un identifiant externe d'équipement utilisateur (ue) temporaire dans un système de communication sans fil
KR20150095843A (ko) 네트워크 능력을 개방하기 위한 시스템 및 방법과, 관련 네트워크 요소
WO2013069981A1 (fr) Système de communication et procédé de fonctionnement utilisant une passerelle domestique
WO2014017720A1 (fr) Procédé et système de courtage de gestion de réseau
WO2018143657A1 (fr) Procédé et appareil de fourniture de service de mémorisation d'informations de réseau pour terminal
JP5596664B2 (ja) 無線ネットワーク不具合切り分け支援システム
WO2023059157A1 (fr) Procédé et appareil pour surveiller une utilisation de données dans un système de communication sans fil
WO2022010301A1 (fr) Procédé et dispositif pour fournir une liaison de réseau mcptx et un serveur de services dans un système de communication
WO2024010433A1 (fr) Gestion de réseau périphérique améliorée
WO2023085756A1 (fr) Procédé et appareil pour prendre en charge une commande de politique de continuité de service
WO2021010632A1 (fr) Procédé pour fournir un service à haute disponibilité à l'aide d'une réaffectation de gnb et dispositif associé

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13822099

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 27/05/2015)

122 Ep: pct application non-entry in european phase

Ref document number: 13822099

Country of ref document: EP

Kind code of ref document: A1