Method for managing base station in wireless communication system

Abstract

A method performed by an electronic device is provided. The method may comprise the steps of: receiving, from a base station operator, a request for upgrading a cloud-native network function (CNF) including a workflow runner resource; generating a task resource on the basis of a workflow resource included in the workflow runner resource; and performing, on the basis of the task resource, an action corresponding to a task.

Description

How to manage base stations in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more specifically, to a method, apparatus, and system for managing a base station in a wireless communication system.

[0002] A Cloud-native Network Function (CNF) refers to a container-based network function that operates in a cloud-native environment. Compared to a Virtualized Network Function (VNF), it leverages container technology to be lighter, more flexible, and capable of being deployed and managed more quickly.

[0003] Base stations can be software-enabled via CNF and run in the cloud. The core components of a base station, the Centralized Unit (CU) and the Distributed Unit (DU), can be deployed via CNF, and CNF can execute the software functions of the CU and DU in the cloud. CNF-based base stations can support automated deployment, scaling, and disaster recovery through orchestration platforms such as Kubernetes.

[0004] According to one aspect of the present disclosure, a method performed by a controller in a wireless communication system may be provided. The method may include the step of receiving a cloud-native network function (CNF) upgrade request from a base station operator that includes a workflow runner resource. The method may include the step of creating a task resource based on a workflow resource included in the workflow runner resource. The method may include the step of performing an action corresponding to a task based on the task resource.

[0005] According to one aspect of the present disclosure, a controller may be provided in a wireless communication system. The controller may include a transceiver; and at least one processor coupled to the transceiver. At least one processor may receive a cloud-native network function (CNF) upgrade request from a base station operator that includes a workflow runner resource. At least one processor may create a task resource based on a workflow resource included in the workflow runner resource. At least one processor may perform an action corresponding to the task based on the task resource.

[0006] FIG. 1 is a drawing for explaining a method of implementing a network function according to one embodiment of the present disclosure.

[0007] FIG. 2 is a diagram illustrating an example of a change in a Cloud-native Network Function (CNF) according to one embodiment of the present disclosure.

[0008] FIG. 3 is a drawing for illustrating an example of a CNF internal application according to one embodiment of the present disclosure.

[0009] FIG. 4 is a drawing for explaining an example in which the application structure inside the CNF is changed according to a package version according to one embodiment of the present disclosure.

[0010] FIG. 5 is a drawing for explaining a Custom Resource Definition (CRD) according to one embodiment of the present disclosure.

[0011] FIG. 6 is a drawing for explaining the process of creating a resource according to one embodiment of the present disclosure.

[0012] FIG. 7 is a drawing for explaining the concept and operation of a controller according to one embodiment of the present disclosure.

[0013] FIG. 8 is a block diagram illustrating the basic configuration of a controller according to one embodiment of the present disclosure.

[0014] FIGS. 9a and 9b are drawings for explaining the operation of a controller for managing a base station according to one embodiment of the present disclosure.

[0015] FIG. 10 is a drawing for illustrating an example of a flowchart for distributing an initial CNF according to one embodiment of the present disclosure.

[0016] FIG. 11 is a diagram illustrating an example of a flowchart for temporarily terminating resources during an upgrade according to one embodiment of the present disclosure.

[0017] FIG. 12 is a diagram illustrating an example of a flowchart for waiting for an update until an emergency call is terminated according to one embodiment of the present disclosure.

[0018] FIG. 13 is a diagram illustrating an example of a flowchart for deleting and reinstalling an entire application according to an error situation according to one embodiment of the present disclosure.

[0019] FIG. 14 is a drawing for explaining an example of an operator's operating method according to one embodiment of the present disclosure.

[0020] FIG. 15 is a flowchart illustrating an operation for managing a base station according to one embodiment of the present disclosure.

[0021] FIG. 16 is a block diagram illustrating the configuration of an electronic device according to one embodiment of the present disclosure.

[0022] The operating principles of the present disclosure will be described in detail below with reference to the attached drawings. In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Furthermore, the terms described below are defined in consideration of their functions in the present disclosure, and these may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0023] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. The embodiments provided are merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0024] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0025] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0026] In this embodiment, the term "part" refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Thus, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and 'parts' may be implemented to utilize one or more CPUs within the device or secure multimedia card. Also, in the embodiments, 'parts' may include one or more processors.

[0027] In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Embodiments of the present disclosure will be described below with reference to the attached drawings.

[0028] The terms used in this invention have been selected based on currently widely used general terms, taking into account their functions within the invention; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the relevant description of the invention. Therefore, the terms used in this invention should be defined not merely by their names, but based on their meanings and the overall content of the invention.

[0029] When a part of a specification is described as "including" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. Furthermore, terms such as "...part" or "module" as used in the specification refer to a unit that processes at least one function or operation, and this may be implemented in hardware or software, or as a combination of hardware and software.

[0030] Additionally, the description 'at least one of A, B, and C' means that it may be any one of 'A', 'B', 'C', 'A and B', 'A and C', 'B and C', and 'A, B, and C'.

[0031] It should be understood that the combinations of blocks and flowcharts in each flowchart can be executed by one or more computer programs containing computer-executable instructions. One or more computer programs may be stored entirely in a single memory or may be partitioned and stored in multiple different memories.

[0032] All functions or operations described in this document may be processed by a single processor or a combination of processors. A single processor or a combination of processors is a circuitry that performs processing and may include circuitry such as an AP (Application Processor), CP (Communication Processor), GPU (Graphical Processing Unit), NPU (Neural Processing Unit), MPU (Microprocessor Unit), SoC (System on Chip), IC (Integrated Chip), etc.

[0033] A processor may include various processing circuits and / or multiple processors. For example, the term "processor" as used herein, including in the claims, may include at least one processor and various processing circuits. In at least one processor, one or more processors may be configured to perform the various functions described herein in a distributed manner, individually and / or collectively. As used herein, "processor," "at least one processor," and "one or more processors" may be configured to perform various functions. However, these terms cover, without limitation, situations where one processor performs some of the functions and other processor(s) perform other parts of the functions, and situations where a single processor can perform all functions. Additionally, at least one processor may include a combination of processors performing various functions of the disclosed functions in a distributed manner. At least one processor may execute program instructions to achieve or perform various functions.

[0034] The following describes embodiments with reference to the attached drawings so that those skilled in the art can easily implement the present invention. However, the present invention may be embodied in various different forms and is not limited to the embodiments described herein. Furthermore, in order to clearly explain the present invention in the drawings, parts unrelated to the explanation have been omitted, and similar parts throughout the specification are denoted by similar reference numerals.

[0035] The present disclosure will be described below with reference to the attached drawings.

[0036] FIG. 1 is a drawing for explaining a method of implementing a network function according to one embodiment of the present disclosure.

[0037] Referring to Fig. 1, the development stages of a method for implementing a network function are described.

[0038] According to one embodiment of the present disclosure, a Physical Network Function (PNF) (110) may mean a network function executed on dedicated physical hardware equipment. The PNF (110) may be executed on dedicated hardware optimized to perform a specific function, and the hardware equipment may include, for example, a network switch, a router, a firewall, wireless base station equipment, etc.

[0039] However, PNF (110) has the disadvantage that it requires the addition of physical equipment when demand increases, which limits scalability, makes maintenance and upgrades difficult, requires hardware replacement to introduce new features, and lacks flexibility as configuration changes and updates are slow and limited.

[0040] According to one embodiment of the present disclosure, a Virtualized Network Function (VNF) (120) may refer to a technology that virtualizes network functions to be executed in the form of a virtual machine. The VNF (120) can reduce hardware dependency and provide network functions as software running on a general server.

[0041] VNF (120) can abstract hardware to run network functions on general-purpose hardware such as general x86 servers, dynamically adjust resources by increasing or decreasing the number of virtual machines as needed, does not require dedicated hardware, can utilize existing data center resources, and can use orchestration tools (e.g., NFV MANO, etc.) that can automate VNF management and deployment. For example, VNF (120) may include a virtual router (vRouter), a virtual firewall (vFirewall), a virtual packet core (vEPC), etc.

[0042] However, although VNF (120) is more flexible than existing hardware-based, it may have performance overhead because it runs on a VM (Virtual Machine) basis and scalability in a cloud-native environment may be limited.

[0043] According to one embodiment of the present disclosure, a Cloud-Native Network Function (CNF) (130) may mean a network function designed with a cloud-native architecture and executed on a container basis. The CNF (130) may be designed to operate on a container orchestration platform such as Kubernetes.

[0044] CNF (130) enables network functions to run as lightweight containers, providing scalability and portability through organic connections between containers, and can use a microservices architecture to subdivide functions and deploy, scale, and manage them independently, and can increase the flexibility, resilience, automation, and scalability of the network by utilizing features such as autoscaling, self-healing, and rolling updates of Kubernetes.

[0045] CNF (130) is executed on a container basis, making it lighter than a VM, and can be executed with minimal resources, and can be optimized for public, private, and hybrid cloud environments. For example, CNF (130) may include a 5G core network (CU (Centralized Unit) / DU (Distributed Unit), UPF (User Plane Function), AMF (Access and Mobility Management Function), etc.), a cloud-based firewall, a cloud-native router, etc.

[0046] According to one embodiment of the present disclosure, when a Network Function is deployed to a CNF, an application may be deployed and serviced on a public cloud (e.g., AWS, GCP, etc.). Additionally, the Network Function may be serviced in an on-premise format.

[0047] Network technology has evolved in the order of PNF (110), VNF (120), and CNF (130). In this disclosure, a technology for managing a base station by implementing the network functions of the base station as a CNF is described.

[0048] In particular, the present disclosure aims to provide technical benefits such as reduced base station management costs and time by enabling the efficient coordination of the sequence of base station installation, upgrades, and rollbacks in order to manage base stations of various types and environments in a unified manner. However, the present disclosure is not limited to base station applications and the invention may also be applied to general commercial applications.

[0049] FIG. 2 is a diagram illustrating an example of a change in a Cloud-native Network Function (CNF) according to one embodiment of the present disclosure.

[0050] Referring to Fig. 2, an example is described in which the scope of the CNF is expanded, the functions of the CNF are added, and the configuration of the CNF is changed.

[0051] According to one embodiment of the present disclosure, CNF can virtualize and containerize various functions of a base station by converting hardware-centric tasks performed by the base station into container-based software. Distributed Unit (DU) and Centralized Unit (CU) functions, which were previously provided only by hardware, can be converted into CNF.

[0052] According to one embodiment of the present disclosure, a base station may include logical components such as a Centralized Unit-Control Plane (CU-CP), a Centralized Unit-User Plane (CU-UP), and a Distributed Unit (DU). The functions performed by each logical component may be composed of various types of CNFs.

[0053] According to one embodiment of the present disclosure, there may be various types of CNFs for operating a base station in a cloud environment. For example, a CNF may include a first CNF, a second CNF, a third CNF, a fourth CNF, a fifth CNF, a sixth CNF, and the like.

[0054] According to one embodiment of the present disclosure, the first CNF can perform the function of a CU-CP (centralized unit-control plane) as a function related to access in the control plane. The second CNF can perform the function of a CU-UP (centralized unit-user plane) as a function related to access in the user plane. The third CNF can perform the function of processing access in a DU (distributed unit). The fourth CNF can perform base station control functions. The fifth CNF can perform the function of controlling High Availability. The sixth CNF can perform the function of a RIC (radio access network intelligent controller). However, it is not limited thereto.

[0055] According to one embodiment of the present disclosure, the types of CNF may be expanded according to changes in the requirements, standards, and functions of the base station operator (or operator). The scope of CNF may be expanded according to changes in the requirements, standards, and functions of the base station operator (or operator).

[0056] According to one embodiment of the present disclosure, functions of the CNF may be added and the structure (or configuration) of the CNF may be changed according to changes in the requirements, standards, and functions of the base station operator (or operator). For example, when the first CNF is upgraded from the first version to the second version, the Redis structure may be changed, and when the second version is upgraded to the third version, a namingRulePolicy may be added.

[0057] FIG. 3 is a drawing for illustrating an example of a CNF internal application according to one embodiment of the present disclosure.

[0058] Referring to Fig. 3, examples of application configurations within a CNF are explained according to the type of CNF.

[0059] According to one embodiment of the present disclosure, a single CNF may be composed of a combination of multiple applications. A CNF may implement a specific network function by combining multiple applications that perform various functions. The applications may perform their respective functions independently and communicate with each other to operate as a single network function. An orchestration tool such as Kubernetes can deploy and manage each application in the form of a container to enable seamless cooperation.

[0060] According to one embodiment of the present disclosure, the combination of applications included in each CNF may differ depending on the type of CNF. For example, the first CNF may include a combination of the first application, the second application, the third application, the fourth application, the fifth application, the sixth application, and the seventh application. Additionally, the fifth CNF may include a combination of the first application and the second application.

[0061] According to one embodiment of the present disclosure, there may be a common pod, which is a common application included in most CNFs. Additionally, there may be a specific pod, which is a specific application including main functions to be managed in each CNF. For example, the common pod may include a first application, a second application, and a third application. Additionally, the specific pod may include a fourth application, a fifth application, a sixth application, a seventh application, and an eighth application.

[0062] For example, the first application may be an application for managing a database. The second application may be an application for managing CNF resources. The third application may be an application for managing performance. The fourth application may be an application for processing a specific X. The fifth application may be an application for managing the interface of a specific X. The sixth application may be an application for managing the SCTP (Stream Control Transmission Protocol) of a specific X. The seventh application may be an application for tracking a specific X. The eighth application may be an application for managing a RU (Radio Unit). Here, the applications may be referred to as Pods.

[0063] According to one embodiment of the present disclosure, each application may be composed of a combination of multiple Kubernetes resources. A Kubernetes resource may refer to an object that defines and manages applications and services within a cluster. Kubernetes resources may be used to deploy applications to a Kubernetes cluster and to implement and operate various functions of the applications.

[0064] According to one embodiment of the present disclosure, Kubernetes resources may include pods, deployments, services, ConfigMap, Secrets, Persistent Volumes (PVs), Persistent Volume Claims (PVCs), Ingress, Horizontal Pod Auto-scalers (HPAs), etc.

[0065] A pod can refer to the most basic unit of an application. A pod is a unit that groups one or more containers and can be the smallest execution unit of an application.

[0066] A deployment is an object that provides the basic method for deploying and operating applications on Kubernetes, allowing you to manage the lifecycle of Pods by specifying which container images to use, how many Pods to run, and more.

[0067] A service is an object that provides network access to specific Pods. When the IP address of a Pod changes, a service can be used to provide a fixed access path to a specific application and distribute traffic through load balancing.

[0068] A ConfigMap is a resource that stores environment settings to be used by an application. For example, you can store configuration files, such as database connection settings or environment variables, in a ConfigMap and allow Pods to refer to these settings.

[0069] A Secret is a resource that stores sensitive information such as passwords and API (application programming interface) keys, and like a ConfigMap, it can be referenced by a Pod to securely manage sensitive information.

[0070] PVs and PVCs can refer to resources that provide persistent storage when data needs to be retained even if the Pod is terminated.

[0071] Ingress can serve the role of routing external traffic to services within the cluster. By configuring domain-based routing rules, Ingress can forward traffic to different services based on various domains or URL (Uniform Resource Locator) paths.

[0072] HPA can refer to a resource that automatically adjusts the number of Pods when the load on an application increases or decreases.

[0073] With CNF, the combination of applications and the internal structure of applications (i.e., the combination of Kubernetes resources) can change as the version changes.

[0074] FIG. 4 is a drawing for explaining an example in which the application structure inside the CNF is changed according to a package version according to one embodiment of the present disclosure.

[0075] Referring to Fig. 4, an example of how the application structure inside CNF changes for each package version is explained.

[0076] According to one embodiment of the present disclosure, in the case of a first CNF package, when the first package is upgraded to a second package, the second application and the fourth application may be changed to an Active / Standby structure. Additionally, when the second package is upgraded to a third package, the sixth application may be changed to operate in an All Active form while being internalized. According to one embodiment of the present disclosure, in the case of a second CNF package, when the third package is upgraded to a fourth package, a ninth application may be added.

[0077] According to one embodiment of the present disclosure, Active may mean a structure in which a node operates in an active state, and Standby may mean a structure in which a node maintains a ready state as a standby state.

[0078] According to one embodiment of the present disclosure, Active / Standby may refer to a redundancy structure in which one node operates as Active and the remaining nodes maintain a ready state as Standby. In the event of a failure, the Standby node can switch to an Active state to continue providing services. Only one node is active at a time to process services, and while the Standby node does not process service requests, it can always monitor and synchronize with the status of the Active node.

[0079] According to one embodiment of the present disclosure, "All active" may mean a structure in which all nodes operate in an active state simultaneously and process requests. In "All active," all nodes process service requests simultaneously, and if a failure occurs, the remaining active nodes handle the load, thereby minimizing service interruption.

[0080] Depending on the hardware specifications, configuration, and platform of the servers used by each base station operator (or manager), base station configurations can be operated in various forms.

[0081] When upgrading base stations, it is crucial to have technology that maintains service during the upgrade process. When upgrading base station applications, the duration of service interruption can vary depending on the order in which the applications are upgraded. For example, in the case of the first application for database management, it is used commonly across all CNFs. Since compatibility issues arise if the versions of the first application differ from those of the remaining applications, upgrading the first application first followed by the others can minimize service interruption.

[0082] However, in the current structure, since all applications are upgraded simultaneously, even if some services are interrupted, they must wait until the upgrade of the primary application is complete, resulting in prolonged service interruption times.

[0083] In the case of base stations, issues arising from service interruptions are more critical than those associated with general cloud services, and emergency calls, in particular, can even have legal implications. However, the existing base station upgrade process fails to provide methods optimized for each operating environment; instead, it is carried out through administrators manually monitoring the current status and making requests. This is a complex and inefficient process that can result in significant management time and costs.

[0084] The present disclosure relates to a flowchart-based installation and upgrade control method tailored to individual base station environments. By using the disclosed method, customized installations can be performed according to the specific conditions of each base station, thereby reducing unnecessary resource waste and increasing efficiency. Furthermore, the adoption of the disclosed method enables more stable and effective base station management.

[0085] FIG. 5 is a drawing for explaining a Custom Resource Definition (CRD) (510) according to one embodiment of the present disclosure.

[0086] Referring to FIG. 5, a CRD (510) for a user to define a Kubernetes resource and a custom controller (520) for managing it are described.

[0087] In one embodiment, Kubernetes may refer to an open source platform that automates the deployment, management, scaling, and recovery of containerized applications. Kubernetes can automatically deploy, manage, and coordinate multiple containers, and can perform the function of container orchestration, which configures network connectivity and storage between containers.

[0088] According to one embodiment of the present disclosure, a Kubernetes controller may refer to a component that monitors etcd and operates to maintain a desired state in accordance with a declared application programming interface (api). The Kubernetes controller may observe the current state of a resource within the cluster (530), compare it with the desired state, and perform necessary operations. For example, if an object corresponding to a pod is created and information regarding this request is stored in etcd, the controller responsible for the pod may detect the change and perform the role of creating a container that performs the actual operation. The Kubernetes controller may be a controller provided by default in Kubernetes.

[0089] According to one embodiment of the present disclosure, etcd is a storage for storing information within a cluster (530) and can perform the role of a backend database for Kubernetes. etcd can store all cluster (530) status and configuration information and can provide important data for managing the operation of the cluster (530).

[0090] According to one embodiment of the present disclosure, a custom controller (520) may refer to a controller developed by a user and deployed to a cluster to manage specific business requirements or customized resources, in addition to the controllers provided by default. The custom controller (520) may be referred to as an operator (520), a controller, a v-RAN CNF In-service Upgrade Controller, etc. The custom controller (520) can create, update, delete, and manage new resources defined by a Custom Resource Definition (CRD) (510).

[0091] According to one embodiment of the present disclosure, a Custom Resource Definition (CRD) (510) may refer to an extension that enables the definition and management of custom resources in Kubernetes. In addition to standard resources provided by default in Kubernetes, such as Pods, Services, and Deployments, new resource types can be used in a cluster (530) by using the CRD (510) when it is necessary to define resources that meet specific requirements.

[0092] According to one embodiment of the present disclosure, the CRD (510) provides the ability to freely extend and use the API without modifying the source code, and can define and implement user-defined resources by directly defining the resources desired by the user as CRDs and defining the operation of the resources as operators (520).

[0093] According to one embodiment of the present disclosure, a Custom Resource (CR) may refer to an actual instance of a special resource type defined by a user, rather than a Kubernetes built-in resource (e.g., Pod, Service, Deployment, etc.). A CR is created based on a resource type defined by a CRD (510) and can manage specific applications or business requirements in a Kubernetes-native manner. A CR may be dynamically managed and assigned actions by a custom controller (520).

[0094] CRD (510) is class information defined before creating an object, and CR can have a similar meaning to an instance object actually created according to the specifications of CRD (510). An operator (520) can provide the ability to define a new type of resource without changing the Kubernetes source code by implementing these new types of CRs so that they can perform the desired type of operation.

[0095] FIG. 6 is a drawing for explaining the process of creating a resource according to one embodiment of the present disclosure.

[0096] Referring to Figure 6, a method for creating Kubernetes resources using Helm charts and configuration values ​​is explained.

[0097] According to one embodiment of the present disclosure, Helm may refer to a Kubernetes container orchestration tool that enables easy and rapid deployment of containers and automates scaling management. Helm may provide functions for deploying, managing, upgrading, and deleting multiple Kubernetes resources that constitute an application by grouping them into a single chart.

[0098] Typical commercial application services can be configured to use various resources in addition to simple pods, such as deployments, configmaps, secrets, services, persistent volumes, and persistent volume claims. Depending on the deployment environment, it may be necessary to modify certain information regarding these resources, such as port details, storage class details, and access permission information for the corresponding cluster.

[0099] According to one embodiment of the present disclosure, a Helm client is a Command-Line Interface (CLI) of Helm and may be a tool that helps a user perform tasks such as installing, managing, upgrading, and deleting Kubernetes applications through a Helm Chart. The Helm client may provide functions such as packaging, installation, and deletion to facilitate the easy operation of modifying information about resources.

[0100] According to one embodiment of the present disclosure, a Helm chart is a package that defines and configures the deployment of a Kubernetes application, and can simplify deployment and management by grouping Kubernetes resources into a single unit. A Helm chart may be a package consisting of a directory structure that includes the application's configuration files, templates, and default settings.

[0101] According to one embodiment of the present disclosure, a values ​​file may refer to a file that defines configuration values ​​to be used in a Helm chart. Variable values ​​referenced in the template file of a Helm chart are defined in the values ​​file, thereby allowing the configuration of the application to be easily changed according to the deployment environment.

[0102] According to one embodiment of the present disclosure, Helm may consist of a helm chart (Templates) containing specifications for each resource and actual values. A helm client may perform a rendering process that combines the helm chart and values. The Helm client may transmit the rendering results, including final release information for deploying actual resources during an installation or upgrade process, to a Kubernetes API server so that the desired resources can be created.

[0103] According to one embodiment of the present disclosure, a Kubernetes API server serves as a central management component of a Kubernetes cluster and can perform a key role in coordinating all operations and communications within the cluster. The Kubernetes API server is the main entity receiving requests from the cluster and may serve as an interface to the cluster. The Kubernetes API server can create Kubernetes resources, check the status of Kubernetes resources running in the cluster, and manage CRs defined by CRDs.

[0104] The Helm Client can operate in the following ways when a user enters a command.

[0105] Referring to operation S610, a Helm developer can create a chart.

[0106] Referring to operation S620, Helm developers can upload a chart to a Helm repository.

[0107] Referring to operation S630, the developer (or user) can set or enter the values.

[0108] Referring to operation S640, the helm client can download the helm chart that the user wants to install from the helm repository or prepare a chart from the local repository.

[0109] Referring to operation S650, the helm client can render a template of a helm chart based on user-entered values. The helm client can generate release information through rendering.

[0110] Referring to operation S660, the helm client can pass the generated release information (or rendered resources) to the API server of the Kubernetes cluster to create or modify the actual resources (Kubernetes resources). The release information can be stored in a ConfigMap or Secret resource within the Kubernetes cluster.

[0111] The Helm client can deploy applications based on Helm charts and manage the state of applications by interacting with a Kubernetes cluster.

[0112] Since typical cloud applications have stateless services, there are no functions to control the installation order of various released resources, such as managing internal or external dependencies, installation sequence, or verifying whether each resource has been successfully installed.

[0113] In this disclosure, we intend to define a Kubernetes CR / CRD / Operator function that can control the order of applications by utilizing Helm, an application deployment solution in the cloud field, to deploy various applications within a base station that have stateful characteristics, unlike general cloud applications.

[0114] However, since general applications may also have stateful features, the present disclosure is not limited to base station applications and may be applied to general applications as well.

[0115] FIG. 7 is a drawing for explaining the concept and operation of a controller (710) according to one embodiment of the present disclosure.

[0116] Referring to FIG. 7, the concept and operation of a controller (710) that manages a base station by controlling the order of applications will be explained.

[0117] According to one embodiment of the present disclosure, the controller (710) is a core module for managing and controlling newly defined CRDs, and may mean a module that enables resources rendered in Helm to operate in a workflow order by incorporating an existing Helm client. The controller (710) may perform the role of a custom controller or operator. The controller (710) may be represented as a vRAN CNF In-service Upgrade Controller.

[0118] To manage cloud-based base station applications, custom resources such as tasks, workflows, and workflow runners can be defined to perform tasks such as deployment, updates, and upgrades according to the workflow sequence. The controller (710) may be a module for managing and controlling the defined custom resources.

[0119] According to one embodiment of the present disclosure, a Task CRD may refer to a resource that defines actions to be performed in detail for creating an installation or upgrade flowchart. A Task CRD provides various types of tasks, each of which can be added or modified as a plugin.

[0120] According to one embodiment of the present disclosure, the lifecycle of each task, such as start conditions and end conditions which are common functions of the task, is managed by a task controller, and the operations to be performed for each detailed action can be executed in each action implementation unit.

[0121] According to one embodiment of the present disclosure, the start and end conditions of each task may receive parameters such as those in [Table 1] below as input.

[0122] [Table 1]

[0123]

[0124] Each action is configured in the form shown in [Table 2] below and can be provided to extend new types of actions in the form of plugins.

[0125] [Table 2]

[0126]

[0127] According to one embodiment of the present disclosure, a Workflow CRD may represent a resource for defining an actual flowchart and may be composed of a combination of single tasks. For example, the sequence information of a base station may be composed of values ​​in the form of "If condition 1 is satisfied, perform action A with the value of ㄱ", "If condition 1 is satisfied, perform action B with the value of ㄴ", "If condition 2 is satisfied, perform action A with the value of ㄷ".

[0128] According to one embodiment of the present disclosure, a WorkflowRunner CRD may refer to a resource defined for an actual CNF controller to trigger an action. The WorkflowRunner CRD may include repository information for downloading a Helm chart, values ​​information required to render Helm, and workflow information regarding what actual action to perform based on Helm resource information.

[0129] According to one embodiment of the present disclosure, values ​​information may include various configuration values ​​for distributing each base station application. For example, values ​​information may include EMS (Element Management System) IP information for managing the CNF, a management ID (identifier) ​​of the CNF, a flavor type of the CNF, platform information for use of the CNF, NE (Network Element) Type information of the CNF, timezone information of the CNF, image information used for each application of the CNF, the number of replicas for each application of the CNF, port information of a service for each application of the CNF, storage class information of the platform, and PV (persistence volume) information of the platform.

[0130] According to one embodiment of the present disclosure, the controller (710) may receive as input workflow runner resource information including repository information for downloading a helm chart, helm values ​​information, and workflow resource information.

[0131] The controller (710) can generate released Kubernetes resource information by rendering helm chart and values ​​information through a helm client. The controller (710) can generate task resources based on workflow resource information and execute actions corresponding to the tasks according to the workflow.

[0132] The controller (710) can perform the distribution, upgrade, rollback, etc. of the CNF based on the flowchart according to the workflow resources.

[0133] FIG. 8 is a block diagram illustrating the basic configuration of a controller (810) according to one embodiment of the present disclosure.

[0134] Referring to FIG. 8, the basic structure and each component constituting the controller (810) will be described.

[0135] In one embodiment, the controller (810) may be composed of an action implementer (820), an action interface (830), a task controller (840), a workflow runner controller (850), a Common Expression Language (CEL) parsor (860), an external service connector (870), and a Helm client (880). However, it is not limited thereto and may include more components or omit some components.

[0136] According to one embodiment of the present disclosure, the action implementation unit (820) may be a module in which operations to be performed for each detailed action are executed. The action implementation unit (820) may be a module in which an action corresponding to each task is executed. The action implementation unit (820) may execute operations to be performed for each detailed action. For example, the actions may include get, create, update, iterate, etc.

[0137] According to one embodiment of the present disclosure, an action interface (830) is an interface for executing an action and may include specifications or action information for each action. The action interface (830) may include an ActionMap for performing a plurality of actions.

[0138] According to one embodiment of the present disclosure, a task controller (840) may be a module that performs and controls a task. The task controller (840) may perform an action corresponding to the task and call an action implementation based on action information of the task resource. The task controller (840) may check the start and end conditions of the task through a CEL parsor (860). The task controller (840) may manage the lifecycle of the task, such as start / end conditions, which are common functions of the task.

[0139] According to one embodiment of the present disclosure, a WorkflowRunner Controller (850) may represent a module that processes WorkflowRunner resources. The WorkflowRunner Controller (850) receives a CNF upgrade request containing WorkflowRunner resources from a base station operator and can obtain Kubernetes resource information through a Helm Client (880).

[0140] The WorkflowRunner Controller (850) can analyze the workflow resources defined in the workflow runner resources. The WorkflowRunner Controller (850) can create work resources so that the work controller (840) can perform individual action commands. The WorkflowRunner Controller (850) can change the state of the workflow runner resources.

[0141] According to one embodiment of the present disclosure, the CEL parsor (860) may be a module that checks the start or end status of a task. The CEL parsor (860) may check the external service status through an External Service Connector (870).

[0142] According to one embodiment of the present disclosure, CEL may refer to a standard language for expressing various syntaxes as common semantics for expression evaluation. CEL can be utilized in various open sources, including Kubernetes, and defines specifications to enable the description of various types of variables and test expressions in sentences, and can provide libraries for various development languages ​​for practical use.

[0143] According to one embodiment of the present disclosure, the external service connector (870) may be a module that connects to an external service to check the status of the external service.

[0144] According to one embodiment of the present disclosure, the Helm Client (880) may be a module that downloads and renders a helm chart by utilizing helm repository information and value information included in the workflow runner resource. The Helm client (880) may obtain necessary Kubernetes resource information by utilizing the result of the rendering.

[0145] FIGS. 9a and 9b are drawings for explaining the operation of a controller for managing a base station according to one embodiment of the present disclosure.

[0146] Referring to FIGS. 9a and 9b, the operation of a controller (710) for managing a base station based on a flowchart utilizing defined custom resources is described as follows.

[0147] Referring to operation S910, the controller (710) may receive a cloud-native network function (CNF) upgrade request containing a workflow runner resource from the base station operator (905). The workflow runner controller (850) may receive a cloud-native network function (CNF) upgrade request containing a workflow runner resource from the base station operator (905).

[0148] According to one embodiment of the present disclosure, a base station operator (905) may transmit a CNF upgrade request including WorkflowRunner resources to a controller (710) via base station management software. The base station operator (905) may transmit a CNF upgrade request including WorkflowRunner resources to a WorkflowRunner controller (850) via base station management software.

[0149] According to one embodiment of the present disclosure, a base station operator (905) may be represented as a base station manager (905), a base station operator (905), a base station operating system (905), a base station management system (905), etc. A base station operator (905) may refer to an individual or organization responsible for the installation, operation, maintenance, and performance management of a base station in a wireless communication network. A base station operating system (905) may refer to a set of software and tools that support the installation, management, maintenance, and optimization of a base station in a wireless communication network.

[0150] According to one embodiment of the present disclosure, a CNF upgrade request may be a request to upgrade (or update) the network functions of a cloud-based base station. A CNF upgrade request may be a signal requesting an upgrade (or update) of network functions in response to changes in requirements, standards, functions, etc. of a base station operator (905). A CNF upgrade request may include a WorkflowRunner resource.

[0151] According to one embodiment of the present disclosure, a WorkflowRunner resource may include a workflow resource, repository information, value information, etc. A workflow resource may be defined in a WorkflowRunner resource.

[0152] Referring to operation S920, the controller (710) can obtain chart information by using repository information included in the workflow runner resource. The controller (710) can perform rendering that combines the chart information and the setting value information included in the workflow runner resource. The controller (710) can generate resource information using the result of the rendering.

[0153] According to one embodiment of the present disclosure, the controller (710) can generate necessary Kubernetes resource information by downloading and rendering a helm chart using the helm repository information and values ​​information included in the WorkflowRunner resource through the helm client (880) module.

[0154] According to one embodiment of the present disclosure, a workflow runner controller (850) can obtain repository information included in a workflow runner resource. The workflow runner controller (850) can download and obtain chart information (i.e., helm chart) using the repository information. The workflow runner controller (850) can obtain setting value information (i.e., values ​​information) included in a workflow runner resource.

[0155] According to one embodiment of the present disclosure, a workflow runner controller (850) can send a rendering request (or Helm rendering request) to a Helm client (880) that includes chart information (i.e., helm chart) and setting value information (i.e., values ​​information).

[0156] According to one embodiment of the present disclosure, a Helm client (880) may perform a rendering that combines chart information and configuration value information included in the rendering request upon receiving a rendering request. The Helm client (880) may generate resource information (or Kubernetes resource information) through the rendering. The Helm client (880) may transmit the result of the rendering to a Kubernetes API server (970) so that resource information can be generated. Here, Kubernetes may be represented as k8s.

[0157] According to one embodiment of the present disclosure, a Helm client (880) may send resource information to a workflow runner controller (850) in response to a rendering request. The resource information may be expressed as k8s resource information, a k8s resource list, Kubernetes resource information, etc.

[0158] According to one embodiment of the present disclosure, a workflow runner controller (850) can receive resource information from a Helm client (880). The workflow runner controller (850) can obtain resource information.

[0159] Referring to operation S930, the controller (710) can analyze the workflow resources included in the workflow runner resources to determine whether receiving information from an external service is necessary.

[0160] According to one embodiment of the present disclosure, a controller (710) can analyze workflow resources defined in workflow runner resources. The controller (710) can analyze tasks included in workflow resources. The controller (710) can analyze tasks defined in workflow resources. The controller (710) can analyze start / end conditions and actions included in tasks. The controller (710) can analyze start / end conditions and actions for performing tasks.

[0161] According to one embodiment of the present disclosure, a workflow runner controller (850) can analyze workflow resources defined in workflow runner resources. The workflow runner controller (850) can analyze tasks included in workflow resources. The workflow runner controller (850) can analyze tasks defined in workflow resources. The workflow runner controller (850) can analyze start / end conditions and actions included in tasks. The workflow runner controller (850) can analyze start / end conditions and actions for performing tasks.

[0162] According to one embodiment of the present disclosure, the controller (710) may determine whether receiving information from an external service is necessary to perform a task. The controller (710) may determine whether receiving information from an external service is necessary to determine start / end conditions. The controller (710) may determine whether receiving information from an external service is necessary to perform an action.

[0163] According to one embodiment of the present disclosure, a workflow runner controller (850) may determine whether receiving information from an external service is necessary to perform a task. The workflow runner controller (850) may determine whether receiving information from an external service is necessary to determine start / end conditions. The workflow runner controller (850) may determine whether receiving information from an external service is necessary to perform an action.

[0164] According to one embodiment of the present disclosure, the controller (710) may enable a monitoring function of an external service when it is necessary to receive information from an external service. The controller (710) may enable a monitoring function of an external service when it is necessary to receive information from an external service by analyzing at least one of a workflow resource, a task, a start / end condition, and an action.

[0165] According to one embodiment of the present disclosure, the workflow runner controller (850) may enable a monitoring function of an external service when it is necessary to receive information from an external service. The workflow runner controller (850) may enable a monitoring function of an external service when it is necessary to receive information from an external service by analyzing at least one of a workflow resource, a task, a start / end condition, and an action.

[0166] According to one embodiment of the present disclosure, a WorkflowRunner Controller (850) can analyze a Workflow resource defined in a WorkflowRunner resource and, if it is necessary to receive information from an external service, enable a monitoring function of the external service through an External Service Connector (870).

[0167] According to one embodiment of the present disclosure, a WorkflowRunner Controller (850) can communicate with an External Service Connector (870) to create a service monitor.

[0168] According to one embodiment of the present disclosure, an external service connector (870) can communicate with an external service (960) to enable a monitoring function of the external service. The external service connector (870) can communicate with the external service (960) to receive information from the external service. The external service connector (870) can communicate with the external service (960) to create a service monitor.

[0169] According to one embodiment of the present disclosure, an external service connector (870) may transmit a service status check request to an external service (960). The external service (960) may return a service status to the external service connector (870). The external service (960) may transmit a service status to the external service connector (870).

[0170] According to one embodiment of the present disclosure, a plurality of service monitors may be created and may periodically access external services to collect necessary information until all related tasks are completed.

[0171] Referring to operation S940, the controller (710) can create a task resource based on a workflow resource included in a workflow runner resource. The workflow runner controller (850) can create a task resource based on a workflow resource included in a workflow runner resource.

[0172] According to one embodiment of the present disclosure, a WorkflowRunner Controller (850) can analyze a Workflow resource defined in a WorkflowRunner resource and create a plurality of task resources so that a task controller (840) can perform individual action commands.

[0173] According to one embodiment of the present disclosure, a workflow runner controller (850) can transmit a generated task resource to a task controller (840). The task controller (840) can perform an action based on the task resource received from the workflow runner controller (850).

[0174] Referring to operation S941, the controller (710) can determine whether the start condition of the task is satisfied. The task controller (840) can determine whether the start condition of the task is satisfied.

[0175] According to one embodiment of the present disclosure, the controller (710) can determine whether the start condition of a task is satisfied through the CEL parsor (860). The task controller (840) can determine whether the start condition of a task is satisfied through the CEL parsor (860).

[0176] According to one embodiment of the present disclosure, the controller (710) can check the start status of a task through the CEL parsor (860). According to one embodiment of the present disclosure, the task controller (840) can check the start status of a task through the CEL parsor (860).

[0177] According to one embodiment of the present disclosure, a controller (710) can independently check the task start status for a plurality of tasks through a CEL parsor (860). According to one embodiment of the present disclosure, a task controller (840) can independently check the task start status for a plurality of tasks through a CEL parsor (860).

[0178] According to one embodiment of the present disclosure, a task controller (840) may transmit a request for a task start condition result to a CEL parsor (860). The CEL parsor (860) may determine whether the task start condition is satisfied. The CEL parsor (860) may check the task start status.

[0179] According to one embodiment of the present disclosure, a task start condition (or, start state) may be performed by determining the completion state of another task. A CEL parsor (860) may determine whether the task start condition is satisfied by determining the completion state of another task. A CEL parsor (860) may check the task start state by determining the completion state of another task.

[0180] According to one embodiment of the present disclosure, the operation start conditions (or start conditions) can be specified in more detail and various ways by referring to [Table 1].

[0181] According to one embodiment of the present disclosure, the controller (710) can determine whether the start condition of a task is satisfied by checking the status of an external service through a connection with an external service. The CEL parsor (860) can determine whether the start condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0182] According to one embodiment of the present disclosure, the CEL parsor (860) can check the status of an external service through an external service connector (870) when a connection with an external service is required. By checking the status of the external service through the external service connector (870), the CEL parsor (860) can determine whether the conditions for starting a task are satisfied.

[0183] According to one embodiment of the present disclosure, the controller (710) can determine whether the start condition of a task is satisfied using resource information. The controller (710) can determine whether the start condition of a task is satisfied using base station Kubernetes resource information.

[0184] According to one embodiment of the present disclosure, the CEL parsor (860) can determine whether the start conditions of a task are satisfied using resource information. The CEL parsor (860) can determine whether the start conditions of a task are satisfied using base station Kubernetes resource information.

[0185] According to one embodiment of the present disclosure, a CEL parsor (860) can request resource information from a Kubernetes API server (970). A CEL parsor (860) can request base station Kubernetes resource information from a Kubernetes API server (970).

[0186] According to one embodiment of the present disclosure, a controller (710) can receive resource information from a Kubernetes API server (970) and determine whether the start conditions of a task are satisfied. The controller (710) can receive base station Kubernetes resource information from a Kubernetes API server (970) and determine whether the start conditions of a task are satisfied.

[0187] According to one embodiment of the present disclosure, a CEL parsor (860) can receive resource information from a Kubernetes API server (970) and determine whether the start conditions of a task are satisfied. A CEL parsor (860) can receive base station Kubernetes resource information from a Kubernetes API server (970) and determine whether the start conditions of a task are satisfied.

[0188] According to one embodiment of the present disclosure, if the controller (710) needs resource information to determine whether the start condition of a task is satisfied, it can obtain resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied. If the controller (710) needs resource information to check the start status of a task, it can obtain resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied.

[0189] According to one embodiment of the present disclosure, if the controller (710) needs base station Kubernetes resource information to determine whether the start condition of a task is satisfied, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied. If the controller (710) needs base station Kubernetes resource information to check the start status of a task, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied.

[0190] According to one embodiment of the present disclosure, if resource information is needed to determine whether the start condition of a task is satisfied, the CEL parsor (860) can obtain resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied. If resource information is needed to check the start status of a task, the CEL parsor (860) can obtain resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied.

[0191] According to one embodiment of the present disclosure, if the CEL parsor (860) needs base station Kubernetes resource information to determine whether the start condition of a task is satisfied, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied. If the CEL parsor (860) needs base station Kubernetes resource information to check the start status of a task, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the start condition is satisfied.

[0192] According to one embodiment of the present disclosure, the CEL parsor (860) may transmit a start condition result to the task controller (840). The CEL parsor (860) may transmit the start condition result to the task controller (840) in response to a request for a task start condition result. The CEL parsor (860) may transmit a start condition result to the task controller (840) including whether the task start condition is satisfied or the task start status.

[0193] Referring to operation S942, the controller (710) can perform an action corresponding to a task based on a task resource. The task controller (840) can perform an action corresponding to a task based on a task resource.

[0194] According to one embodiment of the present disclosure, the controller (710) may call an action implementation corresponding to the task when the start condition of the task is satisfied. The task controller (840) may call an action implementation corresponding to the task when the start condition of the task is satisfied.

[0195] According to one embodiment of the present disclosure, when the start condition of a task is satisfied, the task may perform an action. When the start condition of a task is satisfied, an action included in the task may be performed. When the start condition of a task is satisfied, an action according to the task may be performed.

[0196] According to one embodiment of the present disclosure, the controller (710) can call an actual action implementation based on action information of the corresponding task resource (Task CR) where the event occurred. The task controller (840) can call an actual action implementation based on action information of the corresponding task resource (Task CR) where the event occurred.

[0197] According to one embodiment of the present disclosure, a controller (710) can call an actual action implementation based on action information of a corresponding task resource (Task CR) where an event occurred among an ActionMap for performing a plurality of actions. A task controller (840) can call an actual action implementation based on action information of a corresponding task resource (Task CR) where an event occurred among an ActionMap for performing a plurality of actions.

[0198] According to one embodiment of the present disclosure, a work controller (840) can perform an action using an action implementer (820) through an action interface (830). The work controller (840) can call an action implementer using an action implementer (820) through an action interface (830).

[0199] For example, in the case of an iterate action, the task controller (840) can perform the role of creating multiple additional tasks, such as a for loop, based on internal action information. The action implementer (820) can send a request to create multiple tasks to the task controller (840). The task controller (840) can create multiple tasks using the action implementer (820).

[0200] For example, in the case of a create action, the task controller (840) can request the actual installation of resources at the base station where the CNF is deployed. The task controller (840) can request resource creation using the action implementer (820). The task controller (840) can send a resource creation request to the Kubernetes API server (970). The action implementer (820) can request resource creation from the Kubernetes API server (970).

[0201] For example, in the case of an update action, the task controller (840) can request an update to match the input image version. The task controller (840) can request a resource update using the action implementer (820). The task controller (840) can send a resource update request to the Kubernetes API server (970). The action implementer (820) can request a resource update from the Kubernetes API server (970).

[0202] For example, in the case of a delete action, the task controller (840) can request the deletion of a resource using the action implementer (820). The task controller (840) can send the resource deletion request to the Kubernetes API server (970). The action implementer (820) can request the deletion of a resource from the Kubernetes API server (970).

[0203] For example, in the case of an update external service action, the task controller (840) can request an external service update using the action implementer (820). The task controller (840) can request a service state change using the action implementer (820). The task controller (840) can send an external service update request to the external service connector (870). The task controller (840) can send a service state change request to the external service connector (870). The action implementer (820) can request an external service update from the external service connector (870). The action implementer (820) can request a service state change from the external service connector (870).

[0204] Referring to operation S943, the controller (710) can determine whether the termination condition of the task is satisfied. The task controller (840) can determine whether the termination condition of the task is satisfied.

[0205] According to one embodiment of the present disclosure, the controller (710) can determine whether the termination condition of a task is satisfied through the CEL parsor (860). The task controller (840) can determine whether the termination condition of a task is satisfied through the CEL parsor (860).

[0206] According to one embodiment of the present disclosure, the controller (710) can check the end status of a task through the CEL parsor (860). According to one embodiment of the present disclosure, the task controller (840) can check the start status of a task through the CEL parsor (860).

[0207] According to one embodiment of the present disclosure, the controller (710) can independently check the task termination status for a plurality of tasks through the CEL parsor (860). According to one embodiment of the present disclosure, the task controller (840) can independently check the task termination status for a plurality of tasks through the CEL parsor (860).

[0208] According to one embodiment of the present disclosure, a task controller (840) may send a request for a task termination condition result to a CEL parsor (860). The CEL parsor (860) may determine whether the task termination condition is satisfied. The CEL parsor (860) may check the task termination status.

[0209] According to one embodiment of the present disclosure, a task termination condition (or, termination state) may be performed by determining the completion state of another task. The CEL parsor (860) may determine whether the task termination condition is satisfied by determining the completion state of another task. The CEL parsor (860) may check the task termination state by determining the completion state of another task.

[0210] According to one embodiment of the present disclosure, the operation termination conditions (or termination states) can be specified in more detail and various ways by referring to [Table 1].

[0211] According to one embodiment of the present disclosure, the controller (710) can determine whether the termination condition of a task is satisfied by checking the status of an external service through a connection with an external service. The CEL parsor (860) can determine whether the termination condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0212] According to one embodiment of the present disclosure, the CEL parsor (860) can check the status of an external service through an external service connector (870) when a connection with an external service is required. By checking the status of the external service through the external service connector (870), the CEL parsor (860) can determine whether the termination condition of a task is satisfied.

[0213] According to one embodiment of the present disclosure, the controller (710) can determine whether the termination condition of a task is satisfied using resource information. The controller (710) can determine whether the termination condition of a task is satisfied using base station Kubernetes resource information.

[0214] According to one embodiment of the present disclosure, the CEL parsor (860) can determine whether the termination condition of a task is satisfied using resource information. The CEL parsor (860) can determine whether the termination condition of a task is satisfied using base station Kubernetes resource information.

[0215] According to one embodiment of the present disclosure, a CEL parsor (860) can request resource information from a Kubernetes API server (970). A CEL parsor (860) can request base station Kubernetes resource information from a Kubernetes API server (970).

[0216] According to one embodiment of the present disclosure, the controller (710) can receive resource information from the Kubernetes API server (970) and determine whether the termination condition of the task is satisfied. The controller (710) can receive base station Kubernetes resource information from the Kubernetes API server (970) and determine whether the termination condition of the task is satisfied.

[0217] According to one embodiment of the present disclosure, the CEL parsor (860) can receive resource information from the Kubernetes API server (970) and determine whether the termination condition of a task is satisfied. The CEL parsor (860) can receive base station Kubernetes resource information from the Kubernetes API server (970) and determine whether the termination condition of a task is satisfied.

[0218] According to one embodiment of the present disclosure, if the controller (710) needs resource information to determine whether the termination condition of a task is satisfied, it can obtain resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied. If the controller (710) needs resource information to check the termination status of a task, it can obtain resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied.

[0219] According to one embodiment of the present disclosure, if the controller (710) needs base station Kubernetes resource information to determine whether the termination condition of a task is satisfied, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied. If the controller (710) needs base station Kubernetes resource information to check the termination status of a task, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied.

[0220] According to one embodiment of the present disclosure, if resource information is needed to determine whether the termination condition of a task is satisfied, the CEL parsor (860) can obtain resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied. If resource information is needed to check the termination status of a task, the CEL parsor (860) can obtain resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied.

[0221] According to one embodiment of the present disclosure, if the CEL parsor (860) needs base station Kubernetes resource information to determine whether the termination condition of a task is satisfied, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied. If the CEL parsor (860) needs base station Kubernetes resource information to check the termination status of a task, it can obtain base station Kubernetes resource information through the Kubernetes API server (970) to determine whether the termination condition is satisfied.

[0222] According to one embodiment of the present disclosure, the CEL parsor (860) may transmit a termination condition result to the task controller (840). The CEL parsor (860) may transmit the termination condition result to the task controller (840) in response to a request for a task termination condition result. The CEL parsor (860) may transmit a termination condition result to the task controller (840) including whether the task termination condition is satisfied or the task termination status.

[0223] According to one embodiment of the present disclosure, the controller (710) may change the state of the task resource to completed when the termination condition of the task is satisfied. The task controller (840) may change the state of the task resource to completed when the termination condition of the task is satisfied.

[0224] The controller (710) can determine whether the termination condition of a task is satisfied by checking the status of the external service through a connection with the external service.

[0225] Referring to operation S950, the controller (710) can change the status of the workflow runner resource to complete when all statuses of the task resource are changed to complete. The workflow runner controller (850) can change the status of the workflow runner resource to complete when all statuses of the task resource are changed to complete.

[0226] According to one embodiment of the present disclosure, a WorkflowRunner Controller (850) checks the status of a plurality of created task resources and, when the status of all task resources (task CR) is changed to completed, can change the status of the corresponding WorkflowRunner resource (WorkflowRunner CR) to completed.

[0227] According to one embodiment of the present disclosure, a workflow runner controller (850) can check the task status with a task controller (840). The workflow runner controller (850) can send a request to check the task status to the task controller (840). The task controller (840) can send the task status to the workflow runner controller (850).

[0228] According to one embodiment of the present disclosure, a workflow runner controller (850) can determine whether all states of a task resource have been changed to completed based on a task status received from a task controller (840). If the workflow runner controller (850) determines based on the task status that all states of a task resource have been changed to completed, the workflow runner controller (850) can change the status of a workflow runner resource to completed.

[0229] Through the method of the present disclosure, a service upgrade function of a free form can be provided to a telecommunications operator actually operating a base station. Through the method of the present disclosure, the following technical effects can be provided.

[0230] The occurrence of emergency calls being dropped can be minimized. In other words, the likelihood of a call attempted during an emergency being disconnected or failing to connect in the middle of the conversation can be minimized. Emergency call dropping is considered a very serious problem in communication networks and is directly related to user safety; however, through the method of the present disclosure, this problem can be resolved by waiting for updates until all emergency calls have been completed.

[0231] Unnecessary redundancy failovers can be minimized by prioritizing the upgrade of Standby Pods. Previously, since it was impossible to know which Pod, Active or Standby, would be upgraded first, a failover could occur if the Active Pod was upgraded first, causing it to terminate. Service interruptions can be prevented by establishing an upgrade order that prioritizes Standby Pods.

[0232] Upgrades may be possible according to the operator's policy. Previously, there was a problem requiring waiting time per application, but through the method of the present disclosure, upgrades may be possible according to the operator's policy, for example, by minimizing call drops and minimizing upgrade time.

[0233] With the improved notification feature, you can check the completion status step by step during the upgrade.

[0234] Since upgrades can be performed sequentially, the upgrade can be executed to prevent the entire site from being simultaneously turned off.

[0235] The present disclosure is applicable to various types of scenarios or use cases. Examples of some of these scenarios or use cases are to be described in detail in FIGS. 10 to 13 below.

[0236] FIG. 10 is a drawing for illustrating an example of a flowchart for distributing an initial CNF according to one embodiment of the present disclosure.

[0237] Referring to Fig. 10, an example of a flowchart for distributing an initial CNF in a general situation is described.

[0238] According to one embodiment of the present disclosure, a CNF may represent one of various types of CNFs. Additionally, the target for distribution is not limited to a CNF, and general applications may also be targets for distribution. In one embodiment, "A", "B", "C", ... etc. may represent an application (or pod) included in the CNF.

[0239] According to one embodiment of the present disclosure, "A" may mean an application for managing a database. "B" may mean an application for managing resources of a CNF. "C" may be an application for managing the interface of a CU. "D" may be an application related to the processing of a CU. "E" may be an application for managing the SCTP (Stream Control Transmission Protocol) of a CU. "F" may be an application for tracing a CU. "G" may be an application for managing performance. "H" may be an application related to a Self-Organizing Network (SON). Here, the application may be referred to as a Pod.

[0240] In a general situation, the flowchart (or workflow) for deploying the initial CNF can be configured in the form of Fig. 10, and each task within the workflow is performed independently, and when all tasks are completed, the workflow is also completed.

[0241] A workflow can be composed of a combination of various tasks as follows. A task may include start / end conditions and action information.

[0242] Referring to task 1005, preinstallhookupdate may include an action that "updates hook information" with the value "PRE-INSTALL" unconditionally. Here, hook information may refer to user-defined action information that is executed in response to a specific event or state change.

[0243] Referring to task 1010, globalcreate can include the task of creating a globally available resource when the "preinstallhookupdate task" is completed.

[0244] Referring to task 1015, Acreate may include a task to "create resources for A Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.)" when the "globalcreate task" is completed.

[0245] Referring to task 1020, Bcreate can include the task of “creating resources for B Pods” when the “Acreate task” is completed.

[0246] Referring to task 1025, Ccreate can include the task of "creating resources in C Pod" when the "Acreate task" is completed.

[0247] Referring to task 1030, Dcreate can include the task of “creating resources of D Pod” when the “Acreate task” is completed.

[0248] Referring to task 1035, Ecreate can include the task of “creating resources for E Pods” when the “Acreate task” is completed.

[0249] Referring to task 1040, redismastercreate can include the task of “creating resources for redismaster Pod” when the “Acreate task” is completed.

[0250] Referring to task 1045, Fcreate can include the task of “creating resources for F Pods” when the “Acreate task” is completed.

[0251] Referring to task 1050, Gcreate can include a task to "create G Pod resources" when the "Acreate task" is completed.

[0252] Referring to task 1055, Hcreate may include the task of “creating resources of H Pod” when the “Acreate task” is completed.

[0253] Referring to task 1160, postinstallhookupdate may include an action to "update hook information" with a "POST-INSTALL" value when "all tasks within the workflow" are completed.

[0254] If the work is performed according to the flowchart above, the initial CNF application can be deployed in general situations.

[0255] FIG. 11 is a diagram illustrating an example of a flowchart for temporarily terminating resources during an upgrade according to one embodiment of the present disclosure.

[0256] Referring to Fig. 11, an example of a flowchart for upgrading a CNF while temporarily terminating the Horizontal Pod Autoscaling (HPA) of a CNF running in a public cloud environment is described.

[0257] According to one embodiment of the present disclosure, a CNF may represent one of various types of CNFs. Additionally, the target for upgrade is not limited to a CNF, and a general application may also be a target for upgrade. In one embodiment, "A", "B", "C", ... etc. may represent an application (or pod) included in the CNF.

[0258] According to one embodiment of the present disclosure, "D" may be a main module responsible for processing data with a user terminal within a base station, as an application related to the processing of a CU within a CNF. "D" may be configured with an All Active structure so that multiple services of the same application can be executed simultaneously, and may have a scalable structure, and as the number of "D" increases, the number of calls that can be processed within a single base station may increase.

[0259] According to one embodiment of the present disclosure, when deploying a CNF base station application to a cloud platform (e.g., AWS, GCP, etc.), a plurality of “D” running may also deploy Horizontal Pod Autoscaling (HPA) that can scale according to the CPU usage of each pod and the number of connected calls to control service usage within the base station.

[0260] According to one embodiment of the present disclosure, the problem that may occur at the time of performing an actual update is as follows. For example, if a total of four "D" services are running, the "D" services are updated sequentially for compatibility with existing services, and in this process, one of the four services becomes an updated state and cannot perform the actual service, and only the remaining three services may be able to perform call-related tasks.

[0261] According to one embodiment of the present disclosure, "D" services that are not performing updates may experience an increase in CPU usage and the number of associated calls, which may result in unnecessary service expansion work at the system level. In existing cloud environments, a function to prevent unnecessary service expansion work by temporarily disabling HPA during the upgrade period may not be provided.

[0262] A flowchart (or workflow) capable of solving the above problem can be configured in the form of Fig. 11, and each task within the workflow is performed independently, and when all tasks are completed, the workflow is also completed.

[0263] A workflow can be composed of a combination of various tasks as follows. A task may include start / end conditions and action information.

[0264] Referring to task 1105, preupgradehookupdate may include an action that "updates hook information" with a "PRE-UPDATE" value unconditionally. Here, hook information may refer to user-defined action information that is executed in response to a specific event or state change.

[0265] Referring to task 1110, Aupdate may include the task of “updating A Pod’s resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed. Here, the image tag may refer to a tag that identifies a container image to a specific version or state.

[0266] Referring to task 1115, Bupdate may include the task of “updating B Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “Aupdate task” is completed.

[0267] Referring to task 1120, Cupdate may include a task to "update C Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the "input image tag" when the "Aupdate task" is completed.

[0268] Referring to task 1125, hpadelete may include a task to “delete HPA (Horizontal Pod Autoscaling) of D Application” when the “Aupdate task” is completed.

[0269] Referring to task 1130, Dupdate may include the task of “updating D Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when “hpadelete” is completed.

[0270] Referring to task 1135, hpacreate may include a task to "create HPA (Horizontal Pod Autoscaling) of D Application" when the "Dupdate task" is completed.

[0271] Referring to task 1140, Eupdate may include the task of “updating the resources of the E Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “Aupdate task” is completed.

[0272] Referring to task 1145, redisupdate may include the task of “updating the resources of the redis Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “Aupdate task” is completed.

[0273] Referring to task 1150, Fupdate may include the task of “updating F Pod’s resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “Aupdate task” is completed.

[0274] Referring to task 1155, Gupdate may include a task to "update G Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the "input image tag" when the "Aupdate task" is completed.

[0275] Referring to task 1160, Hupdate may include a task to "update H Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the "input image tag" when the "Aupdate task" is completed.

[0276] Referring to task 1165, postupgradehookupdate may include an action to "update hook information" with a "POST-UPDATE" value when "all tasks within the workflow" are completed.

[0277] If the operation is performed according to the flowchart above, unnecessary service expansion can be prevented by deleting HPA before updating "D" and recreating HPA after "D" is updated.

[0278] FIG. 12 is a diagram illustrating an example of a flowchart for waiting for an update until an emergency call is terminated according to one embodiment of the present disclosure.

[0279] Referring to Fig. 12, an example of a flowchart is described in which, after receiving an event, the CNF application waits normally until the Emergency Call is terminated and then updates sequentially.

[0280] According to one embodiment of the present disclosure, a CNF may represent one of various types of CNFs. Additionally, the target for distribution is not limited to a CNF, and general applications may also be targets for distribution. In one embodiment, "A", "B", "C", ... etc. may represent an application (or pod) included in the CNF.

[0281] After receiving an event, the flowchart (or workflow) in which the CNF application waits normally until the Emergency Call is terminated and then updates sequentially can be configured in the form of Fig. 12, and each task within the workflow is performed independently, and when all tasks are completed, the corresponding workflow is also completed.

[0282] A workflow can be composed of a combination of various tasks as follows. A task may include start / end conditions and action information.

[0283] Referring to task 1201, waitexternalservice may include a task that "waits for an external service" without conditions.

[0284] Referring to task 1202, preupgradehookupdate may include an action to "update hook information" with a "PRE-UPDATE" value when the "waitexternalservice task" is completed. Here, hook information may refer to user-defined action information that is executed in response to a specific event or state change.

[0285] Referring to task 1203, Aupdate may include the task of “updating A Pod’s resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed. Here, the image tag may refer to a tag that identifies a container image to a specific version or state.

[0286] Referring to task 1204, Fupdate may include the task of “updating F Pod’s resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0287] Referring to task 1205, Gupdate may include a task to "update G Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the "input image tag" when the "preupgradehookupdate task" is completed.

[0288] Referring to task 1206, Hupdate may include the task of “updating H Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0289] Referring to task 1207, Bupdate may include the task of “updating B Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0290] Referring to task 1208, Bstandbyupdate may include the task of “updating the state of B Pods to standby” when the “Bupdate task” is completed.

[0291] Referring to task 1209, BactiveUpdate may include the task of “updating the state of B Pods to active” when the “BstandbyUpdate task” is completed.

[0292] Referring to task 1210, Cupdate may include a task to "update C Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the "input image tag" when the "preupgradehookupdate task" is completed.

[0293] Referring to task 1211, Cstandbyupdate may include the task of “updating the state of the C Pod to standby” when the “Cupdate task” is completed.

[0294] Referring to task 1212, Dupdate may include the task of “updating D Pod resources (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0295] Referring to task 1213, Dgetstatefulset may include the task of “getting information about the D pod’s stateful set resources” when the “Dupdate task” is completed.

[0296] Referring to task 1214, Dpodupdateiter may include a task to “repeat updates of D pods” when the “Dupdate task” is completed.

[0297] Referring to task 1215, Cactiveupdate may include the task of “updating the state of C Pods to active” when the “Cstandbyupdate task”, “Dgetstatefulset task”, and “Dpodupdateiter task” are completed.

[0298] Referring to task 1216, DprestopS{{index}} may include a task where "D pod terminates after the task according to index value is processed" when "Dgetstatefulset task" and "Dpodupdateiter tast" are completed. DprestopS{{index}} may represent a task that waits normally until an Emergency Call is completed.

[0299] Referring to task 1217, DpodupdatesS{{index}} may include the task of “updating D pods according to index value” when the “DprestopS{{index}} task” is completed.

[0300] Referring to task 1218, Eupdate may include the task of “updating the resources of the E Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0301] Referring to task 1219, Estandbyupdate may include the task of “updating the state of E Pods to standby” when the “Eupdate task” is completed.

[0302] Referring to task 1220, Eactiveupdate may include the task of “updating the state of E Pods to active” when the “Dgetstatefulset task”, “Dpodupdateiter task”, and “Estandbyupdate task” are completed.

[0303] Referring to task 1221, redisupdate may include the task of “updating the resources of the redis Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.) with the value of the “input image tag” when the “preupgradehookupdate task” is completed.

[0304] Referring to task 1222, redis0update may include the task of “updating resources of redis0 Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.)” when the “redisupdate task” is completed.

[0305] Referring to task 1223, redis1update may include the task of “updating resources of redis1 Pod (e.g., PodDisruptionBudget, ConfigMap, Service, Deployment, etc.)” when the “Dpodupdateiter task” and “redis0update task” are completed.

[0306] Referring to task 1224, postupgradehookupdate may include the task of “updating hook information” with a “POST-UPDATE” value when “all tasks within the workflow” are completed.

[0307] If the operation is performed according to the flowchart above, after receiving an event, "D" waits normally until the Emergency Call is terminated and then updates sequentially, thereby preventing the Emergency Call from being interrupted during the update.

[0308] FIG. 13 is a diagram illustrating an example of a flowchart for deleting and reinstalling an entire application according to an error situation according to one embodiment of the present disclosure.

[0309] Referring to Fig. 13, an example of a flowchart for deleting and reinstalling the entire CNF application when a pod error situation is detected in CNF is described.

[0310] According to one embodiment of the present disclosure, a CNF may represent one of various types of CNFs. Additionally, the target for distribution is not limited to a CNF, and general applications may also be targets for distribution. In one embodiment, "A", "B", "C", ... etc. may represent an application (or pod) included in the CNF.

[0311] According to one embodiment of the present disclosure, "I" may mean an application for managing the interface of a DU. "J" may mean an application for processing a DU. "K" may mean an application related to IPSec (Internet Protocol Security). "L" may mean an application for managing a RU (radio unit).

[0312] When a pod error situation is detected in CNF, a flowchart (or workflow) for deleting and reinstalling the entire CNF application can be configured in the form of Fig. 13, and each task within the workflow is performed independently, and when all tasks are completed, the workflow is also completed.

[0313] A workflow can be composed of a combination of various tasks as follows. A task may include start / end conditions and action information.

[0314] Referring to task 1305, checkappstatus can include an unconditional task to "check the status of the application." Checkappstatus can detect pod error situations in CNF.

[0315] Referring to task 1310, predeletehookupdate may include the task of “updating hook information” with a “PRE-DELETE” value when “checkappstatus tast” is completed.

[0316] Referring to task 1315, Adelete may include a task to “delete resources of A Pod” when the “predeletehookupdate task” is completed.

[0317] Referring to task 1320, Bdelete may include the task of “deleting resources of B Pod” when the “predeletehookupdate task” is completed.

[0318] Referring to task 1325, Idelete may include the task of “deleting resources of I Pod” when the “predeletehookupdate task” is completed.

[0319] Referring to task 1330, Jdelete may include the task of “deleting JPod resources” when the “predeletehookupdate task” is completed.

[0320] Referring to task 1335, Kdelete may include the task of “deleting resources of K Pod” when the “predeletehookupdate task” is completed.

[0321] Referring to task 1340, Gdelete may include a task to “delete G Pod resources” when the “predeletehookupdate task” is completed.

[0322] Referring to task 1345, Ldelete may include the task of “deleting resources of L Pod” when the “predeletehookupdate task” is completed.

[0323] Referring to task 1350, postdeletehookupdate may include a task to "update hook information" with a "POST-DELETE" value when the "task to delete all application resources" is completed.

[0324] Referring to task 1355, preinstallhookupdate may include a task to "update hook information" with the value "PRE-INSTALL" when the "postdeletehookupdate task" is completed.

[0325] Referring to task 1360, Acreate may include the task of “creating resources for A Pod” when the “preinstallhookupdate task” is completed.

[0326] Referring to task 1365, Bcreate can include the task of “creating resources for B Pods” when the “Acreate task” is completed.

[0327] Referring to task 1370, Icreate can include the task of “creating resources for I Pods” when the “Acreate task” is completed.

[0328] Referring to task 1375, Jcreate can include the task of “creating JPod resources” when the “Acreate task” is completed.

[0329] Referring to task 1380, Kcreate may include a task to "create resources for K Pods" when the "Acreate task" is completed.

[0330] Referring to task 1385, Gcreate can include a task to "create a resource in G Pod" when the "Acreate task" is completed.

[0331] Referring to task 1390, Lcreate may include the task of "creating resources for L Pod" when the "Acreate task" is completed.

[0332] Referring to task 1395, postinstallhookupdate may include an action to "update hook information" with a "POST-INSTALL" value when "all tasks within the workflow" are completed.

[0333] If the operation is performed according to the above flowchart, when a pod error situation in CNF is detected, the entire CNF application can be deleted and reinstalled (or reinstalled) to prepare for the CNF error situation.

[0334] FIG. 14 is a drawing for explaining an example of an operator's operating method according to one embodiment of the present disclosure.

[0335] Referring to Fig. 14, examples of units covered by one operator and the method of operation of the operator are described.

[0336] Referring to 1410, one operator can cover one cluster. One operator can deploy and update applications in a manner that covers one cluster. One operator can be operated in a manner that covers one cluster.

[0337] According to one embodiment of the present disclosure, a cluster may mean a set of nodes configured to deploy, manage, scale, and maintain containerized applications and related resources. A cluster may be the basic organizational unit of Kubernetes for performing container orchestration.

[0338] Referring to 1420, one operator can cover one namespace. One operator can deploy and update applications by covering one namespace. One operator can be operated by covering one namespace.

[0339] According to one embodiment of the present disclosure, a namespace may refer to a unit in which resources are logically separated within a cluster. Through namespaces, resources can be isolated between different projects, teams, or environments (e.g., development, test, production) even within the same cluster.

[0340] Referring to 1430, one operator can cover one CNF. One operator can deploy and update applications in a manner that covers one CNF. One operator can be operated in a manner that covers one CNF.

[0341] FIG. 15 is a flowchart illustrating an operation for managing a base station according to one embodiment of the present disclosure.

[0342] Referring to FIG. 15, the specific operation of a controller (710) for managing a base station is described.

[0343] Referring to operation S1510, the controller (710) can receive a cloud-native network function (CNF) upgrade request from a base station operator that includes a workflow runner resource.

[0344] According to one embodiment of the present disclosure, a controller (710) can obtain chart information by using repository information included in a workflow runner resource. The controller (710) can perform rendering that combines the chart information and setting value information included in the workflow runner resource. The controller (710) can generate resource information using the result of the rendering.

[0345] According to one embodiment of the present disclosure, the controller (710) can analyze the workflow resources included in the workflow runner resources to determine whether it is necessary to receive information from an external service. If it is necessary to receive information from an external service, the controller (710) can enable the monitoring function of the external service.

[0346] Referring to operation S1520, the controller (710) can create a task resource based on a workflow resource included in a workflow runner resource.

[0347] According to one embodiment of the present disclosure, a workflow resource may include a workflow that temporarily terminates an auto-scaling resource. A workflow resource may include a workflow that waits for an update of a call handling resource until an urgent call is terminated. A workflow resource may include a workflow that deletes and reinstalls the entire resource when a pod error situation is detected.

[0348] Referring to operation S1520, the controller (710) can perform an action corresponding to a task based on the task resource.

[0349] According to one embodiment of the present disclosure, the controller (710) can determine whether the start condition of a task is satisfied. The controller (710) can determine whether the start condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0350] According to one embodiment of the present disclosure, the controller (710) may call an action implementation corresponding to the task when the start condition of the task is satisfied.

[0351] According to one embodiment of the present disclosure, the controller (710) can determine whether the termination condition of a task is satisfied. The controller (710) can determine whether the termination condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0352] According to one embodiment of the present disclosure, the controller (710) may change the state of a task resource to completed when the termination condition of the task is satisfied. The controller (710) may change the state of a workflow runner resource to completed when all states of the task resource have been changed to completed.

[0353] FIG. 16 is a block diagram illustrating the configuration of an electronic device (1600) according to one embodiment of the present disclosure.

[0354] Referring to FIG. 16, the electronic device (1600) may include a communication interface (1610), a processor (1620), and a memory (1630). However, the components of the electronic device (1600) are not limited to the examples described above. For example, the electronic device (1600) may include more or fewer components than the components described above. In addition, some or all of the communication interface (1610), the processor (1620), and the memory (1630) may be implemented in the form of a single chip.

[0355] According to one embodiment of the present disclosure, the electronic device (1600) may refer to a hardware device on which the operation of the controller (710) is executed. The electronic device (1600) may include, but is not limited to, a server, a cloud server, a cloud platform host server, a base station CNF management server device, etc. The controller (710) may operate within a Kubernetes cluster to manage the base station CNF, and the electronic device (1600) may be a physical server or host server that constitutes the cluster.

[0356] The communication interface (1610) is configured to transmit and receive signals (control commands and data, etc.) to and from an external device via wired or wireless means, and may be implemented to include a communication chipset that supports various communication protocols. The communication interface (1610) may receive signals from the outside and output them to the processor (1620), or transmit signals output from the processor (1620) to the outside.

[0357] According to one embodiment of the present disclosure, a processor (1620) can control a series of processes that enable an electronic device (1600) to operate according to an embodiment of the present disclosure. For example, in a wireless communication system according to an embodiment of the present disclosure, the processor can receive a CNF upgrade request including a workflow runner resource, create a task resource based on the workflow resource included in the workflow runner resource, and control the components of the electronic device (1600) to perform an action corresponding to the task based on the task resource. The processor (1620) may be composed of one or more processors. One or more processors included in the processor (1620) may be circuitry such as a System on Chip (SoC), an Integrated Circuit (IC), etc. One or more processors included in the processor (1620) may be general-purpose processors such as CPU (Central Processing Unit), MPU (Micro Processor Unit), AP (Application Processor), DSP (Digital Signal Processor), graphics-dedicated processors such as GPU (Graphic Processing Unit) and VPU (Vision Processing Unit), artificial intelligence-dedicated processors such as NPU (Neural Processing Unit), or communication-dedicated processors such as CP (Communication Processor). If one or more processors included in the processor (1620) are artificial intelligence-dedicated processors, said artificial intelligence-dedicated processors may be designed with a hardware structure specialized for processing a specific artificial intelligence model. One or more processors included in the processor (1620) may also include processing circuitry.

[0358] The processor (1620) can write data to memory (1630) or read data stored in memory (1630), and in particular, can process data according to predefined operation rules or artificial intelligence models by executing programs or instructions stored in memory (1630). One or more processors included in the processor (1620) can execute instructions stored in memory (1630) individually or collectively. Accordingly, the processor (1620) can perform the operations described in the embodiments of the present disclosure, and the operations described in the present disclosure as being performed by the electronic device (1600) or modules included in the electronic device (1600) can be seen as being performed by the processor (1620) unless otherwise specified.

[0359] Memory (1630) is a configuration for storing various programs or data and may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Memory (1630) may not exist separately but may be configured to be included in the processor (1620). Memory (1630) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Programs or instructions for performing operations according to the embodiments described below may be stored in memory (1630). Memory (1630) may provide stored data to the processor (1620) upon the request of the processor (1620).

[0360] Meanwhile, although not illustrated in FIG. 16, the electronic device (1600) may include additional components to perform the operations described in the aforementioned embodiments.

[0361] In cases where a method according to one embodiment of the present disclosure includes a plurality of operations, the plurality of operations may be performed by a single processor or by a plurality of processors. For example, when a first operation, a second operation, and a third operation are performed by a method according to one embodiment, the first operation, the second operation, and the third operation may all be performed by a first processor, or the first operation and the second operation may be performed by a first processor (e.g., a general-purpose processor) and the third operation may be performed by a second processor (e.g., an AI-dedicated processor). Here, the AI-dedicated processor, which is an example of the second processor, may perform operations for training / inference of an AI model. However, the embodiments of the present disclosure are not limited thereto.

[0362] One or more processors according to the present disclosure may be implemented as a single-core processor or as a multi-core processor.

[0363] In the case where a method according to one embodiment of the present disclosure includes a plurality of operations, the plurality of operations may be performed by a single core or by a plurality of cores included in one or more processors.

[0364] The present disclosure relates to a method, apparatus, and system for managing a base station in a wireless communication system. The technical problems to be solved by the present disclosure are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description in this specification.

[0365] According to one aspect of the present disclosure, a method performed by a controller in a wireless communication system may be provided.

[0366] The above method may include a step of obtaining chart information using repository information included in a workflow runner resource.

[0367] The above method may include a step of performing a rendering that combines chart information and setting value information included in a workflow runner resource.

[0368] The above method may include a step of generating resource information using the result of rendering.

[0369] The above method may include a step of analyzing the workflow resource included in the workflow runner resource to determine whether receiving information from an external service is necessary.

[0370] The above method may include a step of activating the monitoring function of an external service when receiving information from an external service is required.

[0371] The above method may include a step of determining whether the start condition of a task is satisfied.

[0372] The above method may include the step of calling an action implementation corresponding to a task when the start condition of the task is satisfied.

[0373] The above method may include a step of determining whether the termination condition of a task is satisfied.

[0374] The above method may include a step of changing the state of a task resource to completed when the termination condition of the task is satisfied.

[0375] The above method may include a step of determining whether the start conditions of a task are satisfied by checking the status of an external service through a connection with an external service.

[0376] The above method may include a step of determining whether the termination condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0377] The above method may include a step of changing the status of a workflow runner resource to completed when all statuses of a task resource have been changed to completed.

[0378] The above workflow resource may include a workflow that temporarily terminates an auto-scaling resource.

[0379] The above workflow resource may include a workflow that waits for updates to the call processing resource until the urgent call is terminated.

[0380] The above workflow resource may include a workflow that deletes and reinstalls the entire resource when a pod error is detected.

[0381] According to one aspect of the present disclosure, a controller may be provided in a wireless communication system.

[0382] The above controller may include a transceiver; and at least one processor coupled to the transceiver.

[0383] The above at least one processor can obtain chart information by using repository information included in the workflow runner resource.

[0384] The above at least one processor can perform rendering that combines chart information and setting value information included in the workflow runner resource.

[0385] The above at least one processor can generate resource information using the result of rendering.

[0386] The above-mentioned at least one processor can analyze a workflow resource included in a workflow runner resource and determine whether it is necessary to receive information from an external service.

[0387] The above at least one processor can enable a monitoring function of an external service when it is necessary to receive information from an external service.

[0388] The above at least one processor can determine whether the start condition of a task is satisfied.

[0389] The above at least one processor may call an action implementation corresponding to a task when the start condition of the task is satisfied.

[0390] The above at least one processor can determine whether the termination condition of a task is satisfied.

[0391] The above at least one processor can change the state of the task resource to completed when the task termination condition is satisfied.

[0392] The above at least one processor can determine whether the start condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0393] The above at least one processor can determine whether the termination condition of a task is satisfied by checking the status of an external service through a connection with an external service.

[0394] The above at least one processor can change the state of the workflow runner resource to complete when all states of the task resource are changed to complete.

[0395] In the specific embodiments of the present disclosure described above, the components included in the invention are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, or even if a component is expressed in the singular form, it may be composed of a plural form.

[0396] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof. In other words, it is obvious to those skilled in the art that other modifications based on the technical concept of the present disclosure are possible. Furthermore, each of the above embodiments may be combined and operated as needed.

[0397] 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.

[0398] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. 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 this disclosure.

[0399] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM), magnetic disc storage devices, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0400] Additionally, the above program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or 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 through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present disclosure.

Claims

In a method performed by an electronic device, A step of receiving a cloud-native network function (CNF) upgrade request containing a workflow runner resource from a base station operator; A step of creating a task resource based on a workflow resource included in the above workflow runner resource; and A method comprising the step of performing an action corresponding to a task based on the above task resources. In Article 1, A step of obtaining chart information using repository information included in the above workflow runner resource; A step of performing a rendering that combines the above chart information and the setting value information included in the above workflow runner resource; and A method further comprising the step of generating resource information using the result of the above rendering. In Article 1 or Article 2, A step of analyzing the workflow resource included in the workflow runner resource to determine whether receiving information from an external service is necessary; and A method further comprising the step of activating a monitoring function of the external service when receiving information from the external service is required. In any one of paragraphs 1 to 3, Based on the above task resources, the step of performing the above action corresponding to the above task is: A step of determining whether the starting conditions of the above task are satisfied; If the start condition of the above task is satisfied, a step of calling an action implementation corresponding to the above task; A step of determining whether the termination condition of the above task is satisfied; and A method comprising the step of changing the state of a task resource to completed when the termination condition of the task is satisfied. In Paragraph 4, The step of determining whether the start condition of the above task is satisfied is: A method comprising the step of determining whether the start condition of the task is satisfied by checking the status of the external service through a connection with the external service. In Paragraph 4, The step of determining whether the termination condition of the above task is satisfied is: A method comprising the step of determining whether the termination condition of the task is satisfied by checking the status of the external service through a connection with the external service. In any one of paragraphs 1 through 6, A method comprising the step of changing the state of the workflow runner resource to completed when all states of the above task resources are changed to completed. In electronic devices, Memory for storing instructions; and It comprises at least one processor operably coupled to the memory and including a processing circuit, By having at least one processor execute the instructions alone or in cooperation, the electronic device, Receive a cloud-native network function (CNF) upgrade request from a base station operator that includes workflow runner resources, and Based on the workflow resources included in the above workflow runner resources, create a task resource, and An electronic device that performs an action corresponding to a task based on the above task resources. In Article 8, The above electronic device is, Using the repository information included in the above workflow runner resource, chart information is obtained, and Rendering is performed by combining the above chart information and the setting value information included in the above workflow runner resource, and An electronic device that generates resource information using the results of the above rendering. In Article 8 or Article 9, The above electronic device is, Analyze the workflow resource included in the workflow runner resource to determine whether receiving information from an external service is necessary, and An electronic device that activates a monitoring function of the external service when receiving information from the external service is required. In any one of paragraphs 8 through 10, The above electronic device is, Determine whether the start conditions of the above task are satisfied, and If the start condition of the above task is satisfied, call the action implementation corresponding to the above task, and Determine whether the termination condition of the above task is satisfied, and An electronic device that changes the state of a task resource to completed when the termination condition of the task is satisfied. In Article 11, The above electronic device is, An electronic device that determines whether the start conditions of the task are satisfied by checking the status of the external service through a connection with the external service. In Article 11, The above electronic device is, An electronic device that determines whether the termination condition of the task is satisfied by checking the status of the external service through a connection with the external service. In any one of paragraphs 8 through 13, The above electronic device is, An electronic device that changes the state of the workflow runner resource to completed when all states of the above task resources are changed to completed. A computer-readable recording medium having a program recorded thereon for performing the method of any one of claims 1 to 7 on a computer.

Images