Network control method, system, and computer-readable storage medium
The network control system addresses rejected intent requests by managing resource information across multiple networks, ensuring efficient and timely network configuration through intent division and adjustment, thereby reducing rejections.
Patent Information
- Application Number
- PCT/JP2024/042108
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-03-25
- Filing Date
- 2024-11-28
- Publication Date
- 2025-10-02
AI Technical Summary
Existing network management frameworks, such as those described in Non-Patent Document 1, do not address how to handle rejected intent requests in a network environment.
A network control system comprising an orchestrator, a first database, and a second database, which acquires and manages resource information across multiple networks, divides intent requests, and adjusts resource intents to satisfy user demands by selecting and combining transmission paths that accept the split intent requests.
The system effectively reduces the likelihood of intent request rejections, enabling rapid deployment of desired network configurations by managing resource intents and adjusting to network responses.
Smart Images

Figure JP2024042108_02102025_PF_FP_ABST
Abstract
Description
Network control method, system and computer-readable storage medium
[0001] The present disclosure relates to a technology for providing an end-to-end communication path that satisfies intent requests via multiple networks in different domains.
[0002] Non-Patent Document 1 proposes a network management architecture using "intents" called Closed-Loop and Management Framework for Intent-Driven networks aimed at 6G mobile networks.
[0003] Jingwen Zhang, Chungang Yang, Ru Dong, Yao Wang, Alan Anpalagan, Qiang Ni and Mohsen Guizani, "Intent-Driven "Closed-Loop Control and Management Framework for 6G Open Ran", IEEE Internet of Things Journal (Volume: 11, Issue: 4, 15 February 2024) doi: 10.1109 / JIOT. 2023.3312795
[0004] In Non-Patent Document 1, in order to apply the intent of the service level to the network, the abstract intent is interpreted and divided into parameters.
[0005] However, Non-Patent Document 1 does not consider what to do when a divided intent is rejected.
[0006] According to one aspect of the present disclosure, there is provided a network control system including an orchestrator, a first database, and a second database, the network control system providing an end-to-end communication path that satisfies an intent request via a plurality of networks of different domains, the orchestrator being configured to: acquire resource information for each network transmission path from each of the plurality of networks in advance and store the resource information in the first database as resource intent information; manage end-to-end intent information combining the transmission paths of the plurality of networks in advance in the second database based on the resource intent information; select the end-to-end intent information that satisfies the intent request; obtain split intent requests corresponding to each of the plurality of networks from the intent request based on the combination of transmission paths of the selected end-to-end intent information; transmit the split intent requests to the corresponding networks; and provide the communication path based on the combination of transmission paths for which the corresponding networks have accepted the split intent requests.
[0007] Other features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are designated by the same reference numerals.
[0008] 1 is a functional block diagram showing the configuration of the main parts of a mobile network and its management and operation system according to an embodiment. FIG. 2 is a diagram showing a sequence of a pre-operation. FIG. 3 is a diagram showing an example of resource information transmitted by a base station network. FIG. 4 is a diagram showing an example of resource information transmitted by a transport network. FIG. 5 is a diagram showing an example of resource information transmitted by a mobile core network. FIG. 6 is a diagram showing an example of end-to-end intent information. FIG. 7 is a sequence diagram of a process performed by an orchestrator that has received a service intent. FIG. 8 is a diagram showing an example of resource intent for each mobile core network based on the end-to-end resource intent. FIG. 9 is a sequence diagram showing a first re-search procedure. FIG. 10 is a sequence diagram showing a second re-search procedure. FIG. 11 is a sequence diagram showing a third re-search procedure. FIG. 12 is a sequence diagram showing the third re-search procedure. FIG. 13 is a sequence diagram showing an example of application to a network that does not support pre-transmission of resource intent information.
[0009] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention as claimed, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be combined in any desired manner. Furthermore, the same reference numerals are used to designate identical or similar components, and redundant descriptions will be omitted.
[0010] 1 is a functional block diagram showing the configuration of the main parts of a mobile network and a control system for managing and operating the mobile network according to this embodiment. A mobile network is a network that is built and operated by a telecommunications carrier, a local company, a local government, etc. for providing communication services.
[0011] In this embodiment, the type of mobile network is not particularly limited, but here we will use as an example a mobile network consisting of three different domains: a base station network NW1 that accommodates base stations such as 5G, a mobile core network NW3 that is composed of mobile core equipment, and a transport network NW2 that connects the base station network NW1 and the mobile core network NW3.
[0012] A user (administrator) creates a service intent and transmits it to the orchestrator 10. In this embodiment, abstract network information for realizing a service desired by the user, for example, "a network that can distribute 4K video is required" is transmitted as the service intent.
[0013] The orchestrator 10 can be configured by implementing applications (programs) that realize the functions described below on a general-purpose computer or server equipped with a CPU, ROM, RAM, bus, interface, etc. Alternatively, it can be configured as a dedicated machine or a single-function machine in which part of the application is implemented as hardware or software.
[0014] The orchestrator 10 has a function of dividing (or decomposing or distributing) the service intent into resource intents for each domain when it receives a service intent from a user, and a function of requesting each resource intent from the corresponding domain and determining an operation based on a response of acceptance or denial. Of the functions of the orchestrator 10, the function of determining an operation based on a response of acceptance or denial is realized by using information stored in the resource intent DB 20 and the end-to-end intent DB 30.
[0015] Here, the resource intent is information about resources required for the network of each domain, interpreted from the service intent, and includes, for example, delay, jitter, packet loss rate, traffic bandwidth, and the like.
[0016] The resource intent information acquired from each domain is stored in the resource intent DB 20. The resource intent information is periodically transmitted to the orchestrator 10 by a transmission controller 40 (described later), and the orchestrator 10 stores the information in the resource intent DB 20.
[0017] The end-to-end intent DB 30 stores resource intent information related to end-to-end quality (hereinafter referred to as end-to-end intent information) by combining resource intent information acquired from each domain. In this embodiment, the orchestrator 10 combines the resource intent information stored in the resource intent DB 20 and stores the result in the end-to-end intent DB 30 as end-to-end intent information.
[0018] The transmission controller 40 is a communication device that collects resource intent information from a mobile network and transmits it to the orchestrator 10. The resource intent information transmitted by the transmission controller 40 includes information that indicates the network state. Specifically, the resource intent information transmitted by the transmission controller 40 may include delay, jitter, packet loss rate, traffic bandwidth, etc. in a certain section of the network.
[0019] Next, specific operations of this embodiment will be described with reference to sequence diagrams. The operations of this embodiment are broadly divided into pre-operations performed before accepting a service intent from a user, and operations performed after accepting the service intent. Figure 2 shows the sequence of pre-operations, and Figures 7, 9-11 show the sequences of operations after acceptance.
[0020] First, refer to FIG. 2. In step S101, resource information of the base station network NW1 is notified to the transmission controller 40. FIG. 3 is a diagram showing an example of resource information transmitted by the base station network NW1. According to FIG. 3, for each combination of three base stations assigned IDs 101 to 103 as base station IDs and Central Units (CUs) installed in Sapporo, Osaka, and Tokyo, respectively, which are the communication destinations of each base station, the delay (msec), packet loss rate (%), and bandwidth (Gbps) when communicating between each base station and CU are registered.
[0021] In step S102, the resource information of the transport network NW2 is notified to the transmission controller 40. Fig. 4 is a diagram showing an example of resource information transmitted by the transport network NW2, in which the numerical values of the delay (msec) when transmitting between the bases of Sapporo, Osaka, and Tokyo are registered.
[0022] In step S103, resource information of the mobile core network NW3 is notified to the transmission controller 40. Fig. 5 is a diagram showing an example of resource information transmitted by the mobile core network NW3, in which numerical values of delay, packet loss, and bandwidth are registered for each combination of a mobile core and a CU.
[0023] In step S104, the transmission controller 40 transmits the resource information notified from each network in steps S101 to S103 to the orchestrator 10 as resource intent information.
[0024] Note that the processes of steps S101 to S103 can be processed in parallel, and the transmission controller 40 can transmit resource information of the base station network NW1 to the orchestrator 10 as resource intent information without waiting for resource information of the transport network NW2 or the mobile core network NW3. In step S105, the orchestrator 10 stores the resource intent information acquired from the transmission controller 40 in step S104 in the resource intent DB 20.
[0025] In step S106, the orchestrator 10 periodically refers to the information stored in the resource intent DB 20. In this embodiment, the pieces of information on the base station network NW1, the transport network NW2, and the mobile core network NW3 at the time of the reference are combined and treated as a single piece of data.
[0026] In step S107, the orchestrator 10 stores the information referred to and combined in step S106 in the end-to-end intent DB 30 as end-to-end intent information.
[0027] 6 is a diagram showing an example of end-to-end intent information stored in the end-to-end intent DB 30. In this embodiment, by combining resource intent information transmitted by each mobile network, end-to-end delay (E2E delay), packet loss (E2E packet loss), and bandwidth (E2E bandwidth) are stored for each combination of base station ID, CU, and mobile core.
[0028] Here, E2E delay (msec) is the delay between base station / CU + delay between CU / mobile core, E2E packet loss is 1 - (1 - packet loss between base station / CU) (1 - packet loss between CU / mobile core), and E2E bandwidth is min {delay between base station / CU, delay between CU / mobile core}.
[0029] Next, with reference to the sequence diagram of FIG. 7, the subsequent operation of the orchestrator 10 after receiving the service intent will be described in detail.
[0030] In step S201, a service intent for constructing a network desired by a user (e.g., a network for delivering 4K video is required) is transmitted to the orchestrator 10. In step S202, the orchestrator 10 converts the received service intent into an end-to-end resource intent. For example, the orchestrator 10 converts the service intent into an end-to-end resource intent with quantitative values such as a bandwidth of 10 Gbps or more, a delay of 20 msec or less, and a packet loss of 1% or less.
[0031] The orchestrator 10 further divides the end-to-end resource intent into resource intents for the base station network NW1, the transport network NW2 and the mobile core network NW3, respectively.
[0032] 8, an end-to-end resource intent with a bandwidth of 10 Gbps or more, a delay of 20 msec or less, and a packet loss rate of 1% or less is divided into a resource intent with a bandwidth of 10 Gbps, a delay of 10 msec, and a packet loss rate of 0.1% for the base station network NW1, a resource intent with a bandwidth of 10 Gbps, a delay of 5 msec, and a packet loss rate of 0.3% for the transport network NW2, and a resource intent with a bandwidth of 10 Gbps, a delay of 5 msec, and a packet loss rate of 0.3% for the mobile core network NW3. In this way, dividing (or decomposing or distributing) the end-to-end resource intent into resource intents for each network means generating a resource intent for each network so as to satisfy the end-to-end resource intent.
[0033] Note that the determination of specific numerical values (such as a bandwidth of 10 Gbps) is performed in step S204 described below, so here we are limited to the framework of determining the bandwidth, delay, and packet loss rate in the base station network NW1, transport network NW2, and mobile core network NW3.
[0034] Returning to FIG. 7, in step S203, the end-to-end intent DB 30 is referenced to determine which numerical value of the resource intent divided in step S202 should be requested from each network.
[0035] 6, the end-to-end intent DB 30 stores estimated values for end-to-end delay, packet loss rate, and bandwidth for each selectable combination of base station, CU, and mobile core. Therefore, for example, if the base station is selected as base station ID 102, the CU is selected as Sapporo, and the mobile core is selected as Tokyo, it can be seen that the minimum E2E delay is 6 msec and the maximum is 11 msec, the E2E packet loss rate is 0.1%, and the E2E bandwidth is 25 Gbps.
[0036] In step S204, values of the base station network NW1, transport network NW2, and mobile core network NW3 that satisfy the end-to-end resource intent (e.g., bandwidth of 10 Gbps or more, delay of 20 msec or less, packet loss of 1% or less) are selected from the end-to-end intent DB 30 referenced in step S203.
[0037] For example, when referring to the end-to-end intent DB 30, an example of which is shown in FIG. 6, and realizing the current end-to-end resource intent (bandwidth of 10 Gbps or more, delay of 20 msec or less, packet loss of 1% or less), the selection example is as follows:
[0038] (1) Base station network (base station ID 102 to Sapporo CU): Bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1% (2) Transport network (Sapporo to Tokyo): Delay 3-4 msec (3) Mobile core network (Sapporo CU to Tokyo mobile core): Bandwidth 25 Gbps, delay 2-5 msec, packet loss rate 0.05% In step S205, the orchestrator 10 requests the determined resource intent (e.g., bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1%) from the base station network NW1.
[0039] In step S206, the base station network NW1 responds by accepting or rejecting the request. In this embodiment, since available resources are confirmed in advance, the expected response in step S207 and steps S210 and S213 described below is acceptance.
[0040] However, there may be cases where the pre-confirmed resources are unavailable due to overlapping requests from other users or equipment failure. In such cases, the response will be rejected, and an attempt will be made to modify the service intent. How to modify the service intent will be described later.
[0041] In step S208, the orchestrator 10 requests the transport network NW2 for the determined resource intent (e.g., delay of 3-4 msec). In step S209, the transport network NW2 responds by accepting or rejecting the request. In step S210, the orchestrator 10 refers to the response result.
[0042] In step S211, the orchestrator 10 requests the determined resource intent (e.g., bandwidth 25 Gbps, delay 2-5 msec, packet loss rate 0.05%) from the mobile core network NW3. In step S212, the mobile core network NW3 responds by accepting or rejecting the request. In step S213, the orchestrator 10 refers to the response result.
[0043] The resource intents requested in S205, S208, and S211 are divided from the end-to-end resource intent, and are therefore also referred to as divided intents or divided intent requests.
[0044] Next, we will explain three examples of the re-search procedure for modifying and re-requesting the divided resource intent when the mobile network (NW1, NW2, NW3) rejects the divided resource intent request from the orchestrator 10.
[0045] FIG. 9 is a sequence diagram showing a first re-search procedure by the orchestrator 10, and here, a re-search method that excludes rejected parts of the intent will be described.
[0046] In step S301, a resource intent (e.g., bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1%) is requested to the base station network NW1. If the base station network NW1 returns a rejection response in step S302, in step S303, the target of the rejected resource intent is excluded from the selection, and the next candidate is selected.
[0047] For example, if the combination of base station ID 102 and Sapporo CU is rejected, a combination that does not include the rejected base station and CU, such as the combination of base station ID 101 and Tokyo CU, is selected, and the process returns to step S301, where a resource intent is requested again.
[0048] If the modified intent is accepted, the process proceeds to step S304, where a resource intent (eg, delay 3-4 msec) is then requested from transport network NW2.
[0049] In step S305, if the transport network NW2 responds with an acceptance, the process proceeds to step S306, where a resource intent (for example, a bandwidth of 25 Gbps, a delay of 2-5 msec, and a packet loss rate of 0.05%) is requested from the mobile core network NW3.
[0050] In step S307, if the mobile core network NW3 responds with a rejection, the process proceeds to step S308, where the rejected resource intent target is excluded from the selection and the next candidate is selected.
[0051] For example, if the combination of Tokyo CU and Tokyo mobile core is rejected, a combination that does not include the rejected Tokyo mobile core is selected, such as the combination of Tokyo CU and Osaka mobile core. However, since the Tokyo CU has already been decided to be used, the Tokyo CU cannot be changed. Therefore, only the selection of the mobile core is changed, and the process returns to step S306, where a resource intent request is made again, and this process is repeated until an acceptance response is obtained.
[0052] 10 is a sequence diagram showing a second re-search method by the orchestrator 10, in which a search is performed again for candidates in which the numerical values or conditions assigned to the rejected resource intent are relaxed. Note that the difference from the operation sequence in FIG. 9 is only in the method of modifying the service intent, so here, only the differences will be described using as an example a case in which the investigation result from the base station network NW1 and the mobile core network NW3 is a rejection response.
[0053] If the result of the investigation from the base station network NW1 is a rejection response, the orchestrator 10 proceeds to step S401, where it relaxes the numerical value or conditions given to the rejected resource intent and selects the next candidate.
[0054] For example, if a request for a bandwidth of 25 Gbps, a delay of 1-2 msec, and a packet loss rate of 0.1% is rejected, an option with more relaxed conditions, such as a bandwidth of 10 Gbps, a delay of 3-5 msec, and a packet loss rate of 0.2%, is searched and selected from the end-to-end intent DB 30. If the examination result from the transport network NW2 is a rejection response, the process proceeds to step S402, where the numerical values or conditions assigned to the rejected resource intent are similarly relaxed to select the next candidate.
[0055] If the result of the investigation from the mobile core network NW3 is a rejection response, the orchestrator 10 proceeds to step S403, where it similarly relaxes the numerical value or conditions given to the rejected resource intent and selects the next candidate.
[0056] For example, if a request for a bandwidth of 25 Gbps, a delay of 2-5 msec, and a packet loss rate of 0.05% is rejected, an option with more relaxed conditions, such as a bandwidth of 10 Gbps, a delay of 4-7 msec, and a packet loss rate of 0.1%, is searched and selected from the end-to-end intent database.
[0057] 11A to 11C are sequence diagrams showing a third re-search method by the orchestrator 10, and here, a re-search method by updating the resource intent will be described.
[0058] 11A, in step S501, the orchestrator 10 requests resource intent (e.g., bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1%) from the base station network NW1. If the base station network NW1 rejects the request in step S502, the process proceeds to step S503, where the orchestrator 10 requests the base station network NW1 to update the resource information.
[0059] In step S504, the base station network NW1 notifies the transmission controller 40 of the latest resource information. In step S505, the transmission controller 40 transmits the latest resource intent information to the orchestrator 10. In step S506, the orchestrator 10 stores the latest resource intent information transmitted from the transmission controller 40 in the resource intent DB 20.
[0060] In step S507, the orchestrator 10 refers to the information in the resource intent DB 20 and combines the information of the base station network NW1, the transport network NW2, and the mobile core network NW3 at the reference time to handle them as a single data. In step S508, the information referred to and combined in step S507 is stored in the end-to-end intent DB 30 as updated end-to-end intent information.
[0061] 11B, in step S601, the orchestrator 10 requests a resource intent (for example, a delay of 3-4 msec) from the transport network NW2. In step S602, if the transport network NW2 responds with an acceptance, the process proceeds to step S701 in FIG.
[0062] In step S701, the orchestrator 10 requests resource intent (for example, bandwidth 25 Gbps, delay 2-5 msec, packet loss rate 0.05%) from the mobile core network NW3. If the mobile core network NW3 rejects the request in step S702, the orchestrator 10 proceeds to step S703, where it requests the mobile core network NW3 to update the resource information.
[0063] In step S704, the mobile core network NW3 notifies the transmission controller 40 of the latest resource information. In step S705, the transmission controller 40 transmits the latest resource intent information to the orchestrator 10. In step S706, the orchestrator 10 stores the resource intent information transmitted from the transmission controller 40 in the resource intent DB 20.
[0064] In step S707, the orchestrator 10 refers to the information in the resource intent DB and combines the information of the base station network NW1, the transport network NW2, and the mobile core network NW3 at the reference time to handle it as a single piece of data. In step S708, the information referred to and combined in step S707 is stored in the end-to-end intent DB 30 as updated end-to-end intent information.
[0065] Next, with reference to the sequence diagram of FIG. 12, a method for networks that do not support advance transmission of resource information (for example, interconnected networks, the Internet) will be described.
[0066] In step S801, a resource intent request is made to a network that does not support pre-transmission of resource intent. In step S802, a response (acceptance or denial) to the resource intent request is received. In step S803, the response result received in step S802 is cached in the resource intent DB 20. In step S804, a record is created in the end-to-end intent DB 30 based on the cache of the resource intent DB 20 in step S803.
[0067] By the above procedure, it becomes possible to use the cached results to refer to the resource intent DB 20 and the end-to-end intent DB 30 in the same way as in a network that supports advance transmission of resource information.
[0068] Furthermore, according to each of the above embodiments, in a network control system that provides a communication path that satisfies a specified intent request end-to-end via multiple networks in different domains, the possibility that each network will reject the intent request can be significantly reduced, making it possible to deploy the desired intent in a short period of time.
[0069] The invention is not limited to the above-described embodiment, and various modifications and variations are possible within the scope of the gist of the invention.
[0070] This application claims priority based on Japanese Patent Application No. 2024-048422, filed March 25, 2024, the entire contents of which are incorporated herein by reference.
Claims
1. A network control system comprising an orchestrator, a first database, and a second database, which provides a communication path that satisfies an intent request between end-to-end via multiple networks of different domains, wherein the orchestrator: acquires resource information for each network transmission path from each of the multiple networks in advance and stores it in the first database as resource intent information; manages end-to-end intent information that combines the transmission paths of each of the multiple networks in advance in the second database based on the resource intent information; selects the end-to-end intent information that satisfies the intent request; obtains split intent requests corresponding to each of the multiple networks from the intent request based on the combination of transmission paths of the selected end-to-end intent information; transmits the split intent requests to the corresponding networks; and provides the communication path based on the combination of transmission paths for which the corresponding networks have accepted the split intent requests.
2. The network control system according to claim 1, wherein the orchestrator is configured to send a new split intent request to the network that rejected the split intent request, the new split intent request being different from the rejected split intent request.
3. A network control system as described in claim 1 or 2, wherein the orchestrator is configured to send a new split intent request to the network that rejected the split intent request, the new split intent request having relaxed at least one of the numerical values and conditions of the rejected split intent request.
4. The network control system of claim 1 or 2, wherein the orchestrator is configured to request an update of resource information from the network that rejected the split intent request, obtain the updated resource information, update the first database and the second database based on the updated resource information, and reselect a combination of transmission paths that satisfies the intent request based on the updated end-to-end intent information.
5. A network control system according to any one of claims 1 to 4, wherein the orchestrator is configured to send a resource intent request to a network for which no record of resource intent information exists in the first database, and to pre-store end-to-end intent information in the second database based on resource intent information received in response to the resource intent request.
6. A network control system according to any one of claims 1 to 5, wherein the plurality of networks are mobile networks.
7. A network control method executed by a computer for providing a communication path that satisfies an intent request between end-to-end via multiple networks of different domains, comprising: acquiring resource information for each network transmission path from each of the multiple networks in advance and storing it as resource intent information in a first database; managing end-to-end intent information that combines the transmission paths of each of the multiple networks in a second database in advance based on the resource intent information; selecting the end-to-end intent information that satisfies the intent request; obtaining split intent requests corresponding to each of the multiple networks from the intent request based on the combination of transmission paths of the selected end-to-end intent information; transmitting the split intent requests to the corresponding networks; and providing the communication path based on the combination of transmission paths for which the corresponding networks have accepted the split intent requests.
8. The network control method according to claim 7, further comprising: transmitting a new divided intent request different from the divided intent request that was rejected to the network that rejected the divided intent request.
9. A network control method according to claim 7 or 8, further comprising: sending a new divided intent request to a network that rejected the divided intent request, the divided intent request having relaxed at least one of the numerical values and conditions of the rejected divided intent request.
10. A network control method according to claim 7 or 8, comprising: requesting an update of resource information from a network that rejected the divided intent request, and obtaining the updated resource information; updating the first database and the second database based on the updated resource information; and reselecting a combination of transmission paths that satisfies the intent request based on the updated end-to-end intent information.
11. A computer-readable storage medium storing a computer program that, when executed by one or more processors of a computer, causes the computer to carry out the network control method according to any one of claims 7 to 10.
Citation Information
Patent Citations
End-to-end intent definition of network functions for network slice management
US20230370342A1