WO2022172389A1 - リソース割当装置、リソース割当方法、および、リソース割当プログラム - Google Patents

リソース割当装置、リソース割当方法、および、リソース割当プログラム Download PDF

Info

Publication number
WO2022172389A1
WO2022172389A1 PCT/JP2021/005175 JP2021005175W WO2022172389A1 WO 2022172389 A1 WO2022172389 A1 WO 2022172389A1 JP 2021005175 W JP2021005175 W JP 2021005175W WO 2022172389 A1 WO2022172389 A1 WO 2022172389A1
Authority
WO
WIPO (PCT)
Prior art keywords
allocation
group
state management
management unit
resource allocation
Prior art date
Application number
PCT/JP2021/005175
Other languages
English (en)
French (fr)
Inventor
諒平 佐藤
裕一 中谷
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2022581105A priority Critical patent/JPWO2022172389A1/ja
Priority to PCT/JP2021/005175 priority patent/WO2022172389A1/ja
Priority to US18/276,474 priority patent/US20240126612A1/en
Publication of WO2022172389A1 publication Critical patent/WO2022172389A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present invention relates to a resource allocation device, a resource allocation method, and a resource allocation program.
  • a distributed cloud environment is an architecture in which DCs (Data Centers) are distributed in a NW (Network) (Non-Patent Documents 1 and 2).
  • the DC provides computer resources for offloading (replacement) the processing that servers and users have conventionally handled.
  • the state management part is exemplified below as an object to be allocated to the DC.
  • a "state” is data used for a service exchanged in real time between a plurality of users.
  • the “state management unit” is a processing unit that updates the state managed by itself based on the access details received from each user, and shares the data of the updated state with each user.
  • FIG. 7 is a configuration diagram of the online system 9z1 before offloading the state management unit 5z.
  • the service providing device 1z provides a service for sharing states in real time among a plurality of user terminals 4z.
  • Examples of the states managed by the state management unit 5z are as follows. ⁇ Online game: Avatar's position, acceleration, movement, equipment, damage judgment, incapacitated status, etc.
  • ⁇ Online meeting user and screen sharing audio/video data presenter authority, mute settings, etc.
  • a large communication delay becomes a factor that deteriorates the quality of service.
  • FIG. 8 is a configuration diagram of the online system 9z2 after offloading the state management unit 5z to the DC 3z.
  • the device that operates the state management unit 5z is offloaded from the service providing device 1z to the DC 3z near the user terminal 4z. This offload provides the following effects.
  • ⁇ User Reduction of calculation cost and delay.
  • ⁇ Communication carriers Reduction of traffic volume and congestion.
  • ⁇ Service provider Reduction of server load and maintenance cost.
  • Non-Patent Document 3 describes a resource allocation method that obtains delays between user terminals 4z and reduces the maximum value of the delays (maximum E2E delay).
  • FIG. 9 is a configuration diagram of the distributed cloud environment 8z when the state management unit is offloaded to a plurality of DCs.
  • DC1, DC2 two DCs
  • five users U1, UA2, UA3, UB1, UB2
  • DC1 accommodates users (UA1, UA2, UB1).
  • DC2 accommodates users (UA3, UB2).
  • the first group (UA1, UA2, UA3: the group whose second letter is "A") and the second group (UB1, UB2: the second letter is "B” group) is formed.
  • the second group (UB1, UB2: the second letter is "B” group)
  • ST1 the state of UA1 and UA2
  • ST2 the state of UA3 between DCs.
  • the service requirements may differ between the applications of the first group and the applications of the second group.
  • the emphasis is on a large number of participants, such as 100 players, and information on opponents is not as strictly required as in a fighting game.
  • a fighting game played in the second group although it is a small number of people such as one-on-one, it is necessary for the screen information viewed by the members and the operation information input by the members to be reflected quickly (in frame units) on the opponent side. be.
  • Non-Patent Document 3 cannot handle complicated situations in which multiple groups exist and each group requires various service requirements.
  • the main object of the present invention is to allocate resources according to the requirements of each group formed by a plurality of users.
  • the present invention is a request to allocate a state management unit for sharing a state for each group composed of a plurality of user terminals within the group to one of a plurality of data centers deployed in a distributed cloud environment.
  • a request receiving unit that receives a calculating an allocation cost when allocating the state management unit to each of the data centers using an allocation index according to requirements requested by the group, and determining the data center to which the state management unit is allocated according to the allocation cost; and an allocation calculation unit for determining.
  • resource allocation can be performed according to the requirements of each group formed by a plurality of users.
  • FIG. 1 is a configuration diagram of an online system according to this embodiment
  • FIG. 2 is a hardware configuration diagram of a resource allocation device according to this embodiment
  • FIG. 4 is a configuration diagram of a distributed cloud environment in which an allocation calculation unit according to the present embodiment allocates state management units for each group
  • FIG. 4 is a flowchart showing main processing of the greedy method according to the embodiment
  • FIG. 5 is a flow chart showing subroutine processing of the greedy method of FIG. 4 according to the present embodiment
  • FIG. FIG. 6 is an explanatory diagram showing a processing example of the greedy method of FIGS. 4 and 5 according to the present embodiment
  • 1 is a configuration diagram of an online system before offloading a state management unit
  • FIG. FIG. 4 is a configuration diagram of the online system after offloading the state manager to the DC
  • FIG. 4 is a configuration diagram of a distributed cloud environment when a state management unit is offloaded to multiple DCs;
  • FIG. 1 is a configuration diagram of the online system 9. As shown in FIG.
  • the online system 9 is configured by connecting a service providing device 1, a resource allocation device 2, and a distributed cloud environment 8 via a network.
  • a service is provided in which state data is shared among a plurality of user terminals 4 in real time. Therefore, the state management unit 5 manages the state for each group.
  • Each state management unit 5 is arranged in one of the DCs 3 .
  • the resource allocation device 2 performs group matching processing such as (Procedure 1A) to (Procedure 5A).
  • (Procedure 1A) User terminal 4 accesses service providing apparatus 1 .
  • the service providing device 1 selects an appropriate DC 3 as the offload destination of the group formed in (Procedure 2A), and places the state management unit 5 for each group in the DC 3 to start the service. .
  • a server function that provides services (such as a battle function in an online game) is pre-implemented in a VM or container.
  • the state management unit 5 provides services by updating the state of the virtual space within the group.
  • the DC 3 performs processing for updating the state managed by the state management unit 5 of each group.
  • each user terminal 4 sends a command to DC 3 as shown in the following (procedure 1B) to (procedure 4B), and at the same time, the virtual space (state) that has already been synchronized and generated is received from DC3.
  • the user terminal 4 can acquire commands from other user terminals 4 simply by performing one-to-one communication with the DC 3 .
  • Each user terminal 4 writes its own command to the state management unit 5 on DC3. For example, using a controller to send a command to move your avatar forward.
  • State management unit 5 on DC 3 aggregates and synchronizes the commands of (Procedure 1B) from each user terminal 4 . For example, according to commands received from each user terminal 4, each user's avatar is caused to move or perform an action. In other words, the virtual world after a slightly longer period of time than before is generated as a state.
  • State management unit 5 on DC 3 renders (images) the virtual world using the information of (Procedure 2B), and transmits the state to all user terminals 4 .
  • the state management unit 5 distributes (one frame of) a game screen on which commands of all user terminals 4 are reflected.
  • Providedure 4B Each user terminal 4 that has received the state transmits the command again. For example, you see an enemy attacking you, so you enter an avoidance command. Then, return to (procedure 1B).
  • the distributed cloud environment 8 may be applied to an example of obtaining a final processing result by combining a plurality of specific modules in an IoT (Internet of Things) environment.
  • IoT Internet of Things
  • the user terminal 4 for the weather prediction module, the user terminal 4 for the soil analysis module, and the user terminal 4 for the crop analysis module are separately prepared. These three modules are grouped, and a processing section (a processing section corresponding to the state management section 5 described above) that receives the output results of the module group belonging to the group, processes them, and manages fields is provided as DC3. to be placed.
  • the resource allocation device 2 decides in which DC 3 the state management unit 5 offloaded from the service providing device 1 is to be placed (hereinafter referred to as “DC placement”), which is determined by a plurality of users. Select according to the requirements of each group (for example, the requirements of each application that the group uses or the requirements of each service that the group uses). Therefore, the resource allocation device 2 has a request reception unit 21 , a NW data collection unit 22 , an allocation calculation unit 23 and a control unit 24 .
  • the request receiving unit 21 receives from the service providing apparatus 1 a request for each group including the group configuration and the user's delay requirements.
  • the content of this request is to allocate the state management unit 5 for exchanging data for each group composed of a plurality of user terminals 4 to one of the plurality of DCs 3 deployed in the distributed cloud environment 8.
  • the NW data collection unit 22 measures and collects NW data including delay information between each user terminal 4 and each DC 3 and free space (number of assignable users) information of each DC 3 from the distributed cloud environment 8. do.
  • the allocation calculation unit 23 calculates DC allocation for each group according to a resource allocation scheme (hereinafter "scheme").
  • the scheme is information for determining to which DC the state management unit 5 is to be allocated, to what extent, and with what kind of policy (mainly which allocation index is emphasized), and the performance of the distributed cloud environment 8 is determined by the scheme strongly depends on
  • the scheme may be received by the resource allocation device 2 as a request from the service providing device 1 .
  • the allocation calculation unit 23 may obtain a scheme by referring to a database based on the application type that the resource allocation device 2 receives as a request from the service providing device 1 . Schemes corresponding to each application type are registered in advance in the database.
  • the allocation calculation unit 23 may receive designation of schemes from members within the group.
  • the control unit 24 allocates the resources of each state management unit 5 to each DC 3 according to the DC allocation from the allocation calculation unit 23 .
  • FIG. 2 is a hardware configuration diagram of the resource allocation device 2.
  • the resource allocation device 2 is configured as a computer 900 having a CPU 901 , a RAM 902 , a ROM 903 , an HDD 904 , a communication I/F 905 , an input/output I/F 906 and a media I/F 907 .
  • Communication I/F 905 is connected to an external communication device 915 .
  • Input/output I/F 906 is connected to input/output device 916 .
  • a media I/F 907 reads and writes data from a recording medium 917 .
  • the CPU 901 controls each processing unit by executing programs read into the RAM 902 (request reception unit 21, NW data collection unit 22, allocation calculation unit 23, resource allocation program provided in the control unit 24, etc.).
  • This program can be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM for distribution.
  • FIG. 3 is a configuration diagram of the distributed cloud environment 8 in which the allocation calculation unit 23 allocates state management units for each group.
  • DCs are selected on a per-user basis without considering the concept of groups, so state sharing between DCs is necessary. Therefore, communication delay between users has increased due to extra overhead caused by state sharing.
  • the allocation calculation unit 23 performs DC allocation on a group-by-group basis.
  • one state management unit 5 is assigned to one DC 3 per group.
  • the state manager (STA) for the first group (UA1, UA2, UA3) is assigned to DC1
  • the state manager (STB) for the second group (UB1, UB2) is assigned to DC2. Therefore, the overhead of state sharing can be suppressed and strict real-time requirements can be met.
  • the allocation calculation unit 23 can plan DC allocation suitable for the requirements of each group by referring to the scheme suitable for the application type of each group from the request. In other words, the allocation calculation unit 23 calculates allocation costs when allocating the state management unit 5 to each data center using the allocation index of the scheme according to the requirements of each group, and calculates the allocation cost of the state management units 5 according to the allocation cost. Decide which data center to assign to. Examples are given below as combinations of application types and schemes.
  • “Case 1: Perfect Synchronization Type” is an application that allows all users belonging to a group to view the same screen by synchronizing the states after waiting for each communication of all users belonging to the group.
  • “Case 2: semi-synchronous type” is an application that does not (cannot) achieve strict synchronization between users, for example, an FPS (First-Person Shooter) survival game for about 100 players.
  • FPS First-Person Shooter
  • a semi-synchronous scheme minimizes the "average delay within the group". For example, even if only about 3 members of a group of 100 people experience a large delay, only 3 members will feel the inconvenience, and the remaining 97 people will be provided with a comfortable environment with a small average delay. Enough.
  • “Case 3: fair environment type” is a real-time application that particularly requires fairness in the playing environment between users, and is exemplified below.
  • ⁇ A race game in which about 10 people run on the same circuit at the same time.
  • ⁇ In XR spaces and virtual conference rooms it is desirable that the time until the user's motion is reflected in the field of view (motion-to-photonlatency) is 20[ms] or less.
  • ⁇ Even in an application that allows conversation in a virtual space that simulates a real city the number of users who can stay in one space is limited so as not to slow down the response.
  • a fair-environment scheme (assignment index) minimizes the "intra-group delay variation (variance or standard deviation)".
  • the symbol “i ⁇ I” denotes user i and its set I.
  • the symbol “I j ⁇ I” indicates a set I j of users belonging to group j.
  • the symbol 'w ij ' is a binary variable that takes the value '1' if user i belongs to group j, and '0' otherwise.
  • the symbol “d ik ” denotes the delay time between users i-DCk.
  • the symbol “D i " denotes the delay requirement of user i.
  • the symbol " Ck " indicates the number of users that DCk can accommodate.
  • the allocation calculator 23 calculates (Formula 1) and (Formula 2) as allocation indexes.
  • a formula for calculating the maximum delay will be described later in (Equation 4).
  • the left side “a jk ” of (Equation 1) indicates the average delay of user i ⁇ I j when group j is accommodated in DCk.
  • the left side “v 2 jk ” of (Equation 2) indicates the delay dispersion of user i ⁇ I j when group j is accommodated in DCk.
  • Equation 3 shows the objective function of DC allocation. This objective function reduces to the problem of minimizing the sum of allocation costs for group j.
  • the symbol “c jk ” is the allocation cost when group j is accommodated in DCk.
  • the symbol “x jk ” is the calculation result of the allocation calculator 23 .
  • 'x jk ' is a decision variable, which takes a value of '1' if group j is included in DCk, and a value of '0' otherwise.
  • Equation 4 or (Equation 5) will be described as a specific calculation formula by which the allocation calculation unit 23 obtains the allocation cost c jk .
  • ⁇ , ⁇ ( ⁇ , ⁇ ⁇ 0, ⁇ + ⁇ ⁇ 1) are parameters for adjusting the trade-off between the three allocation indices. It is arbitrarily decided by the operator.
  • "1- ⁇ - ⁇ " in the first term on the right side of (Equation 4) is a hyperparameter that emphasizes the "average delay within the group” as the value increases.
  • “ ⁇ ” in the second term on the right side of (Equation 4) is a hyperparameter that emphasizes “variation in delay within a group” as its numerical value increases.
  • “ ⁇ ” in the third term on the right side of (Equation 4) is a hyperparameter that attaches more importance to the "maximum delay within the group” as its numerical value increases. Note that the calculation formula after ⁇ in the third term on the right side is the calculation formula for the maximum delay in the group.
  • the allocation calculation unit 23 may use (Equation 6) instead of (Equation 4) using the variance , and instead of (Equation 5) using the standard deviation, (Formula 7) may be used.
  • (Formula 6) and (Formula 7) use three types of hyperparameters ( ⁇ , ⁇ , ⁇ ). As a result, although the degree of freedom in parameter setting is high, handling (optimal parameter setting) becomes difficult accordingly.
  • “ ⁇ ” in the first term on the right side is a hyperparameter that attaches more importance to “average delay within the group” as its numerical value increases.
  • “ ⁇ ” in the second term on the right side is a hyperparameter that emphasizes “variation in delay within a group” as its value increases.
  • “ ⁇ ” in the third term on the right side is a hyperparameter that emphasizes "maximum delay within the group” as its numerical value increases.
  • the number of parameters is one less and the setting range is narrow.
  • weights can be set by ratios, there is a high possibility that handling will be easier than using three types of hyperparameters ( ⁇ , ⁇ , ⁇ ).
  • Equation 8 shows the constraint condition (subject to) corresponding to the objective function of (Equation 3). Constraints are as follows. - The number of DC assigned to one group is one or less. - The number of accommodated users does not exceed the capacity of each DC. • Each user's actual delay satisfies the delay requirement.
  • the greedy algorithm and the local search method will be described in order as approximation algorithms that the allocation calculation unit 23 uses instead of the round-robin calculation.
  • Allocation calculation unit 23 uses the greedy method alone, or uses both the greedy method and the local search method.
  • the optimal solution or the quasi-optimal solution with a score close to the optimal solution found by round-robin calculation can be found with a smaller amount of calculation than the round-robin calculation.
  • FIG. 4 is a flowchart showing main processing of the greedy method.
  • the greedy method is a method of dividing one large problem into a plurality of small problems, evaluating each small problem individually, and adopting a candidate with a high evaluation value.
  • the allocation calculator 23 creates a cost table, which will be described later in FIG. 6, based on the request from the request receiver 21 and the NW data from the NW data collector 22 (S101).
  • the allocation calculation unit 23 calculates the minimum cost for each group in the cost table of S101 (S102).
  • the allocation calculation unit 23 sorts the minimum cost values for each group in the cost table in ascending order (S103).
  • the allocation calculation unit 23 substitutes the initial value 1 for the group variable j (S104).
  • the allocation calculation unit 23 executes a loop for sequentially selecting group j one by one up to the number of groups in the cost table (S105 to S107). ) is called (S106).
  • S106 In the process of S106, if there is no assignment destination DC that satisfies the delay requirements of a certain user, or if the capacity of the DC is insufficient, there is a possibility that some groups cannot be assigned.
  • FIG. 5 is a flowchart showing subroutine processing (S106) of the greedy method of FIG.
  • the allocation calculation unit 23 reads the j-th group row of the cost table (S111), and tries to allocate the DC with the lowest cost among them (S112). If the user's delay requirement is satisfied (S113, Yes) and the capacity of the DC is sufficient (S114, Yes), the allocation calculation unit 23 allocates group j to that DC (S115). On the other hand, in the case of (S113, No) or (S114, No), the allocation calculation unit 23 deletes the DC from the j-th group cost table (S116).
  • FIG. 6 is an explanatory diagram showing a processing example of the greedy method of FIGS. 4 and 5.
  • the cost table 201 is a two-dimensional table with group j as rows and DCk as columns for allocation costs c jk when group j is accommodated in DCk.
  • the allocation calculator 23 creates the cost table 201 in S101 of FIG. Then, the allocation calculation unit 23 sets the result of sorting the cost table 201 in ascending order according to the minimum value as the cost table 202 (S103).
  • the DC allocation tables 211 to 217 are table formats of the calculation results “x jk ” of the allocation calculator 23 based on the cost table 202 . For example, in the DC allocation table 214, two groups "G4, G2" are allocated to DC1, no group is allocated to DC2 (symbol "-”), and one group "G5" is allocated to DC3.
  • the assignment calculation unit 23 assigns each group to each DC by calling the subroutine of S106 in order from the group positioned at the top of the cost table 202 .
  • the allocation calculation unit 23 allocates G2 to DC1 with the lowest cost (DC allocation table 212 ⁇ DC allocation table 213).
  • the allocation calculation unit 23 allocates G5 to DC3 with the lowest cost (DC allocation table 213 ⁇ DC allocation table 214).
  • the allocation calculation unit 23 tries to allocate G6 to DC1, which has the lowest cost, but DC1 has insufficient capacity. Therefore, the allocation calculator 23 allocates G6 to DC3 with the second lowest cost (DC allocation table 214 ⁇ DC allocation table 215). (G3 on the fifth line) The allocation calculator 23 allocates G3 to DC2 with the lowest cost (DC allocation table 215 ⁇ DC allocation table 216). (G1 in line 6) The allocation calculation unit 23 allocates G1 to DC2 with the lowest cost (DC allocation table 216 ⁇ DC allocation table 217).
  • a cost table is created using ⁇ and ⁇ (L05), and priority is given to the group with the smallest minimum cost in the table ( L11) Perform preprocessing for DC allocation.
  • the actual DC allocation is executed by calling the GroupDC_Mapping function with the arguments w ij , d ik , D i , C k , the cost table c created here, and the permutation J referring to the cost table as arguments ( L12).
  • S100 corresponds to L01
  • S101 corresponds to L05
  • S102 corresponds to L09
  • S103 corresponds to L11
  • S106 corresponds to L12.
  • GroupDC_Mapping function (J, c, w, d, D, C), refer to the given cost table c according to the permutation J (L17) in order (that is, extract the row c[j] with the cost table), Assignments are obtained by sequentially calling the DC_Selection function for assigning DCs to each group (L20, L23). If the DC_Selection function indicates that no DC exists that satisfies the user's delay requirement D, then the delay requirement D is ignored and allocated.
  • the allocation calculation unit 23 can call the Greedy_Allocation function. As a result, by sorting the groups and assigning priority to those with the lowest cost, high-precision optimization can be achieved in a short calculation time. On the other hand, the allocation calculation unit 23 may obtain a better solution by combining the proposed method and the local search method.
  • the allocation calculator 23 first executes the Greedy_Allocation function (M01). Next, the allocation calculation unit 23 executes the GroupDC_Mapping function a fixed number of times (N times of M04) (M06). At this time, the allocation calculation unit 23 randomly changes the permutation of the groups in the "sorting of cost table" portion (M05). Then, the allocation calculation unit 23 selects the allocation with the lowest overall cost among the N iterations (M08 to M10). With this pseudocode (M01 to M11), the addition of the number of searches for repeating the GroupDC_Mapping function N times increases the computational cost, but the allocation cost may be even smaller than the greedy method. Note that the search count N is arbitrarily set by the service provider or distributed environment operator.
  • (Class 1) Offline allocation is a case where all groups to be allocated are given to the request receiving unit 21 in advance.
  • Classification 2 Batch allocation is a case where part (a plurality of groups) of groups to be allocated is sequentially given to the request receiving unit 21, and (relatively small scale) offline allocation is executed each time. For example, in a large-scale system, many groups are created in 10 seconds, so in this case there is a need to assign batches every 10 seconds.
  • (Class 3) Online allocation is a case where groups to be allocated are given to the request receiving unit 21 one by one, and allocation is executed each time. For example, there are cases where groups are not formed as often as batch processing is executed, and cases where it is desired to minimize the time from group formation to completion of allocation.
  • the Greedy_Allocation function described so far assumes that a large number of groups are given to the request receiving unit 21 (offline allocation or batch processing). On the other hand, when the groups to be assigned to the request receiving unit 21 arrive one after another, the following pseudo code for online assignment may be executed.
  • the Greedy_Allocation function is executed once
  • the GroupDC_Mapping function is executed once
  • the DC_Selection function is executed 10 times or more.
  • the number of times to call the DC_Selection function exceeds 10 times, if there is no DC that satisfies the user's delay requirements (when the return value of line L20 is ⁇ ), move to line L23 and DC_Selection again when the function is called.
  • the resource allocation device 2 of the present invention includes a state management unit 5 for sharing the state of each group composed of a plurality of user terminals 4 within the group. a request receiving unit 21 that receives a request to allocate to either; An allocation calculation unit that calculates the allocation cost when allocating the state management unit 5 to each DC 3 using the allocation index according to the requirements requested by the group, and determines the DC 3 to which the state management unit 5 is allocated according to the allocation cost. 23.
  • the user terminal 4 which is a member of the group, can allocate the state management unit 5 to an allocation destination suitable for the application performed by sharing the state management unit 5 in the group. Therefore, resource allocation can be performed according to requirements for each group formed by a plurality of users.
  • the allocation calculation unit 23 obtains the delay time between each user terminal 4 and the DC 3 constituting the group, and uses the average delay of the obtained delay times as the allocation index of the state management unit 5. Characterized by
  • the allocation calculation unit 23 obtains the delay time between each user terminal 4 and the DC 3 constituting the group, and uses the maximum delay of the obtained delay times as the allocation index of the state management unit 5. Characterized by
  • the allocation calculation unit 23 obtains the delay time between each user terminal 4 and the DC 3 that make up the group, and the dispersion or standard deviation of the obtained delay time is used as the allocation index of the state management unit 5. It is characterized by
  • the present invention solves the combinatorial optimization problem in which the allocation calculation unit 23 minimizes the sum of the allocation costs of each group of requests received by the request reception unit 21. It is characterized by calculating an allocation destination.
  • the present invention is an approximation algorithm that uses both the greedy method and the local search method for the combinatorial optimization problem in which the allocation calculation unit 23 minimizes the sum of the allocation costs of each group of requests received by the request reception unit 21. is characterized by calculating the allocation destination of each group.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

リソース割当装置（２）は、複数のユーザ端末（４）から構成されるグループごとのステートをグループ内で共有させるためのステート管理部（５）を、分散クラウド環境（８）に配備された複数のＤＣ（３）のうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部（２１）と、グループが要求する要件に応じた割当指標を用いて、ステート管理部（５）を各ＤＣ（３）に割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部（５）の割当先のＤＣ（３）を決定する割当計算部（２３）とを有する。

Description

リソース割当装置、リソース割当方法、および、リソース割当プログラム
　本発明は、リソース割当装置、リソース割当方法、および、リソース割当プログラムに関する。
　分散クラウド環境は、NW（Network）内にDC（Data Center）が分散して配置されたアーキテクチャである（非特許文献１，２）。DCは、サーバやユーザが従来担っていた処理をオフロード（代行）するための計算機資源（リソース）を提供する。
　以下、DCに割り当てる対象として、ステート管理部を例示する。なお、「ステート」とは、複数のユーザ間でリアルタイムにやりとりするサービスに用いられるデータである。「ステート管理部」とは、各ユーザから受信したアクセス内容をもとに、自身の管理するステートを更新し、その更新後のステートを各ユーザにデータ共有する処理部である。
　図７は、ステート管理部５ｚをオフロードする前のオンラインシステム９ｚ１の構成図である。
　オンラインシステム９ｚ１では、サービス提供装置１ｚは、ステートを複数のユーザ端末４ｚ間でリアルタイムにデータ共有させるサービスを提供する。ステート管理部５ｚが管理するステートは、例えば以下が挙げられる。
　・オンラインゲーム：アバタの位置・加速度・動作・装備、ダメージ判定や戦闘不能のステータスなど。
　・XR(Extended_Reality)：アバタ（ユーザ）の動作や五感情報、仮想世界において発生する事象など。
　・オンライン会議：ユーザや画面共有の音声・映像データプレゼンタ権限やミュートの設定など。
　このオンラインシステム９ｚ１では、サービス提供装置１ｚと各ユーザ端末４ｚとの間の通信距離が長いため、大きな通信遅延がサービスの品質を低下させる要因となる。
　図８は、ステート管理部５ｚをＤＣ３ｚにオフロードした後のオンラインシステム９ｚ２の構成図である。
　オンラインシステム９ｚ２では、ステート管理部５ｚを動作させる装置を、サービス提供装置１ｚから、ユーザ端末４ｚに近いＤＣ３ｚにオフロードさせている。このオフロードにより、下記のような効果が得られる。
　・ユーザ：計算コスト・遅延の低減。
　・通信事業者：トラフィック量・輻輳の軽減。
　・サービス提供者：サーバ負荷・メンテナンスコストの削減。
　つまり、サービス品質を向上させるためには、複数のＤＣ３ｚの候補から、どのＤＣ３ｚにステート管理部５ｚを配置するかを選択することが重要となる。非特許文献３には、各ユーザ端末４ｚの間の遅延を求め、その遅延の最大値（最大のE2E遅延）を小さくするようなリソース割当方法が記載されている。
Alicherry and T. V. Lakshman, "Network aware resource allocation in distributed clouds," in 2012 Proceedings IEEE INFOCOM, pp. 963-971, 2012. M. Mukherjee, L. Shu, and D. Wang, "Survey of fog computing: Fundamental, network applications, and research challenges," in IEEE Communications Surveys & Tutorials, Vol. 20, No. 3, pp. 1826-1857, 2018. A. Kawabata, B. C. Chatterjee, S. Ba and E. Oki, "A Real-Time Delay-Sensitive Communication Approach Based on Distributed Processing," in IEEE Access, vol. 5, pp. 20235-20248, 2017.
　同じオンラインシステムの環境を利用するユーザでも、ユーザのグループごとに様々なアプリケーションを実行させる。その際、例えば、以下の問題を定義する。
　・複数のDCと多数のユーザとが、NW内に散在している。
　・ユーザ同士で比較的少人数（例：2人～10人）のグループを形成済みである。
　・複数のグループに所属するユーザは存在しない。
　・全グループのステート管理部を、それぞれ適切なDCに各々収容したい。
　また、上記の問題に対して、以下の前提条件がすでに与えられているものと仮定する。
　・形成されたすべてのグループとそのメンバ。
　・全ユーザと全DC間の遅延時間（例：ping一回の測定値や複数回の平均値など）。
　・各DCに収容可能なユーザ数と、ユーザが満たすべき遅延要件（許容可能な遅延の最大値など）。
　図９は、ステート管理部を複数のＤＣにオフロードした場合の分散クラウド環境８ｚの構成図である。
　分散クラウド環境８ｚでは、波線で示すNW内に２つのＤＣ（DC1,DC2）が存在し、そのＤＣには５人のユーザ（UA1,UA2,UA3,UB1,UB2）が収容されている。図９の例では、各ユーザは最寄りのＤＣに収容される。よって、DC1には、ユーザ（UA1,UA2,UB1）が収容される。DC2には、ユーザ（UA3,UB2）が収容される。
　ここで、前記の問題定義で説明したように、ユーザ間で第１グループ（UA1,UA2,UA3：２文字目が「A」のグループ）と、第２グループ（UB1,UB2：２文字目が「B」のグループ）とが形成されたとする。第１グループのメンバ同士で同じ対戦ゲームをするためには、UA1,UA2のステート（ST1）とUA3のステート（ST2）とをDC間で共有（同期）する必要がある。第２グループも同様である。
　また、第１グループのアプリケーションと、第２グループのアプリケーションとで、サービス要件が異なることもある。
　例えば、第１グループで遊ばれるサバイバルゲームでは、１００人など参加人数が多いことを重視し、対戦相手の情報は対戦格闘ゲームほど厳密には求められない。
　一方、第２グループで遊ばれる対戦格闘ゲームでは、１対１などの少人数であるがメンバが見る画面情報やメンバの入力した操作情報がすばやく（フレーム単位で）相手側に反映される必要がある。
　このようなサービス要件を考慮しつつ、効率的にグループごとに適したリソース割当を行う手法が求められる。しかし、非特許文献３などの従来のリソース割当技術では、複数のグループが存在し、各グループが様々なサービス要件を求めるような複雑な状況には対応できなかった。
　そこで、本発明は、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことを主な課題とする。
　前記課題を解決するために、本発明のリソース割当装置は、以下の特徴を有する。
　本発明は、複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部と、
　前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定する割当計算部とを有することを特徴とする。
　本発明によれば、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことができる。
本実施形態に係わるオンラインシステムの構成図である。 本実施形態に係わるリソース割当装置のハードウェア構成図である。 本実施形態に係わる割当計算部がグループごとにステート管理部を割り当てる分散クラウド環境の構成図である。 本実施形態に係わる貪欲法のメイン処理を示すフローチャートである。 本実施形態に係わる図４の貪欲法のサブルーチン処理を示すフローチャートである。 本実施形態に係わる図４、図５の貪欲法の処理例を示す説明図である。 ステート管理部をオフロードする前のオンラインシステムの構成図である。 ステート管理部をＤＣにオフロードした後のオンラインシステムの構成図である。 ステート管理部を複数のＤＣにオフロードした場合の分散クラウド環境の構成図である。
　以下、図面を参照して本実施形態を説明する。
　図１は、オンラインシステム９の構成図である。
　オンラインシステム９は、サービス提供装置１と、リソース割当装置２と、分散クラウド環境８とがネットワークで接続されて構成される。分散クラウド環境８では、ステートを複数のユーザ端末４間でリアルタイムにデータ共有させるサービスが提供される。
　そのため、ステート管理部５はグループごとのステートを管理する。各ステート管理部５はいずれかのＤＣ３に配置される。
　まず、リソース割当装置２は、（手順１Ａ）～（手順５Ａ）のようなグループマッチング処理を行う。
　（手順１Ａ）ユーザ端末４はサービス提供装置１にアクセスする。
　（手順２Ａ）ユーザ端末４はサービス提供装置１上で、ステートを共有する相手である任意の（複数の）ユーザ端末４とマッチングし、グループを形成する。例えばオンラインゲームにおいては、「チームメイトや対戦相手」がステートを共有する相手になる。または、オンライン会議システムの場合は「同じ会議の参加者」がステートを共有する相手になる。
　（手順３Ａ）サービス提供装置１は、（手順２Ａ）で形成されたグループのオフロード先として適切なＤＣ３を選択し、そのＤＣ３にグループごとのステート管理部５を配置することでサービスを開始する。
　（手順４Ａ）ステート管理部５には、サービスを提供するサーバ機能（オンラインゲームにおける対戦機能など）があらかじめVMやコンテナで実装されている。ステート管理部５は、グループ内で仮想空間などのステートを更新することで、サービスを提供する。
　（手順５Ａ）対戦終了後にグループが解散された場合は、解散されたグループメンバのユーザ端末４をサービス提供装置１に返却し、（手順２Ａ）に戻る。
　そして、（手順４Ａ）の詳細として、ＤＣ３は、各グループのステート管理部５が自身の管理するステートを更新する処理を行う。例えば、オンラインの対戦ゲームでは、以下の（手順１Ｂ）～（手順４Ｂ）に示すように、各ユーザ端末４はＤＣ３にコマンドを送り、それと同時に、すでに同期処理され生成された仮想空間（ステート）をＤＣ３から受信する。これにより、ユーザ端末４はＤＣ３と１対１通信を行うだけで他のユーザ端末４のコマンドも取得できる。
　（手順１Ｂ）各ユーザ端末４はＤＣ３上のステート管理部５に自身のコマンドを書き込む。例えば、コントローラを用いて自身のアバタを前に進めるためのコマンドを送る。
　（手順２Ｂ）ＤＣ３上のステート管理部５が各ユーザ端末４からの（手順１Ｂ）のコマンドを集約・同期する。例えば、各ユーザ端末４から届いたコマンドにしたがって、各ユーザのアバタに移動やアクションを実行させる。すなわち、先ほどよりも僅かに時間が経過した後の仮想世界をステートとして生成する。
　（手順３Ｂ）ＤＣ３上のステート管理部５は（手順２Ｂ）の情報を用いて仮想世界をレンダリング（画像化）するなどし、全ユーザ端末４に対してステートを送信する。例えば、ステート管理部５は全ユーザ端末４のコマンドを反映させたゲーム画面（の１コマ）を配信する。
　（手順４Ｂ）ステートを受信した各ユーザ端末４は再びコマンドを送信する。例えば、敵が攻撃してくるのが見えたので回避コマンドを入力する。そして（手順１Ｂ）に戻る。
　以上は、オンラインの対戦ゲームの事例だが、IoT（Internet of Things）環境などにおいて、複数の特定モジュールを組み合わせて最終的な処理結果を得る事例に分散クラウド環境８を適用してもよい。
　例えば、気象予測モジュール用のユーザ端末４と、土壌分析モジュール用のユーザ端末４と、農作物分析モジュール用のユーザ端末４とを個別に用意する。そして、これら３つのモジュールをグループ化し、そのグループに属するモジュール群の出力結果を受け取り、それらを処理したり田畑を管理したりする処理部（前記のステート管理部５に対応する処理部）をＤＣ３に配置する。
　（手順３Ａ）において、リソース割当装置２は、サービス提供装置１からオフロードされるステート管理部５を、どのＤＣ３に配置するか（以下「ＤＣ配置」と呼ぶ）を、複数のユーザが形成したグループごとの要件（例えば、グループが利用しているアプリケーションごとの要件や、グループが利用しているサービスごとの要件）に沿って選択する。そのため、リソース割当装置２は、リクエスト受信部２１と、NWデータ収集部２２と、割当計算部２３と、制御部２４とを有する。
　リクエスト受信部２１は、グループ構成と、ユーザの遅延要件とを含むグループごとのリクエストをサービス提供装置１から受信する。このリクエストは、複数のユーザ端末４から構成されるグループごとにデータ交換するためのステート管理部５を、分散クラウド環境８に配備された複数のＤＣ３のうちのいずれかに割り当てる旨の内容である。
　NWデータ収集部２２は、各ユーザ端末４と各ＤＣ３との間の遅延情報と、各ＤＣ３の空き容量（割当可能なユーザの数）情報とを含むNWデータを分散クラウド環境８から測定および収集する。
　割当計算部２３は、リクエスト受信部２１からのリクエストと、割当計算部２３からのNWデータとをもとに、リソース割当スキーム（以下「スキーム」）に従ってグループごとのＤＣ配置を計算する。スキームは、ステート管理部５をどのDCに、どの程度、どのようなポリシで割り当てるかを決定するための情報（主にどの割当指標を重視するか）であり、分散クラウド環境８の性能はスキームに強く依存する。
　なお、スキームは、リソース割当装置２がサービス提供装置１からリクエストとして受信してもよい。または、割当計算部２３は、リソース割当装置２がサービス提供装置１からリクエストとして受信したアプリケーション種別をもとに、データベースを参照してスキームを求めてもよい。データベースには、アプリケーション種別ごとに対応するスキームが事前に登録されている。
　または、割当計算部２３は、グループ内のメンバからスキームの指定を受けてもよい。
　制御部２４は、割当計算部２３からのＤＣ配置に従って、各ステート管理部５を各ＤＣ３にリソース割り当てを行う。
　図２は、リソース割当装置２のハードウェア構成図である。
　リソース割当装置２は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
　通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（リクエスト受信部２１、NWデータ収集部２２、割当計算部２３、制御部２４に備わるリソース割当プログラムなど）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
　図３は、割当計算部２３がグループごとにステート管理部を割り当てる分散クラウド環境８の構成図である。
　なお、図９の分散クラウド環境８ｚではグループの概念を考慮せず、ユーザ単位でＤＣの選択を行っていたために、ＤＣ間のステート共有が必要であった。そのため、ステート共有による余分なオーバーヘッドの影響で、ユーザ間の通信遅延も増大してしまっていた。
　一方、図３の分散クラウド環境８では、割当計算部２３はグループ単位でのＤＣ配置を行う。これにより、１グループあたり１つのステート管理部５が１台のＤＣ３に割り当てられる。例えば、第１グループ（UA1,UA2,UA3）用のステート管理部（STA）がDC1に割り当てられる一方、第２グループ（UB1,UB2）用のステート管理部（STB）がDC2に割り当てられる。よって、ステート共有時のオーバーヘッドを抑制し、厳しいリアルタイム要件に対応できる。
　また、割当計算部２３は、グループごとのアプリケーション種別に適したスキームをリクエストから参照することで、グループごとの要件に適したＤＣ配置を立案できる。
　つまり、割当計算部２３は、グループごとの要件に応じたスキームの割当指標を用いて、ステート管理部５を各データセンタに割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のデータセンタを決定する。以下、アプリケーション種別とスキームとの組み合わせとして事例を例示する。
　「事例１：完全同期型」は、グループに属するすべてのユーザの通信を逐一待ってからステートを同期することで、グループに属するすべてのユーザが同じ画面を閲覧させるアプリケーションである。以下、完全同期型のアプリケーションを例示する。
　・１対１の対戦格闘ゲーム。
　・図１の説明で前記した田畑を管理するシステム。
　完全同期型のスキーム（割当指標）は、「グループ内の最大遅延」を最小化するものである。グループ全体のQoS（Quality of Service）やQoE（Quality of Experience）が最も遅延の大きなユーザに依存するためである。
　「事例２：準同期型」は、ユーザ間で厳密な同期を取らない（取れない）アプリケーションであり、例えば、１００人程度のFPS（First-Person Shooter）のサバイバルゲームである。グループに属する遅延の大きいユーザの通信を待たずにステートを同期することで、遅延の大きいユーザが見る画面がカクついたり、遅延の大きいユーザのキャラクターの最新位置が他ユーザに見えなくなったりする。
　準同期型のスキーム（割当指標）は、「グループ内の平均遅延」を最小化するものである。例えば１００人のグループのうちの３人程度のメンバだけ大きな遅延が発生したとしても、その不便を感じるのは３人だけで、残りの９７人は小さい平均遅延で快適な環境が提供されれば充分である。
　「事例３：公平環境型」は、ユーザ間のプレイ環境において公平性が特に求められるリアルタイムアプリケーションであり、以下に例示する。
　・１０人程度が同時に同じサーキットを走行するレースゲーム。
　・XR空間やバーチャル会議室では、ユーザの動作が視界に反映されるまでの時間（motion-to-photonlatency）が20[ms]以下になることが望ましい。
　・現実の街を模した仮想空間内で会話をするアプリケーションでも、レスポンスを低下させないために一つの空間に滞在可能なユーザ数が制限されている。
　公平環境型のスキーム（割当指標）は、「グループ内の遅延のばらつき（分散または標準偏差）」を最小化するものである。
　一般に遅延が大きいほどQoS・QoEが低下し、仮想世界における優位性（例：ゲームのスコア）にも影響する。よって、公平環境型のアプリケーションに限らず、他の事例のアプリケーションでも、グループ内の遅延のばらつきを小さくすることが望ましい。
　以上、３種類のスキームを例示したが、例えば、準同期型のスキームとして「グループ内の平均遅延」および「グループ内の最大遅延」の最小化を同時に行うなど、複数の割当指標を組み合わせてもよい。同様に、公平環境型のスキームとして、「グループ内の平均遅延」と、「グループ内の最大遅延」と、「グループ内の遅延のばらつき」という３つの割当指標をバランスよく最小化してもよい。
　以下では、グループ内の遅延の最小化と平等化を両立するための定式化を行う。具体的には、３つの割当指標を総合的に評価可能なモデルを説明する。まず、モデルに用いられるパラメータを定義する。
　記号「i∈I」は、ユーザiとその集合Iを示す。
　記号「j∈J」は、グループj(j=1,2,...,n)とその集合Jを示す。
　記号「k∈K」は、ＤＣk（k番目のＤＣ、k=1,2,...,m）とその集合Kを示す。
　記号「Ij⊂I」は、グループjに属するユーザの集合Ijを示す。
　記号「wij」は、二値変数であり、ユーザiがグループjに属しているなら「1」、そうでなければ「0」の値をとる。
　記号「dik」は、ユーザi-ＤＣk間の遅延時間を示す。
　記号「Di」は、ユーザiの遅延要件を示す。
　記号「Ck」は、ＤＣkが収容可能なユーザ数を示す。
　これらの各パラメータは、リクエスト受信部２１のリクエストや、NWデータ収集部２２の収集データとして、割当計算部２３に与えられる。
Figure JPOXMLDOC01-appb-M000001
　割当計算部２３は、割当指標として（式１）および（式２）を計算する。最大遅延の計算式は（式４）で後記する。
　（式１）の左辺「ajk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの平均遅延を示す。
　（式２）の左辺「v2 jk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの遅延分散を示す。
Figure JPOXMLDOC01-appb-M000002
　（式３）はＤＣ割当の目的関数を示す。この目的関数は、グループjの割当コストの総和を最小化（minimize）する問題に帰着する。
　記号「cjk」は、グループjをＤＣkに収容した場合の割当コストである。
　記号「xjk」は、割当計算部２３の計算結果である。「xjk」は決定変数であり、グループjをＤＣkに収容したら「1」の値、そうでなければ「0」の値をとる。
　割当計算部２３が割当コストcjkを求める具体的な計算式として（式４）または（式５）を説明する。なお、遅延のばらつきを示す数値として、（式４）では分散を採用し、（式５）では標準偏差を採用した。分散の代わりに標準偏差を用いることで、２乗を含む項がなくなるので、各項のスケールをある程度合わせることができる。
Figure JPOXMLDOC01-appb-M000003
　α,β(α,β≧0, α+β≦1)は３つの割当指標間のトレードオフを調整するためのパラメータであり、サービス要件等に応じて、サービス提供者、ユーザ、または、NW事業者などが任意に決定する。
　（式４）の右辺第１項の「1-α-β」は、その数値が大きいほど「グループ内の平均遅延」を重視するハイパーパラメータである。
　（式４）の右辺第２項の「α」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
　（式４）の右辺第３項の「β」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。なお、右辺第３項のβよりも後の計算式はグループ内の最大遅延の計算式である。
　つまり、（式４）または（式５）では、以下のように３つのハイパーパラメータの配分に応じて、３種類の指標の優先度合いを調整できる。
　・α=0かつβ=0とした場合は、平均遅延のみを最適化する（事例２：準同期型に適した設定）。
　・α≠0かつβ=0(α+β<1)とした場合は（例：α=0.5,β=0）、平均遅延と分散（標準偏差）とを最適化する。
　・α=1かつβ=0(α+β=1)とした場合は、分散（標準偏差）のみを最適化する（事例３：公平環境型に適した設定）。
　・α=0かつβ≠0(α+β<1)とした場合は、平均遅延と最大遅延とを最適化する。
　・α=0かつβ=1(α+β=1)とした場合は、最大遅延のみを最適化する（事例１：完全同期型に適した設定）。
　・α≠0かつβ≠0(α+β=1)とした場合は、分散（標準偏差）と最大遅延とを最適化する。
　・α≠0かつβ≠0(α+β<1)とした場合は、平均遅延・分散（標準偏差）・最大遅延のすべてを最適化する。
Figure JPOXMLDOC01-appb-M000004
　なお、割当計算部２３は、割当コストcjkを求める計算式として、分散を用いる（式４）の代わりに（式６）を用いてもよいし、標準偏差を用いる（式５）の代わりに（式７）を用いてもよい。
　（式６）および（式７）では、３種類のハイパーパラメータ（α,β,γ）を用いている。これにより、パラメータ設定の自由度が高いが，その分扱い（最適なパラメータ設定）が難しくなる。
　右辺第１項の「α」は、その数値が大きいほど「グループ内の平均遅延」を重視するハイパーパラメータである。
　右辺第２項の「β」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
　右辺第３項の「γ」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。
　一方、（式４）や（式５）では、パラメータが一つ少なく設定範囲も狭い。しかし、割合で重みが設定できることもあり、３種類のハイパーパラメータ（α,β,γ）を用いるよりも、扱いが容易になる可能性が高い。
Figure JPOXMLDOC01-appb-M000005
　（式８）は、（式３）の目的関数に対応する制約条件（subject to）を示す。制約条件は以下の通りである。
　・1グループに割当てられるDCは1個以下である。
　・収容されるユーザ数が各DCの容量を超えない。
　・各ユーザの実際の遅延が遅延要件を満たす。
　以上、（式３）～（式８）として定式化した問題は、組み合わせ最適化問題であり、大域的最適解を求めるためには、割当計算部２３は、すべての組み合わせを調査（総当たり計算）する必要がある。このときの本問題の計算量は、グループ数をn、DC数をmとして計算量オーダ(mのn乗)であり膨大である。
　そこで、割当計算部２３が総当たり計算の代わりに用いる近似アルゴリズムとして、貪欲法（greedy algorithm）と、局所探索法とを順に説明する。割当計算部２３は、貪欲法を単独で用いる、または、貪欲法と局所探索法とを併用する。これにより、総当たり計算で求まる最適解（または最適解に近いスコアの準最適解）を、総当たり計算よりも少ない計算量で求めることができる。
　図４は、貪欲法のメイン処理を示すフローチャートである。なお、貪欲法とは、１つの大きな問題を複数の小さな問題に分割し、小さな問題を個別に評価して評価値の高い候補を採用する手法である。
　割当計算部２３は、リクエスト受信部２１からのリクエストと、NWデータ収集部２２からのNWデータとをもとに、図６で後記するコストテーブルを作成する（Ｓ１０１）。割当計算部２３は、Ｓ１０１のコストテーブルの各グループについて、コストの最小値を算出する（Ｓ１０２）。
　割当計算部２３は、コストテーブルの各グループについてコストの最小値について昇順ソートする（Ｓ１０３）。
　割当計算部２３は、グループの変数jに初期値1を代入する（Ｓ１０４）。
　ここで、割当計算部２３は、グループjをコストテーブルのグループ数まで1つずつ順番に選択するループを実行し（Ｓ１０５～Ｓ１０７）、このループ内でグループjにDC割当を行うサブルーチン（図５）を呼び出す（Ｓ１０６）。
　なお、Ｓ１０６の処理において、あるユーザの遅延要件を満たせるような割当先DCが存在しないとき、もしくはDCのキャパシティが十分でない場合は、割当できないグループが発生する可能性がある。
　図５は、図４の貪欲法のサブルーチン処理（Ｓ１０６）を示すフローチャートである。
　割当計算部２３は、コストテーブルの第jグループ行を読み込み（Ｓ１１１）、その中でコストが最小となるＤＣに割当を試みる（Ｓ１１２）。
　割当計算部２３は、ユーザの遅延要件を満たし（Ｓ１１３,Yes）、かつ、ＤＣの容量が充分にある（Ｓ１１４,Yes）場合に、グループｊをそのＤＣに割り当てる（Ｓ１１５）。
　一方、（Ｓ１１３,No）、または、（Ｓ１１４,No）の場合は、割当計算部２３は、そのＤＣを第ｊグループのコストテーブルから削除する（Ｓ１１６）。
　図６は、図４、図５の貪欲法の処理例を示す説明図である。
　説明をわかりやすくするため、図６では以下の問題設定とする。
　・6個のグループ（G1-G6）を3個のＤＣ（DC1-DC3）に割り当てたい。
　・各DCは2グループまで割当可能である。なお、本来のCkの単位はユーザ数であるが、ここでは簡単のためグループ数で指定した。
　・簡単のため、ユーザの遅延要件は考えない（つまりD=∞）。
　・平均遅延のみを考慮するため、α=β=0とする。もちろん他のパラメータ設定を用いてもよい。
　コストテーブル２０１は、グループjをＤＣkに収容した場合の割当コストcjkについて、グループjを行としＤＣkを列としたときの２次元のテーブルである。割当計算部２３は図４のＳ１０１でコストテーブル２０１を作成する。そして、割当計算部２３は、コストテーブル２０１を最小値で昇順ソートした結果をコストテーブル２０２とする（Ｓ１０３）。
　ＤＣ割当テーブル２１１～２１７は、コストテーブル２０２をもとにした割当計算部２３の計算結果「xjk」をテーブル形式にしたものである。例えば、ＤＣ割当テーブル２１４では、DC1に「G4,G2」という２グループが割り当てられ、DC2にはグループが未割当であり（記号「-」）、DC3に「G5」という１グループが割り当てられている。
　以下の手順により、割当計算部２３は、コストテーブル２０２の上位に位置するグループから順に、Ｓ１０６のサブルーチンを呼び出すことで各グループを各ＤＣに割り当てる。
　（第１行のG4）割当計算部２３は、G4をコスト最小（＝6.0）となるDC1に割り当てる（ＤＣ割当テーブル２１１→ＤＣ割当テーブル２１２）。
　（第２行のG2）割当計算部２３は、G2をコスト最小となるDC1に割り当てる（ＤＣ割当テーブル２１２→ＤＣ割当テーブル２１３）。
　（第３行のG5）割当計算部２３は、G5をコスト最小となるDC3に割り当てる（ＤＣ割当テーブル２１３→ＤＣ割当テーブル２１４）。
　（第４行のG6）割当計算部２３は、G6をコスト最小となるDC1に割り当てようとするも、DC1は容量不足である。よって、割当計算部２３は、G6をコストが２番目に小さいDC3に割り当てる（ＤＣ割当テーブル２１４→ＤＣ割当テーブル２１５）。
　（第５行のG3）割当計算部２３は、G3をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１５→ＤＣ割当テーブル２１６）。
　（第６行のG1）割当計算部２３は、G1をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１６→ＤＣ割当テーブル２１７）。
　以上、図４～図６を参照して貪欲法について説明した。
　以下では、貪欲法のアルゴリズムを詳細に説明する疑似コードを例示する。この疑似コードは、代入「A←1」（変数Aに値１を代入）、繰り返し制御「for～end for、while～end while」、分岐制御「if～end if」などを行う手続型言語である。また、疑似コードの行頭には、説明用の行番号（L01,L02,…）を付加した。
　各関数（function）は、「Input:～」で与えられた入力変数をもとに、所定の計算を行い、その計算結果を「Output:～」で示す出力変数として応答（return）する。
　まず、Greedy_Allocation関数を示す。
　Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
　Output: xjk for ∀j∈J and ∀k∈K
　L01: function Greedy_Allocation(α,β,wij,dik,Di,Ck)
　L02:   for all i∈I,j∈J,k∈K do
　L03:     w[i][j]←wij,d[i][k]←dik
　L04:     D[i]←Di,C[k]←Ck
　L05:     Calculate cjkusing （式4）～（式7）
　L06:     c[j][k]←cjk
　L07:   end for
　L08:   for all j∈J do
　L09:     J[j]←j,L[j]←minkc[j][k]
　L10:   end for
　L11:   Sort J in ascending order of L
　L12:   X←GroupDC_Mapping(J,c,w,d,D,C)
　L13:   return X
　L14: end function
　Greedy_Allocation関数(α,β,wij,dik,Di,Ck)では、αおよびβを用いてコスト表を作成し（L05）、表の中で最小コストが小さいグループから優先的に（L11）DC割当を行うための前処理を行う。なお、実際のDC割当については引数wij,dik,Di,Ckと、ここで作成されたコスト表cおよびコスト表を参照する順列Jを引数としたGroupDC_Mapping関数を呼び出して実行する（L12）。
　図４のフローチャートでは、Ｓ１００がL01に、Ｓ１０１がL05に、Ｓ１０２がL09に、Ｓ１０３がL11に、Ｓ１０６がL12に、それぞれ対応する。
　次に、GroupDC_Mapping関数を示す。
　L16: function GroupDC_Mapping(J,c,w,d,D,C)
　L17:   for j'=1 to size(J) do
　L18:     j←J[j']
　L19:     Discover Ijfrom I using w
　L20:     X[j]←DC_Selection(c[j],Ij,d,D,C)
　L21:     if X[j]=∞ then
　L22:       D[i]←∞ for ∀i∈Ij
　L23:       X[j]←DC_Selection(c[j],Ij,d,D,C)
　L24:     end if
　L25:   end for
　L26:   return X
　L27: end function
　GroupDC_Mapping関数(J,c,w,d,D,C)では、与えられたコスト表cを順列Jにしたがって（L17）順に参照し（すなわちコスト表のある行c[j]を抽出し）、各グループにDCを割り当てるためのDC_Selection関数を順次呼び出して割当を得る（L20,L23）。仮にDC_Selection関数がユーザの遅延要件Dを満たすことのできるDCが存在しないことを示した場合には、遅延要件Dを無視して割当を行う。
　なお、L20,L23のX[j]←kは、割り当て有なら値１（xjk’=1 if k’=k）、または、割り当て無なら値０（xjk’=0 otherwise）と等価である。
　図４のフローチャートでは、Ｓ１０４、Ｓ１０５、および、Ｓ１０７がL17～L25のfor文に、Ｓ１１２がL20およびL23に、それぞれ対応する。
　さらに、DC_Selection関数を示す。
　L29: function DC_Selection(c[j],Ij,d,D,C)
　L30:   tmp←c[j]
　L31:   while True do
　L32:     k←arg mink'tmp[k']
　L33:     if tmp[k]=∞ then
　L34:       return ∞
　L35:     end if
　L36:     if d[i][k]≦D[i] for ∀i∈I and |Ij|≦C[k] then
　L37:       C[k]←C[k]-|Ij|
　L38:       return k
　L39:     else
　L40:       tmp[k]←∞
　L41:     end if
　L42:   end while
　L43: end function
　DC_Selection関数(c[j],Ij,d,D,C)では、グループメンバIjについて、各ユーザの遅延要件Dを満たし、残容量Cがグループサイズ|Ij|より大きいDCの中から（L36）、遅延コストc[j][k]が最も小さいDCkを割当先として選択する（L37,L38）。
　図５のフローチャートでは、Ｓ１１３およびＳ１１４がL36に、Ｓ１１５がL37に、Ｓ１１６がL40に、それぞれ対応する。なお、L40の「tmp[k]←∞」とは、グループコストを無限大にすることで、そのグループを割り当て対象から削除することと等価である。
　以上説明したように、割当計算部２３は、貪欲法を単独で用いる場合は、Greedy_Allocation関数を呼び出せばよい。これにより、グループをソートし、コストが小さいものから優先的に割り当てていくことで、少ない計算時間で高精度な最適化が可能となる。一方、割当計算部２３は、提案法と局所探索法とを組み合わせることで、さらに良い解を求めてもよい。
　以下は、提案法と局所探索法とを組み合わせたアルゴリズムの疑似コードである。
　Input: N,α,β,wij,dik,Di, and Ck
　Output: xjk
　M01: X←Greedy_Allocation(α,β,wij,dik,Di,Ck)
　M02: Calculate the total cost tx of X like （式3）
　M03: n←0
　M04: while n++<N do
　M05:   Randomize the order of J
　M06:   X'←GroupDC_Mapping(J,c,w,d,D,C)
　M07:   Calculate the total cost t'xof X'
　M08:   if t'x<txthen
　M09:     X←X',tx←t'x
　M10:   end if
　M11: end while
　この疑似コード（M01～M11）では、まず、割当計算部２３は、Greedy_Allocation関数を実行する（M01）。次に、割当計算部２３は、GroupDC_Mapping関数を一定回数（M04のN回）実行する（M06）。このとき、「コストテーブルのソート」の部分で、割当計算部２３は、グループの順列をランダムに変更する（M05）。そして、割当計算部２３は、N回の繰り返しの中で最も全体のコストが低かった割当を選択する（M08～M10）。
　この疑似コード（M01～M11）により、GroupDC_Mapping関数をN回繰り返す旨の探索回数の追加により、計算コストは増えるものの、貪欲法よりも割当コストがさらに小さくなる可能性がある。なお、探索回数Nはサービス提供者や分散環境運用者が任意に設定する。
　ここで、リクエスト受信部２１に与えられるグループ数に着目して、以下のように分類する。
　（分類１）オフライン割当は、割り当てるべきすべてのグループがあらかじめリクエスト受信部２１に与えられる場合である。
　（分類２）バッチ割当は、割り当てるべきグループの一部（複数のグループ）が逐次リクエスト受信部２１に与えられ、その都度（比較的小規模な）オフライン割当を実行する場合である。例えば大規模システムでは、例えば10秒の間にいくつものグループが作成されるため、この場合は10秒ごとにバッチ割当をおこなうニーズが出てくる。
　（分類３）オンライン割当は、割り当てるべきグループが一つずつリクエスト受信部２１に与えられ、その都度割当を実行する場合である。例えば、バッチ処理を実行するほど頻繁にグループが形成されない場合や、グループ形成から割当完了までの時間を可能な限り小さくしたい場合などが挙げられる。
　これまで説明したGreedy_Allocation関数は、リクエスト受信部２１にまとまった数のグループが与えられた場合（オフライン割当やバッチ処理）を想定している。一方、リクエスト受信部２１に割り当てるべきグループが逐次やってくる場合には、以下に示すオンライン割当の疑似コードを実行すればよい。
　Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
　Output: xjk for ∀j∈J and ∀k∈K
　N01: while True do
　N02:   if receive an offload request for group j then
　N03:     Calculate cjkfor ∀k∈K
　N04:     c[k]←cjk
　N05:     X[j]←DC_Selection(c[j],Ij,d,D,C)
　N06:     if X[j]=∞ then
　N07:       D[i]←∞ for ∀i∈Ij
　N08:       X[j]←DC_Selection(c[j],Ij,d,D,C)
　N09:     end if
　N10:     return X[j]
　N11:   end if
　N12: end while
　この疑似コード（N01～N12）では、まず、割当計算部２３は、グループjの割当リクエストを受信したとき（N02）、そのグループjと各DC間の割当コストcjkをすべて計算し（N03）、グループjについてのみのコストテーブルを作成する（N04）。
　そして、割当計算部２３は、グループjについてDC_Selection関数を実行する（N05,N08）。このとき、割当計算部２３は、各DCの容量Ck=C[k]を常にモニタしておき、グループjがDCを離れたときはその分容量を増やす。
　以下、（分類１）～（分類３）それぞれの計算量を示すため、各分類の関数の呼び出す回数を例示する。
　（分類１）オフライン割当として、グループ数＝10がいっぺんに与えられる場合は、以下の通りである。
　（分類１）で貪欲法だけを実行する場合は、Greedy_Allocation関数を1回、GroupDC_Mapping関数を1回、DC_Selection関数を10回以上実行する。なお、DC_Selection関数を呼び出す回数が10回を超える場合は、ユーザの遅延要件を満たせるDCがなかった場合（L20行目の返り値が∞となった場合）に、L23行目に移って再びDC_Selection関数が呼び出される場合である。
　（分類１）で貪欲法と局所探索とを併せて実行する場合は、Greedy_Allocation関数を１回実行した後、GroupDC_Mapping関数およびDC_Selection関数をワンセットとしてN回繰り返す（Greedy_Allocation関数を1回、GroupDC_Mapping関数を1+N回、DC_Selection関数を10×(1+N)回以上）。Nはオペレータ等が任意に設定可能なパラメータである。
　（分類２）バッチ割当として、グループ数＝10が、「グループ数＝5」→「グループ数＝3」→「グループ数＝2」の順に３段階で与えられる場合は、以下の通りである。
　（分類２）で貪欲法だけを実行する場合は、以下のようになる。
　・Greedy_Allocation関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
　・GroupDC_Mapping関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
　・DC_Selection関数を5回以上（グループ数5のとき）＋3回以上（グループ数3のとき）＋2回以上（グループ数2のとき）で計10回以上実行する。
　（分類２）で貪欲法と局所探索とを併せて実行する場合は、Greedy_Allocation関数を各１回ずつ行った後、GroupDC_Mapping関数およびDC_Selection関数をワンセットとして各バッチ処理時にN回ずつ繰り返すことになるため、以下のようになる。
　・Greedy_Allocation関数を各1回ずつ計3回実行する。
　・GroupDC_Mapping関数を各(1+N)ずつ×3回実行する。
　・DC_Selection関数を5×(1+N)回以上＋3×(1+N)回以上＋2×(1+N)回以上で計10×(1+N)回以上実行する。
　（分類３）オンライン割当として、グループ数＝10が１つずつ与えられる場合は、以下のようになる。
　（分類３）で貪欲法だけを実行する場合は、DC_Selection関数を1回or2回ずつ10回呼び出されるため計10回以上実行する。
　（分類３）で貪欲法と局所探索とを併せて実行することは不可である。1つのグループしかない場合は、割当順序が関係ないため、局所探索をおこなう余地がないためである。
［効果］
　本発明のリソース割当装置２は、複数のユーザ端末４から構成されるグループごとのステートをグループ内で共有させるためのステート管理部５を、分散クラウド環境８に配備された複数のＤＣ３のうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部２１と、
　グループが要求する要件に応じた割当指標を用いて、ステート管理部５を各ＤＣ３に割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のＤＣ３を決定する割当計算部２３とを有することを特徴とする。
　これにより、グループのメンバであるユーザ端末４が、そのグループでステート管理部５を共有して行うアプリケーションに適した割当先にステート管理部５を割り当てることができる。よって、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことができる。
　本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の平均遅延をステート管理部５の割当指標とすることを特徴とする。
　これにより、サバイバルゲームなどの多人数が参加するアプリケーションにおいて、その多数が満足する割当先を発見できる。
　本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の最大遅延をステート管理部５の割当指標とすることを特徴とする。
　これにより、対戦格闘ゲームなどのグループに属するすべてのユーザの通信で厳密な同期を要するアプリケーションに適した割当先を発見できる。
　本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の分散または標準偏差をステート管理部５の割当指標とすることを特徴とする。
　これにより、レースゲームなどのユーザ間のプレイ環境の公平性が特に求められるリアルタイムアプリケーションに適した割当先を発見できる。
　本発明は、割当計算部２３が、リクエスト受信部２１が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法を用いた近似アルゴリズムにより、各グループの割当先を計算することを特徴とする。
　これにより、組み合わせ最適化問題に対して総当たり計算よりも少ない計算量で、妥当な割当先を計算することができる。
　本発明は、割当計算部２３が、リクエスト受信部２１が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法と局所探索法とを併用する近似アルゴリズムにより、各グループの割当先を計算することを特徴とする。
　これにより、貪欲法を単独で用いる場合と比べて、さらに良い割当先を発見する可能性が高まる。
　１　　　サービス提供装置
　２　　　リソース割当装置
　３　　　ＤＣ（データセンタ）
　４　　　ユーザ端末
　５　　　ステート管理部
　８　　　分散クラウド環境
　９　　　オンラインシステム
　２１　　リクエスト受信部
　２２　　NWデータ収集部
　２３　　割当計算部
　２４　　制御部

Claims (8)

  1. 　複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部と、
    　前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定する割当計算部とを有することを特徴とする
    　リソース割当装置。
  2. 　前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の平均遅延を前記ステート管理部の割当指標とすることを特徴とする
    　請求項１に記載のリソース割当装置。
  3. 　前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の最大遅延を前記ステート管理部の割当指標とすることを特徴とする
    　請求項１に記載のリソース割当装置。
  4. 　前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の分散または標準偏差を前記ステート管理部の割当指標とすることを特徴とする
    　請求項１に記載のリソース割当装置。
  5. 　前記割当計算部は、前記リクエスト受信部が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法を用いた近似アルゴリズムにより、各グループの割当先を計算することを特徴とする
    　請求項１ないし請求項４のいずれか１項に記載のリソース割当装置。
  6. 　前記割当計算部は、前記リクエスト受信部が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法と局所探索法とを併用する近似アルゴリズムにより、各グループの割当先を計算することを特徴とする
    　請求項１ないし請求項４のいずれか１項に記載のリソース割当装置。
  7. 　リソース割当装置は、リクエスト受信部と、割当計算部とを有しており、
    　前記リクエスト受信部は、複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信し、
    　前記割当計算部は、前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定することを特徴とする
    　リソース割当方法。
  8. 　コンピュータを、請求項１ないし請求項６のいずれか１項に記載のリソース割当装置として機能させるためのリソース割当プログラム。
PCT/JP2021/005175 2021-02-12 2021-02-12 リソース割当装置、リソース割当方法、および、リソース割当プログラム WO2022172389A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022581105A JPWO2022172389A1 (ja) 2021-02-12 2021-02-12
PCT/JP2021/005175 WO2022172389A1 (ja) 2021-02-12 2021-02-12 リソース割当装置、リソース割当方法、および、リソース割当プログラム
US18/276,474 US20240126612A1 (en) 2021-02-12 2021-02-12 Resource allocation device, resource allocation method, and resource allocation program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/005175 WO2022172389A1 (ja) 2021-02-12 2021-02-12 リソース割当装置、リソース割当方法、および、リソース割当プログラム

Publications (1)

Publication Number Publication Date
WO2022172389A1 true WO2022172389A1 (ja) 2022-08-18

Family

ID=82838538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/005175 WO2022172389A1 (ja) 2021-02-12 2021-02-12 リソース割当装置、リソース割当方法、および、リソース割当プログラム

Country Status (3)

Country Link
US (1) US20240126612A1 (ja)
JP (1) JPWO2022172389A1 (ja)
WO (1) WO2022172389A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115412563A (zh) * 2022-08-22 2022-11-29 西南交通大学 一种边缘设备资源分配方法、装置、设备及可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09508255A (ja) * 1994-11-22 1997-08-19 ノキア テレコミュニカシオンス オサケ ユキチュア 移動無線システムにおいてグループデータを維持する方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09508255A (ja) * 1994-11-22 1997-08-19 ノキア テレコミュニカシオンス オサケ ユキチュア 移動無線システムにおいてグループデータを維持する方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115412563A (zh) * 2022-08-22 2022-11-29 西南交通大学 一种边缘设备资源分配方法、装置、设备及可读存储介质
CN115412563B (zh) * 2022-08-22 2024-03-22 西南交通大学 一种边缘设备资源分配方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
US20240126612A1 (en) 2024-04-18
JPWO2022172389A1 (ja) 2022-08-18

Similar Documents

Publication Publication Date Title
US8219617B2 (en) Game system, game terminal therefor, and server device therefor
US8250198B2 (en) Capacity planning for data center services
US11102717B2 (en) Network selection method and apparatus for integrated cellular and drone-cell networks
US20100113159A1 (en) Method and apparatus for partitioning virtual worlds using prioritized topic spaces in virtual world systems
CN110098969A (zh) 一种面向物联网的雾计算任务卸载方法
KR102352375B1 (ko) 유전 알고리즘 기반의 엣지 컴퓨팅 최적화 장치 및 방법
DE112021003383T5 (de) Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen
CN101331739A (zh) 对等网络内容传输方法及装置
Jia et al. Delay-sensitive multiplayer augmented reality game planning in mobile edge computing
WO2022172389A1 (ja) リソース割当装置、リソース割当方法、および、リソース割当プログラム
CN109947574A (zh) 一种基于雾网络的车辆大数据计算卸载方法
CN108183828B (zh) 一种基于局部无线网络拓扑的流量控制方法
CN114564312A (zh) 一种基于自适应深度神经网络的云边端协同计算方法
CN114024970A (zh) 基于边缘计算的电力物联网工作负载分配方法
Wang et al. Multi-attributes-based coflow scheduling without prior knowledge
CN112256413A (zh) 基于物联网的边缘计算任务的调度方法和装置
Parastar et al. Frame-sdn: a fair resource allocation for multiplayer edge-based cloud gaming in sdn
CN111211984A (zh) 优化cdn网络的方法、装置及电子设备
CN111135586A (zh) 游戏匹配方法、游戏匹配装置、存储介质与电子设备
Alevizaki et al. Distributed service provisioning for disaggregated 6g network infrastructures
Li et al. User dynamics-aware edge caching and computing for mobile virtual reality
CN110743164B (zh) 一种用于降低云游戏中响应延迟的动态资源划分方法
Wong et al. Network Latency Classification for Computer Games
CN109298932B (zh) 基于OpenFlow的资源调度方法、调度器及系统
Chu et al. Dynamic resource allocation for metaverse applications with deep reinforcement learning

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21925642

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022581105

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18276474

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21925642

Country of ref document: EP

Kind code of ref document: A1