Request reception amount control device, request reception amount control method, and program

Abstract

A server (101) serving as a request reception amount control device for controlling the amount of requests that can reduce the processing capability of a CPU (32) comprises: a processing capability information acquisition unit (110) that acquires processing capability information about the requests from a terminal (2) that the CPU (32) can process per unit time; a request upper limit amount determination unit (120) that, on the basis of the processing capability information acquired by the processing capability information acquisition unit (110), determines an upper limit of the amount of requests the CPU (32) can receive per unit time; and a request reception restriction unit (140) that restricts the requests per unit time from the terminal (2) on the basis of the upper limit amount information about the upper limit of the amount of requests the CPU (32) can receive per unit time.

Description

Request acceptance amount control device, request acceptance amount control method and program

[0001] The present invention relates to a request acceptance amount control device, a request acceptance amount control method, and a program.

[0002] An overview of the wireless access system will now be described. Fig. 8 is a diagram illustrating the overview of the wireless access system. As shown in Fig. 8, the wireless access system includes an antenna (base station antenna) 20 and a base station (BBU: Base Band Unit) 30, and is communicably connected to a terminal 2 and a core network 40.

[0003] The antenna 20 is an antenna that wirelessly communicates with a user's terminal 2. The transmission and reception data communicated between the terminal 2 and the antenna 20 is superimposed on wireless data, transmitted to and received from the base station 30 via a dedicated cable, and decoded by a transmission and reception unit (not shown).

[0004] The base station 30 is a stationary radio station established on land that communicates with the terminal 2. The base station 30 that performs radio signal processing is dedicated hardware for performing radio signal processing. Alternatively, the base station 30 is a virtual radio access network (vRAN) that performs radio signal processing in a signal processing aggregation system of LTE (Long Term Evolution) or 5G (fifth generation) using a general-purpose server. In a vRAN, a general-purpose server that is inexpensive and available in large quantities can be used as the hardware for the base station 30. The base station 30 includes hardware 31, a central processing unit (CPU) 32 on the hardware, an OS 33, a radio signal processing task 1-1 of an L1 protocol, a radio signal processing task 1-2 of an L2 protocol, a radio signal processing task 1-3 of an L3 protocol, and a task scheduler unit 34.

[0005] The core network 40 is an EPC (Evolved Packet Core) / (in the following description, " / " indicates "or") 5GC (5G Core Network) or the like.

[0006] An example of a system that requires real-time performance is a base station (BBU) in a RAN. The base station 30 performs calculations using a CPU 32. In many cases, the base station 30 performs calculations by having a task scheduler unit 34 assign wireless signal processing tasks to each of the cores 32a to 32e of the CPU 32.

[0007] FIG. 9 is a diagram illustrating an example of task management for wireless access processing in the base station 30. Components that are the same as those in FIG. 8 are assigned the same reference numerals. The base station 30 includes a task scheduler unit 34. The task scheduler unit 34 has a task management unit 341 and task queues 37a to 37e. The task management unit 341 assigns priorities to the wireless signal processing tasks 1-1 to 1-3 and allocates them to the task queues 37a to 37e. The task scheduler unit 34 then assigns the tasks allocated to the task queues 37a to 37e by the task management unit 341 to the cores 32a to 32e of the CPU 32.

[0008] [LPI (Low Power Idle) Hardware Control] The CPU 32 has a function for controlling the idle state of the CPU 32 through hardware control, which is called the LPI hardware control function. The LPI hardware control function is often referred to as CPU idle or C-state, and the idle state of the LPI hardware control function will be described below. In the idle state, when the CPU load decreases, the CPU 32 attempts to save power by turning off the power to part of the CPU 32 circuit (Non-Patent Document 1).

[0009] FIG. 10 is a table showing an example of a CPU idle state. Note that state definitions vary depending on the CPU hardware, and FIG. 10 is merely a reference example. As shown in FIG. 10, CPU idle states are classified into grades C0 to C6, and the longer the time that the CPU 32 is unloaded, the deeper the idle state becomes. While a deeper idle state reduces CPU power consumption, the deeper the idle state becomes, the longer it takes to return to normal operation, which can be an issue in terms of low latency.

[0010] The definition of the idle state varies depending on the CPU hardware. For example, there are models that do not have C4 or C5, and models in which the state after C1 is C1E. The deeper the state, the greater the power saving effect, but the longer it takes to return from the idle state.

[0011] Furthermore, the depth to which the idle state of the CPU 32 transitions is controlled by the CPU hardware and depends on the CPU product, which means that it is often not possible to control it from the kernel of the OS 33 or the like.

[0012] 11 is a table showing an example of the maximum value of the time required to transition to a state (RESIDENCY) and the time required to return to normal (WAKE-UP LATENCY). Fig. 11 shows C-state information for an Intel Xeon CPU E5-26X0 v4 (registered trademark).

[0013] [CPU Idle Governor] Linux kernel 4 (registered trademark) provides two types of CPU idle governors to manage the CPU idle state (C-state).

[0014] There are two types of CPU idle governors: ladder governors for systems with periodic processing and menu governors for systems without periodic processing. A ladder governor initially allows only the shallowest idle state transitions, and if there are no tasks until the periodic processing, it gradually transitions to deeper idle states. However, if there is no periodic processing, the system remains in a shallow idle state, so it must be based on periodic processing. A menu governor uses a heuristic approach to estimate idle periods and idle states. For example, the menu governor estimates the next idle period based on the last eight idle periods and transitions to an idle state appropriate for that idle period. This allows the menu governor to directly transition to a deeper idle state. The menu governor used in systems without periodic processing uses the results of the most recent idle period to estimate the depth of the idle state appropriate for the next idle period. The menu governor is effective for workloads with regular idle times, but its effectiveness is limited for irregular workloads.

[0015] FIG. 12 is a diagram illustrating an outline of the logic of the menu governor. As shown in FIG. 12, the menu governor records the most recent idle time (step S30). Then, the menu governor estimates the next idle time (step S31). For example, based on the idle time recorded in step S30, if the deviation is small, the average value is adopted as the next idle time. Based on the estimate of the next idle time, the menu governor estimates an appropriate idle state depth (step S32). For example, if the estimated value of the next idle time is equal to the recovery time from the idle state, it is determined that the idle state is too deep, and a transition to a shallower idle state Cx-1 is made.

[0016] Neither of the two types of governors mentioned above, the ladder governor and the menu governor, has a mechanism to issue a pre-wake-up command from the idle state to return to preparation when a new task arrives. As a result, when a task is assigned while the system is in a deep idle state, a delay corresponding to the time it takes to return to the idle state occurs.

[0017] 10, the idle state of the CPU 32 has grades C1 to C6, and as the time during which the CPU 32 is not loaded increases, the CPU transitions to a deeper idle state. A deeper idle state reduces CPU power consumption, but on the other hand, the time required for recovery increases accordingly, which may pose a problem in terms of low latency.

[0018] 13 and 14 are C-state transition images of the CPU core used for calculations. The horizontal axis indicates elapsed time, and the vertical axis indicates idle state grades C0 to C6. FIG. 13 shows a case where the no-task time is short, and FIG. 14 shows a case where the no-task time is long. The period P shown in FIG. 13 ０ is a period during which the CPU 32 is performing a certain task. １ indicates the period after this task processing is completed and there are no tasks. At this time, the CPU has transitioned to the C2 state via the C1 state. ０ A new task occurs during the period P ２ is the delay period until the CPU returns from the C2 state to the C0 state. After the CPU transitions to the C0 state, the period P ３ At time t ０ Similarly, the task that occurred during the period P shown in FIG. ４ is the period during which the CPU is performing task processing. ５ indicates the time when the task processing has finished and there are no other tasks. At this time, the CPU is gradually transitioning from the C1 state to the C5 state. １ A new task occurs during the period P ６ is the period from the occurrence of this task to the start of new task processing, and is the delay period until the CPU returns from the C5 state to the C0 state. ７ At time t １ The task that occurred in is executed.

[0019] As shown in FIG. 13, the time t ０ The CPU core is in a shallow idle state at ２ However, as shown in FIG. 14, the time t０ If the CPU core is in a deep idle state, the period until recovery is P ６ is longer than the example shown in Fig. 13. In other words, if the CPU core falls into a deep idle state, it takes a long time to return to normal, and real-time performance is impaired.

[0020] The extension of the delay period until recovery as described above is a problem that cannot be ignored in a system in which real-time performance is given top priority, such as the base station 30 shown in Figures 8 and 9. For this reason, the base station (BBU) takes measures such as disabling transition to the idle state or setting the idle state transition to a limited depth, such as the C1 state. In other words, tuning may be performed to aim for real-time performance at the expense of power saving.

[0021] In conventional base stations (BBUs), once the base station falls into a deep idle state, there is no option but to wait until it recovers. For this reason, measures were taken to prevent the base station from falling into a deep idle state, at the expense of power saving.

[0022] CPU Performance Scaling, 2017 Intel Corporation, Rafael J. Wysocki, [online], [Retrieved March 1, 2024], Internet〈URL:https: / / docs.kernel.org / admin-guide / pm / cpufreq.htm〉

[0023] It is desirable for the processing in the general-purpose server shown in Figure 9 to be executed with "minimum power consumption to meet performance requirements," but with the performance-oriented configuration and settings described above, even when the required processing power is low, such as when the load is light, excessively high performance is maintained, resulting in excessive power consumption.

[0024] Here, by applying the above-mentioned existing power-saving technology to a general-purpose server, it is possible to increase or decrease the processing capacity according to the load and suppress excessive power consumption. However, when applying the existing power-saving technology to the general-purpose server shown in Figure 9, the following problems arise.

[0025] FIG. 15 is a diagram showing an image of an increase or decrease in processing performance due to existing power-saving technology. The horizontal axis indicates time, and the vertical axis indicates the load (bold solid line) and processing performance (bold dashed line). The existing power-saving technology shown in FIG. 15 reduces processing capacity to save power based on the load over a certain period of time in the past. １２ indicates the period during which the load decreases. １３ indicates the period during which the load increases. １２ Based on the decrease in the load at time t １２ At this timing, a governor (not shown) determines that the processing capacity is to be reduced, and reduces the processing capacity until the load amount increases, thereby saving power. １３ When the load increases at time t １３ The governor determines the increase in processing capacity at the timing of (a) and increases the processing capacity. The existing power saving techniques shown in Fig. 15 are often capable of dealing with gradual increases and decreases in load.

[0026] The existing power-saving technology shown in Figure 15 increases or decreases processing capacity according to the load amount, and determines whether to expand or reduce processing capacity by sequentially measuring the load amount or statistically predicting the load amount. However, if user demand increases while processing capacity is being reduced, it cannot guarantee that performance requirements will be met. In particular, the existing power-saving technology shown in Figure 15 can handle gradual load increases, but has difficulty handling sudden load increases. This will be explained below with reference to Figure 16.

[0027] 16 is a diagram showing an example of a case where existing power-saving technologies cannot cope with an increase in load. The horizontal axis represents time, and the vertical axis represents the load (bold solid line) and processing performance (bold dashed line). １４ indicates the period during which the load decreases. １４ indicates the period during which the load increases. １４ Due to the decrease in the load at time t １５ The governor determines the reduction in processing capacity at the timing of period P １５ Based on the increase in the load, at time t １５ The governor determines to increase the processing capacity at the timing of the period P shown in FIG. １５The increase in the load amount in the period P １３ This is a rapid and sudden increase compared to the increase in the load in the

[0028] The period P shown in FIG. １５ The load increase in the system is a sudden and unexpected increase in load that cannot be predicted by sequential load measurements or statistical load forecasts. When the load increases, the governor determines that the processing capacity has increased, but as shown by the load significantly exceeding the processing capacity due to such a sudden load increase, the processing capacity is exceeded. This causes a temporary shortage of processing capacity until the power saving function is deactivated.

[0029] When requests from external devices suddenly increase, the increase in processing capacity due to disabling (or limiting) the power saving function may not be able to keep up with the increased load. If the increase in processing capacity is not enough to keep up with the increased load, performance requirements will not be met, resulting in errors and retransmissions. As such, there is a problem in that it is difficult to respond to a sudden increase in requests from external devices or increased load when processing capacity is reduced.

[0030] The present invention was made in light of this background, and its objective is to reduce the possibility of errors or delays due to retransmissions occurring when the number of requests from external devices increases in a system in which processing capacity is degraded.

[0031] In order to solve the above-mentioned problems, a request reception volume control device capable of degrading the processing capacity of a processor is provided, which is characterized by comprising: a processing capacity information acquisition unit that acquires processing capacity information at which the processor can process requests from an external device per unit time; a request upper limit volume determination unit that determines the upper limit volume of requests that the processor can accept per unit time based on the processing capacity information acquired by the processing capacity information acquisition unit; and a request reception limit execution unit that limits requests per unit time from the external device based on the upper limit volume information of requests that the processor can accept per unit time.

[0032] According to the present invention, in a system in which processing power is degraded, it is possible to reduce the possibility of delays due to errors or retransmissions occurring when the number of requests from external devices increases.

[0033] 1 is a schematic configuration diagram of a network system including a request reception amount control device according to a first embodiment of the present invention. FIG. 2 is a diagram illustrating request load volume and processing performance after the introduction of the first embodiment of the present invention. FIG. 3 is a flowchart illustrating request reception amount control processing of the request reception amount control device according to the first embodiment of the present invention. FIG. 4 is a schematic configuration diagram of a network system including a request reception amount control device according to a second embodiment of the present invention. FIG. 5 is a diagram illustrating a table of upper limit request volumes according to frequencies held by a power saving function usage information acquisition unit of the request reception amount control device according to the second embodiment of the present invention. FIG. 6 is a schematic configuration diagram of a vRAN system including a request reception amount control device according to a third embodiment of the present invention. FIG. 7 is a hardware configuration diagram of a server according to an embodiment of the present invention. FIG. 8 is a diagram illustrating an overview of a wireless access system. FIG. 9 is a diagram illustrating an example of task management for wireless access processing in a base station. FIG. 10 is a diagram illustrating an example of C-state states in a table. FIG. 11 is a diagram illustrating an example of maximum values ​​of the time required to transition to a state (RESIDENCY) and the time required for recovery (WAKE-UP LATENCY) in a table. FIG. 12 is a diagram illustrating an overview of the logic of a menu governor. FIG. 13 is an image diagram of C-state transitions of a CPU core used for calculations. FIG. 14 is an image diagram of C-state transitions of a CPU core used for calculations. FIG. 1 is a diagram illustrating a case where existing power-saving techniques cannot cope with an increase in load.

[0034] Hereinafter, a network system and the like in an embodiment for carrying out the present invention (hereinafter referred to as "the present embodiment") will be described with reference to the drawings. (First Embodiment) Fig. 1 is a schematic diagram of a network system including a request reception amount control device according to a first embodiment of the present invention.

[0035] As shown in FIG. 1, a server 101 constituting a network system 1000 includes hardware 31, an OS 33, and a request processing unit 102 and a request reception amount control unit 100 (request reception amount control device) in a user space 35. The hardware 31 includes a CPU 32 including cores 32a to 32e. The CPU 32 is a processor that can transition to a power-saving state to reduce its own processing capacity. The server 101 can transition to a power-saving state to reduce the processing capacity of the CPU 32. The request processing unit 102 causes the CPU 32 to process requests from terminals 2 and acquires load information processed by the CPU 32 per unit time.

[0036] [Request Acceptance Amount Control Unit 100] The request acceptance amount control unit 100 accepts requests from a user terminal 2 in a server 101 in which the processing capacity of the CPU 32 is degenerated. The request acceptance amount control unit 100 includes a processing capacity information acquisition unit 110, a request upper limit amount determination unit 120, a request acceptance amount determination unit 130, and a request acceptance limit execution unit 140.

[0037] <Processing Capacity Information Acquisition Unit 110> The processing capacity information acquisition unit 110 acquires request processing capacity, including the time required to process a request, from an external device such as the terminal 2, and notifies the request upper limit amount determination unit 120. As examples of information to be acquired or notified, the processing capacity information acquisition unit 110 acquires the time required to process a request, and acquires processing capacity information on requests that can be processed per unit time.

[0038] <Request upper limit amount determination unit 120> The request upper limit amount determination unit 120 receives processing capacity information indicating the processing capacity at which the CPU 32 can process requests from the terminal 2 per unit time, and determines the upper limit amount of requests that the CPU 32 can accept per unit time. The request upper limit amount determination unit 120 then notifies the request acceptance amount determination unit 130 of the upper limit amount of requests that the CPU 32 can accept per unit time. As examples of the upper limit amount of requests that the CPU 32 can accept per unit time, the request upper limit amount determination unit 120 notifies the request acceptance amount determination unit 130 of the maximum number of users, the maximum number of requests per second per user, etc. In other words, the request upper limit amount determination unit 120 determines the upper limit amount of requests that the CPU 32 can accept per unit time based on the processing capacity information acquired by the processing capacity information acquisition unit 110.

[0039] <Request Acceptance Amount Determination Unit 130> The request acceptance amount determination unit 130 determines the limit amount of requests per unit time and / or the restriction method based on information about the upper limit amount of requests that can be accepted per unit time by the CPU 32. As output examples of the request limit per unit time, the request acceptance amount determination unit 130 determines the number of accepted users, the allowable amount of requests per second, and schedule information for wireless resources.

[0040] <Request acceptance restriction execution unit 140> The request acceptance restriction execution unit 140 rejects sessions from terminals 2 in a number that exceeds the upper limit, rejects requests that exceed the upper limit amount of requests per unit time, and / or distributes information on the restricted amount of communication resources to terminal 2 to restrict requests that exceed the upper limit amount per unit time from terminal 2. In other words, the request acceptance restriction execution unit 140 restricts requests per unit time from external devices such as terminal 2, based on information on the upper limit amount of requests that the processor can accept per unit time.

[0041] The operation of the request acceptance amount control unit 100 configured as described above will be described below. [Basic Concept] When increasing or decreasing the processing capacity of the CPU 32, the present invention sequentially links information about the processing capacity of the CPU 32 with the request acceptance amount determination unit 130. The present invention limits the request acceptance amount so that requests that exceed the processing capacity of the CPU 32 do not arrive in a unit time, thereby preventing a shortage of processing capacity. As a result, when a user increases the amount of requests per unit time, even if the increase in processing capacity due to disabling the power saving function is not enough, delays due to errors or retransmissions will not occur.

[0042] 2 is a diagram showing the load of requests and the processing performance of requests after the implementation of this embodiment. FIG. 2 is a diagram corresponding to FIG. 16. The horizontal axis indicates time, and the vertical axis indicates the load and processing performance. The thick solid line indicates the load, and the thick dashed line indicates the processing performance. During the period P shown in FIG. ２０ indicates the period during which the load decreases. ２１ indicates the period during which the load increases. ２１ The period P following ２２ is a period during which the load amount increases in the conventional example, but is a period during which the increase in the load amount from the terminal 2 is suppressed. ２０ Based on the decrease in the load at time t １０ The processing power of the CPU 32 is degraded at the timing of ２１ The load suddenly increases during the period P ２２ is the time t when the power saving function is released. １１ This is a period in which the amount of requests from terminal 2 is adjusted until the timing of

[0043] In this embodiment, when it is determined that the processing capacity is to be increased, the processing capacity is increased at time t １１ The period P until the power saving function is released ２２2, when the processing capacity is degraded, requests from external devices are limited so that requests that exceed the processing capacity are not received, thereby preventing a shortage of processing capacity. As a result, by limiting the request load rather than the processing capacity until the power saving function of the CPU 32 is released, it is possible to satisfy the performance requirements during this period and prevent errors and retransmissions.

[0044] 1, the control of the service acceptance amount means that requests that would cause a load exceeding the request processing capacity cannot be executed. In this mode, the amount of requests from external devices such as the terminal 2 is adjusted until the power saving function of the CPU 32 is released, and it appears at first glance that requests from users are not responded to, that is, user requests are ignored. However, during the period P １５ In the case of an increase in the load amount of a request from an external device, even if the request is responded to, if the increase in the load amount exceeds the processing capacity, the request will not be processed even if it is received, and errors or retransmissions will occur repeatedly. Therefore, it is the same in that requests from users cannot be responded to. In this embodiment, if requests from external devices increase while the processing capacity is reduced, the processing capacity can be increased in time by disabling the power saving function, and the performance requirements can be achieved.

[0045] [Operation Flow of the Request Acceptance Amount Control Unit 100] Figure 3 is a flowchart showing the request acceptance amount control process of the request acceptance amount control unit 100. This flow is activated periodically while the network system is running. In step S11, the processing capacity information acquisition unit 110 acquires information on the processing capacity of the CPU 32 from the request processing unit 102 or the OS 33. Here, the processing capacity information acquisition unit 110 acquires the time required for the CPU 32 to process one request. In step S12, the request upper limit amount determination unit 120 determines whether there has been a change in the upper limit amount of requests that the CPU 32 can accept per unit time. An example of determining whether there has been a change in the upper limit amount of requests that the CPU 32 can accept per unit time will be described.

[0046] <Example of Determining Whether the Upper Limit Amount of Requests Acceptable by the CPU 32 Per Unit Time Has Changed> As an example of determining whether the upper limit amount of requests acceptable by the CPU 32 per unit time has changed, let us consider a case where the CPU 32 receives the time t required to process one request. A lower limit percentage threshold a and an upper limit percentage threshold b are determined in advance (e.g., a = 0.9, b = 1.1). If the time t is smaller than the value obtained by multiplying the lower limit percentage threshold a by the time s required to process the request received in the previous interval, it is assumed that the processing delay has significantly decreased, the processing capacity has improved, and the upper limit amount has increased. Therefore, a notification is issued that the number of requests per second that can be accepted has increased by (s / t). On the other hand, if the time t is greater than the value obtained by multiplying the upper limit percentage threshold b by the time s required to process the request received in the previous interval, it is assumed that the processing delay has significantly increased, the processing capacity has decreased, and the upper limit amount has decreased. Therefore, a notification is issued that the number of requests per second that can be accepted has increased by (s / t).

[0047] 3, if the request upper limit amount determination unit 120 determines in step S13 that there is a change in the upper limit amount of requests that the CPU 32 can accept per unit time (S13: Yes), the process proceeds to step S14, but if there is no change in the upper limit amount (S13: No), the process of this flow ends.

[0048] In step S14, the request upper limit amount determination unit 120 notifies the request acceptance amount determination unit 130 of the changed information on the upper limit amount of requests that can be accepted by the CPU 32 per unit time. Here, an example is taken of the case where the information on the upper limit amount of requests that can be accepted by the CPU 32 per unit time is set as information on the upper limit amount of requests per second that can be accepted by the CPU 32.

[0049] In step S15, the request acceptance amount determination unit 130 determines whether or not it is necessary to change the current request acceptance policy based on the upper limit amount received from the request upper limit amount determination unit 120. An example of determining whether or not it is necessary to change the current request acceptance policy will be described.

[0050] <Example of Determining Whether the Current Request Acceptance Policy Needs to Be Changed> Take the case where an acceptable request volume per second m has been received as an example. The request processing unit 102 passes the request volume per second of the requests currently accepted from the terminal 2 as m to the request acceptance limit enforcement unit 140. In this case, if the network system has strict deadlines, a possible example would be to use a constant 0<k<1 and set (k×m) as the upper limit of the request acceptance volume. The request acceptance volume determination unit 130 also determines the method for enforcing the limit; for example, possible methods include restricting the network bandwidth so that the request volume per second does not exceed m, or rejecting requests from the user if it exceeds m.

[0051] Returning to the flow of FIG. 3, in step S16, the request acceptance amount determining unit 130 determines whether or not it is necessary to change the request acceptance policy.

[0052] If the request reception policy needs to be changed (S16: Yes), the process proceeds to step S 17. If the request reception policy does not need to be changed (S16: No), the process of this flow ends.

[0053] In step S17, the request acceptance amount determination unit 130 notifies the request acceptance limit execution unit 140 of the changed request acceptance policy and limiting method. The request acceptance limit execution unit 140 then executes the request acceptance limit based on the request acceptance policy determined by the request acceptance amount determination unit 130, and ends the processing of this flow.

[0054] <Example of Operation of the Request Acceptance Limit Executor 140> The request acceptance limit executer 140 limits the requests per unit time from the external device in accordance with the decision made by the request acceptance amount determiner 130. Examples of this limit include a method of setting a network bandwidth limit for a switch or router, and a method of setting an upper limit on the function for accepting requests or connection establishment requests from terminal 2 and rejecting requests or connection establishment requests that exceed this upper limit.

[0055] Second Embodiment Fig. 4 is a schematic configuration diagram of a network system including a request reception volume control device according to a second embodiment of the present invention. Components that are the same as those in Fig. 1 are assigned the same reference numerals, and explanations of overlapping parts will be omitted. This embodiment is an example in which the network system is applied to a CPU. This embodiment can also be applied to processors other than CPUs, such as GPUs (Graphic Processing Units), FPGAs (Field Programmable Gate Arrays), and ASICs (Application Specific Integrated Circuits), if they have a function to transition to a power-saving state and degrade the processing power of the processor.

[0056] As shown in FIG. 4, a server 101 constituting a network system includes hardware 31, an OS 33, and a request processing unit 102 and a request acceptance amount control unit 100A (request acceptance amount control device) in a user space 35. The hardware 31 includes a CPU 32 including cores 32a to 32e. The CPU 32 is a processor that can transition to a power-saving state to reduce its own processing capacity. The server 101 can transition to a power-saving state to reduce the processing capacity of the CPU 32. The request acceptance amount control unit 100A includes a processing capacity information acquisition unit 110, a request upper limit amount determination unit 120, a request acceptance amount determination unit 130, a request acceptance limit execution unit 140, and a power-saving function usage information acquisition unit 150.

[0057] <Power saving function usage information acquisition unit 150> When the method for reducing the processing capacity of the CPU 32 is a power saving function that reduces power consumption by gradually reducing the operating state of the processor in accordance with the processing load of the processor, the power saving function usage information acquisition unit 150 acquires the power saving function as power saving function information. The power saving function usage information acquisition unit 150 acquires the power saving functions of the CPU 32, which is the processor, and notifies the processing capacity information acquisition unit 110 of the power saving function information. Examples of the information acquired and notified include information on the idle state of the cores 32a to 32e of the CPU 32 and the recovery time required to recover from the corresponding idle state.

[0058] Furthermore, when the processing capacity degeneration method is a power saving function that reduces power consumption by gradually reducing the operating state of the CPU 32, which is a processor, in accordance with the processing load of the CPU 32, the power saving function usage information acquisition unit 150 acquires the power saving state of the CPU 32. In this case, the request upper limit amount determination unit 120 determines the upper limit amount of requests that the CPU 32 can accept per unit time, based on the processing capacity of the CPU 32 in the power saving state.

[0059] Furthermore, if the power saving function is scaling the number of cores of the CPU 32 and enabling the idle state, the power saving function usage information acquisition unit 150 acquires information about the idle state of the cores 32 a to 32 e and the recovery time required to recover from this idle state. In this case, the request upper limit amount determination unit 120 determines the upper limit amount of requests that the CPU 32 can accept per unit time based on the information about the idle state of the cores 32 a to 32 e.

[0060] If the power saving function is CPU frequency control, the power saving function usage information acquisition unit 150 acquires CPU frequency information. In this case, the request upper limit amount determination unit 120 determines the upper limit amount of requests that the CPU 32 can accept per unit time based on the processing capacity of the CPU 32 according to the CPU frequency information.

[0061] The power saving function usage information acquisition unit 150 acquires the time required from the deactivation of the power saving function to the restoration as the restoration time. When the load amount of requests processed by the CPU 32 from external devices such as the terminal 2 per unit time reaches a predetermined ratio of the upper limit amount of requests that the CPU 32 can process, the request reception limit execution unit 140 limits the amount of requests that can be received until the restoration time has elapsed.

[0062] The operation of the request reception amount control unit 100A configured as described above will be described below. <Example of Acquiring Idle Function Utilization Information: Example 1> An example of acquiring idle function utilization information as a power saving function of the power saving function utilization information acquisition unit 150 will be described. One power saving function is a technology that reduces the number of CPU cores that execute request processing to idle according to the load, and utilizes the idle function for the idle cores, thereby saving power. In this case, the request reception amount control unit 100A executes request reception restriction by acquiring and determining the following information.

[0063] The power saving function usage information acquisition unit 150 of the request reception amount control unit 100A acquires information, particularly on idle functions, and determines the processing capacity from the number of active cores and idle cores. Specifically, the power saving function usage information acquisition unit 150 identifies the cores of the CPU 32 that are assigned to request processing. This information can be acquired from the OS 33. The power saving function usage information acquisition unit 150 acquires the usage status of the idle functions in each core of the CPU 32. Specifically, for example, it identifies the time at which each core of the CPU 32 transitions to an idle state, and acquires the extent to which the CPU 32 has fallen into the idle state.

[0064] This makes it possible to know how many cores are currently in an active state executing request processing, and how many cores are in an idle state and have stopped request processing. The power saving function usage information acquisition unit 150 notifies the processing capacity information acquisition unit 110 of the number l of active cores executing request processing and the total number k of cores allocated to request processing. Using the power saving function information sent from the power saving function usage information acquisition unit 150, the processing capacity information acquisition unit 110 notifies the request upper limit amount determination unit 120 that the current processing capacity of the CPU 32 is the maximum processing capacity (l / k) of the CPU 32.

[0065] In FIG. 4, the processing after the request upper limit amount determination unit 120 is the same as the processing operation in FIG. 1, and several examples are possible.

[0066] Example 1: As in the example of determining whether the upper limit amount has changed, a lower limit percentage threshold a and an upper limit percentage threshold b are defined to determine whether the upper limit amount has changed, and the change amount is notified to the request acceptance amount determination unit 130.

[0067] Example 2: The change in the number of cores in use is determined as an absolute value, and if there is a change in the number of cores by two or more, it is determined to be a change, and the request acceptance amount determination unit 130 is notified that the "amount of requests per second that can be processed by one core x change in the number of cores" has changed.

[0068] An example of acquiring information on utilization of the idle function of the CPU 32 is summarized below. The power saving function usage information acquisition unit 150 acquires the usage status of the idle function of the CPU 32. The processing capacity information acquisition unit 110 acquires the number of idle cores among the CPU cores used for request processing, based on the usage status of the idle function of the CPU 32 acquired by the power saving function usage information acquisition unit 150. The request upper limit amount determination unit 120 acquires the amount of reduction in processing capacity and uses it to determine the upper limit amount.

[0069] <Example of CPU Frequency Control Information Acquisition: Example 2> The power saving function usage information acquisition unit 150 acquires CPU frequency control information. The request upper limit amount determination unit 120 determines the request processing capacity per unit time of the CPU 32 based on the CPU frequency control information acquired by the power saving function usage information acquisition unit 150. As a power saving function, power is saved by lowering the CPU frequency in the CPU core that executes request processing. At this time, the request acceptance restriction is implemented based on the following information acquisition and determination.

[0070] The power saving function usage information acquisition unit 150 identifies the number of the CPU core assigned to the request processing. At this time, the power saving function usage information acquisition unit 150 acquires the current operating frequency c and the maximum operating frequency M of the CPU frequency of those cores. The processing capacity information acquisition unit 110 uses the number of the CPU core assigned to the request processing sent from the power saving function usage information acquisition unit 150 to notify the request upper limit amount determination unit 120 that the processing capacity is (c / M). Note that this is just an example, as processing capacity is not necessarily proportional to frequency.

[0071] In Figure 4, the processing after the request upper limit amount determination unit 120 is the same as the processing operation in Figure 1, and several examples are possible. Example 1: As described on the previous page, the CPU 32 determines whether the upper limit amount of requests that can be accepted per unit time has changed by defining a lower limit percentage threshold a and an upper limit percentage threshold b, and notifies the request acceptance amount determination unit 130 of the change amount. Example 2: The CPU clock frequency is determined as an absolute value, a table (Figure 5) of upper limit amounts of requests corresponding to the clock frequency is prepared in advance, and the upper limit amount of requests is notified to the request acceptance amount determination unit 130 by referring to this table (Figure 5).

[0072] FIG. 5 shows a table 50 of upper request amounts according to frequency stored in the power saving function usage information acquisition unit 150. Table 50 stores the number of accepted requests per second for each frequency band as the upper request amount. For example, when the frequency is less than 1.0 GHz, the number of accepted requests per second is specified as 1,000. When the frequency is between 1.0 GHz and 2.0 GHz, the number of accepted requests per second is specified as 1,500. When the frequency is between 2.0 GHz and 3.0 GHz, the number of accepted requests per second is specified as 2,000. When the frequency is 3.0 GHz or higher, the number of accepted requests per second is specified as 2,500. As such, the higher the frequency, the greater the processing volume per unit time, and the greater the number of requests that the CPU 32 can accept per second. However, as noted above, processing power is not necessarily proportional to frequency.

[0073] The <Example of CPU frequency control information acquisition> is summarized as follows: The power saving function usage information acquisition unit 150 acquires the usage status of the CPU frequency function. The processing capacity information acquisition unit 110 acquires processing capacity information of requests per unit time of the CPU 32 from the frequency information of the CPU 32 acquired by the power saving function usage information acquisition unit 150.

[0074] <Request restriction during period of fluctuation in acceptable request volume: Example 3> The power saving function usage information acquisition unit 150 determines the recovery time from when the power saving function is deactivated until the upper limit of the number of requests that can be accepted per unit time by the CPU 32 changes. The request acceptance restriction execution unit 140 restricts requests per unit time from external devices during the recovery time until the upper limit of the number of requests that can be accepted per unit time by the CPU 32 is restored.

[0075] When a power-saving function detects an increase in load, it is often deactivated within a short time, increasing the upper limit of processing capacity. Therefore, by acquiring and determining the time required for deactivation, it is possible to control the request acceptance restriction so that it is only implemented for a specified period of time. For example, idle function information is acquired as power-saving function usage information. As described in the first example of idle function utilization information acquisition, the power-saving function usage information acquisition unit 150 acquires not only the number of active cores and the number of idle cores, but also the period r until an idle core returns to an active state. The power-saving function usage information acquisition unit 150 continues to transmit the period r until an idle core returns to an active state to the request acceptance amount determination unit 130 via the request upper limit amount determination unit 120. The request acceptance amount determination unit 130 can set a policy such as the following based on this period r until recovery.

[0076] Example 1: When scheduling wireless communication resources for a time period u, a restriction based on an upper limit amount is imposed during a period r at time u, but the restriction is lifted for the period after period r, assuming that processing capacity will have recovered.

[0077] Example 2: Consider a case where, when a request that exceeds the upper limit of the number of requests that the CPU 32 can accept per unit time arrives from the terminal 2, the request is rejected and restricted. In this case, if a request exceeding the upper limit is received for a period exceeding the period r, the processing capacity of the CPU 32 is expected to be restored, and the restriction is lifted. The request acceptance restriction execution unit 140 executes the restriction based on these policies.

[0078] (Third embodiment) Fig. 6 is a schematic configuration diagram of a vRAN system including a request reception amount control device according to a third embodiment of the present invention. Components that are the same as those in Figs. 1 and 8 are given the same reference numerals, and descriptions of overlapping parts will be omitted. The third embodiment is an example in which the present invention is applied to a vRAN system.

[0079] As shown in FIG. 6, the wireless access system 1000A includes a user terminal 2, an antenna 20, a base station server 103, and a core network 40.

[0080] The base station server 103 includes hardware 31, an OS 33, and base station software in a user space 35, which includes a radio signal processing unit 104 and a communication resource allocation unit 200 (request acceptance amount control device). The hardware 31 includes a CPU 32 and an accelerator 32A. The accelerator 32A is a calculation unit hardware that performs specific calculations at high speed based on input from the CPU 32. The accelerator 32A is, for example, a PLD (Programmable Logic Device) such as a GPU or FPGA.

[0081] The radio signal processing unit 104 performs radio signal processing in LTE and 5G radio access systems in the base station server 103, which is a general-purpose server.

[0082] The communications resource allocation unit 200 is an existing communications resource allocation unit to which the request acceptance amount control function of the request acceptance amount control unit 100A of Fig. 4 has been applied. The communications resource allocation unit 200 includes a power saving function usage information acquisition unit 150, a processing capacity information acquisition unit 110, a request upper limit amount determination unit 120, a communications information reception unit 210, a MAC (Media Access Control) scheduler 220 having a request acceptance amount determination unit 130, and a schedule distribution unit 230 having a request acceptance limit execution unit 140.

[0083] The power saving function usage information acquisition unit 150 acquires usage information of the power saving functions related to wireless signal processing. Specifically, the power saving function usage information acquisition unit 150 acquires the usage status of the idle function and the characteristics of its recovery delay, and notifies the processing capacity information acquisition unit 110 of the status.

[0084] The processing capacity information acquisition unit 110 acquires the processing capacity of the wireless signal and notifies the request upper limit amount determination unit 120. Specifically, the processing capacity information acquisition unit 110 acquires the CPU usage rate of the CPU 32 used by the wireless signal processing unit 104 from the OS 33.

[0085] The request upper limit determination unit 120 receives wireless signal processing capacity information, determines the upper limit of requests that the CPU 32 can accept per unit time, and notifies the MAC scheduler 220. The following are unique items of wireless communication resources for the upper limit of requests: That is, the number of simultaneous communication users, the number of resource blocks, and the number of antennas are accepted as the upper limit of requests from the communication resource allocation unit 200.

[0086] On the other hand, the communication information receiving unit 210 is an existing function of the base station, and receives the access class and noise amount as user priority, and passes them to the MAC scheduler 220, which is an existing communication resource allocation determining unit. The MAC scheduler 220 allocates communication resources based on the information on the access class and noise amount, which are user priority, received from the communication information receiving unit 210.

[0087] Conventionally, the MAC scheduler 220 receives user priority and noise volume from the communication information receiving unit 210 and determines a schedule for wireless communication resources. The MAC scheduler 220 incorporates a request acceptance volume determining unit 130. The request acceptance volume determining unit 130 receives an upper limit of communication resources related to requests that the CPU 32 can accept per unit time, and determines an upper limit of wireless communication resource allocation so as not to exceed this limit.

[0088] The schedule distribution unit 230 has the same functions as the existing schedule distribution unit, and distributes schedules to the terminal 2 and accepts requests from the terminal 2. The schedule distribution unit 230 incorporates a request acceptance restriction execution unit 140. The request acceptance restriction execution unit 140 restricts requests from an external device to not exceed the upper limit by refusing requests from the external device or by distributing a limited amount of communication resources to the terminal 2.

[0089] [Hardware Configuration] The request reception quantity control unit 100, 100A (FIGS. 1 and 4) according to the above-described embodiment is realized by, for example, a computer 900 configured as shown in FIG. 7. FIG. 7 is a hardware configuration diagram showing the server 101 of FIG. 1 or 4. The server 101 has a CPU 32, a ROM 902, a RAM 903, a HDD 904, a communication interface 906, an input / output interface 905, and a media interface 907. Note that in FIG. 7, interfaces are abbreviated as "I / F."

[0090] The CPU 32 operates based on programs stored in the ROM 902 or the HDD 904, and embodies each unit of the request reception amount control unit 100, 100A (FIGS. 1 and 4). The ROM 902 stores a boot program executed by the CPU 32 when the computer 900 is started up, programs dependent on the hardware of the computer 900, and the like.

[0091] The CPU 32 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display, via an input / output interface 905. The CPU 32 acquires data from the input device 910 via the input / output interface 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 32.

[0092] The HDD 904 stores programs executed by the CPU 32 and data used by the programs. The communication interface 906 receives data from other devices via a communication network (e.g., network 920) and outputs the data to the CPU 32, and also transmits data generated by the CPU 32 to other devices via the communication network.

[0093] The media interface 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 32 via the RAM 903. The CPU 32 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media interface 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0094] For example, when the server 101 functions as the request acceptance amount control unit 100, 100A (FIGS. 1 and 4) configured as one device according to this embodiment, the CPU 32 of the server 101 realizes the functions of the request acceptance amount control unit 100, 100A by executing a program loaded onto the RAM 903. In addition, the HDD 904 stores data in the RAM 903. The CPU 32 reads and executes a program related to a target process from the recording medium 912. Alternatively, the CPU 32 may read a program related to a target process from another device via a communication network (NW 920).

[0095] The configuration and effects of the present invention will be described below. A request reception amount control device (server 101) capable of degenerating the processing capacity of a processor (CPU 32) is characterized by comprising: a processing capacity information acquisition unit (110) that acquires processing capacity information at which the processor (CPU 32) can process requests from an external device (terminal 2) per unit time; a request upper limit amount determination unit (120) that determines the upper limit amount of requests that the processor (CPU 32) can accept per unit time based on the processing capacity information acquired by the processing capacity information acquisition unit (110); and a request reception limit execution unit (140) that limits requests per unit time from the external device (terminal 2) based on the information on the upper limit amount of requests that the processor (CPU 32) can accept per unit time.

[0096] By doing this, the server having a processor that can transition to a power-saving state and degrade its processing capability can adjust the number of requests received from external devices, thereby preventing errors and retransmissions caused by an increase in requests from external devices in the server having a processor that can transition to a power-saving state and degrade its processing capability.

[0097] The processor (CPU 32) has a function of transitioning to a power saving state and degrading processing capacity, and is equipped with a power saving function usage information acquisition unit (150) that acquires the power saving state of the processor (CPU 32), and the request upper limit amount determination unit (120) determines the upper limit amount of requests that the processor (CPU 32) can accept per unit time based on the processing capacity of the processor (CPU 32) in the power saving state.

[0098] By doing this, even if the load suddenly increases due to requests from external devices when the processor's processing capacity is degraded, it is possible to control the load so that it does not exceed the processor's processing capacity. It is possible to prevent errors and retransmissions caused by performance requirements not being met. That is, during the period P １５As described above, even if a request from an external device is responded to, if the load of requests per unit time exceeds the processing capacity of the processor per unit time, the request will not be processed even if it is received from the external device, and errors or retransmissions will simply occur. In this embodiment, when the processing capacity of the processor is degenerated, the processing capacity of requests per unit time of the processor in a power-saving state can be obtained, so that the upper limit of the number of requests that the processor can accept per unit time can be correctly determined.

[0099] When the processor (CPU 32) transitions to a power saving state due to the transition of the processing core of the processor (CPU 32) to an idle state, the request upper limit amount determination unit (120) acquires processing capacity information of the processor (CPU 32) from idle state information of the processing core of the processor (CPU 32) and acquires the recovery time required to return from the idle state.

[0100] In this way, by obtaining the idle state of the processing core of the processor being used to process the request, it is possible to obtain processor processing capacity information from the idle state information of the processing core of this processor, and further obtain the recovery time required to return from the idle state.

[0101] The system is provided with a request processing unit (102) that acquires load information on requests from the external device (terminal 2) processed by the processor (CPU 32) per unit time, and the request reception limit execution unit (140) is characterized in that when the load amount on requests from the external device processed by the processor (CPU 32) per unit time reaches a predetermined percentage of the upper limit amount of requests that can be processed by the processor (CPU 32), it limits the amount of requests that can be received until the recovery time has elapsed.

[0102] By doing so, when the processor is degraded in its processing capacity, it is possible to prevent an increase in the load caused by a sudden increase in requests from external devices.

[0103] When the processor (CPU 32) transitions to a power saving state by controlling the clock frequency, the request upper limit amount determination unit (120) acquires information on the processing capacity of the processor (CPU 32) for requests per unit time from frequency information of the processor (CPU 32).

[0104] In this way, when the processor is shifted to a power saving state by controlling the clock frequency of the processor, it is possible to preferably obtain information on the processing capacity that the processor can process per unit time.

[0105] The request reception restriction execution unit (140) is characterized in that it determines a MAC (Media Access Control) schedule of the virtual wireless access network so as to restrict requests from the external device (terminal 2) based on information on the upper limit amount of requests that the processor (CPU 32) can receive per unit time.

[0106] In a network system such as a vRAN system, a MAC schedule can be set so that the number of requests accepted per unit time from external devices does not exceed the upper limit of the number of requests that a processor can accept.

[0107] The method includes the steps of: degrading the processing capacity of the processor (CPU 32); a processing capacity information acquisition unit (110) acquiring processing capacity information on the processor (CPU 32) that can process requests from an external device (terminal 2) per unit time; a request upper limit amount determination unit (120) determining the upper limit amount of requests that the processor (CPU 32) can accept per unit time based on the processing capacity information on the requests that the processor (CPU 32) can process per unit time; and a request acceptance limit execution unit (140) limiting requests per unit time from the external device (terminal 2) based on the upper limit amount information on the requests that the processor (CPU 32) can accept per unit time.

[0108] By doing this, the server having a processor that can transition to a power-saving state and degrade its processing capability can adjust the number of requests received from external devices, thereby preventing errors and retransmissions caused by an increase in requests from external devices in the server having a processor that can transition to a power-saving state and degrade its processing capability.

[0109] A program for causing a computer (server 101) capable of degrading the processing power of a processor (CPU 32) to execute the following steps: a procedure for acquiring processing power information that the processor (CPU 32) can process requests from an external device (terminal 2) per unit time; a procedure for determining an upper limit of the number of requests that the processor (CPU 32) can accept per unit time based on the acquired processing power information of the requests; and a procedure for limiting the number of requests per unit time from the external device (terminal 2) based on the information on the upper limit of the number of requests that the processor (CPU 32) can accept per unit time.

[0110] By doing this, the server having a processor that can transition to a power-saving state and degrade its processing capability can adjust the number of requests received from external devices, thereby preventing errors and retransmissions caused by an increase in requests from external devices in the server having a processor that can transition to a power-saving state and degrade its processing capability.

[0111] Note that, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods. Furthermore, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. Furthermore, the components of each device shown in the drawings are functionally conceptual and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown in the drawings, and all or part of the devices can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0112] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information such as programs, tables, and files that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disk.

[0113] 2 Terminal (external device) 20 Antenna (base station antenna) 32 CPU 40 Core network 31 Hardware 32 CPU (processor) 32a to 32e Core 32A Accelerator 100, 100A Request acceptance amount control unit (request acceptance amount control device) 101 Server (request acceptance amount control device) 103 Base station server (BBU) 104 Radio signal processing unit 110 Processing capacity information acquisition unit 120 Request upper limit amount determination unit 130 Request acceptance amount determination unit 140 Request acceptance limit execution unit 200 Communication resource allocation function unit (request acceptance amount control device) 210 Communication information receiving unit 220 MAC scheduler 1000 Network system 1000A Radio access system (network system)

Claims

1. A request reception volume control device capable of degrading the processing capacity of a processor, comprising: a processing capacity information acquisition unit that acquires processing capacity information at which the processor can process requests from an external device per unit time; a request upper limit volume determination unit that determines the upper limit volume of requests that the processor can accept per unit time based on the processing capacity information acquired by the processing capacity information acquisition unit; and a request reception limit execution unit that limits requests per unit time from the external device based on the information on the upper limit volume of requests that the processor can accept per unit time.

2. The request reception quantity control device according to claim 1, characterized in that the processor has a function of transitioning to a power saving state and degrading processing capacity, and is equipped with a power saving function usage information acquisition unit that acquires the power saving state of the processor, and the request upper limit quantity determination unit determines the upper limit quantity of requests that the processor can accept per unit time based on the processing capacity of the processor in the power saving state.

3. The request reception amount control device described in claim 2, characterized in that when the processor transitions to a power saving state due to the transition of the processor's processing core to an idle state, the request upper limit amount determination unit obtains processing capacity information of the processor from idle state information of the processor's processing core and obtains the recovery time required to return from the idle state.

4. A request reception volume control device as described in claim 3, further comprising a request processing unit that acquires load information on the amount of load caused by the processor processing requests from the external device per unit time, and wherein the request reception limit execution unit limits the amount of requests received until the recovery time has elapsed when the load caused by the processor processing requests from the external device per unit time reaches a predetermined percentage of the upper limit of the amount of requests that the processor can process.

5. A request reception volume control device as described in claim 2, characterized in that when the processor transitions to a power saving state by controlling the clock frequency of the processor, the request upper limit volume determination unit obtains information on the processor's processing capacity of requests per unit time from the processor's frequency information.

6. The request acceptance quantity control device according to claim 1, characterized in that the request acceptance limit execution unit determines a MAC (Media Access Control) schedule for the virtual wireless access network so as to limit requests from the external device based on information on the upper limit quantity of requests that the processor can accept per unit time.

7. A method for controlling the amount of request acceptance, comprising: a step of degrading the processing capacity of a processor; a step of a processing capacity information acquisition unit acquiring processing capacity information on the processor's ability to process requests from an external device per unit time; a step of a request upper limit amount determination unit determining the upper limit amount of requests that the processor can accept per unit time based on the processing capacity information on the requests that the processor can process per unit time; and a step of a request acceptance limit execution unit limiting requests per unit time from the external device based on the information on the upper limit amount of requests that the processor can accept per unit time.

8. A program for causing a computer capable of degrading the processor's processing power to execute the following steps: acquiring processing power information at which the processor can process requests from an external device per unit time; determining the upper limit of the number of requests that the processor can accept per unit time based on the acquired request processing power information; and limiting the number of requests per unit time from the external device based on the information on the upper limit of the number of requests that the processor can accept per unit time.

Images