WO2023128699A1 - 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법 - Google Patents

서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법 Download PDF

Info

Publication number
WO2023128699A1
WO2023128699A1 PCT/KR2022/021721 KR2022021721W WO2023128699A1 WO 2023128699 A1 WO2023128699 A1 WO 2023128699A1 KR 2022021721 W KR2022021721 W KR 2022021721W WO 2023128699 A1 WO2023128699 A1 WO 2023128699A1
Authority
WO
WIPO (PCT)
Prior art keywords
cnf
service
information
resource
descriptor
Prior art date
Application number
PCT/KR2022/021721
Other languages
English (en)
French (fr)
Inventor
심상역
찬드라세카란가네쉬
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020220006665A external-priority patent/KR20230103772A/ko
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Publication of WO2023128699A1 publication Critical patent/WO2023128699A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic

Definitions

  • the following embodiments relate to a technology for allocating resources of a cloud-native network function based on a service level agreement.
  • Cloud Native Computing refers to cloud-based containers and microservices.
  • Cloud-native computing is an environment that automates application or service system management with container-based technology. Compared to the existing environment, cloud-native computing has the characteristics of increasing system stability, streamlining operation/management tasks, quick response to business needs, and easy system expansion.
  • Container package means packaging an application into a container and distributing/executing it.
  • Container is a technology that originated from Linux, and all the components required for an application are packaged into a single image (file), and resources such as CPU, memory, and network are allocated and executed in an isolated independent space during execution, so deployment is easy and infrastructure resource utilization is high. has the advantage of being able to optimize If you package and deploy as a container, you can utilize idle resources and streamline cloud infrastructure costs because you can run the same or different applications on a single server by allocating as many resources as needed.
  • Dynamically management analyzes the resources of multiple computing nodes (servers, VMs, instances, etc.) and arranges containers (Scheduling), multiplexing (replication), scaling (scaling), redeployment in case of node failure (resuming), and non-stop It is a concept that dynamically automates tasks such as rolling updates. This is called container orchestration, and since application operation tasks can be automated, work efficiency, application availability, and scalability can be dramatically increased.
  • Micro service oriented is an architecture that separates existing monolithic applications into small units of service, makes them lightweight, and allows them to be reused through API. It has the advantage of being able to quickly respond to business needs by reorganizing existing and new services.
  • CNF Cloud-Native Network Functions
  • the 5th generation communication system aims not only to increase data transmission speed but also to provide connectivity capable of accommodating various application services that could not be supported in existing networks. Therefore, in the 5th generation communication system, not only eMBB (Enhanced Mobile Broadband), which aims at high-speed transmission of high-capacity data as a traditional wireless data service, but also mMTC (massive machine type communication), a large-scale inter-machine communication capable of various applications such as the Internet of Things, and industrial Additional services of URLLC (Ultra-Reliable and Low Latency Communication), which strictly require low latency and reliability, such as automation, vehicle-to-vehicle communication, unmanned aerial vehicles, and emergency notifications, will be provided.
  • eMBB Enhanced Mobile Broadband
  • mMTC massive machine type communication
  • URLLC Ultra-Reliable and Low Latency Communication
  • network slicing technology is used to configure multiple networks by logically dividing network resources to satisfy different service level agreements (SLAs) in one network infrastructure. This is being highlighted.
  • SLAs service level agreements
  • Network slicing is a technology that divides virtual networks with different SLAs based on a common physical infrastructure.
  • user devices radio access networks (RANs), and transport networks (TNs)
  • core network CN; Core Network
  • E2E End-to-End
  • a dedicated network specialized for that service is to provide
  • Each network slice (or slice) is guaranteed resources (virtualized server resources, virtualized network resources), and each slice is insulated from each other, so even if an error or failure occurs in a specific slice, communication in other slices is not affected. There is a feature that does not give.
  • Network slicing requires rapid service deployment and update, as well as high levels of availability and scalability, and is more suitable for a cloud-native environment than a virtualized environment, so the change to CNF is accelerating in the telecommunications field as well.
  • CNFs Cloud-Native Network Functions
  • SLA Service Level Agreement
  • the SLA requirements are Latency, Bandwidth, Mobility Level, Security, and Functionality List, and the CPU, memory, and storage (required when installing the actual CNF) Storage) is a completely different value from the amount of resources. Therefore, even if you change the latency value of the SLA requirement to reduce the latency of CNF, you cannot satisfy the SLA if you do not know how to change resources such as CPU and memory and how to modify internal settings when installing CNF.
  • Network Slice Manager (NSM) or End-to-end Orchestrator (E2EO) which manages network slices, delivers slice subnet requirements for managing each network slice. SLA is included in this requirement, but since there is no correlation between SLA and CNF resources, a person (Service Designer) must intervene to configure CNF. After all, network slice management based on automation is difficult.
  • a service provider sends a Request for Proposal (RFP) specifying the SLA of the service to the service developer.
  • RFP Request for Proposal
  • the developer calculates the amount of resources to meet the requested SLA and informs the service provider of several batch flavors such as Tiny, Medium, and Large. Because of this limited information delivery process, it is difficult to respond to rapid distribution of services and various lifecycle changes.
  • the resource allocation device defines a mapping relationship between a Service Level Agreement (SLA) and Cloud-Native Network Functions (CNF) resources to obtain an SLA Depending on the performance, the amount of CNF resources required can be automatically calculated.
  • SLA Service Level Agreement
  • CNF Cloud-Native Network Functions
  • the resource allocation device can provide a service distribution environment easily and quickly by automatically selecting a descriptor necessary for CNF deployment based on the SLA.
  • the resource allocation device associates the mapping relationship between SLA and CNF resources with available resource information of infrastructure, and provides information on the type of SLA that can be supported by the current infrastructure and the range of SLA values can provide.
  • a resource allocation method includes receiving request information requesting generation of a network slice subnet or network service in units of domains; Collecting related information for CNF configuration corresponding to the requested information; creating a CNF descriptor using information related to the CNF configuration; generating a CNF according to the CNF descriptor; and changing an internal parameter of the generated CNF.
  • the domain orchestrator includes: a catalog storing a CNF package, a CNF template descriptor, and a value type file defining a support relationship between a service level agreement and a container; service inventory that stores CNF information related to services; a resource management unit managing information stored in the catalog and the service inventory; Upon reception of request information requesting generation of network slice subnets or network services in units of domains, a CNF package, a CNF template descriptor, and a value type file corresponding to the request information are collected from the catalog, and from the service inventory through the resource management unit.
  • CNF information related to the service check the required CNF package from the function list included in the request information, search the value type file of the container group constituting the CNF, and select the value type file that satisfies the service level agreement requirements a service modeling unit that creates the CNF descriptor using the selected value type file, defines a relationship between CNFs, and requests CNF generation from a service lifecycle management unit; the service lifecycle management unit requesting the CNF generation to a CNF control unit when receiving a CNF generation request from the service modeling unit; and the CNF control unit for transmitting information on the CNF package and the CNF descriptor to a container orchestrator and requesting the generation of the CNF, upon receiving a request for generating the CNF from the service lifecycle management unit.
  • This document receives request information requesting creation of a network slice subnet or network service in units of domains, collects related information for CNF configuration corresponding to the requested information, and uses the related information for CNF configuration to create a CNF descriptor. It relates to an apparatus and method for allocating resources of CNF of SLA that creates CNF according to the CNF descriptor, and the amount of resources required according to SLA performance can be checked before CNF generation, and CNF distribution that satisfies the SLA The operator does not need to calculate computing resources such as CPU and RAM, and the type of SLA that can be supported by the current infrastructure and the range of SLA values are determined by linking the mapping relationship between SLA and CNF resources with available resource information of the infrastructure. can be limited
  • 1 is a diagram schematically illustrating logical resources allocated to various containers belonging to various slices according to an embodiment.
  • FIG. 2 is a diagram showing the configuration of a resource allocation device according to an embodiment.
  • FIG. 3 is a flowchart illustrating a process of allocating resources of a cloud-native network function based on a service level agreement in a resource allocation apparatus according to an embodiment.
  • FIG. 4 is a flowchart illustrating a process of collecting resource information in a resource allocation device according to an embodiment.
  • FIG. 5 is a flowchart illustrating a process of collecting related information for CNF configuration corresponding to requested information in a resource allocation apparatus according to an embodiment.
  • FIG. 6 is a flowchart illustrating a process of creating a CNF descriptor using related information for CNF configuration in a resource allocation apparatus according to an embodiment.
  • FIG. 7 is a flowchart illustrating a process of generating a CNF according to a CNF descriptor in a resource allocation apparatus according to an embodiment.
  • FIG. 8 is a flowchart illustrating a process of changing internal parameters of CNF in a resource allocation apparatus according to an embodiment.
  • FIG. 9 is a diagram illustrating an example of mapping a resource set of a CNF and a container group to a value type file in a resource allocation apparatus according to an embodiment.
  • FIG. 10 is a diagram illustrating an example of value type setting information according to an embodiment.
  • FIG. 11 is a diagram illustrating an example of selecting a value type file having a required CNF resource from an SLA value in a resource allocation apparatus according to an embodiment.
  • FIG. 12 is a diagram illustrating another example of selecting a value type file having a required CNF resource from an SLA value in a resource allocation apparatus according to an embodiment.
  • FIG. 13 is a diagram illustrating an example of displaying resource usage according to an available range of an SLA value and a value change in a resource allocation apparatus according to an embodiment.
  • first, second, A, B, (a), and (b) may be used in describing the components of the embodiment. These terms are only used to distinguish the component from other components, and the nature, order, or order of the corresponding component is not limited by the term.
  • an element is described as being “connected,” “coupled to,” or “connected” to another element, that element may be directly connected or connected to the other element, but there may be another element between the elements. It should be understood that may be “connected”, “coupled” or “connected”.
  • 1 is a diagram schematically illustrating logical resources allocated to various containers belonging to various slices according to an embodiment.
  • a relationship between a container, a CNF, a Network Service (NS), and a Network Slice can be confirmed.
  • a physical infrastructure such as the container infrastructures 151, 152, and 153 is used to create a container using a container orchestrator (eg, Kubernetes, Docker Swarm, etc.).
  • a container orchestrator eg, Kubernetes, Docker Swarm, etc.
  • the container runs specific applications that perform various tasks.
  • a container group (CG) 141-148 is a grouping of some of these containers to perform large-scale functional tasks. Grouping can be composed of various combinations, such as a combination of containers that perform the same setting task according to a purpose, a combination of containers that have different functions and a common task, and a combination of several identical containers.
  • CNFs 131-135 may be formed through definition of mapping and collaboration between various container groups (CGs) 141-148.
  • This mapping between CNFs 131-135 and CGs 141-148 can be defined in the form of a chart or template.
  • a domain orchestrator can process these charts or templates to manage the lifecycle of CNF.
  • the CNFs 132-135 may map one or more CGs.
  • the CNFs 132 and 135 may map a unique CG set.
  • the same CG 145 can be mapped to two different CNFs 133 and 134.
  • CNFs 131-135 can be mapped with CGs deployed only in the same infrastructure.
  • the lifecycle management of CGs (141-148) is performed by the container orchestrator, and these functions can be directly or indirectly coordinated by the domain orchestrator in the form of CNF lifecycle management.
  • CNFs 131-135 may be mapped together to Network Services (NS) 111, 112, and 123-125.
  • NSs can be defined using the NSD (NS Descriptor) standardized in ETSI SOL 001 or can follow a user-defined format.
  • Lifecycle management of NSs 111, 112, 123-125 is performed by the domain orchestrator.
  • Each NS 111, 112, 123-125 may map a dedicated or shared CG 141-148.
  • Each NS (111, 112, 123-125) has the same infrastructure (151, 152, 153), that is, only CNFs belonging to the same domain (eg, Core or RAN) exist.
  • Network Slice (110, 120) may be configured to include at least one NS (111, 112, 123-125).
  • FIG. 2 is a diagram showing the configuration of a resource allocation device according to an embodiment.
  • an end-to-end orchestrator (E2E Orchestrator) 210, a domain orchestrator (220), a container orchestrator (230), an element management system (EMS; Element Management System) ) 240 and infrastructure 250.
  • E2E Orchestrator an end-to-end orchestrator
  • a domain orchestrator (220)
  • a container orchestrator 230
  • EMS element Management System
  • the end-to-end orchestrator 210 transmits, to the domain orchestrator 220, request information for requesting generation of a network slice sublet or network service in each domain to the domain orchestrator 220. .
  • the request information may include a service level agreement (SLA) including performance requirements, a functional list, and control requirements required by the network slice subnet.
  • SLA service level agreement
  • the domain orchestrator 220 includes a service modeling unit 221, a resource management unit 222, a catalog 223, a service inventory 224, and a service lifecycle management unit. (Service Lifecycle Management) (225), CNF controller (CNF Controller) 226, and application controller (Application Controller) (227) It can be configured to include.
  • Service Lifecycle Management 225
  • CNF controller CNF Controller
  • Application Controller Application Controller
  • the service modeling unit 221 configures a concrete network service that satisfies SLA requirements from a CNF package or CNF template descriptor in the catalog 223. By managing mapping information between SLA and CNF resources, an automated CNF configuration work can be performed without intervention of a service designer.
  • the service modeling unit 221 receives request information requesting creation of a domain-based network slice subnet or network service, the CNF package corresponding to the request information from the catalog 223, a CNF template descriptor, and a value type file. , collects service-related CNF information from the service inventory 224 through the resource management unit 222, checks necessary CNF packages from the function list included in the request information, and identifies the value type of container groups constituting the CNF. Search files to select a value type file that satisfies service level agreement requirements, create a CNF descriptor using the selected value type file, define the relationship between CNFs, and request CNF generation to the service lifecycle management unit 225 do.
  • the service modeling unit 221 may store in the service inventory 224 a relationship between services related to a CNF requested to be created.
  • the resource management unit 222 manages information stored in the catalog 223 and the service inventory 224, and manages resource information of the infrastructure 250 and resource information of applications.
  • the resource management unit 222 may integrate and manage resources of instances for each layer based on Container-CNF-Network Service relation information of the service inventory 224 .
  • the catalog 223 stores a network service descriptor, a CNF package, a CNF template descriptor, and a value type file defining a support relationship between service level agreements and containers.
  • the network service descriptor is a distribution template describing distribution and operation requirements of the network service. It is used to create network services that perform lifecycle management tasks.
  • the CNF package is a package that gathers things necessary for running CNF, such as CNFD, container images, and scripts.
  • the CNF template descriptor can be converted into a concrete CNF descriptor by defining and customizing properties such as CNF internal network, number of CPUs, memory, and storage required for actual CNF deployment and operation.
  • the value type file is a file that is customized to create a concrete CNF descriptor.
  • the service inventory 224 stores CNF information related to services. More specifically, the service inventory 224 stores resources constituting network services (CNF, Networking, etc.) and relationships between the resources.
  • CNF network services
  • the service life cycle management unit 225 includes life cycles such as instantiation, activation, modification, de-activation, and termination of network services and CNFs constituting the network services. ) performs the function of managing
  • the service lifecycle manager 225 may request CNF generation to the CNF controller 226.
  • the service life cycle management unit 225 monitors state information of containers constituting the created CNF and manages the life cycle of the created CNF.
  • the service lifecycle manager 225 requests the application controller 227 to set application parameters included in the created CNF.
  • the CNF control unit 226 is a component in charge of interface with the container orchestrator 230 in the domain orchestrator 220, and converts the request from the internal configuration of the domain orchestrator 220 into the corresponding container orchestrator API and processes it. do.
  • the CNF controller 226 may transmit CNF package and CNF descriptor information to the container orchestrator 230 and request CNF generation.
  • the CNF control unit 226 may collect resource information of the infrastructure 250 from the container orchestrator 230 and transmit it to the resource management unit 222 .
  • the application control unit 227 is a configuration for interfacing with CNF internal applications, and may indirectly interface through the element management system 240 or directly interwork with CNF applications.
  • the application control unit 227 may change settings of application parameters included in the generated CNF. At this time, the setting of application parameters included in the CNF may be changed through the element management system 240 .
  • the application control unit 227 may collect resource information of CNF applications from the element management system 240 and transmit it to the resource management unit 222 .
  • the container orchestrator 230 When the container orchestrator 230 receives a request for CNF generation along with information on a CNF package and a CNF descriptor from the CNF control unit 226, the container orchestrator 230 allocates resources to containers using the CNF descriptor and configures a network to generate CNF. there is.
  • FIG. 3 is a flowchart illustrating a process of allocating resources of a cloud-native network function based on a service level agreement in a resource allocation apparatus according to an embodiment.
  • the resource allocation device 200 collects and manages infrastructure resource information and CNF application resource information (310). A detailed description of operation 310 will be described later with reference to FIG. 4 .
  • the resource allocation apparatus 200 receives request information for requesting creation of a network slice subnet or network service in units of domains (320).
  • the request information may include a service level agreement (SLA) including performance requirements, a functional list, and control requirements required by the network slice sublet.
  • SLA service level agreement
  • the resource allocation device 200 collects related information for CNF configuration corresponding to the requested information (330). A detailed description of operation 330 will be described later with reference to FIG. 5 .
  • the resource allocation device 200 creates a CNF descriptor using the related information for CNF configuration (340). A detailed description of operation 340 will be described later with reference to FIG. 6 .
  • the resource allocation device 200 generates CNF according to the CNF descriptor (350). A detailed description of operation 350 will be described later with reference to FIG. 7 .
  • the resource allocation device 200 changes internal parameters of the generated CNF (360). A detailed description of operation 360 will be described later with reference to FIG. 8 .
  • FIG. 4 is a flowchart illustrating a process of collecting resource information in a resource allocation device according to an embodiment.
  • the container orchestrator 230 of the resource allocation device 200 maintains resource information of the infrastructure as up-to-date (410).
  • the CNF control unit 226 of the resource allocation device 200 collects infrastructure resource information from the container orchestrator 230 and transmits it to the resource management unit 222 (420).
  • the CNF controller 226 may periodically request resource information from the container orchestrator 230 or collect resource information of the infrastructure 250 from the container orchestrator 230 through subscription.
  • the resource information of the infrastructure 250 collected at this time mainly deals with physical resources such as CPU, RAM, storage, and network capacity.
  • the container orchestrator 230 transmits a response to the resource information request of the infrastructure 250 to the domain orchestrator 220 . Since all communication with the container orchestrator 230 is performed through the CNF control unit 226, it is finally delivered to the resource management unit 222 via the CNF control unit 226.
  • the element management system 240 of the resource allocation device 200 collects and manages CNF application resource information (430).
  • the element management system 240 collects and manages resource information about capacity and performance of applications from the CNF.
  • the resource information of the application is resource information managed by the application, such as a session and a UE count.
  • the application control unit 227 of the resource allocation device 200 collects resource information of the CNF application from the element management system 240 and transmits it to the resource management unit 222 (440).
  • the domain orchestrator 220 periodically requests resource information of an application from the element management system 240 or applies for a subscription. And, the element management system 240 transfers a response to the resource information request of the application to the domain orchestrator 220 . Since all communication with the element management system 240 is performed through the application control unit 227, it is finally transmitted to the resource management unit 222 via the application control unit 227. In the case of a system without the element management system 240, the application control unit 227 may directly communicate with the CNF.
  • FIG. 5 is a flowchart illustrating a process of collecting related information for CNF configuration corresponding to requested information in a resource allocation apparatus according to an embodiment.
  • the service modeling unit 221 of the resource allocation device 200 collects CNF information related to the service from the service inventory 224 through the resource management unit 222 (520).
  • the resource management unit 222 transfers information on available and shared resources of the current infrastructure 250 and CNF to the service modeling unit 221.
  • the resource management unit 222 extracts information on CNFs related to a service to be created through the service inventory 224 .
  • FIG. 6 is a flowchart illustrating a process of creating a CNF descriptor using related information for CNF configuration in a resource allocation apparatus according to an embodiment.
  • the service modeling unit 221 of the resource allocation device 200 checks a necessary CNF package from the function list included in the request information received from the E2E orchestrator 210 and configures the CNF.
  • a value type file that satisfies service level agreement requirements is selected by searching for a value type file of a container group (610).
  • a CNF descriptor is created using the value type file selected by the service modeling unit 221 of the resource allocation device 200, the relationship between CNFs is defined, and the service lifecycle management unit 225 is requested to generate the CNF ( 620).
  • the service modeling unit 221 of the resource allocation device 200 stores the relationship with the service related to the CNF requested to be created in the service inventory 224 (630).
  • FIG. 7 is a flowchart illustrating a process of generating a CNF according to a CNF descriptor in a resource allocation apparatus according to an embodiment.
  • the service lifecycle management unit 225 of the resource allocation device 200 requests the CNF control unit 226 to generate a CNF (710).
  • the CNF control unit 226 When the CNF control unit 226 receives a CNF generation request from the service lifecycle management unit 225, it transmits the CNF package and CNF descriptor information to the container orchestrator 230 and requests CNF generation (720).
  • the container orchestrator 230 of the resource allocation device 200 receives a CNF generation request from the CNF control unit 226, it allocates resources to containers using the CNF descriptor and configures a network to generate CNF (730). ).
  • the service lifecycle management unit 225 of the resource allocation device 200 monitors state information of containers constituting the CNF created, and manages the life cycle of the created CNF (740).
  • FIG. 8 is a flowchart illustrating a process of changing internal parameters of CNF in a resource allocation apparatus according to an embodiment.
  • the service lifecycle management unit 225 of the resource allocation device 200 requests the application control unit 227 to set application parameters included in the CNF generated (810).
  • the setting of the application resource is completed by changing the setting of the application parameter included in the CNF generated by the application control unit 227 of the resource allocating device 200 (820).
  • the application control unit 227 may change the settings of application parameters included in the CNF generated through the element management system 240.
  • FIG. 9 is a diagram illustrating an example of mapping a resource set of a CNF and a container group to a value type file in a resource allocation apparatus according to an embodiment.
  • CNF is composed of a set of several Container Groups (CGs).
  • CGs Container Groups
  • the first CNF 910 is composed of a set of a plurality of container groups 911 to 913
  • the second CNF 920 is composed of a set of a plurality of container groups 921 to 923. .
  • SLA types related to each CG There are SLA types related to each CG, and the amount of resources required for container creation is described in the value type file according to the SLA value.
  • the container groups 911 to 913 included in the first CNF 910 have a first value type that is a different value type file among the value types 931 to 933 included in the first container infrastructure area 930. (931) and the second value type (932).
  • FIG. 10 is a diagram illustrating an example of value type setting information according to an embodiment.
  • the value type 1010 may include physical resources 1020 and application resources 1030 required for container creation. Also, in addition to the value type 1010, custom resources such as container image information may be further included.
  • FIG. 11 is a diagram illustrating an example of selecting a value type file having a required CNF resource from an SLA value in a resource allocation apparatus according to an embodiment.
  • the sla.yaml (1110) file corresponding to the service level agreement (SLA) has SLA attributes and a flavor file list according to the SLA value.
  • small_flavor.yaml (1120) and big_flavor.yaml (1130) files corresponding to value type files have resource information necessary for container group creation.
  • the domain orchestrator 220 may analyze the sla.yaml 1110 file, select a flavor file that satisfies the requested SLA, and request CNF generation.
  • the domain orchestrator 220 selects the small_flavor.yaml (1120) file if the session_num value is 100000, and if the session_num value is 1000000, big_flavor.yaml (1130 ) file can be selected.
  • FIG. 12 is a diagram illustrating another example of selecting a value type file having a required CNF resource from an SLA value in a resource allocation apparatus according to an embodiment.
  • a sla.yaml (1210) file corresponding to a service level agreement (SLA) has a type of SLA and a range of SLA values.
  • the flavor.yaml(1220) file corresponding to the value type file receives the SLA value and calculates the resources required for container creation through conditions and formulas.
  • the resource allocation device 200 may merge or further subdivide the file corresponding to the service level agreement (SLA) shown in FIGS. 11 and 12 and the value type file, and the domain orchestrator 220 may perform software It may be managed in the form of
  • SLA service level agreement
  • the resource allocation apparatus 200 knows the type of SLA supported by each container group and the range of values, it can know the amount of resources consumed as the value changes.
  • FIG. 13 is a diagram illustrating an example of displaying resource usage according to an available range of an SLA value and a value change in a resource allocation apparatus according to an embodiment.
  • the method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium.
  • the computer readable medium may store program instructions, data files, data structures, etc. alone or in combination.
  • Program commands recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in computer software.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks.
  • - includes hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like.
  • program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler.
  • the hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.
  • Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. You can command the device.
  • Software and/or data may be any tangible machine, component, physical device, virtual equipment, computer storage medium or device, intended to be interpreted by or provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave.
  • the software may be distributed on networked computer systems and stored or executed in a distributed manner.
  • Software and data may be stored on one or more computer readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 문서는 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법에 관한 것으로, 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하고, 상기 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하고, 상기 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하고, 상기 CNF 디스크립터에 따라 CNF를 생성한다.

Description

서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법
이하의 일 실시 예들은 서비스 레벨 협약을 기반으로 하는 클라우드 네이티브 네트워크 기능의 자원을 할당하는 기술에 관한 것이다.
최근 많은 서비스 제공 업체와 기업은 클라우드 기반의 컨테이너와 마이크로 서비스를 나타내는 클라우드 네이티브 컴퓨팅(Cloud Native Computing)을 사용하고 있다.
클라우드 네이티브 컴퓨팅은 어플리케이션 또는 서비스 시스템 관리를 컨테이너 기반 기술로 자동화 한 환경으로, 기존 환경에 비해 시스템 안정성을 높이고 운영/관리 업무의 효율화와 비즈니스 요구에 대한 빠른 응대, 시스템 확장이 용이한 특징을 가진다.
이러한 장점으로 IT 기술 중심 기업에서 이미 범용적으로 사용되고 있으며 최근 통신분야에서도 점차 도입이 확산되고 있다.
클라우드 네이티브 시스템은 다음과 같은 특성을 가진다
컨테이너 팩키지(Container package)
동적 관리(Dynamically management)
마이크로 서비스 지향(Micro service oriented)
컨테이너 팩키지(Container package)란 어플리케이션을 컨테이너로 패키징하고 배포/실행 한다는 것이다. 컨테이너는 리눅스로부터 시작된 기술로 어플리케이션에 필요한 모든 컴포넌트가 단일 이미지로(파일) 패키징되고 실행 시 격리된 독립 공간에 필요한 CPU, 메모리, 네트워크 등의 자원을 할당하여 실행됨으로 배포가 용이하고 인프라 자원의 이용률을 최적화 할 수 있는 장점이 있다. 컨테이너로 패키징 하여 배포하면 하나의 서버에서도 같은 또는 다른 여러 어플리케이션을 필요한 만큼 자원을 할당하여 실행 할 수 있기 때문에 유휴 자원을 활용할 수 있고 클라우드 인프라 비용을 효율화 할 수 있다.
동적 관리(Dynamically management)는 컨테이너를 다수의 컴퓨팅 노드(서버, VM, 인스턴스 등)의 자원을 분석하여 배치하고(Scheduling) 다중화(replication), 스케일링(scaling), 노드 오류 시 재배치(resuming), 무중단 업데이트(rolling update) 등의 작업을 동적으로 자동화 하는 개념이다. 이를 컨테이너 오케스트레이션(Orchestration)이라 하는데 어플리케이션 운영 작업을 자동화 할 수 있어 기존 보다 업무 효율과 어플리케이션의 가용성, 확장성을 획기적으로 높일 수 있다.
마이크로 서비스 지향(Micro service oriented)은 기존 모놀리식(Monolithic)한 어플리케이션을 작은 단위의 서비스로 분리, 경량화 하고 API를 통해 재사용 할 수 있도록 만드는 아키텍처로 서비스의 배포/업데이트가 민첩해지고 레고 블럭과 같이 기존 서비스와 신규 서비스를 재구성하여 빠르게 비즈니스 요구에 대응 할 수 있는 장점이 있다.
이와 같은 클라우드 네이티브 환경의 장정으로 인해 기존의 가상머신으로 개발된 네트워크 기능(Network Function)들이 컨테이너를 이용한 네트워크 기능으로 이동하고 있으며 이러한 기능을 클라우드 네이티브 네트워크 기능(CNF; Cloud-Native Network Functions)라 한다.
5세대 통신 시스템에서는 데이터의 전송 속도의 증대 뿐만 아니라 기존 네트워크에서 지원할 수 없었던 다양한 응용 서비스의 수용이 가능한 연결성 제공을 목표로 한다. 따라서 5세대 통신 시스템에서는 전통적인 무선 데이터 서비스로 고용량 데이터의 고속 전송을 목표로 하는 eMBB(Enhanced Mobile Broadband)뿐만 아니라, 사물 인터넷 등 다양한 응용이 가능한 대규모 사물 간 통신인 mMTC(massive Machine Type communication) 그리고 산업 자동화, 차량 간 통신, 무인 비행장치, 비상 상황 알림 등의 저지연과 신뢰도가 엄격히 요구되는 URLLC(Ultra-Reliable and Low Latency Communication의 서비스가 추가로 제공될 예정이다.
또한 이러한 다양한 서비스를 제공하기 위해, 하나의 네트워크 인프라에 서로 다른 서비스 레벨 협약(SLA; Service Level Agreement)을 만족시키기 위한 네트워크 자원을 논리적으로 나누어 여러 개의 네트워크를 구성하기 위해 네트워크 슬라이싱(Network Slicing) 기술이 부각되고 있다.
네트워크 슬라이싱이란 공통의 물리적 인프라를 기반으로 서로 다른 SLA를 가지는 가상 네트워크를 나누는 기술로, 물리적인 하나의 네트워크를 통해 사용자 장치, 무선 접속 네트워크(RAN; Radio Access Network), 전송 네트워크(TN; Transport Network), 코어 네트워크(CN; Core Network)를 포함하여 엔드 투 엔드(E2E; End-to-End,)로 논리적으로 분리된 네트워크를 만들어 서로 다른 특성을 갖는 다양한 서비스들에 대해 그 서비스에 특화된 전용 네트워크를 제공해주는 것이다. 각 네트워크 슬라이스(Network Slice, 또는 슬라이스)는 자원(가상화된 서버내 자원, 가상화된 망 자원)을 보장받으며, 각 슬라이스가 서로 간에 절연되어 있어 특정 슬라이스 내에 오류나 장애가 발생해도 다른 슬라이스의 통신에는 영향을 주지 않는다는 특징이 있다.
네트워크 슬라이싱을 위해서는 빠른 서비스의 배포와 업데이트, 그리고 높은 수준의 가용성과 확장성 등이 요구되며 이것은 기존 가상화 환경보다 클라우드 네이티브 환경에 더욱 적합하기 때문에 통신 분야에서도 CNF로의 변화가 가속화되고 있다.
서비스 레벨 협약(SLA; Service Level Agreement)을 보장할 수 있는 클라우드 네이티브 네트워크 기능(CNF; Cloud-Native Network Functions)을 구성하는데 다음과 같은 문제가 존재한다.
첫번째로 CNF의 SLA를 보장하기 위해 필요한 자원의 양을 알 수 없다.
SLA 요구사항은 레이턴시(Latency), 대역폭(Bandwidth), 이동성 수준(Mobility Level), 보안(Security) 및 기능 목록(Functionality List)과 같은 것으로 실제 CNF를 설치할 때 필요한 CPU, 메모리(Memory), 저장소(Storage)와 같은 자원의 양과는 전혀 다른 값이다. 따라서 CNF의 레이턴시를 줄이기 위해 SLA 요구사항의 레이턴시 값을 변경하여도 CNF 설치할 때 CPU, 메모리와 같은 자원은 어떻게 변경하고 내부 설정을 어떻게 수정해야할 지 모른다면 SLA를 만족시키지 못한다. 네트워크 슬라이스를 관리하는 NSM(Network Slice Manager) 혹은 E2EO(End-to-end Orchestrator)는 각 네트워크 슬라이스 관리를 위해 슬라이스 서브넷(Slice Subnet) 요구사양을 전달한다. 이 요구사양에는 SLA가 포함되어 있는데 SLA와 CNF 자원과의 상관관계가 없기 때문에 CNF 구성을 위해 사람(Service Designer)이 개입해야만 한다. 결국 자동화를 기반으로 하는 네트워크 슬라이스 관리가 어렵다.
두번째로 CNF의 배치 플레이버(Deployment Flavor)가 제한적이다.
일반적으로 서비스 제공자는 서비스 개발사에게 서비스의 SLA가 명시된 제안 요청서(RFP; Request for Proposal)를 전달한다. 개발사는 요청된 SLA를 충족시키는 자원의 양을 계산하여 작은(Tiny), 중간(Medium), 큰(Large) 과 같은 몇 가지 배치 플레이버를 서비스 제공자에게 알려준다. 이처럼 제한된 정보 전달과정 때문에 서비스의 빠른 배포와 다양한 라이프사이클(Lifecycle) 변화에 대응하기 어렵다.
세번째로 CNF 관리 시 인프라스트럭쳐 내에 적용 가능한 SLA 종류나 범위를 알 수 없다.
적용 가능한 SLA 값의 종류나 범위를 모른다면 CNF의 생성은 물론 스케일링, 업그레이드 등 전반적인 라이프사이클 변경 때 마다 반복적인 조정이 필요하다. 결국 자동화 관리가 어려워지게 된다.
본 문서에 개시되는 다양한 실시예에 따르면, 자원 할당 장치는 서비스 레벨 협약(SLA; Service Level Agreement)과 클라우드 네이티브 네트워크 기능(CNF; Cloud-Native Network Functions) 자원 간의 매핑(mapping) 관계를 정의하여 SLA 성능에 따라 필요한 CNF 자원의 양을 자동으로 계산할 수 있다.
또한, 다양한 실시예에 따르면, 자원 할당 장치는 SLA를 기반으로 CNF 배치에 필요한 디스크립터(Descriptor)을 자동으로 선택하여 쉽고 빠르게 서비스 배포환경을 제공할 수 있다.
또한, 다양한 실시예에 따르면, 자원 할당 장치는 SLA와 CNF자원간의 맵핑 관계를 인프라스트럭쳐(infrastructure)의 가용 자원 정보와 연계하여 현재의 인프라스트럭쳐에서 지원할 수 있는 SLA의 종류, 그리고 SLA 값의 범위 정보를 제공할 수 있다.
일 실시예에 따른 자원 할당 방법은, 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하는 동작; 상기 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하는 동작; 상기 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하는 동작; 상기 CNF 디스크립터에 따라 CNF를 생성하는 동작; 및 상기 생성한 CNF의 내부 파라미터를 변경하는 동작을 포함한다.
일 실시예에 따른 도메인 오케스트레이터를 포함하는 자원 할당 장치에 있어서, 상기 도메인 오케스트레이터는, CNF 패키지, CNF 템플릿 디스크립터 및 서비스 레벨 협약과 컨테이너 간의 지원 관계를 정의한 벨류 타입 파일을 저장하는 카탈로그; 서비스와 관련된 CNF 정보를 저장하는 서비스 인벤토리; 상기 카탈로그와 상기 서비스 인벤토리에 저장되는 정보를 관리하는 자원 관리부; 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하면, 상기 카탈로그로부터 상기 요청 정보에 대응하는 CNF 패키지, CNF 템플릿 디스크립터 및 벨류 타입 파일을 수집하고, 상기 자원 관리부를 통해서 서비스 인벤토리로부터 서비스와 관련된 CNF 정보를 수집하고, 상기 요청 정보에 포함된 기능 목록으로부터 필요한 CNF 패키지를 확인하고, CNF를 구성하는 컨테이너 그룹의 벨류 타입 파일을 검색하여 서비스 레벨 협약 요건을 충족시키는 벨류 타입 파일을 선택하고, 상기 선택한 벨류 타입 파일을 이용해서 상기 CNF 디스크립터를 작성하고, CNF 간의 관계를 정의하고, 서비스 라이프사이클 관리부로 CNF 생성을 요청하는 서비스 모델링부; 상기 서비스 모델링부로부터 CNF 생성을 요청받으면, CNF 제어부로 상기 CNF 생성을 요청하는 상기 서비스 라이프사이클 관리부; 및 상기 서비스 라이프사이클 관리부로부터 상기 CNF 생성을 요청받으면, 상기CNF 패키지와 상기 CNF 디스크립터의 정보를 컨테이너 오케스트레이터로 송신하고 상기 CNF 생성을 요청하는 상기 CNF 제어부를 포함한다.
본 문서는 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하고, 상기 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하고, 상기 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하고, 상기 CNF 디스크립터에 따라 CNF를 생성하는 SLA의 CNF의 자원 할당 장치 및 방법에 관한 것으로, SLA 성능에 따라 필요한 자원의 양을 CNF 생성 이전에 확인할 수 있으며, SLA를 만족하는 CNF 배포를 위해 운영자가 CPU, RAM 과 같은 컴퓨팅 자원을 계산할 필요 없으며, SLA와 CNF자원간의 맵핑 관계를 인프라스트럭쳐의 가용 자원 정보와 연계하여 현재의 인프라스트럭쳐에서 지원할 수 있는 SLA의 종류, 그리고 SLA 값의 범위를 한정할 수 있다.
도 1은 일 실시 예에 따라 여러 슬라이스에 속하는 다양한 컨테이너에 할당된 논리 리소스를 개략적으로 도시한 도면이다.
도 2는 일 실시 예에 따른 자원 할당 장치의 구성을 도시한 도면이다.
도 3은 일 실시 예에 따른 자원 할당 장치에서 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원을 할당하는 과정을 도시한 흐름도이다.
도 4는 일 실시 예에 따른 자원 할당 장치에서 자원 정보를 수집하는 과정을 도시한 흐름도이다.
도 5는 일 실시 예에 따른 자원 할당 장치에서 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하는 과정을 도시한 흐름도이다.
도 6은 일 실시 예에 따른 자원 할당 장치에서 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하는 과정을 도시한 흐름도이다.
도 7은 일 실시 예에 따른 자원 할당 장치에서 CNF 디스크립터에 따라 CNF를 생성하는 과정을 도시한 흐름도이다.
도 8은 일 실시 예에 따른 자원 할당 장치에서 CNF의 내부 파라미터를 변경하는 과정을 도시한 흐름도이다.
도 9는 일 실시 예에 따른 자원 할당 장치에서 CNF와 컨테이너 그룹의 자원 집합을 벨류 타입 파일로 매핑하는 예를 도시한 도면이다.
도 10은 일 실시 예에 따른 벨류 타입의 설정 정보의 예를 도시한 도면이다.
도 11은 일 실시 예에 따른 자원 할당 장치에서 SLA값으로부터 필요로 하는 CNF 자원을 가진 벨류 타입 파일을 선택하는 일 예를 도시한 도면이다.
도 12는 일 실시 예에 따른 자원 할당 장치에서 SLA값으로부터 필요로 하는 CNF 자원을 가진 벨류 타입 파일을 선택하는 다른 예를 도시한 도면이다.
도 13은 일 실시 예에 따른 자원 할당 장치에서 SLA 값의 가용 범위와 값 변경에 따라 자원 사용량을 표시하는 예를 도시한 도면이다.
이하에서, 첨부된 도면을 참조하여 실시예들을 상세하게 설명한다. 그러나, 실시예들에는 다양한 변경이 가해질 수 있어서 특허출원의 권리 범위가 이러한 실시예들에 의해 제한되거나 한정되는 것은 아니다. 실시예들에 대한 모든 변경, 균등물 내지 대체물이 권리 범위에 포함되는 것으로 이해되어야 한다.
실시예에서 사용한 용어는 단지 설명을 목적으로 사용된 것으로, 한정하려는 의도로 해석되어서는 안된다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
또한, 첨부 도면을 참조하여 설명함에 있어, 도면 부호에 관계없이 동일한 구성 요소는 동일한 참조부호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 실시예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 실시예의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.
또한, 실시 예의 구성 요소를 설명하는 데 있어서, 제1, 제2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.
어느 하나의 실시 예에 포함된 구성요소와, 공통적인 기능을 포함하는 구성요소는, 다른 실시 예에서 동일한 명칭을 사용하여 설명하기로 한다. 반대되는 기재가 없는 이상, 어느 하나의 실시 예에 기재한 설명은 다른 실시 예에도 적용될 수 있으며, 중복되는 범위에서 구체적인 설명은 생략하기로 한다.
이하에서는, 본 문서의 일 실시 예에 따른 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법을 첨부된 도 1 내지 도 13을 참조하여 상세히 설명한다.
도 1은 일 실시 예에 따라 여러 슬라이스에 속하는 다양한 컨테이너에 할당된 논리 리소스를 개략적으로 도시한 도면이다.
도 1을 참조하면, 컨테이너(Container), CNF, 네트워크 서비스(NS; Network Service) 및 네트워크 슬라이스(Network Slice) 간의 관계에 대해서 확인할 수 있다.
컨테이너 인프라(151, 152, 153)와 같은 물리적인 인프라스트럭쳐는 컨테이너 오케스트레이터(Container Orchestrator)를 사용하여 컨테이너(Container)를 만드는 데 사용된다(예를 들어, Kubernetes, Docker Swarm 등).
이때, 컨테이너는 다양한 작업을 수행하는 특정 응용 프로그램을 실행한다.
컨테이너 그룹(CG; Container Group)(141-148)은 기능적인 대규모 작업을 수행하기 위해 이러한 컨테이너 중 일부를 그룹화 한 것이다. 그룹화는 목적에 따라 동일한 설정 작업을 수행하는 컨테이너들의 조합, 서로 다른 기능을 가지고 있으면서 공동 작업을 컨테이너들의 조합 및 여러 개의 동일한 컨테이너들의 조합과 같이 다양한 조합으로 구성될 수 있다.
다양한 컨테이너 그룹(CG)(141-148)간의 매핑과 협업에 대한 정의를 통해 CNF(131-135)를 형성할 수 있다.
CNF(131-135)와 CG(141-148)간의 이러한 매핑은 차트 또는 템플릿 형식으로 정의할 수 있다. 도메인 오케스트레이터(Domain Orchestrator)는 이러한 차트 또는 템플릿을 처리하여 CNF의 수명주기(lifecycle)를 관리할 수 있다. 이때, CNF(132-135)는 하나 이상의 CG를 맵핑 할 수 있다. 또한, CNF(132, 135)는 고유한 CG 세트를 맵핑 할 수 있다. 또한, 동일한 CG(145)를 2 개의 다른 CNF(133, 134)로 매핑 할 수 있다. 또한, CNF(131-135)는 동일한 인프라에만 배포 된 CG와 매핑 될 수 있다.
CG(141-148)의 라이프사이클(Lifecycle) 관리는 컨테이너 오케스트레이터에서 수행하며, 이러한 기능은 CNF 라이프사이클 관리 형식으로 도메인 오케스트레이터가 직접 또는 간접적으로 조정 할 수 있다.
이러한 CNF(131-135) 중 일부는 네트워크 서비스(NS; Network Service)(111, 112, 123-125)로 함께 매핑 될 수 있다. 이러한 NS는 ETSI SOL 001에 표준화된 NSD(NS Descriptor)를 사용하여 정의하거나 사용자 정의 형식을 따를 수 있다.
NS(111, 112, 123-125)의 수명주기 관리는 도메인 오케스트레이터에 의해 수행된다.
각 NS(111, 112, 123-125)는 전용 또는 공유 CG(141-148)를 매핑 할 수 있다.
각 NS(111, 112, 123-125)는 동일한 인프라(151, 152, 153), 즉 동일한 도메인 (예를 들어, Core 또는 RAN 등)에 속하는 CNF만 존재한다.
네트워크 슬라이스(Network Slice)(110, 120)는 적어도 하나의 NS(111, 112, 123-125)를 포함하여 구성될 수 있다.
도 2는 일 실시 예에 따른 자원 할당 장치의 구성을 도시한 도면이다.
도 2를 참조하면, 엔드 투 엔드 오케스트레이터(E2E Orchestrator)(210), 도메인 오케스트레이터(Domain Orchestrator)(220), 컨테이너 오케스트레이터(Container Orchestrator)(230), 엘리먼트 관리 시스템(EMS; Element Management System)(240) 및 인프라스트럭쳐(Infrastructure)(250)를 포함하여 구성될 수 있다.
엔드 투 엔드 오케스트레이터(210)는 도메인 오케스트레이터(220)에 도메인 단위의 네트워크 슬라이스 서브넷(Network Slice Sublet) 또는 네트워크 서비스(Network Service) 생성을 요청하는 요청 정보를 도메인 오케스트레이터(220)로 송신한다.
이때, 요청 정보는 네트워크 슬라이스 서브넷에서 필요로 하는 성능 요구 사항과 기능 목록(Functionality List) 및 제어 요구사항을 포함하는 서비스 레벨 협약(SLA)을 포함할 수 있다.
도메인 오케스트레이터(220)는 서비스 모델링부(Service Modeling)(221), 자원 관리부(Resource Management)(222), 카탈로그(Catalog)(223), 서비스 인벤토리(Service Inventory)(224), 서비스 라이프사이클 관리부(Service Lifecycle Management)(225), CNF 제어부(CNF Controller)(226) 및 어플리케이션 제어부(Application Controller)(227)를 포함하여 구성될 수 있다.
서비스 모델링부(221)는 카탈로그(223)에 있는 CNF 패키지(CNF Package)나 CNF 템플릿 디스크립터(CNF Template Descriptor)로부터 SLA요구사양을 만족하는 콘크리트(Concrete)한 네트워크 서비스(Network Service)를 구성한다. SLA와 CNF 자원 간의 맵핑(mapping) 정보를 관리하여 서비스 디자이너(Service Designer)의 개입없이 자동화된 CNF 구성 작업을 수행할 수 있다.
보다 구체적으로, 서비스 모델링부(221)는 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하면, 카탈로그(223)로부터 요청 정보에 대응하는 CNF 패키지, CNF 템플릿 디스크립터 및 벨류 타입 파일을 수집하고, 자원 관리부(222)를 통해서 서비스 인벤토리(224)로부터 서비스와 관련된 CNF 정보를 수집하고, 요청 정보에 포함된 기능 목록으로부터 필요한 CNF 패키지를 확인하고, CNF를 구성하는 컨테이너 그룹의 벨류 타입 파일을 검색하여 서비스 레벨 협약 요건을 충족시키는 벨류 타입 파일을 선택하고, 선택한 벨류 타입 파일을 이용해서 CNF 디스크립터를 작성하고, CNF 간의 관계를 정의하고, 서비스 라이프사이클 관리부(225)로 CNF 생성을 요청한다.
서비스 모델링부(221)는 생성을 요청한 CNF와 관련된 서비스 간의 관계를 서비스 인벤토리(224)에 저장할 수 있다.
자원 관리부(222)는 카탈로그(223)와 서비스 인벤토리(224)에 저장되는 정보를 관리하는 구성으로, 인프라스트럭쳐(250)의 자원 정보와 어플리케이션(Application)의 자원 정보를 관리한다. 자원 관리부(222)는 서비스 인벤토리(224)의 컨테이너-CNF 네트워크 서비스 관계(Container-CNF-Network Service relation) 정보를 바탕으로 각 계층별 인스턴스(instance)의 자원을 통합하여 관리할 수 있다.
카탈로그(223)는 네트워크 서비스 디스크립터(Network Service Descriptor), CNF 패키지(CNF Package), CNF 템플릿 디스크립터(CNF Template Descriptor) 및 서비스 레벨 협약과 컨테이너 간의 지원 관계를 정의한 벨류 타입(Value Type) 파일을 저장한다. 이때, 네트워크 서비스 디스크립터는 네트워크 서비스의 배포 및 운영 요구 사항을 설명하는 배포 템플릿이다. 라이프 사이클 관리 작업을 수행하는 네트워크 서비스를 생성하는 데 사용된다. 그리고, CNF 패키지는 CNFD, 컨테이너 이미지와 스크립트 같이 CNF 구동에 필요한 것을 모은 패키지이다. 그리고, CNF 템플릿 디스크립터는 실제 CNF 배포와 운용에 필요한 CNF 내부 네트워크, CPU의 수, 메모리 및 스토리지 등과 같은 속성을 정의하고 커스터마이징을 통해 콘크리트(Concrete)한 CNF 디스크립터로 변환될 수 있다. 그리고, 벨류 타입 파일은 콘크리트한 CNF 디스크립터를 생성하기 위해 커스터마이징하는 파일이다.
서비스 인벤토리(224)는 서비스와 관련된 CNF 정보를 저장한다. 보다 구체적으로 서비스 인벤토리(224)는 네트워크 서비스를 구성하는 자원과(CNF, Networking 등) 자원들 간의 관계를 저장한다.
서비스 라이프사이클 관리부(225)는 네트워크 서비스와 네트워크 서비스를 구성하는 CNF의 인스턴스화(instantiation), 활성화(activation), 수정(modification), 비활성화(de-activation), 종료(termination)와 같은 라이프사이클(lifecycle)을 관리하는 기능을 수행한다
또한, 서비스 라이프사이클 관리부(225)는 서비스 모델링부(221)로부터 CNF 생성을 요청받으면, CNF 생성을 CNF 제어부(226)로 요청할 수 있다. 서비스 라이프사이클 관리부(225)는 생성한 CNF를 구성하는 컨테이너의 상태정보를 모니터링하고, 생성한 CNF의 라이프 사이클을 관리한다. 서비스 라이프사이클 관리부(225)는 CNF가 생성되면, 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 어플리케이션 제어부(227)에 요청한다.
CNF 제어부(226)는 도메인 오케스트레이터(220)에서 컨테이너 오케스트레이터(230)와 인터페이스를 담당하는 구성으로, 도메인 오케스트레이터(220)의 내부 구성으로부터 온 요청을 해당하는 컨테이너 오케스트레이터 API 로 변환하여 처리한다.
CNF 제어부(226)는 CNF 패키지와 CNF 디스크립터의 정보를 컨테이너 오케스트레이터(230)로 송신하고 CNF 생성을 요청할 수 있다.
CNF 제어부(226)는 컨테이너 오케스트레이터(230)로부터 인프라스트럭쳐(250)의 자원 정보를 수집하여 자원 관리부(222)로 송신할 수 있다.
어플리케이션 제어부(227)는 CNF 내부 어플리케이션과 인터페이스 하기 위한 구성으로 엘리먼트 관리 시스템(240)을 통해 간접적으로 인터페이스 하거나 혹은 CNF의 어플리케이션과 직접적으로 연동할 수 있다.
어플리케이션 제어부(227)는 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 변경할 수 있다. 이때, CNF에 포함된 어플리케이션 파라미터의 설정을 엘리먼트 관리 시스템(240)을 통해서 변경할 수도 있다.
어플리케이션 제어부(227)는 엘리먼트 관리 시스템(240)으로부터 CNF의 어플리케이션의 자원 정보를 수집하여 자원 관리부(222)로 송신할 수 있다.
컨테이너 오케스트레이터(230)는 CNF 제어부(226)로부터 CNF 패키지와 CNF 디스크립터의 정보와 함께 CNF의 생성을 요청받으면, CNF 디스크립터를 이용해서 컨테이너에 자원을 할당하고, 네트워크를 구성하여 CNF를 생성할 수 있다.
이하, 상기와 같이 구성된 본 문서에 따른 방법을 아래에서 도면을 참조하여 설명한다.
도 3은 일 실시 예에 따른 자원 할당 장치에서 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원을 할당하는 과정을 도시한 흐름도이다.
도 3을 참조하면, 자원 할당 장치(200)는 인프라의 자원정보와 CNF의 어플리케이션의 자원 정보를 수집하여 관리한다(310). 310동작의 구체적인 설명은 이후 도 4를 참조하여 후술한다.
그리고, 자원 할당 장치(200)는 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신한다(320). 이때, 요청 정보는 네트워크 슬라이스 서브넷(Network Slice Sublet)에서 필요로 하는 성능 요구 사항과 기능 목록(Functionality List) 및 제어 요구사항을 포함하는 서비스 레벨 협약(SLA)을 포함할 수 있다.
그리고, 자원 할당 장치(200)는 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집한다(330). 330동작의 구체적인 설명은 이후 도 5를 참조하여 후술한다.
그리고, 자원 할당 장치(200)는 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성한다(340). 340동작의 구체적인 설명은 이후 도 6을 참조하여 후술한다.
그리고, 자원 할당 장치(200)는 CNF 디스크립터에 따라 CNF를 생성한다(350). 350동작의 구체적인 설명은 이후 도 7을 참조하여 후술한다.
그리고, 자원 할당 장치(200)는 생성한 CNF의 내부 파라미터를 변경한다(360). 360동작의 구체적인 설명은 이후 도 8을 참조하여 후술한다.
도 4는 일 실시 예에 따른 자원 할당 장치에서 자원 정보를 수집하는 과정을 도시한 흐름도이다.
도 4를 참조하면, 자원 할당 장치(200)의 컨테이너 오케스트레이터(230)에서 인프라의 자원 정보를 최신 정보로 유지한다(410).
자원 할당 장치(200)의 CNF 제어부(226)에서 컨테이너 오케스트레이터(230)로부터 인프라의 자원 정보를 수집하여 자원 관리부(222)로 송신한다(420).
420동작에서, CNF 제어부(226)는 컨테이너 오케스트레이터(230)에 주기적으로 자원 정보를 요청하거나 구독을 통해 컨테이너 오케스트레이터(230)로부터 인프라스트럭쳐(250)의 자원 정보를 수집할 수 있다. 이때 수집하는 인프라스트럭쳐(250)의 자원 정보는 CPU, 램(RAM), 저장소(Storage) 그리고 Network 용량과 같은 물리적인 자원을 주로 다룬다.
컨테이너 오케스트레이터(230)는 인프라스트럭쳐(250)의 자원 정보 요청에 대한 응답을 도메인 오케스트레이터(220)에 전달한다. 컨테이너 오케스트레이터(230)와의 모든 통신은 CNF 제어부(226)를 통해 이루어지기 때문에 CNF 제어부(226)를 거쳐 자원 관리부(222)에 최종적으로 전달된다.
그리고, 자원 할당 장치(200)의 엘리먼트 관리 시스템(240)에서 CNF의 어플리케이션의 자원 정보를 수집하고 관리한다(430).
430동작에서, 엘리먼트 관리 시스템(240)은 CNF로부터 어플리케이션의 용량, 성능에 대한 자원 정보를 수집하여 관리한다. 이때 어플리케이션의 자원 정보는 세션(session), UE count 와 같이 어플리케이션에서 관리하는 자원 정보이다.
그리고, 자원 할당 장치(200)의 어플리케이션 제어부(227)에서 엘리먼트 관리 시스템(240)으로부터 CNF의 어플리케이션의 자원 정보를 수집하여 자원 관리부(222)로 송신한다(440).
440동작에서, 도메인 오케스트레이터(220)는 엘리먼트 관리 시스템(240)에 어플리케이션의 자원 정보를 주기적으로 요청하거나 구독을 신청한다. 그리고, 엘리먼트 관리 시스템(240)은 어플리케이션의 자원 정보 요청에 대한 응답을 도메인 오케스트레이터(220)에 전달한다. 엘리먼트 관리 시스템(240)과의 모든 통신은 어플리케이션 제어부(227)를 통해 이루어지기 때문에 어플리케이션 제어부(227)를 거쳐 자원 관리부(222)에 최종적으로 전달된다. 엘리먼트 관리 시스템(240)가 없는 시스템일 경우 어플리케이션 제어부(227)는 CNF 와 직접적으로 통신할 수도 있다.
도 5는 일 실시 예에 따른 자원 할당 장치에서 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하는 과정을 도시한 흐름도이다.
도 5를 참조하면, 자원 할당 장치(200)의 서비스 모델링부(221)에서 카탈로그(223)로부터 요청 정보에 대응하는 CNF 패키지, CNF 템플릿 디스크립터 및 서비스 레벨 협약과 컨테이너 간의 지원 관계를 정의한 벨류 타입 파일을 수집한다(510).
그리고, 자원 할당 장치(200)의 서비스 모델링부(221)에서 자원 관리부(222)를 통해서 서비스 인벤토리(224)로부터 서비스와 관련된 CNF 정보를 수집한다(520). 520동작에서, 자원 관리부(222)는 현재 인프라스트럭쳐(250)와 CNF의 가용 자원과 공유 자원에 대한 정보를 서비스 모델링부(221)로 전달한다. 자원 관리부(222)는 서비스 인벤토리(224)를 통해 생성하고자 하는 서비스와 관련된 CNF들의 정보를 추출한다.
도 6은 일 실시 예에 따른 자원 할당 장치에서 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하는 과정을 도시한 흐름도이다.
도 6을 참조하면, 자원 할당 장치(200)의 서비스 모델링부(221)에서 E2E 오케스트레이터(210)로부터 전달받은 요청 정보에 포함된 기능(Function) 목록으로부터 필요한 CNF 패키지를 확인하고, CNF를 구성하는 컨테이너 그룹(Container Group)의 벨류 타입 파일(Value Type file)을 검색하여 서비스 레벨 협약 요건을 충족시키는 벨류 타입 파일을 선택한다(610).
그리고, 자원 할당 장치(200)의 서비스 모델링부(221)에서 선택한 벨류 타입 파일을 이용해서 CNF 디스크립터를 작성하고, CNF 간의 관계를 정의하고, 서비스 라이프사이클 관리부(225)로 CNF 생성을 요청한다(620).
그리고, 자원 할당 장치(200)의 서비스 모델링부(221)에서 생성을 요청한 CNF와 관련된 서비스와의 관계를 서비스 인벤토리(224)에 저장한다(630).
도 7은 일 실시 예에 따른 자원 할당 장치에서 CNF 디스크립터에 따라 CNF를 생성하는 과정을 도시한 흐름도이다.
도 7을 참조하면, 자원 할당 장치(200)의 서비스 라이프사이클 관리부(225)에서 CNF 생성을 CNF 제어부(226)로 요청한다(710).
CNF 제어부(226)에서 서비스 라이프사이클 관리부(225)로부터 CNF 생성을 요청받으면, CNF 패키지와 CNF 디스크립터의 정보를 컨테이너 오케스트레이터(230)로 송신하고 CNF 생성을 요청한다(720).
그리고, 자원 할당 장치(200)의 컨테이너 오케스트레이터(230)에서 CNF 제어부(226)로부터 CNF 생성을 요청받으면, CNF 디스크립터를 이용해서 컨테이너에 자원을 할당하고, 네트워크를 구성하여 CNF를 생성한다(730).
그리고, 자원 할당 장치(200)의 서비스 라이프사이클 관리부(225)에서 생성한 CNF를 구성하는 컨테이너의 상태정보를 모니터링하고, 생성한 CNF의 라이프 사이클을 관리한다(740).
도 8은 일 실시 예에 따른 자원 할당 장치에서 CNF의 내부 파라미터를 변경하는 과정을 도시한 흐름도이다.
도 8을 참조하면, 자원 할당 장치(200)의 서비스 라이프사이클 관리부(225)에서 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 어플리케이션 제어부(227)에 요청한다(810).
그리고, 자원 할당 장치(200)의 어플리케이션 제어부(227)에서 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 변경하여 어플리케이션 자원의 설정을 완료한다(820). 820동작에서, 어플리케이션 제어부(227)는 엘리먼트 관리 시스템(240)을 통해서 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 변경할 수도 있다.
도 9는 일 실시 예에 따른 자원 할당 장치에서 CNF와 컨테이너 그룹의 자원 집합을 벨류 타입 파일로 매핑하는 예를 도시한 도면이다.
도 9를 참조하면, CNF는 여러 컨테이너 그룹(CG; Container Group)의 집합으로 이루어져 있다. 예를 들어, 제1 CNF(910)는 복수의 컨테이너 그룹(911-913)의 집합으로 구성되고, 제2 CNF(920)는 복수의 컨테이너 그룹(921-923)의 집합으로 구성됨을 확인할 수 있다.
각각의 CG마다 관련된 SLA 종류들이 있으며 SLA의 값에 따라 컨테이너 생성에 필요로 하는 자원의 양이 벨류 타입 파일에 기재되어 있다.
이때, 제1 CNF(910)에 포함된 컨테이너 그룹(911-913)이 제1 컨테이너 인프라스트럭쳐 영역(930)에 포함된 벨류 타입(931-933)들 중에서 서로 다른 벨류 타입 파일인 제1 벨류 타입(931)과 제2 벨류 타입(932)에 관련될 수도 있다. 또한, 제2 CNF(920)에 포함된 컨테이너 그룹(921-923)이 제2 컨테이너 인프라스트럭쳐 영역(940)에 포함된 벨류 타입(941-943)들 중에서 하나의 벨류 타입 파일인 제1 벨류 타입(941)에 관련될 수도 있다.
도 10은 일 실시 예에 따른 벨류 타입의 설정 정보의 예를 도시한 도면이다.
도 10을 참조하면, 벨류 타입(1010)에는 컨테이너 생성을 위해 필요한 물리적인 자원(1020) 및 어플리케이션 자원(1030)이 포함될 수 있다. 또한, 벨류 타입(1010)에 추가로 컨테이너 이미지에 대한 정보와 같이 커스텀 자원이 더 포함될 수도 있다.
도 11은 일 실시 예에 따른 자원 할당 장치에서 SLA값으로부터 필요로 하는 CNF 자원을 가진 벨류 타입 파일을 선택하는 일 예를 도시한 도면이다.
도 11을 참조하면, 서비스 레벨 협약(SLA)에 해당하는 sla.yaml(1110) 파일은 SLA 속성과 SLA값에 따른 flavor file list를 가지고 있다. 그리고, 벨류 타입 파일에 해당하는 small_flavor.yaml(1120) 및 big_flavor.yaml(1130) 파일은 컨테이너 그룹 생성에 필요한 자원 정보를 가지고 있다.
도메인 오케스트레이터(220)는 sla.yaml(1110) 파일을 분석하여 요청받은 SLA을 만족하는 flavor 파일을 선택하여 CNF 생성을 요청할 수 있다.
보다 구체적으로, 도메인 오케스트레이터(220)는 sla.yaml(1110) 파일을 분석한 결과 session_num 값이 100000이면, small_flavor.yaml(1120) 파일을 선택하고, session_num 값이 1000000이면, big_flavor.yaml(1130) 파일을 선택할 수 있다.
도 12는 일 실시 예에 따른 자원 할당 장치에서 SLA값으로부터 필요로 하는 CNF 자원을 가진 벨류 타입 파일을 선택하는 다른 예를 도시한 도면이다.
도 12를 참조하면, 서비스 레벨 협약(SLA)에 해당하는 sla.yaml(1210) 파일은 SLA의 종류와 SLA 값의 범위를 가지고 있다. 그리고, 벨류 타입 파일에 해당하는 flavor.yaml(1220) 파일은 SLA 값을 입력받아 조건과 수식을 통해 컨테이너 생성에 필요한 자원을 계산한다.
자원 할당 장치(200)는 도 11과 도 12에서 도시하고 있는 서비스 레벨 협약(SLA)에 해당하는 파일과 벨류 타입 파일을 하나로 합치거나 추가로 세분할 수 있으며, 도메인 오케스트레이터(220)에 의해서 소프트웨어의 형태로 관리될 수도 있다.
자원 할당 장치(200)는 컨테이너 그룹 별로 지원하는 SLA의 종류와 값의 범위를 알고 있다면 값이 변함에 따라 소모되는 자원의 양을 알 수 있다.
아래 도 13을 통해서 사용자가 설정 가능한 SLA의 종류와 값의 범위를 확인하고, SLA 값을 변경해 가면서 필요로 하는 자원의 양을 확인할 수 있는 그래픽 유저 인터페이스의 예를 설명한다.
도 13은 일 실시 예에 따른 자원 할당 장치에서 SLA 값의 가용 범위와 값 변경에 따라 자원 사용량을 표시하는 예를 도시한 도면이다.
도 13을 참조하면, 그래픽 유저 인터페이스 화면(1300)에서 사용자가 Service Catalogue(1310)에서 생성하고자 하는 Service(Network Service 혹은 CNF)를 선택하면, 선택한 서비스에 필요한 CNF의 배치도 CNF Deployment(1330) 창에 표시된다.
이후 사용자가 SLA(1320) 창에서 SLA의 값을 조절함에 따라서 CNF Deployment(1330) 창의 CNF의 배치와 Required Resource(1330)의 값이 즉각 변경된다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 저장할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.
이상과 같이 실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기를 기초로 다양한 기술적 수정 및 변형을 적용할 수 있다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 청구범위의 범위에 속한다.

Claims (15)

  1. 도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하는 동작;
    상기 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하는 동작;
    상기 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하는 동작;
    상기 CNF 디스크립터에 따라 CNF를 생성하는 동작; 및
    상기 생성한 CNF의 내부 파라미터를 변경하는 동작
    을 포함하는 자원 할당 방법.
  2. 제1항에 있어서,
    상기 요청 정보는,
    상기 네트워크 슬라이스 서브넷에서 필요로 하는 성능 요구 사항과 기능 목록 및 제어 요구사항을 포함하는 서비스 레벨 협약(SLA)을 포함하는
    자원 할당 방법.
  3. 제1항에 있어서,
    상기 요청 정보에 대응하는 CNF 구성을 위한 관련 정보를 수집하는 동작은,
    서비스 모델링부에서 카탈로그로부터 상기 요청 정보에 대응하는 CNF 패키지, CNF 템플릿 디스크립터 및 서비스 레벨 협약과 컨테이너 간의 지원 관계를 정의한 벨류 타입 파일을 수집하는 동작; 및
    상기 서비스 모델링부에서 자원 관리부를 통해서 서비스 인벤토리로부터 서비스와 관련된 CNF 정보를 수집하는 동작
    을 포함하는 자원 할당 방법.
  4. 제1항에 있어서,
    상기 CNF 구성을 위한 관련 정보를 이용해서 CNF 디스크립터를 작성하는 동작은,
    서비스 모델링부에서 상기 요청 정보에 포함된 기능 목록으로부터 필요한 CNF 패키지를 확인하고, CNF를 구성하는 컨테이너 그룹의 벨류 타입 파일을 검색하여 서비스 레벨 협약 요건을 충족시키는 벨류 타입 파일을 선택하는 동작;
    상기 서비스 모델링부에서 상기 선택한 벨류 타입 파일을 이용해서 상기 CNF 디스크립터를 작성하고, CNF 간의 관계를 정의하고, 서비스 라이프사이클 관리부로 CNF 생성을 요청하는 동작; 및
    상기 서비스 모델링부에서 생성을 요청한 CNF와 관련된 서비스와의 관계를 서비스 인벤토리에 저장하는 동작
    을 포함하는 자원 할당 방법.
  5. 제1항에 있어서,
    상기 CNF 디스크립터에 따라 CNF를 생성하는 동작은,
    서비스 라이프사이클 관리부에서 CNF 생성을 CNF 제어부로 요청하는 동작;
    상기 CNF 제어부에서 CNF 패키지와 상기 CNF 디스크립터의 정보를 컨테이너 오케스트레이터로 송신하고 CNF 생성을 요청하는 동작; 및
    상기 컨테이너 오케스트레이터에서 상기 CNF 디스크립터를 이용해서 컨테이너에 자원을 할당하고, 네트워크를 구성하여 CNF를 생성하는 동작
    을 포함하는 자원 할당 방법.
  6. 제5항에 있어서,
    상기 CNF 디스크립터에 따라 CNF를 생성하는 동작은,
    상기 서비스 라이프사이클 관리부에서 상기 생성한 CNF를 구성하는 컨테이너의 상태정보를 모니터링하고, 상기 생성한 CNF의 라이프 사이클을 관리하는 동작
    을 더 포함하는 자원 할당 방법.
  7. 제1항에 있어서,
    상기 CNF의 내부 파라미터를 변경하는 동작
    상기 서비스 라이프사이클 관리부에서 상기 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 어플리케이션 제어부에 요청하는 동작; 및
    상기 어플리케이션 제어부에서 상기 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 변경하는 동작
    을 포함하는 자원 할당 방법.
  8. 제7항에 있어서,
    상기 어플리케이션 제어부에서 상기 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 변경하는 동작은,
    상기 어플리케이션 제어부에서 상기 생성한 CNF에 포함된 어플리케이션 파라미터의 설정을 엘리먼트 관리 시스템을 통해서 변경하는
    자원 할당 방법.
  9. 제1항에 있어서,
    인프라스트럭쳐의 자원정보와 CNF의 어플리케이션의 자원 정보를 수집하여 관리하는 동작
    을 더 포함하는 자원 할당 방법.
  10. 제9항에 있어서,
    상기 인프라스트럭쳐의 자원 정보와 상기 CNF의 어플리케이션의 자원 정보를 수집하여 관리하는 동작은,
    컨테이너 오케스트레이터에서 상기 인프라스트럭쳐의 자원 정보를 최신 정보로 유지하는 동작;
    CNF 제어부에서 상기 컨테이너 오케스트레이터로부터 상기 인프라스트럭쳐의 자원 정보를 수집하여 자원 관리부로 송신하는 동작;
    엘리먼트 관리 시스템에서 상기 CNF의 어플리케이션의 자원 정보를 수집하고 관리하는 동작; 및
    어플리케이션 제어부에서 상기 엘리먼트 관리 시스템으로부터 상기 CNF의 어플리케이션의 자원 정보를 수집하여 상기 자원 관리부로 송신하는 동작
    을 포함하는 자원 할당 방법.
  11. 제9항에 있어서,
    상기 인프라스트럭쳐의 자원 정보는,
    물리적인 자원에 관한 정보인
    자원 할당 방법.
  12. 제9항에 있어서,
    상기 CNF의 어플리케이션의 자원 정보는,
    상기 CNF에 포함된 어플리케이션에서 요구하는 자원 정보인
    자원 할당 방법.
  13. 도메인 오케스트레이터를 포함하는 자원 할당 장치에 있어서,
    상기 도메인 오케스트레이터는,
    CNF 패키지, CNF 템플릿 디스크립터 및 서비스 레벨 협약과 컨테이너 간의 지원 관계를 정의한 벨류 타입 파일을 저장하는 카탈로그;
    서비스와 관련된 CNF 정보를 저장하는 서비스 인벤토리;
    상기 카탈로그와 상기 서비스 인벤토리에 저장되는 정보를 관리하는 자원 관리부;
    도메인 단위의 네트워크 슬라이스 서브넷 또는 네트워크 서비스 생성을 요청하는 요청 정보를 수신하면, 상기 카탈로그로부터 상기 요청 정보에 대응하는 CNF 패키지, CNF 템플릿 디스크립터 및 벨류 타입 파일을 수집하고, 상기 자원 관리부를 통해서 서비스 인벤토리로부터 서비스와 관련된 CNF 정보를 수집하고, 상기 요청 정보에 포함된 기능 목록으로부터 필요한 CNF 패키지를 확인하고, CNF를 구성하는 컨테이너 그룹의 벨류 타입 파일을 검색하여 서비스 레벨 협약 요건을 충족시키는 벨류 타입 파일을 선택하고, 상기 선택한 벨류 타입 파일을 이용해서 상기 CNF 디스크립터를 작성하고, CNF 간의 관계를 정의하고, 서비스 라이프사이클 관리부로 CNF 생성을 요청하는 서비스 모델링부;
    상기 서비스 모델링부로부터 CNF 생성을 요청받으면, CNF 제어부로 상기 CNF 생성을 요청하는 상기 서비스 라이프사이클 관리부; 및
    상기 서비스 라이프사이클 관리부로부터 상기 CNF 생성을 요청받으면, 상기CNF 패키지와 상기 CNF 디스크립터의 정보를 컨테이너 오케스트레이터로 송신하고 상기 CNF 생성을 요청하는 상기 CNF 제어부
    를 포함하는 자원 할당 장치.
  14. 제13항에 있어서,
    상기 요청 정보는,
    상기 네트워크 슬라이스 서브넷에서 필요로 하는 성능 요구 사항과 기능 목록 및 제어 요구사항을 포함하는 서비스 레벨 협약(SLA)을 포함하는
    자원 할당 장치.
  15. 제13항에 있어서,
    상기 서비스 모델링부는,
    상기 생성을 요청한 CNF와 관련된 서비스 간의 관계를 상기 서비스 인벤토리에 저장하는
    자원 할당 장치.
PCT/KR2022/021721 2021-12-30 2022-12-30 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법 WO2023128699A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20210192954 2021-12-30
KR10-2021-0192954 2021-12-30
KR10-2022-0006665 2022-01-17
KR1020220006665A KR20230103772A (ko) 2021-12-30 2022-01-17 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법

Publications (1)

Publication Number Publication Date
WO2023128699A1 true WO2023128699A1 (ko) 2023-07-06

Family

ID=86999721

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/021721 WO2023128699A1 (ko) 2021-12-30 2022-12-30 서비스 레벨 협약 기반의 클라우드 네이티브 네트워크 기능의 자원 할당 장치 및 방법

Country Status (1)

Country Link
WO (1) WO2023128699A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200264914A1 (en) * 2019-02-15 2020-08-20 Cisco Technology, Inc. Virtual infrastructure manager enhancements for remote edge cloud deployments
US20200275357A1 (en) * 2019-02-22 2020-08-27 Vmware, Inc. Virtual service networks
KR20200125656A (ko) * 2018-02-26 2020-11-04 싱클레어 브로드캐스트 그룹, 인코포레이티드 차세대 멀티-채널-테넌트 가상화 브로드캐스트 플랫폼 및 5g 융합
KR20210101373A (ko) * 2020-02-07 2021-08-19 삼성전자주식회사 무선 통신 시스템에서 네트워크 슬라이스를 생성하기 위한 장치 및 방법
WO2021171073A1 (ja) * 2020-02-26 2021-09-02 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド コンピュータシステムおよびネットワークサービス構築方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200125656A (ko) * 2018-02-26 2020-11-04 싱클레어 브로드캐스트 그룹, 인코포레이티드 차세대 멀티-채널-테넌트 가상화 브로드캐스트 플랫폼 및 5g 융합
US20200264914A1 (en) * 2019-02-15 2020-08-20 Cisco Technology, Inc. Virtual infrastructure manager enhancements for remote edge cloud deployments
US20200275357A1 (en) * 2019-02-22 2020-08-27 Vmware, Inc. Virtual service networks
KR20210101373A (ko) * 2020-02-07 2021-08-19 삼성전자주식회사 무선 통신 시스템에서 네트워크 슬라이스를 생성하기 위한 장치 및 방법
WO2021171073A1 (ja) * 2020-02-26 2021-09-02 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド コンピュータシステムおよびネットワークサービス構築方法

Similar Documents

Publication Publication Date Title
WO2020017843A1 (ko) 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법
WO2018203635A1 (ko) 클라우드 플랫폼에서 어플리케이션을 컨테이너화하는 방법
WO2020017844A1 (ko) 클라우드 플랫폼에서 복수의 클러스터 및 어플리케이션을 모니터링하는 방법
Medhat et al. Service function chaining in next generation networks: State of the art and research challenges
US11099869B2 (en) Management of network functions virtualization and orchestration apparatus, system, management method, and program
WO2020017847A1 (ko) 클라우드 플랫폼에서의 멀티 클러스터 프로비저닝 및 관리 방법
CN106657173B (zh) 一种nfv架构下软件升级中的业务迁移方法、装置及服务器
EP3281111B1 (en) Method and entities for service availability management
WO2020017846A1 (ko) 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법
EP3796163A1 (en) Data processing method and related device
WO2009098909A1 (ja) 仮想アプライアンス配備システム
CN111510515B (zh) 一种区分混合应用环境的容器的方法及装置
CN111835878A (zh) 混合云管理方法、装置和计算设备
Buzachis et al. Towards osmotic computing: Analyzing overlay network solutions to optimize the deployment of container-based microservices in fog, edge and iot environments
CN109358967B (zh) 一种me平台app实例化迁移方法及服务器
WO2014003505A1 (ko) 디바이스 소셜리티 구성 시스템 및 방법
CN111245634B (zh) 一种虚拟化管理方法及装置
WO2019132314A1 (ko) 무선 통신 시스템에서 네트워크 기능 가상화를 위한 장치 및 방법
CN109995552B (zh) Vnf服务实例化方法及装置
WO2021125502A1 (ko) 컨테이너 기반의 클라우드 서비스 제공 시스템 및 그 방법
CN115733746B (zh) 一种服务网格单元的部署方法、装置、设备及存储介质
CN104699522B (zh) 一种虚拟机动态迁移方法
Rafiq et al. Intent-Based Slicing between Containers in SDN Overlay Network.
US11683222B2 (en) Virtual network function VNF deployment method and apparatus
WO2018008933A1 (ko) 단일 인터넷 회선을 이용한 가상 cpe 서비스 제공 방법 및 네트워크 펑션 가상화 클라우드

Legal Events

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

Ref document number: 22916840

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE