Network control method, system, and program

Abstract

To provide a network control system which provides a communication path satisfying a predetermined intent request between end-to-end via a plurality of networks having different domains in which a desired intent can be deployed to each network in a short time.SOLUTION: The present invention provides a communication path that is provided with an orchestrator 10 and first and second databases 20 and 30. On the basis of a combination of transmission paths which accepted an intent request by all of networks, the orchestrator 10 acquires resource information from each network and stores the resource information in the first database, manages an end-to-end quality in the second database based on the resource information acquired from each network, selects the combination of transmission paths the whose end-to-end quality satisfies the intent requirement, divides the intent request for each network based on the selected combination of transmission paths, and transmits the divided intent requests to the corresponding networks.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a network control method, system, and program, and more particularly to a network control method, system, and program that provide a communication path that satisfies a predetermined intent request between end-to-end via multiple networks of different domains. [Background technology]

[0002] Non-Patent Document 1 discloses a proposal for an architecture related to network management using intents called Closed-Loop and Management Framework for Intent-Driven networks aimed at 6G mobile networks. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Jingwen Zhang, Chungang Yang, Ru Dong, Yao Wang, Alagan 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 Summary of the Invention [Problem to be solved by the invention]

[0004] The architecture shown in Non-Patent Document 1 builds and provides an architecture that interprets and divides abstract intent into parameters in order to apply service-level intent to the network.

[0005] However, the architecture for when a request is rejected during the planning and execution stages of deploying the split intent has not been considered. Therefore, there is an issue that, in preparation for actual operation, negotiations will be repeated in the process from intent splitting to execution, which will take a long time to deploy.

[0006] The object of the present invention is to solve the above technical problems and provide a network control method, system, and program that can deploy a desired intent in a short time even if the intent is rejected during the planning and execution stages before deploying the divided intent. [Means for solving the problem]

[0007] In order to achieve the above object, the present invention provides a network control system that provides communication paths that satisfy a specified intent request end-to-end via multiple networks in different domains, and includes an orchestrator and first and second databases. The orchestrator acquires resource information for each transmission path of each network from each network and stores it in the first database. Based on the resource information acquired from each network, the orchestrator manages the end-to-end quality of the combination of transmission paths of each network in the second database. The orchestrator selects a combination of transmission paths whose end-to-end quality satisfies the intent request. The orchestrator divides the intent request by network based on the selected combination of transmission paths and sends each of the divided intent requests to the corresponding network. The orchestrator provides a communication path based on the combination of transmission paths in which all networks have accepted the intent request. [Effects of the Invention]

[0008] According to the present invention, resource information for each transmission path is acquired from each network in advance and combined to manage the end-to-end quality of the combination of the transmission paths of each network. Then, the intent request is divided for each network based on the combination of transmission paths whose end-to-end quality satisfies the intent request, and the divided intent requests are sent to the corresponding networks, respectively. This significantly reduces the possibility that each network will reject the intent request. Therefore, even if the divided intent is rejected during the planning and execution stages before deployment, the desired intent can be deployed in a short time. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a functional block diagram showing the configuration of the main parts of a mobile network and its management and operation system to which the present invention is applied. [Figure 2] FIG. 10 is a diagram showing a sequence of a preliminary operation. [Figure 3] FIG. 10 is a diagram showing an example of resource information transmitted by a base station network. [Figure 4] FIG. 10 is a diagram illustrating an example of resource information transmitted by a transport network. [Figure 5] FIG. 10 is a diagram showing an example of resource information transmitted by a mobile core network. [Figure 6] FIG. 10 is a diagram illustrating an example of end-to-end intent information. [Figure 7] FIG. 10 is a sequence diagram of an orchestrator that receives a service intent. [Figure 8] FIG. 10 is a diagram illustrating an example of decomposing an end-to-end resource intent into resource intents for each mobile core network. [Figure 9] FIG. 10 is a sequence diagram showing a first re-search procedure. [Figure 10] FIG. 10 is a sequence diagram showing a second re-search procedure. [Figure 11A]FIG. 10 is a sequence diagram (part 1) showing the third re-search procedure. [Figure 11B] FIG. 10 is a sequence diagram (part 2) showing the third re-search procedure. [Figure 11C] FIG. 10 is a sequence diagram (part 3) showing the third re-search procedure. [Figure 12] FIG. 10 is a sequence diagram showing an example of adaptation to a network that does not support advance transmission of resource intent. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Fig. 1 is a functional block diagram showing the configuration of the main parts of a mobile network to which the present invention is applied and a control system for managing and operating the same. A mobile network is a network that is built and operated by telecommunications carriers, local companies, local governments, etc. for the purpose of 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 deliver 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] When the orchestrator 10 receives a service intent from a user, it has the function of decomposing the service intent into resource intents for each domain, and the function of requesting each resource intent from the corresponding domain and determining an operation based on the response of either acceptance or denial. Of the functions of the orchestrator 10, the function of determining an operation based on the response of either 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 DB 20 stores information about resource intents acquired from each domain. The resource intents are 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 by combining resource intent information acquired from each domain. In this embodiment, the orchestrator 10 combines the information stored in the resource intent DB 20 and stores the result in the end-to-end intent DB 30.

[0018] The transmission controller 40 is a communication device that collects resource intents from a mobile network and transmits them to the orchestrator 10. The resource intents transmitted by the transmission controller 40 include information that indicates the network status. Specifically, this information includes 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 roughly divided into pre-operations performed before accepting a service intent from a user and operations performed after accepting the service intent. Fig. 2 shows the sequence of pre-operations, and Figs. 7, 9-11 show the sequences of operations after acceptance.

[0020] 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, in which 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, values ​​of delay (msec), packet loss rate (%), and bandwidth (Gbps) when communicating between each base station / CU are registered.

[0021] In step S102, 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 delay (msec) when transmitting between the base stations 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] The processes of steps S101-S103 can be performed in parallel, and the transmission controller 40 can transmit resource information of the base station network NW1 to the orchestrator 10 in advance 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 information of the base station network NW1, the transport network NW2, and the mobile core network NW3 at the time of reference is combined and treated as one 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] FIG. 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 the resource intent information sent 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 latency (msec) is the latency between base station and CU + latency between CU and mobile core, E2E packet loss is 1-(1-latency between base station and CU) (1-latency between CU and mobile core), and E2E bandwidth is min{latency between base station and CU, latency between CU and mobile core}.

[0029] Next, with reference to the sequence diagram of FIG. 7, the subsequent operations of the orchestrator 10 that have received 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 end-to-end resource intent is converted 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 decomposes 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] In this embodiment, as shown in an example in Figure 8, the 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 decomposed 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.

[0033] However, since the specific numerical values ​​(such as 10Gbps bandwidth) will be determined in step S204 described later, the framework here is limited to 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 resolved in step S202 is to be requested from each network.

[0035] As explained above with reference to Figure 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 you select base station ID 102, CU Sapporo, and mobile core Tokyo, it turns out 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 10 Gbps or more, delay 20 msec or less, packet loss 1% or less) decomposed in step S202 are selected from the end-to-end intent DB30 referenced in step S203.

[0037] For example, when referring to the end-to-end intent DB 30 shown in FIG. 6, an example of a selection to realize the end-to-end resource intent (bandwidth 10 Gbps or more, delay 20 msec or less, packet loss 1% or less) is as follows:

[0038] (1) Base station network (base station ID 102 to Sapporo CU): Bandwidth 25 Gbps, latency 1-2 msec, packet loss rate 0.1%

[0039] (2) Transport network (Sapporo to Tokyo): Delay 3-4 msec

[0040] (3) Mobile core network (Sapporo CU to Tokyo Mobile Core): Bandwidth 25 Gbps, latency 2-5 msec, packet loss rate 0.05%

[0041] In step S205, the orchestrator 10 requests the base station network NW1 for the determined resource intent (for example, bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1%).

[0042] 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 later) is acceptance.

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

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

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

[0046] Next, a re-search procedure for modifying the resource intent and making a re-request when the mobile networks (NW1, NW2, NW3) reject the resource intent request from the orchestrator 10 will be described using three examples.

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

[0048] In step S301, a resource intent (e.g., bandwidth 25 Gbps, delay 1-2 msec, packet loss rate 0.1%) is requested from the base station network NW1. If the base station network NW1 rejects the request in step S302, the rejected resource intent is removed from the selection list in step S303, and the next candidate is selected.

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

[0050] 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 the transport network NW2.

[0051] In step S305, if the transport network NW2 responds with an acceptance, the process proceeds to step S306, where a resource intent (for example, bandwidth 25 Gbps, delay 2-5 msec, packet loss rate 0.05%) is requested from the mobile core network NW3.

[0052] In step S307, if the mobile core network NW3 responds with a rejection, the process proceeds to step S308, where the target of the rejected resource intent is excluded from the selection, and the next candidate is selected.

[0053] For example, if the combination of the Tokyo CU and the Tokyo mobile core is rejected, a combination that does not include the rejected Osaka mobile core, such as the combination of the Tokyo CU and the Osaka mobile core, is selected. 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.

[0054] 10 is a sequence diagram showing a second re-search method by the orchestrator 10, in which a search is again performed for candidates in which the numerical values ​​or conditions given 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 explained using as an example a case in which the examination result from the base station network NW1 and the mobile core network NW3 is a rejection response.

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

[0056] 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 result of the examination 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.

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

[0058] 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, the system searches the end-to-end intent database for 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%, and selects it.

[0059] FIG. 11 (FIGS. 11A, 11B, and 11C) is a sequence diagram showing a third re-search method by the orchestrator 10, and here, a re-search method by updating the resource intent will be described.

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

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

[0062] 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 one piece of 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.

[0063] 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, when the transport network NW2 responds with acceptance, the process proceeds to step S701 in FIG. 11C.

[0064] 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 returns a rejection response in step S702, the orchestrator 10 proceeds to step S703, where it requests the mobile core network NW3 to update the resource information.

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

[0066] 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 one 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.

[0067] Next, with reference to the sequence diagram of FIG. 12, a method for networks that do not support advance transmission of resource intent (for example, interconnected networks, the Internet) will be described.

[0068] 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 resource intent request response (acceptance or denial) 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.

[0069] 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 pre-transmission of resource intents.

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

[0071] Therefore, it will be possible to contribute to Goal 9 of the United Nations-led Sustainable Development Goals (SDGs), "Build resilient infrastructure and promote inclusive and sustainable industrialization," and Goal 11, "Make cities inclusive, safe, resilient and sustainable." [Explanation of symbols]

[0072] 10... Orchestrator, 20... Resource Intent DB, 30... End-to-end Intent DB, 40... Transmission Controller, NW1... Base Station Network, NW2... Transport Network, NW3... Mobile Core Network

Claims

1. A network control system that provides a communication path that satisfies a predetermined intent request between end-to-end via multiple networks in different domains, an orchestrator and first and second databases; The orchestrator: Acquire resource information from each network for each transmission path of the network in advance and store it as resource intent information in a first database; Based on the resource intent information, end-to-end intent information combining transmission paths of each network is managed in advance in a second database; selecting a combination of transmission paths that satisfies the intent request based on the end-to-end intent information; Dividing the intent request into networks based on the selected combination of transmission paths; Sending the divided intent requests to the corresponding networks respectively; A network control system characterized in that all networks provide communication paths based on a combination of transmission paths that have accepted the divided intent requests.

2. The network control system according to claim 1 , wherein the orchestrator transmits a new intent request to the network that rejected the divided intent request, the new intent request being different from the rejected intent request.

3. The network control system according to claim 1, wherein the orchestrator sends a new intent request to the network that rejected the split intent request, the new intent request having relaxed at least one of the numerical values ​​and conditions of the rejected intent request.

4. The orchestrator requests the network that rejected the divided intent request to update resource information, and acquires the updated resource information; updating the first and second databases based on the updated resource information; 2. The network control system according to claim 1, wherein a combination of transmission paths that satisfies the intent request is reselected based on the updated end-to-end intent information.

5. The orchestrator further comprises means for transmitting a resource intent request to a network for which no record of intent information exists in the first and second databases; 2. The network control system according to claim 1, wherein intent information is stored in advance in the first and second databases based on resource information returned from each network in response to the resource intent request.

6. 6. A network control system according to claim 1, wherein each of said networks is a mobile network.

7. A network control method in which a computer provides an end-to-end communication path that satisfies a predetermined intent request via multiple networks in different domains, comprising: Acquire resource information from each network for each transmission path of the network in advance and store it as resource intent information in a first database; Based on the resource intent information, end-to-end intent information combining transmission paths of each network is managed in advance in a second database; selecting a combination of transmission paths that satisfies the intent request based on the end-to-end intent information; Dividing the intent request into networks based on the selected combination of transmission paths; Sending the divided intent requests to the corresponding networks respectively; A network control method characterized in that all networks provide communication paths based on a combination of transmission paths that have accepted the divided intent requests.

8. The network control method according to claim 7, further comprising the step of: transmitting a new intent request different from the rejected intent request to the network that rejected the divided intent request.

9. The network control method according to claim 7, further comprising the step of: making a new request to the network that rejected the divided intent request by relaxing at least one of the numerical values ​​and conditions of the rejected intent request.

10. requesting the network that rejected the divided intent request to update resource information, and acquiring the updated resource information; updating the first and second databases based on the updated resource information; 8. The network control method according to claim 7, further comprising the step of: reselecting a combination of transmission paths that satisfies the intent request based on the updated end-to-end intent information.

11. A network control program that provides a communication path that satisfies a predetermined intent request between end-to-end via multiple networks in different domains, a step of acquiring resource information from each network for each transmission path of the network in advance and storing the resource information as resource intent information; a procedure for managing end-to-end intent information combining transmission paths of each network based on the resource intent information; selecting a combination of transmission paths that satisfies the intent request in the end-to-end intent information; dividing the intent request into networks based on the selected combination of transmission paths; a step of transmitting the divided intent requests to corresponding networks respectively; and a procedure for providing a communication path based on a combination of transmission paths for which all networks have accepted the divided intent requests.

Images