Method for handling rlc operation for extended reality services in wireless networks

Abstract

This disclosure relates to 5G or 6G communication systems for supporting higher data transmission rates. Embodiments herein disclose a method for processing radio link control (RLC) reception operations for extended reality (XR) services in a wireless network (1000). The method includes determining, by the receiving side of an Acknowledgment Mode (AM) Radio Link Control (RLC) entity of a receiver device, whether a previously unreceived Service Data Unit (SDU) has expired and abandoning the reception of the expired SDU. Furthermore, the method includes processing the RLC reception operation by the receiving side of the AM RLC entity based on this determination.

Description

Technical Field

[0001] The embodiments disclosed herein relate to wireless networks (or wireless communication networks), and more specifically, to methods and systems for processing radio link control (RLC) operations for extended reality (XR) services in wireless networks. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "below 6 GHz" bands such as 3.5 GHz, but also in "above 6 GHz" bands, including 28 GHz and 39 GHz, known as mmWave. Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered in terahertz bands (e.g., the 95 GHz to 3 THz band) to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] At the outset of 5G mobile communication technology development, standardization was underway regarding beamforming and massive MIMO to support services and meet performance requirements associated with enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC). This standardization aimed to mitigate radio wave path loss in millimeter waves and increase radio wave transmission distance; support parameter sets for dynamic operation (e.g., operating multiple subcarrier spacings) to efficiently utilize millimeter wave resources and time slot formats; initial access technologies to support multi-beam transmission and broadband; the definition and operation of bandwidth portions (BWP); new channel decoding methods (such as low-density parity-check (LDPC) codes for large data transmissions and polar codes for highly reliable transmission of control information); L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, given the services supported by 5G mobile communication technology, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology. Physical layer standardization for technologies such as Vehicle-to-Everything (V2X) is also in place, designed to assist autonomous vehicle driving decisions based on information about the vehicle's location and status transmitted by the vehicle, and to enhance user convenience. This includes NR-U (New Radio Unlicensed) and NR UE Energy Saving (NTN), which are UE-satellite direct communication technologies used to provide coverage and positioning in areas where communication with terrestrial networks is unavailable.

[0005] Furthermore, standardization is ongoing for technologies within the air interface architecture / protocol, such as the Industrial Internet of Things (IIoT) for supporting new services through interoperability and convergence with other industries, Integrated Access and Backhaul (IAB) for providing nodes for network service area extension by supporting wireless backhaul and access links in an integrated manner, mobility enhancements including conditional handover and Dual Active Protocol Stack (DAPS) handover, and two-step random access (two-step RACH for NR) for simplifying the random access process. Standardization is also underway for 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, as well as system architectures / services for Mobile Edge Computing (MEC) based on UE location reception services.

[0006] With the commercialization of 5G mobile communication systems, the already exponentially growing number of connected devices will be connected to the communication network, thus necessitating enhanced functionality and performance of 5G mobile communication systems as well as integrated operation of connected devices. To this end, new research related to extended reality (XR) has been arranged to effectively support augmented reality (AR), virtual reality (VR), mixed reality (MR), etc., by leveraging artificial intelligence (AI) and machine learning (ML), AI service support, metaspace service support, and drone communication to improve 5G performance and reduce complexity.

[0007] Furthermore, this development of 5G mobile communication systems will not only serve as the foundation for developing new waveforms for providing terahertz band coverage in 6G mobile communication technologies, such as multi-antenna transmission technologies like full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas for improving terahertz band signal coverage; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM); and reconfigurable smart surfaces (RIS); it will also serve as the foundation for developing full-duplex technologies to improve the frequency efficiency of 6G mobile communication technologies and enhance system networks; AI-based communication technologies to achieve system optimization by leveraging satellites and AI from the design phase and internalizing end-to-end AI support functions; and next-generation distributed computing technologies to achieve services with complexity levels exceeding the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] The invention is described with reference to Extended Reality (XR) as an applicable scenario. However, the invention is not limited to XR. XR is a collective term for different realities, including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), and is considered an essential technology for realizing digital twins / metaverses. The goal of XR is to provide a communication system framework that meets the challenging requirements of high data rates, very low latency, and energy-efficient connectivity for XR applications.

[0009] Radio Link Control (RLC) is a Layer 2 sublayer and involves several functions for data plane processing of transmitted and received packets. These functions include, but are not limited to, transmission of upper-layer Protocol Data Units (PDUs), error correction via Automatic Repeat Request (ARQ), segmentation and reassembly of RLC Service Data Units (SDUs), resegmentation of RLC segments, duplicate detection, RLC SDU dropping, RLC reconstruction, and protocol error detection.

[0010] For XR applications, existing SDU discarding processes may not be efficient or effective because XR applications are more tightly coupled with frame transmission than with Internet Protocol (IP) packet transmission, which typically maps one-to-one to Protocol Data Convergence Protocol (PDCP) SDUs, and thus to RLC SDUs. Furthermore, in current wireless communication systems (e.g., 5G systems), RLC SDU discarding cannot occur once an RLC SDU or its segments have been submitted to a lower layer (e.g., the Media Access Control (MAC) layer). However, transmitting expired RLC SDUs wastes transmission resources and may also delay the transmission of subsequent new RLC SDUs. Even if the sending RLC entity somehow avoids sending expired RLC SDUs, currently, the receiving RLC entity lacks a mechanism to determine whether expired RLC SDUs were not sent and whether it should abandon receiving them.

[0011] Therefore, there is a need in the art for solutions that overcome the aforementioned disadvantages or deficiencies. Summary of the Invention

[0012] [Technical Issues]

[0013] The primary objective of the embodiments herein is to disclose a method and RLC entity for processing Extended Reality (XR) services in a wireless network.

[0014] Another objective of the embodiments described herein is to handle RLC drop signaling in extended reality in wireless networks.

[0015] Another objective of the embodiments described herein is to receive RLC data packets in a wireless network.

[0016] Another objective of the embodiments described herein is to configure the receiving side of an RLC entity in a wireless network to discard expired RLC data packets.

[0017] Another objective of embodiments of this document is to disclose a method for identifying expired RLC data packets in a wireless network.

[0018] Another objective of the embodiments herein is to disclose a method for discarding received RLC data packets in a wireless network.

[0019] [Technical Solution]

[0020] This document discloses a method for processing radio link control (RLC) reception operations for extended reality (XR) services in a wireless network. The method includes determining, by the receiving side of an Acknowledgment Mode (AM) Radio Link Control (RLC) entity of a receiver device, whether a Service Data Unit (SDU) that has not yet been received has expired and abandoning the reception of the expired SDU. Furthermore, the method includes processing the RLC reception operation by the receiving side of the AM RLC entity based on this determination.

[0021] Embodiments herein disclose an RLC entity for a receiver device, including an XR service controller coupled to a processor and a memory. The XR service controller is configured to determine whether an unreceived SDU has expired and to discard the reception of expired SDUs. Based on this determination, the XR service controller is configured to handle RLC operations for XR services.

[0022] In one embodiment, the receiver device is a user equipment (UE). In another embodiment, the receiver device is a network entity.

[0023] In an embodiment, the method includes: when at least one of a reassembly timer, a local timer, and a configured timer expires, and at least one of an RLC SDU with a SN has not been received and an RLC SDU with a SN has not been fully received, the receiving side of the AM RLC entity determines that at least one RLC SDU with a sequence number (SN) X has expired, wherein SN X is less than SN Y associated with the timer.

[0024] In an embodiment, the receiving side of the AM RLC entity is configured by the network entity in an RRC signaling message with at least one of the following parameters: a timer (e.g., t-Outdated) and a parameter that associates the timer with SN Y (e.g., Rx Outdated Trigger). This configuration is associated with at least one of the following: per RLC entity, per bearer, per Logical Channel Group (LCG) and commonly for User Equipment (UE). SN Y is the Rx Outdated Trigger, and the Rx Outdated Trigger holds the highest possible value of the SN after triggering the discarding of a segment of the RLC SDU(multiple) RLC SDU(multiple) RLCSDU(multiple) upon timer expiration.

[0025] In an embodiment, the method includes determining, by the receiving side of the AM RLC entity, that at least one byte segment of at least one RLC SDU with SN X has been received before the moment when the receiving side of the AM RLC entity determines that an RLC SDU with SN X has expired, wherein the SN X of the at least one RLC SDU is less than the SN Y associated with a timer (e.g., Rx OutdatedTrigger). Furthermore, the method includes, based on this determination, the receiving side of the AM RLC entity discarding at least one byte segment of the stored at least one RLC SDU with SN X.

[0026] In an embodiment, the method includes determining, by the receiving side of the AM RLC entity, that an Acknowledgment Mode Data PDU (AMD PDU) has been received from the lower layer. After an RLC SDU with SN X is determined to be expired, the AMD PDU includes at least one byte segment of either the RLC SDU with SN X or an RLC SDU with SN X. Furthermore, the method includes, based on this determination, the receiving side of the AM RLC entity discarding or abandoning the received AMD PDU.

[0027] In an embodiment, the method includes: when an AMD PDU with SN X is received and, if all bytes of an RLC SDU with SNX have been received, the receiving side of the AM RLC entity updates the status variable RX Highest Status to SN Y of a first RLC SDU whose bytes have not yet been received, such that SN Y is greater than the current RX Highest Status, and wherein the first RLC SDU has not yet been determined to be expired. RX Highest Status stores the highest possible value of the SN of the RLC SDU with the highest SN among the received RLCSDUs.

[0028] In an embodiment, the method includes: when an AMD PDU with SN X is received, and if all bytes of an RLC SDU with SN X are received, the receiving side of the AM RLC entity updates the state variable RX Next (Next RX) to SN Y of a first SDU whose bytes have not yet been received, such that SN is greater than the current RX Next, and wherein the first SDU has not yet been determined to be expired. RX Next is a state variable that stores the value of SN after the last RLC SDU received in sequence, and RX Next serves as the lower edge of the receive window.

[0029] In an embodiment, the method includes updating the state variable RX Next Highest by the receiving side of the AM RLC entity to increment SN X by 1. X is the sequence number of the last received RLC SDU that is determined to be expired, and X is greater than or equal to the current RX Next Highest.

[0030] In an embodiment, the method includes having the receiving side of the AM RLC entity record the SN X of each of the RLC SDUs determined to be expired, such that SN X is greater than the current RX Next. Furthermore, the method includes having the receiving side of the AM RLC entity skip over expired RLC SDUs that are expected to be received from the sending entity. Additionally, the method includes having the receiving side of the AM RLC entity update at least one state variable of the recorded SN X of each of the RLC SDUs.

[0031] In an embodiment, the method includes processing the RLC SDU by the receiving side of the AM RLC entity when the receiving RLC entity has received a segment of an RLC SDU or RLCSDU with SN X and determines that the RLC SDU or RLC SDU segment with SN X has expired. Furthermore, the method includes delivering the RLC SDU to an upper layer by the receiving side of the AM RLC entity based on this processing.

[0032] In an embodiment, the method includes preventing the receiving side of the AM RLC entity from processing the RLC SDU when the receiving RLC entity has received an RLC SDU or RLCSDU segment with SN X and determines that the RLC SDU or RLC SDU segment with SN X has expired. Furthermore, the method includes preventing the receiving side of the AM RLC entity from delivering the RLC SDU to the upper layer. Additionally, the method includes having the receiving side of the AM RLC entity discard the already received RLC SDU or RLC SDU segment.

[0033] In an embodiment, the method includes: when the receiving side of an AM RLC entity determines that an RLC SDU has expired and been abandoned, triggering the receiving side of the AM RLC entity to send a status report to the peer AM RLC entity.

[0034] In an embodiment, the method includes: when at least one RLC SDU with SN X is determined to be expired and abandoned, a status report is triggered by an RLC entity, wherein the determination is based on the expiration of a timer (e.g., t-Outdated).

[0035] In an embodiment, the method includes a receiver-side delay-triggered status report by an AM RLC entity until the expired SDU's SN X is less than RX Highest Status or SN X is greater than or equal to the sum of RX Next and the AM window size.

[0036] In an embodiment, the method includes the receiving side of the AM RLC entity providing a positive acknowledgment in a status report for an RLCSDU with SN X, wherein SN X is determined to be expired and abandoned by the receiving side of the AM RLC entity.

[0037] In an embodiment, the method includes: when an expired RLC SDU is determined at the receiving side of an AM RLC entity, triggering the sending of a status report from the receiving side of the AM RLC entity to a peer AM RLC entity, without considering delay, triggering a STATUS report until SN X is less than RX Highest Status or SN X is greater than the sum of RX Next and AM window size. An RLC SDU with SN X is determined to be expired.

[0038] In an embodiment, the method includes: when the receiving side of an AM RLC entity determines at least one expired RLC SDU with SN X, and the RLC SDU with SN X or a segment of the RLC SDU was received simultaneously or during the time a status prohibition timer is running, the receiving side of the AM RLC entity discards the RLC SDU with SN X or a segment of the RLC SDU. Furthermore, the method includes triggering a status report by the receiving side of the AM RLC entity. Additionally, the method includes providing a positive acknowledgment in the status report by the receiving side of the AM RLC entity for the RLC SDU with SN X that has been determined to be expired.

[0039] In an embodiment, the method includes: when the receiving side of the AM RLC entity has determined that an expired SDU, the AM RLC entity generates a status PDU.

[0040] In an embodiment, the method includes: when it is determined that a timer is not running and RX Next Highest is at least one of the following, starting a timer (e.g., t-Outdated) and setting the Rx Outdated Trigger to RXNext Highest: greater than RX Next plus one, or equal to RX Next plus one and there is at least one missing byte segment of the SDU associated with an SN equal to RX Next before the last byte of all received segments of the SDU.

[0041] In an embodiment, the method includes determining whether a timer (t-Outdated) has expired, and upon t-Outdated expiration, the method further includes discarding byte segments of each of the RLC SDUs having SN X, where SN X is less than the Rx Outdated Trigger. Furthermore, the method includes updating RX_Next to the SN Y of a first RLC SDU having SN Y greater than or equal to the Rx Outdated Trigger, where all bytes of the first RLC SDU have not yet been received. Additionally, the method includes: starting a timer (e.g., t-Outdated) and setting the Rx Outdated Trigger to RX_Next Highest if RX_Next_Highest is greater than RX_Next + one, or equal to RX_Next + one, and there is at least one missing byte segment of an SDU associated with an SN equal to RX_Next preceding the last byte of all received segments of that SDU.

[0042] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that while the following description indicates at least one embodiment and its many specific details, it is given by way of illustration rather than limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from them, and the embodiments herein encompass all such modifications.

[0043] [Beneficial Effects]

[0044] According to embodiments of this disclosure, a method for processing RLC operations of extended reality services in a wireless network can be provided. Attached Figure Description

[0045] Embodiments of the present invention are illustrated in the accompanying drawings, in which the same reference numerals denote corresponding parts in the various drawings. The embodiments of the present invention will be better understood through the following description with reference to the accompanying drawings. Embodiments of the present invention are illustrated by way of example in the accompanying drawings, wherein:

[0046] Figure 1 A wireless network for processing RLC operations of XR services according to an embodiment disclosed herein is shown;

[0047] Figure 2 Various elements of the RLC entity of a receiver device according to embodiments disclosed herein are shown;

[0048] Figure 3 This is a flowchart illustrating a method for processing RLC operations of XR services in a wireless network according to embodiments disclosed herein;

[0049] Figure 4 An example enhanced receiver RLC entity operation is shown according to an embodiment disclosed herein for determining whether an SDU that has not yet been received or has not been fully received has expired and for abandoning the reception of expired SDUs;

[0050] Figure 5 and Figure 6 This is a flowchart illustrating a method for managing expired RLCSDUs at a receiving RLC entity, according to embodiments disclosed herein;

[0051] Figure 7 An example RLC discard information processing method for an XR service at a receiving RLC entity is shown according to embodiments disclosed herein;

[0052] Figure 8 An example RLC discard information processing method at a receiving RLC entity for an XR service, according to embodiments disclosed herein, is illustrated; and

[0053] Figure 9 An example RLC discard information processing method for receiving RLC entities for XR services is shown according to embodiments disclosed herein. Detailed Implementation

[0054] The embodiments described herein, along with their various features and advantageous details, are explained more fully with reference to the non-limiting embodiments illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques have been omitted to avoid unnecessarily obscuring the embodiments herein. The examples used herein are intended only to facilitate understanding of how the embodiments described herein can be practiced and to further enable those skilled in the art to practice the embodiments described herein. Therefore, these examples should not be construed as limiting the scope of the embodiments described herein.

[0055] For the purposes of interpreting this specification, definitions (as defined herein) will apply, and terms used in the singular will include the plural where appropriate, and vice versa. It should be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not restrictive. Unless otherwise stated, the terms “comprising,” “having,” and “including” should be interpreted as open-ended terms.

[0056] The words / phrases “exemplary,” “example,” “illustration,” “in instance,” “the like,” “and so on,” “etc.,” “etectera,” “for example,” and “i.e.” are used herein only to mean “used as an example, instance, or illustration.” Any embodiment or implementation of the subject matter described herein using the words / phrases “exemplary,” “example,” “illustration,” “in instance,” “the like,” “and so on,” “etc.,” “etectera,” “for example,” and “i.e.” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0057] Embodiments herein can be described and illustrated based on blocks that perform one or more of the described functions. These blocks (which may be referred to herein as managers, units, modules, hardware components, etc.) are physically implemented by analog and / or digital circuitry (such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuitry, passive electronic components, active electronic components, optical components, hardwired circuitry, etc.) and may optionally be driven by firmware. The circuitry may be embodied, for example, in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting a block may be implemented by dedicated hardware, by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware (for performing certain functions of the block) and a processor (for performing other functions of the block). Each block of an embodiment may be physically divided into two or more interacting and discrete blocks without departing from the scope of this disclosure. Similarly, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of this disclosure.

[0058] It should be noted that the elements in the accompanying drawings are shown for the purposes of this specification and ease of understanding, and may not necessarily be drawn to scale. For example, flowcharts / sequence diagrams illustrate the method according to the steps required to understand the aspects of the embodiments disclosed herein. Furthermore, regarding the construction of the device, one or more components of the device may have been represented by conventional symbols in the drawings, and the drawings may only show specific details relevant to understanding the embodiments, so as not to obscure the drawings from details readily understood by those skilled in the art from the description herein. Similarly, regarding the system, one or more components / modules constituting the system may have been represented by conventional symbols in the drawings, and the drawings may only show specific details relevant to understanding the embodiments, so as not to obscure the drawings from details readily understood by those skilled in the art from the description herein.

[0059] The accompanying drawings are provided to aid in the easy understanding of the various technical features, and it should be understood that the embodiments presented herein are not limited to the drawings. Therefore, except for those specifically set forth in the drawings and corresponding descriptions, this disclosure should be construed as extending to any modifications, equivalents, and substitutions. The use of terms such as first, second, third, etc., to describe components / elements / steps is for the purposes of this specification and, unless otherwise stated, should not be construed as indicating a sequential order / placement / occurrence.

[0060] This document discloses a method for processing radio link control (RLC) reception operations for extended reality (XR) services in a wireless network. The method includes determining, by the receiving side of an Acknowledgment Mode (AM) Radio Link Control (RLC) entity of a receiver device, whether a Service Data Unit (SDU) that has not yet been received has expired and abandoning the reception of the expired SDU. Furthermore, the method includes processing the RLC reception operation by the receiving side of the AM RLC entity based on this determination.

[0061] Furthermore, embodiments of this document implement a method and system for processing Extended Reality (RLC) drop signaling in a wireless network. Embodiments of this document also implement a method and system for receiving RLC data packets in a wireless network.

[0062] In an embodiment, the method includes sending discard information in an RLC control PDU by a sending RLC entity. Furthermore, the method includes receiving discard information in an RLC control PDU by a receiving RLC entity. The method also includes the receiving RLC entity processing the RLC discard information and updating RLC status variables, managing a reassembly timer, performing delivery to the upper layer, and sending an updated RLC status report to the sending RLC entity.

[0063] This method can be used to achieve low latency and reliable data transmission for XR services, and improve the user experience for both the UE and the network side.

[0064] Now refer to the attached diagram, for more specific details. Figures 1 to 9 Similar reference numerals are consistently used throughout the figures to denote corresponding features, illustrating embodiments.

[0065] Figure 1 A wireless network (1000) for processing RLC operations of XR services according to embodiments disclosed herein is illustrated. The wireless network (1000) may be, for example, but not limited to, a fourth-generation (4G) network, a fifth-generation (5G) network, a sixth-generation (6G) network, an Open Radio Access Network (ORAN), etc. The wireless network (1000) includes an AM RLC entity of a transmitter device (100) and an AM RLC entity of a receiver device (200). In one embodiment, the transmitter device (100) is a UE, and the receiver device (200) is a network entity. In another embodiment, the transmitter device (100) is a network device, and the receiver device (200) is a UE. Furthermore, for example, when the UE and the network entity engage in bidirectional communication, the UE and the network entity may be both a transmitting device and a receiving device. That is, the UE may have both a transmitting side and a receiving side of the RLC AM entity, and the network entity may have both a transmitting side and a receiving side of the RLC AM entity.

[0066] In an embodiment, the enhanced receiver RLC entity operates to determine whether an SDU that has not yet been received or has not been fully received has expired, and abandons the reception of expired SDUs.

[0067] In an embodiment, the enhanced receiver RLC entity operates to determine whether an unreceived SDU has expired and abandons receiving expired SDUs.

[0068] In the embodiments described herein, the receiving side of the Acknowledgment Mode (AM) RLC entity (200) determines that an RLC SDU with SN=x has expired when the reassembly timer (e.g., referred to as t-Reassembly) expires, and that the RLC SDU with SN=x has not been received and / or has not been fully received.

[0069] In the embodiments described herein, the receiving side of the AM RLC entity (200) determines that an RLC SDU with SN=x has expired when a local or configured timer (e.g., referred to as t-Outdated) expires, and that the RLC SDU with SN=x has not been received and / or has not been fully received.

[0070] In one embodiment, the receiving side of the AM RLC entity (200) is configured by the network in a Radio Resource Control (RRC) signaling message (e.g., an RRC reconfiguration message, etc.) with at least one of the t-Outdated timer and RX_Outdated_Trigger parameters. This configuration can be per RLC entity, per bearer, per logical channel group (LCG), or common to the UE. In another embodiment, the state variable RX_Outdated_Trigger can be a parameter locally configured by the UE.

[0071] In the embodiments described herein, the t-Outdated timer can be configured with the same value as the t-Reassembly timer. In another embodiment described herein, the t-Outdated timer can be configured with a larger value than the value configured for the t-Reassembly timer (e.g., the t-Outdated timer can be configured based on a Packet Delay Budget (PDB) or a PDU-based Delay Budget Set Delay Budget (PSDB), while the t-Reassembly timer can be configured based on a HARQ reordering time requirement). In the embodiments described herein, the t-Outdated timer can be configured with a smaller value than the value configured for the t-Reassembly timer.

[0072] In one embodiment of this document, the t-Outdated timer is stopped when the t-Reassembly timer expires. In another embodiment of this document, the t-Reassembly timer is stopped when the t-Outdated timer expires. In yet another embodiment of this document, the t-Outdated timer continues to run when the t-Reassembly timer expires (i.e., the t-Reassembly timer and t-Outdated timer operate separately or independently).

[0073] In an embodiment, if at least one byte segment of an RLC SDU with SN=x has been received before the time when the receiving side of the AM RLC entity (200) determines that the RLC SDU with SN=x has expired, then the receiving side of the AM RLC entity (200) discards at least one byte segment of the stored RLC SDU with SN=x.

[0074] In the embodiments herein, if an AMD PDU is received from the lower layer, wherein the AMD PDU contains at least one byte segment of an RLC SDU with SN=x after the RLC SDU has been determined to be expired, the receiving side of the AM RLC entity (200) discards or abandons the received AMD PDU.

[0075] In the embodiments described herein, examples of the proposed specification are provided as follows:

[0076] Example 1: 5.2.3.2.2 Actions when an AMD PDU is received from a lower layer (e.g., the MAC layer). When an AMD PDU is received from a lower layer, the AMD PDU contains byte segment numbers y to z of an RLC SDU with SN=x. Based on the available allocation size to accommodate the RLC PDU, the RLC PDU may contain segments of the RLC SDU or the complete RLC SDU. For example, an RLC SDU of size 100 bytes may be accommodated as two segments of two RLC PDUs—the first RLC PDU has a byte segment from the first byte to the 40th byte, and the second RLC PDU has a byte segment from the 41st byte to the 100th byte. The receiving side of the AMRLC entity (200) should:

[0077] - If x falls outside the receiving window; or

[0078] - If segment numbers y to z of an RLC SDU with SN=x have already been received; or

[0079] -If an RLC SDU with SN=x has been determined to be expired:

[0080] Discard the received AMD PDU.

[0081] - Otherwise:

[0082] Place the received AMD PDU in the receive buffer;

[0083] -> If some bytes of the RLC SDU contained in the AMD PDU have already been received:

[0084] Discard duplicate byte segments.

[0085] In an embodiment, when an AMD PDU with SN=x is received and if all bytes of an RLC SDU with SN=x are received, the receiving side of the AM RLC entity (200) updates the status variable RX_Highest_Status to the SN of the first RLC SDU that has not yet been delivered to the upper layer (e.g., the application layer), such that SN > the current RX_Highest_Status (i.e., SN is greater than the current RX_Highest_Status), and where the first RLC SDU has not yet been determined to be expired. RX Highest Status stores the highest possible value of the SN of the RLC SDU with the highest SN among the received RLC SDUs.

[0086] In an embodiment, when an AMD PDU with SN=x is received and if all bytes of an RLC SDU with SN=x are received, the receiving side of the AM RLC entity (200) updates the status variable RX_Highest_Status to the SN of the first RLC SDU that has not yet been delivered to the upper layer, such that SN> the current RX_Highest_Status (i.e., SN is greater than the current RX_Highest_Status), where all bytes of the first RLC SDU have not yet been received and the first RLC SDU has not yet been determined to be expired.

[0087] In an embodiment, when an AMD PDU with SN=x is received and if all bytes of an RLC SDU with SN=x are received, the receiving side of the AM RLC entity (200) updates the state variable RX_Next to the SN of the first SDU whose bytes have not yet been received, such that SN > current RX_NEXT (e.g., SN is greater than current RX_NEXT), and the first SDU has not yet been determined to be expired. RX_Next is a state variable that stores the value of the SN after the last RLC SDU received in sequence, and RX_Next serves as the lower edge of the receive window.

[0088] In this embodiment, the receiving side of the AM RLC entity (200) updates the state variable RX_Next_Highest to SN=x+1, where x is the sequence number of the last received RLC SDU that is determined to be expired, and x>=the current RX_Next_Highest. RX_Next_Highest is a state variable that stores the value of the SN following the SN of the RLCSDU with the highest SN among the received RLC SDUs.

[0089] In this embodiment, the receiving side of the AM RLC entity (200) records or marks (or performs bookkeeping) the SN of an RLC SDU that is determined to be expired, such that SN > (updated) RX_Next. Furthermore, the receiving side of the AM RLC entity (200) skips the expectation of receiving these expired RLC SDUs from the sending entity (100) and / or assumes that these expired RLC SDUs have already been received. Therefore, the receiving side of the AM RLC entity (200) updates the state variable of the SN of each of the RLC SDUs that are recorded or marked (or bookkeeping) as described above. For example, when RX_Next becomes equal to SN (i.e., RX_Next = SN), the RLC entity (200) updates RX_Next to the sequence number of the first RLC SDU with a sequence number > the current RX_Next, where all bytes of the first RLC SDU have not yet been received and the first RLC SDU has not been determined to be expired. As another example, when RX_Highest_Status becomes equal to SN (i.e., RX_Highest_Status=SN), the RLC entity (200) updates RX_Highest_Status to the sequence number of the first RLC SDU with a sequence number > the current RX_Next, where all bytes of the first RLC SDU have not yet been received and the first RLC SDU has not been determined to be expired.

[0090] In an embodiment, when an RLC SDU with an SN or a segment of an RLC SDU has been received by the receiving RLC entity (200) and determined to be expired, the receiving RLC entity (200) may process the RLC SDU and / or deliver it to the upper layer.

[0091] In an embodiment, when an RLC SDU with an SN or a segment of an RLC SDU has been received by the receiving RLC entity (200) and determined to be expired, the receiving RLC entity (200) may not process the RLC SDU and / or may not deliver it to the upper layer. Furthermore, the receiving RLC entity (200) may discard the already received RLC SDU or a segment of the RLC SDU.

[0092] In the embodiments described herein, the process for managing expired RLC SDUs at the receiving RLC entity (200) is described below.

[0093] Example 2: For an RLC SDU with SN=x that is determined to be expired and abandoned, the receiving side of the AM RLC entity (200) should:

[0094] - If x>=RX_Next_Highest:

[0095] Update RX_Next_Highest to x+1.

[0096] - If x = RX_Highest_Status:

[0097] -> Update RX_Highest_Status to the SN of the first RLCSDU with SN > current RX_Highest_Status, where not all bytes of the first RLC SDU have been received and the first RLC SDU has not been determined to be expired.

[0098] - If x = RX_Next:

[0099] -> Update RX_Next to the SN of the first RLC SDU with SN > current RX_Next, where not all bytes of the first RLC SDU have been received and the first RLC SDU has not been determined to be expired.

[0100] - If t-Reassembly is running:

[0101] -> If RX_Next_Status_Trigger=RX_Next; or

[0102] -> If RX_Next_Status_Trigger = RX_Next + 1, and there is no missing byte segment of the SDU associated with SN=RX_Next before the last byte of all received segments of this SDU, or SN=RX_Next is determined to be expired; or

[0103] -> -If RX_Next_Status_Trigger falls outside the receive window and RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size:

[0104] -> Stop and reset t-Reassembly.

[0105] - If t-Reassembly is not running (including cases where t-Reassembly has stopped due to the actions described above):

[0106] -> If RX_Next_Highest > RX_Next + 1; or

[0107] -> If RX_Next_Highest = RX_Next + 1, and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU, and SN = RX_Next is not determined to be expired; or

[0108] -> Start t-Reassembly;

[0109] Set RX_Next_Status_Trigger to RX_Next_Highest.

[0110] When the t-Reassembly period expires, the receiving side of the AM RLC entity (200) will:

[0111] - Update RX_Highest_Status to the SN of the first RLCSDU with SN>=RX_Next_Status_Trigger, where all bytes of the first RLC SDU have not yet been received;

[0112] - If RX_Next_Highest > RX_Next+1: or

[0113] - If RX_Next_Highest = RX_Next + 1, and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU, and RX_Next is not determined to be expired:

[0114] -> Start t-Reassembly;

[0115] Set RX_Next_Status_Trigger to RX_Next_Highest.

[0116] In the embodiments described herein, when it is determined that timer t-Outdated is not running and RX Next Highest is at least one of the following, the receiving side of the entity starts timer t-Outdated and sets Rx Outdated Trigger to RX Next Highest: greater than RX Next plus one, or equal to RX Next plus one and there is at least one missing byte segment of the SDU associated with an SN equal to RX Next before the last byte of all received segments of the SDU.

[0117] In the embodiments described herein, the receiving side of the RLC entity determines whether timer t-Outdated has expired, and when timer t-Outdated expires, performs at least one of the following: discards byte segments of each of the RLC SDUs having SN X, where SN X is less than Rx Outdated Trigger; updates RX Next to SN Y of the first RLC SDU having SN Y greater than or equal to Rx Outdated Trigger, where all bytes of the first RLC SDU have not yet been received; and starts timer t-Outdated and sets Rx Outdated Trigger to RX Next Highest if RX Next Highest is at least one of the following: greater than RX Next plus one, or equal to RX Next plus one and there is at least one missing byte segment of the SDU associated with SN equal to RX Next before the last byte of all received segments of the SDU.

[0118] In the embodiments described herein, the process for managing expired RLC SDUs at the receiving RLC entity (200) is described as follows:

[0119] Example 3:

[0120] - If t-Outdated is running:

[0121] -> If RX_Outdated_Trigger = RX_Next; or

[0122] -> If RX_Outdated_Trigger = RX_Next + 1, and there is no missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU, or SN = RX_Next is determined to be expired; or

[0123] -> If RX_Outdated_Trigger falls outside the reception window and RX_Outdated_Trigger is not equal to RX_Next+AM_Window_Size:

[0124] -> Stop and reset t-Outdated.

[0125] - If t-Outdated is not running (including the case where t-Outdated is stopped due to the above action):

[0126] -> If RX_Next_Highest > RX_Next+1; or

[0127] -> If RX_Next_Highest = RX_Next +1, and there is at least one missing byte segment of the SDU associated with SN=RX_Next before the last byte of all received segments of this SDU, and SN=RX_Next is not determined to be outdated; or

[0128] -> Start t-Outdated;

[0129] -> Set RX_Outdated_Trigger to RX_Next_Highest.

[0130] When t-Outdated expires, the receiving side of the AM RLC entity (200) shall:

[0131] - Discard all received byte segments (if any) of the RLC SDU(s) with SN < RX_Outdated_Trigger, and regard the SN as outdated and discarded;

[0132] Update RX_Next to the SN of the first RLC SDU with SN >= RX_Outdated_Trigger, for which all bytes of the first RLC SDU have not been received yet;

[0133] - If RX_Next_Highest > RX_Next+1; or

[0134] - If RX_Next_Highest = RX_Next+1, and there is at least one missing byte segment of the SDU associated with SN=RX_Next before the last byte of all received segments of this SDU, and SN=RX_Next is not determined to be outdated:

[0135] -> Start t-Outdated;

[0136] -> Set RX_Outdated_Trigger to RX_Next_Highest.

[0137] In the embodiments herein, when the receiving side of an Unacknowledged Mode (UM) RLC entity (200) or an AM RLC entity (200) determines that at least one byte segment of an RLC SDU is missing, a reassembly timer is started, and upon expiration of the reassembly timer, the RLC entity (200) discards all segments of the SDU. In the embodiments herein, out-of-order delivery is configured or permitted as an enhanced RLC configuration for the receiving side of the UM RLC entity (200) and / or the AM RLC entity (200). Furthermore, the receiving side of the UM RLC entity (200) and / or the AM RLC entity (200) discards the incompletely received SDU (i.e., SDU segments) upon expiration of the reassembly timer. In the embodiments herein, out-of-order delivery is configured or permitted as an enhanced RLC configuration for the receiving side of the UM RLC entity (200) and / or the AM RLC entity (200). Furthermore, the receiving side of the UM RLC entity and / or the AM RLC entity (200) discards the incompletely received SDU (i.e., SDU segments) upon expiration of the t-outdated timer. In the embodiments herein, when the receiving side of the AM RLC entity (200) determines that an RLC SDU is outdated and discarded, the AM RLC entity (200) triggers transmission of a status report (i.e., a STATUS PDU) to its peer AM RLC entity.

[0138] Example 4: An AM RLC entity (200) transmits a STATUS PDU to its peer AM RLC entity (200) to provide positive and / or negative acknowledgements for an RLC SDU (or a portion thereof).

[0139] Triggers for initiating a STATUS report include:

[0140] - When an RLC SDU with SN=x is determined to be outdated and discarded, the receiving side of the AM RLC entity (200) will:

[0141] -> If x<RX_Highest_Status or x>=RX_Next+AM_Window_Size:

[0142] -> Trigger a STATUS report.

[0143] -> Otherwise:

[0144] -> Delay triggering the STATUS report until x<RX_Highest_Status or x>=RX_Next+AM_Window_Size.

[0145] In the embodiments herein, the receiving side of the AM RLC entity (200) provides a positive acknowledgment in the STATUS report for the RLC SDU with SN=x, which is determined to be expired and discarded by the receiving side of the AM RLC entity (200).

[0146] In the embodiments herein, when the receiving side of the AM RLC entity (200) determines that an RLC SDU is expired, the AM RLC entity (200) triggers sending a status report (i.e., STATUS PDU) to its peer AM RLC entity (200), regardless of delaying the triggering of the status report until x<RX_Highest_Status or x>=RX_Next+AM_Window_Size, where the RLC SDU with SN=x is determined to be expired.

[0147] In the embodiments herein, when the receiving side of the AM RLC entity (200) determines at least one expired RLC SDU with SN=x, and receives the RLC SDU with SN=x or a segment of the RLC SDU at the same time or within the time period during which the status prohibit timer is running, the receiving side of the AM RLC entity (200) discards the RLC SDU with SN=x or the segment of the RLC SDU and triggers a STATUS report. In addition, the receiving side of the AM RLC entity (200) provides a positive acknowledgment in the STATUS report for the RLC SDU with SN=x that is determined to be expired.

[0148] In the embodiments herein, examples of proposed specifications for constructing a STATUS PDU when the receiving side of the AM RLC has determined an expired SDU are provided.

[0149] Example 5: When constructing a STATUS PDU, the AM RLC entity (200) shall:

[0150] - For RLC SDUs with SN such that RX_Next<=SN<RX_Highest_Status that have not been completely received, in increasing order of the SN of the RLC SDU and increasing order of the byte segments within the RLC SDU, starting from SN=RX_Next until the point where the resulting STATUS PDU still fits within the total size of the RLC PDU(s) indicated by the lower layer:

[0151] -> For an RLC SDU for which no byte segment has been received and which has not been determined to be expired:

[0152] -> Include NACK_SN in the STATUS PDU, where NACK_SN is set to the SN of the RLC SDU.

[0153] -> For a consecutive sequence of byte segments of a partially received RLC SDU that have not been received and have not been determined to be expired:

[0154] -> Include the set of NACK_SN, SOstart and SOend in the STATUS PDU.

[0155] -> For a consecutive sequence of RLC SDUs that have not been received and have not been determined to be expired:

[0156] -> Include the set of NACK_SN and the NACK range in the STATUS PDU;

[0157] -> Include SOstart and SOend in the STATUS PDU if necessary. Correct

[0158] -> Set ACK_SN to the SN of the next unreceived RLC SDU, which is not indicated as missing in the resulting STATUS PDU (i.e., the SN of the RLC SDU determined to be expired is also considered).

[0159] In an embodiment, the receiving RLC entity (200) (e.g., the receiving side of a receiving UM RLC entity or AM RLC entity) receives consecutive or non-consecutive discarded RLC SDU SNs in discard signaling. For example, the RLC discard information may include a "set" of the first discarded SDU sequence number and the range of consecutive (multiple) RLC SDUs (i.e., sequentially ordered (multiple) SN RLC SDUs) that are discarded in an RLC control PDU or RLC data header, or the RLC discard information may include the first discarded SDU sequence number and a bitmap for the discard information in the RLC control PDU or RLC data header.

[0160] In an embodiment, if at least one SN value of the discarded RLC SDU included in the received RLC discard information is outside the receiving window, the receiving RLC entity (200) ignores the entire discard information included in the RLC discard signaling (e.g., an RLC control PDU). If RX_Next<=SN<RX_Next+AM_Window_Size, the SN falls within the receiving window. Otherwise, the SN falls outside the receiving window.

[0161] In an embodiment, if at least one SN value of a discarded RLC SDU in the discard information is outside the receiving window, the receiving RLC entity (200) simply ignores the discard information of the corresponding discarded(multiple) RLCSDU in the RLC discard signaling (e.g., RLC control PDU) and processes the RLC discard information of other discarded RLC SDUs within the receiving window.

[0162] In an embodiment, if at least one byte segment of an RLC SDU with SN=x has been received before the receiving side of the AM RLC entity (200) receives RLC discard information including a discarded RLC SDU with SN=x, then the receiving side of the AM RLC entity (200) discards at least one byte segment of the stored RLC SDU with SN=x.

[0163] In the embodiments described herein, if an RLC SDU with SN=x has been received before the AM RLC entity (200) receives RLC discard information including a discarded RLC SDU with SN=x, the AM RLC entity (200) discards the stored RLC SDU with SN=x.

[0164] In the embodiments described herein, the receiving side of the AM RLC entity (200) updates the status variable RX_Highest_Status to the SN of a first RLC SDU that has not yet been delivered to the upper layer, such that SN > current RX_Highest_Status, and the first RLC SDU is not included in the RLC control PDU or is not indicated as discarded in the RLC discard information (e.g., RLC control PDU).

[0165] In the embodiments described herein, the receiving side of the AM RLC entity (200) updates the state variable RX_Next to the SN of the first SDU for which all bytes have not yet been received, such that SN > current RX_Next, and that the first SDU is not included in RLC discard information (e.g., RLC control PDU) or is not indicated as discarded in RLC discard information. RX_Next is a state variable that stores the value of the SN following the last RLC SDU received in sequence, and it serves as the lower edge of the receive window.

[0166] In the embodiments described herein, the receiving side of the AM RLC entity (200) updates the state variable RX_Next_Highest to SN=X+1, where X is the sequence number of the last received RLCSDU that was indicated as being discarded in the RLC discard information (e.g., RLC control PDU), and X>= the current RX_Next_Highest.

[0167] In the embodiments described herein, the receiving side of the RLC entity (200) records or marks (or performs bookkeeping) the SN of an RLC SDU indicated as discarded in the RLC discard information (e.g., RLC control PDU), such that SN > (updated) RX_NEXT. Furthermore, the receiving side of the AM RLC entity (200) skips the expectation of receiving these RLC SDUs from the sending entity (100), or assumes that these RLC SDUs have already been received. Therefore, the receiving side of the AM RLC entity (200) updates the status variable for the SN of each of the RLC SDUs recorded or marked (or bookkeeping) as described above. For example, when RX_Next becomes equal to SN (i.e., RX_Next = SN), RX_NEXT is updated to the sequence number of the first RLC SDU with a sequence number > the current RX_Next, where all bytes of the first RLC SDU have not yet been received, and the first RLC SDU was not indicated as discarded in the RLC discard information. As another example, when RX_Highest_Status becomes equal to SN (i.e., RX_Highest_Status=SN), RX_Highest_Status is updated to the sequence number of the first RLC SDU with a sequence number greater than the current RX_Next, where all bytes of the first RLCSDU have not yet been received and the first RLC SDU has not been indicated as dropped in the RLC drop information.

[0168] In the embodiments herein, when the receiving RLC entity (200) has received an RLC SDU with a SN or a segment of an RLC SDU and it is indicated as to be discarded in RLC discard information (e.g., RLC control PDU), the receiving RLC entity (200) may process the RLC SDU and / or deliver it to the upper layer.

[0169] In the embodiments described herein, when the receiving RLC entity (200) has received an RLC SDU or a segment of an RLC SDU with a SN and it is indicated to be discarded in the RLC control PDU, the receiving RLC entity (200) may not process the RLC SDU and / or may not deliver it to the upper layer. Furthermore, the receiving RLC entity (200) may discard the already received RLC SDU or a segment of an RLC SDU.

[0170] In the embodiments, the process for managing received RLC discard information at the receiving RLC entity (200) of the XR radio bearer is described below (also in... Figures 4-6 (as shown in the image)

[0171] Example 6: For each RLC SDU with SN=x that is indicated as discarded in the received RLC discard information (e.g., RLC control PDU), the receiving side of the AM RLC entity (200) should:

[0172] - If x >= RX _Next_Highest:

[0173] - Update RX_Next_Highest to x+1.

[0174] - If x = RX_Highest_Status:

[0175] -> Update RX_Highest_Status to the SN of the first RLC SDU with SN > current RX_Highest_Status, where all bytes of the first RLC SDU have not yet been received and the first RLC SDU was not indicated as dropped in the RLC drop information.

[0176] - If x = RX_Next:

[0177] -> Update RX_Next to the SN of the first RLC SDU with SN > current RX_Next, where all bytes of the first RLC SDU have not yet been received and the first RLC SDU was not indicated as dropped in the RLC drop information.

[0178] - If t-Reassembly is running:

[0179] -> If RX_Next_Status_Trigger=RX_Next; or

[0180] -> If RX_Next_Status_Trigger = RX_Next + 1, and there is no missing byte segment of the SDU associated with SN=RX_Next before the last byte of all received segments of this SDU, or SN=RX_Next is indicated as dropped in the RLC drop information; or

[0181] -> -If RX_Next_Status_Trigger falls outside the receive window and RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size:

[0182] -> Stop and reset t-Reassembly.

[0183] - If t-Reassembly is not running (including cases where t-Reassembly has stopped due to the actions described above):

[0184] -> If RX_Next_Highest > RX_Next + 1; or

[0185] -> If RX_Next_Highest = RX_Next + 1, and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU; or

[0186] -> Start t-Reassembly;

[0187] Set RX_Next_Status_Trigger to RX_Next_Highest.

[0188] When the t-Reassembly period expires, the receiving side of the AM RLC entity (200) will:

[0189] - Update RX_Highest_Status to the SN of the first RLCSDU with SN>=RX_Next_Status_Trigger, where all bytes of the first RLC SDU have not yet been received;

[0190] - If RX_Next_Highest > RX_Highest_Status + 1: or

[0191] - If RX_Next_Highest = RX_Next + 1, and there is at least one missing byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU:

[0192] -> Start t-Reassembly;

[0193] Set RX_Next_Status_Trigger to RX_Next_Highest.

[0194] In the embodiments described herein, when the receiving side of the receiving UM RLC entity or AM RLC entity (200) determines that at least one byte segment of the RLC SDU is missing and the reassembly timer is started, and when the reassembly timer expires, the RLC entity (200) discards all segments of the SDU.

[0195] In the embodiments herein, out-of-order delivery is configured or permitted as an enhanced RLC discard configuration for the receiving side of the UM RLC entity (200) and / or the receiving side of the AM RLC entity (200). Furthermore, the receiving side of the UM RLC entity (200) and / or the receiving side of the AM RLC entity (200) discards incompletely received SDUs (i.e., SDU segments) upon expiry of the reassembly timer.

[0196] In the embodiments herein, when the receiving side of the AM RLC entity (200) receives RLC discard information (e.g., an RLC control PDU), the AM RLC entity (200) triggers transmission of a status report (i.e., a STATUS PDU) to its peer AM RLC entity.

[0197] Example 7: The AM RLC entity (200) transmits a STATUS PDU to its peer AM RLC entity to provide positive and / or negative acknowledgements for RLC SDUs (or portions thereof).

[0198] Triggers for initiating a STATUS report include:

[0199] - RLC discard information received from its peer AM RLC entity:

[0200] -> When the RLC discard information includes an RLC SDU with SN=x, the receiving side of the AM RLC entity (200) shall:

[0201] -> If x<RX_Highest_Status or x>=RX_Next+AM_Window_Size:

[0202] -> Trigger the STATUS report.

[0203] -> Otherwise:

[0204] -> Delay triggering the STATUS report until x<RX_Highest_Status or x>=RX_Next+AM_Window_Size.

[0205] In the embodiments herein, the receiving side of the AM RLC entity (200) provides a positive acknowledgement in the STATUS report for the RLC SDU with SN=x included in the received RLC discard information.

[0206] In the embodiments of the present disclosure, when the receiving side of an AM RLC entity (200) receives RLC discard information (for example, an RLC control PDU), the AM RLC entity (200) triggers sending a status report (i.e., a STATUS PDU) to its peer AM RLC entity, without considering delaying the triggering of the STATUS report until x<RX_Highest_Status or x>=RX_Next+AM_Window_Size, where the RLC PDU with SN=x is included in the received RLC discard information.

[0207] In the embodiments of the present disclosure, when the receiving side of the AM RLC entity (200) receives RLC discard information (for example, an RLC control PDU) including at least one discarded RLC SDU with SN=x, and receives the RLC SDU with SN=x or a segment of the RLC SDU at the same time or within the time period during which the status prohibit timer is running, the receiving side of the AM RLC entity (200) discards the RLC SDU with SN=x or the segment of the RLC SDU and triggers a STATUS report. In addition, the receiving side of the AM RLC entity (200) provides a positive acknowledgement for the RLC SDU with SN=x included in the received RLC discard information in the STATUS report.

[0208] In the embodiments of the present disclosure, examples of proposed specifications for constructing a STATUS PDU when the receiving side of AM RLC has received RLC discard information are provided as follows:

[0209] Example 8: When constructing a STATUS PDU, the AM RLC entity (200) shall:

[0210] - For RLC SDUs with SN such that RX_Next<=SN<RX_Highest_Status that have not been completely received, in the order of increasing SN of the RLC SDUs and increasing order of byte segments within the RLC SDU, starting from SN=RX_Next until the point where the resulting STATUS PDU still fits within the total size of the RLC PDU(s) indicated by the lower layer:

[0211] -> For byte segments of the RLC SDU that have not been received and are not indicated as discarded in the RLC discard information, if included in the RLC discard information:

[0212] -> Include NACK_SN in the STATUS PDU, where NACK_SN is set to the SN of the RLC SDU.

[0213] -> For a consecutive sequence of byte segments of a received RLCSDU that has not yet been received and was not indicated as discarded in the RLC discard information, if it is included in the RLC discard information:

[0214] -> The STATUS PDU includes a set of NACK_SNs, SOstart, and SOend.

[0215] -> For consecutive sequences of RLC SDUs that have not yet been received and are not indicated as dropped in the RLC drop information, if included in the RLC drop information:

[0216] -> The STATUS PDU includes a set of NACK_SNs and a range of NACKs;

[0217] -> Include the SOstart and SOend pairs in the STATUS PDU if needed.

[0218] - Set ACK_SN to the SN of the next unreceived RLC SDU that is not indicated as missing in the obtained STATUS PDU (i.e., if included in the RLC drop information, also consider the SN of the RLC SDU that is indicated as dropped in the RLC drop information).

[0219] Figure 2 Various hardware components of the RLC entity of a receiver device (200) according to embodiments disclosed herein are shown. In an embodiment, the RLC entity (200) includes a processor (210), a communicator (220), a memory (230), and an XR service controller (240). The processor (210) is coupled to the communicator (220), the memory (230), and the XR service controller (240).

[0220] Furthermore, the XR service controller (240) determines whether any unreceived SDUs have expired and abandons the reception of expired SDUs. Based on this determination, the XR service controller (240) processes the RLC receive operation.

[0221] Furthermore, when at least one of the reorganization timer, the local timer, and the configured timer expires, and at least one of the following conditions is met: an RLC SDU with sequence number (SN) X has not been received and an RLC SDU with sequence number (SN) X has not been fully received, the XR service controller (240) determines that at least one RLC SDU with sequence number (SN) X has expired. The SN X of at least one RLC SDU is less than the SN Y associated with the timer, where SN Y is an Rx Outdated Trigger, and where the Rx Outdated Trigger holds the highest possible value of the SN after triggering the discarding of (multiple) RLC SDUs or segments of (multiple) RLC SDUs upon timer expiration.

[0222] In an embodiment, the XR service controller (240) is configured by a network entity in an RRC signaling message with at least one of the following parameters: a timer (e.g., t-Outdated) and a parameter that associates the timer with SN Y (e.g., an Rx Outdated Trigger). The configuration is associated with at least one of the following: per RLC entity, per bearer, per LCG, and common to UE. SN Y is an Rx Outdated Trigger, and wherein the Rx Outdated Trigger stores the highest possible value of the SN following the SN of the RLC SDU(s) that triggers the discarding of the RLC SDU(s) or a segment of the RLC SDU(s) upon timeout.

[0223] Furthermore, the XR service controller (240) determines that at least one byte segment of at least one RLC SDU with SN X has been received before the moment when the receiving side of the AM RLC entity (200) determines that the RLC SDU with SN X has expired. The SN X of at least one RLC SDU is less than the SN Y associated with a timer (e.g., Rx Outdated Trigger). Based on this determination, the XR service controller (240) discards at least one byte segment of the stored at least one RLC SDU with SN X.

[0224] In this embodiment, the XR service controller (240) determines that an AMD PDU has been received from the lower layer. After an RLCSDU with SN X is determined to be expired, the AMD PDU includes at least one byte segment of an RLC SDU with SN X or an RLC SDU with SN X. Based on this determination, the XR service controller (240) discards or abandons the received AMD PDU.

[0225] In an embodiment, when an AMD PDU with SN X is received and if all bytes of an RLC SDU with SN X are received, the XR service controller (240) updates the status variable RX Highest Status to SN Y of the first RLC SDU whose bytes have not yet been received, such that SN Y is greater than the current RX Highest Status, and the first RLC SDU has not yet been determined to be expired.

[0226] In an embodiment, when an AMD PDU with SN X is received and if all bytes of an RLC SDU with SN X are received, the XR service controller (240) updates the state variable RX Next to the SN Y of the first SDU whose bytes have not yet been received, such that SN is greater than the current RX Next, and the first SDU has not yet been determined to be expired. RX Next is a state variable that stores the value of SN after the last RLC SDU received in sequence, and RX Next serves as the lower edge of the receive window.

[0227] In an embodiment, the XR service controller (240) updates the state variable RX Next Highest to SN X increment by 1, where X is the sequence number of the last received RLC SDU that is determined to be expired, and X is greater than or equal to the current RXNext Highest.

[0228] In this embodiment, the XR service controller (240) records the SNX of each of the RLC SDUs determined to be expired, such that SN X is greater than the current RX Next. Furthermore, the XR service controller (240) skips the expected reception of expired RLC SDUs from the sending entity. Additionally, the XR service controller (240) updates at least one state variable of the SN X of each of the recorded RLC SDUs.

[0229] In an embodiment, when the receiving RLC entity (200) has received an RLC SDU or a segment of an RLC SDU with SN X and the RLC SDU or the segment of an RLC SDU with SN X is determined to be expired, the XR service controller (240) processes the RLCSDU. Furthermore, the XR service controller (240) delivers the RLC SDU to the upper layer based on this processing.

[0230] In this embodiment, when the receiving RLC entity (200) has received an RLC SDU or a segment of an RLC SDU with SN X and the RLC SDU or the segment of an RLC SDU with SN X is determined to be expired, the XR service controller (240) avoids processing the RLC SDU. Furthermore, the XR service controller (240) avoids delivering the RLC SDU to the upper layer. Additionally, the XR service controller (240) discards any received RLC SDUs or RLC SDU segments.

[0231] In an embodiment, when the receiving side of an AM RLC entity (200) determines that an RLC SDU has expired and been abandoned, the XR service controller (240) triggers the sending of a status report to the peer AM RLC entity.

[0232] In an embodiment, when at least one RLC SDU with SN X is determined to be expired and abandoned, the XR service controller (240) triggers a status report, wherein the determination is based on the expiration of a timer (e.g., t-Outdated).

[0233] In this embodiment, the XR service controller (240) delays triggering a status report until the expired SDU's SN X is less than RX Highest Status or SN X is greater than or equal to the sum of RX Next and AM window size.

[0234] In this embodiment, the XR service controller (240) provides a positive acknowledgment for the RLC SDU with SN X in the status report. SN X is determined to be expired and abandoned by the receiving side of the AM RLC entity (200).

[0235] In an embodiment, when the receiving side of the AM RLC entity (200) determines an expired RLC SDU, the XR service controller (240) triggers the sending of a status report to the peer AM RLC entity (200) without considering the delay in triggering a STATUS report until SNX is less than RX Highest Status or SN X is greater than the sum of RX Next and AM window size, where the RLC SDU with SN X is determined to be expired.

[0236] In an embodiment, when the receiving side of the AM RLC entity (200) determines at least one expired RLCSDU with SN X, and the RLC SDU with SN X or a segment of the RLC SDU is received simultaneously or during the time period of the state prohibition timer, the XR service controller (240) discards the RLC SDU with SN X or the segment of the RLC SDU. Furthermore, the XR service controller (240) triggers a status report. Additionally, the XR service controller (240) provides a positive acknowledgment in the status report for the RLC SDU with the determined expired SN X.

[0237] In an embodiment, when the receiving side of the AM RLC entity (200) determines that an expired SDU, the XR service controller (240) generates a status PDU.

[0238] In an embodiment, when it is determined that timer t-Outdated is not running and RX Next Highest is at least one of the following, the XR service controller (240) starts the timer (e.g., t-Outdated) and sets Rx OutdatedTrigger to RX Next Highest: greater than RX Next plus one, or equal to RX Next plus one and there is at least one missing byte segment of the SDU associated with an SN equal to RX Next before the last byte of all received segments of that SDU.

[0239] In one embodiment, the XR service controller (240) determines whether a timer (e.g., t-Outdated) has expired and when t-Outdated expires. In another embodiment, the XR service controller (240) discards byte segments of each of the RLC SDUs having SN X, where SN X is less than the Rx Outdated Trigger. In another embodiment, the XR service controller (240) updates RX_Nextt to the SN Y of a first RLC SDU having SN Y greater than or equal to the Rx Outdated Trigger, where all bytes of the first RLC SDU have not yet been received. In another embodiment, the XR service controller (240) starts a timer (e.g., t-Outdated) and sets the Rx Outdated Trigger to RX Next Highest if RX NextHighest is greater than RX Next + one, or equal to RX Next + one and there is at least one missing byte segment of an SDU associated with an SN equal to RX Next before the last byte of all received segments of that SDU.

[0240] The XR service controller (240) is implemented by analog and / or digital circuitry, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware.

[0241] The processor (210) may include one or more processors. The one or more processors may be general-purpose processors (such as central processing unit (CPU), application processor (AP), etc.), graphics-only processing units (such as graphics processing unit (GPU), vision processing unit (VPU)) and / or AI-specific processors (such as neural processing unit (NPU)). The processor (210) may include multiple cores and is configured to execute instructions stored in memory (230).

[0242] Furthermore, the processor (210) is configured to execute instructions stored in the memory (230) and perform various processes. The communicator (220) is configured for internal communication between internal hardware components and for communication with external devices via one or more networks. The memory (230) also stores instructions to be executed by the processor (210). The memory (230) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Additionally, in some examples, the memory (230) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be construed as meaning that the memory (532) is immovable. In some instances, a non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache memory).

[0243] although Figure 2 Various hardware components of the RLC entity (200) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the RLC entity (200) may include fewer or more components. Furthermore, the labels or names of components are for illustrative purposes only and do not limit the scope of this disclosure. One or more components may be combined to perform the same or substantially similar functions in the RLC entity (200).

[0244] Figure 3 This is a flowchart (S300) illustrating a method for processing RLC receive operations of XR services in a wireless network (1000) according to an embodiment disclosed herein. The operations (S302-S304) are processed by the XR service controller (240).

[0245] At S302, the method includes determining whether an SDU that has not yet been received is expired, and abandoning reception of the expired SDU. At S304, the method includes processing an RLC reception operation based on the determination.

[0246] Figure 4 illustrates an example enhanced receiver RLC entity operation (400) for determining whether an SDU that has not yet been received or has not been completely received is expired and abandoning reception of the expired SDU according to the embodiments disclosed herein.

[0247] In step S402, the receiving RLC entity (200) is configured with expired SDU discard configuration parameters (for example, a t-Outdated timer, an RX_Outdated_Trigger parameter). At step S404, when the t-Outdated timer expires and x < RX_Outdated_Trigger, the receiving RLC entity (200) determines the RLC SDU with SN=x as expired and to be abandoned, and discards the byte segments of the received RLC SDU (if any). At step S406, the receiving RLC entity (200) sends an acknowledgment (ACK) for the associated RLC SDU that is determined to be expired and to be abandoned to the transmitting RLC entity (100) in a status report.

[0248] Figure 5 and Figure 6 are flowcharts (S500 and S600) illustrating a method for managing expired RLC SDUs at the receiving RLC entity (200) according to the embodiments disclosed herein.

[0249] As Figure 5 shown, at S502, when it is determined that the timer t-Outdated is not running and RX Next Highest is at least one of the following, the receiving side of the AM RLC entity (200) starts the timer t-Outdated, and sets RxOutdated Trigger to RX Next Highest: greater than RX Next plus one, or equal to RX Next plus one and there exists at least one missing byte segment of the SDU associated with the SN equal to RX Next before the last byte of all received segments of the SDU.

[0250] As Figure 6As shown, operations (S602-S608) are processed by the XR service controller (240). In S602, the receiving side of the AM RLC entity (200) determines whether timer t-Outdated has expired. When timer t-Outdated expires, at S604, the method includes discarding byte segments of each of the RLC SDUs having SN X, where SN X is less than RxOutdatedTrigger. When timer t-Outdated expires, at S606, the method includes updating RX_Next to SN Y of the first RLC SDU having SN Y greater than or equal to RxOutdated Trigger, where all bytes of the first RLC SDU have not yet been received. When the timer t-Outdated expires, at S608, the method includes starting the timer (e.g., t-Outdated) and setting the Rx Outdated Trigger to RXNext Highest if RX Next Highest is at least one of the following: greater than RX Next plus one, or equal to RX Next plus one, and there is at least one missing byte segment of the SDU associated with an SN equal to RX Next before the last byte of all received segments of the SDU.

[0251] Figure 7 An example RLC discard information processing method (S700) for receiving RLC entities (200) for XR services according to embodiments disclosed herein is shown. Operations (S702-S706) are processed by the XR service controller (240).

[0252] At S702, the method includes receiving RLC discard information and processing each RLC SDU with SN=x that is indicated to be discarded in the received RLC discard information. At S704, the method includes checking whether x is greater than or equal to RX_Next_Highest. If so, proceed to the next step, at S706, where the method includes updating RX_Next_Highest to X+1.

[0253] Figure 8 An example RLC discard information processing method (S800) for XR service at the receiving RLC entity (200) according to an embodiment disclosed herein is shown. The operation (S802-S806) is processed by the XR service controller (240).

[0254] At S802, the method includes receiving RLC discard information and processing each RLC SDU with SN=x that is indicated as discarded in the received RLC discard information. At step 804, the method includes checking whether x is greater than or equal to RX_Highest_Status. If so, proceed to the next step (at step 806), where the method includes updating RX_Highest_Status to the SN of the first RLC SDU with SN > current RX_Highest_Status, wherein not all bytes of the first RLC SDU have been received, and the first RLC SDU was not indicated as discarded in the RLC discard information.

[0255] Figure 9 An example RLC discard information processing method (S900) at a receiving RLC entity for XR is shown according to an embodiment disclosed herein. The operation (S902-S906) is processed by the XR service controller (240).

[0256] At S902, the method includes receiving RLC discard information and processing each RLC SDU with SN=x that is indicated as discarded in the received RLC discard information. At S904, the method includes checking whether x is greater than or equal to RX_Next. If so, proceed to the next step (i.e., at S906, the method includes updating RX_Next to the SN of the first RLC SDU with SN> the current RX_Next, wherein not all bytes of the first RLC SDU have been received, and the first RLC SDU was not indicated as discarded in the RLC discard information).

[0257] This method can be used to achieve low latency and reliable data transmission for XR services, and improve the user experience for both the UE and the network side.

[0258] The various actions, behaviors, blocks, steps, etc. in the flowchart (S300-S900) can be executed in the order they are presented, in different orders, or simultaneously. Furthermore, in some embodiments, actions, behaviors, blocks, steps, etc., can be omitted, added, modified, or skipped without departing from the scope of this disclosure.

[0259] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control network elements. Elements include blocks, which may be at least one of hardware devices or a combination of hardware devices and software modules.

[0260] The embodiments disclosed herein describe a method and system for receiving RLC operations for XR services in a wireless network (1000). Therefore, it should be understood that the scope of protection extends to such programs, and further to computer-readable components containing messages. Such computer-readable storage components contain program code components for implementing one or more steps of the method when the program is run on a server or mobile device or any suitable programmable device. In at least one embodiment, the method is implemented by or with a software program written in, for example, a Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL), another programming language, or by one or more VHDL or software modules executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include components that can be, for example, hardware components (e.g., ASICs) or a combination of hardware and software components (e.g., ASICs and FPGAs or at least one microprocessor and at least one memory with software modules located therein). The method embodiments described herein can be implemented partly in hardware and partly in software. Alternatively, the invention can be implemented on different hardware devices, for example, using multiple CPUs.

[0261] The description of the specific embodiments above will fully reveal the general nature of the embodiments herein. Others can readily modify and / or adapt these specific embodiments for various applications by applying existing knowledge without departing from the general concepts. Therefore, such modifications and adaptations should and are intended to be understood as equivalents of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although the embodiments herein have been described with reference to examples, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the scope of the embodiments described herein.

Claims

1. A method performed by a receiver device in a wireless communication system, the method comprising: The expiration of Radio Link Control (RLC) Service Data Unit (SDU) with sequence number SN X is determined based on a timer. and A status report is sent to the transmitter device, the status report including a positive acknowledgment of the RLC SDU with SN X.

2. The method according to claim 1, further comprising: Discard the RLC SDU.

3. The method according to claim 1, in, An RLC SDU with serial number SN X is determined to be expired if the timer expires and the RLC SDU with serial number SN X has not been received or has not been fully received.

4. The method according to claim 1, in, The timer corresponds to one of the following: a reconfiguration timer, a local timer, and a configured timer. The timer and its associated parameters are configured based on Radio Resource Control (RRC) messages.

5. The method according to claim 1, in, The status report was triggered. If the Radio Link Control (RLC) entity of the receiver equipment determines that the RLC SDU has expired, or In the case where the RLC entity of the receiver device determines that the RLC SDU with SN X has expired based on the expiration of the timer.

6. The method according to claim 1, in, The triggering of the status report is delayed until the SN X of the expired RLC SDU is less than the received RX higheststatus, or SN X is greater than or equal to the sum of RX next and the acknowledgment mode AM window size, or The status report is triggered without considering delay until SN X is less than RX higheststatus or SN X is greater than the sum of RX next and AM window size.

7. The method according to claim 1, further comprising: Upon receiving an acknowledgment mode data AMD protocol data unit PDU with SN X and if all bytes of an RLC SDU with SN X are received, the status variable RX highest status is updated to SN Y of the first RLC SDU whose bytes have not yet been received, such that SN Y is greater than the current RX highest status, and the first RLC SDU has not yet been determined to be expired, wherein the RX highest status is stored in the highest possible value of the SN of the RLCSDU with the highest SN among the received RLC SDUs. Upon receiving an AMD PDU with SN X and if all bytes of an RLC SDU with SN X are received, update the state variable RX next to SN Y of the first SDU whose bytes have not yet been received, such that SN Y is greater than the current RX Next, and wherein the first SDU has not yet been determined to be expired, wherein RX next is a state variable that holds the value of SN after the last RLC SDU received in sequence, and RX next is used as the lower edge of the receive window; or Update the state variable RX next highest to SN X plus one, where X is the sequence number of the last received RLC SDU that has been determined to expire, and X is greater than or equal to the current RX next highest.

8. A receiver device in a wireless communication system, the receiver device comprising: transceiver; and At least one processor, coupled to the transceiver and configured to: Based on a timer, the expiration of the Radio Link Control (RLC) Service Data Unit (SDU) with sequence number SN X is determined, and A status report is sent to the transmitter device, the status report including a positive acknowledgment of the RLC SDU with SN X.

9. The receiver device according to claim 8, in, The at least one processor is also configured to discard the RLC SDU.

10. The receiver device according to claim 8, in, An RLC SDU with serial number SN X is determined to be expired if the timer expires and the RLC SDU with serial number SN X has not been received or has not been fully received.

11. The receiver device according to claim 8, in, The timer corresponds to one of the following: a reconfiguration timer, a local timer, and a configured timer. The timer and its associated parameters are configured based on Radio Resource Control (RRC) messages.

12. The receiver device according to claim 8, in, The status report was triggered. If the Radio Link Control (RLC) entity of the receiver equipment determines that the RLC SDU has expired, or In the case where the RLC entity of the receiver device determines that the RLC SDU with SN X has expired based on the expiration of the timer.

13. The receiver device according to claim 8, in, The triggering of the status report is delayed until the SN X of the expired RLC SDU is less than the received RX higheststatus, or SN X is greater than or equal to the sum of RX next and the acknowledgment mode AM window size, or The status report is triggered without considering delay until SN X is less than RX higheststatus or SN X is greater than the sum of RX next and AM window size.

14. The receiver device according to claim 8, in, The at least one processor is further configured to: Upon receiving an acknowledgment mode data AMD protocol data unit PDU with SN X and if all bytes of an RLC SDU with SN X are received, the status variable RX highest status is updated to SN Y of the first RLC SDU whose bytes have not yet been received, such that SN Y is greater than the current RX highest status, and the first RLC SDU has not yet been determined to be expired, wherein the RX highest status is stored in the highest possible value of the SN of the RLCSDU with the highest SN among the received RLC SDUs. Upon receiving an AMD PDU with SN X and if all bytes of an RLC SDU with SN X are received, update the state variable RX next to SN Y of the first SDU whose bytes have not yet been received, such that SN Y is greater than the current RX Next, and wherein the first SDU has not yet been determined to be expired, wherein RX next is a state variable that holds the value of SN after the last RLC SDU received in sequence, and RX next is used as the lower edge of the receive window; or Update the state variable RX next highest to SN X plus one, where X is the sequence number of the last received RLC SDU that has been determined to expire, and X is greater than or equal to the current RX next highest.

Images