Management server and control method thereof

Abstract

The present disclosure relates to a management server and a control method thereof. Specifically, a management server and a control method thereof may be provided, the management server comprising a monitoring module and a scheduling module, wherein: the monitoring module receives resource information from at least one cluster; and the scheduling module receives an update request for the at least one cluster, determines an update timepoint of the at least one cluster on the basis of status information and network performance information included in the resource information and the service coverage of neighboring clusters, and transmits an update specification so as to update network functions of the at least one cluster at the determined update timepoint.

Description

Management server and its control method

[0001] The present disclosure relates to a management server and a control method thereof. Specifically, the present disclosure provides a management server for updating a cloud-native network function (CNF) of a cluster and a control method thereof.

[0002] The management server can update the network functions of at least one cluster. The network functions can be cloud-native network functions (CNFs). A cloud-native network function can be a unit of service provided by a cloud architecture.

[0003] The management server can update network functions regardless of the state of at least one cluster. If the management server updates network functions regardless of the state of at least one cluster, network loss may occur depending on the state of at least one cluster.

[0004] A management server according to one embodiment of the present disclosure may include a monitoring module and a scheduling module. The monitoring module according to one embodiment may receive resource information from at least one cluster. The scheduling module according to one embodiment may receive an update request for at least one cluster. The scheduling module according to one embodiment may determine an update time for at least one cluster based on status information and network performance information included in the resource information and the service range of adjacent clusters. The scheduling module according to one embodiment may transmit an update specification to update the network function of at least one cluster at the determined update time.

[0005] A method for controlling a management server according to one embodiment of the present disclosure may include an operation for receiving resource information from at least one cluster. A method for controlling a management server according to one embodiment of the present disclosure may include an operation for receiving an update request for at least one cluster. A method for controlling a management server according to one embodiment of the present disclosure may include an operation for determining an update time for at least one cluster based on status information and network performance information included in the resource information and a service range of an adjacent cluster. A method for controlling a management server according to one embodiment of the present disclosure may include an operation for transmitting an update specification to update a network function of at least one cluster at the determined update time.

[0006] FIG. 1 is a diagram illustrating a system including a management server and at least one cluster according to one embodiment of the present disclosure.

[0007] FIG. 2 is a block diagram illustrating a management server according to one embodiment of the present disclosure.

[0008] FIG. 3 is a block diagram illustrating a first cluster according to one embodiment of the present disclosure.

[0009] FIG. 4 is a block diagram illustrating a cloud structure according to one embodiment of the present disclosure.

[0010] FIG. 5 is a flowchart illustrating a control method of a management server according to one embodiment of the present disclosure.

[0011] FIG. 6 is a flowchart showing a control method of a management server according to one embodiment of the present disclosure by operating subject.

[0012] FIG. 7 is a diagram illustrating controlling the update timing of at least one cluster according to a control method of a management server according to one embodiment of the present disclosure.

[0013] FIG. 8 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster based on hardware resource information.

[0014] FIG. 9 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster based on software resource information.

[0015] FIG. 10 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster based on regional information.

[0016] FIG. 11 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster according to a service scope.

[0017] FIG. 12 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster according to a network element (NE) type.

[0018] The terms used in this disclosure will be briefly explained, and one embodiment of the present disclosure will be specifically described.

[0019] The terms used in this disclosure are selected from widely used, current terms, taking into account the functions of one embodiment of the disclosure. However, these terms may vary depending on the intentions of those skilled in the art, precedents, the emergence of new technologies, etc. Furthermore, in certain cases, terms may be arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the description of the relevant embodiments of the disclosure. Therefore, the terms used in this disclosure should not be defined simply as names of terms, but rather based on the meanings of the terms and the overall content of the disclosure.

[0020] In this disclosure, the expression “at least one of a, b or c” may refer to “a”, “b”, “c”, “a and b”, “a and c”, “b and c”, “all of a, b and c”, or variations thereof.

[0021] Throughout this disclosure, when a part is said to "include" a component, this does not exclude other components, but rather implies the inclusion of other components, unless otherwise specifically stated. Furthermore, terms such as "part," "module," and the like described herein refer to a unit that processes at least one function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

[0022] Below, with reference to the attached drawings, embodiments of the present disclosure are described in detail so that those skilled in the art can easily implement the present disclosure. However, one embodiment of the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In addition, in the drawings, parts irrelevant to the description are omitted to clearly describe one embodiment of the present disclosure, and similar parts are designated with similar drawing reference numerals throughout the present disclosure.

[0023] FIG. 1 is a diagram illustrating a system (100) including a management server (120) and at least one cluster (130, 140, 150) according to one embodiment of the present disclosure.

[0024] A cluster can be a collection of resources that perform computational processing. A cluster can take the form of a server, a base station, or a data center. For example, a data center may be a collection of multiple clusters containing a large number of resources.

[0025] The management server (120) may be a server that manages at least one cluster (130, 140, 150). The management server (120) may be referred to as a management cluster.

[0026] At least one cluster (130, 140, 150) can provide a call service to a user equipment (UE) within a designated area. At least one cluster (130, 140, 150) can include multiple clusters. For example, at least one cluster (130, 140, 150) can include a first cluster (130), a second cluster (140), and a third cluster (150). At least one cluster (130, 140, 150) can have a designated service range. For example, the first cluster (130) can have a first service range (131). For example, the second cluster (140) can have a second service range (141). For example, the third cluster (150) can have a third service range (151). The service scope can be referred to as the coverage of the cluster.

[0027] If at least one cluster (130, 140, 150) is located within a specified distance from the management server (120), the at least one cluster (130, 140, 150) may be referred to as an edge cluster. If at least one cluster (130, 140, 150) is located further than a specified distance from the management server (120), the at least one cluster (130, 140, 150) may be referred to as a far edge cluster.

[0028] The management server (120) can receive resource information from at least one cluster (130, 140, 150). The management server (120) can periodically monitor resource information from at least one cluster (130, 140, 150). The resource information can include status information and network performance information.

[0029] The status information may include hardware information of at least one cluster (130, 140, 150), software information of at least one cluster (130, 140, 150), and base station status information of at least one cluster (130, 140, 150). The hardware information may include hardware resource capacity of at least one cluster (130, 140, 150) and hardware resource usage of at least one cluster (130, 140, 150). The software information may include software resource usage of at least one cluster (130, 140, 150), the number of user terminals connected to at least one cluster (130, 140, 150), and the number of active calls of at least one cluster (130, 140, 150). The base station status information of at least one cluster (130, 140, 150) may include region information of at least one cluster (130, 140, 150), service range information of at least one cluster (130, 140, 150), and network element (NE) type information of at least one cluster.

[0030] Network performance information may include key performance indicators (KPIs) of a network to which at least one cluster (130, 140, 150) is connected.

[0031] The management server (120) can receive an update request from a user (110). In response to the update request, the management server (120) can analyze resource information from at least one cluster (130, 140, 150).

[0032] The management server (120) can determine the update time based on the status information and network performance information included in the resource information and the service range of the adjacent cluster. The management server (120) can determine the update time based on the hardware information of at least one cluster (130, 140, 150), the software information of at least one cluster (130, 140, 150), the base station status information of at least one cluster (130, 140, 150), the Key Performance Indicator (KPI) of the network to which at least one cluster (130, 140, 150) is connected, and the service range of the adjacent cluster.

[0033] The management server (120) can control the update timing of at least one cluster (130, 140, 150). The management server (120) can transmit an update specification to at least one cluster (130, 140, 150) to update the network function of at least one cluster (130, 140, 150) at the determined update timing.

[0034] The management server (120) can analyze the status of at least one cluster (130, 140, 150) and the status of the network to which at least one cluster (130, 140, 150) is connected based on resource information. The management server (120) can determine an update time based on the analysis results. Accordingly, the management server (120) can reduce network loss that occurs when updating network functions.

[0035] FIG. 2 is a block diagram illustrating a management server (120) according to one embodiment of the present disclosure. The management server (120) according to one embodiment may include a monitoring module (210) and a scheduling module (220).

[0036] The monitoring module (210) can monitor the status of a plurality of micro-services. A micro-service can include a network function of at least one cluster (130, 140, 150). For example, a micro-service can be a unit service that provides a cloud-native network function (CNF). A micro-service can perform call processing in a cloud environment. For example, the monitoring module (210) can monitor the number of calls being processed by each of the plurality of micro-services, the number of emergency calls being processed by each of the plurality of micro-services, and the throughput of each of the plurality of micro-services. The monitoring module (210) can periodically monitor the status of the plurality of micro-services. The monitoring module (210) can transmit the status of the monitored plurality of micro-services to the scheduling module (220).

[0037] The scheduling module (220) can receive the results of monitoring the status of a plurality of microservices from the monitoring module (210). The scheduling module (220) can determine the update timing of a plurality of microservices of at least one cluster (130, 140, 150). The scheduling module (220) can determine the update order and update method (Option) of the plurality of microservices based on an update request from a user (110). For example, the monitoring module (210) can determine the update order so that a microservice with a smaller number of calls being processed among the plurality of microservices is updated first.

[0038] FIG. 3 is a block diagram illustrating a first cluster (130) according to one embodiment of the present disclosure. The first cluster (130) according to one embodiment may include an execution module (310) and a storage module (320). The description of the first cluster (130) with reference to FIG. 3 may be equally applied to the second cluster (140) or the third cluster (150).

[0039] The execution module (310) can execute a plurality of network functions (311, 312, 313). The plurality of network functions (311, 312, 313) can include functions for performing call processing. For example, the plurality of network functions (311, 312, 313) can include a first network function (311), a second network function (312), a second network function (312), and an Nth (N is a natural number greater than or equal to 3) network function (313). The execution module (310) can update the plurality of network functions (311, 312, 313). The execution module (310) can receive an update specification from the management server (120). The execution module (310) can update the plurality of network functions (311, 312, 313) according to the requirements of the update specification.

[0040] The storage module (320) can store status information (321) and network performance information (322). The storage module (320) can transmit the status information (321) and network performance information (322) to the management server (120).

[0041] The first cluster (130) can manage a cloud structure (330). The plurality of network functions (311, 312, 313) of the first cluster (130) can be cloud native network functions that manage the cloud structure (330).

[0042] FIG. 4 is a block diagram illustrating a cloud structure (330) according to one embodiment of the present disclosure. The cloud structure (330) may be a structure that virtualizes network functions using a cloud environment. The cloud structure (330) may create network functions using a plurality of containers (431, 432, 433). The cloud structure (330) according to one embodiment may include a hardware layer (410), an operating system (OS) layer (420), and a container layer (430).

[0043] The hardware layer (410) may include physical network equipment of the cloud structure (330). The hardware layer (410) may include commodity hardware.

[0044] The operating system layer (420) can drive the operating system of the cloud structure (330). The operating system layer (420) can drive the operating system to execute network functions.

[0045] The container layer (430) may include a plurality of containers (431, 432, 433). For example, the container layer (430) may include a first container (431), a second container (432), a first container (433), and an Nth container (N is a natural number greater than or equal to 3).

[0046] Each of the plurality of containers (431, 432, 433) may include a plurality of network functions (311, 312, 313). For example, a first container (431) may include a first network function (311). For example, a second container (432) may include a second network function (312). For example, an N-th container (433) may include an N-th network function (313). The cloud structure (330) may include the plurality of network functions (311, 312, 313) in the plurality of containers (431, 432, 433) such that each of the plurality of network functions provides a microservice.

[0047] FIG. 5 is a flowchart illustrating a control method of a management server (120) according to one embodiment of the present disclosure.

[0048] In operation 510, a management server (120) according to an embodiment may receive resource information from at least one cluster (130, 140, 150). At least one cluster (130, 140, 150) may be configured as a cloud-native network function (CNF). The management server (120) may receive hardware information from at least one cluster (130, 140, 150). The hardware information may include CPU information, memory information, and capacity information. The management server (120) may receive software information from at least one cluster (130, 140, 150). The software information may include throughput information, latency information, number of user terminals information, and number of processed calls information.

[0049] In operation 520, a management server (120) according to an embodiment may receive an update request for at least one cluster (130, 140, 150). The management server (120) may receive an update request for at least one cluster (130, 140, 150) from a user (110). The management server (120) may receive an update rule related to the update request. The update rule may include at least one of an update completion deadline for at least one cluster (130, 140, 150), a hardware parameter of at least one cluster (130, 140, 150), a software parameter of at least one cluster (130, 140, 150), and an update region of at least one cluster (130, 140, 150).

[0050] In operation 530, the management server (120) according to an embodiment may determine an update time of at least one cluster (130, 140, 150) based on status information and network performance information included in resource information and the service range of the adjacent cluster. The management server (120) may determine an update time based on hardware information of at least one cluster (130, 140, 150), software information of at least one cluster (130, 140, 150), base station status information of at least one cluster (130, 140, 150), a Key Performance Indicator (KPI) of a network to which at least one cluster (130, 140, 150) is connected, and the service range of the adjacent cluster.

[0051] The management server (120) may include a storage module. The storage module may store status information and service scope.

[0052] The management server (120) can identify a first service range of at least one cluster (130, 140, 150) and a second service range of an adjacent cluster. If the first service range and the second service range overlap at least partially, the management server (120) can set a first update period of at least one cluster (130, 140, 150) and a second update period of the adjacent cluster to not overlap. For example, if the first service range and the second service range overlap at least partially, the management server (120) can update at least one cluster (130, 140, 150) and update the adjacent cluster after the update of at least one cluster (130, 140, 150) is completed.

[0053] The management server (120) may determine an update time based on a network element (NE) type of at least one cluster (130, 140, 150). The network element type may include whether the network function performed by at least one cluster (130, 140, 150) is a central unit (CU) or a distributed unit (DU). The network element type may include whether the central unit and the distributed unit operate in one cluster. The network element type may include whether at least one cluster (130, 140, 150) is a stand-alone (SA) mode or a non-stand-alone (NSA) mode. The network element type may include whether the frequency band used by at least one cluster (130, 140, 150) is Sub-6 or mmWave. The management server (120) can set the first update period of at least one cluster (130, 140, 150) and the second update period of the adjacent cluster to not overlap when the network element types of the adjacent clusters overlap at least partially.

[0054] The management server (120) can determine the update time based on at least one of whether the adjacent cluster is updated and the version of the adjacent cluster. The management server (120) can identify the status of the adjacent cluster. The management server (120) can identify the version of the adjacent cluster based on the status of the identified adjacent cluster. The management server (120) can determine the update time of at least one cluster (130, 140, 150) based on the version of the identified adjacent cluster.

[0055] The management server (120) can identify whether the number of user equipment (UE) connected to at least one cluster (130, 140, 150) and the number of active calls of at least one cluster (130, 140, 150) are below a threshold value and the number of currently active emergency calls. The management server (120) can identify internal resources of the current cluster. The management server (120) can identify the number of user equipment and the number of active calls based on the result of identifying the internal resources. The management server (120) can determine an update time based on the result of identifying the number of user equipment and the number of active calls.

[0056] The management server (120) can determine the timing of an update based on the service range and network element type of the adjacent cluster, if other rules other than the base station status are satisfied. If an update is not in progress in an adjacent cluster of the same network element type among adjacent clusters with service ranges that overlap with the coverage of the cluster, the management server (120) can proceed with the update of the relevant cluster.

[0057] In operation 540, the management server (120) according to one embodiment may transmit an update specification to update the network function of at least one cluster (130, 140, 150) at a determined update time.

[0058] At least one cluster (130, 140, 150) can receive an update specification. At least one cluster (130, 140, 150) can update a network function based on the received update specification. At least one cluster (130, 140, 150) can transmit an update status in response to the update specification. The management server (120) can receive the update status transmitted from at least one cluster (130, 140, 150). The management server (120) can provide an update result based on the update status.

[0059] FIG. 6 is a flowchart showing a control method of a management server (120) according to one embodiment of the present disclosure by operating subject.

[0060] In operation 610, a management server (120) according to an embodiment may request resource information from a first cluster (130).

[0061] In one embodiment of operation 620, a first cluster (130) may provide resource information to a management server (120).

[0062] In operation 630, a management server (120) according to an embodiment may receive an update request from a user (110).

[0063] In operation 640, the management server (120) according to an embodiment may receive an update rule from the user (110). For example, the management server (120) may receive an update rule including an update completion deadline, maximum CPU usage during update, maximum memory usage during update, maximum call drop rate during update, update region, and network element type.

[0064] In operation 650, the management server (120) according to an embodiment can determine the update time. The management server (120) can determine the update time using the resource resources of the first cluster (130) being monitored and the key performance indicators of the network.

[0065] In operation 660, the management server (120) according to an embodiment may transmit an update specification to the first cluster (130). The update specification may include information related to the update progress of the cloud native network function included in the first cluster (130).

[0066] In operation 670, the first cluster (130) according to an embodiment may transmit an update status to the management server (120). The first cluster (130) may update the cloud native network function according to the update specification. The first cluster (130) may transmit the update status, including information related to the update progress status, to the management server (120).

[0067] In operation 680, the management server (120) according to an embodiment may provide an update result. The management server (120) may provide the user with an update result of the first cluster (130).

[0068] FIG. 7 is a drawing showing controlling the update timing of at least one cluster (130, 140, 150) according to a control method of a management server (120) according to one embodiment of the present disclosure.

[0069] The management server (120) can update at least one cluster (130, 140, 150). The management server (120) can update the first cluster (130), the second cluster (140), and the Nth cluster (150) (N is a natural number greater than or equal to 3). The management server (120) can update the first cluster (130), the second cluster (140), and the Nth cluster (150) to reduce loss of the overall network.

[0070] The management server (120) can control the update timing of the Nth cluster (150) so that the update of the Nth cluster (150) whose service range does not overlap with an adjacent cluster among at least one cluster (130, 140, 150) is performed first. The management server (120) can receive update completion status information (710) from the Nth cluster (150).

[0071] The management server (120) can perform updates of the first cluster (130) and the second cluster (140) among at least one cluster (130, 140, 150) whose service ranges at least partially overlap with each other so that they do not overlap. The management server (120) can receive update status information (720) from the first cluster (130). The management server (120) can control the update of the second cluster (140) to a standby state. The management server (120) can control the update timing of the second cluster (140) to a time after the update of the first cluster (130) is completed. The management server (120) can receive update standby status information (730) from the second cluster (140).

[0072] FIG. 8 is a diagram illustrating a management server (120) according to one embodiment of the present disclosure controlling the update timing of at least one cluster (130, 140, 150) based on hardware resource information.

[0073] In operation 810, a management server (120) according to an embodiment can obtain hardware resource information of a cluster. The hardware resource information can include CPU parameters of the cluster, memory parameters of the cluster, and capacity parameters of the cluster.

[0074] In one embodiment, the management server (120) may obtain hardware resource usage information and hardware resource capacity information within a base station including the cluster in relation to hardware resource information of the cluster. For example, the management server (120) may obtain CPU usage information of a base station including the cluster, memory usage information of the base station, and capacity information of the base station. The management server (120) may qualitatively or quantitatively classify the hardware resource information. For example, the management server (120) may classify the hardware resource information into tiny, small, medium, and large. For example, the management server (120) may obtain and store the hardware resource information as a quantitative value for each parameter.

[0075] In operation 820, the management server (120) according to an embodiment can determine whether resource usage is below a threshold value. The resource usage threshold value may be a value determined by the parameter type of the hardware resource. For example, the CPU usage threshold value may be 5 cores. For example, the memory usage threshold value may be 10 gigabytes.

[0076] The management server (120) can determine whether resource usage is below a threshold value, either separately from resource usage or by additionally considering other hardware resource information values, such as resource usage. For example, the management server (120) can determine that resource usage is below a threshold value if CPU usage is 5 cores and the total memory capacity of the CPU is 20 gigabytes.

[0077] According to one embodiment, the management server (120) may proceed to operation 830 if the resource usage is below the threshold value (operation 820 - Yes). According to one embodiment, the management server (120) may proceed to operation 840 if the resource usage is greater than the threshold value (operation 820 - No).

[0078] In operation 830, the management server (120) according to an embodiment may send an update specification. The management server (120) may determine that it is time to proceed with a cluster update if the resource usage is below a threshold value. The management server (120) may send an update specification including a command to update the cluster if the resource usage is below the threshold value.

[0079] In operation 840, the management server (120) according to one embodiment may wait for the transmission of an update specification. If the resource usage exceeds a threshold value, the management server (120) may determine that it is time to suspend the cluster update. If the resource usage exceeds the threshold value, the management server (120) may wait for the transmission of the update specification until the resource usage falls below the threshold value.

[0080] FIG. 9 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster based on software resource information.

[0081] In operation 910, a management server (120) according to an embodiment can obtain information on software resource usage of a cluster, the number of terminals connected to the cluster, and the number of active calls. The software resource information can include information on software resource usage, the number of terminals connected to the cluster, and the number of active calls. The software resource information can include a throughput parameter of the cluster, a latency parameter of the cluster, a number parameter of user terminals of the cluster, and a number parameter of calls. The management server (120) can obtain software resource information of the cluster. Based on the software resource information, the management server (120) can obtain information on software resource usage of the cluster, the number of terminals connected to the cluster, and the number of active calls.

[0082] In one embodiment, the management server (120) may monitor software resource usage within a base station including the cluster, in relation to software resource information of the cluster. For example, the management server (120) may monitor the number of user terminals connected to the base station and the number of active calls connected to the base station. The management server (120) may obtain and store software resource information in quantitative form.

[0083] In operation 920, the management server (120) according to an embodiment can identify whether a point in time at which call drops are minimized has been reached. The point in time at which call drops are minimized can be determined based on software resource information. For example, the management server (120) can estimate the number of call drops based on information included in the software resource information, such as the software resource usage of the cluster, the number of terminals connected to the cluster, and the number of active calls. The management server (120) can identify a point in time at which call drops are expected to be minimized. The management server (120) can identify whether the point in time at which call drops are expected to be minimized is currently present.

[0084] The management server (120) can identify a point in time when call drops are expected to be minimized, either separately or in addition to the software resource information, by additionally considering other conditions. The management server (120) can receive an update rule related to at least some of the update completion deadline, monitored hardware parameters, and monitored base station status. The management server (120) can receive an update rule related to a call drop condition. For example, the management server (120) can receive an update rule that a call drop rate must be 1% or less. The management server (120) can identify a point in time when an update rule related to a call drop condition is satisfied.

[0085] According to one embodiment, the management server (120) may proceed to operation 930 if the call drop is minimized (operation 920 - Yes). According to one embodiment, the management server (120) may proceed to operation 940 if the call drop is not minimized (operation 920 - No).

[0086] In operation 930, the management server (120) according to an embodiment may send an update specification. The management server (120) may determine that it is time to proceed with a cluster update when call drops are minimized. The management server (120) may send an update specification including a command to update the cluster when resource usage is at a point where call drops are minimized. In a multi-cluster environment, if multiple clusters meet the update conditions, the management server (120) may preferentially proceed with the update of a cluster expected to have a lower call drop rate among the multiple clusters.

[0087] In operation 940, the management server (120) according to one embodiment may wait for the transmission of an update specification. If the call drop rate is not minimized, the management server (120) may determine that it is time to suspend the cluster update. If the call drop rate is not minimized, the management server (120) may wait for the transmission of an update specification until resource usage falls below a threshold.

[0088] FIG. 10 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster based on regional information.

[0089] In operation 1010, the management server (120) according to one embodiment may obtain regional information about the cluster. The regional information may include information related to the actual location of the cluster. The management server (120) may obtain regional information about the cluster to determine the status of adjacent clusters. The management server (120) may designate a region for which an update is to be performed.

[0090] In one embodiment, the management server (120) may monitor the update status, version, and status of a cluster in relation to the cluster's local information. For example, the management server (120) may monitor the update status, version, and status of a neighboring cluster to determine the status of the neighboring cluster.

[0091] In operation 1020, the management server (120) according to one embodiment can identify whether a neighboring cluster is being updated. Whether a neighboring cluster is being updated can be determined based on the cluster's local information. For example, the management server (120) can identify whether a neighboring cluster is being updated by monitoring the status of the neighboring cluster in real time.

[0092] The management server (120) can identify whether an adjacent cluster is being updated by considering other conditions separately from or in addition to the cluster's regional information.

[0093] According to one embodiment, the management server (120) may proceed to operation 1030 if the adjacent cluster is being updated (operation 1020 - Yes). According to one embodiment, the management server (120) may proceed to operation 1040 if the adjacent cluster is not being updated (operation 1020 - No).

[0094] In operation 1030, the management server (120) according to one embodiment may wait for the transmission of an update specification. If an adjacent cluster is being updated, the management server (120) may determine that it is time to suspend the cluster update. If an adjacent cluster is being updated, the management server (120) may wait for the transmission of an update specification until the update of the adjacent cluster is completed.

[0095] In operation 1040, the management server (120) according to an embodiment may send an update specification. If the adjacent cluster is not currently being updated, the management server (120) may determine that it is time to proceed with the cluster update. If the adjacent cluster is not currently being updated, the management server (120) may send an update specification including a command to update the cluster. The management server (120) may monitor the status of the adjacent cluster in real time and control the update timing of the corresponding cluster.

[0096] FIG. 11 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster according to a service scope.

[0097] In operation 1110, a management server (120) according to an embodiment may acquire the service scope of a cluster and the service scope of an adjacent cluster. The service scope may include the management scope of the cluster. The service scope may be referred to as the coverage of the cluster.

[0098] In one embodiment, the management server (120) may obtain information about the frequency bandwidth of the cluster to obtain the service range of the cluster and the service range of the adjacent cluster. For example, the management server (120) may identify whether the frequency bandwidth of the cluster is a millimeter wave (mmWave) band, a sub-6 GHz band, or a C-band band. The service range of the cluster may be determined based on the frequency bandwidth of the cluster. For example, the management server (120) may identify the service range of the cluster by frequency band.

[0099] In operation 1120, the management server (120) according to an embodiment can identify whether the service range of the cluster and the service range of the adjacent cluster overlap. The management server (120) can identify whether the service range of the acquired cluster and the service range of the adjacent cluster overlap with each other. For example, the management server (120) can identify whether the management range of the cluster and the management range of the adjacent cluster overlap at least partially. For example, the management server (120) can identify whether the frequency range of the cluster and the frequency range of the adjacent cluster overlap at least partially.

[0100] The management server (120) can identify whether the service range of the cluster and the service range of the adjacent cluster overlap by additionally considering the regional information of the cluster along with the service range of the cluster and the service range of the adjacent cluster.

[0101] According to one embodiment, the management server (120) may proceed to operation 1130 if the service range of the cluster and the service range of the adjacent cluster overlap (operation 1120 - Yes). According to one embodiment, the management server (120) may proceed to operation 1140 if the service range of the cluster and the service range of the adjacent cluster do not overlap (operation 1120 - No).

[0102] In operation 1130, the management server (120) according to one embodiment may wait for the transmission of an update specification. If the service range of the cluster and the service range of the adjacent cluster overlap, the management server (120) may determine that it is time to suspend the progress of the cluster update. If the service range of the cluster and the service range of the adjacent cluster overlap, the management server (120) may wait for the transmission of the update specification until the update of the adjacent cluster is completed.

[0103] The management server (120) can sequentially update the cluster and the adjacent cluster when the service range of the cluster and the service range of the adjacent cluster overlap. When the service range of the cluster and the service range of the adjacent cluster overlap, the management server (120) can control the update timing of the cluster so that the cluster update and the update of the adjacent cluster do not occur simultaneously. Accordingly, the management server (120) can control the update timing of the cluster, thereby reducing network loss that occurs during cluster updates.

[0104] In operation 1140, the management server (120) according to an embodiment may send an update specification. The management server (120) may determine that it is time to proceed with an update of the cluster if the service range of the cluster and the service range of the adjacent cluster do not overlap. The management server (120) may send an update specification including a command to update the cluster if the service range of the cluster and the service range of the adjacent cluster do not overlap. The management server (120) may determine the service range of the cluster and the service range of the adjacent cluster in real time and control the update timing of the corresponding cluster.

[0105] FIG. 12 is a diagram illustrating a management server according to one embodiment of the present disclosure controlling the update timing of at least one cluster according to a network element (NE) type.

[0106] In operation 1210, a management server (120) according to an embodiment may obtain network element type information of a cluster. The network element type information of the cluster may include type information related to cloud native network functions. For example, the network element type information may include CNF types such as Access Control Plane Function (ACPF), Access User Plane Function (AUPF), Access vDU Processing Function (ADPF), and Unified Access Distribute Unit Processing Function (UADPF). The management server (120) may specify a CNF type for which an update is to be performed.

[0107] In one embodiment, the management server (120) can identify and distinguish the type of cluster to obtain network element type information of the cluster. For example, the management server (120) can identify whether the type of cluster is a central unit (CU) type or a distributed unit (DU) type. The management server (120) can distinguish between a central unit type cluster and a distributed unit type cluster.

[0108] In one embodiment, the management server (120) can identify and distinguish the communication support range of the cluster to obtain network element type information of the cluster. For example, the management server (120) can identify whether the communication support range of the cluster is SA (Stand Alone, 5G only) or NSA (Non Stand Alone, 5G + LTE). The management server (120) can distinguish between SA clusters and NSA clusters.

[0109] In operation 1220, the management server (120) according to an embodiment can identify whether the network element type of an adjacent cluster overlaps at least partially. The management server (120) can identify the network element type of the cluster based on the network element type information of the acquired cluster. The management server (120) can identify whether the network element type of the cluster and the network element type of the adjacent cluster overlap each other. For example, the management server (120) can identify whether the type of the cluster and the type of the adjacent cluster are the same, such as a central unit type cluster or a distribution unit type cluster. For example, the management server (120) can identify whether the communication support range of the cluster and the communication support range of the adjacent cluster overlap at least partially.

[0110] The management server (120) can identify the association between a central unit type cluster and a distribution unit type cluster. The management server (120) can identify the association between an SA cluster and an NSA cluster. The management server (120) can perform updates based on the association between the clusters.

[0111] According to one embodiment, the management server (120) may proceed to operation 1230 if the adjacent cluster and the network element type overlap at least partially (operation 1220 - Yes). According to one embodiment, the management server (120) may proceed to operation 1240 if the adjacent cluster and the network element type do not overlap (operation 1220 - No).

[0112] In operation 1230, the management server (120) according to one embodiment may wait for the transmission of an update specification. The management server (120) may determine that it is time to suspend the progress of a cluster update if the network element type overlaps at least partially with an adjacent cluster. If the network element type overlaps at least partially with an adjacent cluster, the management server (120) may wait for the transmission of an update specification until the update of the adjacent cluster is completed.

[0113] The management server (120) can sequentially update a cluster and update adjacent clusters when the network element types overlap at least partially with adjacent clusters. The management server (120) can control the update timing of a cluster so that the cluster updates and updates of adjacent clusters do not occur simultaneously when the network element types overlap at least partially with adjacent clusters. Accordingly, the management server (120) can control the update timing of a cluster and reduce network loss that occurs during cluster updates.

[0114] The management server (120) can identify whether the adjacent clusters undergoing an update are SA or NSA clusters before updating the SA cluster and NSA cluster. The management server (120) can determine the timing of the update based on whether the adjacent clusters are SA or NSA clusters. For example, if an adjacent NSA cluster is undergoing an update, the management server (120) can wait for the update of another NSA cluster. Accordingly, the management server (120) can reduce the loss of the LTE network that occurs during the update.

[0115] In operation 1240, the management server (120) according to an embodiment may send an update specification. The management server (120) may determine that it is time to proceed with a cluster update if the network element type does not overlap with that of an adjacent cluster. If the network element type does not overlap with that of an adjacent cluster, the management server (120) may send an update specification including a command to update the cluster. The management server (120) may determine the network element type in real time and control the update timing of the corresponding cluster.

[0116] When the update of a central unit type cluster is completed, the management server (120) can simultaneously update a distribution unit type cluster connected to the central unit type cluster for which the update has been completed. Accordingly, the management server (120) can reduce the time required to update multiple clusters.

[0117] The present disclosure seeks to provide a management server and a control method thereof that control the update timing of at least one cluster based on resource information.

[0118] A management server (120) according to one embodiment may include a monitoring module (210) and a scheduling module (220). The monitoring module (210) according to one embodiment may receive resource information from at least one cluster (130, 140, 150). The scheduling module (220) according to one embodiment may receive an update request for at least one cluster (130, 140, 150). The scheduling module (220) according to one embodiment may determine an update time for at least one cluster (130, 140, 150) based on status information and network performance information included in the resource information and the service range of an adjacent cluster. The scheduling module (220) according to one embodiment may transmit an update specification to update the network function of at least one cluster (130, 140, 150) at the determined update time.

[0119] At least one cluster (130, 140, 150) according to one embodiment may be configured with a Cloud-Native Network Function (CNF).

[0120] A scheduling module (220) according to one embodiment may receive an update rule associated with an update request. The update rule according to one embodiment may include at least one of an update completion deadline of at least one cluster (130, 140, 150), a hardware parameter of at least one cluster (130, 140, 150), a software parameter of at least one cluster (130, 140, 150), and an update region of at least one cluster (130, 140, 150).

[0121] A management server (120) according to one embodiment may include a storage module (320) that stores status information and service scope.

[0122] According to one embodiment, the scheduling module (220) may set the first update period of at least one cluster (130, 140, 150) and the second update period of the adjacent cluster to not overlap when the first service range of at least one cluster (130, 140, 150) and the second service range of the adjacent cluster overlap at least partially.

[0123] A scheduling module (220) according to one embodiment may determine an update time based on a network element (NE) type of at least one cluster (130, 140, 150).

[0124] The scheduling module (220) according to one embodiment may determine the update time based on at least one of whether the adjacent cluster is updated and the version of the adjacent cluster.

[0125] A scheduling module (220) according to one embodiment can identify whether the number of user equipment (UE) connected to at least one cluster (130, 140, 150) and the number of active calls of at least one cluster (130, 140, 150) are below a threshold value. A scheduling module (220) according to one embodiment can determine an update time based on the identification result.

[0126] A scheduling module (220) according to one embodiment may receive an update status transmitted from at least one cluster (130, 140, 150) in response to an update specification.

[0127] A scheduling module (220) according to one embodiment can provide an update result based on an update status.

[0128] A control method of a management server according to one embodiment may include an operation of receiving resource information from at least one cluster. A control method of a management server according to one embodiment may include an operation of receiving an update request for at least one cluster. A control method of a management server according to one embodiment may include an operation of determining an update time of at least one cluster based on status information and network performance information included in the resource information and a service range of an adjacent cluster. A control method of a management server according to one embodiment may include an operation of transmitting an update specification to update a network function of at least one cluster at the determined update time.

[0129] At least one cluster according to one embodiment may be configured with a Cloud-Native Network Function (CNF).

[0130] A control method of a management server according to one embodiment may include receiving an update rule associated with an update request. The update rule according to one embodiment may include at least one of an update completion deadline for at least one cluster, hardware parameters for at least one cluster, software parameters for at least one cluster, and an update region for at least one cluster.

[0131] A method of controlling a management server according to one embodiment may include an operation of storing state information and a service scope.

[0132] A control method of a management server according to one embodiment may include an operation of setting a first update period of at least one cluster and a second update period of an adjacent cluster to not overlap when a first service range of at least one cluster and a second service range of an adjacent cluster overlap at least partially.

[0133] The operation of determining an update point according to one embodiment may include an operation of determining an update point based on a network element (NE) type of at least one cluster.

[0134] The operation of determining the update point according to one embodiment may include an operation of determining the update point based on at least one of whether an adjacent cluster has been updated and a version of the adjacent cluster.

[0135] The operation of determining an update time according to one embodiment may include an operation of identifying whether the number of user equipment (UEs) connected to at least one cluster and the number of active calls in at least one cluster are below a threshold value. The operation of determining an update time according to one embodiment may include an operation of determining an update time based on the identification result.

[0136] A control method of a management server according to one embodiment may include receiving an update status transmitted from at least one cluster in response to an update specification.

[0137] A control method of a management server according to one embodiment may include an operation of providing an update result based on an update status.

[0138] The management server and its control method according to the present disclosure can reduce network loss occurring during update by determining the update time of at least one cluster based on resource information.

[0139] A method according to an embodiment of the present disclosure may be implemented in the form of program commands that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program commands, data files, data structures, etc., alone or in combination. The program commands recorded on the medium may be those specially designed and configured for the present disclosure or may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program commands, such as ROMs, RAMs, and flash memories. Examples of program commands include not only machine language codes generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0140] Some embodiments of the present disclosure may also be implemented in the form of a recording medium containing computer-executable instructions, such as program modules, executed by a computer. Computer-readable media may be any available media that can be accessed by a computer, and include both volatile and nonvolatile media, removable and non-removable media. Furthermore, computer-readable media may include both computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Communication media typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism, and includes any information delivery media. Furthermore, some embodiments of the present disclosure may also be implemented as a computer program or computer program product containing computer-executable instructions, such as a computer program that is executed by a computer.

[0141] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory storage medium" simply means a tangible device that does not contain signals (e.g., electromagnetic waves). This term does not distinguish between cases where data is permanently stored in the storage medium and cases where data is temporarily stored. For example, a "non-transitory storage medium" may include a buffer in which data is temporarily stored.

[0142] According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable app) may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

Claims

1. In the management server (120), Monitoring module (210); and Includes a scheduling module (220), The above monitoring module (210) Receive resource information from at least one cluster (130, 140, 150), The above scheduling module (220) Receive an update request for at least one cluster (130, 140, 150), Determine the update time of at least one cluster (130, 140, 150) based on the status information and network performance information included in the above resource information and the service range of the adjacent cluster, A management server (120) that transmits an update specification to update the network function of at least one cluster (130, 140, 150) at the determined update time.

2. In paragraph 1, The above at least one cluster (130, 140, 150) comprises a management server (120) configured with a cloud-native network function (CNF).

3. In one of the clauses 1 and 2, The above scheduling module (220) Receive update rules related to the above update request, The above update rules are: A management server (120) comprising at least one of an update completion deadline of at least one cluster (130, 140, 150), a hardware parameter of at least one cluster (130, 140, 150), a software parameter of at least one cluster (130, 140, 150), and an update region of at least one cluster (130, 140, 150).

4. In at least one of clauses 1 to 3, A management server (120) further comprising a storage module (320) for storing the above status information and the above service scope.

5. In at least one of clauses 1 to 4, The above scheduling module (220) A management server (120) that sets the first update period of the at least one cluster (130, 140, 150) and the second update period of the adjacent cluster to not overlap when the first service range of the at least one cluster (130, 140, 150) and the second service range of the adjacent cluster overlap at least partially.

6. In at least one of clauses 1 to 5, The above scheduling module (220) A management server (120) that determines the update time based on the network element (NE) type of at least one cluster (130, 140, 150).

7. In at least one of clauses 1 to 6, The above scheduling module (220) A management server (120) that determines the update time based on at least one of whether the adjacent cluster is updated and the version of the adjacent cluster.

8. In at least one of clauses 1 to 7, The above scheduling module (220) Identifying whether the number of user equipment (UE) connected to at least one cluster (130, 140, 150) and the number of active calls of the at least one cluster (130, 140, 150) are less than or equal to a threshold value, A management server (120) that determines the update time based on the above identification results.

9. In at least one of clauses 1 to 8, The above scheduling module (220) A management server (120) that receives an update status transmitted from at least one cluster (130, 140, 150) in response to the above update specification.

10. In paragraph 9, The above scheduling module (220) A management server (120) that provides update results based on the above update status.

11. In the method of controlling the management server, An act of receiving resource information from at least one cluster; An action of receiving an update request for at least one cluster; An operation for determining an update time of at least one cluster based on status information and network performance information included in the resource information and the service range of the adjacent cluster; and A control method of a management server, comprising an action of transmitting an update specification to update the network function of at least one cluster at the determined update time.

12. In paragraph 11, A method for controlling a management server, wherein at least one of the above clusters is configured with a cloud-native network function (CNF).

13. In one of the clauses 11 and 12, Further comprising an action of receiving an update rule related to said update request, The above update rules are: A control method of a management server, comprising at least one of an update completion deadline of at least one cluster, a hardware parameter of at least one cluster, a software parameter of at least one cluster, and an update region of at least one cluster.

14. In at least one of clauses 11 to 13, A control method of a management server, further comprising an operation of storing the above status information and the above service scope.

15. In at least one of clauses 11 to 14, A control method of a management server, further comprising an operation of setting a first update period of the at least one cluster and a second update period of the adjacent cluster to not overlap when a first service range of the at least one cluster and a second service range of the adjacent cluster overlap at least partially.

Images