Requirement division device, requirement division method, and program

Abstract

A requirement division device for dividing a requirement for a slice constructed across a plurality of domains in a communication network into division requirements of each domain. The requirement division device includes: a surplus calculation unit which calculates a surplus with regard to the requirement on the basis of the requirement and a feasible requirement of each domain; and a division calculation unit which calculates the division requirement of each domain on the basis of the feasible requirement of each domain and the surplus.

Description

Requirements division device, requirements division method, and program

[0001] The present invention relates to network slicing in a communication network.

[0002] Networks are becoming more sophisticated with the introduction of diverse communication services such as the Internet of Things (IoT) and autonomous driving, as well as the continuous increase in traffic due to the development of video streaming services. However, there are concerns about the resulting increase in operational costs. In the future, a shortage of operators is expected due to the declining labor force. Therefore, in order to advance network sophistication, it is important to simultaneously advance operational automation and reduce associated costs.

[0003] In 5G, various communication scenarios such as eMBB, URLLC, and mMTC are expected [1], but realizing these in a single monolithic network is difficult from the perspective of cost and physical constraints. In this specification, references are indicated by numbers such as "[1]" as above, and the titles of the documents corresponding to the numbers are listed at the end of the specification.

[0004] Therefore, network slicing, which builds virtual networks corresponding to each scenario on a common physical network, is attracting attention as a technological concept for realizing diverse communication scenarios [2].

[0005] Network slicing involves calculating the network resources and topology required to realize a desired communication scenario and constructing a network slice (or "slice"). Specifically, it is conceivable to control each slice in such a way that a larger amount of network bandwidth is reserved to realize eMBB, which requires a wide bandwidth, or that UPF is placed on the edge side to realize URLLC, which requires ultra-low latency.

[0006] Providing network slices end-to-end (E2E) requires integrated control of networks and systems across multiple domains, such as the access network (AN), transport network (TN), and core network (CN). The ETSI ZSM ISG is currently studying an architecture to achieve this control [3].

[0007] JF Santos, W. Liu, X. Jiao, VN Neto, S. Pollin, JM Marquez-Barja, I. Moerman , LA DaSilva, "Breaking Down Network Slicing: Hierarchical Orchestration of End-to-End Networks," IEEE Communications Magazine, 2020.

[0008] Provisioning a slice across multiple domains may require splitting the E2E requirements for that slice.

[0009] However, in the conventional technology, when dividing requirements, differences in feasible requirements among multiple domains cannot be taken into consideration, and therefore, requirements cannot be divided appropriately.

[0010] The present invention has been made in view of the above points, and aims to provide a technique for appropriately dividing the requirements of slices constructed across multiple domains.

[0011] According to the disclosed technology, there is provided a requirements division device in a communication network that divides the requirements of a slice constructed across multiple domains into division requirements for each domain, the requirements division device comprising: a surplus calculation unit that calculates a surplus for the requirements based on the requirements and feasible requirements of each domain; and a division calculation unit that calculates the division requirements for each domain based on the feasible requirements of each domain and the surplus.

[0012] The disclosed technology provides a technique for appropriately dividing the requirements of slices that are constructed across multiple administrative domains.

[0013] FIG. 1 is a diagram illustrating a schematic configuration of an architecture for realizing control of a network slice; FIG. 2 is a diagram illustrating a system configuration in an embodiment; FIG. 3 is a diagram illustrating a network model; FIG. 4 is a flowchart for explaining the flow of operation of the system; and FIG. 5 is a diagram illustrating an example of the hardware configuration of an apparatus.

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0015] Below, network slicing and its challenges will be explained in more detail, followed by an explanation of the technology according to this embodiment.

[0016] (Network Slicing) As mentioned above, providing network slicing end-to-end (E2E) requires integrated control of networks and systems across multiple domains, such as the access network (AN), transport network (TN), and core network (CN). The ETSI ZSM ISG is currently studying an architecture to achieve this control [3].

[0017] As shown in Figure 1, this architecture consists of two types of Management Domains (MDs). First, there is E2E Service MD1, which provides E2E network services. Under it, there are MDs 2 to 4, which autonomously control the AN, TN, and CN domains. E2E network slices are provided by interconnecting virtual networks called slice subnets, which are constructed on the AN, TN, and CN, respectively. The adoption of such a hierarchical architecture simplifies network management across multiple domains [4]. Therefore, this architecture is assumed in this embodiment. However, the technology according to the present invention is not limited to this architecture.

[0018] (Network Slice Provisioning) When provisioning a slice, a summary of network slice requirements such as latency and bandwidth, called NEST (NEtwork Slice Template) [5], is input to the E2E Service MD. Based on NEST, the E2E Service MD derives the slice subnet requirements for each domain, called SliceProfile [6]. It then requests provisioning based on the SliceProfile to its subordinate MDs.

[0019] Here, when deriving a SliceProfile in the E2E Service MD, there are two types of requirements specified in NEST: those that can be inherited from the original requirements, and those that require separate calculations. An example of the former requirement is bandwidth. In this case, the E2E Service MD simply specifies the same value for the subordinate MDs. An example of the latter requirement is latency. In this case, the E2E Service MD must divide the given latency requirement for the MDs controlling the AN, TN, and CN so that the total value satisfies the value specified in E2E. However, as pointed out in [7], there has been little progress in developing algorithms for deriving the latter type of requirement. Therefore, manual work is currently required.

[0020] In this embodiment, among the requirements that require separate calculation when deriving a SliceProfile, we focus on requirements that require division, such as latency. When such requirements are given in NEST, we propose a specific algorithm for dividing the requirements in E2E Service MD and deriving a SliceProfile, as well as a system for running this algorithm. Details of these will be described later. The technology according to this embodiment makes it possible to automate part of the process related to network slice provisioning.

[0021] (Regarding Related Technologies) Here, we will explain related technologies. Regarding network slice provisioning, there is a technology [8] that calculates the required bandwidth and server resources based on requirements for the network slice, such as latency and reliability. However, this technology assumes centralized management of the entire architecture that constitutes the network slice, and does not match the architecture [3] assumed in this embodiment.

[0022] In addition, there is a study by Santos et al. [7] on an architecture that realizes network slicing across multiple domains. In this study, a hierarchical architecture similar to the architecture assumed in this embodiment [3] was prototyped for network slicing across multiple domains, and its overhead was quantitatively investigated. However, no specific requirement partitioning algorithm was proposed.

[0023] As described above, in the prior art, there is no specific slice requirement division method for network slices spanning multiple domains that is compatible with the architecture [3] assumed in this embodiment.

[0024] (Regarding the Issues) The issues will be described in detail below. The issues described below are not well-known issues, but issues that are expected to occur when the technology according to the present embodiment is not used.

[0025] For the domains that make up a network slice, the requirements for the achievable SliceProfile differ depending on the physical constraints of each domain. As an example, consider the achievable latency in CN and TN.

[0026] In a CN, the processing delay in the NF (Network Function) responsible for data transfer, such as the UPF in 5GC, is considered to be dominant. Therefore, since long-distance data transfer, which is an issue when considering E2E latency, does not occur, a CN can achieve short latency. On the other hand, if the CN is placed in a data center, a TN will require long-distance communication to connect the AN close to the end user with the CN in the data center. Therefore, in this case, the TN cannot achieve extremely short latency.

[0027] However, if requirements are divided without considering this difference, it may result in imposing unrealizable requirements on a specific domain. As a result, provisioning of the slice subnet in the target domain may fail, and consequently, provisioning of the network slice may also fail. Therefore, a requirements division algorithm that takes into account the feasible requirements in the domains that make up the network slice is needed.

[0028] The following describes a technique according to the present embodiment for solving the above problems.

[0029] (Outline of the embodiment) First, a description will be given of the basic processing contents executed by the requirements division device 100. In this embodiment, the requirements division device 100 executes an algorithm (processing) that realizes requirements division that does not impose unrealizable requirements on a specific domain.

[0030] The requirements division device 100 receives as input "a predicted value relating to the minimum value of requirements that can be realized when a new slice subnet is constructed in that domain," which is acquired from the domain that constitutes the slice.

[0031] In this embodiment, this predicted value for each domain constituting a slice is called the feasibility requirement of that domain. For example, an example of a method for calculating the feasibility requirement in a TN is calculating latency assuming that all currently available bandwidth is allocated. Calculation of the feasibility requirement is not limited to this calculation method, and any method may be used.

[0032] The feasible requirements for domain D obtained by some method are expressed as r D Let (D∈{AN,TN,CN}).

[0033] Next, the requirements division device 100 divides the requirement R (E2E requirement) specified by NEST based on the obtained feasible requirements. First, the requirements division device 100 calculates the surplus c of the requirement r obtained by division with respect to the sum of the feasible requirements, as shown below.

[0034] In the above example, the surplus c is calculated by subtracting the sum of feasible requirements from requirement R, but this is not limited to this. For example, surplus c may be calculated by subtracting the "sum of feasible requirements + α" from requirement R, assuming α > 0.

[0035] If c<0, the sum of the minimum values ​​of the requirements that can be realized in each domain exceeds the requirement R. In other words, it can be assumed that it is difficult to provision a network slice that satisfies the given requirement R with the current network resources. How to handle this case is up to the discretion of the implementer, but one possible solution is to suspend provisioning.

[0036] If c ≥ 0, the requirements specified for domain D are D Let (D∈{AN, TN, CN}), and the requirements dividing device 100 calculates each requirement as follows.

[0037] In this calculation, the surplus c is calculated by dividing the feasible requirements r D Whereas, r D The purpose of this calculation is twofold. First, since c ≥ 0, R D ≧r DSince the above holds, it is possible to prevent imposing requirements that are lower than the feasible requirements on a specific domain. Also, the surplus c is calculated by dividing the feasible requirements r of each domain by the D By distributing resources proportionally, we prevent excessive burdens on specific domains and resource shortages.

[0038] In the above example, the surplus c is calculated by dividing the feasible requirements r of each domain. D Whereas, r D For example, in a domain where the variance (uncertainty) of feasible requirements is considered large, the allocation is weighted in proportion to r D In this case, for any other domain, a weight proportional to r D is given a weight less than that proportional to

[0039] (System Configuration) An example of a system configuration in this embodiment is shown in Fig. 2. As shown in Fig. 2, this system includes a control device 100 and a control unit 130 in the E2E Service MD, and a control unit 210 and a computing device 200 in each MD.

[0040] The requirements division device 100 includes a surplus calculation unit 110 and a division calculation unit 120. The calculation device 200 includes a feasible requirements calculation unit 220. The control unit 130 may be included in the control device 100. The control unit 210 may be included in the calculation device 200. An overview of the operation of this system is as follows.

[0041] The control unit 130 in the E2E Service MD receives the requirements of the network slice (the requirement to be divided is assumed to be R) and requests the control unit 210 of each MD to acquire the feasible requirements. The control unit 210 requests the feasible requirements calculation unit 220 to acquire the feasible requirements.

[0042] The feasibility requirement calculation unit 220 calculates the feasibility requirement r D Calculate the feasible requirements r D The control unit 210 transmits the feasibility requirement r D is transmitted to the control unit 130.

[0043] The control unit 130 calculates the requirements R and the feasible requirements r obtained from each MD. D to the surplus calculation unit 110. The surplus calculation unit 110 calculates the surplus c and transmits the surplus c to the control unit 130.

[0044] The control unit 130 calculates the surplus c and the feasible requirements r obtained from each MD. D The division calculation unit 120 calculates the divided requirements R for each domain. D Calculate the requirement R D is transmitted to the control unit 130.

[0045] The control unit 130 divides the requirements R D The slice subnet provisioning request is sent to the control unit 210 of each MD. The control unit 210 executes the provisioning.

[0046] The requirements and modeling in this embodiment will be described in detail below.

[0047] (Requirements) In this embodiment, the DL (downlink) latency L [ms] is the requirement to be divided. "Latency" may also be called delay. Therefore, the requirement R mentioned above corresponds to L in this embodiment. Other requirements include bandwidth B [bps], packet size P [bytes], and the number of base stations A i The construction range A of a slice specified as a set (i∈n) is A:={A1, A2, … , A n Therefore, (L, B, P, A) is given to the control unit 130 by NEST.

[0048] Note that latency is an example of a requirement to be divided, and the requirement to be divided is not limited to latency. For example, the requirement to be divided may be power consumption or the like.

[0049] (Operation of the feasibility requirement calculation unit 220) Next, a description will be given of the calculation of the feasibility requirements executed by the feasibility requirement calculation unit 220. The calculation of the feasibility requirements is performed in each domain D.

[0050] The feasible requirement calculation unit 220 first calculates the feasible requirements for its own domain D using the requirements (B, P, A) that are not subject to division. D and latency model f D In this embodiment, f D is, s D is a monotonically decreasing function with parameter.

[0051] Then, the feasibility requirement calculation unit 220 calculates f D The maximum value of the currently available resources is s D max The latency f D (s D max ) is calculated. D Since is monotonically decreasing, f D (s D max ) is the minimum latency. Therefore, the feasible requirement calculation unit 220 calculates the feasible requirement l D A D = f D (s D max ) is calculated as

[0052] (Regarding the network model) In this embodiment, as shown in Figure 3, we consider a model in which the communication section between the UE and the base station is AN, the 5GC located in the data center is CN, and the communication section between the base station and the data center is TN.

[0053] This model is expressed as a graph G:= (V,E), where V is a set of network devices and E is a set of lines connecting them. AN , V TN , V CN Let V be the set of network devices in each domain, and V:= V AN ∪V TN ∪V CN Let's say.

[0054] The configuration of each domain D and the resources required to calculate the feasible requirements D , the latency model f D is as follows:

[0055] <AN Configuration and Latency Modeling> In this embodiment, a base station with an integrated CU, DU, and RU is assumed, and connections within the base station are not considered. AN Let be a set of base stations. To model the latency, first, we consider the UE and base station A specified by NEST. i The latency between AN i , and related resources AN i In this embodiment, the propagation delay between the UE and the base station is ignored, and only the transmission time of the packet, which is determined by the bandwidth, is considered. Therefore, the resource s AN i Base station A i Number of RBs (Resource Blocks) n prb i Then, the bandwidth calculation formula of 3GPP TS 38.306 [9] is used as n prb i Function B of AN Considering this, base station A i Latency model in f AN i is defined as follows:

[0056] Finally, s AN i , f AN i Use s to find resources in the domain. AN := (s AN 1 ,s AN 2 ,…,s AN n ) and the latency model is f AN (s AN ) :=max i f AN i (s AN i ) In this case, the number of remaining RBs in each base station is N prb i Then, s AN max := (N prb 1 ,N prb2 ,… ,N prb n ) In other words, the f AN i (s AN i ) is maximized, which is the feasible requirement in AN.

[0057] <TN Configuration and Latency Modeling> In this example, V AN Only the backhaul lines connecting the base stations included in V and 5GC are considered. TN is the router that configures the backhaul line. Also, for the line e∈E connecting between routers, a function B TN , Len is defined. Finally, base station A i The route from to 5GC is assumed to be pre-designed.

[0058] To model latency, we first build a model that calculates the sum of the time it takes for a packet to travel (the sum of the time for multiple lines passing through a route) for each route from each base station to 5GC, given the length and bandwidth of each line passing through that route. This sum of time is the latency.

[0059] Resources TN Let f be the bandwidth in that path, then the latency model f TN (s TN ) returns the maximum value of the latency calculated using the model set for each path from the base station to the 5GC.

[0060] For example, there are base stations A1, A2, and A3 as base stations for which slices are to be constructed. If the latency between A1 and 5GC is latency 1, the latency between A2 and 5GC is latency 2, and the latency between A3 and 5GC is latency 3, then f TN (s TN ) returns the maximum value of latency1, latency2, and latency3.

[0061] <CN Configuration and Latency Modeling> The CN is assumed to be located in only one data center. In addition, when modeling the latency in the CN [8], in this example, it is assumed that the latency in the UPF, which is responsible for data transfer in 5GC, is dominant. Therefore, the resource s D Consider the CPUs assigned to UPF as follows. In this case, the latency model f CN decreases monotonically with respect to the allocated CPU amount. TN max as the maximum amount of CPU that can be allocated.

[0062] (Operational Flow) The operational flow in the system shown in FIG. 2 will be described with reference to the flowchart of FIG.

[0063] <S101 (Step 101)> The control unit 130 of the E2E Service MD receives the input requirement R as a provisioning request for the network slice.

[0064] <S102> The control unit 130 generates feasible requirements r for the control unit 210 of each subordinate MD based on the requirements (B, P, A) that are not subject to division. D The control unit 210 of the subordinate MD requests the feasibility requirement calculation unit 220 to acquire the feasibility requirements.

[0065] The feasibility requirement calculation unit 220 calculates a latency model f D and domain resources D Calculate.

[0066] Next, the feasibility requirement calculation unit 220 of each MD calculates the currently available resources s D max Calculate the feasibility requirements r of the domain D = f D (s D max ) is obtained. The control unit 210 of each MD calculates the r D and passes it to the control unit 130 of the E2E Service MD.

[0067] The control unit 130 of the E2E Service MD requests the surplus calculation unit 110 to calculate the surplus c based on the received feasible requirements. The surplus calculation unit 110 calculates the surplus c.

[0068] <S104> If the surplus c<0 (YES in S104), the requirements division device 100 determines that the provisioning of the slice for the given NEST has failed and ends the process. If c≧0, the process proceeds to S105.

[0069] <S105> The division calculation unit 120 calculates the surplus c and the feasibility requirements r of each domain. D Enter the divided requirements R D The divided requirements RD are notified to the control unit 130.

[0070] (Hardware Configuration Example) Any of the devices described in this embodiment (the requirements division device 100 and the computing device 200) can be realized by, for example, causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0071] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0072] Fig. 5 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 5 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected by a bus BS. The computer may further include a GPU.

[0073] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0074] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0075] (Summary, Effects, etc. of the Embodiment) As described above, the technology described in the present embodiment provides a technology for appropriately dividing the requirements of slices constructed across multiple domains.

[0076] That is, in this embodiment, the requirements division device 100 in the E2E Service MD obtains the feasible requirements in the subordinate MD for the requirements to be divided, and based on the feasible requirements, divides the requirements specified in NEST so as not to impose unrealizable requirements on a specific domain, and derives a SliceProfile.

[0077] This makes it possible to prevent inappropriate division that would cause slice provisioning failure when dividing slices according to their requirements. Furthermore, by utilizing the technology according to the present invention, it is possible to promote automation of network slice provisioning.

[0078] The following additional notes are provided regarding the above-described embodiments.

[0079] <Supplementary Notes> (Supplementary Item 1) A requirements division device in a communication network that divides requirements of a slice constructed across multiple domains into division requirements for each domain, comprising: a memory; and at least one processor connected to the memory, wherein the processor calculates a surplus for the requirement based on the requirement and a feasible requirement of each domain, and calculates the division requirements for each domain based on the feasible requirement of each domain and the surplus. (Supplementary Item 2) The processor calculates the surplus by subtracting the sum of the feasible requirements for the multiple domains from the requirement. (Supplementary Item 3) The processor calculates the division requirements for each domain by adding a value obtained by multiplying the surplus by a weight to the feasible requirement. (Supplementary Item 4) The requirements division device according to Supplementary Item 3. (Supplementary Item 5) The requirements division device according to Supplementary Item 4, wherein the processor uses, for each domain, a value obtained by dividing the feasible requirement by the sum of the feasible requirements for the multiple domains as the weight. (Supplementary Item 6) A requirements division method executed by a requirements division device that divides requirements of a slice constructed across multiple domains in a communication network into division requirements of each domain, the requirements division method comprising: a surplus calculation step of calculating a surplus for the requirement based on the requirement and the feasible requirements of each domain; and a division calculation step of calculating the division requirements of each domain based on the feasible requirements of each domain and the surplus. (Supplementary Item 7) A non-transitory storage medium storing a program for causing a computer to function as each unit in the requirements division device according to any one of Supplementary Item 1 to 5.

[0080] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0081] [References] [1] ITU-R, "IMT Vision - Framework and overall objectives of the future development of IMT for 2020 and beyond," 2015. [2] NGMN Alliance, "NGMN 5G White Paper," 2015. [3] ETSI ZSM ISG, "ETSI GS ZSM 003 v.1.1.1," 2021. [4] ETSI ZSM ISG, "ETSI GS ZSM 002 v1.1.1," 2019. [5] GSMA, "Generic Network Slice Template Version 8.0," 2022. [6] 3GPP, "5G; Management and orchestration; Concepts, use cases and requirements (3GPP TS 28.530 version 17.4.0 Release 17)," 2023. [7] J. F. Santos, W. Liu, X. Jiao, V. N. Neto, S. Pollin, J. M. Marquez-Barja, I. Moerman, L. A. DaSilva, "Breaking Down Network Slicing: Hierarchical Orchestration of End-to-End Networks," IEEE Communications Magazine, 2020. [8] M. Lashgari, L. Wosinska, P. Monti, "End-to-End Provisioning of Latency and Availability Constrained 5G Services," 2021. [9] 3GPP, "5G; NR; User Equipment (UE) radio access capabilities (3GPP TS 38.306 version 17.0.0 Release 17)," 2022.

[0082] REFERENCE SIGNS LIST 100 Control device 110 Surplus calculation unit 120 Division calculation unit 130 Control unit 200 Calculation device 210 Control unit 220 Feasible requirement calculation unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A requirements division device in a communication network that divides the requirements of a slice constructed across multiple domains into division requirements for each domain, comprising: a surplus calculation unit that calculates a surplus for the requirements based on the requirements and feasible requirements of each domain; and a division calculation unit that calculates the division requirements for each domain based on the feasible requirements of each domain and the surplus.

2. The requirements division device according to claim 1, wherein the surplus calculation unit calculates the surplus by subtracting the sum of feasible requirements for the plurality of domains from the requirement.

3. The requirements division device according to claim 1, wherein the division calculation unit calculates the divided requirements by adding a value obtained by multiplying the surplus by a weight to the feasible requirements for each domain.

4. The requirements division device according to claim 3, wherein the weights are proportional to the feasibility of the requirements.

5. The requirements division device according to claim 4, wherein the division calculation unit uses, for each domain, a value obtained by dividing the feasible requirement by the sum of the feasible requirements for the multiple domains as the weight.

6. A requirements division method executed by a requirements division device in a communication network that divides the requirements of a slice constructed across multiple domains into division requirements for each domain, the requirements division method comprising: a surplus calculation step of calculating a surplus for the requirements based on the requirements and feasible requirements of each domain; and a division calculation step of calculating the division requirements for each domain based on the feasible requirements of each domain and the surplus.

7. A program for causing a computer to function as each part of the requirements division device according to any one of claims 1 to 5.