Computer system and network service construction method

Abstract

A network operating system (NOS 12) accepts a bundle file including first data that defines a function unit group that realizes a network service and second data that defines a monitoring policy relating to the network service, these data being transmitted from a vendor terminal 16 of a vendor who provides the network service. When the network service is purchased by a purchaser, the NOS 12 constructs the function unit group on the basis of the first data of the bundle file. The NOS 12 executes a monitoring process on the function unit group on the basis of information that relates to the function unit group that is constructed and the second data of the bundle file.

Description

[Technical field]

[0001] The present disclosure relates to data processing technology, and more particularly to a computer system and a network service construction method. [Background technology]

[0002] As an example of a technology related to the deployment of functional units in response to the purchase of a network service, Patent Document 1 describes a technology in which an order for a product purchased by a customer is broken down into VNF (Virtualized Network Function) units and deployed on a Network Functions Virtualization Infrastructure (NFVI).

[0003] Patent Document 2 describes a technique for distributing network function units in available computing devices according to a distribution request so as to satisfy an isolation requirement, which is a requirement regarding non-sharing.

[0004] Patent document 3 describes a technology that allows multiple operators to use all or part of multiple network slices managed by a higher-level operator in a unique manner. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2018 / 181826

[0006] [Patent Document 2] WO 2019 / 64678

[0007] [Patent Document 3] International Publication No. 2018 / 34321 Summary of the Invention [Problem to be solved by the invention]

[0008] There are various needs for network services, such as the configuration, scale, target area, etc. However, even if the techniques described in Patent Documents 1 to 3 are used, it is not possible to flexibly build network services that meet various needs.

[0009] The present disclosure has been made in consideration of the above-mentioned circumstances, and one of its objectives is to provide a technique for supporting the flexible construction of network services that meet various needs. [Means for solving the problem]

[0010] In order to solve the above problems, a computer system of one embodiment of the present disclosure includes a reception unit that receives a bundle file transmitted from a device of a vendor providing a network service, the bundle file including first data defining a group of functional units that realizes the network service and second data defining a monitoring policy for the network service, a construction unit that constructs the group of functional units based on the first data of the bundle file when the network service is purchased by a purchaser, and a monitoring management unit that executes monitoring processing on the group of functional units based on information regarding the group of functional units constructed by the construction unit and the second data of the bundle file.

[0011] Another aspect of the present disclosure is a network service construction method, which is executed by a computer, comprising the steps of: receiving a bundle file transmitted from an apparatus of a vendor that provides a network service, the bundle file including first data defining a functional unit group that realizes the network service and second data defining a monitoring policy for the network service; constructing the functional unit group based on the first data of the bundle file when the network service is purchased by a purchaser; and executing a monitoring process for the functional unit group based on information on the functional unit group constructed in the constructing step and the second data of the bundle file.

[0012] In addition, any combination of the above components, and any conversion of the expressions of the present disclosure between an apparatus, a computer program, a recording medium on which a computer program is readably recorded, etc. are also valid as aspects of the present disclosure. Effect of the Invention

[0013] According to the present disclosure, it is possible to assist in flexibly constructing network services that meet various needs. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram showing a computer system according to a first embodiment.

[0015] [Diagram 2] FIG. 2 is a diagram illustrating an example of a purchase screen.

[0016] [Diagram 3] FIG. 3 is a diagram showing an example of a service requirement input screen.

[0017] [Figure 4] FIG. 4 is a diagram showing an example of the purchase confirmation screen.

[0018] [Diagram 5] FIG. 5 is a diagram showing an example of the purchase confirmation screen.

[0019] [Figure 6] FIG. 6 is a diagram illustrating an example of the data structure of a bundle file.

[0020] [Figure 7] FIG. 7 is a diagram showing a hierarchical structure of multiple types of network elements.

[0021] [Figure 8] FIG. 8 is a diagram showing an example of NSI and NSSI.

[0022] [Figure 9] FIG. 9 is a diagram showing an example of the onboarding screen.

[0023] [Figure 10] FIG. 10 is a functional block diagram showing an example of functions implemented in the MPS and NOS according to an embodiment of the present invention.

[0024] [Figure 11] FIG. 11 is a diagram showing an example of the data structure of a data group generated based on a bundle file.

[0025] [Figure 12] FIG. 12 is a diagram illustrating an example of a data structure of the physical inventory data.

[0026] [Figure 13] FIG. 13 is a diagram illustrating an example of a data structure of logical inventory data.

[0027] [Figure 14] FIG. 14 is a diagram showing an example of the resource management data.

[0028] [Figure 15] FIG. 15 is a diagram illustrating an example of a data structure of the plan data.

[0029] [Figure 16] FIG. 16 is a diagram illustrating an example of the plan data.

[0030] [Figure 17] FIG. 17 is a diagram showing an example of the expected busy level data.

[0031] [Figure 18] FIG. 18 is a diagram showing an example of the resource management data.

[0032] [Figure 19] FIG. 19 is a diagram showing an example of a CNFD.

[0033] [Figure 20] FIG. 20 is a diagram showing an example of the day0 parameters.

[0034] [Figure 21] Figure 21 shows a schematic of the process of constructing NSI and NSSI.

[0035] [Figure 22A] FIG. 22A is a flow diagram showing an example of the flow of processes performed in the vendor terminal, MPS, and NOS according to an embodiment of the present invention.

[0036] [Figure 22B] FIG. 22B is a flow diagram showing an example of the flow of processes performed in the vendor terminal, MPS, and NOS according to an embodiment of the present invention.

[0037] [Diagram 23] FIG. 23 is a flow diagram showing an example of the flow of processing performed in the purchaser terminal, MPS, and NOS according to an embodiment of the present invention.

[0038] [Figure 24] FIG. 24 is a flow diagram showing an example of the flow of processing performed in the purchaser terminal, MPS, and NOS according to an embodiment of the present invention.

[0039] [Figure 25A] FIG. 25A is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0040] [Figure 25B] FIG. 25B is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0041] [Figure 25C]FIG. 25C is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0042] [Figure 25D] FIG. 25D is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0043] [Figure 25E] FIG. 25E is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0044] [Figure 25F] FIG. 25F is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0045] [Figure 25G] FIG. 25G is a flow diagram showing an example of the flow of processing performed in the NOS according to one embodiment of the present invention.

[0046] [Figure 26] FIG. 26 is a diagram showing a schematic diagram of cooperation between a plurality of functional blocks of the NOS according to the second embodiment.

[0047] [Figure 27] FIG. 27 is a diagram showing an example of network hierarchical data relating to a certain purchaser. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0048] (First Example) 1 is a diagram showing a computer system 1 according to a first embodiment. The computer system 1 is an information processing system that performs data processing relating to the construction and management of network services.

[0049] 1, in the computer system 1 of the first embodiment, a marketplace system (MPS) 10, a network operating system (NOS) 12, a purchaser terminal 14, a vendor terminal 16, a plurality of core network systems 20, and a plurality of base station devices 22 are connected to a computer network 24 such as the Internet. The core network system 20, the base station devices 22, and the computer network 24 cooperate with each other to realize a mobile wireless communication network.

[0050] The core network system 20 is a system equivalent to an EPC (Evolved Packet Core) in a fourth generation mobile communication system (hereinafter referred to as 4G) and a 5GC (5G Core Network) including an AMF (Access and Mobility Management Function), an SMF (Session Management Function), and a UPF (User Plane Function) in a fifth generation mobile communication system (hereinafter referred to as 5G). The core network system 20 according to this embodiment is implemented by a group of servers arranged in a plurality of data centers provided in various locations. A plurality of servers are arranged in each data center. Although two core network systems 20 are shown in FIG. 1, the number of core network systems 20 according to this embodiment is not limited to two, and may be one or three or more.

[0051] The base station device 22 is a computer system equipped with an antenna 22a, which corresponds to an eNB (eNodeB) in 4G or a gNB (NR base station) in 5G. The base station device 22 according to this embodiment includes one or more servers (a server 90 described later). The base station device 22 may be implemented by a group of servers arranged in a data center.

[0052] In addition, a virtual distributed unit (vDU) and a virtual central unit (vCU), which are components of a radio access network (RAN) in 4G, may be disposed in a base station device 22 or may be incorporated into a part of the core network system 20. Similarly, a DU and a CU, which are components of a RAN in 5G, may be disposed in a base station device 22 or may be incorporated into a part of the core network system 20.

[0053] The MPS 10 according to the present embodiment is configured on, for example, a cloud platform, and includes a processor 10a, a storage unit 10b, and a communication unit 10c, as shown in FIG. 1. The processor 10a is a program-controlled device such as a microprocessor that operates according to a program installed in the MPS 10. The storage unit 10b is, for example, a storage element such as a ROM or RAM, a solid-state drive (SSD), or a hard disk drive (HDD). The storage unit 10b stores programs executed by the processor 10a, etc. The communication unit 10c is, for example, a communication interface such as a NIC (Network Interface Card) or a wireless LAN module. The communication unit 10c transmits and receives data to and from the NOS 12 and the purchaser terminal 14 via the computer network 24.

[0054] The NOS 12 according to the present embodiment is configured on a cloud platform, for example, and includes a processor 12a, a storage unit 12b, and a communication unit 12c, as shown in FIG. 1. The processor 12a is a program-controlled device such as a microprocessor that operates according to a program installed in the NOS 12. The storage unit 12b is, for example, a storage element such as a ROM or RAM, a solid-state drive (SSD), or a hard disk drive (HDD). The storage unit 12b stores programs executed by the processor 12a, etc. The communication unit 12c is, for example, a communication interface such as a NIC or a wireless LAN module. The communication unit 12c transmits and receives data between the MPS 10, the purchaser terminal 14, the vendor terminal 16, the core network system 20, and the base station device 22 via the computer network 24.

[0055] In this embodiment, in response to a purchase request for a network service by a purchaser, the requested network service is established in the core network system 20 and the base station device 22. Then, the established network service is provided to the purchaser.

[0056] For example, a purchaser, which is an MVNO (Mobile Virtual Network Operator), is provided with network services such as voice communication services and data communication services. The voice communication services and data communication services provided by this embodiment are ultimately provided to a customer (end user) of the purchaser (MVNO in the above example) who uses UE (User Equipment) 26 shown in FIG. 1. The end user can perform voice communication and data communication with other users via the core network system 20 and the base station device 22.

[0057] In addition, the network service provided in this embodiment is not limited to a voice communication service or a data communication service. The network service provided in this embodiment may be, for example, an IoT service. And, for example, an end user who uses a robot arm or a connected car may be a purchaser of the network service according to this embodiment.

[0058] In this embodiment, a container-type application execution environment such as Docker is installed on the servers arranged in the core network system 20 and the base station device 22, and containers can be deployed and operated on these servers. In this embodiment, the network service provided to the purchaser is implemented by a CNF (Cloud-native Network Function), which is a container-based functional unit.

[0059] The purchaser terminal 14 according to this embodiment is, for example, a general computer such as a smartphone, a tablet terminal, or a personal computer used by the purchaser described above.

[0060] Fig. 2 is a diagram showing an example of a purchase screen displayed on the purchaser terminal 14 according to this embodiment. On the purchase screen shown in Fig. 2, the purchaser can select the type of network service to be purchased using radio buttons. Here, when the purchaser specifies a voice communication service and clicks the next button 30, the service requirement input screen shown in Fig. 3 is displayed on the purchaser terminal 14.

[0061] The service requirement input screen allows the purchaser to input the service requirements for the network service to be purchased. In the example in Figure 3, the number of subscribers, opposing IP, monitoring target, monitoring interval, target area, and password can be set. The opposing IP refers to the IP address that serves as the access point to the network system that the purchaser already owns.

[0062] When the purchaser inputs these service requirements and clicks the Next button 32, the service requirement data associated with the input to the service requirement input screen is transmitted to the MPS 10.

[0063] The service requirement data includes, for example, subscriber number data indicating the number of subscribers, opposing IP data indicating opposing IPs, monitoring target data indicating monitoring targets, monitoring interval data indicating monitoring intervals of the monitoring targets, target area data indicating target areas of the network service to be purchased, and password data indicating passwords. Note that the service requirement data does not need to include all of these data, and may also include data indicating requirements other than these.

[0064] Then, the MPS 10, in cooperation with the NOS 12, checks whether or not it is possible to secure a server that satisfies the service requirements indicated by the service requirement data, based on the service requirement data. Here, for example, it is determined whether (1) it is possible to secure a server that satisfies the service requirements, (2) it is possible to secure a server that satisfies the service requirements by setting up an available server, or (3) it is impossible to secure a server that satisfies the service requirements.

[0065] If the result of the determination is (1) or (2), the purchaser terminal 14 displays a purchase confirmation screen, as shown in Fig. 4, indicating that immediate provision is possible. If the result of the determination is (3), the purchaser terminal 14 displays a purchase confirmation screen, as shown in Fig. 5, indicating that a certain delivery time is required (for example, a delivery time of two weeks is required).

[0066] When the purchaser clicks the purchase button 34 shown in FIG. 4 or FIG. 5, the network service requested for purchase is constructed and provided to the purchaser.

[0067] On the other hand, if the purchaser clicks the cancel button 36 shown in FIG. 4 or 5, the purchase is cancelled.

[0068] As described above, according to this embodiment, network services can be flexibly constructed according to various needs of purchasers. Purchasers can receive desired network services by simply specifying some service requirements, without being aware of the detailed implementation of the network service.

[0069] The vendor terminal 16 according to this embodiment is a general computer such as a smartphone, a tablet terminal, or a personal computer that is used by a vendor such as a service provider related to network services.

[0070] In this embodiment, a CI (Continuous Integration) / CD (Continuous Delivery) pipeline including a development environment, a verification environment, and a test environment is provided to the vendor. In this embodiment, a verified bundle file corresponding to a network service to be provided to a purchaser, which is created by the vendor, is onboarded by an onboarding process using the CI / CD pipeline.

[0071] The bundle file according to this embodiment is, for example, a file (for example, a file in targz format) obtained by compressing a group of files in a predetermined directory structure.

[0072] Fig. 6 is a diagram showing an example of a data structure of a bundle file according to this embodiment. As shown in Fig. 6, the bundle file according to this embodiment includes business section data, technology section data, security section data, and operation section data.

[0073] The business section data indicates business requirements of the network service, such as the name of the network service, license requirements, definition of a service level agreement (SLA), etc. In addition, the business section data according to the present embodiment includes data indicating required input items and optional input items for the service requirements of the network service.

[0074] The technology section data indicates, for example, the configuration of a group of functional units that realize a network service, and also indicates, for example, the configuration of an application or CNFC that constitutes the network service.

[0075] The technology section data also shows, for example, a hierarchical structure of a network service (hereinafter also referred to as "NS"), a network function (hereinafter also referred to as "CNF" (Cloud-native Network Function)) and a Cloud-native Network Function Component (CNFC) associated with the network service. The technology section data also shows, for example, a hierarchical structure of a network service, a network slice subnet (hereinafter also referred to as "NSSI") and a network slice (hereinafter also referred to as "NSI") associated with the network service. In other words, the technology section data shows the hierarchical structure of multiple types of network elements, in other words, the correspondence relationship.

[0076] Figure 7 shows the hierarchical structure of multiple types of network elements. NSI and NSSI have a one-to-many relationship, and NSSI and NS have a many-to-many relationship. NS and CNF have a one-to-many relationship, and CNF and CNFC also have a one-to-many relationship. Data showing the hierarchical structure of multiple types of network elements is also referred to as "network hierarchy data" below. Network hierarchy data includes data showing the correspondence between one or more NSIs and multiple NSSIs, data showing the correspondence between multiple NSSIs and multiple NSs, data showing the correspondence between multiple NSs and multiple CNFs, and data showing the correspondence between multiple CNFs and multiple CNFCs.

[0077] Figure 8 shows examples of NSI and NSSI. NSI can be considered as an end-to-end virtual circuit across multiple domains (e.g., from RAN to core network). NSI can be a slice for high-speed, large-capacity communication, a slice for high-reliability and low-latency communication, or a slice for connecting a large number of terminals. NSSI can be considered as a virtual circuit of a single domain obtained by dividing NSI. NSSI can be a slice of RAN domain, a slice of MBH (Mobile Back Haul) domain, or a slice of core network domain. Also, as shown in Figure 8, multiple NSIs may share the same NSSI.

[0078] The NS may be a 5G core network (5GC), a 4G core network (EPC), a 5G RAN, or a 4G RAN. The CNF may be multiple types of network functions in the 5G core network, such as an AMF, an SMF, or an UPF. The CNF may also be multiple types of network functions in the 4G core network, such as a Mobility Management Entity (MME), a Home Subscriber Server (HSS), or a Serving Gateway (S-GW).

[0079] A CNFC may be a microservice deployed as one or more containers on a server. For example, one CNFC may be a microservice providing some of the functions of an eNodeB (i.e., an LTE base station) or a gNB (i.e., a 5G base station). Another CNFC may be a microservice providing some of the functions of a core network function such as an AMF or an MME.

[0080] Returning to FIG. 6, the security section data indicates the security definitions for the network service, such as installation credentials.

[0081] The operation section data indicates a monitoring policy for the network service, such as the metrics to be monitored and the monitoring interval.

[0082] 9 is a diagram showing an example of an onboarding screen displayed on the vendor terminal 16 according to this embodiment. In this embodiment, when the vendor specifies the path where the bundle file is located and then clicks the onboarding button 40, the bundle file is onboarded.

[0083] As described above, in this embodiment, the vendor can easily onboard a network service without being aware of the actual location where the developed files are onboarded.

[0084] The functions of the MPS 10 and NOS 12 according to this embodiment and the processes executed by the MPS 10 and NOS 12 will be further described below.

[0085] FIG. 10 is a functional block diagram showing an example of functions implemented in the MPS 10 and NOS 12 according to this embodiment. The multiple functional blocks shown in the block diagram in this specification can be configured in hardware with circuit blocks, memory, and other LSIs, and in software, are realized by a CPU executing a program loaded in a memory. Therefore, it is understood by those skilled in the art that these functional blocks can be realized in various forms by hardware alone, software alone, or a combination thereof. Note that it is not necessary for the MPS 10 and NOS 12 according to this embodiment to implement all of the functions shown in FIG. 10, and functions other than the functions shown in FIG. 10 may be implemented.

[0086] As shown in FIG. 10, the MPS 10 functionally includes, for example, a bundle management unit 50, a product catalog storage unit 52, and a purchase management unit .

[0087] The bundle management unit 50 and the purchase management unit 54 are implemented mainly using the processor 10a and the communication unit 10c. The product catalog storage unit 52 is implemented mainly using the storage unit 10b.

[0088] The above functions may be implemented by executing a program including instructions corresponding to the above functions on the processor 10a, which is installed in the computer MPS 10. This program may be supplied to the MPS 10 via a computer-readable information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or via the Internet, for example.

[0089] Also, as shown in FIG. 10, NOS 12 functionally includes, for example, a bundle deployment unit 60, an orchestration (E2EO: End-to-End-Orchestration) unit 62, a service catalog memory unit 64, an inventory management unit 66, a CMaaS (Configuration Management as a Service) unit 68, a service manager unit 70, a slice manager unit 72, a monitoring management unit 74, a security setting unit 76, a plurality of container management units 78, a repository unit 80, an inventory database 82, and a BMaaS (Bare Metal as a Service) unit 84.

[0090] The bundle expanding unit 60 and the E2EO unit 62 are implemented mainly using the processor 12a and the communication unit 12c. The service catalog storage unit 64, the repository unit 80, and the inventory database 82 are implemented mainly using the storage unit 12b. The inventory management unit 66, the CMaaS unit 68, the service manager unit 70, the slice manager unit 72, the monitoring management unit 74, the security setting unit 76, and the container management unit 78 are implemented mainly using the processor 12a and the storage unit 12b. The BMaaS unit 84 is implemented mainly using the processor 12a.

[0091] The above functions may be implemented by executing a program including instructions corresponding to the above functions on the processor 12a, which is installed in the computer NOS 12. This program may be supplied to the NOS 12 via a computer-readable information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or via the Internet, for example.

[0092] Fig. 10 also shows a plurality of servers 90 distributed at various locations included in the core network system 20 and the base station device 22 shown in Fig. 1. The plurality of container management units 78 according to this embodiment are each associated with a server group that is a part of the plurality of servers 90.

[0093] A container management tool such as Kubernetes and a package manager such as Helm are installed in each of the multiple container management units 78 according to this embodiment. Then, the container management unit 78 executes life cycle management of the container, including construction of the container such as deployment and configuration of the container for a server group (multiple servers 90) associated with the container management unit 78.

[0094] It should be noted that the container management unit 78 does not need to be included in the NOS 12. The container management unit 78 may be provided, for example, in a server 90 (i.e., the core network system 20 or the base station device 22) managed by the container management unit 78, or in a server provided alongside the server 90.

[0095] In this embodiment, for example, the bundle expansion unit 60 receives a bundle file from the vendor terminal 16. Then, in this embodiment, for example, the bundle expansion unit 60 generates a data group having the data structure shown in Fig. 11 based on the received bundle file. The data group shown in Fig. 11 is a reconstructed version of the contents of the bundle file received by the bundle expansion unit 60.

[0096] As shown in FIG. 11, the data group generated by the bundle expansion unit 60 includes product catalog data, service catalog data, inventory template data, CM template data, service template data, slice template data, monitoring script data, security script data, Helm chart data, and container image data.

[0097] The product catalog data is, for example, data corresponding to the business section data included in the bundle file. As described above, the product catalog data indicates information on the business requirements of the network service, such as the name of the network service displayed on the purchase screen shown in FIG. 2, the license requirements, and the definition of the service level agreement (SLA).

[0098] Furthermore, the product catalog data according to this embodiment includes data indicating required input items and optional input items for the service requirements of the network service. In this embodiment, for example, a purchase screen shown in Fig. 2 and a service requirements input screen shown in Fig. 3 are generated based on the product catalog data.

[0099] The service catalog data corresponds to, for example, a part of the technology section data included in the bundle file, and includes a workflow script for constructing a network service.

[0100] The service catalog data may also include requirement configuration correspondence data indicating the correspondence between the values ​​of the above-mentioned service requirement data and the configuration of a functional unit group (for example, a CNF group) constructed in response to a purchase request.

[0101] For example, the service catalog data may include requirement configuration correspondence data indicating the correspondence between the value of the service requirement data, the type of functional unit group, and the number of functional units for each type. For example, the requirement configuration correspondence data may indicate that "20,000 subscribers and one P-GW (Packet Data Network Gateway)", "20,000 subscribers and one IMS (IP Multimedia System)", and "20,000 subscribers and one HSS (Home Subscriber Server)" correspond to each other. Note that the correspondence between the service requirement data and the type and number of 4G components is not limited, and the service requirement data and the type and number of 5G components may also be associated with each other.

[0102] Also, for example, the requirement configuration correspondence data may indicate the correspondence between the value of the service requirement data and the location where each functional unit included in the functional unit group to be constructed in response to the purchase request is constructed. In this case, the location associated with the value of the service requirement data in the requirement configuration correspondence data may differ depending on the functional unit included in the functional unit group to be constructed.

[0103] The inventory template data is, for example, data corresponding to a part of the technology section data and a part of the security section data included in the bundle file. The inventory template data is, for example, template data indicating logic used by the inventory management unit 66.

[0104] The CM template data is, for example, data corresponding to a part of the technology section data and a part of the operation section data included in the bundle file, and is, for example, template data indicating the logic used by the CMaaS unit 68.

[0105] The service template data is, for example, data corresponding to a part of the technology section data included in the bundle file, and is, for example, template data indicating the logic used by the service manager unit 70. The service template data includes information necessary for the service manager unit 70 to construct a network service. Specifically, the service template data includes, from the network hierarchy data shown in Fig. 7, information defining at least the NS, CNF, and CNFC to be constructed by the service manager unit 70, and information indicating the correspondence between NS, CNF, and CNFC.

[0106] The slice template data is, for example, data corresponding to a part of the technology section data included in the bundle file, and is, for example, template data indicating the logic used by the slice manager unit 72.

[0107] The slice template data includes information on the "Generic Network Slice Template" defined by the GSM Association (GSMA) ("GSM" is a registered trademark). Specifically, the slice template data includes network slice template data (NST), network slice subnet template data (NSST), and network service template data, and also includes information indicating the hierarchical configuration of these network elements (e.g., the above-mentioned network hierarchy data). The NST and NSST include information on SLAs related to network slice instances (NSIs) and network slice subnet instances (NSSIs).

[0108] The above SLA information includes one or more KPIs (Key Performance Indicators) related to NSI and NSSI based on the metric data of the monitored object, and the calculation logic for calculating each KPI. The SLA information also includes information on the threshold used during monitoring and the threshold to be compared with the calculated KPI (e.g., the threshold for detecting anomalies).

[0109] The monitoring script data is, for example, data corresponding to a part of the operation section data included in the bundle file, and is, for example, data indicating the monitoring script to be executed by the monitoring management unit 74.

[0110] The security script data is, for example, data corresponding to a part of the security section data included in the bundle file, and is, for example, data indicating a script relating to security executed by the security setting unit 76.

[0111] The Helm chart data is, for example, data corresponding to a part of the operation section data included in the bundle file, and is data indicating a script template (Helm chart) used by the container management unit 78.

[0112] The container image data is, for example, data corresponding to a part of the operation section data included in the bundle file, and is, for example, data of a container image for a container included in a group of functional units that realize a network service. The container image data includes one or more container images. Each of the one or more container images is associated with a container image ID that is an identifier of the container image.

[0113] In this embodiment, in response to receiving a bundle file, the bundle expansion unit 60 determines a bundle ID corresponding to a data group generated based on the bundle file. A bundle ID is assigned uniquely to each data group generated.

[0114] Then, the bundle expansion unit 60 transmits to the MPS 10 the product catalog data included in the data group corresponding to the bundle ID, after associating the product catalog data with the determined bundle ID.

[0115] Furthermore, the bundle expanding unit 60 associates the service catalog data included in the data group with the determined bundle ID and outputs the associated data to the E2EO unit 62. The E2EO unit 62 then stores the service catalog data in the service catalog storage unit 64.

[0116] In addition, the bundle expansion unit 60 associates the inventory template data, CM template data, service template data, slice template data, monitoring script data, security script data, Helm chart data, and container image data with the bundle IDs corresponding to the data groups, and stores them in the inventory management unit 66, the CMaaS unit 68, the service manager unit 70, the slice manager unit 72, the monitoring management unit 74, the security setting unit 76, the container management unit 78, and the repository unit 80, respectively.

[0117] In this way, in this embodiment, the product catalog data, service catalog data, inventory template data, CM template data, service template data, slice template data, monitoring script data, security script data, Helm chart data, and container image data are associated with each other by the bundle ID.

[0118] Furthermore, in this embodiment, the vendor can easily provide a network service by performing a simple operation such as specifying the path of a bundle file.

[0119] In this embodiment, for example, the bundle management unit 50 receives product catalog data associated with the bundle ID transmitted from the bundle expansion unit 60. Then, the bundle management unit 50 stores the received product catalog data in the product catalog storage unit 52.

[0120] In this embodiment, the product catalog storage unit 52 stores, for example, product catalog data associated with bundle IDs as described above.

[0121] In this embodiment, for example, the purchase management unit 54 receives a network service construction request, such as a network service purchase request associated with a bundle ID and service requirement data, from the purchaser terminal 14. Hereinafter, the bundle ID associated with the purchase request will be referred to as a purchased bundle ID, and the service requirement data associated with the purchase request will be referred to as purchased service requirement data.

[0122] Then, in response to the reception of the above-mentioned purchase request, the purchase management unit 54 transmits the purchased service requirement data associated with the purchased bundle ID to the E2EO unit 62 .

[0123] Furthermore, the purchase management unit 54, in cooperation with the E2EO unit 62 and the inventory management unit 66, identifies the delivery date of the network service to be purchased by the purchaser. Then, the purchase management unit 54 notifies the purchaser of the identified delivery date. For example, the purchase management unit 54 generates a purchase confirmation screen indicating the identified delivery date, and transmits the generated purchase confirmation screen to the purchaser terminal 14.

[0124] In this embodiment, the inventory database 82 is, for example, a database that stores inventory information about a plurality of servers 90 arranged in the core network system 20 and the base station device 22, which is managed by the NOS 12.

[0125] In this embodiment, for example, the inventory database 82 stores inventory data including the physical inventory data shown in Fig. 12 and the logical inventory data shown in Fig. 13. The inventory data indicates the status of resources managed by the NOS 12 (for example, the usage status of the resources).

[0126] Fig. 12 is a diagram showing an example of a data structure of physical inventory data. The physical inventory data shown in Fig. 12 is associated with one server 90. The physical inventory data shown in Fig. 12 includes, for example, a server ID, location data, building data, floor data, rack data, an assigned resource pool group ID, an assigned resource pool ID, spec data, network data, an operating container ID list, and the like.

[0127] The server ID included in the physical inventory data is, for example, an identifier of the server 90 associated with the physical inventory data.

[0128] The location data included in the physical inventory data is, for example, data indicating the location (for example, the address of the location) of the server 90 associated with the physical inventory data.

[0129] The building data included in the physical inventory data is, for example, data indicating the building (for example, the building name) in which the server 90 associated with the physical inventory data is located.

[0130] The floor number data included in the physical inventory data is, for example, data indicating the floor number on which the server 90 associated with the physical inventory data is located.

[0131] The rack data included in the physical inventory data is, for example, an identifier of a rack in which the server 90 associated with the physical inventory data is located.

[0132] The allocated resource pool group ID included in the physical inventory data is, for example, an identifier of a resource pool group to which the server 90 associated with the physical inventory data is allocated.

[0133] The assigned resource pool ID included in the physical inventory data is, for example, an identifier of a resource pool to which the server 90 associated with the physical inventory data is assigned. The resource pool indicated by the assigned resource pool ID is any one of the resource pools included in the resource pool group corresponding to the assigned resource pool group ID. In this embodiment, a free server is assigned to any one of the resource pool groups, but it is not yet determined which resource pool included in the resource pool group the free server will be assigned to. For such free servers, Null is set as the value of the assigned resource pool ID included in the corresponding physical inventory data.

[0134] The specification data included in the physical inventory data is data indicating the specifications of the server 90 associated with the physical inventory data, such as the number of cores, memory capacity, and hard disk capacity of the server 90.

[0135] The network data included in the physical inventory data is, for example, data indicating the NICs provided in the server 90 associated with the physical inventory data, the number of ports provided in the NICs, and the like.

[0136] The operating container ID list included in the physical inventory data is, for example, data indicating a list of identifiers (container IDs) of one or more container instances operating on the server 90 associated with the physical inventory data.

[0137] Fig. 13 is a diagram illustrating an example of a data structure of logical inventory data. As illustrated in Fig. 13, the logical inventory data includes NS (Network Service) data, CNF (Cloud-native Network Function) data, CNFC data, pod data, and container data.

[0138] The NS data is data indicating attributes such as an identifier of an instance of a network service corresponding to a virtual RAN (vRAN) or the like, and the type of the network service. The CNF data is data indicating attributes such as an identifier of an instance of a network function corresponding to an eNodeB or the like, and the type of the network function. The CNF data may be data in units of a vCU or vDU constituting an eNodeB. The CNFC data is data indicating attributes such as an identifier of an instance of a CNFC or the type of the CNFC. The pod data is data indicating attributes such as an identifier of an instance of a pod included in the CNFC or the type of the pod. Here, a pod refers to the smallest unit for managing a Docker container in Kubernetes. The container data is data indicating attributes such as a container ID of an instance of a container included in a pod or the type of the container.

[0139] In addition, data indicating attributes such as a host name and an IP address may be set in the above data included in the logical inventory data. For example, the container data may include data indicating an IP address of a container corresponding to the container data. Also, for example, the CNFC data may include data indicating an IP address and a host name of a CNFC indicated by the CNFC data.

[0140] The above data has a hierarchical structure, and the NS data is associated with one or more CNF data corresponding to one or more network functions included in the network service corresponding to the NS data. The CNF data is associated with one or more CNFC data corresponding to one or more CNFCs included in the network function corresponding to the CNF data. The CNFC data is associated with one or more pod data corresponding to one or more pods included in the CNFC corresponding to the CNFC data. The pod data is associated with one or more container data corresponding to one or more containers included in the pod corresponding to the pod data.

[0141] The container instance is associated with the server 90 on which the container instance is running by the container ID of the container data included in the logical inventory data and the container ID included in the operating container ID list included in the physical inventory data.

[0142] In this embodiment, the network service purchased by the purchaser (the network service associated with the product catalog data) does not have to correspond to the network service associated with the NS data. For example, the network service purchased by the purchaser may be realized by a functional unit group corresponding to a network function associated with one or more CNF data, or may be realized by a functional unit group associated with one or more CNFC data. In addition, the network service purchased by the purchaser may be realized by a functional unit group associated with one or more pods, or may be realized by a functional unit group associated with one or more containers.

[0143] As shown in FIG. 13, the logical inventory data according to this embodiment includes a plurality of resource pool management data each associated with a resource pool group.

[0144] 14 is a diagram showing an example of resource pool management data according to this embodiment. The resource pool management data indicates the statuses of a plurality of resource pools included in a resource pool group associated with the resource pool management data.

[0145] The resource pool management data illustrated in FIG. 14 includes a resource pool group ID, a plurality of resource pool data, and data on the number of available servers.

[0146] The resource pool group ID included in the resource pool management data is an identifier of a resource pool group associated with the resource pool management data.

[0147] The number of available servers data included in the resource pool management data is data indicating the number of available servers allocated to the resource pool group associated with the resource pool management data.

[0148] The resource pool data is data that indicates the status of a resource pool included in a resource pool group associated with the resource pool management data.

[0149] As shown in FIG. 14, the resource pool data includes a resource pool ID, data on the total number of cores, data on the number of remaining cores, and CNF type data.

[0150] The resource pool ID is an identifier for the resource pool.

[0151] The total core count data is data indicating the total number of cores of the servers 90 allocated to the resource pool. The total core count data is one specific example of total resource amount data indicating the total amount of hardware resources included in the resource pool.

[0152] The remaining core number data is data indicating the remaining number of cores of the server 90 assigned to the resource pool. The remaining core number data is one specific example of resource remaining amount data indicating the remaining amount of hardware resources included in the resource pool.

[0153] The CNF type data is data indicating one or more types of CNFs associated with the resource pool. The CNF type data is a specific example of functional unit type data indicating one or more types of functional units associated with the resource pool.

[0154] In this embodiment, a resource pool group that spans multiple locations may be set in advance, or a resource pool group that is associated with only one location may be set in advance. In either case, the resource pool group is associated with one or more locations indicated in the physical inventory data.

[0155] The inventory management unit 66 is also able to grasp the resource status as needed in cooperation with the container management unit 78. The inventory management unit 66 then updates the inventory data stored in the inventory database 82 as needed based on the latest resource status.

[0156] In this embodiment, the E2EO unit 62 and the inventory management unit 66 specify the configuration of functional units that realize the network service to be purchased, based on the service requirement data received from the purchase management unit 54, for example.

[0157] Here, the E2EO unit 62 acquires, for example, service catalog data corresponding to the purchase bundle ID associated with the purchased service requirement data received from the purchase management unit 54 from the service catalog storage unit 64. Then, the E2EO unit 62 executes a script of the workflow indicated by the service catalog data.

[0158] The E2E-O unit 62 and the inventory management unit 66 generate planned data, as shown in Fig. 15 and Fig. 16, based on the purchased service requirement data received from the purchase management unit 54, the service catalog data associated with the purchased bundle ID, the inventory template data associated with the purchased bundle ID, and the inventory data. The planned data is, for example, data indicating the configuration of a group of functional units that realizes the network service to be purchased. This process is executed, for example, when the E2E-O unit 62 executes a workflow script as a trigger.

[0159] FIG. 15 is a diagram showing an example of a data structure of planning data according to this embodiment. FIG. 16 is a diagram showing a schematic example of planning data according to this embodiment. Planning data according to this embodiment includes an inventory key that is an identifier of the planning data. The inventory key is uniquely assigned to the planning data when the planning data is generated. The planning data also includes a purchase bundle ID ("0010" in the example of FIG. 16). The planning data also includes a user ID that is an identifier of the purchaser (user) who made the purchase request.

[0160] The plan data may also include values ​​set in the purchased service requirement data. The plan data shown in Fig. 15 and Fig. 16 includes values ​​of opposing IP data, monitoring target data, monitoring interval data, and password data, which are included in the purchased service requirement data.

[0161] In this embodiment, the plan data includes functional unit configuration data for each of the functional units included in the functional unit group that realizes the purchased network service. The functional unit configuration data includes, for example, CNFC type data indicating the type of the functional unit, host name data indicating the host name, IP address data indicating the IP address, and multiple container configuration data respectively associated with the containers that configure the functional unit.

[0162] Here, for example, the E2EO unit 62 may specify the number of functional units to be constructed based on the purchased service requirement data. For example, the E2EO unit 62 may specify the type of functional units that realize the purchased network service and the number of functional units for each type based on the purchased service requirement data and the requirement configuration correspondence data included in the service catalog data. For example, when the number of subscribers indicated by the service requirement data is 50,000, the functional units to be constructed may be specified to be three P-GWs, three IMSs, and three HSSs based on the above-mentioned requirement configuration correspondence data.

[0163] The E2EO unit 62 may then output data indicating the types of functional unit groups and the number of functional units for each type to the inventory management unit 66 together with the service requirement data. The inventory management unit 66 may then determine a host name and an IP address to be assigned to each functional unit based on the data and the inventory data. Here, for example, the host name and the IP address may be determined so as not to overlap with host names and IP addresses already in use. Then, planning data may be generated that includes host name data indicating the host name determined in this manner and IP address data indicating the IP address determined.

[0164] Also, as described above, the E2EO unit 62 may specify the location where each of the functional units included in the functional unit group to be constructed is to be constructed based on the purchased service requirement data. For example, the E2EO unit 62 may determine the location of each functional unit included in the functional unit group to be constructed based on the target area data included in the purchased service requirement data and the requirement configuration correspondence data included in the service catalog data. Here, a different location may be determined for each functional unit. Then, for each functional unit, a host name or an IP address available in the location determined for the functional unit may be determined as the host name and IP address of the functional unit. Then, planning data including host name data indicating the host name determined in this manner and IP address data indicating the determined IP address may be generated.

[0165] The E2EO unit 62 may also specify the type and number of functional units to be constructed at each of a plurality of locations based on the purchased service requirement data. In this case, the E2EO unit 62 may determine the number of each type of functional unit to be constructed at the location according to the location specified based on the purchased service requirement data. The E2EO unit 62 may also determine the number of each type of functional unit to be constructed at each location based on the weight set for each location specified based on the purchased service requirement data.

[0166] For example, the E2EO unit 62 may store the expected busy level data shown in Fig. 17. The expected busy level data shown in Fig. 17 indicates, for example, the population of an area covered by one or more cells under a data center associated with the expected busy level data. The value of the expected busy level data is an example of the weight set for each location described above.

[0167] Here, the expected busy level data for a data center of the core network system 20 indicates, for example, the population of an area covered by cells of one or more base station devices 22 that communicate with the core network system 20.

[0168] For example, the more the population of a location indicated by the expected busy level data, the more functional units may be deployed. For example, the total number n of vDUs to be deployed is specified based on the subscriber count data included in the purchased service requirement data. Then, based on the target area data included in the purchased service requirement data, a plurality of data centers in which the vDUs are to be deployed are specified within the target area indicated by the target area data. In this case, the number of vDUs that is a proportionate portion of the total number n of vDUs specified may be deployed in each data center based on the value of the expected busy level data for each specified data center.

[0169] As shown in FIG. 15, the container configuration data includes, for example, a container ID, a container image ID, necessary resource data, a resource pool group ID, a resource pool ID, and a connected container ID list.

[0170] The container ID is, for example, as described above, an identifier that is uniquely assigned to an instance of a container corresponding to the container configuration data.

[0171] The container image ID included in the container configuration data is set to, for example, the container image ID assigned to the container image of the container corresponding to the container configuration data.

[0172] The required resource data is, for example, data indicating resources required for the operation of the container. In this embodiment, for example, the inventory template data indicates, for each container, the resources required for the operation of the container. The inventory management unit 66 sets the value of the required resource data based on the inventory template data.

[0173] The resource pool group ID included in the container configuration data is set to, for example, the value of the resource pool group ID of the resource pool group to which the container corresponding to the container configuration data is assigned. The inventory management unit 66 may determine the resource pool group ID in which the container is constructed based on, for example, the location determined as described above and the inventory data.

[0174] The resource pool ID included in the container configuration data is set to, for example, the value of the resource pool ID of the resource pool to which the container corresponding to the container configuration data is assigned. The inventory management unit 66 may determine the resource pool ID based on, for example, the type of the container and the resource pool management data.

[0175] The connected container ID list is a list of container IDs of containers connected to the container. In this embodiment, for example, the inventory template data indicates, for each container, the type of container connected to the container. The inventory management unit 66 determines the value of the connected container ID list based on, for example, the inventory template data and the inventory data.

[0176] When generating the planning data, the E2EO unit 62, in cooperation with the inventory management unit 66, identifies a resource pool in which the new functional unit group is to be deployed and necessary resources. Here, the E2EO unit 62 may identify a resource pool associated with a functional unit identified in response to reception of a network service construction request, such as reception of a purchase request. The E2EO unit 62 may also identify a resource pool group based on a target area of ​​the network service to be purchased. For example, the resource pool group may be identified based on a target area indicated by target area data included in the purchase service requirement data. Then, the E2EO unit 62 may identify a resource pool in which the new functional unit group is to be deployed from among the resource pools included in the identified resource pool group.

[0177] The E2EO unit 62 also determines whether or not a hardware resource (here, for example, a server 90) on which a new group of functional units is deployed can be secured. For example, it is determined whether (1) the server 90 can be secured, (2) the server 90 can be secured by setting up an unused hardware resource (here, for example, a free server) that is not included in any resource pool, or (3) the server 90 cannot be secured.

[0178] Here, in the case of (2), the E2EO unit 62 determines whether or not a predetermined specific type of functional unit is to be deployed to an unused hardware resource (here, for example, an empty server).

[0179] When a specific type of functional unit is deployed, the E2EO unit 62 identifies a resource pool associated with the specific type of functional unit. Here, for example, the resource pool is identified based on resource pool management data.

[0180] In this embodiment, for example, the resource pool group ID of the resource pool group identified as above and the resource pool ID of the identified resource pool are set in the container configuration data.

[0181] In this embodiment, the CMaaS unit 68, the service manager unit 70, and the slice manager unit 72 specify a construction procedure for the functional unit group based on, for example, the configuration of the functional unit group specified as described above and template data that can accept the configuration as a parameter. The construction procedure includes, for example, a procedure for managing the configuration of the container, such as deploying a container and setting the deployed container and containers related to the container. This process is executed, for example, when the E2EO unit 62 executes a workflow script as a trigger.

[0182] Then, the CMaaS unit 68, the service manager unit 70, the slice manager unit 72, and the container management unit 78 execute the identified construction procedure to construct a functional unit group. This process is also executed, for example, in response to the execution of a workflow script by the E2EO unit 62.

[0183] Each of the functional units included in the functional unit group may be constructed in a location specified for that functional unit.

[0184] Also for example, a number of functional units may be constructed that is specified based on purchased service requirement data.

[0185] Also, for example, for each of a plurality of locations, a specified number of functional units of a type specified for that location may be constructed.

[0186] Here, the CMaaS unit 68 and the BMaaS unit 84, for example, secure hardware resources (here, for example, a server 90) on which the new functional unit group is deployed.

[0187] Furthermore, the CMaaS unit 68 and the BMaaS unit 84 set up system software corresponding to the specific type of functional unit on the unused hardware resource. In this embodiment, for example, the CMaaS unit 68 or the BMaaS unit 84 stores a script (for example, an Ansible script) for setting up the above-mentioned specific type of functional unit. The script describes, for example, an installation procedure for a host OS that is the basis of a container execution environment of a specific type or a specific version, a kernel setting procedure for the host OS, a BIOS (Basic Input Output System) setting procedure, and the like. Then, the BMaaS unit 84 executes the script, whereby the system software corresponding to the specific type of functional unit is set up on the free server. For example, the host OS and BIOS of the container execution environment are set up on the free server.

[0188] Then, the CMaaS unit 68 and the BMaaS unit 84 update the resource pool management data to add the unused hardware resource for which the system software has been set up to the identified resource pool. The addition of such a hardware resource to the resource pool is detected by the container management unit 78 that manages the hardware resource. Then, the inventory management unit 66 updates the inventory data corresponding to the added hardware resource (server 90). In this way, the resource pool includes a hardware resource for which the system software has been set up according to a specific type of functional unit.

[0189] For example, it is assumed here that a vDU is a specific type of functional unit, the number of cores required for the vDU is 5, and the number of cores in the available server is 50.

[0190] In this case, when a network service including a vDU is purchased, a resource pool associated with the vDU is identified. In the example of Fig. 14, a resource pool with a resource pool ID of C is identified. Then, it is confirmed whether the remaining hardware resources of this resource pool are sufficient. Then, if the remaining hardware resources are insufficient, system software corresponding to the vDU is set up for one free server. Then, the server 90 on which the system software has been set up is added to the resource pool C, and the resource pool management data is updated to that shown in Fig. 18.

[0191] In this manner, in this embodiment, the hardware resources included in the resource pool corresponding to the resource pool data are subjected to system software setup according to one or more types of functional units associated with the resource pool.

[0192] Depending on the type of functional unit, a general-purpose server with a general configuration may not be able to provide sufficient performance. Therefore, for such a specific type of functional unit, it is desirable to perform a dedicated setup of system software such as a host OS and BIOS on hardware resources such as a server. In this case, it is possible to prepare the required number of hardware resources with the dedicated system software setup before the start of the network service, and deploy the functional unit to the prepared hardware resources when necessary.

[0193] However, it is difficult to estimate the optimal amount of hardware resources for which system software corresponding to a specific type of functional unit should be set up in advance before the provision of a network service is started. Also, if system software corresponding to a specific type of functional unit is set up for many hardware resources with a margin, such hardware resources will be inappropriate for deploying other functional units, resulting in a waste of resources.

[0194] In the present embodiment, when a specific type of functional unit is deployed to an unused hardware resource as described above, the setup of system software corresponding to the specific type of functional unit is applied to the unused hardware resource, and the unused hardware resource to which the setup of the system software has been applied is added to a resource pool associated with the specific type of functional unit.

[0195] In this manner, according to this embodiment, it becomes possible to effectively utilize the hardware resources in which various functional units that realize network services are deployed.

[0196] In the present embodiment, functional units may be identified based on the results of demand forecasting. For example, functional units that are predicted to be in short supply in the near future may be identified based on the results of demand forecasting. Then, a resource pool associated with the functional units identified in this manner may be identified. Then, unused hardware resources to which system software corresponding to the functional units has been set up may be added to the resource pool.

[0197] When the hardware resources for deploying the new functional unit group are secured, the service manager unit 70 instructs the container management unit 78 to deploy the new functional unit group based on, for example, the above-mentioned plan data and the service template data associated with the purchased bundle ID stored in the service manager unit 70. The service template data is capable of accepting a part or all of the plan data as a parameter.

[0198] An example of the above-mentioned service template data is CNFD (CNF Descriptor). Fig. 19 is a diagram showing an example of CNFD. The service manager unit 70 generates a day0 parameter (CNF instance) shown in Fig. 20 based on, for example, the planning data and the CNFD. For example, the day0 parameter shown in Fig. 20 is generated in which the host name and IP address values ​​of the CNFD shown in Fig. 19 are set.

[0199] Here, the CNFD may include templates corresponding to each of a plurality of deployment flavors. For example, the service manager unit 70 may generate day0 parameters based on a template corresponding to a deployment flavor according to the purchased service requirement data.

[0200] Here, the service manager unit 70 may identify the location of the output destination of the day0 parameter. For example, one or more container management units 78 that are to be the output destination of the day0 parameter may be identified. For example, a container management unit 78 associated with a server 90 that is placed at a location of a resource pool indicated in the container configuration data of the planning data may be identified. Then, a day0 parameter that is to be output to each of the identified locations may be generated. For example, a day0 parameter that is to be output to each of the one or more container management units 78 that are to be the output destination may be generated.

[0201] Then, the service manager unit 70 outputs each of the generated one or more day0 parameters to the container management unit 78, which is the location of the output destination of the day0 parameter. The day0 parameter is associated with a purchase bundle ID.

[0202] Then, the container management unit 78 deploys a new group of functional units based on the received day0 parameters. For example, the container management unit 78 identifies a container image to be deployed and a resource pool to which the container is to be deployed based on the Helm chart data associated with the purchased bundle ID and the received day0 parameters. Then, the container management unit 78 acquires the container image from the repository unit 80 and deploys a container corresponding to the container image to the identified resource pool. Here, for example, a manifest file is generated based on the Helm chart data associated with the purchased bundle ID and the received day0 parameters. Then, the container is deployed using the manifest file.

[0203] Furthermore, the CMaaS unit 68 generates planned CM data including a day 1 parameter, for example, based on the above-mentioned plan data and CM template data associated with the purchase bundle ID stored in the CMaaS unit 68. The CM template data is capable of accepting a part or all of the plan data as a parameter.

[0204] The day1 parameters indicate, for example, configuration management procedures such as settings for the deployed functional unit group and at least one functional unit related to the functional unit group (for example, a functional unit that communicates with the deployed functional unit group). The day1 parameters related to the base station device 22 indicate, for example, radio wave strength, the direction and angle of the antenna 22a, a serial number, etc. The day1 parameters related to the S-GW (Serving-Gateway) indicate, for example, information indicating the opposing node (information indicating the communication partner's MME (Mobility Management Entity) and APN (Access Point Name), etc.), the host name or FQDN of the RADIUS (Remote Authentication Dial In User Service) server, etc.

[0205] Then, the CMaaS unit 68 executes configuration management such as setting of functional units based on the day 1 parameters included in the generated planned CM data. These processes are executed, for example, in response to the execution of a workflow script by the E2EO unit 62.

[0206] Then, the slice manager unit 72 executes instantiation of a network slice related to the purchased network service, for example, based on the above-mentioned planning data and slice template data associated with the purchase bundle ID stored in the slice manager unit 72. The slice template data is capable of accepting a part or all of the planning data as a parameter. This process is executed, for example, by being triggered by execution of a workflow script by the E2EO unit 62.

[0207] The slice manager unit 72 is configured to include the functions of the NSMF (Network Slice Management Function) and the NSSMF (Network Slice Sub-network Management Function) described in the 3GPP specification "TS28 533." The NSMF is a function that generates and manages network slices, and provides management of NSI. The NSSMF is a function that generates and manages network slice subnets that constitute part of the network slice, and provides management of NSSI.

[0208] The slice manager unit 72 may include a storage unit (not shown) that stores information about NSI and NSSI. The storage unit may store SST (Slice Service Type: MBB, V2X, etc.), NSI ID (NSI-ID), NSSI ID (NSSI-ID), and NS ID (NS-ID).

[0209] The slice manager unit 72 outputs a configuration management instruction related to instantiation of the network slice and the network slice subnet to the CMaaS unit 68 based on the slice template data. At that time, the slice manager unit 72 assigns IDs to the constituting NSI and NSSI and stores the ID information in the above-mentioned storage unit. As a modified example, the CMaaS unit 68 may assign IDs to the NSI and NSSI in accordance with the configuration management instruction received from the slice manager unit 72 and notify the slice manager unit 72 of the ID information, and the slice manager unit 72 may store the ID information notified from the CMaaS unit 68 in the above-mentioned storage unit. For topology management, the slice manager unit 72 associates the IDs of the NSI, NSSI, and NS associated in the network hierarchy data of the slice template data with each other and stores them in the above-mentioned storage unit.

[0210] Here, an example of the process of constructing an NSI and an NSSI will be described. Fig. 21 shows a schematic diagram of the process of constructing an NSI and an NSSI. Devices a to c in Fig. 21 correspond to a plurality of servers 90. The slice manager unit 72 passes a configuration management instruction including setting information for setting an NSI and an NSSI on each device to the CMaaS unit 68.

[0211] The CMaaS unit 68 constructs an NSI and an NSSI on each device using a known segment routing technology (for example, SRv6 (segment routing IPv6)) based on the configuration information passed from the slice manager unit 72. For example, the CMaaS unit 68 may generate an NSI and an NSSI across multiple target CNFs by issuing a command to configure a common Virtual Local Area Network (VLAN) for multiple target CNFs constructed on multiple devices, and a command to assign a bandwidth and a priority indicated by the configuration information to the VLAN.

[0212] When setting NSI and NSSI for multiple target CNFs built on multiple devices, the slice manager unit 72 sets the type of metric data and an identification tag to be notified to the monitoring management unit 74 for the CNFC included in each target CNF. The identification tag is data including a value that can uniquely identify each CNFC from among multiple CNFCs, in other words, data including a different value for each CNFC.

[0213] The slice manager unit 72 holds SLA information related to NSIs and NSSIs included in slice template data. The SLA information defines the KPI calculation logic and the threshold for issuing an alarm. The slice manager unit 72 identifies a Pod (also called a container or CNFC) associated with the NSI and NSSI for which the KPI is to be calculated from the management table, and instructs the monitoring management unit 74 to calculate the KPI for each NSI and NSSI based on the metric data output from the Pod.

[0214] Here, the slice manager unit 72 may output a configuration management instruction related to instantiation of the network slice to the CMaaS unit 68. Then, the CMaaS unit 68 may execute configuration management such as setting in accordance with the configuration management instruction.

[0215] Here, for example, the CMaaS unit 68 may perform configuration management related to new functional units when the deployment of the new functional units is completed, and then perform configuration management related to the instantiation of the network slice.

[0216] Alternatively, the CMaaS unit 68 may update the day1 parameters once generated based on a configuration management instruction received from the slice manager unit 72. Then, the CMaaS unit 68 may collectively execute configuration management related to the instantiation of new functional units and network slices.

[0217] In this embodiment, for example, the monitoring management unit 74 identifies a monitoring policy indicated by the purchased service requirement data based on the above-mentioned plan data and monitoring script data associated with the purchased bundle ID stored in the monitoring management unit 74. Then, the monitoring management unit 74 executes monitoring settings according to the identified monitoring policy. Then, the monitoring management unit 74 monitors the constructed functional unit group according to the identified monitoring policy. Here, for example, monitoring may be executed for the monitoring target indicated by the purchased service requirement data at the monitoring interval indicated by the purchased service requirement data. This process is executed, for example, triggered by execution of a workflow script by the E2EO unit 62.

[0218] The monitoring management unit 74 may, for example, obtain a log from a sidecar that outputs the value of a metric to be monitored, which is associated with a container to be monitored, as a log at the above-mentioned monitoring interval. The monitoring management unit 74 may then accumulate the log. The monitoring management unit 74 may then transmit the log to the purchaser terminal 14 in response to a request from the purchaser terminal 14.

[0219] The monitoring management unit 74 acquires the metric value of the monitored target associated with the monitored CNFC (microservice) using known monitoring software, and calculates the KPI based on the metric value and a predetermined calculation logic. The known monitoring software may be Prometheus. The monitoring management unit 74 outputs alert information when the calculated KPI value exceeds a predetermined threshold value or when the KPI value is less than a predetermined threshold value.

[0220] The monitoring management unit 74 may calculate the values ​​of KPIs related to the NSI and NSSI based on an instruction from the slice manager unit 72. In order to calculate the values ​​of KPIs related to the NSI and NSSI, the monitoring management unit 74 may also calculate KPIs for NS, CNF, and CNFC associated with those NSI and NSSI.

[0221] In this embodiment, the security setting unit 76 executes security settings such as setting a password in accordance with the value of the purchased service requirement data based on the above-mentioned plan data and the security script data associated with the purchased bundle ID stored in the security setting unit 76.

[0222] Here, the flow of the processing executed by the vendor terminal 16, MPS 10, and NOS 12 when the onboarding button 40 is clicked by the vendor on the onboarding screen shown in FIG. 9 will be described with reference to the flow diagrams shown in FIGS. 22A and 22B.

[0223] First, the vendor terminal 16 transmits bundle data arranged in a path specified on the onboarding screen to the bundle extractor 60 of the NOS 12 (S101).

[0224] Then, the bundle decompression unit 60 decompresses the bundle data received in the process shown in S101, and generates the data group shown in FIG. 11 (S102).

[0225] Then, the bundle decompression unit 60 determines a bundle ID corresponding to the data group indicated in S102 (S103).

[0226] Then, the bundle expanding unit 60 transmits the product catalog data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103, to the bundle management unit 50 of the MPS 10. Then, the bundle management unit 50 of the MPS 10 stores the received product catalog data in the product catalog storage unit 52 (S104).

[0227] Then, the bundle expanding unit 60 outputs the service catalog data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103, to the E2EO unit 62. Then, the E2EO unit 62 stores the received service catalog data in the service catalog storage unit 64 (S105).

[0228] Then, the bundle expanding section 60 causes the inventory management section 66 to store the inventory template data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S106).

[0229] Then, the bundle expanding unit 60 causes the CMaaS unit 68 to store the CM template data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S107).

[0230] Then, the bundle expanding section 60 causes the service manager section 70 to store the service template data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S108).

[0231] Then, the bundle expanding unit 60 causes the slice manager unit 72 to store the slice template data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S109).

[0232] Then, the bundle expanding section 60 causes the monitoring management section 74 to store the monitoring script data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S110).

[0233] Then, the bundle expanding section 60 causes the security setting section 76 to store the security script data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103 (S111).

[0234] Then, the bundle expanding unit 60 stores the helm chart data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103, in the container management unit 78 (S112). Here, for example, the bundle expanding unit 60 may store the helm charts included in the data group shown in S102 in a plurality of container management units 78. Also, the helm chart data associated with a container management unit 78 may be stored in the container management unit 78.

[0235] Then, the bundle expansion unit 60 stores in the repository unit 80 (S113) the container image data included in the data group shown in S102, which is associated with the bundle ID determined in the process shown in S103, and the process shown in this processing example is terminated.

[0236] The following summarizes the operation during onboarding of bundle data uploaded from the vendor terminal 16. The bundle data includes multiple types of template data including slice template data and service template data. The bundle expansion unit 60 accepts the bundle data uploaded from the vendor terminal 16, associates the multiple types of template data included in the bundle data with the services indicated by the bundle data, and distributes them to multiple function blocks of the NOS 12. For example, the bundle expansion unit 60 provides the slice template data to the slice manager unit 72, and provides the service template data to the service manager unit 70.

[0237] The slice template data describes the SLA information of NSI and NSSI to be provided to the purchaser of the service. The SLA information includes the type of KPI to be monitored, the calculation logic of the KPI, and the threshold value that is the standard for evaluating the KPI. The slice template data also describes the hierarchical structure (correspondence) of NSI-NSSI-NS. The service template data describes the types of NS, CNF, and CNFC to be constructed, as well as their definition information.

[0238] Next, the flow of processing executed by the purchaser terminal 14, MPS 10, and NOS 12 when the purchaser clicks the Next button 32 on the service requirement input screen shown in FIG. 3 will be described with reference to the flow diagram shown in FIG.

[0239] First, the purchaser terminal 14 transmits purchased service requirement data associated with the purchased bundle ID to the purchase management unit 54 of the MPS 10 (S201). The purchased bundle ID is the bundle ID of the network service selected by the purchaser on the purchase screen shown in Fig. 2. The purchased service requirement data is service requirement data indicating the contents entered on the service requirement input screen shown in Fig. 3.

[0240] Then, the purchase management unit 54 of the MPS 10 transmits the purchased service requirement data associated with the purchased bundle ID received in the process shown in S201 to the E2E O unit 62 of the NOS 12 (S202).

[0241] Then, the E2EO unit 62 of the NOS 12 generates availability inquiry data based on the service catalog data associated with the purchased bundle ID (S203). Here, for example, availability inquiry data is generated that indicates the types of functional units that realize the network service to be purchased and the number of functional units for each type.

[0242] Then, the E2EO unit 62 outputs the availability inquiry data generated in the process shown in S203 to the inventory management unit 66 (S204).

[0243] Then, the inventory management unit 66 generates availability data based on the received availability inquiry data, inventory data, and inventory template data (S205). Here, for example, availability data is generated that indicates that the hardware resources to which the functional units shown in the received availability inquiry data are deployed are (1) available, (2) available by adding a free server to the resource pool, or (3) unavailable.

[0244] Then, the inventory management unit 66 transmits the availability data generated in the process shown in S205 to the E2E O unit 62 (S206).

[0245] Then, the E2EO unit 62 generates answer data based on the availability data received in the process shown in S206 (S207). For example, in this case, if the availability data indicates the above-mentioned (1) or (2), answer data indicating OK is generated, and if the availability data indicates the above-mentioned (3), answer data indicating NG is generated.

[0246] Then, the E2EO unit 62 transmits the response data generated in the process shown in S207 to the purchase management unit 54 of the MPS 10 (S208).

[0247] Then, the purchase management unit 54 generates a purchase confirmation screen based on the response data received in the process shown in S208 (S209). For example, if the received response data indicates OK, a purchase confirmation screen indicating that immediate provision is possible, as shown in Fig. 4, is generated. On the other hand, if the received response data indicates NG, a purchase confirmation screen indicating that a certain delivery time is required (for example, a delivery time of two weeks) is generated, as shown in Fig. 5.

[0248] Then, the purchase management unit 54 transmits the purchase confirmation screen generated in the process shown in S209 to the purchaser terminal 14 (S210).

[0249] Then, the purchaser terminal 14 displays the purchase confirmation screen received in the process shown in S210 on the display of the purchaser terminal 14 (S211), and the process shown in this process example is terminated.

[0250] Next, the flow of processing executed by the purchaser terminal 14, MPS 10, and NOS 12 when the purchaser clicks the purchase button 34 on the purchase confirmation screen shown in FIG. 4 or FIG. 5 will be explained with reference to the flow diagram shown in FIG.

[0251] First, the purchaser terminal 14 transmits a purchase request for a network service to the purchase management unit 54 of the MPS 10 (S301). The purchase request is associated with the purchase bundle ID and the purchase service requirement data transmitted in the process shown in S201.

[0252] Then, the purchase management unit 54 transmits the purchase request associated with the purchase bundle ID and the purchase service requirement data received in the process shown in S301 to the E2E O unit 62 (S302).

[0253] Then, the E2EO unit 62 identifies the service catalog data corresponding to the purchase bundle ID associated with the received purchase request (S303).

[0254] Then, the E2EO unit 62 obtains the service catalog data identified in the process shown in S303 from the service catalog storage unit 64, and executes the workflow script indicated by the service catalog data (S304), and the process shown in this processing example is terminated.

[0255] Here, the process of S304 will be described in detail with reference to the flow charts shown in FIGS. 25A to 25G.

[0256] First, the E2EO unit 62 and the inventory management unit 66 generate plan data based on purchase service requirement data, service catalog data, inventory template data, and inventory data associated with the purchase request (S401). The process executed in S401 includes, for example, a process of identifying a resource pool in which a group of functional units is deployed and a process of identifying necessary resources.

[0257] Then, the inventory management unit 66 stores the generated plan data in the inventory database 82 (S402).

[0258] Then, the inventory management unit 66 outputs the inventory key included in the generated plan data to the E2EO unit 62 (S403).

[0259] Then, the E2EO unit 62 outputs the received inventory key to the CMaaS unit 68 (S404).

[0260] Then, the CMaaS unit 68 acquires the plan data including the received inventory key from the inventory database 82 (S405).

[0261] Then, the CMaaS unit 68 generates and holds planned CM data including the day 1 parameters based on the plan data acquired in the process shown in S405 (S406).

[0262] Then, the CMaaS unit 68 outputs a setup instruction such as securing necessary hardware resources to the BMaaS unit 84 (S407), and the BMaaS unit 84 executes setup such as securing hardware resources according to the instruction (S408). At this time, the setup of system software according to a specific type of functional unit and the addition of a free server to the resource pool are executed as necessary.

[0263] In this embodiment, the addition of free servers to the resource pool may be performed with a margin (buffer). For example, a plurality of servers 90 may be added to the resource pool at once.

[0264] Then, when the BMaaS unit 84 outputs a completion notification to the CMaaS unit 68 (S409), the CMaaS unit 68 updates the resource pool management data (S410). Here, for example, the value of the remaining core count data of the resource pool in which the hardware resources have been secured may be subtracted. Also, the values ​​of the number of free servers and the total core count data may be updated. Note that, in the process shown in S410, the BMaaS unit 84 may update the resource pool management data, instead of the CMaaS unit 68. Also, the inventory management unit 66 may update the resource pool management data according to an instruction from the CMaaS unit 68.

[0265] Then, the CMaaS unit 68 outputs a completion notification to the E2EO unit 62 (S411).

[0266] Then, the E2EO unit 62 outputs the inventory key received in the process shown in S403 to the service manager unit 70 (S412).

[0267] Then, the service manager unit 70 acquires the planning data including the received inventory key from the inventory database 82 (S413).

[0268] Then, the service manager section 70 identifies locations where the functional units are to be deployed based on the plan data acquired in the process shown in S418 (S414).

[0269] Then, the service manager unit 70 generates day0 parameters (CNF instance) for each location identified in the process shown in S414 (S415).

[0270] Then, the service manager unit 70 outputs the day0 parameters corresponding to the container management unit 78 to the container management unit 78 corresponding to each location identified in the process shown in S414 (S416).

[0271] Then, the container management unit 78 executes the deployment of the container based on the received day0 parameters (S417).

[0272] Then, the container management unit 78 outputs a completion notification to the service manager unit 70 (S418).

[0273] Then, the service manager unit 70 outputs a completion notification to the E2E O unit 62 (S419).

[0274] Then, the E2EO unit 62 outputs a configuration management instruction based on the day1 parameters to the CMaaS unit 68 (S420).

[0275] Then, the CMaaS unit 68 executes configuration management of the container group based on the day 1 parameters included in the held planned CM data (S421).

[0276] Then, the CMaaS unit 68 outputs a completion notification to the E2EO unit 62 (S422).

[0277] Then, the E2EO unit 62 outputs the inventory key received in the process shown in S403 to the slice manager unit 72 (S423).

[0278] Then, the slice manager unit 72 acquires the planning data including the received inventory key from the inventory database 82 (S424).

[0279] Then, the slice manager unit 72 executes instantiation of the network slice based on the plan data acquired in the process shown in S429 (S425). In the process shown in S425, for example, as described above, the slice manager unit 72 may output a configuration management instruction related to the instantiation of the network slice to the CMaaS unit 68. Then, the CMaaS unit 68 may execute configuration management such as setting in accordance with the configuration management instruction.

[0280] Also, as described above, the processes shown in S420 to S422 may not be executed, and in the process shown in S425, the CMaaS unit 68 may update the day1 parameters based on a configuration management instruction received from the slice manager unit 72. Then, the CMaaS unit 68 may execute configuration management such as setting in accordance with the configuration management instruction.

[0281] Then, the slice manager unit 72 outputs a completion notification to the E2E O unit 62 (S426).

[0282] Then, the E2EO unit 62 outputs the inventory key received in the process shown in S403 to the monitoring management unit 74 (S427).

[0283] The monitoring management unit 74 then acquires the plan data including the received inventory key from the inventory database 82 (S428).

[0284] Then, the monitoring management unit 74 executes monitoring settings in accordance with the monitoring policy indicated by the purchased service requirement data, based on the plan data acquired in the process indicated in S428 (S429).

[0285] Then, the monitoring management unit 74 outputs a completion notification to the E2E O unit 62 (S430).

[0286] Then, the E2EO unit 62 outputs the inventory key received in the process shown in S403 to the security setting unit 76 (S431).

[0287] The security setting unit 76 then acquires the plan data including the received inventory key from the inventory database 82 (S432).

[0288] Then, the security setup unit 76 executes security setup based on the plan data acquired in the process shown in S432 (S433).

[0289] Then, the security setting unit 76 outputs a completion notification to the E2E O unit 62 (S434), and the process shown in this processing example is terminated.

[0290] The following summarizes the operations during network service provisioning triggered by the purchase of a service by a purchaser. Here, the purchased service is called the "purchased service." The E2EO unit 62 starts executing a workflow corresponding to the purchased service selected by the purchaser. The E2EO unit 62 and the inventory management unit 66 create planning data for the purchased service by filling in inventory data (IP address, host name, etc.) in the inventory template of the purchased service, in other words, by setting inventory data in the variable items of the inventory template.

[0291] The service manager unit 70 creates day0 data (day0 parameters) by filling in the contents indicated by the plan data in the service template data of the service to be purchased. The service manager unit 70 passes the created day0 data to the container management unit 78 (Kubernetes). The container management unit 78 generates a CNF (in other words, an application) for the service to be purchased based on the day0 data.

[0292] The CMaaS unit 68 creates day 1 data (day 1 parameters) by filling in the contents indicated by the plan data in the CM template data of the service to be purchased. The CMaaS unit 68 inputs the created day 1 data into the CNF for the service to be purchased.

[0293] The slice manager unit 72 creates slice data by filling in the slice template data of the service to be purchased with the contents indicated by the plan data. The slice manager unit 72 passes the created slice data to the CMaaS unit 68. The CMaaS unit 68 inputs the settings of the network slice and the network slice subnet into the CNF (in other words, the application) based on the slice data.

[0294] The monitoring management unit 74 executes monitoring processing for the functional unit group based on information about the functional unit group (e.g., CNF) to be constructed and monitoring script data distributed at the time of onboarding of the bundle file. For example, the monitoring management unit 74 may create monitoring setting data by filling in the monitoring script data of the purchased service with the contents indicated by the plan data as information about the functional unit group to be constructed. The monitoring management unit 74 may start monitoring processing based on the monitoring setting data. The monitoring setting data includes, for example, (1) monitoring frequency, (2) monitoring targets and their hierarchical structure, (3) logic for calculating KPIs from metric data acquired from CNFC, and (4) thresholds that serve as triggers for sending alarm information.

[0295] Another example of the monitoring setting data creation by the monitoring management unit 74 will be described. The service manager unit 70 may notify the inventory management unit 66 of information (such as IP address and host name information) on the NS, CNF, and CNFC constructed in association with the purchase of the service by the purchaser, and the inventory management unit 66 may store the information in the inventory database 82 in association with the service to be purchased. The service manager unit 70 may pass information on the NS, CNF, and CNFC to be constructed to a plurality of container management units 78, and the inventory management unit 66 may acquire the information from the plurality of container management units 78 and store it in the inventory database 82. The monitoring management unit 74 may create the monitoring setting data by acquiring information on the NS, CNF, and CNFC of the service to be purchased from the inventory management unit 66 (inventory database 82) and setting it in the variable items of the monitoring script data of the service to be purchased. The monitoring management unit 74 may directly acquire information on the NS, CNF, and CNFC constructed by the service manager unit 70 from the service manager unit 70.

[0296] Furthermore, the monitoring management unit 74 may obtain information regarding the NSI and NSSI of the service to be purchased (e.g., setting information on the NSI and NSSI) from the slice manager unit 72. The monitoring management unit 74 may create monitoring setting data by setting the information regarding the NSI and NSSI of the service to be purchased in variable items of the monitoring script data of the service to be purchased. The slice manager unit 72 may notify the inventory management unit 66 of the information regarding the NSI and NSSI of the service to be purchased. In this case, the monitoring management unit 74 may obtain the information regarding the NSI and NSSI of the service to be purchased from the inventory management unit 66.

[0297] According to the NOS 12 of the first embodiment, a vendor providing a network service can upload a bundle file including first data (e.g., technology section data) that defines a functional unit group that realizes the network service and second data (e.g., operation section data) that defines a monitoring policy for the network service to the NOS 12, and when a purchaser purchases a network service, the functional unit group that realizes the network service and the monitoring settings for the network service are automatically executed. The vendor can flexibly build the network service by adjusting the contents of the bundle file. Also, the network service can be quickly provided to the purchaser in response to the purchaser's purchase of the network service.

[0298] The present invention has been described above based on the first embodiment. This embodiment is merely an example, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component or each treatment process, and that such modifications are also within the scope of the present invention.

[0299] For example, a network service provided to a purchaser may be implemented by a VNF (Virtualized Network Function), which is a VM (Virtual Machine)-based functional unit using a hypervisor-type or host-type virtualization technology, instead of a CNF, which is a container-based functional unit. Here, when a specific type of functional unit is deployed to unused hardware resources (e.g., a vacant server in this case), system software corresponding to the specific type of functional unit may be set up in a host OS, which is the foundation of the virtual machine environment.

[0300] Also, for example, the division of roles for each function shown in Fig. 10 is not limited to that shown in Fig. 10. For example, part of the processing executed by the E2EO unit 62 may be executed by the inventory management unit 66. Also, for example, part of the processing executed by the inventory management unit 66 may be executed by the E2EO unit 62.

[0301] In this embodiment, the NOS 12 does not necessarily need to include the repository unit 80. Then, the bundle deployment unit 60 may store the Helm chart data and the container image data in the container management unit 78. Then, the container management unit 78 may deploy the container image stored in the container management unit 78.

[0302] In addition, in this embodiment, the NOS 12 does not necessarily need to include the bundle expansion unit 60. For example, a bundle file may be onboarded from an external file transfer server.

[0303] It will be understood by those skilled in the art that the functions to be performed by each of the constituent elements recited in the claims can be realized by each of the constituent elements shown in the first embodiment and the modified examples, either individually or in cooperation with each other. For example, the "reception unit" recited in the claims can be realized by the bundle expansion unit 60 of the NOS 12 in the first embodiment. Also, the "construction unit" recited in the claims can be realized by the CMaaS unit 68, service manager unit 70, slice manager unit 72, and container management unit 78 of the NOS 12 in the first embodiment, either individually or in combination.

[0304] (Second Example) The following description of this embodiment will focus on the differences from the first embodiment, and will omit the description of the commonalities as appropriate. The components of this embodiment that are the same as or correspond to the components of the first embodiment will be described with the same reference numerals.

[0305] The configuration of the computer system 1 of the second embodiment is similar to the configuration of the computer system 1 of the first embodiment (FIG. 1). Moreover, the functional blocks of the NOS 12 of the second embodiment are similar to the functional blocks of the NOS 12 of the first embodiment (FIG. 10).

[0306] An overview of the NOS 12 of the second embodiment will be described. The NOS 12 of the second embodiment acquires information on the operation of each of a plurality of network functions that realizes a network slice constructed in a mobile wireless communication network, measured by one or more devices that provide at least a part of the plurality of network functions. The NOS 12 of the second embodiment derives evaluation index values ​​for the plurality of network functions based on the acquired information on the operation of the plurality of network functions, and derives an evaluation index value for the network slice based on the evaluation index values ​​for the plurality of network functions. This makes it possible to obtain evaluation index values ​​for each network slice constructed in the mobile wireless communication network, and to support the evaluation and maintenance of each network slice.

[0307] 7 in the first embodiment, the network service provided to the purchaser is hierarchically organized into (1) NSI, (2) one or more NSSIs included in the NSI, (3) one or more NSs that realize each NSSI, (4) one or more CNFs that realize each NS, and (5) one or more CNFCs (microservices) that realize each CNF. The NOS 12 in the second embodiment traces the hierarchical structure from the lowest microservice to the highest NSI, and sequentially derives the KPI values ​​of each CNFC (microservice), CNF, NS, NSSI, and NSI.

[0308] The configuration of the NOS 12 in the second embodiment will be described in detail. As described in the first embodiment, the monitoring management unit 74 creates monitoring setting data by setting information about a group of functional units for realizing the purchased service in the variable items of the monitoring script data distributed when a bundle file is onboarded from the vendor terminal 16.

[0309] The monitoring configuration data (monitoring script data) includes logic (hereinafter referred to as "KPI derivation logic") for deriving evaluation index values ​​(hereinafter referred to as "KPI") for each of the functional units NSI, NSSI, NS, CNF, and CNFC that make up the service to be purchased, based on metric data output from multiple CNFCs that make up the service to be purchased.

[0310] The metric data output from the CNFC includes information about the operation or status of the CNFC. For example, the metric data may include at least one of (1) a throughput indicating the amount of data processed in a given period of time, (2) a connection completion rate of a telephone line or packet communication, and (3) a CPU usage rate of the CNFC.

[0311] The KPIs of the NSI, NSSI, NS, CNF, and CNFC may be indicators defined as SLAs, and may include, for example, throughput and connection completion rate. The KPIs of these network elements may include (1) a target or guaranteed value of throughput, (2) a target or guaranteed value of connection completion rate, and (3) a target or guaranteed value of the number of simultaneous connections. Furthermore, the KPIs of these network elements may include KPIs described in 3GPP specifications, such as KPIs described in "TS 28.552, Management and orchestration; 5G performance measurements" or "TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)".

[0312] The KPI derivation logic may include (1) the IDs of the NSI, NSSI, NS, CNF, and CNFC, and (2) a calculation formula for deriving the KPIs of the NSI, NSSI, NS, CNF, and CNFC. The KPI derivation logic may include (3) information on an identification tag for identifying metric data used in the above calculation formula, in other words, information for identifying the type of metric data used in the calculation formula and the CNFC that is the notification source. The calculation formula may include a formula for calculating the total or average value of multiple metric data or multiple KPIs.

[0313] The KPI derivation logic of the embodiment may include a formula for accumulating KPIs of lower elements in the network hierarchical data and calculating the KPI of a higher element. In other words, the KPI derivation logic may include a formula for deriving KPIs in the order of CNFC, CNF, NS, NSSI, and NSI. For example, the KPI derivation logic of a certain CNFC may include a formula for calculating the sum or average value of metric data notified from that CNFC. In addition, the KPI derivation logic of a certain CNF may include a formula for calculating the sum or average value of KPI values ​​of multiple CNFCs corresponding to that CNF.

[0314] The KPI derivation logic of an NS may include a formula for calculating the sum or average value of KPI values ​​of multiple CNFs corresponding to the NS. The KPI derivation logic of an NSSI may include a formula for calculating the sum or average value of KPI values ​​of multiple NSs corresponding to the NSSI. The KPI derivation logic of an NSI may include a formula for calculating the sum or average value of KPI values ​​of multiple NSSIs corresponding to the NSI.

[0315] 26 is a diagram showing the cooperation between a plurality of functional blocks of the NOS 12 according to the second embodiment. This diagram shows the cooperation during monitoring of a network service (in other words, during operation).

[0316] The CNF (RAN) 102 provides, for example, at least a part of the functions of an eNodeB (i.e., an LTE base station) or a gNB (i.e., a 5G base station). The CNF (SW) 104 provides, for example, a layer 2 switch or a layer 3 switch. The CNF (Core) 106 provides, for example, at least a part of the functions of a core network such as an AMF or an MME. The CNF (RAN) 102, the CNF (SW) 104, and the CNF (Core) 106 are, for example, components of one NSI 100.

[0317] Multiple CNFs (CNF(RAN) 102, CNF(SW) 104, and CNF(Core) 106 in the example of FIG. 8) deployed in a distributed manner across multiple servers 90 measure metric data set by the slice manager unit 72 when the network slice is configured, and periodically transmit the metric data to the monitoring management unit 74. The metric data transmitted from a certain CNF includes one or more types of metric data defined when the network slice is configured, and also includes an identification tag assigned to the CNF.

[0318] The monitoring management unit 74 includes a function of an acquisition unit that acquires information about the operation of each network function measured by one or more devices that provide at least a part of the multiple network functions. In the embodiment, the monitoring management unit 74 acquires metric data about the operation of one or more CNFs associated with each network function as the information about the operation of each network function.

[0319] In the example of Figure 26, the monitoring management unit 74 accepts metric data regarding each CNF transmitted from a device (e.g., server 90) in which a container (in other words, a pod) corresponding to each of CNFs, CNF (RAN) 102, CNF (SW) 104, and CNF (core) 106, is deployed.

[0320] A sidecar container that aggregates metric data output from multiple containers for each CNFC (microservice) may be deployed on the server 90. This sidecar container may include an agent called an exporter. The monitoring management unit 74 may repeatedly execute a process of acquiring metric data aggregated for each microservice from the sidecar container using the mechanism of Prometheus at a monitoring frequency defined in the monitoring setting data.

[0321] The monitoring management unit 74 also includes a function of a derivation unit that derives evaluation index values ​​of a plurality of network functions based on information on the operation of the plurality of network functions, and derives evaluation index values ​​of a network slice based on the evaluation index values ​​of the plurality of network functions. The monitoring management unit 74 derives KPI values ​​of each of a plurality of network elements (NSI, NSSI, NS, CNF, CNFC) associated in the network hierarchical data based on KPI derivation logic for each network element set in the monitoring setting data and metric data related to a plurality of CNFCs. The monitoring management unit 74 derives the KPI values ​​in a bottom-up manner, starting from the KPI value of the lower CNFC to the KPI value of the higher NSI.

[0322] A description will be given of a first specific example of KPI derivation by the monitoring management unit 74. The monitoring management unit 74 may derive the KPI value of each element of the network hierarchical data in the following steps (1) to (5).

[0323] (1) Derive KPI values ​​for each of multiple CNFCs based on the metric data of each of those CNFCs. (2) Based on the sum or average of the KPI values ​​of multiple CNFCs, the KPI values ​​of the higher-level CNFs (here, multiple CNFs) corresponding to those multiple CNFCs are derived. (3) Based on the sum or average of the KPI values ​​of multiple CNFs, the KPI values ​​of the higher-level NSs (here, multiple NSs) corresponding to those multiple CNFs are derived. (4) Based on the sum or average of the KPI values ​​of multiple NSs, the KPI value of the higher-level NSSI (here, multiple NSSIs) corresponding to those multiple NSs is derived. (5) Based on the sum or average of the KPI values ​​of multiple NSSIs, a KPI value for a higher-level NSI (or NSIs) corresponding to those multiple NSSIs is derived.

[0324] The monitoring management unit 74 compares the KPI values ​​(also called "KPI derived values") of each of the derived CNFCs with the KPI thresholds of each CNFC set in the monitoring setting data. If the relationship between the KPI derived value of a CNFC and the KPI threshold of that CNFC satisfies the alert condition set in the monitoring setting data, the monitoring management unit 74 outputs alert information including a pair of the ID and KPI derived value of that CNFC to the container management unit 78. The alert condition may be determined according to the type of KPI, and may be, for example, that the KPI derived value is less than the KPI threshold or that the KPI derived value exceeds the KPI threshold.

[0325] Furthermore, the monitoring management unit 74 compares the KPI derived value of each of the multiple CNFs with the KPI threshold of each CNF set in the monitoring setting data. If the relationship between the KPI derived value of a certain CNF and the KPI threshold of that CNF satisfies the alert condition set in the monitoring setting data, the monitoring management unit 74 outputs alert information including a pair of the ID of that CNF and the KPI derived value to the service manager unit 70.

[0326] Furthermore, the monitoring management unit 74 compares the KPI derived value of each of the multiple NSs with the KPI threshold value of each NS set in the monitoring setting data. If the relationship between the KPI derived value of a certain NS and the KPI threshold value of that NS satisfies the alert condition set in the monitoring setting data, the monitoring management unit 74 outputs alert information including a pair of the ID of that NS and the KPI derived value to the service manager unit 70.

[0327] Furthermore, the monitoring management unit 74 compares the KPI derived value of each of the multiple NSSIs with the KPI threshold value of each NSSI set in the monitoring setting data. If the relationship between the KPI derived value of a certain NSSI and the KPI threshold value of that NSSI satisfies the alert condition set in the monitoring setting data, the monitoring management unit 74 outputs alert information including a pair of the ID of that NSSI and the KPI derived value to the slice manager unit 72.

[0328] Furthermore, the monitoring management unit 74 compares the KPI derived value of each of the multiple NSIs with the KPI threshold value of each NSI set in the monitoring setting data. If the relationship between the KPI derived value of a certain NSI and the KPI threshold value of that NSI satisfies the alert condition set in the monitoring setting data, the monitoring management unit 74 outputs alert information including a pair of the ID of that NSI and the KPI derived value to the slice manager unit 72.

[0329] A second specific example of KPI derivation by the monitoring management unit 74 will be described. Here, the operation of the monitoring management unit 74 will be described, but this operation may be defined in the calculation logic in the monitoring setting data (in other words, the monitoring script data included in the bundle file) referenced by the monitoring management unit 74.

[0330] Fig. 27 shows an example of network hierarchical data for a certain purchaser. The network hierarchical data in Fig. 27 includes NSI110, NSSI112, NS114a, NS114b, and NS114c. Although not shown in Fig. 27, CNFs and CNFCs are further associated with each of NS114a, NS114b, and NS114c. In this example, the monitoring management unit 74 may calculate, as the throughput value as the KPI of NSSI112, the arithmetic mean of the throughput value as the KPI of NS114b and the throughput value as the KPI of NS114c.

[0331] Also, NS114b is an IP telephone service in the core domain, NS114c is an IP telephone service in the RAN domain, and NSSI112 is an NSSI for IP telephone services spanning from the RAN domain to the core domain. In this case, the monitoring management unit 74 may calculate the product of the connection completion rate value as a KPI of NS114b and the connection completion rate value as a KPI of NS114c as the connection completion rate value as a KPI of NSSI112.

[0332] A third specific example of KPI derivation by the monitoring management unit 74 will be described. Here, the operation of the monitoring management unit 74 will be described, but this operation may be defined in the calculation logic in the monitoring setting data (in other words, the monitoring script data included in the bundle file) referenced by the monitoring management unit 74.

[0333] The monitoring management unit 74 may derive (1) an RRC (Radio Resource Control) connection completion rate (KPI of the RAN domain NS), (2) an attach success rate (KPI of the core domain NS), and (3) an ERAB (EPS Radio Access Bearer) established success rate (KPI of the core domain NS) as the KPIs of the multiple NSs. The monitoring management unit 74 may derive (1) the product of the average RRC connection completion rate, (2) the average attach success rate, and (3) the average ERAB establishment success rate as the KPI value (e.g., connection completion rate) of an NSI (or NSSI) that is higher than the multiple NSs. Note that the average RRC connection completion rate may be the average RRC connection completion rate across multiple gNBs belonging to the same NSI (or NSSI).

[0334] 26, the slice manager unit 72 includes a function of a change unit that autonomously changes the setting of at least one of the NSI and NSSI in accordance with the KPI values ​​of the NSI and NSSI respectively derived by the monitoring management unit 74. In the second embodiment, the slice manager unit 72 autonomously changes the setting of at least one of the NSI and NSSI in accordance with the KPI derived value of the NSI or NSSI indicated by the alert information notified from the monitoring management unit 74.

[0335] The slice manager unit 72 may store the KPI thresholds of the NSI and NSSI described in the purchased service requirement data (or slice template data) when constructing the NSI and NSSI. The purchased service requirement data (or slice template data) may define configuration changes according to the KPI derived values ​​of the NSI and NSSI. The slice manager unit 72 may compare the KPI derived value of the NSI or NSSI notified by the monitoring management unit 74 with the KPI threshold, and execute a configuration change (a setting change of at least one of the NSI and NSSI) defined by the purchased service requirement data (or slice template data) according to the comparison result.

[0336] For example, if the KPI derived value (e.g., connection completion rate) of an NSI or NSSI notified by the monitoring management unit 74 is less than a predetermined KPI threshold, the slice manager unit 72 may scale out the CNF (referred to as the "corresponding CNF") associated with that NSI or NSSI in the network hierarchy data.

[0337] As an example of scale-out, the slice manager unit 72 may cooperate with the service manager unit 70 and the container management unit 78 to deploy a new CNF having the same functions as the corresponding CNF to the server 90. The slice manager unit 72 may further cooperate with the CMaaS unit 68 to configure the new CNF with the NSI or NSSI in the same manner as the corresponding CNF. As another example of scale-out, the slice manager unit 72 may cooperate with the container management unit 78 to increase the number of Pods in the corresponding CNF.

[0338] Furthermore, when the KPI derived value (here, throughput) of an NSI or NSSI notified from the monitoring management unit 74 is less than a predetermined KPI threshold, the slice manager unit 72 may change the setting of the Quality of Service (QoS) for that NSI or NSSI. As an example of changing the QoS, the slice manager unit 72 may work with the CMaaS unit 68 to change the shaving value set in the CNF corresponding to that NSI or NSSI in the network hierarchical data to a value larger than the previous value.

[0339] Furthermore, the slice manager unit 72 may store the time series transition of the KPI derived values ​​of each of the NSI and the NSSI, in other words, derive the trend of change of the KPI derived values. For example, (1) when the connection completion rate as the KPI of the NSI or the NSSI is on a downward trend, or (2) when the connection completion rate in a unit time has decreased by exceeding a predetermined threshold, or (3) when the decrease rate of the connection completion rate has exceeded a predetermined threshold, the slice manager unit 72 may scale out the CNF corresponding to that NSI or NSSI.

[0340] In addition, if (1) the throughput as a KPI of an NSI or NSSI is showing a downward trend, or (2) the throughput has decreased by more than a predetermined threshold in a unit time, or (3) the rate of decrease in throughput has exceeded a predetermined threshold, the slice manager unit 72 may change the QoS settings (e.g., shaving value) for that NSI or NSSI.

[0341] The service manager unit 70 changes the configuration of the NS or CNF in cooperation with the container management unit 78 in accordance with the KPI derived value of the NS or CNF notified by the monitoring management unit 74. The container management unit 78 changes the configuration of the CNF in accordance with the KPI derived value of the CNFC notified by the monitoring management unit 74.

[0342] According to the NOS 12 of the second embodiment, it is possible to obtain highly accurate KPI values ​​for network slices (NSI and NSSI) constructed in a mobile communication network virtualized by NFV (Network Functions Virtualization) and SDN (Software-Defined Networking). For example, even if a certain network slice is constructed across multiple servers 90, or one server 90 is shared by multiple network slices, it is possible to obtain highly valid KPI values ​​for each network slice. This can assist in appropriate evaluation, operation, and maintenance of each network slice.

[0343] In addition, the NOS 12 of the second embodiment derives the KPI value of the network slice based on the sum or average value of the KPI values ​​of multiple network functions. Specifically, the NOS 12 derives the KPI values ​​from the lower element to the higher element for the NSI-NSSI-NS-CNF-CNFC associated in the network hierarchical data. This makes it possible to appropriately derive the KPI value of each element in the network hierarchical data.

[0344] Furthermore, according to the NOS 12 of the second embodiment, the settings of the network slice (e.g., the number of CNFCs, resources, QoS settings, etc.) are automatically and autonomously changed according to the KPI value of the network slice. This makes it possible to maintain appropriate settings of the network slice and also realize efficient operation and maintenance.

[0345] The present invention has been described above based on the second embodiment. This embodiment is merely illustrative, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component or each processing process, and that such modifications are also within the scope of the present invention. It will also be understood by those skilled in the art that the functions to be performed by each component recited in the claims can be realized by each component shown in the second embodiment and the modifications alone or in combination with each other.

[0346] A modified example of the second embodiment will be described. The slice manager unit 72 may transmit information about the set NSI and NSSI, information about the configuration below the NS in which those slices are set, and SLA information of each network element to the monitoring management unit 74. The monitoring management unit 74 may derive KPI values ​​of the NSI and NSSI from KPI values ​​or metrics data related to the NS based on the information received from the slice manager unit 72.

[0347] Another modified example of the second embodiment will be described. The monitoring management unit 74 may hold KPI derivation logic for the NSI and NSSI, and may derive the KPI values ​​of the NSI and NSSI. In this case, the monitoring management unit 74 may transmit data required for deriving the KPI values ​​of the NSI and NSSI, for example, metric data acquired regarding the NSI and NSSI, and / or the KPI values ​​of the NS·CNF·CNFC associated with the NSI and NSSI, to the slice manager unit 72.

[0348] Another modified example of the second embodiment will be described. The slice manager unit 72 may compare the KPI derived values ​​of NSI and NSSI with the KPI threshold value and output an alert based on the comparison result. In this case, the entity that derives the KPI values ​​of NSI and NSSI may be the monitoring management unit 74 as in the second embodiment, or the slice manager unit 72 as in the above modified example. In the latter case, the monitoring management unit 74 may only acquire the metric values ​​of the monitored objects, and the processing after the KPI calculation may be performed by the slice manager unit 72.

[0349] Any combination of the above-described embodiments and modifications is also useful as an embodiment of the present invention. A new embodiment resulting from the combination has the combined effects of the embodiments and modifications. [Industrial Applicability]

[0350] The techniques of the present disclosure can be applied to computer systems. [Explanation of symbols]

[0351] 1 computer system, 12 NOS, 14 purchaser terminal, 16 vendor terminal, 60 bundle deployment section, 62 E2EO section, 70 service manager section, 72 slice manager section, 74 monitoring management section, 90 server.

Claims

1. A method for providing a network service comprising: receiving a bundle file including first data defining a functional unit group for implementing the network service and second data defining a monitoring policy for the network service; a construction unit that constructs the functional unit group based on first data of the bundle file when the network service is purchased by a purchaser; a monitoring management unit that executes a monitoring process for the functional unit group based on information about the functional unit group constructed by the construction unit and second data of the bundle file; Equipped with The second data of the bundle file includes logic for calculating an evaluation index value of the network service based on the metric data of the functional unit group. Computer system.

2. The information about the functional unit group constructed by the construction unit includes an identifier of the functional unit group on a network assigned to the functional unit group, 2. The computer system according to claim 1, wherein the monitoring management unit performs monitoring processing on the functional unit group in accordance with an identifier of the functional unit group indicated by information regarding the functional unit group constructed by the construction unit and a monitoring policy indicated by second data of the bundle file.

3. A step of receiving a bundle file including first data defining a group of functional units that realize a network service and second data defining a monitoring policy for the network service; constructing the functional unit group based on first data of the bundle file when the network service is purchased by a purchaser; and executing a monitoring process for the functional unit group based on information about the functional unit group constructed in the constructing step and second data of the bundle file, The second data of the bundle file includes logic for calculating an evaluation index value of the network service based on the metric data of the functional unit group. A network service construction method implemented by a computer.

Images