Managing packet discard signaling for extended reality (XR) in a communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments disclosed herein describe a method and system for managing packet discard signaling for extended reality (XR) in a communication system. Further, comprising a first electronic device (100) and a second electronic device (200), each having a transmitting PDCP entity and a receiving PDCP entity, each having a memory, a processor and a PDCP sequence number (SN) gap controller. The controller determines whether a triggering criterion is met at the transmitting PDCP entity based on discarded or stored PDCP service data units (SDUs). If the criterion is met, the first electronic device (100) triggers packet discard signaling to the second electronic device (200) for generating a PDCP SN gap report. The second electronic device (200) processes discard information for SDUs within a reordering window, while ignoring those outside the window. This enables an efficient method for packet discard signaling and low latency operation for implementing XR.

Description

Technical Field

[0001] This application relates to wireless communication, and more specifically to managing packet drop signaling for extended reality (XR) in a communication system. 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 the "below 6 GHz" band, such as 3.5 GHz, but also in the "above 6 GHz" band, including 28 GHz and 39 GHz, known as mmWave. Furthermore, 6G mobile communication technology (called Super 5G systems) has been considered for implementation 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-volume data transmission 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, 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, Non-Terrestrial Network (NTN), which provides coverage and positioning for UE-satellite direct communication 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 number of connected devices will increase exponentially, 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 initiated 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. Summary of the Invention

[0008] Technical issues

[0009] The present invention has been made to address at least the aforementioned problems and / or disadvantages, and to provide at least the following advantages. Therefore, one aspect of the present invention provides a method and apparatus for managing packet drop signaling for extended reality (XR) in a communication system.

[0010] Solution to the problem

[0011] According to one aspect of this disclosure, a method performed by a user equipment (UE) is provided. The method includes: receiving from a base station a Radio Resource Control (RRC) message for configuring the transmission of a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report; identifying whether a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report is triggered; and, if a PDCP SN gap report is triggered, sending a PDCP SN gap report to the base station, wherein the PDCP SN gap report includes at least one of a first Drop Count (FDC) field and a Drop Bitmap field.

[0012] According to one aspect of this disclosure, a method performed by a base station is provided. The method includes: sending a Radio Resource Control (RRC) message to a User Equipment (UE) for configuring the transmission of a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report; and receiving a PDCP SN gap report from the UE, wherein the PDCP SN gap report includes at least one of a first Drop Count (FDC) field and a Drop Bitmap field.

[0013] According to one aspect of this disclosure, a user equipment (UE) is provided. The UE includes a transceiver and a controller coupled to the transceiver, and is configured to receive from a base station a Radio Resource Control (RRC) message for configuring the transmission of a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report, identify whether a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report is triggered, and, if a PDCP SN gap report is triggered, send a PDCP SN gap report to the base station, wherein the PDCP SN gap report includes at least one of a first Drop Count (FDC) field and a Drop Bitmap field.

[0014] According to one aspect of this disclosure, a base station is provided. The base station includes a transceiver and a controller coupled to the transceiver and configured to send a Radio Resource Control (RRC) message to a User Equipment (UE) for configuring the transmission of a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report, and to receive a PDCP SN gap report from the UE, wherein the PDCP SN gap report includes at least one of a first Drop Count (FDC) field and a Drop Bitmap field.

[0015] Beneficial effects of the invention

[0016] The advantages and salient features of the invention will become apparent to those skilled in the art from the following detailed description of exemplary embodiments disclosed in conjunction with the accompanying drawings. For more advanced communication systems, there is a need for methods and apparatus for avoiding the management of packet drop signaling for extended reality (XR) within the communication system. Attached Figure Description

[0017] The invention is illustrated in the accompanying drawings, in which the same reference numerals denote corresponding parts in each drawing. Embodiments herein will be better understood through the following description with reference to the accompanying drawings, wherein:

[0018] Figure 1 This is a block diagram of a first electronic device for managing packet drop signaling for XR in a communication system according to embodiments disclosed herein;

[0019] Figure 2 This is a block diagram of a second electronic device for managing packet drop signaling for XR in a communication system according to embodiments disclosed herein;

[0020] Figure 3 This is a flowchart illustrating a method for triggering packet dropping signaling for XR in a communication system according to embodiments disclosed herein;

[0021] Figure 4 This is a flowchart illustrating a mechanism in a communication system according to embodiments disclosed herein for generating and transmitting a PDCP SN gap report in response to the triggering of a packet drop signaling in response to XR.

[0022] Figure 5 This is a flowchart illustrating a method for setting a discard bitmap field for a transmitting PDCP entity of a first electronic device according to an embodiment disclosed herein.

[0023] Figure 6 This is a flowchart illustrating a method for allocating the length of a discard bitmap field for a transmitting PDCP entity of a first electronic device according to an embodiment disclosed herein.

[0024] Figure 7 This is a flowchart illustrating a mechanism for setting the FDC field by a transmitting PDCP entity of a first electronic device according to an embodiment disclosed herein.

[0025] Figure 8 This is a flowchart illustrating a method for processing a PDCP control PDU, including discard information, by a receiving PDCP entity of a second electronic device according to an embodiment disclosed herein.

[0026] Figure 9 This is a flowchart illustrating a method for transmitting a PDCP SDU to an upper layer based on an indication of a dropped SDU in packet drop signaling, according to an embodiment disclosed herein.

[0027] Figure 10This is a flowchart illustrating a PDCP SN gap controller mechanism for transmitting packet drop signaling and receiving and processing packet drop signaling in a communication system for XR according to embodiments disclosed herein. Detailed Implementation

[0028] These and other aspects of the exemplary 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 exemplary embodiments and their 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 exemplary embodiments herein without departing from the spirit of the embodiments herein, and the exemplary embodiments herein encompass all such modifications.

[0029] 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 help understand how the embodiments described herein can be implemented and to further enable those skilled in the art to implement the embodiments described herein. Therefore, these examples should not be construed as limiting the scope of the embodiments described herein.

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

[0031] The words / phrases “exemplary,” “example,” “illustration,” “in instance,” “etc.,” “e.g.,” “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,” “etc.,” “e.g.,” “i.e.,” is not necessarily to be construed as preferred or advantageous over other embodiments.

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

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

[0034] 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 a sequential order / placement / occurrence.

[0035] XR, encompassing virtual reality (VR), augmented reality (AR), and mixed reality (MR), represents a significant advancement in human-computer interaction. This technology is a key component of 5G and 5G advanced communication systems, designed to revolutionize how individuals interact with their digital environments. XR offers immersive experiences that blend the real and virtual worlds and contributes to the development of digital twins and the metaverse. These advancements promise to enhance various sectors, including entertainment, education, healthcare, and remote work.

[0036] Despite its transformative potential, integrating XR services into existing and future wireless networks presents numerous challenges. The task of the 3GPP New Radio (NR) framework supporting XR is to accommodate the demanding requirements of these applications, including high data rates, ultra-low latency, and energy-efficient connectivity. As XR applications become more prevalent, the pressure on network infrastructure to effectively manage these requirements intensifies.

[0037] A key component in wireless network architecture is the Protocol Data Convergence Protocol (PDCP) layer, which is responsible for various functions such as Service Data Unit (SDU) dropping, encryption, integrity protection, header compression, reordering, decryption, integrity verification, deduplication, and header decompression. These functions are essential for maintaining the security, efficiency, and reliability of data transmission in wireless networks.

[0038] However, the existing mechanisms used by PDCP to handle SDUs, particularly the SDU discarding process, are not well-suited to the unique needs of XR applications. XR services typically involve the transmission of tightly coupled sets of frames or PDUs, rather than the typical one-to-one mapping of IP packets to PDCP SDUs. This difference can lead to inefficiencies, especially when there are delays in the receiver's operation to provide timely delivery of received SDUs.

[0039] Due to stringent low-latency requirements, frequent and drastic SDU dropping in XR can cause this difference. In particular, the receiving PDCP entity may incur reordering delays due to the gaps caused by SDUs dropped at the transmitting PDCP entity in the received PDCP SDUs. The objective of embodiments of the present invention is to specify packet dropping signaling between the transmitting (Tx) PDCP and receiving (Rx) PDCP entities, including details regarding triggering, combining dropping information, and operations for transmitting and receiving such information.

[0040] The aim is to address the aforementioned shortcomings or other drawbacks, or at least provide a useful alternative.

[0041] The main objective of this invention is to provide a method and system for managing packet drop signaling in XR within a communication system.

[0042] Another object of the present invention is to provide a trigger for initiating drop signaling for XR in a wireless network.

[0043] Another object of the present invention is to combine and send PDCP SN gap reports.

[0044] Another objective of this invention is to receive and process PDCP SN gap reports and to further update PDCP state variables based on PDCP SN gap reports.

[0045] Another objective of this invention is to manage the PDCP reordering and transmission of XR in a wireless network.

[0046] Another object of the present invention is to configure the bearer for PDCP SN gap reporting for XR in a wireless network.

[0047] In one aspect, these objectives are achieved by providing a method and system for managing packet drop signaling in a communication system for XR. The method includes a first electronic device receiving a Radio Resource Control (RRC) signaling message from a second electronic device. This RRC signaling message includes a PDCP configuration for a radio bearer and specifies drop information for transmitting a PDCP entity. The first electronic device then determines whether a triggering criterion for the packet drop signaling is met. This triggering criterion includes the following conditions: a dropped PDCP SDU, an SDU with a count value greater than the count value of a dropped SDU, or a dropped SDU not submitted by the Radio Link Control (RLC) from the PDCP entity to a lower layer (e.g., the RLC layer, MAC layer, and PHY layer). If the criterion is met, the first electronic device triggers packet drop signaling with drop information on the received PDCP entity of the second electronic device to generate a PDCP sequence number (SN) gap report. If the criterion is not met, no triggering occurs.

[0048] On the other hand, these objectives are achieved by providing a system for managing packet drop signaling (i.e., PDCP SN gap reporting) in a communication system for XR. The system includes a first electronic device and a second electronic device, the first electronic device including a transmitting entity and a receiving entity, and the second electronic device also having a transmitting entity and a receiving entity. Each includes a memory, a processor, and a PDCP SN gap controller connected to the memory and the processor. The PDCP SN gap controller in the first electronic device determines whether triggering criteria for generating a PDCP SN gap report are met, wherein the PDCP SN gap report triggering criteria include at least one of the following: at least one PDCP Service Data Unit (SDU) is dropped, at least one stored PDCP SDU is associated with a count value greater than the count value associated with at least one dropped PDCP SDU, and at least one dropped PDCP SDU has not yet been submitted to a lower layer (such as the MAC layer and PHY layer) by Radio Link Control (RLC). If the criteria are met, it triggers packet drop signaling with drop information to cause the second electronic device to generate a PDCP SN gap report. If the criteria are not met, packet drop signaling is not triggered. The receiving PDCP entity of the second electronic device receives the packet drop signaling and checks whether the count value of the dropped SDU in the drop information is within the reordering window, and ignores or processes the drop information accordingly.

[0049] 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 preferred embodiments and many specific details thereof, it is given by way of illustration rather than limitation. Many changes and modifications can be made within the scope of the embodiments herein, and the embodiments herein include all such modifications.

[0050] 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. Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments. Unless otherwise stated, the term "or" as used herein means non-exclusive or. 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.

[0051] As is known in the art, embodiments 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 units or modules, etc.) are physically implemented by analog 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. The circuitry may, for example, be embodied 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). Without departing from the scope of the invention, each block of an embodiment may be physically divided into two or more interacting and discrete blocks. Similarly, without departing from the scope of the invention, the blocks of an embodiment may be physically combined into more complex blocks.

[0052] 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, this disclosure should be construed as extending to any modifications, equivalents, and substitutions. Although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally used only to distinguish one element from another.

[0053] In the rapidly evolving wireless communication landscape, the integration of XR applications presents unique challenges, particularly in ensuring timely data delivery and efficient network resource utilization. XR applications encompassing Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR) require high data throughput and low latency to deliver a seamless user experience. Due to these low-latency requirements, SDU dropouts in XR can be very frequent and severe. Specifically, the receiving PDCP entity may incur reordering delays due to the SN gaps caused by SDU dropouts at the transmitting PDCP entity within the received PDCP SDU. Therefore, existing systems have significant limitations that can hinder the performance of XR applications.

[0054] The current SDU dropping process involves dropping a PDCP SDU when an associated timer expires or when the successful delivery of the PDCP SDU is confirmed, for example, by a PDCP status report from a peer PDCP entity. For XR applications, existing PDCP SDU dropping may not be efficient and effective because XR applications are more tightly coupled with frame (e.g., a set of packets, video frames, slices) transmissions rather than with IP packet transmissions that are typically mapped one-to-one to PDCP SDUs. For XR, an enhanced dropping mechanism has been introduced that considers dropping at the PDU set level (e.g., a set of SDUs belonging to the same frame or slice). However, regardless of whether dropping is performed at the SDU level or the PDU set level, there are drawbacks associated with the PDCP dropping mechanism. When dropping is performed, a SN gap may occur. When an SDU is received at the receiver entity, the SN gap can cause a reordering timer to run the entire process, and when the reordering timer expires, the receiver entity will be aware of the loss of the SDU with the associated SN. This results in a delay in receiver operations for providing timely delivery of received SDUs.

[0055] In the description of embodiments of the present invention, the terms COUNT and SN are used interchangeably. Generally, COUNT may include the superframe number (HFN) and SN. This does not limit or restrict the embodiments of the present invention in any way.

[0056] To overcome these limitations, the proposed invention introduces a solution for managing packet drop signaling in Extended Reality (XR) within a communication system. The method for managing packet drop signaling in Extended Reality (XR) within a communication system includes a first electronic device (100) receiving a Radio Resource Control (RRC) signaling message containing a PDCP configuration of a radio bearer from a second electronic device (200). The PDCP configuration includes parameters required for drop information to configure a transmitting PDCP entity (108) of the first device (100) to provide packet drop signaling to a receiving PDCP entity of the second device (200). The first device (100) then determines whether a triggering criterion is met at the transmitting PDCP entity. The PDCP SN gap reporting triggering criterion may include dropping at least one PDCP Service Data Unit (SDU), a stored PDCP SDU having a count value greater than the count value of the dropped SDU, or the dropped SDU not being submitted to the lower layer by Radio Link Control (RLC). If the criteria are met, the first device (100) triggers packet drop signaling with drop information to the receiving PDCP entity of the second device (200) to generate a PDCP sequence number (SN) gap report for the radio bearer; otherwise, the device avoids triggering the signaling.

[0057] In this embodiment, the first electronic device (100) is a user equipment, and the second electronic device (200) is a network device. Furthermore, each has a transmitting entity and a receiving entity.

[0058] In this embodiment, the first electronic device (100) is a network device, and the second electronic device (200) is a user device. Furthermore, each has a transmitting entity and a receiving entity.

[0059] In an embodiment, the method includes: in response to a trigger, a first electronic device (100) generates a PDCP SN gap report at a transmitting PDCP entity, wherein the PDCP SN gap report is compiled by setting at least one of a first drop count (FDC) field and a drop bitmap field; and for a Uu interface, the first electronic device (100) transmits the PDCP SN gap report from the transmitting PDCP entity to a lower layer of the first electronic device (100), wherein the Uu interface is an air interface between the first electronic device and a second electronic device.

[0060] In an embodiment, the method includes: sending discard information includes: a first electronic device (100) setting a PDCP control PDU type field to a value of 100 to indicate that the PDCP control PDU includes a PDCP SN gap report; and the first electronic device (100) sending the PDCP SN gap report in the PDCP control PDU.

[0061] In an embodiment, the method includes setting a discard bitmap field, which includes: determining, by a first electronic device (100), at a transmitting PDCP entity (108), that more than one PDCP SDU has been discarded; allocating the discard bitmap field by the transmitting PDCP entity of the first electronic device (100); setting all PDCP SDUs that have not yet been discarded to "0" in the discard bitmap field by the transmitting PDCP entity of the first electronic device (100); and setting the discard bitmap field to "1" in the discard bitmap field for all PDCP SDUs that have been discarded by the transmitting PDCP entity of the first electronic device (100).

[0062] In an embodiment, the method includes: allocating the discard bitmap field by the transmitting PDCP entity (108) of the first electronic device (100), which includes: determining the discard bitmap field for the PDCP SDU by the first electronic device (100), wherein the discard bitmap field is octet aligned and is a multiple of 8 bits; establishing a maximum size for the PDCP SDU by the first electronic device, wherein the maximum size is 9000 bytes; configuring the discard bitmap field by the first electronic device (100) to exclude the count value considering the first discarded PDCP SDU and to include the count value considering the next PDCP SDU to the last discarded PDCP SDU; and generating a PDCP control PDU by the first electronic device (100) including the discarded PDCP SDU. The discard information corresponding to the SDU; and the determination by the first electronic device (100) of whether the size of the PDCP control PDU is equal to or greater than 9000 bytes, performed by one of the following: when it is determined that the size of the PDCP control PDU is equal to or greater than 9000 bytes, allocating the length of the discard bitmap such that the PDCP control PDU is rounded to 9000 bytes, and when it is determined that the size of the PDCP control PDU is less than 9000 bytes, rounding the PDCP control PDU to a multiple of the next 8 bits including the last discarded PDCP SDU.

[0063] In an embodiment, the method includes setting the FDC field by: the transmitting PDCP entity of the first electronic device (100) setting the FDC field to the minimum count value among the count values ​​associated with the discarded PDCP SDU; the transmitting PDCP entity of the first electronic device (100) determining that only a single PDCP SDU is discarded; and the transmitting PDCP entity of the first electronic device (100) omitting the discard bitmap field in the PDCP control PDU to indicate the discarding of the single PDC SDU, wherein the length of the discard bitmap field is set to 0.

[0064] In an embodiment, the method includes the FDC field always being present, regardless of whether a single PDCP SDU or multiple PDCP SDUs are discarded, and wherein the discard bitmap field in the PDCP control PDU is present only when multiple PDCP SDUs are discarded.

[0065] In an embodiment, the method includes: discarding at least one PDCP SDU by a first electronic device (100) when a count value has not yet been assigned to at least one PDCP SDU at the sending PDCP entity; and excluding the at least one discarded PDCP SDU from the discard information carried in the discard signaling by the first electronic device (100).

[0066] In an embodiment, the method includes: a PDCP SN gap report being included in a PDCP control protocol data unit (PDU), and wherein when a PDCP entity is associated with one or more RLC entities, the PDCP control PDU including the PDCP SN gap report is submitted to only one RLC entity.

[0067] In an embodiment, the method includes: when a PDCP entity is associated with one or more RLC entities, submitting a PDCP control PDU including a PDCP SN gap report to only one associated RLC entity, wherein, in a dual-connectivity scenario, the associated RLC entity is a primary RLC entity or a separate auxiliary RLC entity.

[0068] In an embodiment, the method includes: a first electronic device (100) processing a PDCP SN gap report into a delay-critical PDCP data volume at the transmitting PDCP entity, while tracking a delay status report (DSR).

[0069] In an embodiment, the method includes: receiving a PDCP control PDU from a first electronic device (100) at a receiving PDCP entity by a second electronic device (200), wherein the PDCP control PDU includes discard information for one or more discarded Service Data Units (SDUs), each SDU being associated with a count value; determining at the receiving PDCP entity whether the count value of the discarded SDU in the discard information is outside a reordering window; when the count value of the discarded SDU is outside the reordering window, the second electronic device (200) at the receiving PDCP entity ignores the discard information in the PDCP control PDU for the discarded SDU having the count value outside the reordering window; and processing at the receiving PDCP entity discard information in the PDCP control PDU for other discarded SDUs having the count value within the reordering window.

[0070] In an embodiment, the method includes: updating the receive transmission (RX_DELIV) status variable at the receiving PDCP entity by the second electronic device (200) to a count value of a first PDCP SDU that has not yet been transmitted to the upper layer of the second electronic device (200) and is not considered discarded, wherein the count value is greater than the RX_DELIV value.

[0071] In an embodiment, the method includes having a second electronic device (200) at the receiving PDCP entity consider that the count value of a PDCP SDU indicated as discarded in the PDCP SN gap report will be assumed to have been received, while transmitting all stored PDCP SDUs with consecutive associated count values ​​to the upper layer in ascending order of the associated count values.

[0072] In an embodiment, the method includes: a first electronic device (100) being a user equipment, and a second electronic device (200) being a network device.

[0073] In an embodiment, the method includes: a first electronic device (100) being a network device, and a second electronic device (200) being a user device.

[0074] In an embodiment, a system for managing packet drop signaling for Extended Reality (XR) in a communication system includes a first electronic device (100) having a transmitting entity and a receiving entity, and a second electronic device (200) connected to the first electronic device (100), also including a transmitting entity and a receiving entity. The first electronic device (100) includes a memory (102), a processor (101), and a PDCP SN gap controller (103) connected to both the memory and the processor. The SN gap controller (103) determines whether a triggering criterion is met at the transmitting PDCP entity, wherein the PDCP SN gap reporting triggering criterion includes at least one of the following: dropping at least one PDCP Service Data Unit (SDU), the stored PDCP SDU having a count value greater than the count value of the dropped SDU, or the dropped SDU not being submitted to the lower layer by Radio Link Control (RLC). The controller then performs one of two actions: when the triggering criteria are met, it triggers packet drop signaling, which includes drop information of the received PDCP entity destined for the second electronic device (200) to generate a PDCP sequence number (SN) gap report for the radio bearer; or when the criteria are not met, it determines not to trigger packet drop signaling.

[0075] In one embodiment, the system includes a second electronic device (200), which includes a memory (202), a processor (201), and a PDCP SN gap controller (203) connected to the memory and the processor. The PDCP SN gap controller (203) receives PDCP control PDUs from the first electronic device (100) at a receiving PDCP entity and determines whether the count value of the discarded SDUs in the discard information is outside the reordering window. If the count value of the discarded SDUs is outside the reordering window, the receiving PDCP entity ignores the discard information of those SDUs. Otherwise, the receiving PDCP entity processes the discard information of discarded SDUs with count values ​​within the reordering window.

[0076] In one embodiment, the system includes a first electronic device (100) as a user device and a second electronic device (200) as a network device.

[0077] In one embodiment, the system includes a first electronic device (100) as a network device and a second electronic device (200) as a user device.

[0078] Now refer to the attached diagram, for more specific details. Figures 1 to 10 A preferred embodiment is shown.

[0079] Figure 1 This is a block diagram of a first electronic device for managing packet drop signaling for XR in a communication system. The first electronic device (100) includes a processor (101), a memory (102), and a PDCP SN gap controller (103).

[0080] Examples of the first electronic device (100) may include, but are not limited to, consumer electronics (such as mobile phones and smartphones), tablets, wearable devices, computing devices (such as laptops, notebooks, desktops, workstations, etc.), televisions, IoT devices, automotive systems (such as connected cars, autonomous vehicles, vehicle-to-everything (V2X) communication devices, etc.), enterprise devices (such as robots), specialized devices (such as medical devices, public safety devices, etc.), and media devices (such as game consoles, streaming media devices, etc.). These devices are equipped with various sensors and interfaces to support XR applications such as accelerometers, gyroscopes, cameras, and microphones, thereby enabling immersive user experiences. XR applications may include augmented reality (AR), virtual reality (VR), and mixed reality (MR), which require high data rates and low latency to operate effectively. Furthermore, the first electronic device (100) may support edge computing capabilities, allowing it to offload computationally intensive tasks to nearby servers, thereby reducing the processing burden on the device itself.

[0081] Examples of the first electronic device include wireless communication network systems, including but not limited to cellular networks (such as 2G, 3G, 4G, 5G, B5G / 6G or advanced cellular networks), local area networks (LANs) such as Wi-Fi, Li-Fi, etc.), personal area networks (PANs) such as Bluetooth, Zigbee, Z-Wave, etc.), wide area networks (WANs) such as satellite communication networks, long-range WANs, narrowband IoT, low-bandwidth communication for IoT, etc.), metropolitan area networks (MANs), machine-to-machine (M2M) networks, self-organizing and mesh networks, emerging and advanced networks.

[0082] The first electronic device (100) includes a protocol stack of the mobile communication system layer, such as a Packet Data Convergence Protocol (PDCP) entity (104), a Radio Link Control (RLC) entity (105), a Media Access Control (MAC) entity (106), and a Physical (PHY) entity (107).

[0083] The PDCP entity (104) is responsible for header compression, encryption, and integrity protection of data packets to ensure security and data transmission. In this embodiment, when the first electronic device (100) acts as a transmitter and performs transmitter-related operations, the PDCP entity (104) acts as a transmitting PDCP entity. Similarly, when the first electronic device (100) acts as a receiver and performs receiver-related operations, the PDCP entity (104) acts as a receiving PDCP entity. The RLC entity (105) manages the segmentation and reassembly of data packets, as well as error correction via the Automatic Repeat Request (ARQ) mechanism, which is used to maintain data integrity in XR applications. The MAC layer (106) handles the scheduling and prioritization of data packets, coordinating access to the shared radio medium to optimize network resource utilization. The PHY entity (107) is responsible for signal modulation and demodulation, as well as the transmission and reception of data over the air interface, utilizing advanced techniques such as OFDM (Orthogonal Frequency Division Multiplexing) and beamforming to enhance signal quality and coverage.

[0084] The processor (101) is responsible for executing instructions and managing the overall operation of the first electronic device (100), including the enhanced packet drop signaling mechanism. The processor (101) communicates with the memory (102) and the PDCP SN gap controller (103). The processor (101) is used to execute instructions stored in the memory (102) and perform various processes for real-time data processing in XR applications. The processor (101) may include one or more processors, which may be general-purpose processors (such as central processing unit (CPU), application processor (AP), etc.), pure graphics processing units (such as graphics processing unit (GPU), vision processing unit (VPU)) and / or artificial intelligence (AI) dedicated processors (such as neural processing unit (NPU)).

[0085] The memory (102) stores the operating system, application software, and temporary data used by the processor (101). The memory (102) stores Physical Downlink Control Channel (PDCCH) information, Downlink Control Information (DCI) information, and Physical Downlink Shared Channel (PDSCH) information. The memory (102) stores instructions to be executed by the processor (101). The memory (102) 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 (102) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier or propagating signal. However, the term "non-transitory" should not be construed as meaning that the memory (102) is immovable. In some examples, the memory (102) may be configured to store a larger amount of information than a standard memory. In the example, non-transitory storage media can store data that can change over time (e.g., in random access memory (RAM) or cache).

[0086] The PDCP SN gap controller (103) is hardware designed to manage packet drop signaling in an XR communication system. The PDCP SN gap controller (103) is physically implemented by analog or digital circuitry such as logic gates, integrated circuits, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware. The PDCP SN gap controller (103) determines whether a triggering criterion is met at the transmitting PDCP entity, wherein the PDCP SN gap reporting triggering criterion includes at least one of the following: the count value of the PDCP SDU stored in the discarded PDCP Service Data Unit (SDU) is greater than the count value of the discarded PDCP SDU, or the discarded PDCP SDU was not submitted to the lower layer by the Radio Link Control (RLC). Based on whether the criterion is met, the system performs one of two actions at the transmitting PDCP entity: triggering packet drop signaling, which includes drop information from the receiving PDCP entity sent to the second electronic device (200) for generating a PDCP sequence number (SN) gap report for the radio bearer, or determining not to trigger packet drop signaling when the criterion is not met.

[0087] In the embodiments, the proposed invention implements an efficient method for packet drop signaling and low-latency operation for XR. Furthermore, the ability of the PDCP SN gap controller (103) to dynamically adjust the priority of PDCP SDUs based on real-time conditions is a key feature for enhancing the overall performance and efficiency of the UE (100) in various network scenarios.

[0088] The PDCP SN gap controller (103) determines whether triggering criteria are met at the transmitting PDCP entity. These criteria include the following conditions: a PDCP SDU is dropped, at least one stored SDU is associated with a count greater than the dropped SDU, or the dropped SDU has not yet been submitted by the Radio Link Control (RLC) to a lower layer such as the MAC entity (106) and the PHY entity (107). If the PDCP SN gap controller (103) checks and finds the criteria met, the controller triggers packet drop signaling to generate a PDCP SN gap report, which is sent to the receiving PDCP entity of the second electronic device. If the criteria are not met, no signaling is triggered. Furthermore, the ability to generate and send PDCP SN gap reports enables improved synchronization between the transmitting and receiving entities.

[0089] In one embodiment, a first electronic device (100) includes a transmitting entity and a receiving entity, and a second electronic device (200) is connected to the first electronic device (100) and includes a transmitting entity and a receiving entity for managing packet drop signaling for extended reality (XR) in a communication system.

[0090] Figure 2 This is a block diagram of a second electronic device used to manage packet drop signaling for XR in a communication system. The second electronic device (200) includes a processor (201), a memory (202), and a PDCP SN gap controller (203).

[0091] Examples of second electronic devices (200) may include, but are not limited to, consumer electronics (such as mobile phones and smartphones), tablets, wearable devices, computing devices (such as laptops, notebooks, desktops, workstations, etc.), IoT devices, automotive systems (such as connected cars, autonomous vehicles, vehicle-to-everything (V2X) communication devices, etc.), enterprise devices (such as robots), specialized devices (such as medical devices, public safety devices, etc.), and media devices (such as game consoles, streaming media devices, etc.). These devices are equipped with various sensors and interfaces to support XR applications such as accelerometers, gyroscopes, cameras, and microphones, enabling immersive user experiences. XR applications may include augmented reality (AR), virtual reality (VR), and mixed reality (MR), which require high data rates and low latency to function effectively. Furthermore, the second electronic devices (200) may support edge computing capabilities, allowing them to offload computationally intensive tasks to nearby servers, thereby reducing the processing burden on the devices themselves.

[0092] Examples of the second electronic device (200) include wireless communication network systems, including but not limited to cellular networks (such as 2G, 3G, 4G, 5G, B5G / 6G or advanced cellular networks), local area networks (LANs) (such as Wi-Fi, Li-Fi, etc.), personal area networks (PANs) (such as Bluetooth, Zigbee, Z-Wave, etc.), wide area networks (WANs) (such as satellite communication networks, long-range WANs, narrowband IoT, low-bandwidth communication for IoT, etc.), metropolitan area networks (MANs), machine-to-machine (M2M) networks, self-organizing and mesh networks, emerging and advanced networks.

[0093] The second electronic device (200) includes a protocol stack of the mobile communication system layer, such as a Packet Data Convergence Protocol (PDCP) entity (204), a Radio Link Control (RLC) entity (205), a Media Access Control (MAC) entity (206), and a Physical (PHY) entity (207).

[0094] The PDCP entity (204) is responsible for header compression, encryption, and integrity protection of data packets to ensure secure data transmission. In this embodiment, when the first electronic device (200) acts as a transmitter and performs transmitter-related operations, the PDCP entity (204) acts as a transmitting PDCP entity. Similarly, when the first electronic device (200) acts as a receiver and performs receiver-related operations, the PDCP entity (204) acts as a receiving PDCP entity. The RLC entity (205) manages the segmentation and reassembly of data packets, as well as error correction via the Automatic Repeat Request (ARQ) mechanism, which is used to maintain data integrity in XR applications. The MAC entity (206) handles the scheduling and prioritization of data packets, coordinating access to the shared radio medium to optimize network resource utilization. The PHY entity (207) is responsible for signal modulation and demodulation, as well as the transmission and reception of data over the air interface, utilizing advanced techniques such as OFDM (Orthogonal Frequency Division Multiplexing) and beamforming to enhance signal quality and coverage.

[0095] The processor (201) is responsible for executing instructions and managing the overall operation of the second electronic device (200), including the enhanced packet drop signaling mechanism. The processor (201) communicates with the memory (202) and the PDCP SN gap controller (203). The processor (201) is used to execute instructions stored in the memory (202) and perform various processes for real-time data processing in XR applications. The processor (201) may include one or more processors, which may be general-purpose processors such as central processing unit (CPU), application processor (AP), graphics-only units such as graphics processing unit (GPU), vision processing unit (VPU), and / or artificial intelligence (AI) dedicated processors such as neural processing unit (NPU).

[0096] The memory (202) stores the operating system, application software, and temporary data used by the processor (201). The memory (202) stores Physical Downlink Control Channel (PDCCH) information, Downlink Control Information (DCI) information, and Physical Downlink Shared Channel (PDSCH) information. The memory (202) stores instructions to be executed by the processor (201). The memory (202) 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 (202) may be considered a non-transitory storage medium. The term non-transitory can indicate that the storage medium is not embodied in a carrier or propagating signal. However, the term non-transitory should not be construed as meaning that the memory (202) is immovable. In some examples, the memory (202) may be configured to store a larger amount of information than a standard memory. In the example, non-transitory storage media can store data that can change over time (e.g., in random access memory (RAM) or cache).

[0097] In the embodiments, the proposed invention implements an efficient method for packet drop signaling and low-latency operation for XR.

[0098] In this embodiment, the PDCP SN gap controller (103) determines whether triggering criteria are met at the transmitting PDCP entity (108). These criteria include the following conditions: one or more PDCP SDUs are dropped (e.g., when a drop timer expires), one or more stored PDCP SDUs are associated with a count value greater than the count value associated with at least one dropped PDCP SDU, and at least one dropped PDCP SDU has not yet been submitted to a lower layer by the RLC, has an SDU with a higher count value than the dropped PDCP SDU, or has not been submitted to a lower layer (such as the MAC entity (106) and PHY entity (107)) by the Radio Link Control (RLC). If the PDCP SN gap controller (103) checks and finds that the criteria are met, the controller triggers packet drop signaling to the receiving PDCP entity of the second electronic device (200) to generate an SN gap report. If the criteria are not met, no signaling is triggered.

[0099] Figure 3 This is a flowchart (300) illustrating a method for sending and receiving management packet discarding signaling for XR in a communication system.

[0100] In step 301, the method includes receiving an RRC signaling message with PDCP configuration by a first electronic device (100), the RRC signaling message including parameters required for discarding information to enable packet discarding signaling.

[0101] In step 302, the method includes a first electronic device (100) checking whether the triggering criteria for PDCP SN gap reporting are met.

[0102] In step 303, the method includes checking whether the triggering criteria for PDCP SN gap reporting are met, including discarding at least one PDCP service data unit (SDU).

[0103] In step 304, the method includes checking whether the triggering criteria for PDCP SN gap reporting are met, including whether the count value of at least one stored PDCP SDU is greater than the count value of a discarded PDCP SDU.

[0104] In step 305, the method includes checking whether the triggering criteria for PDCP SN gap reporting are met, including whether the dropped PDCP SDU has not yet been submitted to the lower layer (such as MAC entity (106) and PHY entity (107) by the Radio Link Control (RLC).

[0105] In step 306, the method includes: if the above triggering criteria are met, the first electronic device (100) triggers a packet drop signaling with drop information (i.e., PDCP SN gap report) to the second electronic device (200).

[0106] In step 307, the method includes generating a PDCP SN gap report for the radio bearer.

[0107] Figure 4 The flowchart (400) illustrates the mechanism for generating and sending PDCP SN gap reports in response to the triggering of packet drop signaling for XR in the communication system.

[0108] In step 401, the method includes generating a PDCP SN gap report at the sending PDCP entity in response to a trigger, and compiling the PDCP SN gap report by setting at least one of a first drop count (FDC) field and a drop bitmap field.

[0109] In step 402, the method includes combining discard information (i.e., PDCP SN gap report) within the PDCP control PDU.

[0110] In step 403, the method includes setting the PDCP control PDU type field to the value "100", indicating that the PDCP control PDU contains discard information.

[0111] In step 404, the method includes sending a PDCP SN gap report from the lower layer (e.g., RLC entity (104), MAC entity (106), and PHY entity (107)) of the PDCP entity to the UE and via the Uu interface, wherein the Uu interface is the air interface between the first electronic device and the second electronic device (200).

[0112] In an embodiment, the sending PDCP entity determines at least one gap in the sequence number of the PDCP SDU caused by the PDCP discard operation and triggers a discard signaling message including discard information to be sent to the receiving PDCP entity.

[0113] In this embodiment, the discard signaling, including discard information, is carried in the PDCP control PDU. The PDCP control PDU including discard information may be referred to as PDCP discard information and is identified by the PDU type field included in the PDCP control PDU carrying a specific value (e.g., a 3-bit PDU type field may be set to "100" to indicate that the PDCP control PDU is PDCP discard information).

[0114] In one embodiment, discard signaling including discard information is carried in at least one field in the header of the PDCP data PDU. The at least one field in the header may include the number of consecutive PDCP SDUs that have been discarded, and its SN is earlier than the SN of the PDCP SDU carrying the field in the header of the PDCP data PDU and the SN of the first discarded SDU. In another embodiment, a PDCP data PDU (or corresponding SDU) carrying at least one field in its header may be discarded, and then the next PDCP data PDU that is not discarded may carry at least one field in its header including discard information for the discarded SDU. In another embodiment, when the PDCP data PDU carries discard information in its header and when the data to be carried is unavailable, the PDCP data PDU may not include data (i.e., apply a payload), i.e., a header-only PDCP data PDU is constructed to carry the discard signaling. The header-only PDCP data PDU is assigned a count value (or SN) of the next PDCP SDU to be sent: COUNT (i.e., TX_NEXT).

[0115] In an embodiment, the discard signaling including discard information includes at least one discarded SDU sequence number.

[0116] In an embodiment, the discard signaling including discard information includes at least one set of first discarded SDU counts or sequence numbers (e.g., referred to as the first discard count FDC) and a range of consecutive discarded PDCP SDUs (i.e., sequentially ordered PDCP SDUs). For example, in the set, the range can be a field, value, or number indicating the number of sequentially ordered (or consecutive) SDUs discarded, starting from the first discarded SDU SN. The range may or may not include the first discarded SDU. In an alternative embodiment, the range in the set may correspond to the number of SDUs discarded in the PDU set. The FDC field may be 32 bits long.

[0117] Figure 5 This is a flowchart (500) illustrating a method for setting a discard bitmap field for a transmitting PDCP entity for a first electronic device (100).

[0118] In step 501, the method includes the transmitting PDCP entity of the first electronic device determining that more than one PDCP SDU has been discarded.

[0119] At step 502, the method includes the sending PDCP entity of the first electronic device allocating the length of the discard bitmap field.

[0120] In step 503, the method includes sending the PDCP entity of the first electronic device to set the (bit) in the discard bitmap field to "0" for all PDCP SDUs that have not yet been discarded.

[0121] In step 504, the method includes sending a PDCP entity of the first electronic device (100a) to set the (bit) in the discard bitmap field to "1" for all PDCP SDUs that have been discarded.

[0122] In this embodiment, when only one SDU is discarded, it is indicated by the FDC field, and the range field can be omitted in the PDCP control PDU. That is, the length of the bitmap field can be 0.

[0123] In an embodiment, when only one consecutive SDU is discarded, it is indicated by the FDC field, and the bitmap field can be omitted from the corresponding set of consecutive discard information in the PDCP control PDU.

[0124] In this embodiment, the sending PDCP entity compiles and sends each set of discard information (e.g., consisting of an FDC field and / or a range field) of the continuously discarded SDUs to the receiving PDCP entity in a separate PDCP control PDU. That is, multiple PDCP control PDUs can be sent.

[0125] In this embodiment, the sending PDCP entity compiles and sends each set of discard information (e.g., consisting of an FDC field and / or a range field) of the continuously discarded SDUs to the receiving PDCP entity in a separate PDCP control PDU. That is, multiple PDCP control PDUs can be sent.

[0126] In an embodiment, at least one set of discard information in the discard signaling (e.g., PDCP control PDU) may be related to an SDU that is discarded due to discardTimer expiration and / or discardTimerLowImportance expiration.

[0127] In an embodiment, two or more sets of discard information included in the discard signaling (e.g., PDCP control PDU) may be discontinuous.

[0128] Figure 6 This is a flowchart (600) illustrating a method for allocating the length of the discard bitmap field for the transmitting PDCP entity of a first electronic device.

[0129] In step 601, the method includes determining a discard bitmap field of the PDCP SDU, the discard bitmap field being octet aligned and a multiple of 8 bits.

[0130] In step 602, the method includes setting the maximum size of the PDCP SDU (9000 bytes).

[0131] In step 603, the method includes configuring a discard bitmap to exclude the count value of the first discarded PDCP SDU from being considered, and includes considering the count values ​​from the next PDCP SDU up to the last discarded PDCP SDU.

[0132] In step 604, the method includes generating a PDCP control PDU having discard information corresponding to discarded PDCP SDUs and non-discarded PDCP SDUs.

[0133] In step 605, the method includes determining whether the size of the PDCP control PDU is equal to or greater than 9000 bytes.

[0134] In step 606, the method includes: if the size is ≥ 9000 bytes, it allocates the length of the discard bitmap such that the PDCP control PDU is rounded to 9000 bytes; if the size is < 9000 bytes, it rounds the PDCP control PDU to a multiple of the next 8 bits including the last discarded PDCP SDU.

[0135] In an embodiment, the discard signaling including discard information (e.g., PDCP control PDU) includes at least one of a bitmap of a first discard SDU count or sequence number (e.g., referred to as the first discard count FDC) and consecutive PDCP SDUs (i.e., PDCP SDUs arranged in sequence), wherein the bitmap indicates whether to discard the PDCP SDU (e.g., the corresponding ordered bit in the bitmap is set to 1) or not to discard the PDCP SDU (e.g., the corresponding ordered bit in the bitmap is set to 0). For example, the first bit in the bitmap may refer to the SDU with the next sequence number after the first discarded SDU sequence number included in the discard information. Furthermore, the position of the bit in the bitmap may represent a value having COUNT(FDC + bit position) modulo 2. 32 PDCP SDU.

[0136] In one embodiment, the bitmap is 8-bit byte aligned (a multiple of 8 bits), and the last bit in the bitmap may not correspond to the last discarded SDU sequence number. In another embodiment, bits after the last bit in the bitmap that is set to 1 (i.e., the SDU SN is discarded) can be interpreted by the receiver as irrelevant; that is, the receiver may not be certain of any discard status of the SDU with the corresponding SN. The FDC field can be 32 bits long.

[0137] In an embodiment, the bitmap field in the PDCP control PDU containing the discard information is assigned a length (in bits) equal to the number of counts from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last discarded PDCP SDU (including the last discarded PDCP SDU), which is rounded up to the next multiple of 8, or until the generated PDCP control PDU is equal to a PDCP SDU of 9000 bytes (whichever comes first).

[0138] Figure 7 This is a flowchart (700) illustrating the mechanism for setting the FDC field by the transmitting PDCP entity of the first electronic device (100).

[0139] In step 701, the method includes the transmitting PDCP entity of the first electronic device setting the FDC field to the minimum count value among the count values ​​associated with the discarded PDCP SDU.

[0140] In step 702, the method includes the transmitting PDCP entity of the first electronic device determining to discard only a single PDCP SDU.

[0141] In step 703, the method includes omitting the discard bitmap field in the PDCP control PDU to indicate the discarding of a single PDCPSDU, i.e., the length of the bitmap field is 0.

[0142] In step 704, the method includes the FDC field always existing in the PDCP control PDU, regardless of whether a single PDCP SDU or multiple PDCP SDUs are discarded.

[0143] In step 705, the method includes the discard bitmap field existing in the PDCP control PDU only when multiple PDCP SDUs are discarded.

[0144] In embodiments, the SDU discarding process involves discarding a PDCP SDU when the associated timer has expired or when the successful delivery of the PDCP SDU is confirmed, for example, by a PDCP status report from a peer PDCP entity. For XR applications, existing PDCP SDU discarding may not be efficient and effective because XR applications are more tightly coupled with frame (e.g., a set of packets, video frame slices) transmissions than with IP packet transmissions, which are typically mapped one-to-one to PDC / PSDUs. For XR, an enhanced discarding mechanism has been introduced that considers discarding at the PDU set level (e.g., a set of SDUs belonging to the same frame or slice). However, whether discarding is performed at the SDU level or the PDU set level, there are drawbacks associated with the PDCP discarding mechanism. When discarding is performed, it can lead to SN gaps. When an SDU is received at the receiver entity, an SN gap can cause a reordering timer to run the entire process, and when the reordering timer expires, the receiver entity will be aware of the loss of the SDU with the associated SN. This results in delays in receiver operations (for providing timely delivery of received SDUs).

[0145] In an embodiment, the bitmap field in the PDCP control PDU containing the discard information is assigned a length (in bits) equal to the number of PDCP SDUs from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the PDCP SDUs (including the PDCP SDUs) with a count of TX_NEXT minus 1 (i.e., the count before TX_NEXT), which is rounded up to the next multiple of 8 or until the generated PDCP control PDU is equal to a PDCP SDU of size 9000 bytes (whichever comes first).

[0146] In this embodiment, when only one SDU is discarded, it is indicated by the FDC field, and the bitmap field can be omitted in the PDCP control PDU. That is, the length of the bitmap field can be 0.

[0147] In an embodiment, the first discard count (FDC) may also be referred to as the first loss count (FMC), and the discarded SDUs may also be referred to as lost SDUs.

[0148] In this embodiment, after the associated discard timer and / or low-importance discard timer have expired, the SDUs of the PDU set subsequently received from the upper layer are not assigned a count (or SN), and further, these SDUs of the PDU set are discarded and are not included in the discard information carried in the discard signaling. The discard information carried in the discard signaling includes SDUs in the PDU set other than those of the subsequently received PDU set.

[0149] In an embodiment, when at least one SDU / PDU is discarded (e.g., when PDU set discard is not configured (pdu-SetDiscard)), or when at least one PDU set is discarded (e.g., when PDU set discard is configured (pdu-SetDiscard)), or when at least one SDU / PDU in a PDU set is discarded (e.g., when PDU set discard is configured (pdu-SetDiscard)), and at least one discarded SDU / PDU or at least one SDU / PDU in the discarded PDU set has not yet been submitted to one or more associated RLC entities, a PDCP SN gap is determined and a discard signaling is triggered by the sending PDCP entity. At least one discarded SDU or at least one SDU in the discarded PDU set may have already been assigned a count by the sending PDCP entity.

[0150] In an embodiment, when at least one SDU / PDU is discarded (e.g., when PDU set discard (pdu-SetDiscard) is not configured) or at least one PDU set is discarded (e.g., when PDU set discard (pdu-SetDiscard) is configured) or at least one SDU / PDU in a PDU set is discarded (e.g., when PDU set discard (pdu-SetDiscard) is configured) and at least one discarded SDU / PDU or at least one SDU / PDU in a PDU set (if submitted to an associated RLC entity) is not sent by at least one associated RLC entity (or not submitted to lower layers, such as MAC entity (106) and PHY entity (107)), a PDCP SN gap is determined and a discard signaling is triggered by the sending PDCP entity. The transmission considerations of at least one associated RLC entity may be for complete SDUs and / or segments of SDUs.

[0151] In an embodiment, when a drop instruction is received at an RLC entity and at least one segment of an SDU (PDCP PDU) or SDU (PDCPPDU) has been sent (or submitted to a lower layer), at least one of the associated RLC entities communicates this to the sending PDCP entity. Therefore, when at least one associated RLC entity communicates to the sending PDCP entity that an SDU or at least one segment of an SDU has been sent, the PDCP entity determines not to trigger drop signaling. When no associated RLC entity communicates to the sending PDCP entity that an SDU or at least one segment of an SDU has been sent, the PDCP entity determines to trigger drop signaling.

[0152] In this embodiment, after the associated discardTimer and / or discardTimerLowImportance has expired, the SDUs of the PDU set subsequently received from the upper layer are not assigned a count (or SN), and these SDUs of the PDU set are discarded and not included in the discard information carried in the discard signaling. The discard information carried in the discard signaling includes SDUs in the PDU set other than those of the subsequently received PDU set.

[0153] In this embodiment, when a received SDU is discarded at the PDCP layer without being assigned a count or SN, the discard information carried in the discard signaling does not include the SDU.

[0154] In this embodiment, when a received SDU is assigned a count or SN at the PDCP layer and the SDU is discarded before it has been submitted to the RLC layer, the PDCP can reassign the same count or SN to a new or subsequent SDU. In this case, the discarded SDU is not counted in the discard information carried in the discard signaling.

[0155] In this embodiment, when an SDU received from an upper layer is assigned a COUNT or SN at the PDCP layer and the SDU is discarded, and if the SDU is submitted to the RLC layer and if the RLC neither submits the SDU nor its fragments to the lower layers (e.g., MAC entity (106) and PHY entity (107)), the PDCP can reassign the same COUNT or SN to a new or subsequent SDU. In this case, the discarded SDU is not counted in the discard information carried in the discard signaling.

[0156] In an embodiment, when a PDCP entity is associated with one or more RLC entities, the PDCP control PDU, including the discard signaling, is submitted only to the primary RLC entity.

[0157] In an embodiment, when a PDCP entity is associated with one or more RLC entities, a PDCP control PDU, including dropped signaling, is submitted to only one associated RLC entity. The associated RLC entity can be one of a primary RLC entity and a split secondary RLC entity (e.g., in a dual-connection scenario).

[0158] In an embodiment, when a PDCP entity is associated with one or more RLC entities, a PDCP control PDU, including dropped signaling, is submitted to more than one associated RLC entity. The associated RLC entity can be one of a primary RLC entity and a split secondary RLC entity (e.g., in a dual-connection scenario).

[0159] In an embodiment, when a PDCP entity is associated with one or more RLC entities, the PDCP control PDU, including drop signaling, is submitted only to the primary RLC entity or a split auxiliary RLC entity. The RLC entity is determined based on at least one of the following: whether the associated MAC entity is not experiencing congestion (i.e., SDU drop based on PDU set importance (PSI) is disabled), or the associated MAC entity is not in an inactive period of Cell-DRX, or the MAC entity is not in an inactive period of UE DRX, or the associated MAC entity has available uplink grant, or the associated link is not experiencing relatively weak channel conditions.

[0160] In this embodiment, the UE indicates to the network its ability to support PDCP discard signaling in the UE Capability Message and / or through the indication in the UE Assist Information (UAI) Message.

[0161] In an embodiment, the UE receives configuration for PDCP discard signaling from the network in an RRC signaling message (e.g., an RRC reconfiguration message). This configuration may include at least one parameter, which may include at least one of setting, releasing, modifying, enabling, disabling, or disabling timers, triggers, and trigger conditions for discard signaling. For example, the configuration parameter may include the parameter discardInformationRequired to configure or instruct the sending PDCP entity to provide discard signaling to the receiving PDCP entity. This configuration may be configured for each radio bearer and may be included in the pdcp-Config for radio bearer configuration in RRC reconfiguration. When discard signaling functionality is configured by an upper layer in the configuration or reconfiguration (which is not used for releasing or disabling configuration), the PDCP entity (104) applies the discard signaling trigger and initiates discard signaling when at least one trigger condition is met.

[0162] In an embodiment, the triggering condition, which includes the number of gaps in the sequence number, can be explicitly considered by configuring such a number (e.g., in RRC configuration or reconfiguration) or implicitly considered by processing the sending entity implementation.

[0163] In an embodiment, when a data radio bearer is configured by the upper layer to send PDCP discard information (e.g., discardInformationRequired is configured for the data radio bearer), the PDCP sending entity may trigger PDCP discard signaling to send the discard information when at least one of the following conditions is met:

[0164] a) The upper layer requests the reconstruction of the PDCP entity;

[0165] b) The upper layer requests PDCP data recovery;

[0166] c) The upper layer requests uplink data exchange; and

[0167] d) The upper layer reconfigures the PDCP entity to release DAPS and configures daps-SourceRelease.

[0168] In this embodiment, an example specification for the sending operation of discarding signaling is provided as follows:

[0169] Example 1:

[0170] For a DRB configured by the upper layer to send PDCP discard information (with discardInformationRequired configured), the sending PDCP entity should determine the PDCP SN gap and trigger PDCP discard signaling to send the discard information under the following conditions:

[0171] Discard SDUs with assigned count values ​​(including SDUs belonging to the PDU set); and

[0172] The SDU has not yet been submitted to the RLC, or if it has been submitted to the RLC, neither the SDU nor any fragment thereof has been submitted to the lower levels by the RLC.

[0173] In this embodiment, an example specification for the sending operation of discarding signaling is provided as follows:

[0174] Example 2:

[0175] If a PDCP drop signaling is triggered, the sending PDCP entity should:

[0176] The compilation of PDCP discard information is as follows:

[0177] ● Set the First Discard Count (FDC) field to the count of the first PDCP SDU that was discarded;

[0178] ●If FDC <TX_NEXT:

[0179] - Allocate a bitmap field whose length (in bits) is equal to the count of the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last discarded PDCP SDU (including the last discarded PDCPSDU), rounded up to the next multiple of 8, or up to the generated PDCP control PDU size equal to 9000 bytes of PDCP SDU (including PDCP SDU) (whichever comes first).

[0180] - For all PDCP SDUs that have not yet been discarded, set the bitmap field to "0";

[0181] - For all PDCP SDUs that have been discarded, set the bitmap field to "1";

[0182] - Submit the "PDCP drop information" (i.e., the PDCP control PDU including the drop information) to the lower layer as the first PDCP PDU for transmission via the sending PDCP entity, as specified in Clause 5.2.1 (in TS 38.323) for the Uu interface and Clause 5.2.3 (TS 38.323) for the PC5 interface.

[0183] In this embodiment, an example specification for the sending operation of discarding signaling is provided as follows:

[0184] Example 3:

[0185] If a PDCP drop signaling is triggered, the sending PDCP entity should:

[0186] The compilation of PDCP discard information is as follows:

[0187] ○ For each set of consecutively discarded PDCP SDUs

[0188] ● Set the First Discard Count (FDC) field to the count of the first PDCP SDU that was discarded;

[0189] ●If FDC <TX_NEXT:

[0190] - Set the range field to the number of counts from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last consecutively discarded PDCP SDU (including the last consecutively discarded PDCP SDU), rounded up to the generated PDCP control PDU size not exceeding 9000 bytes (including the PDCP SDU).

[0191] - Submit the "PDCP drop information" (i.e., the PDCP control PDU including the drop information) to the lower layer as the first PDCP PDU for transmission via the sending PDCP entity, as specified in Clause 5.2.1 (in TS 38.323) for the Uu interface and Clause 5.2.3 (in TS 38.323) for the PC5 interface.

[0192] In an embodiment, the sending PDCP entity may not partially or completely repeat previously sent discard information in subsequent discard messages. That is, discard information for a specific SDU can only be sent once. An example is when discard information is combined based on discardTimer and / or discardTimerLowImportance expiration, and the corresponding discarded SDU information is compiled and sent only in the PDCP control PDU.

[0193] In embodiments, the sending PDCP entity may partially or completely repeat previously sent discard information in subsequently sent discard information. That is, discard information for a particular SDU may be sent more than once. One example is when discard information is combined to include consecutive SDU discards or no-discard states. First, consider when an SDU with discardTimerLowImportance (with a higher count value) expires, discard information is compiled and sent in the PDCP control PDU; second, when an SDU with discardTimer (with a lower count value) expires, later discard information is compiled and sent in the PDCP control PDU. In this case, the second PDCP control PDU may include discard information for both the SDU with the lower count value and the SDU with the higher count value. Another example is when an SDU that was previously addressed as not discarded in discard information in discard signaling is now discarded and is again addressed as discarded in discard information in new discard signaling.

[0194] In an embodiment, the sending PDCP entity performs drop information signaling in at least one of a congested scenario (e.g., when PSI-based SDU dropping is activated) and a non-congested scenario (e.g., when PSI-based SDU dropping is deactivated). This can be configured in the RRC signaling, specified in the specification, or left to the implementation of the drop information management method.

[0195] In an embodiment, the sending PDCP entity performs discard information signaling for at least one of discardTimer-based SDU discarding and discardTimerLowImportance-based SDU discarding. This can be configured in RRC signaling, specified in the specification, or left to the implementation of the discard information management method.

[0196] In an embodiment, a prohibition timer for discarding signaling is configured or specified (e.g., called t-discardInfoProhibit), which determines that the sending PDCP entity will not frequently send discarding signaling. A prohibition timer for discarding signaling is configured for each radio bearer, and when configured, the prohibition timer starts when discarding signaling is sent. While the prohibition timer is running, sending triggering discarding signaling is not allowed. When the prohibition timer expires or when the prohibition timer is not running, sending triggering discarding signaling is allowed.

[0197] In this embodiment, discarded signaling (e.g., PDCP control PDUs including discarded information, i.e., PDCP SN gap reports) is considered a delay-critical PDCP data volume when pursuing Delayed Status Reports (DSR).

[0198] In this embodiment, because a DSR is triggered when the discardTimer (and / or discardTimerLowImportance) expires within a configured threshold time, discard signaling (e.g., a PDCP control PDU including discard information) is not yet available. It is possible that the sending entity may have uplink resources to send discard signaling. To address this, a Buffer Status Report (BSR) and / or a Schedule Request (SR) (e.g., an SR for discard signaling) is triggered when discard signaling (e.g., a PDCP control PDU including discard information) is sent. In this embodiment, the SR for discard signaling may have a dedicated SR configuration, or it may share the SR configuration used for the BSR.

[0199] In an embodiment, the receiving PDCP entity receives discontinuously dropped PDCP SDU SNs in the dropping signaling (e.g., different sets of the first dropped SDU sequence number and the range of consecutive PDCP SDUs (i.e., sequentially ordered PDCP SDUs) dropped in the PDCP control PDU, or a bitmap of the first dropped SDU sequence number and dropping information in the PDCP control PDU).

[0200] Figure 8 This is a flowchart (800) illustrating a method by which a receiving PDCP entity of a second electronic device processes a PDCP control PDU, including discard information.

[0201] In step 801, the method includes: a receiving PDCP entity of a second electronic device receiving a PDCP control PDU from a first electronic device, the PDCP control PDU containing discard information of one or more discarded SDUs, each discarded SDU being associated with a count value.

[0202] In step 802, the method includes determining whether the count value of one or more discarded SDUs in the discard information is outside the reordering window.

[0203] In step 803, the method includes: if the count values ​​of one or more discarded SDUs are outside the reordering window, the receiving PDCP entity ignores the discard information of those discarded SDUs.

[0204] At step 804, the method includes: if the count values ​​of one or more discarded SDUs are within a reordering window, then receiving the discard information of those SDUs from the PDCP entity.

[0205] In an embodiment, if at least one count value of a discarded SDU in the discard information is outside the reordering window, the receiving PDCP entity ignores the entire discard information included in the PDCP control PDU.

[0206] In an embodiment, if at least one count value of a discarded SDU in the discard information is outside the reordering window, the receiving PDCP entity simply ignores the discard information in the PDCP control PDU for the corresponding discarded SDU, and processes the discard information in the PDCP control PDU for other discarded SDUs within the reordering window.

[0207] Figure 9 This is a flowchart (900) illustrating a method for transmitting a PDCP SDU to the upper layer based on an indication of a dropped SDU in packet drop signaling.

[0208] In step 901, the method includes: when the count value is greater than the current RX_DELIV value, the receiving PDCP entity of the second electronic device updates the RX_DELIV value to the count value of a first PDCP SDU that has not yet been transmitted to the upper layer and is not considered discarded. In step 902, the method includes considering that the count values ​​of PDCP SDUs indicated as discarded in the PDCP SN gap report will be assumed to have been received. In step 903, the method includes passing all stored PDCP SDUs with consecutively associated count values ​​to the upper layer in ascending order of count values.

[0209] In an embodiment, the receiving PDCP entity updates the state variable RX_DELIV to the COUNT of the first SDU that has not yet been transmitted to the upper layer, such that COUNT >= RX_DELIV, and the first SDU is not included in the PDCP control PDU or is not indicated as discarded in the PDCP control PDU.

[0210] In an embodiment, the receiving PDCP entity updates the state variable RX_NEXT to the COUNT of the first SDU that has not yet been received, such that COUNT >= RX_NEXT, and the first SDU is not included in the PDCP control PDU or is not indicated as discarded in the PDCP control PDU.

[0211] In an embodiment, the receiving PDCP entity records or marks (or performs bookkeeping) the COUNT (count) of PDCP SDUs indicated as discarded in the PDCP control PDU, such that COUNT > (updated) RX_DELIV and / or COUNT > (updated) RX_NEXT. Furthermore, the receiving entity skips expecting to receive these PDCP SDUs from the sending entity, or assumes as if these SDUs were received. Therefore, the receiving PDCP entity updates state variables, such as the COUNT of each PDCPSDU recorded or marked (or bookkeeping) as described above. When RX_DELIV becomes equal to COUNT (i.e., RX_DELIV = COUNT), RX_DELIV is updated to COUNT+1, and when RX_NEXT becomes equal to COUNT (i.e., RX_NEXT = COUNT), RX_NEXT is updated to COUNT+1.

[0212] In the example, the PDCP control PDU can have one or more sets of discard information, where each set can be a range / bitmap of consecutively discarded SDU SNs (e.g., SNs 5, 6, and 7 discarded due to the expiration of a discard timer, and SNs 11 and 12 discarded due to the expiration of a low-importance discard timer). When these sets of discard information are not consecutive (i.e., SNs 5, 6, 7, 11, and 12), the receiving PDCP entity can benefit from the discard signaling. That is, the receiving PDCP entity performs bookkeeping to record or mark non-consecutive discarded SDU SNs (e.g., SNs 11 and 12). This can be achieved simply through PDCP state variable updates.

[0213] In an embodiment, when a PDCP SDU with a COUNT has been received by the receiving PDCP entity and indicated as to be discarded in the PDCP control PDU, the receiving PDCP entity may process (e.g., perform integrity verification, decryption, header compression) the PDCP SDU and / or deliver it to the upper layer.

[0214] In an embodiment, when a PDCP SDU with a COUNT has been received by the receiving PDCP entity and indicated as to be discarded in the PDCP control PDU, the receiving PDCP entity may not process (e.g., perform integrity verification, decryption, header compression) the PDCP SDU and / or may not deliver it to the upper layer.

[0215] Figure 10 This is a flowchart (1000) illustrating the PDCP SN gap controller mechanism for transmitting packet drop signaling and receiving and processing packet drop signaling in a communication system for XR.

[0216] In step 1001, the method includes the SN gap controller (103) of the first electronic device (100) evaluating whether the triggering criteria (based on the discarded PDCP SDU or count value or submitted from the RLC to the lower layer) are met at the point of transmission of the PDCP entity.

[0217] In step 1002, the method includes: if the triggering criteria are met, the first electronic device triggers packet drop signaling and sends drop information (PDCP SN gap report) to the receiving PDCP entity of the second device.

[0218] In step 1003, the method includes: if the criteria are not met, the first device (100) does not trigger packet drop signaling.

[0219] In step 1004, the method includes a second electronic device (200) checking whether the count value of one or more discarded SDUs is outside the reordering window.

[0220] In step 1005, the method includes: if the count value is outside the reordering window, the first device receiving the PDCP ignores the discard information of those SDUs.

[0221] In step 1006, the method includes: if the count value is within the reordering window, the first device processes the discard information of the relevant SDU.

[0222] In an embodiment, an example of the process for managing received PDCP discard information at the receiving PDCP entity of the XR radio bearer is described below:

[0223] Example 4:

[0224] For DRB, when a PDCP control PDU including PDCP discard information is received, the receiving PDCP entity should:

[0225] - If at least one count of the SDUs dropped in the dropout information is outside the reordering window:

[0226] - Ignore the discard information of the SDU used for corresponding discarding in the PDCP control PDU;

[0227] - If RX_NEXT <= the count (COUNT) of the last SDU dropped in the discard message:

[0228] - Update RX_NEXT to the COUNT of the first SDU that has not yet been received, such that COUNT >= RX_NEXT, and that the first SDU is not included in the PDCP control PDU or has not been indicated as discarded in the PDCP control PDU.

[0229] - If RX_DELIV <= the count (COUNT) of the last SDU dropped in the discard message:

[0230] - Update RX_DELIV to the COUNT of the first SDU that has not yet been transmitted to the upper layer, such that COUNT >= RX_DELIV, and that the first SDU is not included in the PDCP control PDU or is not indicated as discarded in the PDCP control PDU.

[0231] - If the (updated) RX_DELIV <= the count (COUNT) of the last discarded SDU in the discard information:

[0232] - Record the COUNT of PDCP SDUs that are indicated as discarded in the PDCP control PDU, such that COUNT > (updated) RX_DELIV (the receiving PDCP entity does not expect to receive these PDCP SDUs).

[0233] - After performing header decompression, all stored PDCP SDUs with consecutively associated count (COUNT) values ​​are sent to the upper layer in ascending order of associated count values ​​(if any), such that COUNT < (updated) RX_DELIV, while excluding (i.e. ignoring consecutively associated COUNT considerations) the count values ​​of records of PDCP SDUs that are indicated as discarded in the PDCP control PDU.

[0234] - If t-Reordering is running, and if RX_DELIV >= RX_REORD:

[0235] -Stop and reset t-Reordering.

[0236] - If t-Reordering is not running (including cases where t-Reordering stops due to the actions described above), and RX_DELIV <RX_NEXT:

[0237] - Update RX_REORD to RX_NEXT;

[0238] -Start t-Reordering.

[0239] 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 according to preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments described herein.

Claims

1. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Receives Radio Resource Control (RRC) messages from the base station for configuring the transmission of Packet Data Convergence Protocol (PDCP) Sequence Number (SN) Gap Report; Indicate whether the Packet Data Convergence Protocol (PDCP) Sequence Number (SN) gap report has been triggered; as well as When the PDCP SN gap report is triggered, the PDCP SN gap report is sent to the base station. The PDCP SN gap report includes at least one of a first drop count (FDC) field and a drop bitmap field.

2. The method according to claim 1, wherein, The PDCP SN gap report is triggered under the following circumstances: In the event that at least one PDCP service data unit (SDU) is discarded, or In the case where at least one stored PDCP SDU is associated with a count value greater than the count value associated with the discarded PDCP SDU, or In the event that at least one discarded PDCP SDU has not yet been submitted to the lower layer by the Radio Link Control (RLC).

3. The method according to claim 1, further comprising: The first drop count FDC field is set in the PDCP SN gap report. The FDC field indicates the minimum count value among the count values ​​associated with at least one discarded PDCP SDU.

4. The method according to claim 1, further comprising: Assign a discard bitmap field whose length in bits is equal to the number of count values ​​from the first discarded PDCP SDU, excluding the first discarded PDCP SDU, to the last discarded PDCP SDU, including the last discarded PDCP SDU.

5. The method according to claim 1, in, The PDCP SN gap report is sent via the PDCP control protocol data unit (PDU).

6. A method performed by a base station in a wireless communication system, the method comprising: Send a Radio Resource Control (RRC) message to the User Equipment (UE) for configuring the transmission of Packet Data Convergence Protocol (PDCP) Sequence Number (SN) Gap Report; as well as Receive PDCP SN gap report from the UE. The PDCP SN gap report includes at least one of a first drop count (FDC) field and a drop bitmap field.

7. The method according to claim 6, in, The FDC field indicates the minimum count value among the count values ​​associated with at least one discarded PDCP SDU, and The allocated discard bitmap field has a length in bits equal to the number of count values ​​from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last discarded PDCP SDU (including the last discarded PDCP SDU).

8. The method according to claim 6, in, The PDCP SN gap report is received via the PDCP control protocol data unit (PDU).

9. A user equipment (UE) in a wireless communication system, the UE comprising: transceiver; and A controller, coupled to the transceiver, is configured to: Receives Radio Resource Control (RRC) messages from the base station for configuring the transmission of Packet Data Convergence Protocol (PDCP) Sequence Number (SN) Gap Report. Indicates whether the Packet Data Convergence Protocol (PDCP) sequence number (SN) gap report is triggered, and When the PDCP SN gap report is triggered, the PDCP SN gap report is sent to the base station. The PDCP SN gap report includes at least one of a first drop count (FDC) field and a drop bitmap field.

10. The UE according to claim 9, wherein, The PDCP SN gap report is triggered under the following circumstances: In the event that at least one PDCP service data unit (SDU) is discarded, or In the case where at least one stored PDCP SDU is associated with a count value greater than the count value associated with the discarded PDCP SDU, or In the event that at least one discarded PDCP SDU has not yet been submitted to the lower layer by the Radio Link Control (RLC).

11. The UE according to claim 9, wherein, The controller is also configured to: Configure the first drop count FDC field in the PDCP SN gap report. The FDC field indicates the minimum count value among the count values ​​associated with at least one discarded PDCP SDU.

12. The UE according to claim 9, wherein, The controller is also configured to: Assign a discard bitmap field whose length in bits is equal to the number of count values ​​from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last discarded PDCP SDU (including the last discarded PDCP SDU).

13. The UE according to claim 9, in, The PDCP SN gap report is sent via the PDCP control protocol data unit (PDU).

14. A base station in a wireless communication system, the base station comprising: transceiver; and A controller, coupled to the transceiver, is configured to: Sends a Radio Resource Control (RRC) message to the User Equipment (UE) to configure the transmission of Packet Data Convergence Protocol (PDCP) Sequence Number (SN) Gap Report, and Receive PDCP SN gap report from the UE. The PDCP SN gap report includes at least one of a first drop count (FDC) field and a drop bitmap field.

15. The base station according to claim 14, in, The FDC field indicates the minimum count value among the count values ​​associated with at least one discarded PDCP SDU. The allocated discard bitmap field has a length in bits equal to the number of count values ​​from the first discarded PDCP SDU (excluding the first discarded PDCP SDU) to the last discarded PDCP SDU (including the last discarded PDCP SDU), and... The PDCP SN gap report is received via the PDCP control protocol data unit (PDU).

Images