WO2026015174A1

WO2026015174A1 - Delay status report and feedback for uplink scheduling

Info

Publication number: WO2026015174A1
Application number: PCT/US2025/018853
Authority: WO
Inventors: Awn Muhammad; Pankaj Tanaji SHETE
Original assignee: Rakuten Mobile Inc; Rakuten Symphony Usa LLC
Current assignee: Rakuten Mobile Inc; Rakuten Symphony Usa LLC
Priority date: 2024-07-09
Filing date: 2025-03-07
Publication date: 2026-01-15
Anticipated expiration: 2027-01-09

Abstract

Example embodiments of the present disclosure relate to delay status report and feedback for uplink scheduling. According to example embodiments, a method may include receiving, by a gNodeB (gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration.

Description

DELAY STATUS REPORT AND FEEDBACK FOR UPLINK SCHEDULING

TECHNICAL FIELD

[0001] The present disclosure relates to delay status report and feedback for uplink scheduling.

BACKGROUND

[0002] The information disclosed in this background section is only for the 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.

[0003] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and/or software of a particular RAN is vendor specific.

[0004] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and/or software to a telecommunications system. Since different vendors are involved, the type of hardware and/or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based), or could be in physical hardware form (e.g., non-VM based).

[0005] To this end, O-RAN disaggregates the RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and/or Packet Data

Convergence Protocol (PDCP) sublayers of the RAN. The DU maybe a logical node hosting Radio

Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] FIG. 1 illustrates an O-RAN architecture in the related art. RAN functions in the O-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the O-RAN system, as well as to automate and optimize RAN operations. As shown in FIG. 1 , the RIC may be divided into two types: a non-real-time RIC (Non- RT RIC) 120 and a near-real-time RIC (Near-RT RIC) 130.

[0007] The Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within a Service Management and Orchestration (SMO) framework 110. Its functionalities may be implemented through modular applications called rApps, and may include: providing policy based guidance and enrichment across the Al interface, which is the interface that enables communication between the Non-RT RIC and the Near-RT RIC; performing data analytics; Artificial Intelligence/Machine Learning (AI/ML) training and inference for RAN optimization; and/or recommending configuration management actions over the 01 interface, which may be the interface that connects the SMO to RAN managed elements (e.g., Near-RT RIC 130, O-RAN Centralized Unit (O-CU) 140,150, O-RAN Distributed Unit (O-DU) 170, etc.). [0008] The Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-DU 170, the O-CU (disaggregated into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and an open evolved NodeB (O- eNB) 160 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes/network functions (NFs)) over a near-real-time control loop. The Near-RT RIC 130 may monitor, suspend/stop, override, and control the E2 nodes (O-CU 140,150, O-DU 170, and O-eNB 160) via policies. For example, the Near-RT RIC 130 may set policy parameters on activated functions of the E2 nodes. Further, the Near-RT RIC 130 may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc.

[0009] Here, the O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via the El interface, and may be coupled to the O-DU 170 via the Fl-c interface and Fl-u interface, respectively. Further, the O-RU 180 may be coupled to the O-DU 170 via the Open Fronthaul (OF) Control (C), User (U), Synchronization (S), and Management (M) Planes, and may be coupled to the SMO 110 via the OF M-Plane.

[0010] The two types of RICs work together to optimize the O-RAN. For example, the Non-RT RIC 120 may provide the policies, data, and AI/ML models enforced and used by the Near-RT RIC 130 for RAN optimization, and the Near-RT RIC 130 may return policy feedback (i.c. , how the policy set by the Non-RT RIC 120 works).

[0011] As mentioned above, the Non-RT RIC 120 may be located within the SMO framework 110, which manages and orchestrates RAN elements. Specifically, the SMO 110 may manage and orchestrate what is referred to as the O-Ran Cloud (O-Cloud) 190. The O-Cloud 190 may be a collection of physical RAN nodes that host the RICs, O-CUs, and O-DUs, the supporting software components (e.g., the operating systems and runtime environments), and the SMO 110 itself. In other words, the SMO 110 may manage the O-Cloud 190 from within. The 02 interface may be the interface between the SMO 110 and the O-Cloud 190 it resides in. Through the 02 interface, the SMO 110 may provide infrastructure management services (IMS) and deployment management services (DMS).

[0012] In the related art, a delay status report (DSR) may be sent by a base station (e.g., O-eNB 160 or gNodeB (gNB) in 5G) to a user equipment (UE), e.g. O-RU 170, to be used by the UE for scheduling in uplink.

[0013] In the related art, uplink scheduling may include using Logical Channel Prioritization (LCP) restriction, which is a parameter which may allow for the selection of a logical channel in uplink. LCP restriction is typically focused on providing a structured approach to resource allocation.

SUMMARY

[0014] DSR mechanisms in the related art lack a feedback component that informs the UE about the treatment of delay-critical data after its reporting. This absence of feedback can lead to uncertainty in the management of high-priority and delay-sensitive data, possibly causing suboptimal transmission strategies, heightened packet loss, or delays. If the gNB were able to provide feedback indicating which Service Data Unit’s (SDUs) arc scheduled for transmission and which are at risk of expiration, the UE could more effectively prioritize its transmissions and possibly forego attempts to resend SDUs that are unlikely to be delivered in time.

[0015] In addition, existing DSR mechanisms in the related art fail to consider the varied urgency and priority of all data types within the buffer, potentially delaying the transmission of high-priority data, also it does not provide the granularity required to effectively differentiate between delay-critical and non-delay-critical data, this may impact servicing critical SDU’s that needs to be served despite not having delay criticality information, it fails to consider the varied urgency and priority of all data types within the buffer, potentially delaying the transmission of high-priority data.

[0016] LCP restriction enhancements in the related art, while providing a structured approach to resource allocation, would be less flexible as they typically involve more static and predefined criteria for resource allocation.

[0017] Accordingly, there is a need for an improved DSR mechanism which can incorporate a feedback component that includes considering the priority and urgency of data, as well as being less reliant on LCP restriction.

[0018] According to example embodiments, a method may include receiving, by a gNodeB

(gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration.

[0019] Based on the above example embodiments, the DSR feedback report may, for example, allow for feedback to be generated such that DU sets (SDU, PDU) that are to be scheduled and at risk of expiration can be determined, based on the DSR report including the status of one or more DU sets. Example embodiments may also be less reliant on LCP restriction and have a greater focus on LCH based prioritization.

[0020] According to example embodiments, a gNodeB (gNB) may be provided and configured to: receive a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); schedule the one or more DU sets based on the DSR message; and generate a first DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration.

[0021] According to example embodiments, a non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method may be provided, the method including: receiving, by a gNodeB (gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration.

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

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

[0024] FIG. 1 illustrates an example O-RAN architecture according to the related art, in which one or more example embodiments may be applied;

[0025] FIG. 2 illustrates a callflow diagram for DSR and feedback transmission, according to one or more example embodiments;

[0026] FIG. 3 illustrates an example DSR message format for SDU, according to one or more example embodiments;

[0027] FIG. 4, illustrates an example DSR message format for XR uplink and PDU, according to one or more example embodiments; [0028] FIG. 5, illustrates an example feedback report format, according to one or more example embodiments;

[0029] FIG. 6 illustrates a block diagram of an example method for DSR and feedback transmission, according to one or more example embodiments;

[0030] FIG. 7 illustrates a block diagram of an example device for implementing one or more example embodiments; and

[0031] FIG. 8 illustrates a block diagram of an example environment for implementing one or more example embodiments.

DETAILED DESCRIPTION

[0032] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above 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 one of the various embodiments. 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).

[0033] 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 limited to the described implementations. Thus, the operation and behavior of the systems and/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.

[0034] Even though particular combinations of features are disclosed in the claims and/or in the specification, these 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. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0035] 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” 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.

[0036] 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. [0037] Example embodiments may focus on LCH prioritization over enhancing LCP restrictions for managing uplink scheduling of delay-critical data. Prioritization based on LCH allows for more dynamic and responsive scheduling that can be adapted in real-time to the urgency of the data packets. Example methods may minimize the delay for critical data by adjusting the priority dynamically based on the SDU’s proximity to its deadline, which is crucial for applications requiring strict timing like XR services. In contrast, LCP restriction enhancements, while providing a structured approach to resource allocation, are less flexible as they typically involve more static and predefined criteria for resource allocation, as explained above.

[0038] Example embodiments may introduce a feedback mechanism after DSR and scheduling that allows the network to send back information to the UE regarding the scheduling and expiration status of data reported in DSRs. This feedback would specifically inform the UE which SDU’s have been prioritized for imminent transmission and which are likely to be expired due to inability to meet the delay requirements.

[0039] Example embodiments may improve the DSR MAC Control Element to introduce multi-tiered reporting for each Logical Control Group (LCG), which would detail the urgency (e.g., delay criticality) and buffer sizes for different data priority levels, thereby enhancing gNB’s decision-making capabilities regarding resource allocation.

[0040] Example embodiments may include a priority indicator field, which is a new bit field to indicate the priority of the packet. This could be integrated, for example, into a DSR MAC Control Element (CE) structure, where a 'priority level' field may specifies if the data is high or low priority. [0041] Example embodiments may augment the buffer size reporting to differentiate between high-priority and low-priority data within each LCG. This could be implemented, for example, by adding a second buffer size field exclusively for high-priority data.

[0042] Example embodiments may modify a remaining time field to include multiple entries per LCG, each corresponding to different priority levels or individual PDU sets, to provide more granular control over scheduling decisions based on urgency.

[0043] Example embodiments may also revise the LCGi field to reflect the complexity of the data reported, indicating whether the DSR includes high-priority, low-priority, or both types of data.

[0044] According to example embodiments, a method may include receiving, by a gNodeB (gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration.

[0045] Based on the above example embodiments, the DSR feedback report may, for example, allow for feedback to be generated such that DU sets (SDU, PDU) that are to be scheduled and at risk of expiration can be determined, based on the DSR report including the status of one or more DU sets. Example embodiments may also be less reliant on LCP restriction and have a greater focus on LCH based prioritization.

[0046] 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. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.

[0047] FIG. 2 illustrates a callflow diagram for DSR and feedback transmission, according to one or more example embodiments.

[0048] Referring to FIG. 2, gNodeB 200 (gNB) and user equipment 210 may be provided.

[0049] At step 1, gNB 200 may send a RRC configuration message to UE 210. This may be performed during the initial connection setup between gNB 200 and UE 210. According to embodiments, this RRC connection message may include a feedback configuration information element (IE) indicating that DSR feedback is enabled. The feedback IE are regarding the scheduling and expiration status of SDU sets. An example of parameters which may be included in the RRC reconfiguration message are as follows:

RRC Reconfiguration:

- Feedbackconfiguration:

- DSRFeedbackEnabled: TRUE/FALSE

- FeedbackReportinglnterval: [Value]

- FeedbackType: [SDU Set/Individual SDU]

[0050] DSRFeedbackEnabled may indicates whether feedback will be provided after a DSR. FeedbackReportinglnterval may specify the interval at which feedback will be provided, if applicable. FeedbackType may specify whether the feedback pertains to SDU Sets or individual SDUs.

[0051] Enhancements to the RRC signaling may also include configuration procedures for configuring and managing the feedback mechanism via RRC signaling. [0052] At step 2, gNB 200 may receive a delay status report (DSR) message from UE 210. The DSR message may report the status of DU (e.g., SDU, PDU) sets. An example of DSR message format is described later on (with reference to FIG. 3 and FIG. 4 below).

[0053] At step 3, gNB 200 may perform scheduling based on the DSR message in step 2. This scheduling may be based on parameters included in the DSR message, such as priority of the DU sets, and their remaining time. Other examples of parameters which may be included (and not necessarily be limited to) in the DSR message may be buffer size, QoS level, and time sensitivity. [0054] At step 4, gNB 200 may generate feedback based on the DSR message in step 2. The gNB 200 may evaluate which SDU sets are scheduled, and which are at risk of expiration, then generate a feedback report. An example format of the feedback report is described later on (with reference to FIG. 5 below).

[0055] At step 5, gNB 200 may transmit the feedback generated in step 4 to UE 210. This may be performed using a MAC Control Element (CE). According to embodiments, the feedback may be generated and sent periodically based on a predetermined time interval (e.g., every 20ms). [0056] At step 6, UE 210 may adjust the transmission strategy of uplink to the gNB, based on the feedback received in step 5. As an example, the feedback may indicate that SDU sets 1 and Set 3 are scheduled for imminent transmission, whereas SDU Set 2 is at risk of expiration. Accordingly, upon receiving the feedback, the UE may prioritize retransmitting SDU Set 1 and Set 3, whereas it avoids retransmitting SDU set 2 as it is likely to expire before it can be successfully transmitted.

[0057] FIG. 3 illustrates an example DSR message format for SDU, according to one or more example embodiments. [0058] The LCG (logical channel group) identifier, the SDU Set identifier, the priority, remaining time, buffer size, and time-sensitivity are provided. This DSR format is enhanced in order to report multiple pairs of remaining time and buffer sizes for SDU sets within each LCG.

[0059] As an example, a logical control group 7 (LCG) may belong to SDU set 1, and the priority for this set is “high”, such that it is prioritized over other SDU sets for retransmission. The remaining time until it expires is 10ms, which may be related to the time-sensitivity of “critical”. On the other hand, priorities of medium, low in SDU set 2 and SDU set 3 respectively, may indicate that there is more remaining time (20ms and 50ms) respectively, and the time-sensitivity rating may accordingly be lower (important and standard respectively).

[0060] Based on the above, the gNB would likely put a higher emphasis on scheduling SDU set 1 over SDU set 2 and 3, although it should be appreciated that other factors may also be considered by the gNB when analyzing the DSR message.

[0061] FIG. 4, illustrates an example DSR message format for XR uplink and PDU, according to one or more example embodiments. The DSR message format shares some similarities with that illustrated in FIG. 3, however there are some differences in the fields in order to accommodate more parameters, such that the gNB can make further informed scheduling decisions. Specifically, this DSR format may be used for extended reality (XR) services.

[0062] Notably, the DSR format in FIG. 4 introduces an i-bit, which may be F (for high priority data) and S (for standard priority data). Accordingly, the gNB may make enhanced decisions based on the importance of the data from this bit. This may particularly be useful for XR data, as different types of XR traffic may have different importance levels.

[0063] As another example of importance/priority configurations, Augmented Reality (AR) may have a critical importance level, whereas Virtual Reality (VR) may have a high importance level, Mixed Reality (MR) may have a medium importance level, and standard XR may have a low-importance level. The gNB may configure the UE with these importance levels via an RRC reconfiguration message.

[0064] Parameters which may be included may be LCGi, (an identifier indicating the logic channel group), remaining time including Time F (for high priority data) and Time S (for standardpriority data), buffer size reporting the total buffer size of delay-critical Uplink data for an LCG including Buffer Size F (for high priority data) and Buffer Size S (for standard priority data), a priority indicator including an i-bit for indicating the importance level of the reported data (F or S for high priority and standard priority respectively), and PDU set information (which includes PDU set ID, remaining time, buffer size, and priority level). The MAC CE type may also be specified (in this case, it may generally be DSR CE)

[0065] During DSR transmission, the UE may detect buffer occupancy and prepare the send the DSR including the parameters above.

[0066] Based on receiving this DSR, the gNB may process remaining times, buffer sizes, importance levels, and PDU set information. The gNB may prioritize the scheduling of data with higher importance levels (e.g., critical and high), and consider detailed PDU set information. This may be useful to have prioritization since XR applications may be delay-sensitive and have stringent latency and QoS requirements.

[0067] FIG. 5 illustrates an example feedback report format, according to one or more example embodiments.

[0068] A feedback MAC CE Type may be described. The feedback report may indicate scheduled DU (SDU/PDU) set IE’s and Expiring DU Set ID’s. [0069] For example, Set 1 and Set 3 may have been scheduled by gNB, whereas Set 2 can be let expired. Accordingly, upon receiving this feedback report, DU Set’s 1 and 3 may be scheduled, and Set 2 may be allowed to expire.

[0070] FIG. 6 illustrates a block diagram of an example method 600 for DSR and feedback transmission, according to one or more example embodiments.

[0071] At operation 601, gNB sends a RRC configuration message to the UE. This may indicate whether the DSR feedback reporting is available based on a parameter. Further parameters may also include the importance of the data (e.g., S or F in the i-bit)

[0072] At operation 602, gNB may receive a DSR message from the UE. The DSR message may indicate the status of one or more DU sets (such as SDU or PDU), and may include a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set.

[0073] At operation 603, gNB may schedule one or more DU sets based on the DSR message. Scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

[0074] At operation 604, gNB may generate a DSR feedback report. This may include the DU sets which are scheduled in operation 603, as well as DU sets which are at risk of expiration. According to embodiments, this step may be repeated for a second DSR feedback report at a predetermined time interval after the initial DSR feedback report is generated.

[0075] At operation 605, the GNB may send the DSR feedback report generated in operation 604 and report it to the UE. The UE, upon receiving this feedback report, may be configured to adjust the transmission strategy of the DU groups accordingly. This may be sent using a MAC Control Element. [0076] Based on the above example embodiments, the DSR feedback report may, for example, allow for feedback to be generated such that DU sets (SDU, PDU) that are to be scheduled and at risk of expiration can be determined, based on the DSR report including the status of one or more DU sets. Example embodiments may also be less reliant on LCP restriction and have a greater focus on LCH based prioritization.

[0077] FIG. 7 illustrates a block diagram of an example device 700 for implementing one or more example embodiments. As shown in FIG. 7, the device 700 includes processor 710, a memory 720, a storage component 730, an input component 740, an output component 750, a communication interface 760, and a bus 770.

[0078] The processor 710, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 710 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and/or one or more single core processors, a distributed processing system, or the like. The processor 710 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.

[0079] Memory 720 includes a non-transitory computer readable medium. Memory 720 includes a random-access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (c.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by processor 710. The memory 720 comprises machine-readable instructions which are executable by the processor 710. These machine-readable instructions when executed by the processor 710 cause the processor 710 to perform one or more method steps of an embodiment described above. [0080] Storage component 730 stores information and/or software related to the operation and use of the device 700. For example, storage component 730 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.

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

[0082] Output component 750 is configured to provide output information from the device 700. For example, the output component 750 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).

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

[0084] The bus 770 acts as an interconnect between the processor 710, the memory 720, the storage component 730, the input component 740, the output component 750, and the communication interface 760 of the device 700. The bus 770 may include a wired interconnection or a wireless interconnection. [0085] The number and arrangement of components shown in FIG. 7 are provided as an example. In practice, device 700 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 7. Additionally, or alternatively, a set of components (e.g., one or more components) of device 700 may perform one or more functions described as being performed by another set of components of device 700. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 700 in communication with one another.

[0086] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0087] FIG. 8 illustrates a block diagram of an example environment 800 for implementing in which systems and/or method, described herein, may be implemented. The implementation environment 800 includes a UE (User equipment) 810, a service environment 820, and a network 830. The service environment 820 include one or more sub-environments 821. To illustrate this, FIG. 8 shows, for convenience, examples of a 1st sub-environment 821-1, a 2nd sub-environment 821-2, and an N-th sub-environment 821-N (where N is any natural number).

[0088] The UE 810 is connected to the network 830, and the network 830 is connected to the service environment 820. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 810 and the service environment 820 arc connected via the network 830.

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

[0090] The example figure 8 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.”

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

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

[0093] The example figure 8 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." [0094] The one or more services provided by the service environment 820 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 810, a service that stores information from the UE 810, or a sendee that performs processing based on information from the UE 810 and returns the results of the processing.

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

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

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

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

[0099] The network 830 is a network that exchanges information between the UE 810 and the service environment 820. The network 830 includes one or more wired and/or wireless networks. [0100] For example, the network 830 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.

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

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

Various Aspects of Embodiments

[0103] It is contemplated that the example embodiments described hereinabove with reference to FIG. 1 to FIG. 8 arc merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0104] Specifically, 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.

[0105] Some embodiments may relate to a device (e.g., node, etc.), 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.

[0106] 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), electrically erasable programmable read-only memory (EEPROM), 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.

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

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

[0109] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

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

[0111] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices 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.

[0112] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a 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.

[0113] 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 limited to the implementations. Thus, the operation and behavior of the systems and/or methods were 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.

[0114] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items: Item [1]: A method including receiving, by a gNodeB (gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration.

Item [2] : The method according to Item [ 1 ] further including: sending, by the gNB, the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets.

Item [3]: The method according to any one of Items [l]-[2], wherein the method further includes: sending, by the gNB, a RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

Item [4] The method according to any one of Items [l]-[3], wherein the status of the one or more DU sets includes a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set. Item [5]: The method according to Item [4], wherein the scheduling the one or more

DU sets is based at least in part on the priority of the DU set and the remaining time of the

DU set.

Item [6]: The method according to any one of Items [ 1 ]-[5] further including: generating, by the gNB, a second DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated.

Item [7]: The method according to any one of Items [ 1 ]-[6] wherein the data unit includes one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU).It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings.

Item [8] A gNodeB (gNB) configured to: receive a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); schedule the one or more DU sets based on the DSR message; and generate a first DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration.

Item [9]: The gNB according to Item [8], further configured to send the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets. Item [10]: The gNB according to any one of Items [8]-[9], further configured to send an RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

Item [11]: The gNB according to any one of Items [8]-[10], wherein the status of the one or more DU sets includes a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set.

Item [12]: The gNB according to Item [11], wherein the scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

Item [13]: The gNB according to any one of Items [8]-[12] further configured to: generate a second DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated.

Item [14]: The gNB according to any one of Items [8]-[13], wherein the data unit includes one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU). Item [15]: A non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method including: receiving, by a gNodeB (gNB), a delay status report (DSR) message including the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration.

Item [16]: The non-transitory computer-readable recording medium according to Item [15], the method further including sending, by the gNB, the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets.

Item [17]: The non-transitory computer-readable recording medium according to any one of Items [ 15]-[ 16], the method further including sending, by the gNB, a RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

Item [18]: The non-transitory computer-readable recording medium according to any one of Items [15]-[17], wherein the status of the one or more DU sets includes a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set. Item [19]: The non- transitory computer-readable recording medium according to Item [18], wherein the scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

Item [20]: The non-transitory computer-readable recording medium according to any one of Items [ 15]-[ 19] , the method further including generating, by the gNB, a second DSR feedback report including scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated, wherein the data unit includes one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU).

It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A method comprising: receiving, by a gNodeB (gNB), a delay status report (DSR) message comprising the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration.

2. The method as claimed in claim 1, further comprising: sending, by the gNB, the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets.

3. The method as claimed in claim 1 , wherein the method further comprises: sending, by the gNB, a RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

4. The method as claimed in claim 1 , wherein the status of the one or more DU sets comprises a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set.

5. The method as claimed in claim 4, wherein the scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

6. The method as claimed in claim 1, further comprising: generating, by the gNB, a second DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated.

7. The method as claimed in claim 1, wherein the data unit comprises one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU).

8. A gNodeB (gNB) configured to: receive a delay status report (DSR) message comprising the status of one or more data unit (DU) sets from a user equipment (UE); schedule the one or more DU sets based on the DSR message; and generate a first DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration.

9. The gNB as claimed in claim 8, further configured to: send the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets.

10. The gNB as claimed in claim 8, further configured to: send an RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

11. The gNB as claimed in claim 8, wherein the status of the one or more DU sets comprises a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set.

12. The gNB as claimed in claim 11, wherein the scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

13. The gNB as claimed in claim 8, further configured to: generate a second DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated.

14. The gNB as claimed in claim 8, wherein the data unit comprises one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU).

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method comprising: receiving, by a gNodeB (gNB), a delay status report (DSR) message comprising the status of one or more data unit (DU) sets from a user equipment (UE); scheduling, by the gNB, the one or more DU sets based on the DSR message; and generating, by the gNB, a first DSR feedback report comprising scheduled DU sets and

DU sets that are at risk of expiration.

16. The non-transitory computer-readable recording medium as claimed in claim 15, the method further comprising: sending, by the gNB, the generated first DSR feedback report to the UE using a MAC Control Element, wherein upon receiving the generated first DSR feedback report, the UE is configured to adjust transmission strategy for the one or more DU sets.

17. The non-transitory computer-readable recording medium as claimed in claim 15, the method further comprising: sending, by the gNB, a RRC connection message to the UE, wherein the RRC connection message indicates that DSR feedback reporting is available.

18. The non-transitory computer- readable recording medium as claimed in claim 15, wherein the status of the one or more DU sets comprises a logical control group (LCG) identifier, a DU set identifier, a priority of the DU set, a remaining time of the DU set, a buffer size of the DU set, and the time-sensitivity of the DU set.

19. The non-transitory computer-readable recording medium as claimed in claim 18, wherein the scheduling the one or more DU sets is based at least in part on the priority of the DU set and the remaining time of the DU set.

20. The non-transitory computer-readable recording medium as claimed in claim 15, the method further comprising: generating, by the gNB, a second DSR feedback report comprising scheduled DU sets and DU sets that are at risk of expiration, wherein the second DSR feedback report is generated at a predetermined time interval after the first DSR feedback report is generated, wherein the data unit comprises one of a Protocol Data Unit (PDU) or a Service Data Unit (SDU).