Delay status report management in a network

Abstract

Provided are apparatus, method, and device for automatically managing delay status report (DSR). According to example embodiments, the system may include a base station. The base station may be configured to receive a delay status report (DSR). The DSR may include information associated with target data in a buffer of a user equipment (UE). The DSR may include a delay-critical flag indicating that target data is delay-critical. The base station may be configured to identify that the DSR comprises the delay-critical flag. The base station may be configured to allocate resources to the UE with prioritized scheduling for the target data.

Description

DELAY STATUS REPORT 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 management of delay status report (DSR) 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] In order to enhance the performance of a telecommunication network, various features and mechanisms have been introduced. Among others, one or more technical specifications provided by one or more standard organizations, have described the concepts and mechanisms related to delay status report (DSR). The DSR may refer to a report including delay information associated with data to be transmitted from a user equipment (UE), which may be utilized by a base station to schedule and allocate resources.SUMMARY

[0005] Example embodiments of the present disclosure automatically manage delay status report (DSR). As such, example embodiments of the present disclosure may allow the reporting of the DSR to be optimized to provide granular reporting while keeping signaling overhead minimal.

[0006] According to example embodiments, a system is provided. The system may include a base station that may be configured to: receive a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is delay-critical; identify that the DSR comprises the delay-critical flag; and allocate resources to the UE with prioritized scheduling for the target data.

[0007] According to example embodiments, a method is provided. The method may include: receiving a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is delay-critical; identifying that the DSR comprises the delay-critical flag; and allocating resources to the UE with prioritized scheduling for the target data.

[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: receiving a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is del ay -critical; identifying that the DSR comprises the delay-critical flag; and allocating resources to the UE with prioritized scheduling for the target data.

[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. 1 illustrates a block diagram of an example system configuration for managing delay status report (DSR) in a network, according to one or more example embodiments;

[0012] FIG. 2 illustrates a flow diagram of an example method for managing delay status report (DSR), according to one or more example embodiments;

[0013] FIG. 3 illustrates a flow diagram of an example method for managing delay status report (DSR), according to one or more example embodiments;

[0014] FIG. 4 illustrates a flow diagram of an example method for managing delay status report (DSR), according to one or more example embodiments;

[0015] FIG. 5 illustrates a flow diagram of an example method for managing delay status report (DSR), according to one or more example embodiments;

[0016] FIG. 6 illustrates a flow diagram of an example method for managing delay status report (DSR), according to one or more example embodiments;

[0017] FIG. 7 illustrates a flow diagram of an example method 700 for managing delay status report (DSR), according to one or more example embodiments;

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

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

[0020] 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.

[0021] 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 systemsand / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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 (O-RAN) Alliance standard organization, and the like. For instance, the terms “DSR”, “XR”, “MAC”, “CE”, “LCG”, “PUCCH”, “PUSCH”, and the like, as well as the associatedfeatures and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0029] 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.

[0030] As described above, the DSR may refer to a report including delay information associated with data to be transmitted from a user equipment (UE), which may be utilized by a base station to schedule and allocate resources.

[0031] In general, a UE may communicate with a base station (e.g., gNodeB) in order to transmit and receive various kinds of data required. In this regard, certain data transmitted from the UE to the base station may be delay-critical and must be sent within a specific time limit.

[0032] For example, a UE implementing an XR technology may communicate with the base station in order to transmit and receive data required to operate the technology. In this regard, said data may be delay-critical and must be sent within a specific time limit.

[0033] 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 fully immersive virtual experience.

[0034] In this regard, for example in an AR technology, a user may use a camera of a smartphone (UE) to view a chair product, where the UE may capture images of the chair product and transmit data associated with the images of the chair product (hereinafter “chair data”) to a server via a base station. Once the server receives the chair data, the server may transmit dataincluding information related to the chair product (e.g., prize, dimensions, weight, and the like) to the UE via the base station, where the UE may then display such data as virtual elements alongside the chair which is a physical element on the screen of the smartphone. In this regard, the chair data must be transmitted to and received by the base station within a certain time limit (e g., 50ms) in order to ensure that such data remains relevant. Otherwise, for example, the user may move the camera of the smartphone to view a desk product before the chair data is transmitted to the base station. In such case, it is no longer necessary to transmit the chair data to the base station, since the user is no longer viewing the chair product and it is no longer necessary for the user / UE to receive data related to the chair product.

[0035] Here, in order to facilitate communications between the base station and the UE in view of the above delay-critical data, a delay status report (DSR) may be transmitted from the UE to the base station. The DSR may refer to a report including delay information associated with data to be transmitted from the UE, and may indicate whether certain data has expired and is no longer relevant. Once the base station receives the DSR, the base station may determine the scheduling and allocate resources to prioritize receiving the delay-critical data accordingly.

[0036] In this regard, the implementation of DSR in the related art may have the following shortcomings.

[0037] The format of DSR (e.g., DSR media access control (MAC) control element (CE) format) is designed to report aggregate buffer size per logic channel group (LCG), but it lacks the ability to differentiate between delay-sensitive and non-delay-sensitive data. This leads to inefficiencies in scheduling, particularly in cases where: the UE has a mix of time-sensitive and background traffic in its buffer but cannot explicitly inform the network which portion requiresimmediate scheduling; the gNB assumes that all reported buffer data is urgent, leading to inefficient uplink (UL) resource allocation that may delay truly urgent traffic from other UEs; and multiple UEs compete for limited uplink grants where the scheduler prioritizes buffer size rather than true urgency, leading to potential misallocations of scheduling resources.

[0038] For example, in the XR application, the UE may have real-time motion-tracking data (delay-critical) that must be scheduled immediately, and background texture updates (nondelay-critical) that can be scheduled opportunistically. However, since both traffic types are aggregated in the same DSR buffer size report, the scheduler may assume all data requires urgent scheduling, potentially delaying other UEs that have genuinely high-priority traffic.

[0039] Further, in certain implementations that introduce multiple reporting thresholds per LCG, the MAC CE format must evolve to support more granular, yet efficient, delay reporting. The challenge may include ensuring that the additional threshold information does not lead to excessive signaling overhead while still providing the scheduler with the necessary granularity for intelligent uplink resource allocation.

[0040] Several MAC CE designs have been proposed in the related art, such as bitmapbased reporting and extension bit per pair. In bitmap-based reporting, a bitmap per LCG is used to indicate which reporting pairs are present, which provides structured reporting but can increase MAC CE size when multiple LCGs are reported. In extension bit per pair, one additional bit per reporting pair is used, which reuses existing reserved bits in DSR and ensures compact signaling but requires dynamic parsing at the gNodeB.

[0041] An additional concern is related to how the MAC CE should be parsed when multiple LCGs are reported simultaneously. If each LCG has multiple reporting thresholds, theMAC CE size may increase significantly, affecting control channel efficiency. A structured approach that dynamically scales the number of reported pairs based on network requirements may be beneficial.

[0042] To summarize, the format of DSR (e.g., DSR MAC CE format) in the related art does not fully support scalable, priority -aware reporting, leading to potential inefficiencies when handling both delay-critical and non-delay-critical traffic.

[0043] Another shortcoming of the implementation of DSR in the related art may involve inefficiencies in DSR retransmission logic. In particular, one of the persistent inefficiencies in DSR retransmission logic is that UEs may continue to send updated DSRs even when uplink grants are constrained, leading to unnecessary control signaling. This is particularly problematic in scenarios where: the gNodeB has already deprioritized a UE’s buffer report due to congestion but the UE keeps triggering DSR updates, consuming physical uplink control channel (PUCCH) resources that could be used for other control signaling; and multiple UEs experience scheduling delays, causing a build-up of redundant DSR retransmissions, ultimately leading to PUCCH congestion and inefficient resource utilization.

[0044] The DSR retransmissions mechanism in the related art do not account for scheduling feedback from the gNodeB. Even if the gNodeB does not immediately schedule an uplink grant, the UE keeps retransmitting DSRs at regular intervals, assuming that the buffer status remains unchanged. As such, an improved retransmission strategy that allows UEs to suppress redundant reports if network feedback indicates resource constraints may be beneficial.

[0045] To summarize, the DSR mechanisms in the related art lead to excessive control signaling, particularly in congestion scenarios where the gNodeB cannot schedule UL grants immediately.

[0046] Another shortcoming of the implementation of DSR in the related art may involve DSR reporting behavior according to traffic type. In particular, treating all traffic the same and applying a uniform reporting mechanism across all services may lead to inefficient scheduling, particularly for applications like XR and streaming services, which require continuous buffer updates, versus burst-based traffic that only requires occasional reporting.

[0047] For example, an XR application with strict latency constraints may require higher reporting frequency, while a non-interactive background process may not need frequent DSR updates. However, the DSR procedures in the related art do not provide a way for networks to differentiate reporting rules based on service type, leading to potential inefficiencies in how different traffic classes compete for uplink scheduling.

[0048] To summarize, the DSR mechanisms in the related art do not differentiate reporting frequency or triggering logic based on traffic type, leading to potential inefficiencies in scheduling priority between interactive and non-interactive services.

[0049] Another shortcoming of the implementation of DSR in the related art may involve uplink scheduling efficiency. In particular, while DSR plays a crucial role in uplink scheduling efficiency, one of its key inefficiencies is that there is no mechanism for the gNodeB to cancel a previously received DSR report, even if the network determines that UL resources cannot be allocated. In such cases, UEs may continue to attempt retransmitting their buffer status, leading to: redundant control signaling, particularly when UL grants remain unavailable; increased PUCCHcongestion, as multiple UEs repeatedly report unschedulable DSR information; and potential scheduling inefficiencies, as repeated DSR retransmissions may interfere with more urgent control signals.

[0050] While certain implementations of DSR already rely on triggering and cancellation based on predefined UE conditions, there is no way for the gNodeB to explicitly instruct UEs to stop sending further DSR updates in cases where a network-wide congestion event prevents scheduling. Further, certain implementations of DSR involve multi-threshold reporting enhancements, which increase the complexity as UEs may report more frequent and granular delay status updates, further exacerbating congestion-related inefficiencies when scheduling resources are unavailable.

[0051] To summarize, the DSR mechanisms in the related art do not provide an explicit cancellation method, leading to redundant reporting when uplink resources are unavailable.

[0052] Accordingly, the system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage delay status report (DSR).

[0053] According to example embodiments, the system may include a base station that may be configured to receive, from a user equipment (UE), a delay status report (DSR). Here, the DSR may include information associated with target data in a buffer of the UE, and a delay-critical flag indicating that target data is delay-critical. The base station may also be configured to identify that the DSR comprises the delay-critical flag, and subsequently allocate resources to the UE with prioritized scheduling for the target data.

[0054] Ultimately, example embodiments of the present disclosure automatically manage delay status report (DSR), which may allow the reporting of the DSR to be optimized to provide granular reporting while keeping signaling overhead minimal.

[0055] 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.

[0056] 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

[0057] FIG. 1 illustrates a block diagram of an example system configuration 100 for managing delay status report (DSR) in a network, according to one or more example embodiments.

[0058] As illustrated in FIG. 1, system configuration 100 may include a base station 110 and a user equipment (UE) 120, 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.

[0059] The base station 110 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.

[0060] The UE 120 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.

[0061] According to example embodiments, the UE 120 may include a device operated by a user and configured to implement an XR technology or to run an XR application. For example, the UE 120 may include a smartphone, a tablet, a camera, a headset, and the like. The XR technology may refer to immersive technologies such as augmented reality (AR), virtual reality (VR), mixed reality (MR), and the like.

[0062] The UE 120 may also be communicatively coupled to the base station 110 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.

[0063] According to example embodiments, the UE 120 and the base station 110 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 delay status report (DSR) in a network. Example operations performable by the UE 120 for managing the DSR are described below with reference to FIG. 6. Further, example operations performable by the base station 110 for managing the DSR are described below with reference to FIG. 2 to FIG. 5 and FIG. 7.Example Operations for Managing Delay Status Report in the Present Disclosure

[0064] 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. 2 to FIG. 7.

[0065] FIG. 2 illustrates a flow diagram of an example method 200 for managing delay status report (DSR), according to one or more example embodiments. One or more operations in method 200 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage delay status report (DSR).

[0066] 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.

[0067] As illustrated in FIG. 2, at operation S210, the system may be configured to receive a delay status report (DSR). The DSR may be received from a user equipment (UE), and may include information associated with target data in a buffer of the UE.

[0068] According to example embodiments, the target data may include XR data (i.e., data associated with operations related to the XR technology / XR application). Here, the target data may currently be in the buffer of the UE and is to be transmitted to the system (e.g., base station), such as urgency, importance, priority, size, and the like.

[0069] According to example embodiments, the target data may be del ay -critical (i.e., data which relevance is affected by time).

[0070] According to example embodiments, the DSR may also include information associated with non-delay-critical data in the buffer of the UE. In particular, depending on specific needs or configurations, the DSR may be configured to include information associated with delay -critical data (i.e., target data), non-delay-critical data, or both. For example, the DSR may includeinformation associated with non-delay-critical data that is alongside or ahead of delay-critical data in the buffer of the UE.

[0071] In this regard, according to example embodiments, the DSR may include a DSR media access control (MAC) control element (CE) (i.e., DSR in a MAC CE format).

[0072] According to example embodiments, the DSR (e.g., DSR MAC CE) may include a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical. In particular, the DSR MAC CE may define two separate fields, one field specifying buffer size associated with delay-critical data (i.e., first buffer size field), and another field specifying buffer size associated with non-delay-critical data (i.e., second buffer size field).

[0073] According to example embodiments, the DSR (e.g., DSR MAC CE) may include a delay-critical flag. The delay-critical flag may include any kind of indicator (flag) indicating that target data is del ay -critical. According to example embodiments, the delay-critical flag may be in a bit format. For example, the delay-critical flag may be in a 1-bit format per LCG where 0 indicates the absence of delay delay-critical flag and 1 indicates the existence of delay-critical flag.

[0074] According to example embodiments, the DSR (e.g., DSR MAC CE) may include a priority indicator. The priority indicator may include any kind of indication indicating a priority (urgency) associated with the target data. According to example embodiments, the priority indicator may be in a bit format. For example, the priority indicator may be in a 2 -bit format where 00 indicates low priority, 01 indicates medium priority, and 10 indicates high priority.

[0075] According to example embodiments, the priority indicator may be reported per packet data unit (PDU) set or per logical channel group (LCG) to avoid excessive MAC CE signaling overhead. The method then proceeds to operation S220.

[0076] At operation S220, the system may be configured to identify that the DSR includes the delay-critical flag.

[0077] In particular, according to example embodiments, the system may be configured to determine whether the DSR include any delay-critical flag.

[0078] In this regard, according to example embodiments, if the DSR includes the delay-critical flag indicating that target data is delay-critical, the system may identify that the DSR includes the delay-critical flag. The method then proceeds to operation S230.

[0079] At operation S230, the system may be configured to allocate resources to the UE with prioritized scheduling for the target data.

[0080] In particular, since it is identified that the DSR comprises the delay-critical flag indicating that the target data is delay-critical during operation S220, the system may determine that resources should be allocated to the UE with prioritized scheduling for the target data, such that the target data may be timely transmitted from the UE and received by the system (e.g., base station) before it expires.

[0081] The resource may include any kind of resources associated with transmission and reception of the data between a base station and a UE. According to example embodiments, the resources may include uplink (UL) grant for transmission of the target data

[0082] According to example embodiments, the system may provide / schedule uplink (UL) grants to focus on transmission of the target data (delay-critical data) based on the obtained DSR, in order to ensure that said the target data can receive timely resource allocation.

[0083] According to example embodiments, the system may also be configured to configure per-LCG DSR reporting thresholds based on traffic priority and a predefined radio resource control (RRC) signaling.

[0084] According to example embodiments, the system may also be configured to configure separate DSR triggering thresholds for delay -critical and non-delay-critical traffic based on RRC signaling and per-LCG threshold adaptation.

[0085] According to example embodiments, the system may also be configured to configure default priority mapping based on traffic class, QoS profile, and RRC signaling.

[0086] Upon performing operation S230, the method 200 may be ended or be terminated. Alternatively, method 200 may return to operation S210, such that the at least one processor may be configured to repeatedly perform, for at least a predetermined amount of time, the receiving the DSR (at operation S210), the identifying that the DSR comprises the delay-critical flag (at operation S220), and the allocating the resource (at operation S230).

[0087] Accordingly, the above processes may allow the reporting of the DSR to be optimized to provide granular traffic reporting while keeping signaling overhead minimal.

[0088] In particular, the use of the delay-critical flag may allow the UE to explicitly indicate to the system (e.g., base station) which portion of the reported buffer contains delaysensitive data and requires immediate scheduling. This may prevent non-critical data from consuming scheduling resources unnecessarily, and ensure that the system (e.g., the base station) can prioritize scheduling decisions based on the presence of the delay-critical flag in order to reduce misallocation of resources for non-time-sensitive traffic.

[0089] Further, the use of separate buffer size fields (i.e., first buffer size field and second buffer size field) may allow the UE to report delay-sensitive and non-delay-sensitive buffer sizes separately. This may ensure that scheduling prioritization remains efficient and that the system (e g., base station) can consider both buffer size reports independently and correctly prioritize scheduling.

[0090] Furthermore, the use of the priority indicator may allow the UE to signal only the most urgent delay status updates, and dynamically adjust the reporting format based on available control signaling resources. This may allow the system (e.g., the base station) to interpret the priority levels and make resource allocation decisions accordingly to ensure that high-priority data is scheduled first, and that the most critical buffer updates are transmitted when control overhead is constrained.

[0091] FIG. 3 illustrates a flow diagram of an example method 300 for managing delay status report (DSR), according to one or more example embodiments. One or more operations 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 delay status report (DSR).

[0092] 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.

[0093] According to example embodiments, the operations of method 300 may be performed after the operations of method 200 are performed. In particular, according to exampleembodiments, the operations of method 300 may be performed after the system (e.g., base station) allocates resources to the UE with prioritized scheduling for the target data (indicated in the DSR).

[0094] As illustrated in FIG. 3, at operation S310, the system may be configured to detect scheduling failure associated with the target data.

[0095] The scheduling failure may refer to an event where the system (e.g., base station) is no longer able to allocate resource to the UE for transmission of the target data. Here, the scheduling failure may occur due to any causes, such as traffic congestions, and the like. Further, the system may detect the scheduling failure using any methods, techniques, tools, and the like. The method then proceeds to operation S320.

[0096] At operation S320, the system may be configured to determine an extended interval associated with retransmission of the DSR (e.g., the same DSR including information associated with target data as received during operation S210 in method 200).

[0097] In particular, since the system is unable to allocate resource to the UE for transmission of the target data due to the scheduling failure, the target data may not be transmitted from the UE to the system, and the UE may retransmit the DSR including information associated with target data to the system.

[0098] Here, the retransmission of the DSR may be performed at a particular interval, such that the UE may continuously transmit the DSR to the system to attempt to obtain resource allocation for the target data until the scheduling failure is resolved and the system is able to allocate resource for transmission of the target data.

[0099] In this regard, according to example embodiments, the extended interval determined during operation S320 may be longer (extended) in comparison to a default interval associated with retransmission of the DSR already defined / configured at the UE.

[0100] According to example embodiments, the extended interval associated with retransmission of the DSR may be determined based on a type of the target data. More specifically, the extended interval associated with retransmission of the DSR may be determined based on the type of the target data in accordance with a policy. The policy may specify different values of retransmission intervals corresponding to different types of target data. The policy may also specify different values of retransmission intervals corresponding to different types of traffic, QoS profile, and the like. According to example embodiments, the policy may be referred to as DSR reporting classes. According to example embodiments, the policy may specify progressive increase of the extended interval based on an amount of time the DSR (associated with the target data) is unscheduled. The method then proceeds to operation S330.

[0101] At operation S33O, the system may be configured to transmit a DSR retransmission extension request. The DSR retransmission extension request may be transmitted to the UE, and may include a request to extend an interval associated with retransmission of the DSR according to the determined extended interval.

[0102] According to example embodiments, the DSR retransmission extension request may be transmitted via RRC signaling.

[0103] According to example embodiments, the DSR retransmission extension request may be in the MAC CE format.

[0104] In response to receiving the DSR retransmission extension request, the UE may extend the interval associated with retransmission of the DSR from a value already defmed / configured at the UE to a value corresponding to the determined extended interval (i.e., determined during operation S320 and included in the DSR retransmission extension request). As such, the UE may be updated to retransmit the DSR at an interval appropriate to the type of the target data.

[0105] Accordingly, the above processes may allow the DSR reporting intervals and thresholds to be dynamically configured per traffic type, ensuring that different applications receive scheduling priority based on service requirements.

[0106] In particular, the above processes may allow the system (e.g., base station) to configure different DSR behavior based on QoS profiles in order to ensure that interactive applications receive prioritized scheduling, as well as to adjust UE reporting behavior dynamically based on congestion levels and resource availability.

[0107] As a result, the UE may be configured to recognize the DSR retransmission extension request (e.g., via RRC signaling) and adjust DSR retransmission behavior accordingly. The UE may also apply different DSR transmission logic for interactive vs. background data, ensuring more efficient uplink buffer management.

[0108] FIG. 4 illustrates a flow diagram of an example method 400 for managing delay status report (DSR), according to one or more example embodiments. One or more operations in method 400 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage delay status report (DSR).

[0109] 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.

[0110] According to example embodiments, the operations of method 400 may be performed after the operations of method 200 are performed. In particular, according to example embodiments, the operations of method 400 may be performed after the system (e.g., base station) allocates resources to the UE with prioritized scheduling for the target data (indicated in the DSR).

[0111] As illustrated in FIG. 4, at operation S410, the system may be configured to detect scheduling failure associated with the target data.

[0112] The scheduling failure may refer to an event where the system (e.g., base station) is no longer able to allocate resource to the UE for transmission of the target data. Here, the scheduling failure may occur due to any causes, such as traffic congestions, and the like. Further, the system may detect the scheduling failure using any methods, techniques, tools, and the like. The method then proceeds to operation S420.

[0113] At operation S420, the system may be configured to transmit a DSR retransmission cancellation request. The DSR retransmission cancellation request may be transmitted to the UE, and may include a request to cancel a received DSR (e.g., the DSR including information associated with target data received during operation S210 in method 200).

[0114] In particular, since the system is unable to allocate resource to the UE for transmission of the target data due to the scheduling failure, the target data may not be transmitted from the UE to the system.

[0115] In this regard, the system may transmit the DSR retransmission cancellation request to cancel such DSR.

[0116] According to example embodiments, the DSR retransmission cancellation request may be in a MAC CE format. Here, the DSR retransmission cancellation request in the MAC CE format may specify information associated with UE identification, LCG, cancellation reason (e.g., reason code), and the like.

[0117] According to example embodiments, the system may define hybrid automatic repeat request (HARQ) interaction rules to ensure that DSR is not canceled if related data is still in the HARQ retransmission process. The method then proceeds to operation S430.

[0118] At operation S430, the system may be configured to receive a DSR cancellation acknowledgement from the UE.

[0119] In particular, in response to receiving the DSR retransmission cancellation request, the UE may interpret the DSR retransmission cancellation request and adjust buffer status reporting accordingly. Subsequently, the UE may transmit the DSR cancellation acknowledgement to the system.

[0120] According to example embodiments, the system may define a DSR rejection mechanism, ensuring that UEs do not continue retransmitting reports that cannot be scheduled due to congestion.

[0121] Accordingly, the above processes may allow the system (e.g., base station) to signal the UE when their previously reported DSR information is no longer needed. This may ensure that the UE does not repeatedly send buffer status that the network cannot schedule, as well as prevent unintended retransmissions of previously reported data.

[0122] FIG. 5 illustrates a flow diagram of an example method 500 for managing delay status report (DSR), according to one or more example embodiments. One or more operations in method 500 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage delay status report (DSR).

[0123] 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.

[0124] According to example embodiments, the operations of method 500 may be performed after the operations of method 200 is performed. In particular, according to example embodiments, the operations of method 500 may be performed after the system (e.g., base station) receives the DSR from the UE.

[0125] As illustrated in FIG. 5, at operation S510, the system may be configured to receive a DSR cancellation request.

[0126] The DSR cancellation request may be received from the UE, and may include a request to cancel resource allocation for the target data associated with the DSR previously sent from the UE to the system (e.g., base station).

[0127] According to example embodiments, the DSR cancellation request may be in the MAC CE format. In this regard, the DSR cancellation request may be in the form of a cancellation flag within the MAC CE.

[0128] Here, the UE may determine to transmit the DSR cancellation request based on a DSR cancellation policy. In particular, according to example embodiments, the system may beconfigured to transmit a DSR cancellation policy to the UE. The DSR cancellation policy may specify various rules and policies which the UE may utilize to determine when to cancel DSR and transmit the DSR cancellation request. According to example embodiments, the DSR cancellation policy may be transmitted via RRC signaling.

[0129] For example, the DSR cancellation policy may allow the UE to autonomously cancel a pending DSR report when, for example, the UE buffer state changes significantly that would render the previous DSR report outdated (e.g., the application layer may determine that certain delay-sensitive data is no longer relevant (e.g., expired XR frames)), the UE determines that re-reporting is inefficient due to multiple failed scheduling attempts, determines that the reported buffer data is no longer valid or useful, and the like. The method then proceeds to operation S520.

[0130] At operation S520, the system may be configured to cancel resource allocation for the target data. The method then proceeds to operation S53O.

[0131] At operation S530, the system may be configured to transmit a DSR cancellation acknowledgement to the UE.

[0132] As such, the above processes may allow for UE-initiated DSR cancellations, ensuring that the DSR operations remains efficient and responsive to network scheduling conditions, as well as ensuring that both the UE and the system (e.g., base station) maintain synchronization on buffer status reporting.

[0133] FIG. 6 illustrates a flow diagram of an example method 600 for managing delay status report (DSR), according to one or more example embodiments. One or more operations inmethod 600 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage delay status report (DSR).

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

[0135] According to example embodiments, the operations of method 500 may be performed in parallel with the operations of method 200.

[0136] As illustrated in FIG. 6, at operation S610, the system may be configured to transmit a DSR. The DSR may be transmitted to a base station, and may include information associated with target data in a buffer of the system (e.g., UE). The method then proceeds to operation S620.

[0137] At operation S620, the system may be configured to determine whether resources are allocated from the base station for the transmission of the target data.

[0138] Here, the system may determine whether resources are allocated from the base station for the transmission of the target data using any appropriate methods, techniques, tools, and the like.

[0139] In this regard, in response to determining that the resources are not allocated from the base station for the transmission of the target data, the system may determine that retransmission of the DSR should be delayed, and the method proceeds to operation S630.

[0140] In particular, as described above in relation to FIG. 3 and FIG. 4, the base station may encounter scheduling failure where the base station is no longer able to allocate resource tothe UE for transmission of the target data. In such case, the UE may determine that the resources are not allocated from the base station for the transmission of the target data.

[0141] On the other hand, in response to determining that the resources are allocated from the base station for the transmission of the target data, the system may determine that retransmission of the DSR should not be delayed, and the method ends. In this regard, the system (e.g., the UE) may proceed to transmit the target data to the base station using the allocated resources.

[0142] At operation S630, the system may be configured to delay transmission (retransmission) of the DSR.

[0143] In particular, as described above in relation to FIG. 3 and FIG. 4, since the base station is unable to allocate resource to the system (e.g., UE) for transmission of the target data due to the scheduling failure, the target data may not be transmitted from the system to the base station, and the system may retransmit the DSR including information associated with target data to the base station.

[0144] In this regard, the system may delay transmission (retransmission) of the DSR until a specified hold-off period has passed. The hold-off period may be predefined.

[0145] According to example embodiments, the system may be configured to delay transmission (retransmission) of the DSR in accordance with a policy. The policy may specify, for example, maximum delay before a suppressed DSR is re-transmitted (i.e., hold-off period), rules for extending retransmission intervals dynamically, and the like. The policy may also be received from the base station via RRC signaling.

[0146] In response to delaying the transmission (retransmission) of the DSR, the method may return to operation S610 to transmit (retransmit) the DSR.

[0147] In this regard, according to example embodiments, the system may delay transmission (retransmission) of the DSR by an amount based on the number of times which transmission (retransmission) of the DSR has been delayed. For example, the system may progressively extend the time between retransmitted DSRs if scheduling opportunities remain unavailable.

[0148] According to example embodiments, the system may re-trigger the transmission of the DSR if the buffer status changes significantly, rather than relying on periodic retransmissions.

[0149] Accordingly, the above processes may allow the system (eg., UE) to detect potential scheduling failure at the base station, and automatically extend the retransmission intervals of the DSR, thereby reducing excessive PUCCH usage. In particular, the above processes may allow the system to dynamically extend DSR retransmission intervals if prior DSRs have not resulted in UL grant allocations.

[0150] FIG. 7 illustrates a flow diagram of an example method 700 for managing delay status report (DSR), according to one or more example embodiments. One or more operations in method 700 may be performed by the system of one or more example embodiments of the present disclosure. The system may be configured to manage delay status report (DSR).

[0151] 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.

[0152] According to example embodiments, the operations of method 700 may be performed after the operations of method 200 is performed. In particular, according to example embodiments, the operations of method 700 may be performed after the system (e.g., base station) allocates resources to the UE with prioritized scheduling for the target data (indicated in the DSR).

[0153] As illustrated in FIG. 7, at operation S710, the system may be configured to detect scheduling failure associated with the target data.

[0154] The scheduling failure may refer to an event where the system (e.g., base station) is no longer able to allocate resource to the UE for transmission of the target data. Here, the scheduling failure may occur due to any causes, such as traffic congestions, and the like. Further, the system may detect the scheduling failure using any methods, techniques, tools, and the like. The method then proceeds to operation S720.

[0155] At operation S720, the system may be configured to transmit a DSR retransmission suppression request. The DSR retransmission suppression request may be transmitted to the UE, and may include a request to suppress retransmission of the DSR (the same DSR including information associated with target data as received during operation S210 in method 200).

[0156] In particular, since the system is unable to allocate resource to the UE for transmission of the target data due to the scheduling failure, the target data may not be transmitted from the UE to the system, and the UE may retransmit the DSR including information associated with target data to the system.

[0157] In this regard, the system may transmit the DSR retransmission suppression request to suppress such retransmission of the DSR and temporary stop the UE from retransmitting more DSR associated with the target data.

[0158] In response to receiving the DSR retransmission suppression request, the UE may suppress (temporary stop) retransmitting the DSR (including information associated with target data) to the system. In particular, the UE may interpret the DSR retransmission suppression request and adjust buffer status reporting accordingly.

[0159] According to example embodiments, the DSR retransmission suppression request may be in a MAC CE format. Here, the DSR retransmission suppression request in the MAC CE format may specify information associated with UE identification, LCG, cancellation reason (e.g., reason code), and the like.

[0160] According to example embodiments, the system may implement a congestion-aware DSR suppression threshold in order to ensure that high-priority data can still be retransmitted even if general suppression rules are active.

[0161] According to example embodiments, the DSR retransmission suppression request may include suppression configuration. The suppression configuration may specify various configurations and parameters associated with the suppression of the DSR retransmission. For example, the suppression configuration may specify exit conditions for resuming the DSR retransmission (e.g., time expiry, buffer change threshold, congestion and reporting overhead threshold, etc.)

[0162] According to example embodiments, the system may determine the suppression configuration based on a suppression rule. In particular, the system may configure rules to suppress unnecessary DSR retransmissions, preventing control signaling congestion. The suppression rule may be configured, for example, via RRC.

[0163] In response to receiving the DSR retransmission suppression request, the UE may recognize the DSR retransmission suppression request, and enter a suppressed state where DSR retransmission is suppressed based on the suppression configuration (e.g., with exit conditions).

[0164] Accordingly, the above processes may allow the system (e.g., base station) to signal the UE when their previously reported DSR information is no longer needed. This may subsequently eliminate unnecessary DSR retransmissions, reduce control signaling overhead, ensure that the UE does not repeatedly send buffer status updates when uplink scheduling constraints prevent resource allocation, and allow the UE to dynamically adjust retransmission behavior in order to ensure that new scheduling attempts are only made when necessary.

[0165] Subsequently, the UE may be prevented from continuing to retransmit DSR that cannot be scheduled (e.g., due to congestions).

[0166] As such, the above processes may allow for network-initiated DSR suppressions, ensuring that the DSR operations remains efficient and responsive to network scheduling conditions.Various Aspects of Embodiments

[0167] In view of the above, example embodiments of the present disclosure may allow the reporting of the DSR to be optimized to provide granular reporting while keeping signaling overhead minimal.

[0168] 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.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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 circuitryincluding, 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.

[0173] 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.

[0174] 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.

[0175] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computerreadable 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.

[0176] 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.

[0177] One or more components of the system of the example embodiments (e.g., base station, UE, etc.), as well as the operations associated therewith (e.g., one or more operations inFIG. 2 to FIG. 7, 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. 2 to FIG. 7 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.

[0178] FIG. 8 illustrates an embodiment of a system 800 for implementing one or more example embodiments. As shown in FIG. 8, the system 800 includes a processor 810, a memory 820, a storage component 830, an input component 840, an output component 850, a communication interface 860, and a bus 870.

[0179] The processor 810, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 810 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. The processor 810 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.

[0180] Memory 820 includes a non-transitory computer readable medium. Memory 820 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 opticalmemory) that stores information and / or instructions for use by processor 810. The memory 820 comprises machine-readable instructions which are executable by the processor 810. These machine-readable instructions when executed by the processor 810 causes the processor 810 to perform one or more method steps of an embodiment described herein.

[0181] Storage component 830 stores information and / or software related to the operation and use of the system 800. For example, storage component 830 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.

[0182] Input component 840 is configured to receive information, such as user input. For example, the input component 840 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 840 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0183] Output component 850 is configured to provide output information from the system 800. For example, the output component 850 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).

[0184] Communication interface 860 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 860 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 acommunication network that exists between the system 800 and other devices. In other words, the standard of the communication interface 860 is not limited.

[0185] The bus 870 acts as an interconnect between the processor 810, the memory 820, the storage component 830, the input component 840, the output component 850, and the communication interface 860 of the system 800. The bus 870 may include a wired interconnection or a wireless interconnection.

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

[0187] Further, according to example embodiments, the system 800 may include one or more elements from the system architecture described above in relation to FIG. 1. For example, the system 800 may include the base station or the UE.

[0188] 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.

[0189] 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.

[0190] 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, and is 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.

[0191] It should be noted that the AI / ML 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.

[0192] FIG. 9 is a diagram of an example of implementation environment 900 in which systems and / or method, described herein, may be implemented. The implementation environment900 includes a UE (User equipment) 910, a service environment 920, and a network 930. The service environment 920 include one or more sub-environments 921. To illustrate this, FIG. 9 shows, for convenience, examples of a 1st sub-environment 921-1, a 2nd sub-environment 921-2, and an N-th sub-environment 921-N (where N is any natural number).

[0193] The UE 910 is connected to the network 930, and the network 930 is connected to the service environment 920. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 910 and the service environment 920 are connected via the network 930.

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

[0195] The example figure 9 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.”

[0196] For example, the UE 910 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.

[0197] The service environment 920 is an environment that communicates with the UE 910 to provide one or more services. The service environment 920 receives information from the UE 910 and / or sends information to the UE 910. Also, the service environment 920 may generate and / or store information to be transmitted, as necessary. Also, the service environment 920 may store and / or process information that is received, as necessary. For example, the service environment 920 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.

[0198] The example figure 9 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.”

[0199] The one or more services provided by the service environment 920 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 UE 910, a service that stores informationfrom the UE 910, or a service that performs processing based on information from the UE 910 and returns the results of the processing.

[0200] In an embodiment, the Service Environments 920 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.

[0201] 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, when means 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.

[0202] The service environment 920 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 920 can be determined as appropriate. Additionally, if the serviceenvironment 920 includes one or more sub-environments 921, the placement of devices can be determined based on predetermined policies for each sub-environment 921. For example, devices related to the first service may be placed in the 1st sub-environment 921-1, and devices related to the second service may be placed in the 2nd sub-environment 921-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 921-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 921-2. In this way, specific devices can be placed in specific sub -environments 921. Conversely, each sub-environment 921 can be specialized for a particular purpose.

[0203] 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.

[0204] The network 930 is a network that exchanges information between the UE 910 and the service environment 920. The network 930 includes one or more wired and / or wireless networks.

[0205] For example, the network 930 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.

[0206] The network 930 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 930 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 920 could be in the core network, in which case the network 930 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0207] The number and arrangement of devices and networks shown in FIG. 9 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.

[0208] 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: receive a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is delay-critical; identify that the DSR comprises the delay- critical flag; and allocate resources to the UE with prioritized scheduling for the target data.Item [2]: The system according to item [1], wherein the DSR may include a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE may include a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.Item [3]: The system according to one of items [l]-[2], wherein the DSR may further include a priority indicator indicating a priority associated with the target data.Item [4]: The system according to one of items [l]-[3], wherein the delay-critical flag may be in a bit format.Item [5]: The system according to one of items [l]-[4], wherein the base station may be further configured to: detect scheduling failure associated with the target data; determine an extended interval associated with retransmission of the DSR based on a type of the target data; and transmit, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.Item [6]: The system according to one of items [l]-[5], wherein the base station may be further configured to: detect scheduling failure associated with the target data; and transmit, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.Item [7]: The system according to one of items [l]-[6], wherein the base station may be further configured to: receive, from the UE, a DSR cancellation request to cancel resource allocation for the target data; and cancel resource allocation for the target data.Item [8]: A method that may include: receiving a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is delay-critical; identifying that the DSR comprises the delay-critical flag; and allocating resources to the UE with prioritized scheduling for the target data.Item [9]: The method according to item [8], wherein the DSR may include a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE mayinclude a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.Item

[0010] : The method according to one of items [8]-[9], wherein the DSR may further include a priority indicator indicating a priority associated with the target data.Item

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

[0010] , wherein the delay-critical flag may be in a bit format.Item

[0012] : The method according to one of items [8]-[l 1], wherein the method may further include: detecting scheduling failure associated with the target data; determining an extended interval associated with retransmission of the DSR based on a type of the target data; and transmitting, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.Item

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

[0012] , wherein the method may further include: detecting scheduling failure associated with the target data; and transmitting, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.Item

[0014] : The method according to one of items [8]-[l 3], wherein the method may further include: receiving, from the UE, a DSR cancellation request to cancel resource allocation for the target data; and cancelling resource allocation for the target data.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: receiving a delay status report (DSR) including information associatedwith target data in a buffer of a user equipment (UE), wherein the DSR may include a delay-critical flag indicating that target data is delay-critical; identifying that the DSR comprises the delay-critical flag; and allocating resources to the UE with prioritized scheduling for the target data.Item

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

[0015] , wherein the DSR may include a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE may include a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.Item

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

[0015] -

[0016] , wherein the DSR may further include a priority indicator indicating a priority associated with the target data.Item

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

[0015] -

[0017] , wherein the delay-critical flag may be in a bit format.Item

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

[0015] -

[0018] , wherein the method may further include: detecting scheduling failure associated with the target data; determining an extended interval associated with retransmission of the DSR based on a type of the target data; and transmitting, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.Item

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

[0015] -

[0019] , wherein the method may further include: detecting schedulingfailure associated with the target data; and transmitting, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.

[0209] 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.Additional Disclosures

[0210] 3GPP TSG-RAN WG2 Meeting #129 R2-DSR

[0211] Agenda Item: 8.7.4.2

[0212] Source: Rakuten Mobile

[0213] Title: Discussion on enhanced DSR for XR

[0214] Document for: Discussion and Decision

[0215] 1 Introduction

[0216] In RAN2 some agreements of enhanced DSR had been reached as below.

[0217] As Rel-19 introduces enhanced DSR mechanisms, including multiple reporting thresholds per LCG, several technical gaps remain in ensuring efficient scheduling and optimal resource allocation. Previous agreements in RAN2#127bis and RAN2#128 have clarified aspects such as buffer segmentation, threshold configurations, and interworking with Rel-18 DSR, but certain issues require further refinements to:

[0218] Optimize DSR for UEs transmitting both delay-critical and non-del ay -critical traffic, ensuring that non-urgent data does not interfere with time-sensitive scheduling decisions.

[0219] Introduce explicit DSR cancellation mechanisms, allowing both network and UE-triggered cancellation to reduce redundant signaling and improve scheduling efficiency.

[0220] Ensure compatibility between Rel-18 and Rel-19 DSR implementations, minimizing disruptions when legacy and enhanced UEs coexist in the same scheduling environment.

[0221] Improve the coordination between DSR triggering and retransmission mechanisms, ensuring that buffer status updates remain relevant and dynamic scheduling decisions are properly aligned.

[0222] This contribution provides a refined framework for further DSR enhancements, addressing the remaining technical gaps while ensuring that the proposed refinements align with recent agreements in RAN2.

[0223] 2 Discussion

[0224] 2.1 Optimizing DSR MAC CE Design for Mixed Delay-Critical and Non-Delay- Critical Traffic

[0225] The current DSR MAC CE format in Rel-18 and early Rel-19 discussions is designed to report aggregate buffer size per LCG, but it lacks the ability to differentiate between delay-sensitive and non-delay-sensitive data. This leads to inefficiencies in scheduling, particularly in cases where:

[0226] A UE has a mix of time-sensitive and background traffic in its buffer but cannot explicitly inform the network which portion requires immediate scheduling.

[0227] The gNB assumes that all reported buffer data is urgent, leading to inefficient UL resource allocation that may delay truly urgent traffic from other UEs.

[0228] Multiple UEs compete for limited uplink grants, and the scheduler prioritizes buffer size rather than true urgency, leading to potential misallocations of scheduling resources.

[0229] For example, in an XR application, a UE may have:

[0230] Real-time motion-tracking data (latency-critical) that must be scheduled immediately.

[0231] Background texture updates (non-delay-critical) that can be scheduled opportunistically.

[0232] However, since both traffic types are aggregated in the same DSR buffer size report, the scheduler may assume all data requires urgent scheduling, potentially delaying other UEs that have genuinely high-priority traffic.

[0233] Furthermore, with Rel-19 introducing multiple reporting thresholds per LCG, the MAC CE format must evolve to support more granular, yet efficient, delay reporting. The challenge is ensuring that the additional threshold information does not lead to excessive signaling overhead while still providing the scheduler with the necessary granularity for intelligent uplink resource allocation.

[0234] Several MAC CE designs have been proposed in RAN2, including:

[0235] Bitmap-Based Reporting - A bitmap per LCG that indicates which reporting pairs are present. This approach provides structured reporting but can increase MAC CE size when multiple LCGs are reported.

[0236] Extension Bit Per Pair - One additional bit per reporting pair, which reuses existing reserved bits in Rel-18 DSR. This ensures compact signaling but requires dynamic parsing at the gNB.

[0237] An additional concern is how the MAC CE should be parsed when multiple LCGs are reported simultaneously. If each LCG has multiple reporting thresholds, the MAC CE size may increase significantly, affecting control channel efficiency. A structured approach that dynamically scales the number of reported pairs based on network requirements is required.

[0238] A potential refinement to address both challenges — the lack of delay-critical differentiation and the MAC CE size inefficiency — is to introduce a dual-buffer structure in the MAC CE, allowing UEs to:

[0239] Report delay-sensitive and non-delay-sensitive buffer sizes separately, ensuring that the gNB correctly prioritizes scheduling.

[0240] Dynamically adjust reporting format based on available control signaling resources, ensuring that only the most critical buffer updates are transmitted when control overhead is constrained.

[0241] By combining these refinements, the DSR MAC CE format can be optimized to provide granular traffic reporting while keeping signaling overhead minimal.

[0242] Observation 1:

[0243] Current DSR MAC CE formats do not fully support scalable, priority -aware reporting, leading to potential inefficiencies when handling both delay-critical and non-delay-critical traffic.

[0244] Proposal la:

[0245] Introduce a Delay-Critical Data Flag within the DSR MAC CE, allowing the UE to explicitly indicate which portion of the reported buffer requires immediate scheduling.

[0246] Proposal lb:

[0247] Define a dual-buffer reporting structure in the MAC CE, allowing UEs to report delay-sensitive and non-delay-sensitive buffer sizes separately, ensuring that scheduling prioritization remains efficient.

[0248] Proposal 1c:

[0249] Implement a DSR Field Priority Indicator, allowing the UE to signal only the most urgent delay status updates, dynamically adjusting the reporting format based on available control signaling resources.

[0250] Define whether the priority field should be reported per PDU Set or per LCG to avoid excessive MAC CE signaling overhead.

[0021] 2.2 Adaptive DSR Retransmission to Prevent Unnecessary Control Signaling

[0252] One of the persistent inefficiencies in current DSR retransmission logic is that UEs continue sending updated DSRs even when uplink grants are constrained, leading to unnecessary control signaling. This is particularly problematic in scenarios where:

[0253] A gNB has already deprioritized a UE’s buffer report due to congestion but the UE keeps triggering DSR updates, consuming PUCCH resources that could be used for other control signaling.

[0254] Multiple UEs experience scheduling delays, causing a build-up of redundant DSR retransmissions, ultimately leading to PUCCH congestion and inefficient resource utilization.

[0255] Currently, DSR retransmissions do not account for scheduling feedback from the gNB. Even if a gNB does not immediately schedule an uplink grant, the UE keeps retransmitting DSRs at regular intervals, assuming that the buffer status remains unchanged. Instead, a smarterretransmission strategy is required — one that allows UEs to suppress redundant reports if network feedback indicates resource constraints.

[0256] A possible solution is to introduce a Dynamic DSR Retransmission Suppression Mechanism, where:

[0257] If the gNB does not schedule UL resources after receiving a DSR, the UE delays retransmission until a specified hold-off period has passed.

[0258] The UE only re-triggers a DSR if the buffer status changes significantly, rather than relying on periodic retransmissions.

[0259] If a DSR has been ignored multiple times, the UE should switch to an extended retransmission interval, preventing excessive PUCCH usage.

[0260] Observation 2:

[0261] Current DSR retransmission behavior leads to excessive control signaling, particularly in congestion scenarios where the gNB cannot schedule UL grants immediately.

[0262] Proposal 2a:

[0263] Introduce a congestion-aware DSR suppression threshold, ensuring that high-priority data can still be retransmitted even if general suppression rules are active.

[0264] Proposal 2b:

[0265] Implement an Extended Retransmission Interval Mode, where UEs progressively extend the time between retransmitted DSRs if scheduling opportunities remain unavailable.

[0266] 2.3 Configurable DSR Reporting for Different Traffic Types

[0267] Another aspect discussed in previous RAN2 meetings is whether DSR reporting behavior should vary based on traffic type, rather than applying a uniform reporting mechanismacross all services. Some companies have raised concerns that treating all traffic the same may lead to inefficient scheduling, particularly for applications like XR and streaming services, which require continuous buffer updates, versus burst-based traffic that only requires occasional reporting.

[0268] For instance, an XR application with strict latency constraints may require higher reporting frequency, while a non-interactive background process may not need frequent DSR updates. However, current DSR procedures do not provide a way for networks to differentiate reporting rules based on service type, leading to potential inefficiencies in how different traffic classes compete for uplink scheduling.

[0269] One possible enhancement is to introduce Configurable DSR Reporting Classes, where:

[0270] DSR reporting intervals and thresholds can be dynamically configured per traffic type, ensuring that different applications receive scheduling priority based on service requirements.

[0271] The network can signal adaptive DSR configurations, allowing gNBs to adjust reporting rules dynamically for different QoS profiles.

[0272] UEs can apply different DSR transmission logic for interactive vs. background data, ensuring more efficient uplink buffer management.

[0273] Observation s:

[0274] Current DSR procedures do not differentiate reporting frequency or triggering logic based on traffic type, leading to potential inefficiencies in scheduling priority between interactive and non-interactive services.

[0275] Proposal 3a:

[0276] Introduce Configurable DSR Reporting Classes, where DSR reporting intervals and triggering rules are dynamically adjusted based on traffic type.

[0277] Proposal 3b:

[0278] Allow network-controlled DSR adaptation, where gNBs can configure different DSR behavior based on QoS profiles, ensuring that interactive applications receive prioritized scheduling.

[0279] Define gNB-configurable DSR reporting adaptation, where the network can adjust UE reporting behavior dynamically based on congestion levels and resource availability.

[0280] 2.4 Introducing Explicit DSR Cancellation Mechanisms

[0281] Background and Problem Statement

[0282] While DSR plays a crucial role in uplink scheduling efficiency, one of its key inefficiencies is that there is no mechanism for the gNB to cancel a previously received DSR report, even if the network determines that uplink resources cannot be allocated. In such cases, UEs may continue to attempt retransmitting their buffer status, leading to:

[0283] Redundant control signaling, particularly when UL grants remain unavailable.

[0284] Increased PUCCH congestion, as multiple UEs repeatedly report unschedulable DSR information.

[0285] Potential scheduling inefficiencies, as repeated DSR retransmissions may interfere with more urgent control signals.

[0286] Rel-18 DSR already relies on triggering and cancellation based on predefined UE conditions, but in cases where a network-wide congestion event prevents scheduling, there is no way for the gNB to explicitly instruct UEs to stop sending further DSR updates.

[0287] Rel-19, with its multi-threshold reporting enhancements, increases the complexity as UEs may report more frequent and granular delay status updates, further exacerbating congestion-related inefficiencies when scheduling resources are unavailable.

[0288] An effective way to resolve this issue is to introduce a network-triggered DSR cancellation mechanism, allowing the gNB to signal UEs when their previously reported DSR information is no longer needed, thus:

[0289] Eliminating unnecessary DSR retransmissions, reducing control signaling overhead.

[0290] Ensuring that UEs do not repeatedly send buffer status updates when uplink scheduling constraints prevent resource allocation.

[0291] Allowing UEs to dynamically adjust retransmission behavior, ensuring that new scheduling attempts are only made when necessary.

[0292] Additionally, UEs should be able to autonomously cancel a pending DSR report if:

[0293] The UE buffer state changes significantly, rendering the previous DSR report outdated.

[0294] Multiple scheduling attempts have failed, and the UE determines that re-reporting is inefficient.

[0295] This dual-triggered approach — allowing both network-initiated and UE-initiated DSR cancellations — ensures that Rel-19 DSR remains efficient and responsive to network scheduling conditions.

[0296] Observation 4:

[0297] Current DSR mechanisms do not provide an explicit cancellation method, leading to redundant reporting when uplink resources are unavailable.

[0298] Proposal 4a:

[0299] Introduce a DSR Cancellation MAC CE, allowing the gNB to signal UEs when previously reported buffer status information is no longer required, reducing unnecessary retransmissions.

[0300] Proposal 4b:

[0301] Introduce a DSR Cancellation Confirmation Mechanism, where the gNB confirms the cancellation to the UE, preventing unintended retransmissions of previously reported data.

[0302] Define HARQ interaction rules, ensuring that a DSR is not canceled if related data is still in the HARQ retransmission process.

[0303] Proposal 4c:

[0304] Define a network-controlled DSR rejection mechanism, ensuring that UEs do not continue retransmitting reports that cannot be scheduled due to congestion.

[0305] Proposal 4d:

[0306] Allow UE-initiated DSR cancellations in cases where the application layer determines that certain delay-sensitive data is no longer relevant (e.g., expired XR frames)

[0307] 3 Conclusion

[0308] 4 References

[0309] R2 128 R18 MBS, R18 QoE and R19 XR session notes (Dawid) EOM.docx

[0310] Annex -

[0311] Enhancements to DSR Contributions with Stage-1, Stage-2, and Stage-3 Implementation in Standards

[0312] To solidify the contribution for provisional patent filing and align with 3GPP Stage- 1, Stage-2, and Stage-3 processes, we will refine each proposal by specifying:

[0313] Stage-1 (Requirements Stage) —> High-level functional requirements, identifying the need for a feature and defining its value in terms of network efficiency.

[0314] Stage-2 (Architecture and Procedures Stage) Specification of RAN2 protocollevel changes needed to support the feature, ensuring compatibility with existing network functions.

[0315] Stage-3 (Protocol Signaling Stage) —> Definition of specific MAC / RRC protocol changes, signaling messages, and procedural details.

[0316] 2.1 Optimizing DSR MAC CE Design for Mixed Delay-Critical and Non-Delay- Critical Traffic

[0317] Proposal la: Introduce a Delay-Critical Data Flag within the DSR MAC CE

[0318] Stage-1 (Requirements Stage):

[0319] Define a mechanism that allows the UE to explicitly indicate which portion of its reported buffer contains delay-sensitive data, preventing non-critical data from consuming scheduling resources unnecessarily.

[0320] Stage-2 (Architecture and Procedures Stage):

[0321] Introduce a new Delay-Critical Data Flag within the MAC CE format.

[0322] Ensure the gNB prioritizes scheduling decisions based on the presence of this flag, reducing misallocation of resources for non-time-sensitive traffic.

[0323] Stage-3 (Protocol Signaling Stage):

[0324] Modify MAC CE format to include a 1 -bit Delay-Critical Data Flag per LCG.

[0325] Define RRC signaling support, allowing the gNB to configure per-LCG DSR reporting thresholds based on traffic priority.

[0326] Proposal lb: Define a Dual -Buffer Reporting Structure in the MAC CE

[0327] Stage- 1 (Requirements Stage):

[0328] Enable separate reporting of delay-sensitive and non-delay-sensitive buffer sizes to prevent unnecessary UL resource allocation for non-critical data.

[0329] Stage-2 (Architecture and Procedures Stage):

[0330] Extend the DSR MAC CE format to include two separate buffer size fields:

[0331] One for delay -critical data.

[0332] One for non-delay-critical data.

[0333] Ensure that gNB scheduling behavior considers both buffer size reports independently.

[0334] Stage-3 (Protocol Signaling Stage):

[0335] Modify the MAC CE format to define separate buffer size fields:

[0336] B_delay_critical (buffer size of delay-sensitive data).

[0337] B non critical (buffer size of non-delay-sensitive data).

[0338] Define RRC signaling to allow per-LCG threshold adaptation, ensuring that the gNB can configure separate DSR triggering thresholds for del ay -critical vs. non-delay-critical traffic.

[0339] Proposal 1c: Implement a DSR Field Priority Indicator

[0340] Stage- 1 (Requirements Stage):

[0341] Introduce a mechanism that allows the UE to specify the urgency level of a reported buffer, ensuring that high-priority data is scheduled first.

[0342] Stage-2 (Architecture and Procedures Stage):

[0343] Define a priority weight system within the DSR MAC CE, allowing UEs to classify buffer status reports as High, Medium, or Low priority.

[0344] Ensure that the gNB scheduling algorithm can interpret these priority levels and make resource allocation decisions accordingly.

[0345] Stage-3 (Protocol Signaling Stage):

[0346] Extend the DSR MAC CE format with a 2 -bit Priority Indicator (e.g., 00 = Low, 01 = Medium, 10 = High).

[0347] Modify RRC signaling procedures to allow the network to configure default priority mapping based on traffic class and QoS profile.

[0348] 2.2 Adaptive DSR Retransmission to Prevent Unnecessary Control Signaling

[0349] Proposal 2a: Allow the gNB to Configure DSR Suppression Rules

[0350] Stage- 1 (Requirements Stage):

[0351] Define a mechanism where gNB can configure rules to suppress unnecessary DSR retransmissions, preventing control signaling congestion.

[0352] Stage-2 (Architecture and Procedures Stage):

[0353] Introduce RRC signaling messages that allow the gNB to configure suppression thresholds based on network congestion levels.

[0354] Ensure that UEs can recognize suppression indications and adjust DSR retransmission behavior accordingly.

[0355] Stage-3 (Protocol Signaling Stage):

[0356] Define a new MAC CE suppression indicator, allowing the gNB to explicitly instruct a UE to delay or stop sending redundant DSR reports.

[0357] Modify the UE behavior so that DSR retransmission timers are dynamically adjusted based on gNB suppression signals.

[0358] Proposal 2b: Implement an Extended Retransmission Interval Mode

[0359] Stage- 1 (Requirements Stage):

[0360] Introduce an adaptive retransmission interval that prevents excessive control signaling during congestion.

[0361] Stage-2 (Architecture and Procedures Stage):

[0362] Ensure that UEs dynamically extend DSR retransmission intervals if prior DSRs have not resulted in UL grant allocations.

[0363] Stage-3 (Protocol Signaling Stage):

[0364] Define RRC parameters for configuring Extended Retransmission Mode, allowing the gNB to specify:

[0365] Maximum delay before a suppressed DSR is re-transmitted.

[0366] Rules for extending retransmission intervals dynamically.

[0367] 2.3 Introducing Explicit DSR Cancellation Mechanisms

[0368] Proposal 3a: Introduce a DSR Cancellation MAC CE

[0369] Stage- 1 (Requirements Stage):

[0370] Define a mechanism where the gNB can explicitly cancel previously received DSR reports, ensuring that UEs do not retransmit buffer status that the network cannot schedule.

[0371] Stage-2 (Architecture and Procedures Stage):

[0372] Introduce a DSR Cancellation MAC CE that allows the gNB to send cancellation commands to specific UEs, reducing unnecessary retransmissions.

[0373] Ensure that UEs correctly interpret cancellation messages and adjust buffer status reporting accordingly.

[0374] Stage-3 (Protocol Signaling Stage):

[0375] Define MAC CE message format for DSR cancellation, including:

[0376] UE identifier.

[0377] LCG information.

[0378] Cancellation reason code (e.g., congestion, scheduling failure).

[0379] Proposal 3b: Define a DSR Cancellation Flag for UE-Initiated Cancellation

[0380] Stage- 1 (Requirements Stage):

[0381] Allow UEs to autonomously cancel a DSR if they determine that the reported buffer data is no longer valid or useful.

[0382] Stage-2 (Architecture and Procedures Stage):

[0383] Introduce a cancellation flag within the MAC CE, allowing UEs to indicate that a previously reported buffer status is no longer relevant.

[0384] Ensure that the gNB acknowledges and stops processing the canceled DSR reports.

[0385] Stage-3 (Protocol Signaling Stage):

[0386] Modify MAC CE format to include a DSR Cancellation Flag, ensuring that both the UE and the gNB maintain synchronization on buffer status reporting.

[0387] Define an RRC signaling update, allowing the network to configure rules for when UEs can autonomously cancel DSRs.

Claims

What is claimed is:

1. A system comprising:a base station configured to:receive a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR comprises a delay-critical flag indicating that target data is delay-critical;identify that the DSR comprises the delay-critical flag; andallocate resources to the UE with prioritized scheduling for the target data.

2. The system according to claim 1, wherein the DSR comprises a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE comprises a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.

3. The system according to claim 1, wherein the DSR further comprises a priority indicator indicating a priority associated with the target data.

4. The system according to claim 1, wherein the delay-critical flag is in a bit format.

5. The system according to claim 1, wherein the base station is further configured to:detect scheduling failure associated with the target data;determine an extended interval associated with retransmission of the DSR based on a type of the target data; andtransmit, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.

6. The system according to claim 1, wherein the base station is further configured to:detect scheduling failure associated with the target data; andtransmit, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.

7. The system according to claim 1, wherein the base station is further configured to:receive, from the UE, a DSR cancellation request to cancel resource allocation for the target data; andcancel resource allocation for the target data.

8. A method comprising:receiving a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR comprises a delay-critical flag indicating that target data is delay-critical;identifying that the DSR comprises the delay-critical flag; andallocating resources to the UE with prioritized scheduling for the target data.

9. The method according to claim 8, wherein the DSR comprises a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE comprises a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.

10. The method according to claim 8, wherein the DSR further comprises a priority indicator indicating a priority associated with the target data.

11. The method according to claim 8, wherein the delay-critical flag is in a bit format.

12. The method according to claim 8, further comprising:detecting scheduling failure associated with the target data;determining an extended interval associated with retransmission of the DSR based on a type of the target data; andtransmitting, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.

13. The method according to claim 8, further comprising:detecting scheduling failure associated with the target data; andtransmitting, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.

14. The method according to claim 8, further comprising:receiving, from the UE, a DSR cancellation request to cancel resource allocation for the target data; andcancelling resource allocation for the target data.

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:receiving a delay status report (DSR) including information associated with target data in a buffer of a user equipment (UE), wherein the DSR comprises a delay-critical flag indicating that target data is delay-critical;identifying that the DSR comprises the delay-critical flag; andallocating resources to the UE with prioritized scheduling for the target data.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the DSR comprises a DSR media access control (MAC) control element (CE), and wherein the DSR MAC CE comprises a first buffer size field associated with delay-critical data and a second buffer size field associated with non-delay-critical data.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the DSR further comprises a priority indicator indicating a priority associated with the target data.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the delay-critical flag is in a bit format.

19. The non-transitory computer-readable recording medium according to claim 15, wherein the method further comprises:detecting scheduling failure associated with the target data;determining an extended interval associated with retransmission of the DSR based on a type of the target data; andtransmitting, to the UE, a DSR retransmission extension request to extend an interval associated with retransmission of the DSR according to the determined extended interval.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the method further comprises:detecting scheduling failure associated with the target data; andtransmitting, to the UE, a DSR retransmission cancellation request to cancel retransmission of the DSR.

Images