Logical channel prioritization management in a network

Abstract

Provided are apparatus, method, and device for automatically managing logical channel prioritization (LCP). According to example embodiments, the system may include a base station that may be configured to: determine, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

Description

LOGICAL CHANNEL PRIORITIZATION MANAGEMENT IN A NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No.63 / 754,788, filed with the U.S. Patent and Trademark Office on February 6, 2025, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to the management of logical channel prioritization (LCP) in a telecommunications network.BACKGROUND

[0003] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] Logical channel prioritization (LCP) may refer to a set of rules and policies specifying the prioritization of logical channels for transmission of data to a physical channel. Such prioritization may enable scheduling and management of data flow as part of the data transmission process of a network, since a physical channel may not have enough resources to accommodate for all data from all logical channels at once.SUMMARY

[0005] Example embodiments of the present disclosure automatically manage logical channel prioritization (LCP). As such, example embodiments of the present disclosure may provide a solution to introduce explicit configuration framework (parameters) to define how additional priority is applied, persisted, or revoked across different scheduling conditions.

[0006] According to example embodiments, a system is provided. The system may include a base station that may be configured to: determine, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

[0007] According to example embodiments, a method is provided. The method may include: determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmitting, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

[0008] According to example embodiments, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may have recorded thereon instructions executable by a system to cause the system to perform a method including:determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmitting, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

[0009] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0011] FIG. 1A to FIG. 1C illustrate an example data transmission process with logical channel prioritization (LCP);

[0012] FIG. 2 illustrates a block diagram of an example system configuration for managing logical channel prioritization (LCP) in a network, according to one or more example embodiments;

[0013] FIG. 3 illustrates a flow diagram of an example method for managing logical channel prioritization (LCP), according to one or more example embodiments;

[0014] FIG. 4 illustrates a diagram of example components of a system for implementing one or more example embodiments; and

[0015] FIG. 5 illustrates a diagram of an example of implementation environment in which systems and / or method, described herein, may be implemented.DETAILED DESCRIPTION

[0016] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the present disclosure.

[0017] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods should not limit their implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understoodthat software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0018] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0019] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” (in other words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B. Further still, where only one item is intended, the term “one” or similar language is used.

[0020] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0021] Reference throughout this specification to “one embodiment,” “an embodiment,” “non-limiting exemplary embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0022] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0023] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0024] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (0-RAN) Alliance standard organization, and the like. For instance, the terms “LCP”, “LCH”, “PBR”, “SR”, “BSR”, “MAC CE”, “RRC”, and the like, as well as the associated featuresand operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0025] Further, example embodiments of the present disclosure may apply to any suitable network elements in any suitable telecommunications system, such as a 4G LTE system, 5G system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0026] As described above, logical channel prioritization (LCP) may refer to a set of rules and policies specifying the prioritization of logical channels (LCHs) for transmission of data to a physical channel (PHY).

[0027] In particular, a particular user equipment (UE) may include a plurality of logical channels, which may each contain data (logical channel data) that has to be transmitted through a particular physical channel as part of a data transmission process to the network (e.g., base station). In this regard, the LCP may define the rules and policies specifying the prioritization regarding which data on which logical channels should be transmitted through the particular physical channel first, and which data on which logical channels should be transmitted through the particular physical channel later.

[0028] Since a physical channel may have limited resources where data may be transmitted once in a single transmission time interval (TTI), the above prioritization may be crucial when the physical channel does not have enough resources to accommodate for all data from all logical channels at once.

[0029] It is noted here that the LCP may be configured by the network (e.g., base station) and implemented at a user equipment (UE).

[0030] FIG. 1A to FIG. 1C illustrate an example data transmission process with logical channel prioritization (LCP).

[0031] As shown in FIG. 1A to FIG. 1C, the example data transmission process may include a first logical channel 110, a second logical channel 120, a third logical channel 130, a fourth logical channel 140, and a physical channel 150.

[0032] Here, as shown in FIG. 1A, the first logical channel 110, second logical channel 120, third logical channel 130, and fourth logical channel 140 may include data A 112, data B 122, data C 132, and data D 142 in the respective pipelines of the first logical channel 110, second logical channel 120, third logical channel 130, and fourth logical channel 140. Said data may be transmitted to the physical channel 150 based on the periodization specified by the LCP.

[0033] In this regard, the LCP may specify the prioritization where the first logical channel 110 may have the highest priority, the second logical channel 120 may have the second highest priority, the third logical channel 130 may have the third highest priority, and the fourth logical channel 140 may have the fourth highest priority (lowest priority).

[0034] Accordingly, as shown in FIG. IB, based on the above prioritization, data A 112 in the pipeline of the first logical channel 110 may be transmitted to the physical channel 150 first, followed by data B 122 in the pipeline of the second logical channel 120 and data C 132 in the pipeline of the third logical channel 130.

[0035] Here, after data C 132 in the pipeline of the third logical channel 130 is transmitted to the physical channel 150, the pipeline of the physical channel 150 may be full and data D 142 in the pipeline of the fourth logical channel 140 (which has priority following the third logical channel 130) may have to wait for the subsequent TTI.

[0036] Accordingly, as shown in FIG. 1C, after data A 112, data B 122, and data C 132 in the pipeline of the physical channel 150 are transmitted in the previous TTI, data D 142 in the pipeline of the fourth logical channel 140 may be transmitted to the physical channel 150 at the subsequent TTI, assuming there are no more data in the pipeline of the first logical channel 110, second logical channel 120, and third logical channel 130.

[0037] In this regard, an additional priority may refer to a new (updated) priority that overwrites an original (e.g., default) priority of a particular logical channel when a certain condition is met. The new priority may be higher than the original priority, such that the particular logical channel may have higher priority for a certain period of time.

[0038] Such mechanism may be beneficial when handing delay-critical data, such as XR data (e.g., data associated with immersive technologies such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and the like), where the priority of a particular logical channel may be temporarily increased when there is delay-critical data in its pipeline to ensure that such delay-critical data is timely transmitted.

[0039] Here, the management of LCP and additional priority in the related art may have the following concerns.

[0040] One concern may involve whether the additional priority defined should persist indefinitely or be dynamically adapted based on network conditions. While strict persistence may ensure consistency, a dynamic approach where priority is re-evaluated based on buffer status, remaining delay budget, competing traffic demands, and the like may allow for flexibility and avoiding starvation. Accordingly, a uniform approach may be desirable, where the network maybe allowed to configure additional priority handling to ensure consistent behavior across all user equipment (UEs) while retaining enough flexibility to adapt to different deployment conditions.

[0041] In addition, the control point of the additional priority should be considered (i.e., the UE or the network). The UE-driven adjustments may allow for localized optimizations, reducing signaling overhead, while network / gNodeB-controlled priority scaling may ensure network-wide consistency. There is also the question of interactions with existing scheduling constraints, such as bucket size (Bj) and prioritized bit rate (PBR). Additional priority may allow a UE to send more data than originally allocated, which could impact scheduling fairness if not properly managed.

[0042] To summarize, the absence of clearly defined configuration parameters for additional LCH priority handling could lead to inconsistent implementations across vendors, making scheduling behavior unpredictable and difficult to optimize for network operators.

[0043] Another concern may involve when and how an additional priority of a particular LCH should be revoked or adjusted dynamically. The lack of a clearly defined configuration may lead to issues with fairness and scheduling predictability for vendors, where if a particular LCH retains additional priority beyond what is strictly necessary, other traffic flows may be delayed unnecessarily, leading to unintended resource monopolization. In other words, this may lead to situations where some UEs retain the additional priority for too long, while others drop the additional priority prematurely, affecting quality of service (QoS) consistency across different devices.

[0044] Here, a time-based threshold may be introduced, where priority is gradually reduced after a certain duration, allowing other LCHs to compete for resources. Another approachmay involve tying priority retention to buffer status, where priority persists only if delay-critical data remains in the buffer. An additional complexity may also arise in scenarios where multiple LCHs have additional priority. A rotational fairness mechanism has been discussed, which involves priority shifts between competing LCHs over multiple scheduling intervals, preventing one LCH from monopolizing uplink resources indefinitely.

[0045] To summarize, without clear rules on additional priority persistence, some UEs may retain the additional priority for longer than necessary, while others may drop it prematurely, leading to inconsistent QoS behavior across devices.

[0046] Another concern may involve how additional priority might impact bucket size (Bj) and prioritized bit rate (PBR) constraints, particularly in networks with high congestion or competing traffic flows. In particular, applying additional priority could override Bj or PBR limits, leading to unintended resource monopolization by certain LCHs. This could cause best-effort or lower-priority traffic to be deprioritized indefinitely, creating fairness issues across UEs. Further, buffer status report (BSR)-based scheduling may not accurately reflect the impact of additional priority adjustments. The BSR may report buffer availability to a base station (e.g., gNodeB), but additional priority can alter how much data is actually transmitted, potentially misaligning grant allocation decisions. If the network expects a certain data volume to be transmitted based on BSR, but additional priority allows more data to be scheduled than expected, this can create inefficiencies in grant assignment and overall resource utilization. Accordingly, a structured approach may be beneficial to ensure that additional priority handling does not conflict with Bj, PBR, orBSR-based scheduling.

[0047] Having PBR and Bj remain strictly enforced may ensure that additional priority does not introduce uncontrolled scheduling deviations. Further, PBR constraints may be relaxed dynamically for delay-sensitive LCHs, allowing for short-term priority boosts while still maintaining long-term fairness. There is also discussion on whether Bj should be extended dynamically for priority-extended LCHs, ensuring that priority-extended packets are not prematurely discarded due to Bj expiration.

[0048] To summarize, additional priority handling introduces potential conflicts with Bj and PBR limits, potentially allowing certain LCHs to exceed their originally allocated resources, which could impact fairness and lower-priority traffic scheduling.

[0049] Another concern may involve how PBR and Bj should interact with priority-extended LCHs, particularly in scenarios where multiple high-priority LCHs compete for scheduling opportunities. PBR and Bj are critical mechanisms in uplink scheduling that regulate transmission rate limits and buffer retention policies, ensuring fair and efficient resource distribution among logical channels (LCHs). More specifically, PBR enforces rate-based transmission limits, preventing any single LCH from dominating uplink resource allocation. Further, Bj defines how long buffered data remains eligible for transmission before being discarded. When additional priority is applied, certain LCHs may transmit data later than originally scheduled, increasing the risk that Bj expires before transmission occurs and leading to unexpected data loss. Bj may also experience exhaustion in networks with multiple priority-extended LCHs where, if too many LCHs receive extended Bj, this could reduce scheduling efficiency, making it difficult for lower-priority LCHs to compete for resources, ultimately impacting overall uplink performance.

[0050] Having strict PBR enforcement may ensure that additional priority does not override existing rate controls. Further, delay-sensitive LCHs may be allowed with temporary PBR bypassing, ensuring that time-sensitive data is not constrained by rigid rate limits. A potential compromise may involve introducing a dynamic scaling factor, where priority-extended LCHs can temporarily exceed PBR limits within a defined threshold, balancing fairness and scheduling efficiency. In addition, dynamically adjusting Bj for LCHs with additional priority may allow priority-extended data to remain in the buffer longer. Further, having Bj fixed may ensure that additional priority does not disrupt buffer management policies.

[0051] To summarize, if additional priority is applied without considering PBR, certain LCHs may consume more uplink resources than originally intended, leading to potential scheduling fairness issues. Further, without adjustments, additional priority handling may cause Bj expiration issues, leading to premature data loss despite the LCH being prioritized for transmission.

[0052] Another concern may involve ensuring fairness between high-priority and low-priority LCHs. In particular, while additional priority is intended to enhance scheduling for delaysensitive traffic, it is equally important to prevent it from completely starving lower-priority LCHs. Once an LCH receives additional priority, it may be scheduled indefinitely, while other traffc (e.g., uplink retransmissions, lower-priority QoS flows, best-effort data, etc.) may be delayed indefinitely.

[0053] To summarize, it may be beneficial for additional priority handling to include fairness controls to ensure that lower-priority LCHs are not indefinitely deprioritized, preventing scheduling imbalance within the UE.

[0054] Accordingly, systems, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage logical channel prioritization (LCP).

[0055] According to example embodiments, the system may include a base station that may be configured to receive a delay-critical data notification from a user equipment (UE), which may include information associated with target data in a buffer of a target logical channel at the UE. Here, the target data may be delay-critical. The base station may be further configured to determine whether to increase a priority associated with the target logical channel based on the information associated with target data and a logical channel prioritization (LCP) policy. Accordingly, in response to determining to increase the priority associated with the target logical channel, the base station may be further configured to transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

[0056] Ultimately, example embodiments of the present disclosure automatically manage logical channel prioritization (LCP), which may provide a solution to introduce explicit configuration framework (parameters) to define how additional priority is applied, persisted, or revoked across different scheduling conditions.

[0057] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0058] Further descriptions of the features, components, configuration, operations, and implementations of the system of the present disclosure, according to one or more embodiments, are provided in the following.Example System Architecture

[0059] FIG. 2 illustrates a block diagram of an example system configuration 200 for managing logical channel prioritization (LCP) in a network, according to one or more example embodiments.

[0060] As illustrated in FIG. 2, system configuration 200 may include a base station 210 and a user equipment (UE) 220, although it is contemplated that the system architecture may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, the present disclosure may include any number of UEs.

[0061] The base station 210 may include base stations in a network, such as a cell (e.g., super cell, a macro cell, a small cell, a femto cell, a pico cell, etc.), a node (e.g., a NodeB, an eNodeB (eNB), a gNodeB (gNB), etc.), a radio unit (RU) under radio access network (RAN), a distributed unit (DU) under radio access network (RAN), a centralized unit (CU) under radio access network (RAN), a carrier, a component carrier, a sector, and the like.

[0062] The UE 220 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), a SIM-based device, or a similar device.

[0063] According to example embodiments, the UE 220 may include a device operated by a user and configured to implement an XR technology or to run an XR application. In particular, the XR may refer to a collective term used to describe immersive technologies such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and the like, which may provide immersive experiences to the user by either blending real and virtual worlds together, or by creating a fullyimmersive virtual experience. For example, the UE 220 may include a smartphone, a tablet, a camera, a headset, and the like.

[0064] The UE 220 may also be communicatively coupled to the base station 210 in order to transmit and receive various kinds of data, such as data associated with DSR and operations related to the XR technology / XR application.

[0065] In this regard, the UE 220 may include a plurality of logical channels (LCHs) and a physical channel (PHY), and may be configured to transmit data through the plurality of LCHs and the PHY to the base station 210 under LCP, in the similar manner as described above in relation to FIG. 1 A to FIG. 1C. Here, the rules and configurations associated with the LCP may be configured by the base station 210, which may be transmitted to the UE 220 for implementation at the UE 220.

[0066] According to example embodiments, the UE 220 and the base station 210 may include an apparatus, a system, a platform, a module, or the like, which may be configured to perform one or more operations or actions for managing logical channel prioritization (LCP) in a network. Example operations performable by the base station 210 for managing the LCP are described below with reference to FIG. 3.Example Operations for Managing Logical Channel Prioritization in the Present Disclosure

[0067] In the following, several example operations are performable by the system of one or more example embodiments of the present disclosure are described with reference to FIG. 3.

[0068] FIG. 3 illustrates a flow diagram of an example method 300 for managing logical channel prioritization (LCP), according to one or more example embodiments. One or moreoperations in method 300 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage LCP.

[0069] According to example embodiments, the system may include a base station. It is noted that, while the below descriptions are provided from the perspective of the base station, the present disclosure is not limited thereto and may encompass corresponding operations from the perspective of the UE.

[0070] As illustrated in FIG. 3, at operation S310, the system may be configured to receive a delay-critical data notification. The delay-critical data notification may be received from a user equipment (UE), and may include information associated with target data in a buffer of a target logical channel at the UE.

[0071] In particular, the UE may include the plurality of logical channels, and may have data that is in a buffer (pipeline) of one of the plurality of logical channels. Said data may be referred to as target data, and said one of the plurality of logical channels may be referred to as the target logical channel. In this regard, the UE may transmit the delay-critical data notification to the system (e.g., base station) to provide information regarding the target data, before the target data is transmitted to the physical channel and subsequently to the system.

[0072] Here, the information associated with target data may include any kind of information, such as a type of the target data, an identification of the target logical channel (i.e., the logical channel which the target data is in), a default priority of the target logical channel, whether the target data is delay-critical, and the like.

[0073] Further, the UE may implement logical channel prioritization (ECP) specifying various priorities associated with the plurality of logical channels. The priorities associated withthe plurality of logical channels implemented at the UE may have default values (values initially / previously configured by the system / base station).

[0074] For example, the UE may implement a first logical channel, a second logical channel, and a third logical channel, where the first logical channel, the second logical channel, and the third logical channel may have default priorities of values 1, 2, and 3 respectively (1 indicating highest priority and 3 indicating lowest priority).

[0075] According to example embodiments, the target data may be delay-critical (i.e., data which relevance is affected by time). The method then proceeds to operation S320.

[0076] At operation S320, the system may be configured to determine whether to increase a priority associated with the target logical channel. The system may determine whether to increase the priority associated with the target logical channel based on the information associated with target data and a logical channel prioritization (LCP) policy.

[0077] In particular, the system may be configured to determine whether the target data is delay-critical based on the information associated with target data included in the delay-critical data notification.

[0078] In response to determining that the target data is delay-critical, the system may be configured to determine whether to increase the priority associated with the target logical channel based on the information associated with target data and the LCP policy.

[0079] The LCP policy may specify rules and policies regarding changes to priorities of various LCHs based on various criteria. According to example embodiments, the LCP may include a mapping between different values of priority and different levels of network conditions.

[0080] For example, the system may determine the current level of network conditions (e.g., traffic congestion levels, quality of service (QoS) level, etc.), and identify a value of priority corresponding to the determined current level of network conditions based on the mapping specified in the LCP policy. In this regard, if the identified value of priority is higher than the default value of priority associated with the target logical channel, the system may determine to increase the priority associated with the target logical channel to correspond to the identified value.

[0081] In this regard, in response to determining to increase the priority associated with the target logical channel, the method then proceeds to operation S330. On the other hand, in response to determining to not increase the priority associated with the target logical channel, the method may end.

[0082] At operation S330, the system may be configured to transmit a logical channel priority increase request. The logical channel priority increase request may be transmitted to the UE, and may include a request to increase the priority associated with the target logical channel.

[0083] For example, if the identified value of priority is 1 which is higher than the default value of priority associated with the third logical channel (the target logical channel) of 3, the system may determine to increase the priority associated with the third logical channel to value 1. Accordingly, the system may transmit the logical channel priority increase request to increase the priority associated with the third logical channel to 1.

[0084] According to example embodiments, the logical channel priority increase request may include a persistence configuration. The persistence configuration may define a persistency of the increased priority (additional priority) associated with the target logical channel. In other words, the persistence configuration may specify the manner which the increased priorityassociated with the target logical channel should persist at the UE (e.g., the manner which the third logical channel should persist at priority value 1 before reverting to default priority value 3).

[0085] According to example embodiments, the persistence configuration may define at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.

[0086] In particular, the persistence configuration may define that the increased priority associated with the target logical channel is static, which may indicate that the increased priority associated with the target logical channel should persist indefinitely. Alternatively, the persistence configuration may define that the increased priority associated with the target logical channel is dynamic based on network conditions, which may indicate that the increased priority associated with the target logical channel should change based on the network conditions. To this end, the persistence configuration may include a priority persistence mode parameter, which may indicate whether the increased priority associated with the target logical channel is static or dynamic.

[0087] Further, the persistence configuration may define the expiration of the increased priority associated with the target logical channel. The expiration may be defined, for example as time period (e.g., the increased priority associated with the target logical channel should persist for 20ms before reverting to the default priority value). To this end, the persistence configuration may include an expiration threshold parameter, which may indicate the expiration of the increased priority associated with the target logical channel. This may ensure that the target logical channel does not retain the increased priority longer than needed.

[0088] Furthermore, the persistence configuration may define that the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission. Here, the increased priority may be maintained only for HARQ transmissions that meet delay-critical thresholds.

[0089] According to example embodiments, the logical channel priority increase request may include a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel. In particular, according to example embodiments, the PBR configuration may include a priority bypass PBR parameter, which may define whether the increased priority (additional priority) can bypass PBR constraints under certain conditions (e.g., when and how additional priority can exceed PBR constraints). According to example embodiments, the PBR configuration may also include a PBR scaling factor parameter, which may define a temporary increase of PBR for priority-extended logical channels. This may ensure that delay-sensitive traffic is not unnecessarily restricted.

[0090] According to example embodiments, the logical channel priority increase request may include a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel. In particular, according to example embodiments, the Bj configuration may include a priority buffer extension factor parameter, which may define extension of the Bj dynamically for logical channels with additional priority. This may ensure that delay-critical data is not prematurely discarded before it can be scheduled. According to example embodiments, the Bj configuration may also include a maximum Bj extension limit parameter, which may define the maximum limit of the Bj extension. This may prevent Bj from extending indefinitely and ensuring scheduling fairness across multiple LCHs.

[0091] According to example embodiments, the logical channel priority increase request may include a fairness threshold. The fairness threshold may define a limit on the number of consecutive TTIs the target logical channel can retain additional priority before other logical channels are scheduled. This may ensure that even when additional priority is applied, lower-priority traffic is not completely blocked from uplink scheduling.

[0092] According to example embodiments, the logical channel priority increase request may include a traffic scaling mechanism. The traffic scaling mechanism may define rules and policies for scaling down additional priority of the target logical channel when lower-priority logical channels accumulate significant buffered data, preventing best-effort traffic from being completely blocked. Based on the traffic scaling mechanism, the UE may automatically scale down additional priority when lower-priority logical channels have accumulated a certain amount of backlogged data. This may prevent situations where best-effort traffic remains unscheduled for extended periods, ensuring better overall scheduling balance.

[0093] According to example embodiments, the logical channel priority increase request may include a logical channel balancing rule. The logical channel balancing rule may define rules and policies for ensuring that priority handling is distributed fairly among different logical channels within the UE.

[0094] According to example embodiments, the logical channel priority increase request may be transmitted via radio resource control (RRC) signaling. In this regard, according to example embodiments, the RRC signaling format may include a priority service mapping parameter defining which network conditions (e g., QoS) levels map to additional priority. According to example embodiments, the RRC signaling format may also include a priority scalefactor parameter defining dynamic priority adjustments based on QoS requirements. According to example embodiments, the RRC signaling format may also include a priority congestion scaling factor parameter defining dynamic scaling of priority thresholds.

[0095] According to example embodiments, the logical channel priority increase request may be transmitted via medium access control (MAC) control element (CE). In this regard, according to example embodiments, the MAC CE format may include a priority persistent indicator defining whether the increased priority associated with the target logical channel is persistent across HARQ retransmission. According to example embodiments, the MAC CE format may include a priority adjusted BSR parameter indicating the changes in Bj and / or PBR handling. According to example embodiments, the MAC CE format may include a BSR priority indicator enabling distinguishing between priority-extended and normal buffer reports.

[0096] Accordingly, in response to receiving the logical channel priority increase request, the UE may increase the priority associated with the target logical channel based on the logical channel priority increase request. Further, the UE may retain the increased priority associated with the target logical channel based on the persistence configuration. Furthermore, the UE may extend the PBR and / or the Bj based on the PBR configuration and Bj configuration.

[0097] Upon performing operation S330, the method 300 may be ended or be terminated. Alternatively, method 300 may return to operation S310, such that the at least one processor may be configured to repeatedly perform, for at least a predetermined amount of time, the receiving the delay-critical data notification (at operation S310), the determining whether to increase the priority (at operation S320), and the transmitting the logical channel priority increase request (at operation S330).

[0098] For example, operations S310 to S330 may be performed for multiple logical channels (i.e., multiple target logical channels), where the UE may have multiple logical channels with additional priority (increased value of priority). In this regard, according to example embodiments, the system may implement a fairness rotation mechanism in order to ensure equitable scheduling access. In particular, the fairness rotation mechanism may define priority shifts between competing multiple logical channels over multiple scheduling intervals, preventing one logical channel from monopolizing uplink resources indefinitely.

[0099] Accordingly, the above processes provide a solution to introduce explicit configuration framework (parameters) to define how additional priority is applied, persisted, or revoked across different scheduling conditions. These parameters may be configurable via RRC signaling, allowing networks to dynamically control additional LCH priority handling based on real-time traffic demands.

[0100] In particular, the above processes may provide a mechanism that allows additional priority handling to be mapped to predefined QoS configurations, ensuring consistency in traffic scheduling. The above processes may also allow priority levels to be dynamically adjusted based on network conditions, ensuring fair scheduling in high-load scenarios. The above processes may also ensure that BSR remains aligned with additional priority-based Bj / PBR changes, preventing mismatches in scheduling behavior. The above processes may also ensure that priority handling is distributed fairly among different logical channels within a UE, preventing a single LCH from monopolizing uplink resources.Various Aspects of Embodiments

[0101] In view of the above, example embodiments of the present disclosure may provide a solution to introduce explicit configuration framework (parameters) to define how additional priority is applied, persisted, or revoked across different scheduling conditions.

[0102] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0103] Some embodiments may relate to a system, a method, and / or a computer readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

[0104] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory(SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0105] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0106] Computer readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the"C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0107] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0108] The computer readable program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0109] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a microservice(s) module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0110] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software.The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code-it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0111] One or more components of the system of the example embodiments (e.g., base station, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG.3, etc.), may be implemented in one or more systems, devices, or hardware components, such as one or more servers, and the like. In the following, descriptions of a system in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more operations or methods described above with reference to FIG. 3 may be performed by the system. For instance, the one or more operations or methods may be performed by at least one processor of the system upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the system.

[0112] FIG. 4 illustrates an embodiment of a system 400 for implementing one or more example embodiments. As shown in FIG. 4, the system 400 includes a processor 410, a memory 420, a storage component 430, an input component 440, an output component 450, a communication interface 460, and a bus 470.

[0113] The processor 410, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 410 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and one or more single core processors, a distributed processing system, or the like. Theprocessor 410 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0114] Memory 420 includes a non-transitory computer readable medium. Memory 420 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 410. The memory 420 comprises machine-readable instructions which are executable by the processor 410. These machine-readable instructions when executed by the processor 410 causes the processor 410 to perform one or more method steps of an embodiment described herein.

[0115] Storage component 430 stores information and / or software related to the operation and use of the system 400. For example, storage component 430 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0116] Input component 440 is configured to receive information, such as user input. For example, the input component 440 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 440 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0117] Output component 450 is configured to provide output information from the system 400. For example, the output component 450 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0118] Communication interface 460 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 460 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the system 400 and other devices. In other words, the standard of the communication interface 460 is not limited.

[0119] The bus 470 acts as an interconnect between the processor 410, the memory 420, the storage component 430, the input component 440, the output component 450, and the communication interface 460 of the system 400. The bus 470 may include a wired interconnection or a wireless interconnection.

[0120] The number and arrangement of components shown in FIG. 4 are provided as an example. In practice, system 400 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of system 400 may perform one or more functions described as being performed by another set of components of system 400. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of system 400 in communication with one another.

[0121] Further, according to example embodiments, the system 400 may include one or more elements from the system architecture described above in relation to FIG. 2. For example, the system 400 may include the base station.

[0122] In the present disclosure, specific tasks may be performed using AI / ML (Artificial Intelligence / Machine Learning) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc.

[0123] Although Al and ML are explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve their performance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0124] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, transductive learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, andis not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0125] It should be noted that the ALML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0126] FIG. 5 is a diagram of an example of implementation environment 500 in which systems and / or method, described herein, may be implemented. The implementation environment 500 includes a UE (User equipment) 510, a service environment 520, and a network 530. The service environment 520 include one or more sub-environments 521. To illustrate this, FIG. 5 shows, for convenience, examples of a 1st sub-environment 521-1, a 2nd sub-environment 521-2, and an N-th sub-environment 521-N (where N is any natural number).

[0127] The UE 510 is connected to the network 530, and the network 530 is connected to the service environment 520. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 510 and the service environment 520 are connected via the network 530.

[0128] The UE 510 is a device that communicates with the service environment 520. The UE 510 receives information from the service environment 520 and / or sends information to the service environment 520. Also, the UE 510 may generate and / or store information to be transmitted, as necessary. Also, the UE 510 may store and / or process information that is received, as necessary.

[0129] The example figure 5 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE ”

[0130] For example, the UE 510 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0131] The service environment 520 is an environment that communicates with the UE 510 to provide one or more services. The service environment 520 receives information from the UE 510 and / or sends information to the UE 510. Also, the service environment 520 may generate and / or store information to be transmitted, as necessary. Also, the service environment 520 may store and / or process information that is received, as necessary. For example, the service environment 520 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0132] The example figure 5 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the"service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment.”

[0133] The one or more services provided by the service environment 520 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the HE 510, a service that stores information from the HE 510, or a service that performs processing based on information from the HE 510 and returns the results of the processing.

[0134] In an embodiment, the Service Environments 520 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0135] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, whenmeans of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0136] The service environment 520 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 520 can be determined as appropriate. Additionally, if the service environment 520 includes one or more sub-environments 521, the placement of devices can be determined based on predetermined policies for each sub-environment 521. For example, devices related to the first service may be placed in the 1st sub-environment 521-1, and devices related to the second service may be placed in the 2nd sub-environment 521-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 521-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 521-2. In this way, specific devices can be placed in specific sub -environments 521. Conversely, each sub-environment 521 can be specialized for a particular purpose.

[0137] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0138] The network 530 is a network that exchanges information between the UE 510 and the service environment 520. The network 530 includes one or more wired and / or wireless networks.

[0139] For example, the network 530 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0140] The network 530 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 530 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 520 could be in the core network, in which case the network 530 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0141] The number and arrangement of devices and networks shown in FIG. 5 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.

[0142] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system that may include a base station that may be configured to: determine, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the targetlogical channel; and in response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.Item [2]: The system according to item [1], wherein the LCP policy may include a mapping between different values of priority and different levels of network conditions.Item [3]: The system according to one of items [l]-[2], wherein the logical channel priority increase request may be transmitted via radio resource control (RRC) signaling.Item [4]: The system according to one of items [l]-[3], wherein the logical channel priority increase request may include a persistence configuration defining a persistency of the increased priority associated with the target logical channel.Item [5]: The system according to item [4], wherein the persistence configuration may define at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.Item [6]: The system according to one of items [l]-[5], wherein the logical channel priority increase request may include a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel.Item [7]: The system according to one of items [l]-[6], wherein the logical channel priority increase request may include a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.Item [8]: A method that may include: determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmitting, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.Item [9]: The method according to item [8], wherein the LCP policy may include a mapping between different values of priority and different levels of network conditions.Item

[0010] : The method according to one of items [8]-[9], wherein the logical channel priority increase request may be transmitted via radio resource control (RRC) signaling.Item

[0011] : The method according to one of items [8]-

[0010] , wherein the logical channel priority increase request may include a persistence configuration defining a persistency of the increased priority associated with the target logical channel.Item

[0012] : The method according to item

[0011] , wherein the persistence configuration may define at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.Item

[0013] : The method according to one of items [8]-

[0012] , wherein the logical channel priority increase request may include a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel.Item

[0014] : The method according to one of items [8]-

[0013] , wherein the logical channel priority increase request may include a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.Item

[0015] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by a system to cause the system to perform a method including: determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; and in response to determining to increase the priority associated with the target logical channel, transmitting, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the LCP policy may include a mapping between different values of priority and different levels of network conditions.Item

[0017] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0016] , wherein the logical channel priority increase request may be transmitted via radio resource control (RRC) signaling.Item

[0018] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0017] , wherein the logical channel priority increase request may include a persistence configuration defining a persistency of the increased priority associated with the target logical channel.Item

[0019] : The non-transitory computer-readable recording medium according to item

[0018] , wherein the persistence configuration may define at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.Item

[0020] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0019] , wherein the logical channel priority increase request may include at least one of: a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel; and a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.

[0143] It is understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.Various Aspects of Embodiments

[0144] 3GPP TSG-RANWG2 Meeting #129 R2-XXXX

[0145] Agenda item: 8.7.4.1

[0146] Source: Rakuten Mobile

[0147] Title: On Priority Switching during LCP Procedure

[0148] WID / SID: NR_XR_Ph3-Core

[0149] Document for: Discussion / Decision

[0150] Introduction

[0151] RAN 127: Agreements

[0152] 1. As a baseline, additional LCH priority is applied for an LCH in both 1st and 2nd Rounds of resource allocation procedure in LCP, as long as the LCH has delay-critical data available for transmission when starting the 1st Round.

[0153] 2. FFS if we can still change the priority for the 2nd round to ensure fairness, but we need to consider tight timeline of LCP procedure and UE complexity. Companies can also check whether we can leave this to UE implementation.

[0154] 3. Introduce an independent per-LCH remaining time threshold for applying delay-critical priority.

[0155] 4. We do not introduce any setting restrictions of this new remaining time threshold with relation to DSR triggering threshold.

[0156] RAN128: Agreements

[0157] 1. As a baseline, the additional LCH priority is applied to both the first round and the second round of the LCP procedure. The UE does not fallback to the default LCH priority in the second round even if there is no more LCH priority-adjusted data after the first round.

[0158] 2. As an optional capability, the UE can also support to fallback to default priority in the 2nd round of LCP.

[0159] In previous RAN2 discussions, the application of additional priority for LCH has been actively discussed, leading to

[0160] agreements that additional LCH priority should be applied in both the first and second rounds of the LCP procedure.

[0161] However, several open issues remain regarding:

[0162] Configuration details for additional priority handling.

[0163] Impact of Bj (bucket size) and PBR (Prioritized Bit Rate) on LCP performance.

[0164] Interaction with intra-UE prioritization mechanisms, including uplink grant allocation, retransmissions, and Scheduling Request (SR) prioritization.

[0165] Logical Channel Prioritization (LCP) has been extensively discussed in RAN2, with consensus on the application of additional LCH priority across both the first and second rounds of the LCP procedure, alongside an optional fallback capability for UEs to return to default priority if neededRP-242517 SR for XR WI 2. However, while these agreements set a foundation, they leave many details unresolved, particularly in terms of how additional priority should be configured, applied, and dynamically adjusted. Without standardized configuration parameters, we risk inconsistent vendor implementations, unpredictable scheduling behavior, and fairness concerns across different network deployments.

[0166] Operators require fine-grained control over LCP priority behavior, ensuring that additional priority is applied in a way that aligns with QoS objectives while maintaining scheduling fairness. The ability to configure priority persistence, manage interactions with schedulingconstraints such as Bj and PBR, and define network-level policies for LCP adjustments is essential for ensuring interoperability across implementations.

[0167] This contribution presents a structured configuration framework that addresses these gaps by defining explicit parameters, ensuring that additional priority handling remains predictable, scalable, and adaptable to real-world deployment scenarios.

[0168] Discussions

[0169] Configuration Details for Additional Priority Handling in

[0170] In previous RAN2 discussions, companies have raised concerns regarding how additional LCH priority should be applied in practice. While the agreement to support additional priority in both rounds of LCP provides a baseline behavior, the lack of specific configuration parameters means that different vendors may implement this in different ways, leading to interoperability challenges.

[0171] One major concern is whether additional priority should persist indefinitely or be dynamically adapted based on network conditions. Some companies argue that strict persistence ensures consistency, while others advocate for a dynamic approach, where priority is re-evaluated based on buffer status, remaining delay budget, or competing traffic demands. If left undefined, we risk situations where certain UEs aggressively retain additional priority, potentially leading to LCH starvation for other services.

[0172] Another area of debate is who controls priority adaptation — the UE or the network. Some believe UE-driven adjustments allow for localized optimizations, reducing signaling overhead, while others stress that gNB-controlled priority scaling ensures network-wide consistency. There is also the question of interactions with existing scheduling constraints, suchas PBR and Bj. Additional priority may allow a UE to send more data than originally allocated, which could impact scheduling fairness if not properly managed.

[0173] From an implementation perspective, it is clear that a uniform approach is needed — one that allows the network to configure additional priority handling explicitly, ensuring consistent behavior across all UEs while retaining enough flexibility to adapt to different deployment conditions. Observation 1: The absence of standardized configuration parameters for additional LCH priority handling could lead to inconsistent implementations across vendors, making scheduling behavior unpredictable and difficult to optimize for network operators.

[0174] Proposal la: Introduce explicit configuration parameters to define how additional priority is applied, persisted, or revoked across different scheduling conditions.

[0175] Proposal lb: Ensure that these parameters are configurable via RRC signaling, allowing networks to dynamically control additional LCH priority handling based on real-time traffic demands.

[0176] Priority Adaptation and Persistence Considerations

[0177] While the agreement to apply additional priority across both LCP rounds provides a clear baseline, it does not specify when and how priority should be revoked or adjusted dynamically. This lack of clarity has raised concerns among companies regarding fairness and scheduling predictability. Some companies argue that if an LCH retains additional priority beyond what is strictly necessary, other traffic flows may be delayed unnecessarily, leading to unintended resource monopolization.

[0178] A possible solution is to introduce a time-based threshold, where priority is gradually reduced after a certain duration, allowing other LCHs to compete for resources. Anotherapproach is to tie priority retention to buffer status, where priority persists only if delay-critical data remains in the buffer. Without such controls, we risk situations where some UEs retain priority for too long, while others drop priority prematurely, affecting QoS consistency across different devices.

[0179] An additional complexity arises in scenarios where multiple LCHs have additional priority. Some companies suggest a rotational fairness mechanism, where priority shifts between competing LCHs over multiple scheduling intervals, preventing one LCH from monopolizing uplink resources indefinitely.

[0180] Observation 2: Without clear rules on priority persistence, some UEs may retain additional priority for longer than necessary, while others may drop it prematurely, leading to inconsistent QoS behavior across devices.

[0181] Proposal 2a: Introduce a priorityPersistenceMode parameter to define whether priority is STATIC (always retained) or DYNAMIC (adjusted based on network conditions).

[0182] Proposal 2b: Define a timeRemainingThreshold parameter to determine when additional priority should expire, ensuring that LCHs do not retain priority longer than needed.

[0183] Proposal 2c: Implement a fairness rotation mechanism for cases where multiple LCHs have additional priority, ensuring equitable scheduling access.

[0184] Impact on the existing LCP procedure

[0185] During previous RAN2 discussions, concerns were raised regarding how additional LCH priority might impact Bj and PBR constraints, particularly in networks with high congestion or competing traffic flows. One major concern is that applying additional priority could override Bj or PBR limits, leading to unintended resource monopolization by certain LCHs. This couldcause best-effort or lower-priority traffic to be deprioritized indefinitely, creating fairness issues across UEs.

[0186] Another issue is that BSR-based scheduling may not accurately reflect the impact of additional priority adjustments. Today, BSR reports buffer availability to the gNB, but additional priority can alter how much data is actually transmitted, potentially misaligning grant allocation decisions. If the network expects a certain data volume to be transmitted based on BSR, but additional priority allows more data to be scheduled than expected, this can create inefficiencies in grant assignment and overall resource utilization.

[0187] Some companies argue that PBR and Bj should remain strictly enforced, ensuring that additional priority does not introduce uncontrolled scheduling deviations. Others suggest that PBR constraints should be relaxed dynamically for delay-sensitive LCHs, allowing for short-term priority boosts while still maintaining long-term fairness. There is also debate on whether Bj should be extended dynamically for priority-extended LCHs, ensuring that priority-extended packets are not prematurely discarded due to Bj expiration.

[0188] Given these challenges, a structured approach is needed to ensure that additional priority handling does not conflict with Bj, PBR, or BSR-based scheduling.

[0189] Observation 1: Additional priority handling introduces potential conflicts with Bj and PBR limits, potentially allowing certain LCHs to exceed their originally allocated resources, which could impact fairness and lower-priority traffic scheduling.

[0190] Proposal la: Introduce a priorityBypassPBR parameter that allows networks to define whether additional priority can bypass PBR constraints under certain conditions.

[0191] Proposal lb: Implement a priorityBufferExtensionF actor that enables Bj to extend dynamically for LCHs with additional priority, ensuring delay-critical data is not prematurely discarded.

[0192] Ensuring Compatibility Between Additional Priority and PBR / Bj Constraints

[0193] PBR and Bj are critical mechanisms in uplink scheduling that regulate transmission rate limits and buffer retention policies, ensuring fair and efficient resource distribution among logical channels (LCHs). The introduction of additional priority handling raises concerns about how these mechanisms should interact with priority-extended LCHs, particularly in scenarios where multiple high-priority LCHs compete for scheduling opportunities.

[0194] PBR enforces rate-based transmission limits, preventing any single LCH from dominating uplink resource allocation. Some companies advocate for strict PBR enforcement, ensuring that additional priority does not override existing rate controls. Others argue that delaysensitive LCHs should be allowed temporary PBR bypassing, ensuring that time-sensitive data is not constrained by rigid rate limits. A potential compromise is to introduce a dynamic scaling factor, where priority-extended LCHs can temporarily exceed PBR limits within a defined threshold, balancing fairness and scheduling efficiency.

[0195] Similarly, Bj defines how long buffered data remains eligible for transmission before being discarded. When additional priority is applied, certain LCHs may transmit data later than originally scheduled, increasing the risk that Bj expires before transmission occurs, leading to unexpected data loss. Some companies propose dynamically adjusting Bj for LCHs with additional priority, allowing priority-extended data to remain in the buffer longer. Others arguethat Bj should remain fixed, ensuring that additional priority does not disrupt buffer management policies.

[0196] A further concern is Bj exhaustion in networks with multiple priority-extended LCHs. If too many LCHs receive extended Bj, this could reduce scheduling efficiency, making it difficult for lower-priority LCHs to compete for resources, ultimately impacting overall uplink performance.

[0197] Observations and Proposals

[0198] Observation 1: If additional priority is applied without considering PBR, certain LCHs may consume more uplink resources than originally intended, leading to potential scheduling fairness issues.

[0199] Proposal 1 : Introduce a BSR Alignment Mechanism, ensuring that BSR accurately reflects additional priority-based Bj / PBR changes.

[0200] Proposal la: Introduce a priorityPBRBypassMode parameter, allowing networks to define when and how additional priority can exceed PBR constraints.

[0201] Proposal lb: Define a PBRScalingF actor that allows temporary PBR increases for priority-extended LCHs, ensuring that delay-sensitive traffic is not unnecessarily restricted.

[0202] Observation 2: Without adjustments, additional priority handling may cause Bj expiration issues, leading to premature data loss despite the LCH being prioritized for transmission.

[0203] Proposal 2a: Introduce a Bj ScalingF actor that dynamically extends Bj for LCHs with additional priority, ensuring that priority-extended data is not discarded before it can be scheduled.

[0204] Proposal 2b: Allow networks to define a maximum Bj extension limit, preventing Bj from extending indefinitely and ensuring scheduling fairness across multiple LCHs.

[0205] Ensuring Fairness Between High-Priority and Lower-Priority LCHs

[0206] While additional priority is intended to enhance scheduling for delay-sensitive traffic, it is equally important to prevent it from completely starving lower-priority LCHs. Some companies express concerns that once an LCH receives additional priority, it may be scheduled indefinitely, while other traffic — such as uplink retransmissions, lower-priority QoS flows, and best-effort data — may be delayed indefinitely.

[0207] One way to mitigate this issue is by introducing a fairness threshold, which would limit how many consecutive TTIs an LCH can retain additional priority before allowing lower-priority LCHs to be scheduled. This would ensure that even when additional priority is applied, lower-priority traffic is not completely blocked from uplink scheduling.

[0208] Another approach is to introduce a traffic-awareness mechanism, where the UE automatically scales down additional priority when lower-priority LCHs have accumulated a certain amount of backlogged data. This would prevent situations where best-effort traffic remains unscheduled for extended periods, ensuring better overall scheduling balance.

[0209] Observation 3 : Additional priority handling must include fairness controls to ensure that lower-priority LCHs are not indefinitely deprioritized, preventing scheduling imbalance within the UE.

[0210] Proposal 3a: Introduce a fairness threshold that limits the number of consecutive TTIs an LCH can retain additional priority before other LCHs are scheduled.

[0211] Proposal 3b : Implement a traffic-awareness mechanism that scales down additional priority when lower-priority LCHs accumulate significant buffered data, preventing best-effort traffic from being completely blocked.

[0212] Proposal 3c: Introduce Intra-UE LCH Balancing Rule, ensuring that priority handling is distributed fairly among different logical channels within a UE.

[0213] Conclusions

[0214] This paper provides our views on whether LCH priority

[0215] References

[0216] ANNEX:

[0217] Enhancements with Stage-1, Stage-2, and Stage-3 Implementations

[0218] 1. Introducing a Service-Based Priority Mapping Mechanism

[0219] Stage- 1 (Requirements Stage)

[0220] Define a mechanism that allows additional priority handling to be mapped to predefined QoS configurations, ensuring consistency in traffic scheduling.

[0221] Stage-2 (Architecture and Procedures Stage)

[0222] Introduce an RRC signaling update to allow the gNB to configure additional priority settings per QoS profile.

[0223] Stage-3 (Protocol Signaling Stage)

[0224] Modify the RRC signaling format to include:

[0225] priorityServiceMapping, defining which QoS levels map to additional priority.

[0226] priority Seal eFactor, allowing dynamic priority adjustments based on QoS requirements.

[0227] 2. HARQ-Aware Priority Persistence Rule

[0228] Stage- 1 (Requirements Stage)

[0229] Define a mechanism where additional priority can persist across HARQ retransmissions without affecting fairness in scheduling.

[0230] Stage-2 (Architecture and Procedures Stage)

[0231] Introduce an LCP-based rule where priority is maintained only for HARQ transmissions that meet delay-critical thresholds.

[0232] Stage-3 (Protocol Signaling Stage)

[0233] Modify the MAC CE format to include:

[0234] priorityPersistencelndicator, defining whether an LCH retains priority across HARQ retransmissions.

[0235] 3. Dynamic Congestion-Aware Priority Mode

[0236] Stage- 1 (Requirements Stage)

[0237] Define a mechanism where priority levels are dynamically adjusted based on network congestion conditions, ensuring fair scheduling in high-load scenarios.

[0238] Stage-2 (Architecture and Procedures Stage)

[0239] Introduce an adaptive priority adjustment algorithm, allowing gNBs to modify priority handling based on real-time traffic demand.

[0240] Stage-3 (Protocol Signaling Stage)

[0241] Define a priorityCongestionScalingF actor parameter within the RRC signaling format, allowing dynamic scaling of priority thresholds.

[0242] 4. BSR Alignment Mechanism

[0243] Stage- 1 (Requirements Stage)

[0244] Define a method for ensuring that BSR remains aligned with additional prioritybased Bj / PBR changes, preventing mismatches in scheduling behavior.

[0245] Stage-2 (Architecture and Procedures Stage)

[0246] Introduce an updated BSR reporting rule, ensuring that additional priority handling dynamically modifies BSR buffer status reports.

[0247] Stage-3 (Protocol Signaling Stage)

[0248] Modify the BSR MAC CE format to allow:

[0249] priority AdjustedBSR, reflecting changes in Bj / PBR handling.

[0250] BSRPriority Indicator, allowing gNBs to distinguish between priority-extended and normal buffer reports.

[0251] 5. Intra-UE LCH Balancing Rule

[0252] Stage- 1 (Requirements Stage)

[0253] Define a mechanism where priority handling is distributed fairly among different logical channels within a UE, preventing a single LCH from monopolizing uplink resources.

[0254] Stage-2 (Architecture and Procedures Stage)

[0255] Introduce priority rotation mechanisms where priority shifts between competing LCHs over scheduling intervals.

[0256] Stage-3 (Protocol Signaling Stage)

[0257] Modify LCP behavior to allow:

[0258] priorityFaimessTimer, ensuring that additional priority does not persist indefinitely within a single LCH.

[0259] priorityWeightDistribution, enabling scheduling fairness among multiple high-priority LCHs.

Claims

What is claimed is:

1. A system comprising:a base station configured to:determine, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; andin response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

2. The system according to claim 1, wherein the LCP policy comprises a mapping between different values of priority and different levels of network conditions.

3. The system according to claim 1, wherein the logical channel priority increase request is transmitted via radio resource control (RRC) signaling.

4. The system according to claim 1, wherein the logical channel priority increase request comprises a persistence configuration defining a persistency of the increased priority associated with the target logical channel.

5. The system according to claim 4, wherein the persistence configuration defines at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.

6. The system according to claim 1, wherein the logical channel priority increase request comprises a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel.

7. The system according to claim 1, wherein the logical channel priority increase request comprises a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.

8. A method comprising:determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; andin response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

9. The method according to claim 8, wherein the LCP policy comprises a mapping between different values of priority and different levels of network conditions.

10. The method according to claim 8, wherein the logical channel priority increase request is transmitted via radio resource control (RRC) signaling.

11. The method according to claim 8, wherein the logical channel priority increase request comprises a persistence configuration defining a persistency of the increased priority associated with the target logical channel.

12. The method according to claim 11, wherein the persistence configuration defines at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.

13. The method according to claim 8, wherein the logical channel priority increase request comprises a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel.

14. The method according to claim 8, wherein the logical channel priority increase request comprises a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system to cause the system to perform a method comprising:determining, based on information associated with target data in a buffer of a target logical channel at a user equipment (UE) and a logical channel prioritization (LCP) policy regarding the target logical channel, whether to increase a priority associated with the target logical channel; andin response to determining to increase the priority associated with the target logical channel, transmit, to the UE, a logical channel priority increase request to increase the priority associated with the target logical channel.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the LCP policy comprises a mapping between different values of priority and different levels of network conditions.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the logical channel priority increase request is transmitted via radio resource control (RRC) signaling.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the logical channel priority increase request comprises a persistence configuration defining a persistency of the increased priority associated with the target logical channel.

19. The non-transitory computer-readable recording medium according to claim 18, wherein the persistence configuration defines at least one of: whether the increased priority associated with the target logical channel is static or dynamic based on network conditions; an expiration of the increased priority associated with the target logical channel; and whether the increased priority associated with the target logical channel is persistent across hybrid automatic repeat request (HARQ) retransmission.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the logical channel priority increase request comprises at least one of: a prioritized bit rate (PBR) configuration defining PBR extension based on the increased priority associated with the target logical channel; and a bucket size (Bj) configuration defining Bj extension based on the increased priority associated with the target logical channel.

Images