Method and apparatus for managing plurality of devices in wireless communication system

Abstract

A method performed by a server for a software defined network (SDN) system, according to an embodiment of the present disclosure, may comprise the operations of: generating an inventory list for a plurality of devices; generating a backup target list on the basis of the inventory list; storing first backup data for devices included in the backup target list; on the basis of the first backup data, determining whether or not configuration information regarding a device included in the backup target list has been changed; and when it is determined that the configuration information regarding the device included in the backup target list has been changed, storing second backup data on the basis of the changed configuration information.

Description

Method and device for managing multiple devices in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and apparatus for managing a plurality of devices based on SDN (software defined networking) in a wireless communication system.

[0002] With the advancement of wireless communication systems, multiple network-connected devices can now be centrally managed using a single SDN (software defined networking) controller. More specifically, in case a network-connected device's settings change or malfunctions due to a failure or disaster, the device's configuration information can be backed up and stored on a service server. In the event of a failure or disaster, this backup information can be used to restore or recover the device.

[0003] Typically, SDN controllers must back up device configuration information at scheduled times and individually register and update multiple devices. Furthermore, when restoring or recovering a device, it's difficult to grasp the necessary information at a glance, and the complex procedures hinder user convenience.

[0004] Based on the discussion described above, the present disclosure can provide a method and device for comprehensively managing configuration information of multiple devices connected to an SDN controller.

[0005] The present disclosure may provide a method and device for backing up configuration information of a device at the time the device is registered in an orchestration service connected to an SDN controller, creating a copy of the configuration information, and storing the copy in a database.

[0006] The present disclosure synchronizes the backup target list with the inventory list, thereby enabling effective management of devices to be monitored for setting changes.

[0007] The present disclosure provides a method and apparatus for obtaining post-change configuration information of a device based on a configuration change event when the configuration of a device connected to an SDN controller is changed and storing another copy in a database, and for monitoring a plurality of devices connected to the SDN controller and obtaining post-change configuration information whenever a configuration change event occurs and storing new copies.

[0008] Additionally, the present disclosure can support a service and user interface for integrated management of multiple backup data sets. In particular, the present disclosure can support a user interface that selects two backup data sets and visually displays the differences between them.

[0009] In addition, the present disclosure provides a method and device that can be used to recover or restore backed up settings by providing a list of verifiable backup versions of a plurality of backup data.

[0010] A method performed by a server for an SDN (software defined network) system according to one embodiment of the present disclosure may include: an operation of generating an inventory list for a plurality of devices; an operation of generating a backup target list based on the inventory list; an operation of storing first backup data for devices included in the backup target list; an operation of determining whether setting information for a device included in the backup target list has changed based on the first backup data; and an operation of storing second backup data based on the changed setting information when it is determined that setting information for a device included in the backup target list has changed.

[0011] According to one embodiment of the present disclosure, a server for a software defined network (SDN) system includes a transceiver; a controller; and a storage unit for storing commands, wherein when the commands are executed by the controller: an inventory list for a plurality of devices is generated, a backup target list is generated based on the inventory list, first backup data for devices included in the backup target list is stored, whether setting information for devices included in the backup target list has changed is determined based on the first backup data, and when it is determined that setting information for devices included in the backup target list has changed, second backup data can be stored based on the changed setting information.

[0012] According to one embodiment of the present disclosure, multiple versions of setting information (hereinafter, 'multiple backup data') can be managed.

[0013] According to one embodiment of the present disclosure, a user can visually check the differences between backup data and restore the settings of a device using the backup data in the event of a failure or disaster.

[0014] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0015] Figure 1 illustrates the architecture of software according to one embodiment of the present disclosure.

[0016] FIG. 2 is a flowchart of a backup procedure performed by a server according to one embodiment of the present disclosure.

[0017] FIG. 3 illustrates an inventory user interface (UI) for displaying an inventory list according to one embodiment of the present disclosure.

[0018] FIG. 4 illustrates a UI displaying a backup target list according to one embodiment of the present disclosure.

[0019] FIG. 5 is a flowchart illustrating a method for modifying device information according to one embodiment of the present disclosure.

[0020] FIG. 6 is a flowchart illustrating synchronization and reload operations performed by a server according to one embodiment of the present disclosure from the perspective of services included in the server.

[0021] FIG. 7 is a flowchart of a procedure in which backup data is generated and stored based on setting information of a device when the setting of a device included in a backup target list is changed according to one embodiment of the present disclosure.

[0022] FIG. 8 is a flowchart illustrating a procedure for storing backup data according to one embodiment of the present disclosure. FIG. 9 illustrates an example of a backup data list UI provided according to one embodiment of the present disclosure.

[0023] FIG. 10 is a flowchart of a recovery (or restoration) procedure according to one embodiment of the present disclosure.

[0024] FIG. 11 illustrates a UI indicating the progress of a recovery (or restoration) procedure according to one embodiment of the present disclosure.

[0025] FIG. 12 is a flowchart illustrating a method for managing multiple devices in a wireless communication system according to one embodiment of the present disclosure.

[0026] FIG. 13 is a block diagram of a device according to one embodiment of the present disclosure.

[0027] FIG. 14 is a block diagram of a server according to one embodiment of the present disclosure.

[0028] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning as the meaning they have in the context of the related technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0029] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0030] In the following description, terms referring to signals (e.g., message, information, preamble, signal, signaling, sequence, stream), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), PRB (physical resource block), BWP (bandwidth part), occasion), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to control information (e.g., downlink control information (DCI), medium access control (MAC) control element (CE), radio resource control (RRC) signaling), terms referring to network entities, terms referring to components of devices, etc. are used in the description. These terms are provided for convenience. Therefore, the present disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used.

[0031] Additionally, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled. However, this is merely a description for expressing an example and does not exclude descriptions of "more than" or "less than." Conditions described as "more than" may be replaced with "more than," conditions described as "less than" may be replaced with "less than," and conditions described as "more than and less than" may be replaced with "more than and less than."

[0032] Additionally, although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0033] Figure 1 illustrates the architecture of software according to one embodiment of the present disclosure.

[0034] Referring to FIG. 1, a server (100) may be connected to an SDN controller included in the server (e.g., via a physical connection or wired connection) and may manage a plurality of network equipment or devices (110) registered in the inventory of the SDN controller. In the present disclosure, the devices (110) may include a switch, a router, and / or a server.

[0035] According to one embodiment of the present disclosure, when a setting change occurs in one of a plurality of devices (110), the server (100) may provide a function of receiving a report that a setting change event has occurred from the device where the setting change occurred (S101), obtaining changed setting information from the device where the setting change occurred, storing backup data for the changed setting information (S102), and restoring the settings of the device based on the backup data (S103). This function according to one embodiment may be referred to as a zero touch backup and restore (ZTBR) function, and the ZTBR function may be provided through a ZTBR service.

[0036] The devices (110) may be configured to transmit a notification or report of a setting change event to the server (100). The devices (110) may store the IP (Internet Protocol) address of the server (100) for the setting change event. The devices (110) may transmit a notification or report of the setting change event to the server (100) based on the IP address of the server (100).

[0037] The server (100) can obtain information that a setting change has occurred from the device by receiving a notification or report regarding a setting change event. In the present disclosure, the server (100) is characterized in that it performs an event-based backup and manages multiple backup data by generating and storing backup data of setting information whenever a setting change event occurs. At this time, the server (100) can store a new version of the backup data whenever it generates backup data. In the present disclosure, backing up the setting information of devices based on an event related to a setting change of the devices can be referred to as an event-based backup.

[0038] According to one embodiment, the server (100) may register devices in the inventory of the SDN controller, create or update an inventory list including the devices registered in the inventory, and store information about the devices included in the inventory list. More specifically, the server (100) may register devices in the inventory of the SDN controller through an orchestration service and store information about the devices registered in the inventory. In the present disclosure, the inventory list is a list of devices registered in the inventory, and the server (100) may create or update the inventory list through the orchestration service. In addition, the server (100) may store information about the devices registered in the inventory list through the orchestration service. In one embodiment, the inventory list may include a plurality of devices (110) connected to the server (e.g., physically connected or wired connected).

[0039] According to one embodiment, the server (100) may obtain information on target devices on which event-based backup is to be performed, and generate or update a backup target list including information on candidate devices for the event-based backup. More specifically, the server (100) may obtain information on target devices on which event-based backup is to be performed through the ZTBR service, and store the information in a database. In the present disclosure, the backup target list is a list of candidate devices for the event-based backup, and the server (100) may store information on devices included in the backup target list through the ZTBR service.

[0040] According to one embodiment, the server (100) may perform an event-based backup using at least some of the information included in the backup target list. For example, the server (100) may receive an input from a user to select at least one device from the backup target list on which to actually perform the event-based backup procedure. At this time, the server (100) may perform the event-based backup procedure based on information about at least one device selected from the backup target list. In the present disclosure, information about at least one selected device may be referred to as source information. In the present disclosure, the source information may include information about a device managed through a backup engine service.

[0041] According to one embodiment, the server (100) may generate an inventory list, generate a backup target list based on the inventory list, and synchronize the inventory list with the backup target list so that the backup target list includes information about the same devices as the inventory list. To maintain the synchronization of the backup target list, the server (100) may continuously or repeatedly compare the inventory list with the backup target list and update the backup target list.

[0042] The server (100) can periodically or repeatedly determine or identify information about devices that will perform an event-based backup procedure. That is, the server (100) can periodically determine or identify source information. Since the backup target list can be synchronized with the inventory list and changed, the information about devices included in the source information can also be changed. In addition, since the server's settings can be changed to perform or not perform event-based backup for specific devices included in the backup target list at the time the server determines or identifies the source information, the information about devices included in the source information can also be changed.

[0043] For example, an input may be received from a user to set not to perform event-based backup for a specific device included in a backup target list. At this time, the server (100) may determine source information and / or perform event-based backup based on the remaining devices excluding the corresponding device in the backup target list. As another example, an input may be received from a user to set to perform event-based backup for a specific device included in a backup target list. At this time, source information including information about the corresponding device in the backup target list may be determined and / or event-based backup may be performed.

[0044] The server may periodically or repeatedly determine or identify information (or source information) of devices on which event-based backup procedures will be performed, and the source information may be determined or identified differently depending on changes in the inventory list, changes in the backup target list and inventory list, and / or settings at the time the source information is determined. Accordingly, the devices on which the server performs event-based backup procedures may vary over time.

[0045] In one embodiment, the server (100) can determine devices for performing an event-based backup procedure by generating and synchronizing a backup target list based on an inventory list and determining source information through the ZTBR service. For example, the generation and synchronization of the backup target list can be performed through the orchestration service and the ZTBR service, and the determination of source information can be performed through the ZTBR service and the backup engine service.

[0046] Devices determined or identified for event-based backup may be configured to transmit a notification or report of a configuration change event to the server (100). In one embodiment, the server (100) may receive a notification or report of a configuration change event from devices determined or identified for event-based backup. In this case, the devices determined or identified for event-based backup may be configured to transmit a notification or report based on the IP address of the server (100).

[0047] For example, in operation 101 of FIG. 1, the server (100) can receive a trap message from a connected device. At this time, a plurality of devices (110) can be configured to generate a trap message when a setting is changed and transmit the generated trap message to the server (100). A device whose setting has been changed can be configured to transmit a trap message based on the IP address of the server (100). The IP address of the server (100) can be set through an SNMP trap receiver service. The server (100) can receive the trap message through an SNMP (simple network management protocol) trap receiver service.

[0048] The server (100) can identify or obtain identification information of the device that reported the event and obtain configuration information of the device based on the identification information. According to one embodiment, the identification information of the device that reported the event may include a universally unique identifier (UUID).

[0049] In one embodiment, the server (100) can identify the UUID of the device that generated the trap message through the SNMP trap receiver service, identify the device whose settings have been changed using the identified UUID, and obtain setting information from the identified device. At this time, the procedure for identifying the UUID of the device that generated the trap message can be performed through the trap receiver service. In addition, the procedure for identifying the device whose settings have been changed using the identified UUID can be performed through the message broker service, the ZTBR service, and / or the backup engine service. Furthermore, the procedure for obtaining setting information can be performed through the ZTBR service and the backup engine service.

[0050] According to one embodiment, the server (100) acquires configuration information of a device, determines whether the acquired configuration information differs from the configuration information the server already has for the device, and if it determines that there is a change, it can back up the acquired configuration information. At this time, the server (100) can store a new version of backup data each time it generates backup data. In the present disclosure, the configuration information stored as a backup may be referred to as backup data. As event-based backups are repeated, multiple versions of backup data may be stored.

[0051] In one embodiment, the server (100) may modify the device's settings based on backup data, and such modification may be referred to as a restore or recovery. For example, the server (100) may replace the device's settings based on designated or selected backup data from among multiple stored backup data through a restore service.

[0052] According to one embodiment, the server (100) may display an inventory list UI, a backup target list UI, a backup data list UI, and / or a UI indicating the progress of a recovery procedure through a front-end service. The backup data list UI may include GUIs for a viewer function that compares two specified backup data sets.

[0053] FIG. 2 is a flowchart of a backup procedure performed by a server according to one embodiment of the present disclosure.

[0054] Referring to FIG. 2, in operation 201, the server (100) can generate an inventory list for a plurality of devices. The server (100) can provide an inventory UI for user input. The server (100) can register a plurality of devices in the inventory by receiving user input for entering data for individual devices through the inventory UI or by receiving data for a plurality of devices from an external input device, and can generate and store an inventory list for the plurality of registered devices.

[0055] In operation 202, the server (100) may generate a backup target list based on the inventory list. In one embodiment, the server (100) may generate an inventory list and fetch the inventory list to generate a backup target list. The backup target list may refer to a list of devices that are targets of event-based backup in operation 204. In one embodiment, as the inventory list is generated, an initial backup target list is generated, and the backup target list may also be changed or updated according to changes or updates in the inventory list. Referring to FIG. 1, the server (100) may generate an inventory list through an orchestration service and generate a backup target list through a ZTBR service.

[0056] According to one embodiment, the server (100) may create or store the initial version of backup data when creating a backup target list according to the initial settings.

[0057] After generating a backup target list based on the inventory list in Action 202, the inventory list can be changed or updated. For example, devices can be added or deleted from the inventory list.

[0058] In operation 203, the server (100) may determine a difference between the inventory list and the backup target list, or compare the inventory list with the backup target list. Alternatively, the server (100) may determine whether the backup target list is synchronized with the inventory list. According to one embodiment, the server (100) may periodically, continuously, or repeatedly check for differences between the inventory list and the backup target list.

[0059] In one embodiment, the server may compare a unique identification number (e.g., a universally unique identifier (UUID)) of each device included in the inventory list with the unique identification numbers of the devices included in the backup target list. In one embodiment, the server (101) may store the UUIDs of all devices included in the inventory list in a single data structure set and compare this set with the UUIDs of the devices included in the backup target list.

[0060] For example, if the inventory list includes device A and device B, the server can store the UUID of device A and the UUID of device B in a set. The server can compare the set with the UUIDs included in the backup target list. If the backup target list includes a UUID that is identical to the UUID of device A, the server can determine that the inventory list and the backup target list have the same information for device A. If the UUID of device B is not included in the backup target list, the server can decide to add information about device B to the backup target list.

[0061] Additionally, if device C was included in the inventory list and then deleted, the set will not include the UUID of device C, but the backup target list may include the UUID of device C. The server may decide to delete information about device C from the backup target list.

[0062] In operation 204, the server (101) may synchronize the backup target list with the inventory list. Based on the comparison result between the inventory list and the backup target list of operation 203, the backup target list may be changed or updated to match the inventory list.

[0063] In one embodiment, device information that is only included in the inventory list and not in the backup target list can be added to the backup target list. Device information that is only included in the backup target list and not in the inventory list can be deleted from the backup target list. That is, if a device registered in the inventory list is deleted from the inventory list, the deleted device can also be deleted from the backup target list.

[0064] As a result, since the inventory list and the backup target list are synchronized, the server (100) can perform event-based backups for devices included in the inventory list. The backup target list synchronized to the inventory list can be stored in a database (e.g., the database of FIG. 1).

[0065] Even after synchronizing the backup target list with the inventory list in operation 204, devices can be added or deleted from the inventory list. As described in operation 203, the server (100) can periodically, continuously, or repeatedly check the difference between the inventory list and the backup target list. Accordingly, the backup target list can remain synchronized with the inventory list.

[0066] In operation 205, the server (100) can generate backup data based on the configuration information of a device included in the backup target list when the configuration of the device is changed. That is, the server (100) can perform an event-based backup. As described in FIG. 1, the event-based backup can be performed on devices designated among the devices included in the backup target list or on devices included in the source information. Operation 205 is described in detail in FIG. 7.

[0067] FIG. 3 illustrates an inventory user interface (UI) for displaying an inventory list according to one embodiment of the present disclosure.

[0068] Referring to operation 201 of FIG. 2, the server (100) can generate an inventory list including a plurality of devices and store information about the plurality of devices included in the inventory list. Information about the device can include the device's name, IP address, model, type, provisioning state, and / or maintenance mode. The model can indicate the device manufacturer. The type can indicate whether the device corresponds to a router, a switch, or a server.

[0069] The provisioning state of a device can indicate whether the SDN controller has acquired detailed information (e.g., port up / down status, CPU (central processing unit), memory, equipment temperature, or device SSH (secure shell) information) that is set in advance to manage the device. For example, if the SSH information acquired during the provisioning process of a device registered in the inventory (or included in the inventory list) does not match the SSH information set on the device, the provisioning may progress fail.

[0070] In the present disclosure, SSH (secure shell) authentication is an example of an authentication procedure for maintaining the confidentiality of device configuration information, and SSH authentication may also be referred to as SSH access authentication, SSH connection authentication, SSH login authentication, or SSH. Information for SSH authentication includes a user name and password, and may also be referred to as SSH information, SSH access information, SSH connection information, SSH login information, or SSH authentication information.

[0071] The inventory UI may include the following GUIs to increase usability:

[0072] Referring to FIG. 3, the inventory UI may provide a GUI (301) to indicate the name, IP address, model name, and / or type of the device.

[0073] The inventory UI may include graphical user interface icons (GUIs) that indicate the provisioning status of a device. For example, the provisioning GUI (302) may indicate that a device is registered in the inventory but is in an "unprovisioned" state.

[0074] The inventory UI may include a GUI (303) that displays statistics on the provisioning status of all devices registered in the inventory. For example, the GUI (303) may display the number of provisioned devices, the number of devices in progress, the number of devices whose progress has failed, and the number of unprovisioned devices.

[0075] The inventory UI may include a GUI (304) for setting a maintenance mode. The GUI (304) may include a toggle object that can enable / disable the maintenance mode.

[0076] The inventory UI may include a GUI (305) for grouping devices included in the inventory list and displaying them in a tree structure. The GUI (305) may further include objects for editing groups. For example, referring to FIG. 3, a group may be added through user input received via an object ("add group").

[0077] The inventory UI may include a GUI (306) to indicate that a problem has occurred with the device. For example, the GUI (306) may classify the problems into critical, major, and minor problems according to the severity of the problem, and may indicate the number of problems corresponding to each classification.

[0078] The inventory UI may include GUIs for search (307), filtering (308), refresh (309), data import (310), data export (311), and add (312) functions. In one embodiment, the server (100) may obtain information about individual devices based on user input received through the GUI (312) for the add function when generating an inventory list, and / or may obtain information about devices by receiving data about multiple devices from an external device. FIG. 4 illustrates a UI for displaying a backup target list according to one embodiment of the present disclosure.

[0079] Referring to operations 202 to 204 of FIG. 2, the server (100) may generate a backup target list based on the inventory list and synchronize the backup target list with the inventory list. The backup target list may include devices included in the inventory list. Information about the devices included in the backup target list may include the device's name, IP address, and / or model name. Any overlapping information regarding device information with the inventory list will be briefly described.

[0080] Device information may include connection status information indicating whether the device and server are in a connected state. If the device and server are in a connected state, the server (100) may connect to the device (e.g., SSH connection or connection) or obtain device configuration information to store backup data. In this case, the server (100) may connect to the device via a backup engine service.

[0081] The backup target list UI may include a GUI (401) for indicating connection status information between a device and a server. The GUI (401) may include an object indicating a connected state and an object indicating a non-connected state, as shown in FIG. 5.

[0082] The server (100) attempts to connect to or establish a connection with a device, and if the connection or establishment is successful, obtains configuration information from the device, and can disconnect the connection or establishment upon obtaining the configuration information. The backup target list may include average run time information, which is the time from the time the server (100) attempts to connect to or establish a connection with the device and the connection is successful to the time the connection is disconnected. For example, if the server (100) attempts to connect to a device but fails, the average run time value is 0 (zero) because the connection with the device has failed. For example, if the server (100) succeeds in connecting to or establishing a connection with the device but does not obtain the necessary configuration information and the connection is not disconnected, the average run time value may be much greater than a specified value. In other words, an average run time value of 0 (zero) may indicate a state in which the server (100) and the device are not connected, and an average run time value greater than a specified value may indicate that the server (100) and the device are connected but there is a problem in transmitting information. Accordingly, the average run time information can indicate the performance of the server (100), and the server (100) or the operator of the server (100) can determine the need for inspection of the device based on the average run time information. The backup target list UI can include a GUI (402) for displaying the average run time information.

[0083] The backup target list UI may include a GUI (403) that displays a backup start time and / or a last update time. The backup start time object may indicate the time when the first backup file on the device was saved. The last update time may indicate the time when the most recent or last backup file was saved.

[0084] The backup target list UI may include a GUI (404) for selecting backup on / off. The GUI (404) may include a toggle object for enabling or disabling backup for each device. As described in FIG. 1, since the server (100) determines information of at least some devices specified in the backup target list as source information, information of devices excluded from the source information may not be used when backing up the device configuration information. According to one embodiment, the server (100) may set whether to back up or not to back up configuration information for a specific device based on user input received through the GUI (404).

[0085] The backup target list UI may include a GUI (405) for individual updates. In one embodiment, backup data for a device may be individually stored for a designated device among multiple devices included in the backup target list. For example, based on user input received via the GUI (405), the server (100) may attempt to connect to each device and obtain configuration information for each device.

[0086] In another embodiment, the connection status between a device and a server can be individually identified for a given device. For example, based on user input received via the GUI (405), the server (100) can attempt to connect to an individual device and identify the connection status.

[0087] According to another embodiment, the server (100) can identify the connection status of all devices and the server (100) based on the connection status information and average runtime information with all devices included in the source information. For example, if the GUI (401) of a specific device includes an object indicating that it is connected, and the value of the average runtime information falls within a specified category, the specific device may be determined to be connected to the server (100). Even if the GUI (401) of a specific device includes an object indicating that it is connected, if the value of the average runtime information falls outside the specified category, the server (100) may determine that there is a problem with the connection status with the specific device. If the GUI (401) of a specific device includes an object indicating that it is not connected or the average runtime is 0 (zero), the server (100) may be determined to be not connected to the specific device. According to one embodiment, the server (100) can identify connection status information and average run time information for all devices included in the source information periodically or repeatedly through a polling method, and based on this, can check the connection status between multiple devices and the server (100) in a single operation for all devices included in the source information among the backup target list.

[0088] In another embodiment, even if the device and the server (100) are connected, the server (100) may not be able to back up the device's configuration file. For example, if the device and the server (100) are in a deadlock state, the server (100) may not be able to back up the device's configuration file. Alternatively, the device and the server (100) may not be connected. For example, if the device's information is incorrectly entered when the device is registered in the inventory, the device's information included in the backup target list generated based on the inventory list may also be incorrect, which may cause the connection between the device and the server (100) to fail. In addition, the device and the server (100) may be connected, but an error may occur, causing the connection to be disconnected.

[0089] The server (100) can periodically, continuously, and repeatedly check whether the device's configuration information can be backed up. The server (100) can check the connection status between the server (100) and the device by connecting to the device. For example, the server (100) can check the connection status between the server and the device through an SSH connection.

[0090] FIG. 5 is a flowchart illustrating a method for modifying device information according to one embodiment of the present disclosure.

[0091] As previously described, when a device is registered in the inventory list (e.g., operation 201 of FIG. 2), information about the registered device can be stored (e.g., operation 202). If the information about a device registered in the inventory list contains incorrect information, the incorrect information will continue to be used unless corrected. FIG. 5 illustrates a procedure for correcting incorrect information about a device included in the inventory list and reflecting the changes in the source information.

[0092] Any content in the description of Actions 501 to 510 that overlaps with the previous description will be briefly explained.

[0093] In operation 501, a server (100) according to one embodiment may generate an inventory list for a plurality of devices. Furthermore, the server (100) may generate SSH information (e.g., user name and password) for the devices included in the inventory list. The SSH information may be entered during inventory registration. The SSH information generated in operation 501 may be incorrect SSH information.

[0094] In operation 502, the server (100) may generate a backup target list based on the inventory list. Furthermore, the server (100) may generate backup data for devices included in the backup target list. At this time, since the backup target list is generated based on the inventory list generated in operation 501, the SSH information for the devices included in the backup target list may be incorrect.

[0095] Since the source information is determined based on information from a device that contains incorrect SSH information in operation 503, the source information may contain incorrect SSH information.

[0096] According to one embodiment, the server (100) may attempt to connect to a device using SSH information included in the source information based on an event in which the settings of a device included in the backup target list are changed. In operation 504, if the SSH information included in the source information is correct, the server (100) may connect to the device and obtain the device's settings information in operation 505.

[0097] In operation 504, the server (100) attempts to connect to the device based on SSH information and determines whether the connection is successful. If the SSH information included in the source information is incorrect, the server (100) cannot connect to the device and cannot obtain the device's configuration information.

[0098] According to one embodiment, the server (100) can correct incorrect device information. For example, as described above, if the SSH information is incorrect, the server (100) can correct the SSH information.

[0099] In operation 506, the server (100) can correct incorrect device information (e.g., SSH information). For example, the inventory list UI further includes a GUI for correcting incorrect device information, and the server (100) can correct incorrect SSH information based on user input received through the GUI.

[0100] According to one embodiment, the server (100) can synchronize a backup target list based on an inventory list and generate backup data for devices included in the backup target list. At this time, the procedure for synchronizing the backup target list can be performed periodically for all information on devices included in the inventory list, as described in FIG. 2, or can be performed based on user input for synchronization for individual devices received through the inventory list UI.

[0101] In operation 506, the server (100) may correct incorrect SSH information. More specifically, the server (100) may delete incorrect SSH information from the inventory list and add correct SSH information. For example, the server (100) may correct incorrect SSH information in the inventory list based on user input for deleting incorrect SSH information or user input for entering correct SSH information into the inventory list. In operation 507, the server (100) may connect to the device based on the correct SSH information. Operation 507 may be performed immediately after the SSH information is corrected in operation 506.

[0102] As described in FIG. 1, the server (100) can periodically or repeatedly determine or identify information about devices that will perform an event-based backup procedure. In operation 508, the server (100) can determine source information based on a backup target list containing correct SSH information through this repetitive operation.

[0103] According to one embodiment, when the server (100) modifies SSH information after an SSH connection failure, the server (100) can synchronize the backup target list and determine the source information. If the backup target list is immediately synchronized in operation 507, when the server detects that the inventory list has been modified after the SSH connection failure in operation 509, the server can immediately determine the source information based on the backup target list.

[0104] In one embodiment, when modifying the inventory list after an SSH connection failure, the server can immediately determine the source information. If the synchronization of operation 507 is performed immediately after the inventory modification in operation 506, the server can immediately determine the source information based on the user input for determining the source information received through the reload GUI after the SSH connection failure in operation 510. In this case, the reload GUI can be included in the inventory list UI of FIG. 4.

[0105] After one of actions 508, 509, and 510 is performed, the server can perform action 504 again. Since the source information in actions 508, 509, and 510 contains the correct SSH information, the server can connect to the device using the correct SSH information.

[0106] In one embodiment, one of operations 508, 509, and 510 and operation 507 may be performed concurrently. For example, in response to a modification to the inventory list at 509, the backup target list may be immediately synchronized and the source information determined.

[0107] FIG. 6 is a flowchart illustrating a synchronization and reload procedure performed by a server according to one embodiment of the present disclosure from the perspective of services included in the server.

[0108] Operations 601 to 604 of FIG. 6 may correspond to operations S201 to S204 of FIG. 2 and may correspond to operations 501 to 507 of FIG. 5. Operations 605 to 609 of FIG. 6 may correspond to operations 508 to 510 of FIG. 5. Therefore, any content overlapping with the preceding description will be briefly described.

[0109] Referring to FIG. 6, the server (100) can identify whether a plurality of devices registered in the inventory list are included in the backup target list, and add devices included in the inventory list but not in the backup target list to the backup target list. By doing so, the server (100) can synchronize the backup target list based on the inventory list. The synchronization can be performed as in operations 601 to 604.

[0110] Before actions 601 and 602, the server (100) can generate an inventory list through the ZTBR service and the orchestration service.

[0111] In operations 601, 602, and 6030, the server (100) can synchronize the inventory list with the backup target list. For example, the server (100) can compare the inventory list with the backup target list through the ZTBR service and the orchestration service. To this end, in operation 601, the ZTBR service can request the inventory list from the orchestration service. In operation 602, the ZTBR service can receive the inventory list in response from the orchestration service. In operation 603, the ZTBR service can determine or identify whether the inventory list received in response from the orchestration service and the backup target list stored in the database are synchronized.

[0112] Actions 601 through 603 can be performed periodically, continuously, or repeatedly. To this end, the ZTBR service can periodically request an inventory list from the orchestration service, which can be said to be polling the orchestration service. In one embodiment, the ZTBR service can request an inventory list from the orchestration service through a polling method.

[0113] Specifically, in operation 602, the ZTBR service can obtain UUID information of multiple devices registered in the inventory list. For example, the orchestration service can respond to the ZTBR service by including the UUIDs of multiple devices included in the inventory list in a single set.

[0114] At this time, since the ZTBR service is polling the orchestration service, the ZTBR service periodically, continuously, or repeatedly requests a set of UUIDs from the orchestration service, the orchestration service responds with a set of UUIDs to the ZTBR service, and the ZTBR service that receives the set in response can compare the UUIDs stored in the set with the UUIDs in the backup target list.

[0115] In operation 603, if the server (100) determines that the inventory list and the backup target list match each other, the server (100) may terminate the procedure without proceeding to the operation of synchronizing the backup target list with the inventory list (e.g., operation 604). Then, when the cycle of operation 601 returns, the server (100) may perform the procedure of operation 601 again.

[0116] In operation 603, if the server (100) determines that the inventory list and the backup target list do not match, the server (100) can synchronize the backup target list with the inventory list. Specifically, the server (100) can synchronize the inventory list and the backup target list through the ZTBR service. Alternatively, if the server (100) determines that there is a difference in information between the inventory list and the backup target list in operation 603, the server (100) can change or update the backup target list based on the inventory list. Specifically, the server (100) can change or update the backup target list so that the information in the backup target list matches the information in the inventory list. This synchronization operation can be performed through the ZTBR service.

[0117] In operation 604, the server (100) can store information on the synchronized backup target list through the ZTBR service in a database. Information on the changed or updated backup target list can be stored in the database.

[0118] For example, if information about device B (e.g., UUID of device B) is included in the SET received in response from the orchestration service and is not included in the backup target list, the ZTBR service can identify in operation 603 that information about device B is not included in the backup target list. In operation 604, the server (100) can add device B to the backup target list through the ZTBR service.

[0119] Before operation 605, operations 504 and 506 to 507 of FIG. 5 may be performed. In operations 504 and 506 to 507 of FIG. 5, the server (100) may determine that information on a device included in the inventory list is incorrect, correct the inventory list, and generate backup data based on the inventory list.

[0120] Specifically, referring to FIG. 1, the backup engine service may attempt to connect to a device using SSH information included in the source information and fail. At this time, the server (100) may determine that the SSH information included in the inventory list is incorrect. Referring to FIG. 4, the server may display a GUI (401) indicating a connection failure or a GUI (402) indicating an average run time of 0 (zero) via the ZTBR service and the front-end service.

[0121] In operations 504 and 506 to 507 of FIG. 5, the server (100) may attempt to connect to the device via the backup engine service. If the connection is delayed, the server may determine that the information contained in the inventory list is incorrect and perform operations 605 to 609 to reload the correct information.

[0122] Action 605 may include action 509 or action 510 of FIG. 5. At this time, the ZTBR service may request a reload from the backup engine service. The reload request may include a request from the backup engine service to immediately request source information from the ZTBR service. Alternatively, the reload request may include a request from the backup engine server to retrieve new source information because information in the inventory list and backup target list has been modified.

[0123] For example, the ZTBR service may request the Backup Engine service to immediately request source information in response to a modification to the inventory list. In another example, the ZTBR service may receive user input requesting the Backup Engine service to immediately request source information, which is received through a reload GUI included in the Backup Target List UI. The ZTBR service may request the Backup Engine service to immediately request source information based on the user input.

[0124] In operation 606, the backup engine service may request source information from the ZTBR service based on the reload request of operation 605. According to one embodiment, the source information may include information on devices set to 'backup activation' (e.g., see GUI (404) of FIG. 4) among the devices included in the backup target list at the time of the source information request from the backup engine service, as described in FIGS. 1 and 4.

[0125] In operation 607, the ZTBR service can request source information from the database, and in operation 608, the database can receive source information in response from the ZTBR service. At this time, the ZTBR service can retrieve the backup target list stored in the database in operation 604.

[0126] In operation 609, the ZTBR service can respond to the Backup Engine service with source information. In operation 609, the Backup Engine service can receive source information from the ZTBR service, determined based on the latest backup target list.

[0127] Through the process described above, the backup target list can be periodically synchronized with the inventory list to ensure it contains the same device information as the inventory list. Furthermore, source information can be determined based on the most recent backup target list.

[0128] Additionally, the inventory list UI and backup target list UI can display the connection status between the server and the device, including the connection status GUI and the average runtime GUI. The connection status between the server (100) and the device can provide an indication of whether the information on the device registered in the inventory is correct and / or an indication of whether an abnormal situation has occurred that makes connection to the device impossible.

[0129] FIG. 7 is a flowchart of a procedure in which backup data is generated and stored based on setting information of a device when the setting of a device included in a backup target list is changed according to one embodiment of the present disclosure.

[0130] Referring to FIG. 7, in operation 701, the device may report to the server (100) that the settings have changed when the settings have changed. According to one embodiment, the device may transmit a message (hereinafter, referred to as a “setting change report message”) to the server to report that the settings have changed. In operation 701, the server (100) may detect that the settings of the device have changed by receiving a report of the device’s settings change from the device.

[0131] For example, a configuration change report message may include a trap message or a configuration notification trap message. The device may generate a trap message based on a configuration change, and the device may transmit the trap message to the server (100) using the IP address of the server (100). The IP address of the server (100) may be set in advance in the device. Specifically, the server (100) may receive the trap message from the device through the SNMP trap receiver service.

[0132] In operation 702, the server (100) can identify the device that generated or transmitted the configuration change report message. According to one embodiment, the server (100) can identify the device that generated the configuration change report message using the universally unique identifier (UUID) of the device. For example, this UUID can be included in the configuration change report message, and the server can obtain the UUID of the device that sent the configuration change report message based on the configuration change report message.

[0133] In operation 703, the server (100) may request configuration information from the identified device. To this end, the server (100) may attempt to connect or access the identified device. For example, the server (100) may attempt to establish an SSH connection to the identified device using SSH information such as a user name and password.

[0134] According to one embodiment, the server (100) may transmit a command to the identified device to obtain configuration information from the identified device. In this case, the command transmission may be performed via a backup engine service.

[0135] In operation 704, the server (100) can obtain configuration information of the identified device. The server that successfully connects to the device identified in operation 703 via SSH can obtain configuration information of the identified device.

[0136] In operation 705, the server (100) can determine whether the settings of the identified device have actually changed based on the configuration information acquired from the identified device. In order to determine whether the settings of the identified device have actually changed, the server can compare the configuration information acquired from the identified device with existing backup data. In this case, the existing backup data may include at least one of the previous versions of backup data already stored in the database. Since the server of the present disclosure performs operations 701 to 706 every time the settings of the device are changed, the database may store multiple versions of backup data based on the past configuration information of the device. That is, the server (100) can compare the configuration information acquired in operation 704 with at least one of the previous versions of backup data already stored in the database in relation to the identified device. The server (100) can determine whether the settings of the identified device have actually changed based on the comparison result.

[0137] According to one embodiment, the previous version of the backup data may include the backup data most recently stored in the database with respect to the identified device. Accordingly, the server (100) may compare the configuration information acquired in operation 704 with the backup data most recently stored in the database. Hereinafter, the backup data most recently stored in the database may be referred to as the latest version backup data. For example, it may be determined whether the configuration information of operation 704 is different from the previous version of the backup data. If it is determined that the configuration information of operation 704 is different from the previous backup data, the server (100) may determine that the configuration of the identified device has actually changed. Meanwhile, to identify the most recently stored backup data, the server may record, manage, or utilize the time at which the backup data was stored in the database.

[0138] In one embodiment, the existing backup data may include all version-specific backup data already stored in the database for the identified device. In other words, the server (100) may compare the configuration information of operation 704 with all previously stored backup data.

[0139] The server (100) can assign a commit ID to backup data for each version through the backup engine service. The commit ID may be assigned for each version of backup data stored in the database. The server (100) can assign a commit ID after acquiring configuration information in operation 704.

[0140] Specifically, the server (100) can determine whether the configuration information acquired in operation 704 is different from the backup data already stored in the database. For example, if the server (100) determines that the configuration information acquired in operation 704 has been partially changed by comparing it with the backup data already stored in the database, the server (100) can assign a new commit ID to the configuration information acquired in operation 704.

[0141] As another example, if it is determined that the configuration information acquired in operation 704 is the same as one of the backup data already stored in the database, the server (100) may assign a commit ID already assigned to the backup data that is determined to be the same, rather than assigning a new commit ID to the acquired configuration information.

[0142] According to one embodiment, the server (100) may compare the configuration information acquired in operation 704 with both the previous version backup data and the full backup data. That is, if the server (100) determines that the configuration information of operation 704 and the previous version backup data are different after comparing the configuration information of operation 704 with the previous version backup data, the server may compare the configuration information acquired in operation 704 with the full backup data. For example, if the server determines that the configuration information acquired in operation 704 is different from the previous version backup data, the server may further determine whether the configuration information acquired in operation 704 is different from the backup data already stored in the database. If the server determines that the configuration information is different from the backup data already stored in the database, the server may assign a new commit ID to the configuration information acquired in operation 704. In addition, if the server determines that the same backup data is already stored in the database, the server may assign the same commit ID as the commit ID assigned to the already stored backup data to the configuration information acquired in operation 704.

[0143] In operation 706, the server may store the acquired configuration information as a new version of backup data. For example, based on the determination that the configuration information of operation 704 is different from the previous version of backup data, the server (100) may store the configuration information acquired in operation 704 as new backup data in the database.

[0144] For another example, if the server determines that the commit ID of the configuration information of operation 704 is new, the server can store the configuration information of operation 704 as new backup data in the database. For another example, if the configuration information of operation 704 is different from the previous backup data and the server determines that the commit ID of the configuration information of operation 704 is new, the server can store the configuration information of operation 704 as new backup data in the database.

[0145] At this time, the commit ID assigned to the configuration information acquired in operation 704 may be used in operation 706 to determine whether to store the configuration information acquired in operation 704 in the database. For example, after the server assigns a commit ID in operation 705 to the configuration information acquired in operation 704 through the backup engine service, the server may determine whether the commit ID assigned to the configuration information in operation 705 is new through the ZTBR service. If the server determines through the ZTBR service that the commit ID of the configuration information of operation 704 is not new, the server may not store the configuration information of operation 704 as backup data. Alternatively, if the server determines through the ZTBR service that the commit ID of the configuration information of operation 704 is new, the server may store the configuration information of operation 704 in the database as backup data through the ZTBR service.

[0146] FIG. 8 is a flowchart of a procedure for storing backup data according to one embodiment of the present disclosure. Operations 801 to 814 of FIG. 8 may correspond to operations 205 of FIG. 2 or operations 504 to 505 of FIG. 5 , and therefore, any overlapping content with the preceding description will be briefly described.

[0147] In operation 801, the server (100) may receive a report from device A via an SNMP trap receiver service that a setting change has occurred in device A. According to one embodiment, device A may transmit a message notifying that a setting has been changed to an IP address set in relation to the SNMP trap receiver service, i.e., the IP address of the server (100). For example, the message of operation 801 may include a trap message.

[0148] In operation 802, the server can identify the device that sent the configuration change report via the SNMP Trap Receiver service. A message containing identification information of the device that sent the configuration change report can be issued by the producer engine of the SNMP Trap Receiver service. For example, the identification information of the device can include the device's UUID.

[0149] In steps 803 to 805, the server may request information from the identified device to confirm a configuration change. The requested information may include configuration information of the identified device. Furthermore, the action of requesting information may include attempting to connect to device A.

[0150] Specifically, in operation 803, the message issued in operation 802 may be responded to by the ZTBR service through the message broker service via the SNMP trap receiver service. In operation 804, the ZTBR service may request the backup engine service to check whether the configuration of device A has changed. In operation 805, the backup engine service may attempt to connect to device A (e.g., SSH connection). At this time, authentication information (e.g., SSH information) of device A included in the source information managed by the backup engine service may be utilized.

[0151] If the authentication information of device A included in the source information is correct, the backup engine service can connect to device A. If the authentication information is incorrect, the backup engine service cannot connect to device A. If device A cannot be connected, the server (100) can display an object indicating the connection status for device A through the front-end service. For example, in FIG. 4, the server (100) can display GUI (401) or GUI (402) for indicating a connection failure status through the front-end service.

[0152] According to one embodiment, the ZTBR service may periodically or repeatedly request the Backup Engine service for connection status information and average runtime information for devices included in the source information held by the Backup Engine service. Based on the connection status information and average runtime information received from the Backup Engine service, the ZTBR service may simultaneously check the connection status between the devices and the server for all devices.

[0153] In operation 806, the backup engine service may obtain configuration information A of network device A from device A. The backup engine service may generate a command requesting configuration information A from device A and / or transmit the command to device A. The backup engine service may receive configuration information A from device A based on the command.

[0154] The server (100) can determine whether the settings of device A have actually changed by comparing the setting information A with existing backup data. At this time, the existing backup data may include at least one of the backup data already stored in the database. The existing backup data may include the backup data most recently stored in the database in relation to the identified device and / or all of the backup data already stored in the database in relation to the identified device. In operations 807 to 811, the server (100) can determine that the setting information A is different from the previous backup data and compare the setting information A with the entire backup data.

[0155] For example, the backup engine service may compare configuration information A with existing backup data. In particular, the backup engine service may compare configuration information A with the immediately previous backup data. In operation 807, the backup engine service may determine that configuration information A is different from the immediately previous backup data. Based on the determination in operation 807, the backup engine service may generate, assign, or determine a commit ID A for configuration information A in operation 808.

[0156] As another example, the backup engine service may compare configuration information A with multiple backup data stored in the database. For example, if the backup engine service determines in operation 807 that configuration information A is different from the backup data, the backup engine service may generate, assign, or determine a commit ID A for configuration information A in operation 808.

[0157] Through actions 808 to 810, the ZTBR service can obtain the commit ID A generated by the backup engine service. In action 809, the ZTBR service can request the commit ID A from the backup engine service, and in action 810, the backup engine service can respond to the ZTBR service with the commit ID A.

[0158] The ZTBR service can determine whether commit ID A is a new commit ID. At operation 811, the ZTBR service can determine that commit ID A is new.

[0159] If the ZTBR service determines that commit ID A is new in operation 811, then in operation 812, the ZTBR service may request the backup engine service for configuration information A corresponding to commit ID A to store configuration information A in the database.

[0160] The ZTBR service can receive configuration information A corresponding to commit ID A from the backup engine service in operation 813, and store the configuration information A as new backup data in the database in operation 814.

[0161] FIG. 9 illustrates an example of a backup data list UI provided according to one embodiment of the present disclosure.

[0162] The backup data stored in this disclosure can be searched or viewed through a backup data list UI. Referring to FIG. 9, the backup data list UI may include a GUI (901) indicating the time at which the backup data was stored, a GUI (902) for searching for backup data, a GUI (903) for viewing backup data stored for a specific period, and / or GUIs for a viewer function for comparing two specified backup data.

[0163] According to one embodiment, the server may provide a viewer function that compares two specified backup data sets and visually displays the differences. To this end, the backup data list UI may further include a GUI (904) that receives user input for selecting two backup data sets. Furthermore, the backup data list UI may further include a GUI (905) that receives user input for viewing the entire contents of the backup data and a GUI that receives user input for copying the entire contents of the backup data.

[0164] For example, for a more convenient viewer experience, the server can use a front-end service to highlight the different parts of the two backup data sets and / or hide the same parts.

[0165] Due to storage limitations, backup data cannot be stored indefinitely. In one embodiment, the server may follow a policy (e.g., a retention policy) to delete backup data that has exceeded a certain retention period.

[0166] According to one embodiment, a server can determine which backup data among multiple backup data items are permanently stored, regardless of the retention policy. The server can mark the backup data to identify the permanently stored backup data. In the present disclosure, the permanently stored backup data may be referred to as genesis backup data. For example, genesis backup data may be used to restore device settings in the event of a failure or disaster. For example, genesis backup data may be initially set or determined based on user input. In this case, the backup data list UI may further include a GUI that receives user input for determining genesis backup data.

[0167] FIG. 10 is a flowchart of a recovery (or restoration) procedure according to one embodiment of the present disclosure.

[0168] The recovery procedure may involve replacing the settings of a specific device with specified backup data. The specified backup data may be determined based on user input. The specified backup data may include settings that ensure normal operation of the specific device even in the event of a failure or disaster.

[0169] Referring to FIG. 10, the server may determine designated backup data in operation 1001. In one embodiment, the server may receive user input for determining designated backup data. To this end, the server may display a GUI for receiving user input via a front-end service. In this case, the GUI may be included in the backup data list UI of FIG. 9.

[0170] According to one embodiment, in response to user input determining designated backup data, the designated backup data may be determined as genesis backup data.

[0171] The server can replace the device configuration with the specified backup data in operation S1002. Operation S1002 can be performed via the ZTBR service, the restore service, the configuration generator service, and the workflow service. Specifically, the ZTBR service can fetch the entire configuration information for the backup data from the database. The ZTBR service can send a restore request to the restore service, and the restore request can include the device configuration information.

[0172] Restore requests received by the Restore Service can be processed through the Configuration Generation Service and the Workflow Service. For example, the Configuration Generation Service can convert the device configuration information received from the ZTBR Service into a file and pass the file to the Workflow Service. The Workflow Service can then replace the device configuration information with specified backup data.

[0173] FIG. 11 illustrates a UI indicating the progress of a recovery (or restoration) procedure according to one embodiment of the present disclosure.

[0174] Referring to Figure 11, a task is created as the recovery procedure progresses. The UI indicating the progress of the recovery procedure may include a GUI indicating the name of the created task, a GUI indicating the IP address of the device, a GUI indicating the time at which the device's restoration began, and a GUI indicating the time at which the restoration was completed.

[0175] FIG. 12 is a flowchart illustrating a method for managing multiple devices in a wireless communication system according to one embodiment of the present disclosure.

[0176] In operation 1201, the server (100) can generate an inventory list for multiple devices.

[0177] Thereafter, in operation 1202, the server (100) may generate a backup target list based on the inventory list. In one embodiment, the server (100) may compare the inventory list with the backup target list to synchronize the backup target list with the inventory list. At this time, the server (100) may periodically and repeatedly compare the inventory list with the backup target list to synchronize the inventory list with the backup target list.

[0178] In operation 1203, the server (100) can store first backup data for devices included in the backup target list.

[0179] In operation 1204, the server (100) can determine whether the configuration information for the devices included in the backup target list has changed based on the first backup data. More specifically, the server (100) can receive a configuration change report from a device included in the backup target list, and identify the device included in the backup target list based on a universally unique identifier (UUID) included in the configuration change report. The server (100) can obtain current configuration information from the device included in the backup target list, and determine whether the configuration information for the device included in the backup target list has changed by comparing the first backup data for the device included in the backup target list with the current configuration information. In addition, the server (100) can compare the current configuration information with at least one or more backup data for the device included in the backup target list, and assign a commit ID to the current configuration information. More specifically, the current configuration information may be compared with at least one or more backup data, and if the current configuration information is identical to one of the stored backup data, the same commit ID as that of the corresponding backup data may be assigned. If no backup data identical to the current configuration information exists, a new commit ID may be assigned. Thereafter, by comparing the commit ID of the current configuration information with the commit IDs of multiple backup data stored in the database, it may be determined whether the configuration information for the devices included in the backup target list has changed.

[0180] In operation 1205, if the server (100) determines that the configuration information for a device included in the backup target list has changed, the server (100) may store second backup data based on the changed configuration information. The server (100) may store the second backup data in a database.

[0181] FIG. 13 is a block diagram of a device according to one embodiment of the present disclosure.

[0182] FIG. 13 illustrates the structure of a device (1300) according to one embodiment of the present disclosure.

[0183] As illustrated in FIG. 13, the device (1300) of the present disclosure may include a control unit (control unit) (1330) and a traffic forwarding unit. The traffic forwarding unit may include an input port (1310), an output port (1315), and a switch (1320). However, the components of the device (1300) are not limited to the examples described above. For example, the device (1300) may include more or fewer components than the components described above. In addition, the control unit (1330), the input port (1310), the output port (1315), and the switch (1320) may be implemented in the form of a single chip. The control unit (1330) of FIG. 13 may include at least one processor or controller. For example, the control unit (1330) may include a routing processor. The device (1300) of FIG. 13 may correspond to the devices (110) of FIG. 1. Although FIG. 13 illustrates the structure of a router, the device (1300) is not limited to a router. For example, the device (1300) may include a switch.

[0184] The input port (1310) may perform link layer functions necessary for interoperability with the link layer on the opposite side of the input link. Furthermore, the input port (1310) may search for the most appropriate interface or output port to forward the received packet to a specific location. The input port (1310) may refer to a forwarding table to determine the router output port to which the received packet will be forwarded through the switch. At this time, the input port (1310) and the output port (1315) may refer to physical input / output router interfaces different from ports associated with network applications and sockets.

[0185] Specifically, the input port (1310) can perform line termination functions and data link processing. Furthermore, based on a forwarding table determined by the control unit (1330) or a forwarding table received from a remote SDN controller (e.g., the control unit (1430) of FIG. 14), the input port (1310) can search for the most appropriate interface or output port. The input port (1310) can determine the output port (1315) through a forwarding table-based search and forward the packet to the switch (1320).

[0186] The switch (1320) can connect the input port (1310) and the output port (1315) of the router. The packet is transmitted from the input port (1310) to the output port (1315) through the switch (1320).

[0187] (1315) can be switched. For example, the switching method may include a packet switching method via memory, a packet switching method via a bus, and a switching method via an interconnection network. The control unit (1330) may include a routing processor to determine the forwarding table described above and transmit it to the input port (1310).

[0188] To this end, the memory of the device (1300) can store programs and data necessary for the operation of the device (1300). In addition, the memory can store control information or data included in signals transmitted and received by the device (1300). The memory can be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, there can be multiple memories.

[0189] FIG. 14 is a block diagram of a server according to one embodiment of the present disclosure.

[0190] FIG. 14 illustrates the structure of a server (1400) according to one embodiment of the present disclosure.

[0191] As illustrated in FIG. 14, the server (1400) of the present disclosure may include a control unit (control unit) (1430), a transceiver (1410), and a storage unit (memory) (1420). However, the components of the server (1400) are not limited to the examples described above. For example, the server (1400) may include more or fewer components than the components described above. In addition, the control unit (1430), the transceiver (1410), and the storage unit (1420) may be implemented in the form of a single chip. The control unit (1430) of FIG. 14 may include at least one processor or controller. The server (1400) of FIG. 14 may correspond to the server (100) of FIG. 1.

[0192] The control unit (1430) can control a series of processes so that the server can operate according to the embodiment of the present disclosure described above.

[0193] The transceiver (1410) can transmit and receive signals with the server. The signals transmitted and received with the server can include control information and data. The transceiver (1410) can be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and frequency-converts the received signal. However, the transceiver (1410) is only one embodiment, and the components of the transceiver (1410) are not limited to the RF transmitter and RF receiver. In addition, the transceiver (1410) can receive a signal through a wireless channel and output it to the control unit (1430), and transmit a signal output from the control unit (1430) through the wireless channel.

[0194] According to one embodiment, the storage unit (1420) may store programs and data required for the operation of the server (1400). In addition, the storage unit (1420) may store control information or data included in signals transmitted and received by the server (1400). The storage unit (1420) may be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, there may be a plurality of storage units (1420).

[0195] According to one embodiment, the storage unit (1420) may include a database storing an inventory list and a database storing a backup target list. The database storing the inventory list and the database storing the backup target list may be different from each other and may be classified as a first database and a second database, respectively.

[0196] Referring to FIG. 2, in operation 201, the control unit (1430) may generate an inventory list for a plurality of devices including the device (1300). At this time, the control unit (1430) may receive (or input) data for the device (1300) through an inventory UI supported by the server (1400), or may receive data for the device (1300) through the transceiver (1310). The control unit (1430) may generate an inventory list based on the data for the device (1300) and store it in the storage unit (1420). For example, the control unit (1430) may store the inventory list in a first database included in the storage unit (1420).

[0197] In operation 202, the control unit (1430) can generate a backup target list based on the inventory list, and the control unit (1430) can store the backup target list in the storage unit (1420). For example, the control unit (1430) can store the backup target list in a second database included in the storage unit (1420).

[0198] The backup target list may include a list of devices eligible for event-based backup. The control unit (1430) may also create an initial backup target list when initially creating an inventory list, and may subsequently change or update the backup target list when changing or updating the inventory list.

[0199] To this end, the control unit (1430) may compare the inventory list with the backup target list, as in operation 203. Specifically, the control unit (1430) may periodically, continuously, or repeatedly check for differences between the inventory list and the backup target list. In operation 204, the control unit (1430) may change or update the backup target list so that it matches the inventory list.

[0200] Additionally, in operation 205, the control unit (1430) can generate backup data based on the setting information of the device (1300) when the setting of the device (1300) included in the backup target list is changed.

[0201] Referring to FIG. 7, in operation 701, when the settings of a device (1300) included in the backup target list are changed, the control unit (1430) can receive a report from the device (1300) notifying that the settings have been changed. The setting change report message received from the device (1300) can be received, for example, through the transceiver (1410).

[0202] In operation 702, the control unit (1430) can identify that the settings of the device (1300) have changed based on the settings change report message. Specifically, the control unit (1430) can identify the UUID of the device (1300) based on the settings change report message.

[0203] In operation 703, the control unit (1430) may request configuration information from the device (1300). To this end, the control unit (1430) may attempt to connect or access the device (1300), for example, through the transceiver unit (1410). In operation 704, the control unit (1430) may obtain configuration information of the device (1300) through the transceiver unit (1410).

[0204] In operation 705, the control unit (1430) can compare the existing backup data with the setting information of the device (1300) acquired through operation 704 to determine whether the settings of the device (1300) have actually changed. For example, the control unit (1430) can compare the backup data stored in the storage unit (1420) with the setting information of the device (1300), and determine whether the settings of the device (1300) have changed based on the comparison result.

[0205] If the control unit (1430) determines that the settings of the device (1300) have changed in operation 705, the control unit (1430) may store the setting information of the device (1300) as a new version of backup data in operation 706. For example, the control unit (1430) may store the setting information of the device (1300) as new backup data in the second database of the storage unit (1430).

[0206] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0207] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.

[0208] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0209] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device performing an embodiment of the present disclosure.

[0210] In the specific embodiments of the present disclosure described above, components included in the invention are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0211] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are only specific examples to easily explain the technical contents of the present disclosure and help understand the present disclosure, and are not intended to limit the scope of the present disclosure. In other words, it will be apparent to those skilled in the art that other modifications based on the technical idea of ​​the present disclosure are possible. In addition, each embodiment can be combined and operated with each other as needed. For example, parts of one embodiment of the present disclosure and parts of another embodiment can be combined with each other to operate a base station and a terminal. For example, parts of the first embodiment and the second embodiment of the present disclosure can be combined with each other to operate a base station and a terminal. In addition, although the embodiments have been presented based on an FDD LTE system, other modifications based on the technical idea of ​​the embodiments can be implemented with other systems such as a TDD LTE system, 5G, or NR system.

[0212] Meanwhile, the order of description in the drawings explaining the method of the present invention does not necessarily correspond to the order of execution, and the order of precedence may be changed or executed in parallel.

[0213] Alternatively, the drawings illustrating the method of the present invention may omit some components and include only some components within a scope that does not harm the essence of the present invention.

[0214] In addition, the method of the present invention may be implemented by combining some or all of the contents included in each embodiment within a scope that does not harm the essence of the invention.

[0215] Various embodiments of the present disclosure have been described above. The foregoing description of the present disclosure is for illustrative purposes only, and the embodiments of the present disclosure are not limited to the disclosed embodiments. Those skilled in the art will appreciate that the present disclosure can be readily modified into other specific forms without altering the technical spirit or essential characteristics of the present disclosure. The scope of the present disclosure is indicated by the claims below rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included within the scope of the present disclosure.

[0216] A method performed by a server for an SDN (software defined network) system according to one embodiment of the present disclosure may include: an operation of generating an inventory list for a plurality of devices; an operation of generating a backup target list based on the inventory list; an operation of storing first backup data for devices included in the backup target list; an operation of determining whether setting information for a device included in the backup target list has changed based on the first backup data; and an operation of storing second backup data based on the changed setting information when it is determined that setting information for a device included in the backup target list has changed.

[0217] The operation of determining whether setting information for a device included in the backup target list has changed may include: an operation of receiving a setting change report from a device included in the backup target list; an operation of identifying a device included in the backup target list based on a universally unique identifier (UUID) included in the setting change report; an operation of obtaining current setting information from a device included in the backup target list; and an operation of comparing the first backup data for a device included in the backup target list with the current setting information.

[0218] The operation of determining whether the configuration information for the device included in the backup target list has changed may include an operation of assigning a commit ID of the current configuration information; and an operation of comparing the commit ID of the current configuration information with the commit IDs of a plurality of backup data stored in a database.

[0219] The method may further include an operation of attempting an SSH connection to a device included in the backup target list based on first SSH (secure shell) information; and an operation of displaying an object indicating a connection status between the server and the device based on a failure of the SSH connection.

[0220] The method may further include an operation of attempting an SSH connection to the device based on first SSH (secure shell) information; an operation of changing the first SSH information of the device included in the inventory list to second SSH information after the SSH connection fails; and an operation of changing the first SSH information of the device included in the backup target list to second SSH information based on the first SSH information being changed to the second SSH information.

[0221] The method may further include an operation of determining one backup data among a plurality of backup data stored in a database; and an operation of replacing the configuration information of the device with the determined backup data.

[0222] The method may further include an operation of receiving a user input for selecting two backup data from among a plurality of backup data stored in a database; an operation of comparing the two backup data with each other based on the user input; and an operation of displaying an object representing a different part of the two backup data.

[0223] The above method may further include an operation of deleting backup data excluding the specified backup data among a plurality of backup data whose storage time in the database exceeds a specified value.

[0224] The method may further include an operation of comparing the inventory list with the backup target list; an operation of synchronizing the backup target list with the inventory list; and an operation of storing second backup data in a database based on setting information of the device when it is determined that the setting of the device included in the backup target list has changed.

[0225] The operation of comparing the above inventory list with the above backup target list may be repeated periodically.

[0226] According to one embodiment of the present disclosure, a server for a software defined network (SDN) system includes a transceiver; a controller; and a storage unit for storing commands, wherein when the commands are executed by the controller: an inventory list for a plurality of devices is generated, a backup target list is generated based on the inventory list, first backup data for devices included in the backup target list is stored, whether setting information for devices included in the backup target list has changed is determined based on the first backup data, and when it is determined that setting information for devices included in the backup target list has changed, second backup data can be stored based on the changed setting information.

[0227] When the above commands are executed by the control unit: a configuration change report is received from a device included in the backup target list, a device included in the backup target list is identified based on a universally unique identifier (UUID) included in the configuration change report, current configuration information is acquired from a device included in the backup target list, and the first backup data for the device included in the backup target list and the current configuration information can be compared.

[0228] When the above commands are executed by the control unit: the commit ID of the current setting information is assigned, and the commit ID of the current setting information and the commit IDs of multiple backup data stored in the storage unit can be compared.

[0229] When the above commands are executed by the control unit: an SSH connection is attempted to a device included in the backup target list based on the first SSH (secure shell) information, and an object indicating the connection status of the server and the device may be displayed based on a failure of the SSH connection.

[0230] When the above commands are executed by the control unit: an SSH connection to the device is attempted based on the first SSH (secure shell) information, and after the SSH connection fails, the first SSH information of the device included in the inventory list is changed to second SSH information, and based on the first SSH information being changed to the second SSH information, the first SSH information of the device included in the backup target list can be changed to the second SSH information.

[0231] When the above commands are executed by the control unit: one backup data among a plurality of backup data stored in the storage unit is determined, and the configuration information of the device can be replaced with the determined backup data.

[0232] When the above commands are executed by the control unit: a user input for selecting two backup data from among a plurality of backup data stored in the storage unit is received, the two backup data are compared with each other based on the user input, and an object representing a different part of the two backup data can be displayed.

[0233] When the above commands are executed by the control unit: among the plurality of backup data whose time stored in the storage unit exceeds the specified value, the remaining backup data except for the specified backup data can be deleted.

[0234] When the above commands are executed by the control unit: the inventory list and the backup target list are compared, the backup target list is synchronized with the inventory list, and if it is determined that the settings of a device included in the backup target list have changed, second backup data may be stored in the storage unit based on the setting information of the device.

[0235] When the above commands are executed by the control unit: the inventory list and the backup target list can be periodically compared.

Claims

1. A method performed by a server for an SDN (software defined network) system, The action of generating an inventory list for multiple devices; An action to create a backup target list based on the above inventory list; An operation of storing first backup data for devices included in the above backup target list; An operation for determining whether setting information for a device included in the backup target list has changed based on the first backup data; and If it is determined that the setting information for the device included in the above backup target list has changed, an operation of storing second backup data based on the changed setting information is included. method.

2. In claim 1, The action of determining whether the configuration information for the devices included in the above backup target list has changed is as follows: An action of receiving a setting change report from a device included in the above backup target list; An action of identifying a device included in the backup target list based on a universally unique identifier (UUID) included in the above setting change report; An operation of obtaining current setting information from a device included in the above backup target list; and Comprising an operation of comparing the first backup data and the current setting information for the device included in the backup target list. method.

3. In claim 2, The action of determining whether the configuration information for the devices included in the above backup target list has changed is as follows: An action to assign a commit ID to the above current setting information; and An operation that includes comparing the commit ID of the current setting information with the commit IDs of multiple backup data stored in the database. method.

4. In claim 1, An operation of attempting to connect to a device included in the backup target list through SSH based on the first SSH (secure shell) information; and Further comprising an action of displaying an object indicating the connection status of the server and the device based on the failure of the SSH connection. method.

5. In claim 1, An action of attempting to connect to the device through SSH based on the first SSH (secure shell) information; After the above SSH connection fails, an operation of changing the first SSH information of the device included in the above inventory list to second SSH information; and Further comprising an action of changing the first SSH information of the device included in the backup target list to the second SSH information based on the first SSH information being changed to the second SSH information. method.

6. In claim 1, An operation of determining one backup data among multiple backup data stored in a database; and Further comprising an action of replacing the configuration information of the device with the determined backup data. method.

7. In claim 1, An action of receiving user input for selecting two backup data from among multiple backup data stored in a database; An operation of comparing the two backup data based on the user input; and Further comprising an action of displaying an object representing different parts of the above two backup data. method.

8. In claim 1, It further includes an action of deleting the remaining backup data except for the specified backup data among the multiple backup data whose storage time in the database exceeds the specified value. method.

9. In claim 1, An action of comparing the above inventory list with the above backup target list; An action to synchronize the above backup target list with the above inventory list; If it is determined that the settings of a device included in the above backup target list have changed, an action of storing second backup data in a database based on the setting information of the device is further included. method.

10. In claim 9, The operation of comparing the above inventory list with the above backup target list is repeated periodically. method.

11. In a server for SDN (software defined network) system, a transceiver; controller; and A storage unit for storing commands, wherein when the commands are executed by the control unit: An inventory list is created for multiple devices, A backup target list is created based on the above inventory list. The first backup data for the devices included in the above backup target list is stored, Based on the first backup data, it is determined whether the setting information for the device included in the backup target list has changed. If it is determined that the setting information for the device included in the above backup target list has changed, the second backup data is stored based on the changed setting information. Server.

12. In claim 11, when the commands are executed by the control unit: A configuration change report is received from a device included in the above backup target list, The devices included in the backup target list are identified based on the universally unique identifier (UUID) included in the above setting change report, Current setting information is obtained from the devices included in the above backup target list, The first backup data and the current setting information for the devices included in the backup target list are compared. Server.

13. In claim 12, when the commands are executed by the control unit: The commit ID of the above current setting information is assigned, The commit ID of the current setting information above is compared with the commit IDs of multiple backup data stored in the storage unit. Server.

14. In claim 11, when the commands are executed by the control unit: An SSH connection is attempted to a device included in the backup target list based on the first SSH (secure shell) information, and An object indicating the connection status between the server and the device is displayed based on the failure of the above SSH connection. Server.

15. In claim 11, when the commands are executed by the control unit: An SSH connection to the device is attempted based on the first SSH (secure shell) information, After the above SSH connection fails, the first SSH information of the device included in the inventory list is changed to the second SSH information, and The first SSH information of the device included in the backup target list is changed to the second SSH information based on the first SSH information being changed to the second SSH information. Server.

Images