CloudRIC: Real-time and energy-efficient control of vRAN resources in shared O-RAN clouds.

Abstract

A method for real-time joint control of radio resources and computing resources in an O-RAN O-Cloud platform is disclosed.

Description

[Technical Field]

[0001] The project leading to this application is funded under European Union Horizon 2020 Research and Innovation Programme Grant Agreement No. 101017109.

[0002] This disclosure relates to communication systems. This disclosure is particularly relevant to, but not limited to, wireless communication systems and devices operating in accordance with the Third Generation Partnership Project (3GPP) standards or their equivalents or derivatives. This disclosure is particularly relevant to, but not limited to, systems using real-time and energy-efficient control of virtualized radio access network (vRAN) resources. [Background technology]

[0003] The O-RAN Alliance (O-RAN) is a group that defines the specifications for Open Radio Access Networks (Open RAN). The Open RAN architecture is based on a distributed approach to deploying RANs, built on cloud-native principles, and represents an evolution of next-generation RAN (NG-RAN) architectures.

[0004] O-RAN proposes a cloud architecture for hosting O-RAN-compliant network functions (NFs), such as distributed units (DUs). Within this architecture, the O-RAN Acceleration Abstraction Layer (AAL) provides a common interface for NFs, such as DUs, to access hardware accelerators (HAs). This abstraction allows developers to decouple software design from accelerator details.

[0005] To this end, O-RAN introduced the concept of AAL Logical Processing Units (AAL-LPUs), as shown in Figure 1. An AAL-LPU is a logical representation of an HA resource within a particular NF (e.g., a DU). This representation supports HAs that provide multiple processing units, subsystems, or hard partitions of HA resources, each represented as an AAL-LPU. While an HA may support multiple AAL-LPUs, as shown in Figure 3, an AAL-LPU is always associated with a single HA. An AAL queue is then used by the NF to share the AAL-LPU resources. In addition, an AAL-LPU can be associated with one or more AAL profiles that specify functions that can be offloaded to the HA. The following description will focus on forward error correction (FEC), low-density parity check (LDPC), and decoding tasks.

[0006] The main problem with this approach is that load balancing cannot be efficiently implemented because the NF can greedily select HA. For example, on a platform with heterogeneous acceleration resources, the NF may overload the fastest HA, potentially degrading overall performance. Thus, because centralized coordination of acceleration resources is not supported and wireless scheduling policies cannot be imposed on the relevant DUs, O-RAN's AAL alone cannot efficiently mediate access to the shared infrastructure, despite providing appropriate abstractions.

[0007] Previous research proposed three extensions to the O-RAN open cloud (O-Cloud) architecture, as shown in Figure 2. These extensions integrate seamlessly with the standard O-RAN O-Cloud architecture and add three key enhancements. This is a function called a Real-Time RAN Intelligent Controller (or "Real-Time RIC (RT-RIC)") that receives temporary grants issued by the DU and returns a final grant, which is a modification (or non-modification) of the temporary grant that can maximize wireless throughput, allowing the AAL to meet the processing deadline for the corresponding transport block (TB). This feature, called "AAL Broker," has two subcomponents. - AAL Broker Control Plane (AAL-B-CP): This plane is responsible for allocating LPUs to final grants to meet processing deadlines with minimal energy costs. - AAL Broker User Plane (AAL-B-UP): Functions as a proxy between the O-RAN NF (O-DU in this case) and the O-RAN AAL. From the NF's perspective, AAL-B-UP acts as a virtual AAL LPU providing all AAL profiles supported by all HAs in the system. From the perspective of each O-RAN AAL LPU, AAL-B-UP simply acts as the NF. AAL-B-UP is responsible for routing the TBs authorized by the UE to the AAL queues corresponding to the LPUs allocated by the AAL-B-CP. This is an interface for real-time communication between the broker, RT-RIC, and O-DU, and is called the "E3" interface.

[0008] Given the real-time nature of Interface E3, it is expected that the RT-RIC, DU instances, and AAL broker will be deployed on the same physical infrastructure, such as an edge data center.

[0009] This approach has three advantages. 1. Separating AAL-B-CP and AAL-B-UP minimizes data plane overhead. 2. By centrally managing the allocation of computing resources, it becomes possible to balance the load more appropriately in order to achieve the desired objectives. 3. By influencing the DU's wireless scheduler, it is possible to ensure that deadlines are met (for example, by limiting the allocation of wireless resources when the AAL queue is congested).

[0010] However, the remaining challenge is to design an efficient method for optimizing RAN performance using the architecture shown in Figure 2.

[0011] Therefore, in summary, the O-RAN standard has a problem in that load balancing cannot be efficiently implemented because NFs can only greedily select HAs without information about the queues associated with other NFs that share the same HA. This is highly inefficient on platforms with heterogeneous acceleration resources, as NFs overload the fastest HAs, degrading overall performance and consuming more energy. While previous studies have offered some advantages, they have not provided a mechanism to utilize AAL-Broker and RT-RIC in a way that contributes to maximizing throughput and minimizing energy consumption. [Overview of the project] [Problems that the invention aims to solve]

[0012] The present invention aims to address one or more of the above-mentioned problems or issues, or to improve them at least partially. [Means for solving the problem]

[0013] Next, the present invention will be described simply as an example, with reference to the attached drawings. [Brief explanation of the drawing]

[0014] [Figure 1]Figure schematically showing the O-RAN acceleration abstraction layer (AAL). [Figure 2] Figure schematically showing the O-Cloud architecture. [Figure 3] Figure schematically showing the design and workflow of Cloud RIC. [Figure 4] Figure showing the LPU allocator. [Figure 5a] Message sequence diagram of the workflow shown in Figure 3. [Figure 5b] Message sequence diagram of the workflow shown in Figure 3. [Figure 6] Figure schematically showing the O-RAN architecture to which the above aspects are applicable. [Figure 7] Block diagram showing the main components of the UE. [Figure 8] Block diagram showing the main virtual components of an exemplary v(R)AN node. [Figure 9] Block diagram showing the main virtual components of the core network node.

Mode for Carrying Out the Invention

[0015] Figure 3 shows the design and workflow of the Cloud RAN Intelligent Controller (RIC).

[0016] For the sake of explanation, consider a system that includes a small number of virtual DU instances sharing the same O-Cloud infrastructure to offload the FEC decoding task.

[0017] Also consider an O-Cloud that includes a set of M heterogeneous HAs that may be different.

[0018] The DU allocates radio resources to the relevant UE by issuing grants according to its own MAC layer scheduling procedure, but fortunately, it follows a simple policy referred to herein as CloudRIC, as will be discussed later.

[0019] The resulting transport block (TB) sent by the user (UE) is processed (decoded) by the AAL within a time constraint D; otherwise, the TB is discarded.

[0020] The goal here is to minimize the system's energy consumption over the long term, provided that the time constraint D for all scheduled TBs is met.

[0021] A crucial consideration in the design of real-time RAN control mechanisms, often overlooked in the literature, is the latency overhead they introduce, which is added to the overall processing latency of the TB. Therefore, it is beneficial to design systems that expedite decision-making, eliminating the need for complex optimization approaches or large-scale machine learning models.

[0022] A particularly useful detailed diagram of the CloudRIC design is shown in Figure 3. Exemplary implementations of the workflow shown in Figure 3 are shown in Figures 5a and 5b, which illustrate possible message sequences between various entities in the system for implementing the workflow. The key to this CloudRIC design is its reliance on distributed, ultralight neural network models that work together efficiently. The main workflow of this design is as follows:

[0023] Step (1) All temporary grants arriving at RT-RIC

[0024]

number

[0025] bandwidth

[0026]

number

[0027] (Number of RBs), selected modulation and coding scheme (MCS) (i) UE's signal-to-noise ratio (SNR) q (i) , corresponding TB size (bits)

[0028]

number

[0029] and priority p (i) This includes, in other words, the following:

[0030]

number

[0031] Top bar

[0032]

number

[0033] Here, it is used to indicate that the corresponding element is temporary.

[0034] Step (2) Temporary Grant

[0035]

number

[0036] Upon receiving this, the RT-RIC state processor receives each AAL queue from AAL-B-CP.

[0037]

number

[0038] We collect state information related to L in the formula. k This is the kth LPU. This information consists of estimated (predicted) latency values ​​for each AAL queue, as shown below.

[0039]

number

[0040] Hat on top

[0041]

number

[0042] Here, the corresponding element is used to indicate that it is a prediction.

[0043] Waiting time

[0044]

number

[0045] To estimate, AAL-B-CP uses queues.

[0046]

number

[0047] All Grant G (k) Estimated processing time

[0048]

number

[0049] and the grants being processed on the LPU at that time (s) The expected remaining processing time for the associated TB is aggregated, i.e.

[0050]

number

[0051] And in the formula,

[0052]

number

[0053] This is the (actual) time that has been held in the LPU up to this point (s <k<i)。

[0054] Processing time

[0055]

number

[0056] A useful approach for calculating this is detailed in step (5).

[0057] Step (3) The state processor converts all of the above information into a single feature vector x (i) To integrate into.

[0058]

number

[0059] Vector x (i) Given, the wireless agent μ,

[0060]

number

[0061] is the final grant

[0062]

Number

[0063] The radio allocation policy is such that the bandwidth (number of RBs) permitted to

[0064]

Number

[0065] is calculated.

[0066] · Step (4) As shown in FIGS. 3 and 5, the radio allocation policy r (i) is transmitted to both the corresponding DU and AAL-B-CP via interface E3. The policy r (i) determines the final scheduling grant,

[0067]

Number

[0068] which can be allocated to the UE,

[0069]

Number

[0070] is the corresponding TB size (bits). The DU can now notify the UE of the grant g (i) in a DCI message as specified by 3GPP.

[0071] · Step (5) Next, using the computational resource model v n for each LPU n ∈ L, the grant g (i)The time required by the LPU to process the associated TB with FEC.

[0072]

number

[0073] and energy

[0074]

number

[0075] It is estimated that, that is,

[0076]

number

[0077] These are stateless models, and therefore can be constructed using simple neural networks trained offline for each HA.

[0078] As shown in Figures 3 and 5, the LPU allocation function grants g based on a simple algorithm (shown in Figure 4). (i) The LPU is pre-allocated to the associated TB. In short, the LPU allocation function removes AAL LPUs that do not have the bit capacity to store TB from the set of LPUs L, creating a (sub)set of LPUs L1⊆L. Then, the estimated latency and processing time calculated above are used.

[0079]

number

[0080] and

[0081]

number

[0082] Using this, the allocator calculates the expected processing time.

[0083]

number

[0084] Remove LPUs with the specified value from the (sub)set L1 to generate a "shortlist" (sub)set L2 ⊆ L1 of LPUs. Then, given the shortlist L2, find the minimum expected energy

[0085]

number

[0086] A single LPU k∈L2 capable of processing the TB is selected. This simple "greedy" approach is efficient and very fast. Prioritization information for the TB p (i) This can also be used when selecting an LPU.

[0087] If the HA cannot process the grant within the time limit, the DU will be denied permission to issue that scheduling grant.

[0088] Step (6) After a time equal to K2 (as specified by 3GPP), the UE will grant the scheduled grant. (i) The corresponding TB is transmitted wirelessly via PUSCH. Upon reception, the DU forwards the TB to the AAL-B-UP dispatcher, which simply routes the data to the AAL queue pre-allocated for FEC processing. Once the corresponding LPU completes its task, the decoded data is sent back to the DU for further 3GPP standard processing (e.g., Cyclic Redundancy Check (CRC) verification), the AAL-B-CP updates its queue status information, and the LPU begins processing the next TB in the queue.

[0089] overview Beneficial in nature, the embodiments described above include, but are not limited to, one or more of the following:

[0090] A method to maximize throughput and minimize energy consumption in real time by providing a computationally conscious wireless scheduling policy and an LPU (Logical Processing Unit) allocator that jointly allocates hardware accelerators to each wireless scheduling grant, based on predictions of the processing latency and energy consumption of each hardware accelerator in a pool of heterogeneous hardware accelerators.

[0091] To provide the above functionality, this specification describes the following exemplary steps. 1) Before scheduling the final grant, the DU issues a request to the RT-RIC state processor along with a temporary grant. 2) A state processor constructs a state feature vector using that information and wait estimates from the AAL broker. 3) A radio agent that uses such state feature vectors to propose a radio resource policy consisting of a limit (or no limit) on the amount of bandwidth that the DU can use for the final grant. 4) A set of computational resource models that use wireless policy and grant information to predict the processing latency and energy consumption of each hardware accelerator. 5) An LPU allocator that uses the predictions from step 4 to pre-allocate AAL queues / LPUs (hardware accelerators) to scheduled grants. 6) When the TB arrives (after time K2, when the radio grant is signaled to the UE according to the 3GPP specification), the AAL-B-UP redirects the encoded TB to a pre-allocated AAL queue / LPU.

[0092] The above features contribute to maximizing network throughput in a shared O-Cloud system with minimal energy consumption.

[0093] System Overview Figure 6 schematically shows an O-RAN architecture to which the above embodiment can be applied.

[0094] This architecture includes the following functional components, Non-RT RIC 11 and near-RT RIC 12. The former is hosted by the system's SMO framework 10 (e.g., integrated within ONAP), and the latter may reside in the same location as the 3GPP gNB functions (O-CU and / or O-DU), or in a separate node, provided latency constraints are met. Figure 6 also shows O-Cloud, an O-RAN compliant cloud platform that deploys eNB / gNB as virtualized network functions in v(R)AN scenarios using hardware acceleration add-ons as needed, and a hardware-decoupled software stack.

[0095] As shown in Figure 6, O-RAN enables radio resource management (RRM) from Near-RT RIC 12 via the E2 open interface. The E2 node is a 3GPP-defined RAN NF such as DU. Meanwhile, the O2 interface is used by SMO 10 to provide non-RT infrastructure and NF lifecycle management procedures in a virtualized environment known as O-Cloud.

[0096] SMO10 has a range of organizational and management services that go beyond pure RAN management, such as 3GPP(NG-) core management or end-to-end network slice management. In the context of O-RAN, SMO10's primary responsibilities include failure, configuration, accounting, performance, and security (FCAPS) interfaces to O-RAN network functions, large-scale timescale RAN optimization, as well as O-Cloud management and orchestration via O2 interfaces, including resource discovery, scaling, FCAPS, software management, and interaction with O-Cloud resources.

[0097] Non-RT RIC 11 is a logical function that enables non-real-time control and optimization of RAN elements and resources, AI / ML workflows including model training and updating, and policy-based guidance for applications / functions of near-RT RIC 12. Non-RT RIC 11 also provides an A1 interface to Near-RT RIC 12. Its primary purpose is to support large-scale timescale RAN optimization (seconds or minutes), including policy calculation, ML model management, and other radio resource management functions within this timescale. Data management tasks requested from Non-RT RIC 11 are translated into O1 / O2 interfaces, and contextual / enrichment information can be provided to Near-RT RIC 12 via the A1 interface.

[0098] Near-RT RIC 12 is a logical function that (i) exposes E2 node data (network measurements, context information, etc.), (ii) implements RRM procedures defined by 3GPP, and (iii) deploys radio control policies to E2 nodes. Furthermore, Near-RT RIC 12 enables near real-time optimization and control of O-CU and O-DU nodes and resources, as well as data monitoring, on a Near-RT timescale (10ms to 1s) through fine-grained data acquisition and action via the E2 interface. Control of Near-RT RIC 12 is guided by policy and supported by models computed / trained by non-RT RIC 11. Near-RT RIC 12 also supports xApps (independent software plug-ins to the Near-RT RIC 12 platform for third-party extensions of RAN functionality).

[0099] This architecture essentially provides three independent control loops. • Non-RT RIC 11 control loop: Large-scale timescale operation ranging from a few seconds to several minutes. Its purpose is to perform O-RAN-specific orchestration decisions, such as policy configuration or ML model training. • Near-RT RIC 12 control loop: Sub-second timescale operation. Its purpose is to perform tasks such as policy enforcement or wireless resource management. • O-DU scheduler control loop: Real-time operation performing legacy radio operations such as HARQ, beamforming, or scheduling.

[0100] While control loops are understood to be independent, it should be understood that they can still interact with each other.

[0101] Furthermore, although not shown in Figure 6, the O-RAN architecture has been extended to include the RT-RIC, AAL broker, and the so-called "E3" interface between the broker, RT-RIC, and O-DU (as shown in Figures 2 and 3). These extensions are seamlessly integrated into the standard O-RAN O-Cloud architecture shown in Figure 6.

[0102] The RT-RIC receives temporary grants issued by the DU and returns a final grant (which may represent a modification (or unmodification) of the temporary grant), thereby maximizing wireless throughput and enabling the AAL to meet the corresponding TB processing deadline.

[0103] The AAL broker has two subcomponents: the AAL broker control plane (AAL-B-CP) and the AAL broker user plane (AAL-B-UP). The AAL-B-CP is responsible for allocating LPUs to final grants to meet processing deadlines with minimal energy cost. The AAL broker user plane (AAL-B-UP) acts as a proxy between the O-RAN NF (O-DU in this case) and the O-RAN AAL. From the NF's perspective, the AAL-B-UP behaves as a virtual AAL LPU providing all AAL profiles supported by all HAs in the system. From the perspective of each O-RAN AAL LPU, the AAL-B-UP simply acts as the NF. The AAL-B-UP is responsible for routing TBs authorized by the UE to the AAL queues corresponding to the LPUs allocated by the AAL-B-CP. The E3 interface is the interface for real-time communication between the AAL broker, RT-RIC, and O-DU.

[0104] The components of this architecture are configured to perform one or more of the solutions described above.

[0105] User Equipment (UE) Figure 7 is a block diagram showing the main components of the UE (Mobile Device 3) that communicate with the system shown in Figure 6. As shown, the UE includes a transceiver circuit 31 that can operate to send and receive signals to and from connected nodes via one or more antennas 33. Although not necessarily shown in Figure 7, the UE of course has all the usual functions of a conventional mobile device (such as a user interface 35), which may be provided as appropriate by one or any combination of hardware, software, and firmware. The controller 37 controls the operation of the UE according to software stored in memory 39. The software may be pre-installed in memory 39 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 41 and a communication control module 43. The communication control module 43 is responsible for processing (generating / transmitting / receiving) signaling messages and uplink / downlink data packets between the UE 3 and other nodes, including the v(R)AN node 5, application functions, and core network nodes. Such signaling includes well-formatted requests and responses related to the training, validation, registration, and deployment of AI and ML models.

[0106] Virtual RAN (v(R)AN) node Figure 8 is a block diagram showing the main virtual components of an exemplary v(R)AN node 5 (base station) that can be used in the system shown in Figure 6. As shown, the v(R)AN node 5 includes transceiver circuitry 51 that can operate to send and receive signals to and from UE3 connected via one or more antennas 53, and to send and receive signals to and from other network nodes (directly or indirectly) via a network interface 55. The network interface 55 typically includes a suitable base station-base station interface (e.g., X2 / Xn) and a suitable base station-core network interface (e.g., NG-U / NG-C). A controller 57 controls the operation of the v(R)AN node 5 according to software stored in memory 59. The software may be pre-installed in memory 59 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 61 and a communications control module 63. The communications control module 63 is responsible for processing (generating / transmitting / receiving) signaling between the v(R)AN node 5 and other nodes such as UE3 and core network nodes.

[0107] Core network node Figure 9 is a block diagram showing the main virtual components of a general-purpose core network node (or function) that can be used in the system shown in Figure 6. As shown, the core network node includes transceiver circuitry 71 that can operate to send and receive signals to and from other nodes (including UE3 and v(R)AN node 5) via a network interface 75. A controller 77 controls the operation of the core network node according to software stored in memory 79. The software may be pre-installed in memory 79 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 81 and at least a communications control module 83. The communications control module 83 is responsible for processing (generating / transmitting / receiving) signaling between the core network node and other nodes such as UE3, v(R)AN node 5, and other core network nodes. Such signaling includes appropriately formatted requests and responses related to intelligent data acquisition and management of the Open RAN intelligent controller.

[0108] Amendments and alternatives Detailed embodiments have been described above. As those skilled in the art will understand, many modifications and substitutions can be made to the above embodiments, while still enjoying the advantages of the invention embodied therein. Some of these substitutions and modifications are described as examples.

[0109] For the sake of clarity, the above description assumes that the UE, v(R)AN node, and core network node have several separate modules (such as communication control modules). While these modules may be provided in this manner in certain applications, such as when an existing system is modified to implement the above embodiments, in other applications, such as systems designed from the outset with the features of the present invention in mind, these modules may be integrated into the overall operating system or code and therefore may not be identifiable as separate entities. These modules may also be implemented in software, hardware, firmware, or a combination thereof.

[0110] Each controller may include, for example, (but not limited to) one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers and / or timers, and any other suitable form of processing circuitry.

[0111] In the above embodiments, several software modules have been described. As those skilled in the art will understand, the software modules may be provided in compiled or uncompiled form and may be supplied to the UE, v(R)AN nodes, and core network nodes as signals over a computer network or as signals on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates the updating of the UE, v(R)AN nodes, and core network nodes in order to update their functions.

[0112] The above embodiments are also applicable to "non-mobile" or generally fixed user devices.

[0113] Other various modifications are obvious to those skilled in the art and will not be described in further detail here. [Explanation of Symbols]

[0114] 1. Telecommunications Network 3 Mobile devices 5 v(R)AN nodes 31 Transceiver Circuit 33 Antennas 35 User Interface 37 Controllers 39 memory 41 Operating Systems 43 Communication control module 51 Transceiver Circuit 53 Antenna 55 Network Interfaces 57 Controllers 59 memory 61 Operating Systems 63 Communication control module 71 Transceiver Circuit 77 Controllers 79 memory 81 Operating Systems 83 Communication control module

Claims

1. A method for allocating hardware accelerator (HA) resources to a scheduled grant to process transport blocks (TB), This includes the step of allocating one of several Logical Processing Units (LPUs) to a scheduled grant, Each of the aforementioned LPUs represents its own HA, The aforementioned assignment step is, Each HA is expected to have a certain latency to complete the processing of the TB, or Each HA's predicted energy consumption to complete the processing of the TB The LPU is allocated based on at least one of the following: method.

2. The method according to claim 1, wherein the allocation step involves identifying a set of capacity-based LPUs comprising at least a subset of the plurality of LPUs based on the respective capacity of each LPU for storing the TB, and allocating the LPUs from the set of capacity-based LPUs.

3. The method according to claim 2, wherein each LPU included in the set of capacity-based LPUs has a capacity sufficient to store the TB.

4. The method according to claim 1, wherein the allocation step allocates the LPUs by identifying a set of latency-based LPUs, which includes at least a subset of the plurality of LPUs, based on the respective latency predicted for each HA, and allocating the LPUs from the set of latency-based LPUs.

5. The method according to claim 4, wherein the predicted latency for each HA is based on a combination of a predicted waiting time until the HA starts processing the TB and a predicted processing time for the HA to process the TB.

6. The method according to claim 5, wherein the predicted waiting time is based on the sum of the predicted processing time for each grant in the queue associated with the LPU representing the HA, and the predicted remaining processing time for each TB associated with each grant in the queue.

7. The method according to claim 5, wherein the predicted latency is based on status information collected in real time by a wireless access network intelligent controller for each of the multiple queues associated with the multiple LPUs.

8. The method according to claim 4, wherein the latency-based set of LPUs includes LPUs whose predicted latency is less than or equal to a predefined time constraint (D).

9. The method according to claim 1, wherein the allocation step involves allocating the LPUs by comparing the predicted energy consumption of each HA associated with at least a subset of the plurality of LPUs, and allocating the LPU corresponding to the HA with the lowest predicted energy consumption to the scheduled grant.

10. The method according to claim 1, wherein the allocation step allocates the LPU based on the priority associated with the TB.

11. The method according to claim 1, wherein the allocation step includes the step of allocating the queue corresponding to the allocated LPU to the scheduled grant.

12. A device for allocating hardware accelerator (HA) resources to scheduled grants for processing transport blocks (TB), Includes means for allocating one of multiple logical processing units (LPUs) to a scheduled grant, Each of the aforementioned LPUs represents its own HA, The aforementioned assignment step is, Each HA is expected to have a certain latency to complete the processing of the TB, or Each HA's predicted energy consumption to complete the processing of the TB The LPU is allocated based on at least one of the following: Device.

Images