Systems and methods for medium access control entity activation and usage in a cell-free network

Abstract

Systems and methods for cluster establishment, creation, activation, and use of medium access control (MAC) entities with respect to base stations serving user equipment (UEs) are discussed herein. It is possible that each / any base station within a cluster uses more than one MAC entity for a UE. These multiple MAC entities can be established for a UE according to / corresponding to a subset cluster of base stations from the cluster as used by radio bearers between the UE and the network. The possible MAC entities are established upon determining that the latency of the MAC entity satisfies the latency requirement of the subset cluster that the MAC entity can serve. The set of such possible MAC entities can be reduced to account for simultaneous MAC limitations at the UE. Dynamic activation / deactivation of one or more established MACs corresponding to active data communications are also discussed.

Description

Technical Field

[0001] This application relates in general to wireless communication systems, including media access control (MAC) entities in cellular architectures. Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. For example, wireless communication system standards and protocols may include, for instance, 3GPP Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLANs) (often referred to as Wi-Fi within the industry organization). ® ).

[0003] As envisioned by 3GPP, different wireless communication system standards and protocols can use various radio access networks (RANs) for communication between RAN base stations (sometimes also commonly referred to as RAN nodes, network nodes, or simply nodes) and wireless communication equipment called user equipment (UEs). 3GPP RANs can include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next Generation Radio Access Network (NG-RAN).

[0004] Each RAN can use one or more Radio Access Technologies (RATs) to perform communication between the base station and the UE. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements the NR RAT (this NR RAT is sometimes referred to herein as the 5G RAT, 5G NR RAT, or simply NR). In some deployments, E-UTRAN may also implement the NR RAT. In some deployments, NG-RAN may also implement the LTE RAT.

[0005] The base stations used by a RAN can correspond to that RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also called gNode B or gNB).

[0006] The RAN provides communication services to external entities through its connection with the core network (CN). For example, E-UTRAN can utilize the evolved packet core (EPC), while NG-RAN can utilize the 5G core network (5GC).

[0007] 5G NR frequency bands can be divided into two or more distinct frequency ranges. For example, Frequency Range 1 (FR1) may include bands operating at frequencies below 6 GHz, some of which are available in previous standards and can potentially be extended to cover new spectrum offerings from 410 MHz to 7125 MHz. Frequency Range 2 (FR2) may include bands from 24.25 GHz to 52.6 GHz. It should be noted that in some systems, FR2 may also include bands from 52.6 GHz to 71 GHz (or higher). Bands in the millimeter-wave (mmWave) range of FR2 may have smaller coverage areas but potentially higher available bandwidth than bands in FR1. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may change over time or in different regions. Attached Figure Description

[0008] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure reference numerals refer to the figure number in which the element was first introduced.

[0009] Figure 1 A diagram illustrating an example of a cluster in a cellular-free network architecture according to the implementation scheme discussed herein.

[0010] Figure 2 A diagram illustrating portions of the protocol stack corresponding to the first PDU session and the second PDU session according to the embodiment of this document is shown.

[0011] Figure 3 Diagrams illustrating various aspects of the radio protocol used in a non-cellular network mechanism according to the implementation scheme discussed herein are provided.

[0012] Figure 4 A diagram illustrating a portion of the protocol stack according to the implementation scheme discussed herein and its visual application within the corresponding cluster is shown.

[0013] Figure 5 An illustration is provided showing a portion of the protocol stack according to the implementation scheme discussed herein and its visualization application within a cluster serving the UE, corresponding to the case of MAC scheduling using joint decision-making.

[0014] Figure 6The illustration shows a portion of the protocol stack according to the implementation scheme discussed herein and its visual application within a cluster, corresponding to the case of MAC scheduling using centralized decision-making.

[0015] Figure 7 A diagram illustrating a portion of the protocol stack according to the implementation scheme discussed herein and its visual application within a cluster is shown, corresponding to the case of MAC scheduling formulated using hybrid mode decision-making.

[0016] Figure 8 A diagram illustrating a base station cluster according to the implementation scheme discussed herein and MAC entity options for that cluster is shown.

[0017] Figure 9 A diagram illustrating a portion of the protocol stack according to the implementation scheme discussed herein and its visual application within a cluster is shown.

[0018] Figure 10A , Figure 10B and Figure 10C A diagram illustrating a portion of the protocol stack according to the implementation scheme discussed herein and its visual application within a cluster is shown.

[0019] Figure 11 A flowchart illustrating the establishment and / or creation of a corresponding MAC entity according to the implementation scheme discussed herein is provided.

[0020] Figure 12A , Figure 12B and Figure 12C Examples of RLC-to-MAC edge activation / deactivation in the context of the protocol stack are illustrated according to the implementation scheme discussed herein.

[0021] Figure 13 A diagram illustrating a base station that demonstrates the operation of a MAC controller entity according to the implementation scheme discussed herein is provided.

[0022] Figure 14 The diagram illustrates the correspondence between the transmission of UE capability messages according to the implementation scheme discussed herein, and also illustrates the content of the UE capability message report that may be included in the UE capability message.

[0023] Figure 15 An example of the configuration of a radio bearer ID for indicating a radio bearer-specific TB, such as between a UE and a non-cellular network, according to the implementation scheme discussed herein is illustrated.

[0024] Figure 16AA flowchart illustrating a DL process for indicating radio bearers based on a previously established configuration information according to the implementation scheme discussed herein, the previously established configuration information being for the correspondence between radio bearer IDs and zero or more radio bearers existing between the UE and the non-cellular network.

[0025] Figure 16B A flowchart illustrating a UL process for indicating radio bearers based on a previously established configuration information according to the implementation discussed herein, the previously established configuration information being for the correspondence between radio bearer IDs and zero or more radio bearers existing between the UE and the non-cellular network.

[0026] Figure 17 Illustrations are provided of each of the non-DRB-specific data allocation options and DRB-specific data allocation options for the operation of a MAC entity of an example protocol stack according to the implementation scheme discussed herein.

[0027] Figure 18A A flowchart illustrating the exchange of RRC messages for configuring a CORESET corresponding to a MAC entity between a UE and a non-cellular network, according to the implementation scheme discussed herein, is provided.

[0028] Figure 18B A flowchart illustrating the maximum number of MAC CE indications that can be assigned by the MAC, such as PDCCH (corresponding to DCI / TB) between the UE and the non-cellular network, according to the implementation scheme discussed herein.

[0029] Figure 19A , Figure 19B , Figure 19C , Figure 19D and Figure 19E Together, we visually illustrate the process of using a greedy algorithm according to the implementation scheme discussed in this paper.

[0030] Figure 20 A method for CCF (Continuous Communication Function) of a wireless communication system for performing MAC entity establishment for a cluster of base stations serving a UE, according to an embodiment of this document, is illustrated.

[0031] Figure 21 An example is illustrated of a method for CCF (Continuous Communication Function) in a wireless communication system for performing MAC entity establishment for a cluster of base stations serving a UE, according to an embodiment of this document.

[0032] Figure 22 A method for a UE served by a base station of a wireless communication system according to an embodiment of this document is illustrated.

[0033] Figure 23An example is illustrated of an L3 scheduler for performing RLC-to-MAC edge-activated wireless communication systems in a cluster of base stations serving a UE, according to an embodiment of the present invention.

[0034] Figure 24 A method for a UE served by a base station trunking system according to an embodiment of this document is illustrated.

[0035] Figure 25 An example of a method for a cluster of base stations serving a UE according to an embodiment of this document is illustrated.

[0036] Figure 26 An example of a method for a cluster of base stations serving a UE according to an embodiment of this document is illustrated.

[0037] Figure 27 A method for a UE served by a base station trunking system according to an embodiment of this document is illustrated.

[0038] Figure 28 An example of a method for a cluster of base stations serving a UE according to an embodiment of this document is illustrated.

[0039] Figure 29 A method for a UE being served by a base station trunking system according to the implementation scheme described herein is illustrated.

[0040] Figure 30 A method for a UE served by a base station trunking system according to an embodiment of this document is illustrated.

[0041] Figure 31 An example of a method for a cluster of base stations serving a UE according to an embodiment of this document is illustrated.

[0042] Figure 32 An example architecture of a wireless communication system according to the implementation scheme disclosed herein is illustrated.

[0043] Figure 33 A system for performing signaling between a wireless device and a network device according to an embodiment disclosed herein is illustrated. Detailed Implementation

[0044] Various implementations are described with respect to the UE. However, references to the UE are provided for illustrative purposes only. The example implementations can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE as described herein is used to represent any suitable electronic component.

[0045] In some wireless systems, cellular network architectures provide an adaptive / dynamic and UE-centric distribution of functionality that can be associated with a “serving cell,” as understood in the context of prior cell-based network architectures (e.g., NR or LTE network architectures). Regarding this disclosure, it is generally understood that a UE’s “cluster” or “serving cluster” is a collection of physically and / or logically connected base stations on which functionality associated with serving the UE (e.g., traditional serving cell functionality used in cell-based network architectures) can be distributed. Therefore, in some contexts, the concept of a cluster can “replace” the concept of a UE’s serving cell, as understood for prior cell-based networks.

[0046] A cluster can have a one-to-one mapping to a UE. Therefore, the individual (logical) cluster for each of two UEs can be understood / identified (even when each of the two corresponding clusters consists of the same physical set of base stations). Furthermore, it should be noted that a single base station can belong to multiple clusters simultaneously, each serving different UEs.

[0047] Figure 1 Figure 100 illustrates an example of a cluster in a cellular network architecture according to the embodiments discussed herein. A first cluster 102 of base stations serves a first UE 104, and a second cluster 106 of base stations serves a second UE 108. As illustrated, the first cluster 102 includes a first base station 110 and a second base station 112, while the second cluster 106 includes a second base station 112 and a third base station 114.

[0048] It is not always necessary for base stations within the same cluster to jointly transmit / receive to / from the UE being served. Furthermore, control plane and / or user plane functionality can be dynamically distributed among base stations within the cluster.

[0049] A cluster control function (CCF) can be defined as a set of one or more logical functions used to establish and control clusters in a wireless communication system. A CCF can be a distributed entity within the wireless communication system. For example, a CCF can be distributed across one or more base stations in the core network, the RAN Intelligent Controller (RIC), and / or the RAN.

[0050] The CCF can dynamically develop, update, control, and schedule UE-centric connection sets for clusters in certain geographic areas based on factors such as: services, latency, reliability, coverage, interference, sensing, mobility, cell load, radio resource management (RRM) aspects, radio link quality, backhaul ideality, location, quality of service (QoS) requirements, and / or measurement reports.

[0051] In some wireless communication systems, clustering in a cellular network includes concepts such as UE-centric clusters, CCFs, connected base stations (cBSs) (e.g., base stations that are part of a cluster serving the UE), and adjacent unconnected base stations (uBSs) (e.g., base stations adjacent to the UE that are not currently part of a cluster serving the UE). In some such systems, the CCF includes, in particular, the functionality, protocols, message exchange capabilities, etc., available for cluster establishment and / or update tasks. UEs and base stations may include corresponding functionality, protocols, message exchange capabilities, etc., supporting the use of clusters as described herein.

[0052] In wireless communication systems implementing cellular networks, it is possible to establish and maintain message delivery protocols using cellular radio resource control (RRC) connections. This in particular can mean that the RRC state of a UE is typically understood relative to the network (rather than relative to a specific serving cell).

[0053] Furthermore, such wireless communication systems for cellular networks can use one or more cluster establishment options corresponding to the UE's initial access and / or cluster update mechanism (e.g., which controls the composition of base stations in the cluster after the UE's initial access). These can include, for example, "greedy," downlink-based (DL), uplink-based (UL), and / or real-time methods (and any corresponding message exchange).

[0054] Radio bearer delay requirements

[0055] Suppose C represents a cluster for a given UE (which consists of one or more base stations serving the UE). The UE and the network have a single RRC entity. The cluster includes base stations associated with the UE (where such associations can be defined, for example, based on signal quality and / or mobility prediction, etc.).

[0056] Furthermore, the UE can establish one or more Protocol Data Unit (PDU) sessions, where each PDU session includes one or more radio bearers. In some such cases, there is a one-to-one correspondence between a Serving Data Adaptation Protocol (SDAP) layer entity and a PDU session. The SDAP entity packets service quality (QoS) streams with similar requirements and then maps them to radio bearers. In various cases, it can be understood that the QoS requirements (specifically, latency requirements) within each particular radio bearer are static for at least a period of time.

[0057] Figure 2A diagram 200 illustrates portions of the protocol stack corresponding to the first PDU session 202 and the second PDU session 204 according to an embodiment of this document. As illustrated, the first SDAP entity 206 corresponds to the first PDU session 202, while the second SDAP entity 208 corresponds to the second PDU session 204.

[0058] Assume that D is the set of radio bearers used by the UE. These radio bearers have a one-to-one correspondence with the PDCP entities that exist under the SDAP entity in the protocol stack scheme.

[0059] For example, Figure 2 Figure 200 illustrates the case corresponding to the set D = {DRB1, DRB2, DRB3} of data radio bearers (DRBs). Figure 200 illustrates the first PDCP entity 210 corresponding to the first radio bearer 212 (DRB1) and the second PDCP entity 214 corresponding to the second radio bearer 216 (DRB2), each serving the first SDAP entity 206. Furthermore, the third PDCP entity 218 corresponding to the third radio bearer 220 (DRB3) serves the second SDAP entity 208.

[0060] It should be noted that the physical location of SDAP entities and / or PDCP entities may not be strictly specified. For example, the options for the physical location of SDAP entities and / or PDCP entities may be the same as those available for user plane functions (UPF) in, for example, 5G wireless communication systems.

[0061] It should be noted that, regarding Figure 200, it should be understood that the UE is served by a single cluster C and according to a single RRC entity.

[0062] Radio protocols in cellular networks

[0063] In some wireless communication systems, "trunking partitioning" refers to the dynamic division of a trunk serving a UE into logical sub-trunks for a specific radio bearer. This division may determine the protocol stack architecture applied to that trunk. For example, each sub-trunk may correspond to a specific Logical Radio Controller (RLC) entity. Then, base stations within the same sub-trunk may, for example, carry a copy of the same logical RLC entity for a given radio bearer.

[0064] Figure 3Figure 300 illustrates various aspects of the radio protocol used in a cellular-free network mechanism according to the embodiments discussed herein. UE 302 is served by cluster 304. Within cluster 304, there exists a first sub-cluster 306 corresponding to a first RLC entity 310 used between UE 302 and cluster 304, and a second sub-cluster 308 corresponding to a second RLC entity 312 used between UE 302 and cluster 304. The first RLC entity 310 and the second RLC entity 312 are RLC entities used by a PDCP entity 318, which corresponds to the radio bearer between UE 302 and cluster 304 and uses the illustrated cluster partitioning.

[0065] As illustrated, the first RLC entity 310 is synchronized 314 across the base stations (BS1, BS2, and BS3) of the first sub-cluster 306. This means, for example, that each of these base stations has a copy of the first RLC entity 310 and operates according to that copy, as shown. Furthermore, the second RLC entity 312 is synchronized 316 across the base stations (BS4, BS5, and BS6) of the second sub-cluster 308. This means, for example, that each of these base stations has a copy of the second RLC entity 312 and operates according to that copy, as shown. It should be noted that, as illustrated, the arrangement of specific base stations of a cluster as either the first sub-cluster 306 or the second sub-cluster 308 can be transparent to the UE (the UE knows about the first RLC entity 310 and the second RLC entity 312 (according to the sub-cluster) / operates according to the first RLC entity and the second RLC entity, regardless of the specific base stations under those RLC entities / sub-clusters).

[0066] In the illustrated scenario, the first packet 320 of the radio bearer corresponding to PDCP entity 318 is processed at the first RLC entity 310. This ultimately means that the first packet 320 is transmitted between UE 302 and cluster 304 via one or more base stations of the first sub-cluster 306. Furthermore, the second packet 322 of the (same) radio bearer corresponding to PDCP entity 318 is processed at the second RLC entity 312. This ultimately means that the second packet 322 is transmitted between UE 302 and cluster 304 via one or more base stations of the second sub-cluster 308.

[0067] The idea is that cluster partitioning can be updated over time. The establishment and / or updating of cluster partitioning can take into account QoS requirements and service characteristics associated with radio bearers. For example, latency constraints and / or service periodicity can be considered. These mechanisms allow the network (e.g., CCF) to optimally configure multi-connectivity of UEs to enabled sub-clusters in scenarios such as non-ideal backhaul (where different partitions of the same cluster may have significantly different QoS / service management characteristics).

[0068] In some wireless communication systems, radio protocols in cellular networks utilize concepts such as trunking / sub-trunking and RLC synchronization. Functionality for controlling dynamic updates of trunking partitions and corresponding protocols for the update process can be used. PDCP data routing options and corresponding configurations can be used. Finally, cellular radio bearer configuration and / or message exchange procedures for radio bearer establishment can be used.

[0069] Creation of RLC entities based on time delay analysis

[0070] For each radio bearer, the network (e.g., CCF) divides the cluster into one or more sub-clusters. For radio bearer d D, will As a partition where cluster C becomes sub-cluster S, where = ,constraint: Each ∈ There is a one-to-one correspondence with the RLC entity, which belongs to radio bearer d and is located at base station b ∈ It contains the same copy.

[0071] Base stations within the same sub-cluster can synchronously share the RLC buffer state, which adds some latency to transmission. Related assumptions for this synchronization may include: the latency of synchronization between base stations in the sub-cluster is tolerable for the service of radio bearer d; and / or the synchronization is physically feasible to deploy over the network (e.g., the capacity of the associated Xn connection is sufficient).

[0072] Figure 4 A diagram 400 illustrates a portion of the protocol stack 402 according to the implementation scheme discussed herein and its visual application within the corresponding cluster 404. As illustrated, cluster 404 includes a first base station 406 (BS1), a second base station 408 (BS2), and a third base station 410 (BS3), and serves UE 412.

[0073] The corresponding protocol stack 402 includes a first PDCP entity 414 for serving a first radio bearer and a second PDCP entity 416 for serving a second radio bearer (where each of the first PDCP entity 414 and the second PDCP entity 416 operates under the same SDAP entity 418 of the protocol stack 402).

[0074] Figure 400 illustrates the division of the cluster 404 for a first radio bearer served by a first PDCP entity 414 using a first sub-cluster 420, which includes each of the first base station 406, the second base station 408, and the third base station 410 (all base stations of cluster 404).

[0075] The first sub-cluster 420 corresponds to the first RLC entity 422 (RLC 1-1) serving the first PDCP entity 414. Therefore, each of the first base station 406, the second base station 408, and the third base station 410 is synchronized with the first RLC entity 422 with respect to the first radio bearer (this is indicated next to each of the first base station 406, the second base station 408, and the third base station 410 in Figure 400).

[0076] In Figure 400, the first radio bearer served by the first PDCP entity 414 may be, for example, a best-effort radio bearer.

[0077] Figure 400 also illustrates a second radio bearer served by the second PDCP entity 416, wherein the division of the cluster 404 uses a second sub-cluster 424 and a third sub-cluster 426, the second sub-cluster using a first base station 406 and a second base station 408, and the third sub-cluster using a third base station 410.

[0078] The second sub-cluster 424 corresponds to the second RLC entity 428 (RLC 2-1) serving the second PDCP entity 416. Therefore, each of the first base station 406 and the second base station 408 is synchronized with the second RLC entity 428 with respect to the second radio bearer (this is indicated next to each of the first base station 406 and the second base station 408 in Figure 400).

[0079] Furthermore, the third sub-cluster 426 corresponds to the third RLC entity 430 (RLC 2-2) serving the second PDCP entity 416. Therefore, the third sub-cluster 426 uses the third RLC entity 430 with respect to the second radio bearer (which is indicated next to the third base station 410 in Figure 400).

[0080] In Figure 400, the second radio bearer served by the second PDCP entity 416 may be, for example, a radio bearer with guaranteed low latency.

[0081] Cellular-free process timescale

[0082] The process of cellular-free networks can be operated on various time scales and / or managed by various entities.

[0083] The first set of functionalities for non-cellular networks includes non-real-time functionalities. Non-real-time functionalities can occur on the order of seconds and can be managed by the CCF.

[0084] Non-real-time functionality can take one or more of the following as inputs, for example: inter-base station exchange (Xn interface) latency, radio bearer configuration information, and / or UE capabilities.

[0085] Non-real-time functionality can make one or more decisions, such as (for example): determining the assignment of base station identifiers to clusters; establishing sub-clusters and corresponding RLC entities for each radio bearer of the cluster; and establishing media access control (MAC) entities within the protocol stack, including assigning base station identifiers to MAC entities and / or assigning MAC entities to RLC entities.

[0086] The second set of functionalities for non-cellular networks includes near real-time functionality. Near real-time functionality can occur on the order of tens to hundreds of milliseconds and can be managed by a Layer 3 (L3) scheduler. The L3 scheduler can be an L3 process implemented within the network. It can dynamically (e.g., at a given transmission time interval (TTI) and / or a given set of multiple TTIs) shape, update, and / or schedule the logical state of UE-specific sub-clusters and base stations. This can occur on request and / or based on applicable QoS requirements and / or measurement reports, etc. In some implementations, the L3 scheduler is implemented as part of the CCF (but this is not mandatory—the L3 scheduler can optionally reside separately from the CCF in the wireless communication system).

[0087] Near real-time functionality can take one or more of the following as input (e.g.): propagation delay between the UE and one or more base stations, base station status information (load information, signal quality information, etc.) and / or service statistics.

[0088] Near real-time functionality can make one or more decisions, such as (for example): determination of physical (PHY) layer limitations (such as propagation delay and / or synchronization impairments); determination of the MAC layer, including transport block (TB) numbering configuration and / or scheduling mode protocol; determination of the MAC scheduler, including the selection of responsible base stations and the establishment of resource allocation chains; determination of RLC-to-MAC link activation; and / or determination of PDCP-to-RLC links, including for traffic routing and / or replication.

[0089] The third set of functionalities for non-cellular networks includes real-time functionalities (e.g., those designed to occur as quickly as possible). Real-time functionalities can occur in milliseconds (ms) or even less and can be managed by the MAC scheduler.

[0090] Real-time functionality can take one or more of the following as input, for example: channel state information (CSI), buffer state, and / or scheduling metrics.

[0091] Real-time functionality can make one or more decisions, such as (for example): determination of the MAC scheduler, including coordinating message exchange, radio resource allocation and / or LA; determination of the MAC layer, including layer 3 (L2) data processing; and determination of the physical layer (PHY layer), including multi-user multiple-input multiple-output (MU-MIMO) precoding and / or layer 2 (L1) data transmission and / or reception.

[0092] Implementation plan for cellular-free MAC scheduling

[0093] This discussion now concerns MAC scheduling used within a cellular network exhibiting the characteristics described herein. MAC scheduling can be performed by a MAC entity. A MAC entity can be understood as serving one or more RLC entities (and therefore one or more sub-clusters). A MAC entity can operate with respect to one, some, and / or all of the base stations of the RLC / sub-clusters it serves (as the case may be). As described herein, a MAC entity can be responsible for performing MAC scheduling across its constituent base stations, which correspond to data packets received from the RLC entities served by the MAC entity.

[0094] The first option for MAC scheduling can be referred to as "joint decision-making." In the case of joint decision-making, the MAC resource allocation decision is jointly / co-opted by all base stations in the sub-cluster.

[0095] Figure 5 A diagram 500 illustrates a portion of the protocol stack 502 according to the implementation discussed herein and its visual application within cluster 504 serving UE 506, corresponding to the case of MAC scheduling using joint decision-making. As illustrated, cluster 504 uses a first base station 514 (BS1), a second base station 516 (BS2), and a third base station 518 (BS3) to serve UE 506.

[0096] Figure 500 illustrates a PDCP entity 508 corresponding to a radio bearer, which is served by an RLC entity 510 in the manner discussed herein, the RLC entity representing a sub-cluster comprising each of a first base station 514 (BS1), a second base station 516 (BS2), and a third base station 518 (BS3).

[0097] Figure 500 also illustrates that RLC entity 510 itself is served by MAC entity 512, which can perform MAC scheduling using first base station 514, second base station 516, and third base station 518. It should be noted that the boundaries of MAC entity 512, as illustrated in cluster 504, can be understood directly from MAC entity 512 rather than RLC entity 510 (although these boundaries are mutually extended in this case).

[0098] An example of joint decision-making is now described. An initial decision is made by one of the base stations (e.g., first base station 514) and (e.g., via the Xn interface) provided to other base stations (e.g., second base station 516 and third base station 518). In some cases, there may be several rounds of similar message exchanges. At least one round of message exchange is used. Therefore, it should be understood that in the case of joint decision-making, a resource allocation decision can be made for a TTI of at least Xn delay in the future, corresponding to at least one round of message exchange. Thus, the use of joint decision-making can be understood as adding the Xn delay to the scheduling delay for MAC entity 512.

[0099] Joint decision-making can be understood accordingly as achieving high spectral efficiency across the first base station 514, the second base station 516, and the third base station 518 at the cost of additional MAC scheduling latency. Therefore, it may be a good option for latency-tolerant services.

[0100] The second option for MAC scheduling can be referred to as "centralized decision-making." In the centralized decision-making scenario, resource allocation decisions are made in a decentralized manner by base stations across different sub-clusters.

[0101] Figure 6 A diagram 600 illustrates a portion of the protocol stack 602 according to the implementation scheme discussed herein and its visual application within cluster 604, corresponding to a case of MAC scheduling using centralized decision-making. As illustrated, cluster 604 uses a first base station 614 (BS1), a second base station 620 (BS2), and a third base station 626 (BS3) to serve UE 606.

[0102] Figure 600 illustrates a PDCP entity 608 corresponding to a radio bearer, which is served by a first RLC entity 610, a second RLC entity 616, and a third RLC entity 622 in the manner discussed herein. The first RLC entity represents a first sub-cluster including a first base station 614 (BS1), the second RLC entity represents a second sub-cluster including a second base station 620 (BS2), and the third RLC entity represents a third sub-cluster including a third base station 626 (BS3).

[0103] Figure 600 also illustrates that the first RLC entity 610 is served by a first MAC entity 612, which can perform MAC scheduling using a first base station 614; the second RLC entity 616 is served by a second MAC entity 618, which can perform MAC scheduling using a second base station 620; and the third RLC entity 622 is served by a third MAC entity 624, which can perform MAC scheduling using a third base station 626. It should be noted that the boundaries of each of the first MAC entities 612, the second MAC entity 618, and the third MAC entity 624, as illustrated in cluster 604, should be understood directly from the boundaries of the respective MAC entities rather than any corresponding RLC entities (although in this case, the MAC entity boundaries extend together with the corresponding RLC entity boundaries).

[0104] As in the example now describing centralized decision-making, first base station 614, second base station 620, and third base station 626 agree on a resource-sharing pattern (in the time domain, frequency domain, and / or spatial domain) for a period of time. For example, they may agree to schedule UE 606 in TTI T for each base station K selected from the first base station 614, second base station 620, and third base station 626, such that Tmod 3 = K (where K is a different integer value from 1 to 3 corresponding to the three base stations in question).

[0105] In another example, where UE 606 is a multi-antenna UE, the first base station 614, the second base station 620, and the third base station 626 may agree on the splitting of frequency bands and / or spatial domains among the first base station 614, the second base station 620, and / or the third base station 626.

[0106] Then, each of the first base station 614, the second base station 620, and the third base station 626 (e.g., in real time) decides to schedule UE 606 in a manner consistent with the resource-sharing model. These decisions can be made autonomously at each base station (without needing to check with any other base station and / or obtain consensus from any other base station).

[0107] Therefore, decentralized decision-making can be understood as not incurring the additional latency penalty described in this paper for joint decision-making, but may ultimately result in lower spectral efficiency compared to joint decision-making.

[0108] The third option for MAC scheduling can be referred to as "semi-decentralized decision making" or "hybrid-mode decision making." In the case of hybrid-mode decision making, resource allocation decisions are made in a hybrid / semi-decentralized manner, which uses joint decision making among base stations within a sub-cluster and also uses decentralized decision making across different sub-clusters.

[0109] Figure 7 A diagram 700 illustrates a portion of the protocol stack 702 according to the implementation discussed herein and its visual application within cluster 704, corresponding to a MAC scheduling scenario using hybrid mode decision-making. As illustrated, cluster 704 uses a first base station 714 (BS1), a second base station 720 (BS2), and a third base station 722 (BS3) to serve UE 706.

[0110] Figure 700 illustrates a PDCP entity 708 corresponding to a radio bearer, which is served by a first RLC entity 710 and a second RLC entity 716 in the manner discussed herein. The first RLC entity represents a first sub-cluster including a first base station 714 (BS1) and a second base station 720 (BS2), and the second RLC entity represents a second sub-cluster including a third base station 722 (BS3).

[0111] Figure 700 also illustrates that the first RLC entity 710 is served by the first MAC entity 712, which can perform MAC scheduling using the first base station 714 and the second base station 720, and the second RLC entity 716 is served by the second MAC entity 718, which can perform MAC scheduling using the third base station 722. It should be noted that the boundaries of each of the first MAC entities 712 and 718, as illustrated in cluster 704, should be understood directly from the boundaries of the respective MAC entities (and not any corresponding RLC entities). Although in this case, the first MAC entity 712 covers all base stations of the sub-cluster of the first RLC entity 710, this should be understood only by way of example (it is possible for a MAC entity to cover fewer base stations than the RLC entities / sub-clusters it serves).

[0112] In hybrid decision-making, joint decision-making resource allocation occurs between base stations belonging to the same sub-cluster (independent of other base stations in different sub-clusters). For example, the first base station 714 and the second base station 720 within the sub-cluster corresponding to the first RLC entity 710 may use message exchange (e.g., similar to...) when they are simultaneously used for joint MAC scheduling (e.g., this may be the case according to the first MAC entity 712). Figure 5 The joint decision-making mechanism coordinates their transmission. This message exchange / coordination can occur without checking and / or reaching a consensus with any base station outside the cluster (such as the third base station 722).

[0113] Furthermore, base stations across different sub-clusters can agree on a resource-sharing mode (in the time, frequency, and / or spatial domains) for a period of time to be used between those base stations, where resources are allocated based on MAC entities. For example, base stations of the first MAC entity 712 (first base station 714 and second base station 720) can agree with base station of the second MAC entity 718 (third base station 722) on a resource-sharing mode (in the time, frequency, and / or spatial domains) for a period of time to allocate resources between the first MAC entity 712 and the second MAC entity 718 (e.g., similar to...). Figure 6 (A decentralized decision-making mechanism).

[0114] It is understandable that using joint decision-making at the sub-cluster level to determine resource allocation tasks can involve more tolerable / lower Xn latency / MAC scheduling latency penalties between base stations in the sub-cluster compared to an alternative scenario where joint decision-making is performed across all base stations in the entire cluster (e.g., regarding...). Figure 5 (As described). Furthermore, due to the use of MAC-level distributed resource allocation, it is similar to... Figure 6 Compared to the scenario described where decentralized decision-making occurs at each individual base station across the entire cluster, this approach can at least slightly improve cross-cluster spectral efficiency. Therefore, the hybrid decision-making mechanism can be understood as providing a trade-off between competing spectral efficiency and latency considerations in the discussion.

[0115] It should be noted that, in such cases, Figure 7 As illustrated, in the case of a single radio bearer in use at the cluster, it is sufficient to establish a one-to-one correspondence between MAC entities and RLC entities and the entire set of base stations associated with the corresponding RLC entities in order to achieve hybrid mode decision-making. However, in cases corresponding to greater degrees of freedom within the cluster (e.g., where there are multiple radio bearers using different RLC entities arranged according to different sub-cluster partitions, where MAC entities may or may not be co-extended with the RLC entities they serve), support for using hybrid mode decision-making may require further consideration.

[0116] This document describes implementation schemes that support joint, distributed, and / or hybrid decision-making within a cluster, taking into account degrees of freedom in the cluster regarding, for example, the number of radio bearers, the sub-clustering for each radio bearer, and whether MAC entities serving an RLC entity co-extend with that RLC entity. Procedures for creating multiple MAC entities are discussed, which can be used to support joint, distributed, and / or hybrid decision-making options for MAC scheduling of one or more DRBs for a UE. Various aspects of MAC entity-to-RLC entity connectivity are discussed. Examples of simultaneous operation of several MAC entities are discussed, including the concept of grant allocation. Mechanisms for near real-time activation and / or deactivation of MAC entity-to-RLC entity connections, taking into account UE capabilities and avoiding DRB service congestion, are discussed. Finally, various aspects of coordination between different MAC entities are discussed.

[0117] Implementation plan for establishing MAC entities

[0118] Figure 8 Figure 800 illustrates a base station cluster 802 according to the implementation scheme discussed herein and a MAC entity option 812 for that cluster. Cluster 802 uses a first base station 804 (BS1), a second base station 806 (BS2), and a third base station 808 (BS3) to serve UE 810.

[0119] Regarding cluster 802, the following MAC entity options 812 exist. A first MAC entity option can be used for a first MAC entity 814 using a first base station 804. A second MAC entity option can be used for a second MAC entity 816 using a second base station 806, and a third MAC entity option can be used for a third MAC entity 818 using a third base station 808. A fourth MAC entity option can be used for a fourth MAC entity 820 using both the first and second base stations 804 and 806. A fifth MAC entity option can be used for a fifth MAC entity 822 using both the first and third base stations 804 and 808. A sixth MAC entity option can be used for a sixth MAC entity 824 using both the second and third base stations 806 and 808. A seventh MAC entity option can be used for a seventh MAC entity 826 using the first, second, and third base stations 804 and 808.

[0120] Regarding the design of MAC entities, each MAC entity created for a UE is associated with a unique set of base stations serving that UE. If the Xn latency of inter-base station communication within the MAC entity and the latency provided by MAC scheduling coordination are acceptable for the RLC entity, then the MAC entity can connect to (and potentially serve) the RLC entity. This connection between the RLC entity and the MAC entity can be activated and / or deactivated on a near real-time timescale (causing the MAC entity to begin actively serving / stop actively serving the RLC entity).

[0121] It is important to note that the timescale for making decisions regarding MAC entity creation is typically longer than the timescale for activating / deactivating RLC entity-to-MAC entity connections. For example, MAC entity creation is usually a non-real-time process, where the set of MAC entities created can be updated, for example, on the order of seconds. However, the activation of MAC entity-to-RLC entity connections can be a near real-time process (a much faster process), which can occur on the order of tens or hundreds of milliseconds.

[0122] A MAC entity M can be understood based on the set of base stations to which it belongs (i.e., M). C). Each base station b M has the same copy of the MAC entity. If the latency of M's data processing and scheduling is relative to the RLC entity... If this is acceptable, then the MAC entity M is assumed / considered as an RLC entity connected to the radio bearer d. Once established, the connection can be activated and / or deactivated.

[0123] In some implementations, the relation M concerning the corresponding subsets of base stations It should be satisfied.

[0124] A single RLC entity can be connected to one or more MAC entities. A single MAC entity can be connected to one or more RLC entities. A MAC entity not connected to any RLC entity can be discarded / not used / disabled. MAC entities of the same UE do not assume synchronization with each other (instead, they are each understood to act and make decisions independently of other MAC entities).

[0125] Figure 9 A diagram 900 illustrates a portion of the protocol stack 902 according to the implementation scheme discussed herein and its visual application within cluster 904. As illustrated, cluster 904 uses a first base station 916 (BS1), a second base station 922 (BS2), and a third base station 928 (BS3) to serve UE 906.

[0126] Figure 900 illustrates a first PDCP entity 908 corresponding to a first radio bearer between the network and the UE 906, and a second PDCP entity 910 corresponding to a second radio bearer between the network and the UE 906.

[0127] Figure 900 illustrates the division of a first radio bearer served by a first PDCP entity 908, where a first sub-cluster 930 is used, which includes each of a first base station 916, a second base station 922, and a third base station 928 (all base stations of cluster 904).

[0128] The first sub-cluster 930 corresponds to the first RLC entity 912 (RLC 1-1) serving the first PDCP entity 908. Therefore, each of the first base station 916, the second base station 922, and the third base station 928 is synchronized with the first RLC entity 912 with respect to the first radio bearer (this is indicated next to each of the first base station 916, the second base station 922, and the third base station 928 in Figure 900).

[0129] Figure 900 also illustrates the division of the second radio bearer served by the second PDCP entity 910, where the cluster 904 is divided using a second sub-cluster 932 and a third sub-cluster 934, the second sub-cluster using a first base station 916 and a second base station 922, and the third sub-cluster using a third base station 928.

[0130] The second sub-cluster 932 corresponds to the second RLC entity 918 (RLC 2-1) serving the second PDCP entity 910. Therefore, each of the first base station 916 and the second base station 922 is synchronized with the second RLC entity 918 with respect to the second radio bearer (this is indicated next to each of the first base station 916 and the second base station 922 in Figure 900).

[0131] Furthermore, the third sub-cluster 934 corresponds to the third RLC entity 924 (RLC 2-2) serving the second PDCP entity 910. Therefore, the third base station 1010 uses the third RLC entity 924 with respect to the second radio bearer (this is indicated next to the third base station 928 in Figure 900).

[0132] As illustrated, the first MAC entity 914 (MAC1) includes a first base station 916, a second base station 922, and a third base station 928; the second MAC entity 920 (MAC2) includes the first base station 916 and the second base station 922; and the third MAC entity 926 (MAC3) includes the third base station 928. The first MAC entity 914, the second MAC entity 920, and the third MAC entity 926 are examples of valid MAC entities that can be created / used with respect to the arrangement of the protocol stack 902 and cluster 904 as described. This is because each of these MAC entities satisfies at least one... Requirements M (For example, a MAC entity is a subset of base stations that come from at least one sub-cluster used by at least one radio bearer / PDCP entity.)

[0133] It should be noted that other valid MAC entities (not illustrated) are also possible / valid with respect to the illustrated configuration (satisfying M) (at least one instance). However, it is possible that these other MAC entities may not have been established / created for the illustrated scenario (because, for example, it is determined that the illustrated MAC entity represents a complete and valid configuration for use).

[0134] Implementation plan for MAC entity creation and setup

[0135] Figure 10A , Figure 10B and Figure 10C A diagram 1000 illustrates a portion of the protocol stack 1002 according to the implementation scheme discussed herein and its visual application within cluster 1004. As illustrated, cluster 1004 uses a first base station 1006 (BS1), a second base station 1008 (BS2), and a third base station 1010 (BS3) to serve UE 1012.

[0136] from Figure 10A Beginning: Figure 1000 illustrates a first PDCP entity 1014 corresponding to a first radio bearer (DRB1) between the network and UE 1012, a second PDCP entity 1016 corresponding to a second radio bearer (DRB2) between the network and UE 1012, and a third PDCP entity 1018 corresponding to a third radio bearer (DRB3) between the network and UE 1012.

[0137] Figure 1000 illustrates a first radio bearer served by a first PDCP entity 1014, where the division of trunk 1004 uses a first sub-truncate 1032, which includes each of the first base station 1006, the second base station 1008, and the third base station 1010 (all base stations of trunk 1004).

[0138] The first sub-cluster 1032 corresponds to the first RLC entity 1020 (RLC 1-1) serving the first PDCP entity 1014. Therefore, each of the first base station 1006, the second base station 1008, and the third base station 114 is synchronized with the first RLC entity 1020 with respect to the first radio bearer (this is indicated next to each of the first base station 1006, the second base station 1008, and the third base station 1010 in Figure 1000).

[0139] Figure 1000 also illustrates the division of the second radio bearer served by the second PDCP entity 1016, where the cluster 1004 is divided using a second sub-cluster 1034 and a third sub-cluster 1036, the second sub-cluster using a first base station 1006 and a second base station 1008, and the third sub-cluster using a third base station 1010.

[0140] The second sub-cluster 1034 corresponds to the second RLC entity 1022 (RLC 2-1) serving the second PDCP entity 1016. Therefore, each of the first base station 1006 and the second base station 1008 is synchronized with the second RLC entity 1022 with respect to the second radio bearer (this is indicated next to each of the first base station 1006 and the second base station 1008 in Figure 1000).

[0141] Furthermore, the third sub-cluster 1036 corresponds to the third RLC entity 1024 (RLC2-2) serving the second PDCP entity 1016. Therefore, the third sub-cluster 1036 uses the third RLC entity 1024 with respect to the second radio bearer (which is indicated next to the third base station 1010 in Figure 1000).

[0142] Figure 1000 also illustrates the division of cluster 1004 for a third radio bearer served by a third PDCP entity 1018, using a fourth sub-cluster 1038, a fifth sub-cluster 1040, and a sixth sub-cluster 1042. The fourth sub-cluster uses a first base station 1006, the fifth sub-cluster uses a second base station 1008, and the sixth sub-cluster uses a third base station 1010.

[0143] The fourth sub-cluster 1038 corresponds to the fourth RLC entity 1026 (RLC 3-1) serving the third PDCP entity 1018. Therefore, the first base station 1006 uses the fourth RLC entity 1026 with respect to the third radio bearer (this is indicated next to the first base station in Figure 1000).

[0144] Furthermore, the fifth sub-cluster 1040 corresponds to the fifth RLC entity 1028 (RLC3-2) serving the third PDCP entity 1018. Therefore, the second base station 1008 uses the fifth RLC entity 1028 with respect to the third radio bearer (this is indicated next to the second base station 1008 in Figure 1000).

[0145] Furthermore, the sixth sub-cluster 1042 corresponds to the sixth RLC entity 1030 (RLC 3-3) serving the third PDCP entity 1018. Therefore, the third base station 1010 uses the sixth RLC entity 1030 with respect to the third radio bearer (this is indicated next to the third base station 1010 in Figure 1000).

[0146] We will now discuss the process for establishing the MAC entity that will be created within the described structure. Initially, M satisfies A list of all possible MAC entities M is determined. Regarding the protocol stack 1002 as described so far, there exists at least one sub-cluster using each of the first base station 1006, the second base station 1008, and the third base station 1010 (e.g., the first sub-cluster 1032 corresponding to the first RLC entity 1020), so it is possible to use the first MAC entity 1044 using each of the first base station 1006, the second base station 1008, and the third base station 1010.

[0147] Furthermore, there exists at least one sub-cluster that uses each of the second base station 1008 and the third base station 1010 (e.g., the first sub-cluster 1032 corresponding to the first RLC entity 1020), so it is possible to use the second MAC entity 1046 that uses each of the second base station 1008 and the third base station 1010.

[0148] Furthermore, there exists at least one sub-cluster using each of the first base station 1006 and the third base station 1010 (e.g., the first sub-cluster 1032 corresponding to the first RLC entity 1020), so it is possible to use the third MAC entity 1048 using each of the first base station 1006 and the third base station 1010.

[0149] Furthermore, since there exists at least one sub-cluster using each of the first base station 1006 and the second base station 1008 (e.g., either / each of the first sub-cluster 1032 corresponding to the first RLC entity 1020 and the second sub-cluster 1034 corresponding to the second RLC entity 1022), it is possible to use the fourth MAC entity 1050 using each of the first base station 1006 and the second base station 1008.

[0150] Furthermore, since there exists at least one sub-cluster using the first base station 1006 (e.g., any one / each of the first sub-cluster 1032 corresponding to the first RLC entity 1020, the second sub-cluster 1034 corresponding to the second RLC entity 1022, and the fourth sub-cluster 1038 corresponding to the fourth RLC entity 1026), it is possible to use the fifth MAC entity 1052 of the first base station 1006.

[0151] Furthermore, since there exists at least one sub-cluster using the second base station 1008 (e.g., any one / each of the first sub-cluster 1032 corresponding to the first RLC entity 1020, the second sub-cluster 1034 corresponding to the second RLC entity 1022, and the fifth sub-cluster 1040 corresponding to the fifth RLC entity 1028), it is possible to use the sixth MAC entity 1054 of the second base station 1008.

[0152] Finally, since there exists at least one sub-cluster using the third base station 1010 (e.g., any one / each of the first sub-cluster 1032 corresponding to the first RLC entity 1020, the third sub-cluster 1036 corresponding to the third RLC entity 1024, and the sixth sub-cluster 1042 corresponding to the sixth RLC entity 1030), it is possible to use the seventh MAC entity 1056 using the third base station 1010.

[0153] The network can also check whether each MAC entity in the possible MAC entity M can be determined based on the RLC / subcluster layout for that MAC entity M when considering the RLC / subcluster layout of the active DRB. Operations can be performed with acceptable data processing and scheduling latency. Figure 10A In the illustrated case, the network determines that this is the case for each illustrated MAC entity.

[0154] like Figure 10A The examples illustrate how each possible MAC entity can be understood / inferred from its structural relationships (such as M). (in the middle) and the connections between each RLC entity in the RLC entity that serves according to data processing and scheduling latency requirements. Note that, in the illustrated case, there is at least one such connection for each possible MAC entity.

[0155] In an alternative case where the MAC entity has no connection to any RLC entity (e.g., the MAC entity does not satisfy structure M) Requirements and / or if the MAC entity cannot satisfy the requirements for satisfying structure M (Regarding the required data processing and scheduling latency of any RLC entity), at that node, it can be removed from the list of possible MAC entities (this is not...). Figure 10A(The situation in the figure is not illustrated here).

[0156] Starting from this node, the network can create one or more MAC entities from the list of MAC entities. In some cases, this can be achieved by transmitting a message to the UE containing an indication of a MAC entity that can be used by an RLC entity. In some cases, these indications specify a particular RLC entity as capable of using a particular MAC entity from the list of MAC entities, consistent with the determinations discussed so far.

[0157] Figure 10A This corresponds to a situation where there may be no UE-based limit on the number of MACs created. In this case, the network can create all possible entities (e.g., the network can create each of the following: first MAC entity 1044, second MAC entity 1046, third MAC entity 1048, fourth MAC entity 1050, fifth MAC entity 1052, sixth MAC entity 1054, and seventh MAC entity 1056).

[0158] Figure 10B This illustrates a scenario where MAC entity creation occurs when the network is configured to utilize as much joint resource allocation as possible among base stations within the same sub-cluster (e.g., while adhering to applicable latency constraints). In this case, the network may ultimately create only a subset of MAC entities that use the full set of base stations within a single sub-cluster. In other words, for each RLC entity, among all connected MACs, the MAC associated with the maximum number of base stations is assumed to be selected (or at least preferred) by the network for use with that RLC entity.

[0159] For example, Figure 10B This example illustrates that, in the case discussed, the second MAC entity 1046 was not ultimately created (because there is no sub-cluster completely filled only by the second base station 1008 and the third base station 1010), and the third MAC entity 1048 was not ultimately created (because there is no sub-cluster completely filled only by the first base station 1006 and the second base station 1008). Note that... Figure 10B Examples of the same Figure 10A Similarly, this situation aligns with the concept that there is no UE-based limit on the number of MACs created.

[0160] Figure 10C An example of MAC entity creation is illustrated, where the network is aware of UE-based constraints instructing the UE to support only two simultaneously active MAC entities. In UE-constrained scenarios, the network may endeavor to create multiple MAC entities within the UE constraints / restrictions, and each radio bearer may be served by at least one of the MAC entities (through at least one RLC entity for that radio bearer).

[0161] Figure 10C The illustrated example shows one of the possible decisions the network can make in response to the situation currently under discussion. The network determines that the seventh MAC entity 1056 at the third base station 1010 can be used to allocate services to each of the sixth RLC entity 1030 serving DRB3 of the third PDCP entity 1018 and the third RLC entity 1024 serving DRB2 of the second PDCP entity 1016. Furthermore, the network determines that the fourth MAC entity 1050 can be used to allocate services to the second RLC entity 1022 serving DRB2 of the second PDCP entity 1016 and the first RLC entity 1020 serving DRB1 of the first PDCP entity 1014. It should be noted that while not every RLC entity within the protocol stack 1002 can allocate services in this case, at least one RLC entity can allocate services for each radio bearer.

[0162] Consistent with these determinations and the two MAC entity restrictions at the UE, the network ultimately creates a fourth MAC entity 1050 and a seventh MAC entity 1056 (and does not create any other MAC entities, as illustrated).

[0163] Figure 11 A flowchart 1100 illustrating the establishment and / or creation of corresponding MAC entities according to the implementation scheme discussed herein is provided. Flowchart 1100 illustrates the operation of CCF 1102, one or more RLC entities 1104, and L3 scheduler 1106, as well as the operations between them.

[0164] CCF 1102 receives 1108 RLC delay requirement (denoted as L) from RLC entity 1104. REQ (RLC). These latency requirements can correspond to the acceptable data processing and scheduling latency for RLC entity 1104, as discussed herein.

[0165] CCF 1102 then selects 1110 candidate MAC entities (e.g., MAC entities that are one of the MAC entities in the list of possible MAC entities, as described herein).

[0166] For the selected candidate MAC entity, CCF 1102 sends a request to L3 scheduler 1106 for a report on the delay for the candidate MAC entity caused by scheduler coordination. CCF 1102 receives a report on the delay for the candidate MAC entity caused by scheduler coordination in response to the response from L3 scheduler 1106.

[0167] CCF 1102 then continues to calculate the total delay of candidate MAC entities 1116 (denoted as L). MAC The total latency of the MAC candidate includes the latency caused by scheduler coordination received from L3 scheduler 1114. The total latency of the candidate MAC entity may also include / take into account additional associated durations known to CCF 1102, such as the duration for algorithm processing, the duration corresponding to the communication of permission to the UE, and / or the duration corresponding to the period between the first TTI when permission is granted and the second TTI sent by the scheduler.

[0168] Once the L for the candidate MAC entity MAC It has been determined that the network has determined L. MAC Is it possible to target the structure (according to structure M)? (Requirement) The L of each RLC entity in RLC entity 1104 served by the candidate MAC entity REQ (RLC) within (e.g., less than or equal to L) REQ (RLC)). If at least one such case exists, a corresponding connection between the candidate MAC entities can be assumed, and the candidate MAC entities remain on the list of possible MAC entities. If no such case exists, the candidate MAC entities under consideration are removed as candidates.

[0169] It should be noted that the process from selecting 1110 to determining 1118 can also be performed for additional candidate MAC entities.

[0170] CCF 1102 then decides 1120 on the creation of the MAC entity. This decision 1120 can be made based on a set of candidate MAC entities, for which there exists L MAC In the applicable L REQ At least one of the following situations within (RLC). In addition, decisions can be made based on one or more of the bases discussed herein, such as whether the network is specifically configured to use as many joint resource allocations as possible, whether there are any UE restrictions on the number of simultaneous MAC entities, etc.

[0171] Transport block distribution on MAC

[0172] The set of all created MAC entities in the UE can be obtained by In addition, take T. max This indicates the maximum number of TBs that the UE can process / use during a single TTI. Note that T... max It can be defined by / based on the UE's capabilities.

[0173] It allows MAC entity M to generate (up to) T at a single TTI. MOne transport block. Therefore, T M This is equal to the number of permissions (DL or UL) that can be provided by MAC entity M. In various cases, the network can be configured to provide an assignment of T to each MAC entity M. M The TB distribution (e.g., on a near real-time basis).

[0174] In which T M When T = 0, the corresponding MAC entity M can be considered inactive. M When the value is greater than 0, the corresponding MAC entity M can be considered active. As a collection of all active MAC addresses.

[0175] Now let's discuss T. M "Feasible" distribution The concept of T. (This refers to a concept that is considered feasible.) M Distribution ,against T M The assignment should satisfy the following two constraints:

[0176] 1. ,and

[0177] 2. For each radio bearer r R should have an active MAC entity M connected to the RLC of r. .

[0178] Will As all feasible distributions on M A set of.

[0179] It can be understood that this is the set of all MAC entities at the UE. It should be configured such that it supports at least one feasible distribution. Now, based on the above text regarding... Figure 9 The protocol stack 902 and cluster 904 described in Figure 900 are examples used to illustrate this concept.

[0180] about Figure 9 Protocol stack 902, when T max When =1, there are two possible feasible distributions:

[0181] 1. T1=0, T2=1, T3=0

[0182] 2. T1=0, T2=0, T3=1

[0183] It should be noted that the first MAC entity 914 cannot be used in this case, because the radio bearer of the second PDCP entity 910 will be blocked in this case.

[0184] Again about Figure 9 Protocol stack 902, when T max When = 2, there are five possible feasible distributions:

[0185] 1. T1=1, T2=1, T3=0

[0186] 2. T1=1, T2=0, T3=1

[0187] 3. T1=0, T2=1, T3=1

[0188] 4. T1=0, T2=2, T3=0

[0189] 5. T1=0, T2=0, T3=2

[0190] It should be noted that in this case, at least one of the second MAC entity 920 and the third MAC entity 926 should be used to allow the radio bearer for each of the first PDCP entity 908 and the second PDCP entity 910 to communicate with the UE.

[0191] RLC entity to MAC entity edge activation

[0192] In the discussion of this paper, the term "edge" is defined as a possible one-to-one connection between an existing RLC entity and an existing MAC entity. References Figure 9 Accordingly, it can be understood that the illustrated connection between the RLC entity and the MAC entity is an example of an “edge” as discussed in this article.

[0193] An "active" edge is an active (e.g., in use) connection between an RLC entity and a MAC entity required by a given QoS and / or Link Adaptation (LA) policy for a radio bearer. An "inactive" edge is an inactive (e.g., not in use) connection between an RLC entity and a MAC entity required by a given QoS and / or LA policy for a radio bearer. It is conceivable that any given radio bearer may correspond to one or more active and / or inactive edges. Edges can be active / activated and / or inactive / deactivated at the TTI granularity.

[0194] One or more edges from the set of all edges for a selected (created) MAC entity can be dynamically activated or deactivated based on, for example, the need to meet different QoS and / or LA policy requirements for different bearers over time. Because of the ability to dynamically activate / deactivate edges, the entire set of created MAC entities does not necessarily need to be adjusted to account for every change in these QoS and / or LA policy requirements for active bearers; therefore, the process for creating and / or deleting MAC entities can be performed at a lower frequency compared to alternative mechanisms where edges are not dynamically activated / deactivated. In other words, because edges can be activated and / or deactivated more efficiently than the complete creation and / or deletion of MAC entities, the total overhead incurred when using edge activation / deactivation can be relatively reduced. Activating / deactivating one or more edges in the described manner can be performed by the L3 scheduler.

[0195] Regarding the handling of different potential QoS and / or LA policy requirements for different radio bearers, various requirements may come into play. For example, there may be high reliability requirements for radio bearers. This requirement may lead to the use of more simultaneous data transmissions via multiple MAC entities. In cases where beamforming is not used, this requirement may not require MAC entity synchronization.

[0196] As another example, there may be low latency requirements for radio bearers. This requirement might result in transmission using a single terabyte (TB) via a single MAC entity. Furthermore, this requirement could impact the QoS and / or LA requirements of other radio bearers.

[0197] As another example, there may be capacity requirements for radio bearers. This requirement might lead to more simultaneous, non-replicated data transmissions via multiple possible MAC entities. Where beamforming is not used, this requirement may not require MAC entity synchronization.

[0198] Examples of RLC to MAC edge activation / deactivation

[0199] Figure 12A , Figure 12B and Figure 12C Examples are given in the first part about Figure 9 Examples of RLC-to-MAC edge activation / deactivation in the context of the 902 protocol stack are introduced. In these examples, it is assumed that T max =2.

[0200] Figure 12A Examples are given of those that are passed through Figure 9 Distribution of the 902 protocol stack This corresponds to the case where T1=1, T2=1, and T3=0. As discussed earlier, this is a feasible distribution.

[0201] Consistent with this distribution, as shown in the figure, the first edge 1202 between the first RLC entity 912 and the first MAC entity 914 is active, the second edge 1204 between the first RLC entity 912 and the second MAC entity 920 is inactive, the third edge 1206 between the first RLC entity 912 and the third MAC entity 926 is inactive, the fourth edge 1208 between the second RLC entity 918 and the second MAC entity 920 is active, and the fifth edge 1210 between the third RLC entity 924 and the third MAC entity 926 is inactive. Since no edge connected to the third MAC entity 926 is active, the third MAC entity 926 is inactive (unused) during the TTI using this arrangement.

[0202] As shown in the figure, activating the first edge 1202 and the fourth edge 1208 within the context of protocol stack 902 corresponds to the following situations: the TB of the first MAC entity 914 is used for the data of the first radio bearer of the first PDCP entity 908 according to the first QoS and / or LA policy for the first radio bearer of the first PDCP entity 908; and the TB of the third MAC entity 926 is used for the data of the second radio bearer of the second PDCP entity 910 according to the second QoS and / or LA policy for the second radio bearer of the second PDCP entity 910.

[0203] Figure 12A The arrangement can be considered as representing an example candidate edge activation for protocol stack 902 in the case of reliability constraint data in the radio bearer for the first PDCP entity 908.

[0204] Figure 12B Examples are given of those that are passed through Figure 9 Distribution of the 902 protocol stack This corresponds to the cases where T1=1, T2=0, and T3=1. As discussed earlier, this is a feasible distribution.

[0205] Consistent with this distribution, as shown in the figure, the first edge 1202 between the first RLC entity 912 and the first MAC entity 914 is active, the second edge 1204 between the first RLC entity 912 and the second MAC entity 920 is inactive, the third edge 1206 between the first RLC entity 912 and the third MAC entity 926 is active, the fourth edge 1208 between the second RLC entity 918 and the second MAC entity 920 is inactive, and the fifth edge 1210 between the third RLC entity 924 and the third MAC entity 926 is active. Since no edge connected to the second MAC entity 920 is active, the second MAC entity 920 is inactive (unused) during the TTI using this arrangement.

[0206] In this scenario, it is possible that, for each of the TB of the first MAC entity 914 and the TB of the third MAC entity 926, data from the first PDCP entity 908 in the buffer of the first RLC entity 912 may be copied or not copied and forwarded. For the TB of the third MAC entity 926, data from the second PDCP entity 910 in the buffer of the third RLC entity 924 is forwarded. Given that the TB of the third MAC entity 926 is potentially used by each of the first RLC entity 912 for the first PDCP entity 908 and the third RLC entity 924 for the second PDCP entity 910, if either the first PDCP entity 908 or the second PDCP entity 910 requires a relatively low modulation and decoding scheme (MCS), then the data in both the buffers of the first RLC entity 912 and the buffer of the third RLC entity 924 should follow that lower MCS in the TB of the third MAC entity 926.

[0207] Figure 12B The arrangement can be considered as representing an example candidate edge activation for protocol stack 902 in the case of reliability and / or capacity constraint data in the radio bearer for the first PDCP entity 908.

[0208] Figure 12B Examples are given of those that are passed through Figure 9 Distribution of the 902 protocol stack This corresponds to the cases where T1=0, T2=1, and T3=1. As discussed earlier, this is a feasible distribution.

[0209] Consistent with this distribution, as shown in the figure, the first edge 1202 between the first RLC entity 912 and the first MAC entity 914 is inactive; the second edge 1204 between the first RLC entity 912 and the second MAC entity 920 is active; the third edge 1206 between the first RLC entity 912 and the third MAC entity 926 is inactive; the fourth edge 1208 between the second RLC entity 918 and the second MAC entity 920 is active; and the fifth edge 1210 between the third RLC entity 924 and the third MAC entity 926 is active. Since no edge connected to the first MAC entity 914 is active, the first MAC entity 914 is inactive (unused) during the TTI using this arrangement.

[0210] From this arrangement, it can be understood that data from the first PDCP entity 908 in the buffer of the first RLC entity 912 and data from the second PDCP entity 910 in the buffer of the second RLC entity 918 will effectively follow the same QoS and LA policies (based on the fact that data from either / both of the buffers of the first RLC entity 912 and the second RLC entity 918 can be merged into the TB of the second MAC entity 920). This means, for example, if either the first PDCP entity 908 or the second PDCP entity 910 requires a relatively low MCS, then data in both the buffers of the first RLC entity 912 and the buffer of the second RLC entity 918 should follow that lower MCS in the TB of the third MAC entity 926.

[0211] MAC controller entity for MAC entity orchestration at the base station

[0212] In some existing wireless communication systems, each connected base station has a single logical MAC entity for each connected UE (this may be the case, for example, depending on the current specific implementation of a wireless communication system operating LTE and / or NR RAT). However, in a cellular network architecture as described herein, each base station may have more than one logical MAC entity for each connected UE. Therefore, it should be understood that, for the same set of hardware and / or software resources, a smaller number of UEs can be supported simultaneously at a base station operating under a cellular network architecture compared to a base station operating in an LTE / NR context.

[0213] It can be observed that some MAC procedures operated by MAC entities can be defined / understood as UE-specific (procedures that should be implemented per UE), and other procedures can alternatively be understood as TB-specific (procedures that can be implemented on a per TB / per MAC entity basis). In the cellular-free architectures discussed herein, which now envision potential multiple MACs for a single UE at the base station, it is therefore possible that some UE-specific procedures may be replicated at each MAC entity for that UE. This replication represents an inefficient use of hardware and / or software resources at the base station.

[0214] Therefore, in some implementations, a MAC controller entity can be introduced at the base station. The MAC controller entity can be a logical entity with a one-to-one correspondence with the UE. The MAC controller entity can be a UE-specific MAC entity utilizing additional / specific control functions. The MAC controller entity can have the ability to distinguish between UE-specific MAC procedures and TB-specific MAC procedures, so as to enable more efficient use of hardware and / or software resources at base stations operating in a cellular architecture.

[0215] A MAC controller entity can assume one or more of the following roles. For example, a MAC controller entity can assume an operational role, under which it is responsible for performing all UE-specific procedures and UE-specific data processing without routing data to any (potentially multiple) logical MAC entities at the base station for a given UE (thus resulting in more efficient use of hardware and / or software resources at the base station).

[0216] Example MAC controller entities additionally and / or alternatively assume management and orchestration roles, under which they manage all TB-specific data processing for a given UE across different logical MAC entities at base stations (resulting in more efficient use of hardware and / or software resources at the base station).

[0217] Figure 13 A diagram 1300 illustrates a base station 1302 with an operational MAC controller entity 1304 according to an embodiment discussed herein. As illustrated, the MAC controller entity 1304 can control one or more of the first MAC entity 1306, the second MAC entity 1308, and / or the third MAC entity 1310 of the base station 1302 (e.g., according to operational roles and / or management and orchestration roles, as discussed herein). It should be noted that in this arrangement, the first MAC entity 1306, the second MAC entity 1308, and the third MAC entity 1310 maintain their position as entities that directly interact with the physical layer 1312.

[0218] Implementation plan for UE's multi-TB (multi-TB) capability message transmission

[0219] To enable distributed MAC scheduling as described herein, a UE can simultaneously handle multiple (e.g., several) UL / DL grants and can further receive / transmit a corresponding number of TBs within a given TTI. It is possible that the UE is configured to provide a capability message to the network indicating its ability to handle TBs within a given TTI, thus informing the network of these UE capabilities. The UE capability message may include one or more of the following: the maximum number of TBs supported by the UE per TTI, the maximum data size of the TBs (e.g., assuming a given number of transmitted and / or received TBs), and / or the total maximum collective data size of the TBs transmitted and / or received within a given TTI. In some implementations, the UE capability message may be an RRC message. In some cases, the UE limit on the maximum / total TB size may be broken separately between the UL and DL in the capability message.

[0220] It should be noted that UE limitations such as maximum / total collective TB size apply at the UE level in order to keep the complexity of the UE's PHY layer implementation at a feasible level.

[0221] Figure 14 Figure 1400 illustrates the correspondence between the transmission of UE capability message 1406 according to the implementation scheme discussed herein, and also illustrates the content of UE capability message report 1412 that may be included in UE capability message 1406.

[0222] As illustrated, UE 1402 can provide UE capability message 1406 to non-cellular network 1404. This UE capability message 1406 can be transmitted to, for example, a cluster of base stations serving the UE.

[0223] UE capability message 1406 may include, for example, UE capability message report 1412. In this example, UE capability message report 1412 (individually) reports the maximum number of DL TBs that the UE can support with respect to various maximum possible DL TB sizes 1408 and the maximum number of UL TBs that the UE can support with respect to various maximum possible UL TB sizes 1410.

[0224] In Figure 14 In the corresponding example, the maximum number of DL TBs that the UE can support is 1408. When the maximum possible DL TB size is S_DL (the size of the DL allowed), it is up to one DL TB; when the maximum possible DL TB size is S_DL / 2, it is up to two DL TBs; when the maximum possible DL TB size is S_DL / 4, it is up to four DL TBs; when the maximum possible DL TB size is S_DL / 8, it is up to eight DL TBs; and when the maximum possible DL TB size is S_DL / 16, it is up to 16 DL TBs.

[0225] Furthermore, the UE can support a maximum number of UL TBs of 1410, up to one UL TB when the maximum possible UL TB size is S_UL (UL-permitted size), up to two UL TBs when the maximum possible UL TB size is S_UL / 2, up to four UL TBs when the maximum possible UL TB size is S_UL / 4, and up to eight UL TBs when the maximum possible UL TB size is S_UL / 8. Note that other numbers / values ​​may be applied in alternative examples / alternative UEs.

[0226] Implementation schemes for radio bearers with specific TB requirements

[0227] According to the cellular-free network mechanism described herein, a TB can contain data from a single logical channel or from multiple logical channels (and therefore from a single radio bearer or from multiple radio bearers). It is conceivable that an authorization (for DL ​​or UL) can be provided per TB. In the case of DL, the authorization for a TB (e.g., in DCI) can indicate one or more radio bearer identifiers (IDs) of the radio bearer that will use the DL TB. In the case of UL, the uplink control information (UCI) accompanying the scheduling of the TB can indicate one or more radio bearer IDs of the radio bearer that will use the UL TB.

[0228] Therefore, the UE and the network can configure information about the mapping between radio bearer IDs and radio bearers of interest before the indication (in order to simplify the subsequent indication). Figure 15 An example of configuring a radio bearer ID for indicating a radio bearer-specific TB between a radio bearer such as UE 1502 and noncellular network 1504, according to the implementation scheme discussed herein, is illustrated. It should be noted that noncellular network 1504 can operate via, for example, a cluster of base stations of noncellular network 1504 serving UE 1502, as indicated.

[0229] As illustrated, UE 1502 provides configuration information 1506 to the non-cellular network 1504 regarding one or more radio bearer IDs. The configuration information 1506 may, for example, associate the mapping of radio bearer IDs with zero or more radio bearers that exist or may exist between UE 1502 and the non-cellular network 1504.

[0230] Figure 15 An example of such configuration information is provided in the form of Table 1510, which lists radio bearer IDs. As shown in Table 1510, radio bearer ID “0” is not associated with any radio bearer, radio bearer ID “1” is associated with the first signaling radio bearer (SRB) (SRB1), radio bearer ID “2” is associated with each of the first and second DRBs (DRB1 and DRB2), and radio bearer ID “3” is associated with the third DRB (DRB6).

[0231] Regarding Table 1510, if the data for SRB1 and / or DRB1, DRB2 and / or DRB6 are to be located in the TB, this will be indicated in the DCI or UCI (as the case may be) using the corresponding radio bearer ID; otherwise, the indication in the DCI / UCI may be “0”.

[0232] Upon receiving configuration information 1506, the non-cellular network 1504 can reply to UE 1502 with confirmation message 1508.

[0233] It can be envisioned that configuration information 1506 may represent a semi-static configuration delivered using RRC message sending and receiving (and in this case, flowchart 1500 can therefore be understood as an example of RRC message exchange).

[0234] It is also conceivable that the configuration information 1506 may include different information (e.g., different tables) for each of the UL and DL scenarios. In other words, in some embodiments, the configuration information 1506 may include first information regarding the correspondence between radio bearer IDs and zero or more radio bearers used in the UL context, and second information regarding the correspondence between radio bearer IDs and zero or more radio bearers used in the DL context.

[0235] It is also conceivable that configuration information 1506 could also provide a set of radio bearers to use when the radio bearer ID is not included in the indication (signaling situations that can be utilized to save radio resources).

[0236] In the UL case, it is possible that the UCI, including the radio bearer ID for the applicable radio bearer using the UL TB, is transmitted in the physical uplink control channel (PUCCH), which is transmitted either before or together with the corresponding physical uplink shared channel (PUSCH) having the TB.

[0237] Based on the radio bearer information for the TB known to each of the UE and the network, the UE / network can adjust the PHY layer and / or L2 processing for the TB (e.g., processing order and / or the number of low-density parity (LDPC) decoder iterations).

[0238] Figure 16A A flowchart 1600 is illustrated according to the implementation discussed herein for indicating a radio bearer based on previously established configuration information for mapping radio bearer IDs to zero or more radio bearers existing between UE 1602 and the cellular network 1604. It should be noted that the cellular network 1604 can operate as indicated by, for example, a cluster of base stations serving UE 1602 within the cellular network 1604.

[0239] Flowchart 1600 illustrates a DCI 1606 transmitted from cellular network 1604 to UE 1602. This DCI scheduling includes a TB (Radio Bearer) and a Physical Downlink Shared Channel (PDSCH) with a radio bearer indication corresponding to that TB. This radio bearer indication may take the form of a radio bearer ID previously configured between UE 1602 and cellular network 1604, which identifies one or more radio bearers that will use the TB. In this way, the UE is notified which radio bearers will use the TB.

[0240] Then, the non-cellular network 1604 transmits PDSCH 1608 with TB to the network. Based on the radio bearer indication received in DCI 1606, UE 1602 knows which radio bearers use TB, and is therefore able to select 1610 the reception processing option that allows UE 1602 to properly handle TB.

[0241] Figure 16B A flowchart 1612 is illustrated according to the embodiment discussed herein for indicating a radio bearer based on previously established configuration information for mapping radio bearer IDs to zero or more radio bearers existing between UE 1602 and the cellular network 1604. It should be noted that the cellular network 1604 can operate as indicated by, for example, a cluster of base stations serving UE 1602.

[0242] Flowchart 1600 illustrates a DCI 1614 that schedules a PUSCH containing a TB to be transmitted from a cellular network 1604 to a UE 1602. The UE 1602 then performs a MAC data allocation 1616 from data carried by one or more radios into that TB.

[0243] UE 1602 then transmits PUCCH 1618 to the non-cellular network 1604. This PUCCH includes a UCI indicating a radio bearer indication corresponding to the TB. This radio bearer indication may take the form of a radio bearer ID previously configured between UE 1602 and the non-cellular network 1604, which identifies one or more radio bearers of the TB. In this way, the network is notified which radio bearers will use the TB.

[0244] Then, UE 1602 transmits PUSCH 1620 with TB to the network. Based on the radio bearer indication received in PUCCH 1618, the non-cellular network 1604 knows which radio bearers are using TB, and is therefore able to select 1622 the receive processing option that allows the non-cellular network 1604 to properly handle the TB.

[0245] One advantage derived from using radio to carry a specific TB mechanism is that it makes it possible to apply different QoS and / or LA policies for each TB within a TB. Figure 17 A diagram 1700 illustrates each of the non-DRB-specific data allocation options 1702 and DRB-specific data allocation options 1704 for the operation of MAC entity 1706 for example protocol stack 1708 according to the implementation discussed herein. As illustrated, MAC entity 1706 can serve first data (DRB1 data 1718) for a first radio bearer (DRB1) via a first PDCP entity 1710 and a first RLC entity 1712, and second data (DRB2 data 1720) for a second radio bearer DRB2 via a second PDCP entity 1714 and a second RLC entity 1716. MAC entity 1706 may be able to create two TBs during the TTI.

[0246] exist Figure 17 In the diagram, DRB1 data 1718 is illustrated with a solid line, and DRB2 data 1720 is illustrated with a dashed line. Regarding the non-DRB-specific data allocation option 1702, as illustrated, it is possible that MAC entity 1706 can schedule DRB1 data 1718 and DRB2 data 1720 on each of the first TB 1722 and the second TB 1724. In this case, it is possible that the MCS selection for the two TBs should be targeted at a BLER compatible with the QoS requirements of both DRBs (e.g., satisfying the most stringent DRB's Block Error Rate (BLER) / QoS requirement).

[0247] Regarding the DRB-specific data allocation option 1704, as illustrated, it is possible that MAC entity 1706 alternatively schedules (only) DRB1 data 1718 on the first TB 1722 and (only) DRB2 data 1720 on the second TB 1724. In this case, the MCS for the first TB 1722 can be selected based on the QoS requirements of DRB1, while the MCS for the second TB 1724 can be selected (independently) based on the QoS requirements of DRB2.

[0248] Generally, for DRBs with low latency QoS requirements, targeting a lower BLER (<10%) for LA is considered better, while for DRBs with high throughput QoS requirements, targeting a higher BLER (approximately 10% and higher) is considered better. Therefore, using radio bearer-specific TBs (such as in DRB-specific data allocation option 1704) allows for flexibility in implementing different LAs (MCS selection) across TBs within the same MAC entity and during the same TTI.

[0249] PDCCH configuration for multiple TB / permitted

[0250] It is conceivable that in some implementations, each MAC entity can be configured to correspond to a specific control resource set (CORESET) used to provide control information to the UE. In such cases, it is also possible that the MAC entity provides more than one UL grant (or more than one DL TB allocation) for the same TTI. In this case, the MAC entity allocates a corresponding number of PDCCH / DCIs in the CORESET search space used for that MAC.

[0251] Therefore, the UE can search for PDCCHs in the CORESET corresponding to the MAC entity until the maximum number of PDCCHs for that MAC entity is reached. This process can be repeated for each MAC entity at the UE.

[0252] It is conceivable that the UE can be provided with a maximum number of PDCCHs for MAC entities in various ways, including, for example, via RRC signaling and / or MAC control element (MACCE) signaling.

[0253] In some cases, the DCI of the PDCCH can include an indication of the actual number of PDCCHs for the UE in the considered CORESET, which may be less than the maximum number of PDCCHs for that CORESET. This indication can be used to reduce the complexity of PDCCH searching at the UE, because once the actual number of PDCCHs has been identified in the CORESET, the UE can stop performing PDCCH searching in the CORESET.

[0254] Figure 18A A flowchart 1800 is illustrated, showing an embodiment of the implementation discussed herein for configuring RRC message exchange for a CORESET corresponding to a MAC entity between UE 1802 and cellular network 1804. It should be noted that cellular network 1804 can operate via, for example, a cluster of base stations serving UE 1802, as indicated.

[0255] Flowchart 1800 illustrates how the cellular network 1804 transmits a first RRC message 1806 to the UE 1802, which configures the mapping between the CORESET and a specific MAC entity of the UE. Then, the cellular network 1804 transmits a second RRC message 1808 to the UE 1802, which indicates the maximum number of PDCCHs that can be found in the CORESET. Therefore, the UE knows and is configured to search (up to) the maximum number of PDCCHs for the MAC corresponding to the CORESET.

[0256] Figure 18B A flowchart 1810 illustrates a maximum number of MAC CE indications for a pair of PDCCHs (corresponding to DCI / TB) that can be allocated by MAC, such as between UE 1802 and cellular network 1804, according to the implementation discussed herein. It should be noted that cellular network 1804 can operate as indicated by, for example, a cluster of base stations of cellular network 1804 serving UE 1802.

[0257] Flowchart 1810 illustrates the transmission of MAC CE 1812 from MAC entity 1814 (from the side of non-cellular network 1804) to (the same) MAC entity 1814 (on the side of MAC entity 1814). The MAC CE 1812 includes the maximum number of PDCCHs for MAC entity 1814 that can be found in the CORESET for MAC entity 1814.

[0258] Implementation scheme of the algorithm for MAC entity establishment

[0259] We will now discuss the process of creating MAC entities and assigning each of them to a UE-specific subset of 1) base station entities and 2) RLC entities.

[0260] The inputs to this process may include:

[0261] •C, a list of base stations belonging to the cluster for the UE;

[0262] • A list of DRB entities;

[0263] • A list of RLC entities (e.g., with entries in the form of: (RLC_ID, DRB_ID, (BS ID)) which conveys the ID of the RLC entity, the DRB ID of the DRB served by the RLC entity, and the IDs of one or more base stations in the sub-cluster of the RLC entity;

[0264] • The reference signal received power (RSRP) associated with each base station (e.g., as an actual value in decibels (dB), and the base station load for each base station (e.g., a value in the range [0,1]).

[0265] •MAC Max : This value represents the maximum number of MAC entities;

[0266] •T max : This value represents the maximum number of transport blocks that a UE can process simultaneously;

[0267] •Gain ThThe parameters of the options for the greedy algorithm discussed elsewhere in this article; and

[0268] •N o Noise parameters (e.g., in dB).

[0269] The output of this process may include a list of MAC entities. .

[0270] exist A MAC entity can be represented by a MAC ID, a list of base station IDs associated with that MAC entity, and a list of RLC entities associated with that MAC entity (e.g., in the form of (MAC_ID, (BS ID), (RLC ID))).

[0271] In this case, for each MAC entity M ∈ There should exist a natural value T. M At least one assignment of (transfer block) such that:

[0272] 1. ,and

[0273] 2. For each DRB d, there exists a T connected to the RLC entity belonging to DRB d. M At least one MAC entity M with a value greater than 0.

[0274] Furthermore, the number of DRBs connected to MAC entity M can be defined as D(M) := #{d DRB: M RLC d}, where RLC d means that the RLC entity belongs to DRB d.

[0275] It's understandable, b M signifies that base station b is associated with MAC entity M. MAC entity M is considered connected to an RLC entity if and only if the set of base stations associated with MAC M is also the set of base stations associated with an RLC entity. Note that M... RLC represents the relationship between MAC entity M and a given RLC entity.

[0276] It's also understandable that w = (w b ) b The vector represents the base station weights, where w b ∈ .

[0277] The objective function can then be defined as follows:

[0278] ,in

[0279] .

[0280] Given the above framework, we will now describe the process for the first option of the greedy algorithm.

[0281] First, for each base station b, the weights are calculated as follows:

[0282] .

[0283] Then, The set of all subsets that are set to be equal to cluster C.

[0284] Then, repeat the following steps:

[0285] 1. Find the objective function F that does not decrease when it is eliminated. The element M, i.e. F( , w) = F( \{M},w).

[0286] 2. Settings := \{M}

[0287] These steps can be repeated until no solution can be found that eliminates the objective function F without reducing it. The element M.

[0288] If | | ≤ MAC Max Then the result is set to:= Otherwise, repeat the following steps until | | ≤MAC Max :

[0289] 1. Find the method that minimizes the reduction of the objective function F by eliminating it. The element M.

[0290] 2. Settings := {M}.

[0291] Once| | ≤ MAC Max Result of setting:= .

[0292] Once the algorithm is complete, a MAC list structure can be created based on the results.

[0293] Figure 19A , Figure 19B , Figure 19C , Figure 19D and Figure 19E Together, we visually illustrate the modification of diagram 1900 corresponding to the process using a greedy algorithm according to the implementation scheme discussed herein. Diagram 1900 includes, as per... Figure 4 The protocol stack 402 and cluster 404 discussed (but note that for ease of illustration, they have been removed from...) Figure 19A SDAP entity 418 is omitted in protocol stack 402.

[0294] exist Figure 19A At the illustrated node, various possible MAC entities have been identified with respect to protocol stack 402, and connections corresponding to these possibilities have been established. These possible MAC entities include: a first MAC entity 1902, which uses each of the first base station 406, the second base station 408, and the third base station 410 and is connected to the first RLC entity 422; a second MAC entity 1904, which uses the first base station 406 and the second base station 408 and is connected to the first RLC entity 422 and the second RLC entity 428; a third MAC entity 1906, which uses the third base station 410 and is connected to the first RLC entity 422 and the third RLC entity 430; and a fourth MAC entity 190. 8. The fourth MAC entity uses the first base station 406 and the third base station 410 and is connected to the first RLC entity 422; the fifth MAC entity 1910 uses the second base station 408 and the third base station 410 and is connected to the first RLC entity 422; the sixth MAC entity 1912 uses the first base station 406 and is connected to the first RLC entity 422 and the second RLC entity 428; and the seventh MAC entity 1914 uses the second base station 408 and is connected to the first RLC entity 422 and the second RLC entity 428.

[0295] The network may know that UE 412's capabilities are limited to using 3 MAC entities. Therefore, using methods such as cross-... Figure 19A , Figure 19B , Figure 19C , Figure 19D and Figure 19E The illustrated greedy algorithm means reducing the seven possible MAC entities to a set of three MAC entities that will actually be created.

[0296] Figure 19B The example illustrates that during the first repetition of this process, the removal of the seventh MAC entity 1914 as a possibility does not reduce the objective function F corresponding to the set of possible MAC entities. Therefore, the seventh MAC entity 1914 is removed from the set of possible MAC entities as a possible MAC entity.

[0297] Figure 19C An example is given in the second repetition of this process, where the removal of the sixth MAC entity 1912 as a possibility does not reduce the objective function F corresponding to the set of possible MAC entities. Therefore, the sixth MAC entity 1912 is removed from the set of possible MAC entities as a possible MAC entity.

[0298] Figure 19D An example is given in the fourth repetition of this process, where the removal of the fifth MAC entity 1910 as a possibility does not reduce the objective function F corresponding to the set of possible MAC entities. Therefore, the fifth MAC entity 1910 is removed from the set of possible MAC entities as a possible MAC entity.

[0299] Figure 19E An example is given in the fifth repetition of this process, where the removal of the fourth MAC entity 1908 as a possibility does not reduce the objective function F corresponding to the set of possible MAC entities. Therefore, the fourth MAC entity 1908 is removed from the set of possible MAC entities as a possible MAC entity.

[0300] At this node, there are three remaining possible MAC entities, which is within the UE's capabilities. Therefore, the network continues to create these three MAC entities.

[0301] It should be noted that the examples provided earlier are not the only possible options for a greedy algorithm. A description of the process for a second option for a greedy algorithm will now be given.

[0302] First, for each base station b, the weight w is calculated as follows: b :w b := (1 – Load b )

[0303] Then, for each RLC entity, select the base station with the highest weight: b(RLC) := .

[0304] Then, set .

[0305] Then, if ≤ MAC Max ,

[0306] 1. Settings — Represents the set of all subsets of the cluster, excluding The elements and the empty set.

[0307] 2. Set MaxMACLatency :=

[0308] 3. Repeat the following steps, while | | ≤ MAC Max :

[0309] i. Calculate for each S ∈ F( ∪ {S}, w), assume that SchedMACLatency(S| ) ≤ MACLatencyReq(RLC) and S RLC, MAC S connects to RLC.

[0310] ii. Find the one with the largest F( The elements S ∈ ∪ {S}, w) .

[0311] iii. If ≥ Gain Th ,renew := ∪ {S}, := { Otherwise: break the loop.

[0312] Then, set the result := .

[0313] Once the algorithm is complete, a MAC list structure can be created based on the results.

[0314] Implementation scheme of the algorithm for edge activation of RLC entity to MAC entity

[0315] The algorithm for RLC entity-to-MAC entity edge activation can use the following decision variables:

[0316] •x i,j : A binary variable representing the connection between RLC entity i and MAC entity j.

[0317] •y j : A binary variable indicating whether MAC entity j is active (e.g., 1 if active, 0 otherwise).

[0318] The algorithm used for RLC entity-to-MAC entity edge activation can use the following parameters:

[0319] •C i,j : A connection matrix entry indicating whether the connection between RLC entity i and MAC entity j is feasible (1 if possible, 0 otherwise);

[0320] •w dPriority weights of DRB d;

[0321] • : The normalized priority weight of a given MAC entity j corresponding to DRB d. Based on To calculate;

[0322] •b k,j : The weight of base station k associated with MAC entity j, indicating its base station load and RSRP quality;

[0323] •α j : The normalized weights of base stations belonging to MAC entity j, to ensure that the MAC entity weights reflect the average value of base stations across MAC entity j, i.e., α j =

[0324] •RLC d : A set of RLC entity indexes associated with DRB d. This set may be a subset of the total number of RLC entities across all DRBs;

[0325] • D: The total number of DRBs associated with a given UE;

[0326] • P: The total number of RLC entities associated with all DRBs of a given UE;

[0327] • R: The total number of all possible MAC entities;

[0328] •T max The maximum number of MAC entities that can be activated based on the maximum number of TBs for a given UE; and

[0329] •λ: Fairness factor that ensures fair utilization of resources among all DRBs of a given UE.

[0330] Then, the objective function is used. The objective function aims to maximize the combined priority of the DRB and the weights of the base stations connected by the active MAC entities, while maintaining fairness across the DRB. Therefore, the optimization problem represented by the objective function is constructed to maximize the combined priority of the DRB and the weights of the base stations, while also ensuring fairness and adhering to the given set of constraints.

[0331] Example objective functions could be:

[0332] .

[0333] In the objective function, the term Designed to enable DRB (by The cumulative priority of (represented by) and the base station associated with the MAC entity (by b) k,jThis approach maximizes the weight of (represented by DRB priority and base station weight). It encourages prioritizing connections between RLC and MAC entities based on both DRB priority and base station weight.

[0334] item It is designed to operate as a fairness penalty. It will square the deviation from the minimum fair connection (where each DRB will have 1 connection). The lambda multiplier controls the importance of this fairness relative to the other term.

[0335] Now let's discuss the various constraints within the framework described above.

[0336] The first type of constraint can be a feasibility constraint. This constraint ensures that only operations such as those performed by the connection matrix C are possible. i,j Defined possible connections. This constraint is necessary to comply with the UE's capability limitations. This constraint can be expressed as:

[0337]

[0338] Another type of constraint could be the MAC activation constraint. This constraint ensures that the number of active MAC entities does not exceed T. max This constraint can be used to comply with UE capability limitations. This constraint can be expressed as:

[0339] y j ≤ T max

[0340] Another such constraint ensures that at least one RLC is connected for each DRB. This constraint guarantees that each DRB obtains at least one connection, thus ensuring a minimum service level for each DRB. This constraint can be expressed as:

[0341]

[0342] Another constraint can link y j and x i,j Variable: Such a constraint will y j Decision variables and x i,j Variable linking. If any RLC entity is linked to MAC entity j, then y j It will be forced to 1, indicating that MAC entity j is active. Conversely, if no RLC entity is connected to MAC entity j, then y j A value of 0 indicates that MAC entity j is inactive. This constraint can be expressed as:

[0343]

[0344] Other constraints can be y j and x i,jBinary constraints on variables. These constraints ensure that decision variables can only take the values ​​0 or 1, representing the absence or presence of a connection, respectively. These constraints can be expressed as:

[0345]

[0346] as well as

[0347]

[0348] Regarding the objective function, choosing an appropriate fairness factor λ is crucial for achieving a balance between the priorities of individual DRBs and the overall fairness among all DRBs. A general method for determining λ is now described.

[0349] Initially, it is noted that regarding the role of λ, a larger λ emphasizes fairness (ensuring that as many DRBs as possible have at least one RLC entity among their RLC entities connected to the MAC entity), while a smaller λ focuses more on the individual DRB priorities and the weight of the base station.

[0350] Then, in order to find the value λ to use:

[0351] • First, choose any value for λ (for example, set it to be equal to the average priority of all DRBs).

[0352] • Then, solve the optimization problem (using the objective function) and analyze the results. If the solution undesirably supports the individual DRB priorities at the expense of fairness, increase λ. Conversely, if the solution is too fair (e.g., causing high-priority DRBs to be ignored), decrease λ.

[0353] • In the proposed iterative refinement mechanism, λ is adjusted in small increments or decrements. Each time λ is modified, the optimization problem is solved again. The iterative mechanism refines λ repeatedly in this way until a satisfactory balance between DRB priority and fairness is achieved.

[0354] When choosing λ, various practical considerations can be applied. For example, in real-world scenarios, prioritizing certain DRBs may be beneficial, especially when they are associated with critical applications or services. In such cases, a lower λ can be used.

[0355] Conversely, in scenarios where service must be provided to as many users as possible (even if, for example, this means compromising the quality of high-priority users), a higher λ can be used.

[0356] Figure 20A method 2000 for performing CCF (Continuous Communication Function) establishment for a wireless communication system for a cluster of base stations serving a UE, according to an embodiment of the present invention, is illustrated. Method 2000 includes identifying 2002 a first candidate MAC entity for the UE, the first candidate MAC entity corresponding to one or more base stations of the cluster, wherein the first or more base stations are in a first sub-cluster of base stations of the cluster, and a first RLC entity is synchronized across the first sub-cluster. Method 2000 further includes calculating 2004 a first delay for the first candidate MAC entity. Method 2000 further includes determining 2006 that the first delay for the first candidate MAC entity is within a first delay threshold of the first RLC entity. Method 2000 further includes transmitting 2008 a first indication to the UE that the first RLC entity can use the first candidate MAC entity based on determining that the first delay for the first candidate MAC entity is within the first delay threshold of the first RLC entity.

[0357] In some implementations, method 2000 further includes: requesting a scheduler coordination delay for a first candidate MAC entity from an L3 scheduler; and receiving a scheduler coordination delay for the first candidate MAC entity from an L3 scheduler, wherein the first delay for the first candidate MAC entity is calculated by the CCF using the scheduler coordination delay for the first candidate MAC entity.

[0358] In some implementations, method 2000 further includes receiving a first delay threshold from the first RLC entity.

[0359] In some implementations, method 2000 further includes: identifying a second candidate MAC entity for the UE, the second candidate MAC entity corresponding to a second or more base stations in a cluster, wherein the second or more base stations are in a sub-cluster, and the first RLC entity is synchronized across the sub-cluster; calculating a second delay for the second candidate MAC entity; determining that the second delay for the second candidate MAC entity is within a first delay threshold of the first RLC entity; and based on determining that the second delay for the second candidate MAC entity is within the first delay threshold of the first RLC entity, transmitting to the UE a second indication that the first RLC entity can use the second candidate MAC entity.

[0360] In some implementations, method 2000 further includes: identifying a second candidate MAC entity for the UE, the second candidate MAC entity corresponding to a second or more base stations in a cluster, wherein the second or more base stations are in a sub-cluster, and the first RLC entity is synchronized across the sub-cluster; calculating a second delay for the second candidate MAC entity; determining that the second delay for the second candidate MAC entity is not within a delay threshold of the first RLC entity; and discarding a second indication that the first RLC entity can use the second candidate MAC entity based on the determination that the second delay for the second candidate MAC entity is not within a delay threshold of the first RLC entity.

[0361] In some embodiments of method 2000, a first or more base stations corresponding to the first MAC entity are in a second sub-cluster of base stations of a cluster, the second RLC entity is synchronized across the second sub-cluster, and method 2000 further includes determining that a first delay for the first candidate MAC entity is within a second delay threshold of the second RLC entity, and based on determining that the first delay for the first candidate MAC entity is within the second delay threshold of the second RLC entity, transmitting to the UE a second indication that the second RLC entity can use the first candidate MAC entity.

[0362] Figure 21 A method 2100 for performing MAC entity establishment for a cluster of base stations serving a UE in a wireless communication system according to an embodiment of the present invention is illustrated. Method 2100 includes determining 2102 that the set of candidate MAC entities for the UE exceeds the UE's capabilities. Method 2100 further includes removing 2104 a first MAC entity from the set of candidate MAC entities for the UE in response to determining that the set of candidate MAC entities for the UE exceeds the UE's capabilities. Method 2100 further includes transmitting to the UE 2106 a list identifying that the set of candidate MAC entities can be used for communication corresponding to the UE in the wireless communication system.

[0363] In some implementations, method 2100 further includes: after removing a first MAC entity from the candidate MAC entity set, determining that the candidate MAC entity set for the UE does not exceed the UE's capabilities; wherein transmitting to the UE the list identifying that the candidate MAC entity set can be used for communication corresponding to the UE in the wireless communication system is based on determining that the candidate MAC entity set for the UE does not exceed the UE's capabilities.

[0364] In some implementations of method 2100, a first MAC entity is selected based on a greedy algorithm for removing the first MAC entity from the candidate MAC candidate set.

[0365] In some implementations, method 2100 further includes determining, before removing the first MAC entity from the candidate MAC entity set, that the candidate MAC entity set will be the feasible MAC entity set after removing the first MAC entity from the candidate MAC entity set; wherein removing the first MAC entity from the candidate MAC entity set for the UE also responds to determining that the candidate MAC entity set will be the feasible MAC entity set after removing the first MAC entity from the candidate MAC entity set.

[0366] In some implementations, method 2100 further includes: after removing a first MAC entity from the candidate MAC entity set, determining that the candidate MAC entity set still exceeds the capabilities of the UE; and removing a second MAC entity from the candidate MAC entity set for the UE in response to determining that the candidate MAC entity set for the UE still exceeds the capabilities of the UE.

[0367] In some embodiments of method 2100, the UE's capability includes the maximum number of MAC entities that can be supported at the UE, and determining that the set of candidate MAC entities for the UE exceeds the UE's capability includes determining that the number of MAC entities in the set of candidate MAC entities exceeds the maximum number of MAC entities that can be supported at the UE.

[0368] In some implementations, method 2100 also includes the ability to receive a UE from a UE.

[0369] Figure 22 A method 2200 for a UE served by a cluster of base stations of a wireless communication system according to an embodiment of this document is illustrated. Method 2200 includes receiving 2202 from the CCF of the wireless communication system an identifier of a set of MAC entities that can be used in the wireless communication system corresponding to the UE. Method 2200 further includes performing 2204 first communication in the wireless communication system using a first MAC entity from the MAC entity set, wherein the first MAC entity corresponds to a first or more base stations of the cluster, and wherein the first communication is directed to a first RLC entity that synchronizes across a first sub-cluster of base stations comprising the first or more base stations.

[0370] In some embodiments, method 2200 further includes using a second MAC entity from the MAC entity set to perform a second communication in a wireless communication system, wherein the second MAC entity corresponds to a second or more base stations of the cluster, and wherein the second communication is directed to a second RLC entity that synchronizes across a second sub-cluster of base stations of the cluster comprising the second or more base stations. In some such embodiments, the first communication and the second communication include data on the same radio bearer. In some such embodiments, the first communication includes first data on a first radio bearer, and the second communication includes second data on a second radio bearer.

[0371] In some implementations, method 2200 further includes using a first MAC entity from the MAC entity set to perform a second communication, wherein the second communication is directed to a second RLC entity that synchronizes across a second sub-cluster of base stations comprising a cluster of one or more first base stations.

[0372] Figure 23 A method 2300 for an L3 scheduler of a wireless communication system performing RLC-to-MAC edge activation in a cluster of base stations serving a UE, according to an embodiment of the present invention, is illustrated. Method 2300 includes activating 2302 a first edge between a first MAC entity and a first RLC entity used by a first radio bearer during a first TTI. Method 2300 further includes scheduling 2304 the use of a first sub-cluster of the cluster corresponding to the first RLC base station during the first TTI based on the activation of the first edge, to transfer first data of the first radio bearer between the first RLC entity and the first MAC entity during the first TTI.

[0373] In some implementations, method 2300 further includes activating a second edge between the first RLC entity and the second MAC entity within a first TTI, wherein scheduling of the use of the first sub-cluster during the first TTI is also used to transmit second data of the first radio bearer between the first RLC entity and the second MAC entity during the first TTI based on the activation of the second edge.

[0374] In some implementations, method 2300 further includes: activating a second edge between a first MAC entity and a second RLC entity used by a second radio bearer during a first TTI; and scheduling a second sub-cluster of the cluster corresponding to the base station of the second RLC entity during the first TTI, based on the activation of the second edge, to transmit second data of the second radio bearer between the second RLC entity and the first MAC entity during the first TTI. Some such implementations also include configuring each of the first and second RLC entities to use the same MCS for the TB of the first MAC entity during the first TTI.

[0375] In some implementations, method 2300 further includes: activating a second edge between a second MAC entity and a second RLC entity used by a second radio bearer during a first TTI; and scheduling a second sub-cluster of the cluster corresponding to the second RLC entity during the first TTI based on the activation of the second edge, to transmit second data of the second radio bearer between the second RLC entity and the second MAC entity during the first TTI.

[0376] In some implementations, method 2300 further includes deactivating the first edge during the second TTI; activating the second edge between the first RLC entity and the second MAC entity during the second TTI; and scheduling the first sub-cluster during the second TTI based on the activation of the second edge to transmit the second data of the first radio bearer between the first RLC entity and the second MAC entity during the second TTI.

[0377] In some embodiments, method 2300 further includes determining that a first TB of a first MAC entity can satisfy one of a first QoS policy and a first LA policy for a first radio bearer during a first TTI, wherein activation of the first edge is based on the determination that the first TB of the first MAC entity can satisfy one of the first QoS policy and the first LA policy for the first radio bearer during the first TTI. In some such embodiments, method 2300 further includes determining that a second TB of a second MAC entity can satisfy one of a second QoS policy and a second LA policy for a second radio bearer during the first TTI; and activating a second edge between the second MAC entity and a second RLC entity used by the second radio bearer within the first TTI based on the determination that the second TB of the second MAC entity can satisfy one of the second QoS policy and the second LA policy for the second radio bearer during the first TTI.

[0378] Figure 24 A method 2400 for a UE served by a base station trunking according to an embodiment of this document is illustrated. Method 2400 includes generating a capability message 2402 indicating a first maximum number of TBs supported at the UE during a single TTI. Method 2400 also includes sending a capability message 2404 to the trunking.

[0379] In some implementations of method 2400, the first maximum number of TBs is for UL, and the capability message also indicates a second maximum number of TBs supported at the UE during a single TTI for DL.

[0380] In some implementations of method 2400, the capability message also indicates the maximum data size for each TB in the TB.

[0381] In some implementations of method 2400, the capability message also indicates the maximum data size for the TB total.

[0382] Figure 25 A method 2500 for a cluster of base stations serving a UE according to an embodiment of this document is illustrated. The illustrated method 2500 includes receiving from the UE a capability message 2502 indicating a first maximum number of TBs supported at the UE during a single TTI. Method 2500 also includes performing 2504 MAC scheduling within the maximum number of TBs in response to receiving the capability message.

[0383] In some implementations of method 2500, the first maximum number of TBs is for UL, and the capability message also indicates a second maximum number of TBs supported at the UE during a single TTI for DL.

[0384] In some implementations of method 2500, the capability message also indicates the maximum data size for each TB in the TB.

[0385] In some implementations of method 2500, the capability message also indicates the maximum data size for a total TB.

[0386] Figure 26 A method 2600 for a base station cluster serving a UE according to an embodiment of this document is illustrated. Method 2600 includes transmitting 2602 a DCI to the UE, the DCI scheduling a first TB in a DL and including a first radio bearer ID identifying a first or more radio bearers capable of using the first TB. Method 2600 further includes transmitting 2604 first data of the first or more radio bearers to the UE in the first TB.

[0387] In some implementations, method 2600 further includes receiving configuration information from the UE defining the first radio bearer ID as being for a first or more radio bearers.

[0388] In some implementations, method 2600 further includes adjusting the lower-level processing used by the cluster to correspond to one or more radio bearers for the first TB before transmitting the first data.

[0389] In some implementations of method 2600, DCI also schedules a second TB in DL, and UCI includes a second radio bearer ID that identifies a second or more radio bearers capable of using the second TB, and method 2600 also includes transmitting second data of the second or more radio bearers to the UE in the second TB, wherein the first TB and the second TB are generated by the same MAC entity according to different MCS.

[0390] Figure 27A method 2700 for a UE served by a base station trunking according to an embodiment of this document is illustrated. Method 2700 includes receiving 2702 a DCI scheduled in the UL for a first TB from the trunking. Method 2700 also includes transmitting 2704 a UCI to the trunking, the UCI including a first radio bearer ID for a first or more radio bearers capable of using the first TB. Method 2700 further includes transmitting 2706 first data of the first or more radio bearers to the trunking in the first TB.

[0391] In some implementations, method 2700 further includes transmitting configuration information to the cluster defining a first radio bearer ID for a first or more radio bearers.

[0392] In some implementations, method 2700 further includes adjusting the lower-level processing used by the UE to correspond to one or more radio bearers for the first TB before transmitting the first data.

[0393] In some implementations of method 2700, DCI also schedules a second TB in UL, UCI includes a second radio bearer ID for a second or more radio bearers capable of using the second TB, and method 2700 also includes transmitting second data of the second or more radio bearers to the cluster in the second TB, wherein the first TB and the second TB are generated by the same MAC entity according to different MCS.

[0394] Figure 28 A method 2800 for a base station cluster serving a UE according to an embodiment of this document is illustrated. Method 2800 includes transmitting 2802 a DCI (Distributed Control Information) for scheduling a first TB (Base Station) in the UL (Unified Module) to the UE. Method 2800 also includes receiving 2804 a UCI (Unified Module) from the UE, the UCI including a first radio bearer ID for a first or more radio bearers capable of using the first TB. Method 2800 further includes receiving 2806 first data from the UE in the first TB, representing 2806 one or more radio bearers.

[0395] In some implementations, method 2800 further includes receiving configuration information from the UE defining the first radio bearer ID as being for a first or more radio bearers.

[0396] In some implementations, method 2800 further includes adjusting the lower-level processing used by the cluster to correspond to one or more radio bearers for the first TB before receiving the first data.

[0397] In some implementations of method 2800, DCI also schedules a second TB in UL, UCI includes a second radio bearer ID for a second or more radio bearers capable of using the second TB, and method 2800 also includes receiving second data from the UE in the second TB from the second or more radio bearers, wherein the first TB and the second TB are received by the same MAC entity and according to different MCS.

[0398] Figure 29 A method 2900 for a UE being served by a base station trunking according to an embodiment of this document is illustrated. Method 2900 includes receiving 2902 a DCI from the trunking, the DCI scheduling a first TB in a DL and including a first radio bearer ID for a first or more radio bearers capable of using the first TB. Method 2900 also includes receiving 2904 first data of the first or more radio bearers from the trunking in the first TB.

[0399] In some implementations, method 2900 further includes transmitting configuration information to the cluster defining a first radio bearer ID for a first or more radio bearers.

[0400] In some implementations, method 2900 further includes adjusting the lower-layer processing used by the UE to correspond to a first or more radio bearers for a first TB before receiving the first data.

[0401] In some implementations of method 2900, DCI also schedules a second TB in DL and includes a second radio bearer ID for a second or more radio bearers that can use the second TB, and method 2900 also includes receiving second data from the cluster in the second TB, wherein the first TB and the second TB use the same MAC entity and are received according to different MCS.

[0402] Figure 30 A method 3000 for a UE served by a base station trunking according to an embodiment of this document is illustrated. Method 3000 includes receiving 3002 a first message from the trunking, the first message configuring a CORESET for use by a MAC entity of the trunking. Method 3000 also includes receiving 3004 a second message from the trunking, the second message indicating the maximum number of PDCCHs that can be allocated by the MAC entity in the CORESET per TTI. Method 3000 further includes performing 3006 a PDCCH search in the CORESET during a first TTI to identify up to the maximum number of PDCCHs.

[0403] In some implementations of method 3000, the second message is received in RRC signaling.

[0404] In some implementations of method 3000, the second message is received in the MAC CE.

[0405] In some implementations, method 3000 further includes: receiving a third message from the cluster indicating the actual number of PDCCHs allocated by the MAC entity in the CORESET during the first TTI; and stopping the PDCCH search in the CORESET during the first TTI after identifying the actual number of PDCCHs.

[0406] Figure 31 A method 3100 for a cluster serving a UE according to an embodiment of this document is illustrated. Method 3100 includes transmitting 3102 a first message to the UE, the first message configuring a CORESET for use by a MAC entity of the cluster. Method 3100 also includes transmitting 3104 a second message to the UE, the second message indicating the maximum number of PDCCHs that can be allocated by the MAC entity in the CORESET per TTI. Method 3000 further includes 3106 allocating up to the maximum number of PDCCHs in the CORESET by the MAC entity in the first TTI.

[0407] In some implementations of method 3100, the second message is transmitted in RRC signaling.

[0408] In some implementations of method 3100, the second message is transmitted in the MAC CE.

[0409] In some implementations, method 3100 further includes transmitting a third message to the UE, the third message indicating the actual number of PDCCHs allocated by the MAC entity in the CORESET during the first TTI.

[0410] Figure 32 An example architecture of a wireless communication system 3200 according to an embodiment disclosed herein is illustrated. The following description is provided for an example wireless communication system 3200 operating in conjunction with LTE system standards and / or 5G or NR system standards provided by 3GPP technical specifications.

[0411] like Figure 32 As shown, the wireless communication system 3200 includes UE 3202 and UE 3204 (but any number of UEs may be used). In this example, UE 3202 and UE 3204 are exemplified as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.

[0412] UE 3202 and UE 3204 can be configured to communicatively couple with RAN 3206. In an implementation, RAN 3206 can be NG-RAN, E-UTRAN, etc. UE 3202 and UE 3204 utilize connections (or channels) with RAN 3206 (shown as connection 3208 and connection 3210, respectively), each of these connections including a physical communication interface. RAN 3206 may include one or more base stations (such as base station 3212 and base station 3214) implementing connection 3208 and connection 3210.

[0413] In this example, Connection 3208 and Connection 3210 are air interfaces that enable this type of communication coupling and can conform to the RAT used by RAN 3206, such as LTE and / or NR, for example.

[0414] In some implementations, UE 3202 and UE 3204 can also directly exchange communication data via sidelink interface 3216. UE 3204 is shown configured to access an access point (shown as AP 3218) via connection 3220. By way of example, connection 3220 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, while AP 3218 may include Wi-Fi. ® Router. In this example, AP 3218 can connect to another network (e.g., the Internet) without going through CN 3224.

[0415] In the implementation, UE 3202 and UE 3204 may be configured to communicate with each other or with base station 3212 and / or base station 3214 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication technologies, such as but not limited to orthogonal frequency division multiple access (OFDMA) communication technology (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication technology (e.g., for uplink and ProSe or sidelink communication), but the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0416] In some implementations, all or some of the base stations in base station 3212 or base station 3214 may be implemented as one or more software entities running on a server computer as part of a virtual network. Furthermore, or in other implementations, base station 3212 or base station 3214 may be configured to communicate with each other via interface 3222. In implementations where the wireless communication system 3200 is an LTE system (e.g., when CN 3224 is an EPC), interface 3222 may be an X2 interface. This X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to the EPC and / or between two eNBs connected to the EPC. In implementations where the wireless communication system 3200 is an NR system (e.g., when CN 3224 is a 5GC), interface 3222 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs, etc.) connected to the 5GC, between a base station 3212 (e.g., a gNB) connected to the 5GC and an eNB, and / or between two eNBs connected to the 5GC (e.g., CN 3224).

[0417] RAN 3206 is shown communicatively coupled to CN 3224. CN 3224 may include one or more network elements 3226 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of UE 3202 and UE 3204) connected to CN 3224 via RAN 3206. Components of CN 3224 may be implemented in a single physical device or a separate physical device including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media).

[0418] In the implementation scheme, CN 3224 may be an EPC, and RAN 3206 may be connected to CN 3224 via S1 interface 3228. In the implementation scheme, S1 interface 3228 may be divided into two parts: an S1 user plane (S1-U) interface carrying service data between base station 3212 or base station 3214 and the serving gateway (S-GW), and an S1-MME interface serving as the signaling interface between base station 3212 or base station 3214 and the mobility management entity (MME).

[0419] In the implementation scheme, CN 3224 may be a 5GC, and RAN 3206 may be connected to CN 3224 via NG interface 3228. In the implementation scheme, NG interface 3228 may be divided into two parts: an NG user plane (NG-U) interface carrying service data between base station 3212 or base station 3214 and user plane function (UPF), and an S1 control plane (NG-C) interface serving as the signaling interface between base station 3212 or base station 3214 and access and mobility management function (AMF).

[0420] Generally, application server 3230 can be a component that provides Internet Protocol (IP) bearer resources (e.g., packet-switched data services) for use with CN 3224. Application server 3230 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE 3202 and UE 3204 via CN 3224. Application server 3230 can communicate with CN 3224 via IP communication interface 3232.

[0421] Figure 33 A system 3300 for executing signaling 3334 between a wireless device 3302 and a network device 3318 according to an embodiment disclosed herein is illustrated. System 3300 may be part of a wireless communication system as described herein. Wireless device 3302 may be, for example, a UE (User Equipment) of a wireless communication system. Network device 3318 may be, for example, a base station (e.g., an eNB or gNB) of a wireless communication system.

[0422] Wireless device 3302 may include one or more processors 3304. Processor 3304 is executable with instructions that cause various operations of wireless device 3302 to be performed as described herein. Processor 3304 may include one or more baseband processors, which may be implemented using, for example, a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), controller, field-programmable gate array (FPGA) device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0423] Wireless device 3302 may include memory 3306. Memory 3306 may be a non-transitory computer-readable storage medium that stores instructions 3308, which may include, for example, instructions executed by processor 3304. Instructions 3308 may also be referred to as program code or computer program. Memory 3306 may also store data used by processor 3304 and results calculated by the processor.

[0424] Wireless device 3302 may include one or more transceivers 3310, which may include radio frequency (RF) transmitter circuitry and / or receiver circuitry, which use antenna 3312 of wireless device 3302 to facilitate signaling (e.g., signaling 3334) to and / or from wireless device 3302 and other devices (e.g., network device 3318) in accordance with a corresponding RAT.

[0425] Wireless device 3302 may include one or more antennas 3312 (e.g., one, two, four, or more antennas). For embodiments with multiple antennas 3312, wireless device 3302 can fully utilize the spatial diversity of such multiple antennas 3312 to transmit and / or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, multiple-input multiple-output (MIMO) behavior (referring to multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmission performed by wireless device 3302 can be achieved based on pre-decoding (or digital beamforming) applied at wireless device 3302, which multiplexes data streams across antennas 3312 according to known or assumed channel characteristics, such that each data stream is received with appropriate signal strength relative to the other streams and at a desired location in the spatial domain (e.g., the location of the receiver associated with that data stream). Some implementations may use a single-user MIMO (SU-MIMO) approach (where all data streams are directed to a single receiver) and / or a MU-MIMO approach (where individual data streams can be directed to individual (different) receivers at different locations in the airspace).

[0426] In some implementations with multiple antennas, wireless device 3302 can implement analog beamforming technology, thereby relatively adjusting the phase of the signal transmitted by antenna 3312 so that the (joint) transmission of antenna 3312 can be directed (this is sometimes called beam control).

[0427] Wireless device 3302 may include one or more interfaces 3314. Interfaces 3314 can be used to provide input to or output to wireless device 3302. For example, wireless device 3302 as a UE may include interfaces 3314, such as microphones, speakers, touchscreens, and buttons, to allow users of the UE to input to and / or output to the UE. Other interfaces of such a UE may consist of transmitters, receivers, and other circuitry that allow communication between the UE and other devices (e.g., in addition to the transceiver 3310 / antenna 3312 already described), and may be compatible with known protocols (e.g., Wi-Fi). ® and Bluetooth ® (etc.) to perform the operation.

[0428] Wireless device 3302 may include MAC entity module 3316. MAC entity module 3316 may be implemented via hardware, software, or a combination thereof. For example, MAC entity module 3316 may be implemented as a processor, circuitry, and / or instructions 3308 stored in memory 3306 and executed by processor 3304. In some examples, MAC entity module 3316 may be integrated within processor 3304 and / or transceiver 3310. For example, MAC entity module 3316 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 3304 or transceiver 3310.

[0429] The MAC entity module 3316 can be used in various aspects of this disclosure, for example, Figures 1 to 31 In all aspects. The MAC entity module 3316 can be configured to enable the wireless device 3302 to establish, create, activate and / or use MAC entities with respect to the base station serving the wireless device 3302 in one or more ways discussed herein.

[0430] Network device 3318 may include one or more processors 3320. Processor 3320 is executable instructions that cause various operations of network device 3318 to be performed as described herein. Processor 3320 may include one or more baseband processors, which are implemented using, for example, a CPU, DSP, ASIC, controller, FPGA device, another hardware device, firmware device, or any combination thereof configured to perform the operations described herein.

[0431] Network device 3318 may include memory 3322. Memory 3322 may be a non-transitory computer-readable storage medium that stores instructions 3324, which may include, for example, instructions executed by processor 3320. Instructions 3324 may also be referred to as program code or computer program. Memory 3322 may also store data used by processor 3320 and results calculated by the processor.

[0432] Network device 3318 may include one or more transceivers 3326, which may include RF transmitter circuitry and / or receiver circuitry that uses the antenna 3328 of network device 3318 to facilitate signaling (e.g., signaling 3334) to and / or from network device 3318 and other devices (e.g., wireless device 3302) in accordance with a corresponding RAT.

[0433] Network device 3318 may include one or more antennas 3328 (e.g., one, two, four or more). In embodiments having multiple antennas 3328, network device 3318 may perform MIMO, digital beamforming, analog beamforming, beam control, etc., as described.

[0434] Network device 3318 may include one or more interfaces 3330. Interfaces 3330 can be used to provide input to or output to network device 3318. For example, network device 3318 as a base station may include interfaces 3330 consisting of transmitters, receivers, and other circuitry (e.g., in addition to the transceiver 3326 / antenna 3328 already described), which enable the base station to communicate with other equipment in the core network and / or enable the base station to communicate with external networks, computers, databases, etc., for the purpose of performing operations, management, and maintenance of the base station or other equipment operatively connected to the base station.

[0435] Network device 3318 may include MAC entity module 3332. MAC entity module 3332 may be implemented via hardware, software, or a combination thereof. For example, MAC entity module 3332 may be implemented as a processor, circuitry, and / or instructions 3324 stored in memory 3322 and executed by processor 3320. In some examples, MAC entity module 3332 may be integrated within processor 3320 and / or transceiver 3326. For example, MAC entity module 3332 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuitry) within processor 3320 or transceiver 3326.

[0436] The MAC entity module 3332 can be used in various aspects of this disclosure, for example, Figures 1 to 31 In all aspects. The MAC entity module 3332 can configure the network device 3318 to establish, create, activate and / or use MAC entities with respect to a UE serving a cluster of base stations including the network device 3318 in one or more ways discussed herein.

[0437] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of any one or more of methods 2200, 2400, 2700, 2900, and / or 3000. The apparatus may be, for example, a UE (such as wireless device 3302 as a UE, as described herein).

[0438] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions for causing the electronic device to perform one or more elements of any one or more of methods 2200, 2400, 2700, 2900, and / or 3000 when executed by one or more processors of the electronic device. The non-transitory computer-readable medium may, for example, be a memory of the UE (such as memory 3306 of a wireless device 3302 serving as a UE, as described herein).

[0439] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of any one or more of methods 2200, 2400, 2700, 2900, and / or 3000. The apparatus may be, for example, a UE (such as wireless device 3302 as a UE, as described herein).

[0440] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of any one or more of method 2200, method 2400, method 2700, method 2900, and / or method 3000. The apparatus may be, for example, a UE (such as wireless device 3302 as a UE, as described herein).

[0441] The implementation scheme envisioned herein includes a signal as described in or associated with one or more elements of any one or more of methods 2200, 2400, 2700, 2900, and / or 3000.

[0442] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution by a processor will cause the processor to perform one or more elements of any one or more of method 2200, method 2400, method 2700, method 2900, and / or method 3000. The processor may be a processor of the UE (such as processor 3304 as a wireless device 3302 of the UE, as described herein). These instructions may, for example, be located in the processor and / or in the memory of the UE (such as memory 3306 as a wireless device 3302 of the UE, as described herein).

[0443] The embodiments contemplated herein include an apparatus comprising components for performing one or more elements of any one or more of methods 2000, 2100, 2300, 2500, 2600, 2800, and / or 3100. The apparatus may be, for example, an apparatus for one or more base stations (such as network device 3318 as a base station, as described herein).

[0444] The embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions for causing the electronic device to perform one or more elements of any one or more of method 2000, method 2100, method 2300, method 2500, method 2600, method 2800, and / or method 3100 when executed by one or more processors of the electronic device. The non-transitory computer-readable medium may, for example, be the memory of one or more base stations (such as memory 3322 of network device 3318 as a base station, as described herein).

[0445] The embodiments contemplated herein include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of any one or more of methods 2000, 2100, 2300, 2500, 2600, 2800, and / or 3100. The apparatus may be, for example, an apparatus for one or more base stations (such as network device 3318 as a base station, as described herein).

[0446] The embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of any one or more of method 2000, method 2100, method 2300, method 2500, method 2600, method 2800, and / or method 3100. The apparatus may be, for example, an apparatus for one or more base stations (such as network device 3318 as a base station, as described herein).

[0447] The implementation scheme envisioned herein includes a signal as described in or associated with one or more elements of any one or more of methods 2000, 2100, 2300, 2500, 2600, 2800, and / or 3100.

[0448] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform one or more elements of any one or more of method 2000, method 2100, method 2300, method 2500, method 2600, method 2800, and / or method 3100. The processor may be a processor of one or more base stations (such as processor 3320 of network device 3318 as a base station, as described herein). These instructions may, for example, be located in the processor and / or in the memory of one or more base stations (such as memory 3322 of network device 3318 as a base station, as described herein).

[0449] For one or more embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a baseband processor as described herein in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein. Similarly, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples illustrated herein.

[0450] Unless otherwise expressly stated, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustrative and descriptive information, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice with various embodiments.

[0451] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical parts for performing the operations; or may include a combination of hardware, software, and / or firmware.

[0452] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is contemplated that parameters, attributes, aspects, etc., of one implementation may be used in another. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that, unless expressly stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0453] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0454] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope and equivalents of the appended claims.

Claims

1. A method for executing a Layer 3 (L3) scheduler in a cluster of base stations serving a user equipment (UE) for a wireless communication system with Radio Link Control (RLC) to Media Access Control (MAC) edge activation, the method comprising: Activate the first edge between the first MAC entity and the first RLC entity used by the first radio bearer during the first transmission time interval (TTI); as well as Based on the activation of the first edge, the use of a first sub-cluster of the cluster corresponding to the base station of the first RLC is scheduled during the first TTI to transmit the first data of the first radio bearer between the first RLC entity and the first MAC entity during the first TTI.

2. The method of claim 1, further comprising activating a second edge between the first RLC entity and the second MAC entity within the first TTI, wherein the scheduling of the use of the first sub-cluster during the first TTI is also used to transmit second data of the first radio bearer between the first RLC entity and the second MAC entity during the first TTI based on the activation of the second edge.

3. The method according to claim 1, further comprising: Activate the second edge between the first MAC entity and the second RLC entity used by the second radio bearer within the first TTI; as well as Based on the activation of the second edge, during the first TTI, a second sub-cluster of the base station corresponding to the second RLC entity of the cluster is scheduled to transmit the second data of the second radio bearer between the second RLC entity and the first MAC entity during the first TTI.

4. The method of claim 3, further comprising configuring each of the first RLC entity and the second RLC entity to use the same modulation and decoding scheme (MCS) for the transport block (TB) of the first MAC entity during the first TTI.

5. The method according to claim 1, further comprising: Activate the second edge between the second MAC entity and the second RLC entity used by the second radio bearer within the first TTI; as well as Based on the activation of the second edge, during the first TTI, the second sub-cluster of the cluster corresponding to the second RLC entity is scheduled to transmit the second data of the second radio bearer between the second RLC entity and the second MAC entity during the first TTI.

6. The method according to claim 1, further comprising: The first edge is deactivated during the second TTI; Activate the second edge between the first RLC entity and the second MAC entity during the second TTI; as well as The first sub-cluster is scheduled during the second TTI based on the activation of the second edge to transmit the second data of the first radio bearer between the first RLC entity and the second MAC entity during the second TTI.

7. The method of claim 1, further comprising determining that a first transport block (TB) of the first MAC entity can satisfy one of a first quality of service (QoS) policy and a first link adaptation (LA) policy for the first radio bearer during the first TTI, wherein the activation of the first edge is based on the determination that the first TB of the first MAC entity can satisfy one of the first quality of service (QoS) policy and the first LA policy for the first radio bearer during the first TTI.

8. The method according to claim 7, further comprising: Determine that the second TB of the second MAC entity can satisfy one of the second QoS policy and the second LA policy for the second radio bearer during the first TTI; as well as Based on the determination that the second TB of the second MAC entity can satisfy one of the second QoS policy and the second LA policy for the second radio bearer during the first TTI, the second edge between the second MAC entity and the second RLC entity used by the second radio bearer is activated within the first TTI.

9. A method for providing user equipment (UE) with trunking services from a base station, the method comprising: Generate a capability message indicating the first maximum number of transport blocks (TBs) supported at the UE during a single TTI; as well as Send the capability message to the cluster.

10. The method of claim 9, wherein the first maximum number of TBs is for uplink (UL), and wherein the capability message further indicates a second maximum number of TBs supported at the UE during the single TTI for downlink (DL).

11. The method of claim 9, wherein the capability message further indicates the maximum data size for each TB in the TB.

12. The method of claim 9, wherein the capability message further indicates the maximum data size for the total TB.

13. A method for a cluster of base stations serving a user equipment (UE), the method comprising: Receive from the UE a capability message indicating the first maximum number of transport blocks (TBs) supported at the UE during a single TTI; as well as In response to receiving the capability message, perform Media Access Control (MAC) scheduling within the maximum number of TBs.

14. The method of claim 13, wherein the first maximum number of TBs is for uplink (UL), and wherein the capability message further indicates a second maximum number of TBs supported at the UE during the single TTI for downlink (DL).

15. The method of claim 13, wherein the capability message further indicates the maximum data size for each TB in the TB.

16. The method of claim 13, wherein the capability message further indicates the maximum data size for the total TB.

17. A method for a cluster of base stations serving a user equipment (UE), the method comprising: Downlink control information (DCI) is transmitted to the UE, the downlink control information (DCI) scheduling a first transport block (TB) in the downlink (DL) and including a first radio bearer identifier (ID) that identifies a first or more radio bearers that can use the first TB. as well as The first data of the first one or more radio bearers is transmitted to the UE in the first TB.

18. The method of claim 17, further comprising receiving configuration information from the UE defining the first radio bearer ID as being for the first one or more radio bearers.

19. The method of claim 17, further comprising, prior to transmitting the first data, adjusting a lower-level processing procedure used by the cluster to correspond to the one or more radio bearers for the first TB.

20. The method of claim 17, wherein the DCI further schedules a second TB in the DL and includes a second radio bearer ID identifying a second or more radio bearers capable of using the second TB, and the method further includes: In the second TB, the second data of the second or more radio bearers is transmitted to the UE. The first TB and the second TB are generated by the same MAC entity according to different modulation and decoding schemes (MCS).

21. A method for user equipment (UE) served by a base station trunking system, the method comprising: Receive downlink control information (DCI) from the cluster to schedule the first transport block (TB) in the uplink (UL); Uplink control information (UCI) is transmitted to the cluster, the uplink control information (UCI) including a first radio bearer identifier (ID) for a first one or more radio bearers that can use the first TB. as well as The first data of the first one or more radio bearers is transmitted to the cluster in the first TB.

22. The method of claim 21, further comprising transmitting to the cluster configuration information defining the first radio bearer ID as being for the first one or more radio bearers.

23. The method of claim 21, further comprising, prior to transmitting the first data, adjusting a lower-layer processing procedure used by the UE to correspond to the one or more radio bearers for the first TB.

24. The method of claim 21, wherein the DCI further schedules a second TB in the UL, and wherein the UCI includes a second radio bearer ID for a second or more radio bearers capable of using the second TB, and the method further includes: In the second TB, the second data of the second or more radio bearers is transmitted to the cluster. The first TB and the second TB are generated by the same MAC entity according to different modulation and decoding schemes (MCS).

25. A method for a cluster of base stations serving a user equipment (UE), the method comprising: Transmit downlink control information (DCI) to the UE for scheduling the first transport block (TB) in the uplink (UL); The UE receives uplink control information (UCI), which includes a first radio bearer identifier (ID) for a first or more radio bearers capable of using the first TB. as well as In the first TB, the first data of the one or more radio bearers is received from the UE.

26. The method of claim 25, further comprising receiving configuration information from the UE defining the first radio bearer ID as being for the first one or more radio bearers.

27. The method of claim 25, further comprising, prior to receiving the first data, adjusting a lower-level processing procedure used by the cluster to correspond to the one or more radio bearers for the first TB.

28. The method of claim 25, wherein the DCI further schedules a second TB in the UL, and wherein the UCI includes a second radio bearer ID for a second or more radio bearers capable of using the second TB, and the method further includes: In the second TB, second data of the second or more radio bearers is received from the UE. The first TB and the second TB are received by the same MAC entity but according to different modulation and decoding schemes (MCS).

29. A method for user equipment (UE) being served by a base station trunking system, the method comprising: The cluster receives downlink control information (DCI) that schedules a first transport block (TB) in the downlink (DL) and includes a first radio bearer identifier (ID) for a first or more radio bearers that can use the first TB. as well as The first data of the first one or more radio bearers is received from the cluster in the first TB.

30. The method of claim 29, further comprising transmitting to the cluster configuration information defining the first radio bearer ID as being for the first one or more radio bearers.

31. The method of claim 29, further comprising, prior to receiving the first data, adjusting a lower-layer processing procedure used by the UE to correspond to the first one or more radio bearers for the first TB.

32. The method of claim 29, wherein the DCI further schedules a second TB in the DL and includes a second radio bearer ID for a second or more radio bearers capable of using the second TB, and the method further includes: In the second TB, second data is received from the cluster from the second or more radio bearers. The first TB and the second TB use the same MAC entity but are received according to different modulation and decoding schemes (MCS).

33. A method for providing user equipment (UE) with trunking services from a base station, the method comprising: Receive a first message from the cluster, the first message configuring a control resource set (CORESET) for use by the cluster's media access control (MAC) entity; A second message is received from the cluster, indicating the maximum number of Physical Downlink Control Channels (PDCCHs) that can be allocated by the MAC entity in the CORESET per Transmission Time Interval (TTI); and In the first TTI, a PDCCH search is performed in the CORESET to identify up to the maximum number of PDCCHs.

34. The method of claim 33, wherein the second message is received in Radio Resource Control (RRC) signaling.

35. The method of claim 33, wherein the second message is received in a MAC control element (MAC CE).

36. The method according to claim 33, further comprising: A third message is received from the cluster, the third message indicating the actual number of PDCCHs allocated by the MAC entity in the CORESET during the first TTI; as well as After identifying the actual number of PDCCHs, the PDCCH search in the CORESET is stopped in the first TTI.

37. A method for a cluster of base stations serving a user equipment (UE), the method comprising: A first message is transmitted to the UE, the first message configuring a control resource set (CORESET) for use by the media access control (MAC) entity of the cluster; A second message is transmitted to the UE, the second message indicating the maximum number of physical downlink control channels (PDCCH) that can be allocated by the MAC entity in the CORESET per transmission time interval (TTI); as well as The MAC entity allocates up to the maximum number of PDCCHs in the CORESET during the first TTI.

38. The method of claim 37, wherein the second message is transmitted in Radio Resource Control (RRC) signaling.

39. The method of claim 37, wherein the second message is transmitted in a MAC control element (MAC CE).

40. The method of claim 37, further comprising transmitting a third message to the UE, the third message indicating the actual number of PDCCHs allocated by the MAC entity in the CORESET during the first TTI.

41. An apparatus comprising components for performing the method according to any one of claims 1 to 40.

42. A computer-readable medium comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 40.

43. An apparatus comprising a logic component, module, or circuit for performing the method according to any one of claims 1 to 40.

Images