CN117062141A

CN117062141A - Method and user equipment for initiating PDCP (packet data Condition protocol) status report process

Info

Publication number: CN117062141A
Application number: CN202311083718.7A
Authority: CN
Inventors: 张园园; 王学龙
Original assignee: MediaTek Singapore Pte Ltd
Current assignee: MediaTek Singapore Pte Ltd
Priority date: 2020-12-30
Filing date: 2021-12-20
Publication date: 2023-11-14
Also published as: TW202226860A; US20220209903A1

Abstract

The invention provides a method for initiating a PDCP state report process, user equipment and a storage medium. Wherein the method comprises the following steps: the user equipment receives PDCP PDU from the lower layer through the PDCP entity; storing PDCP SDUs corresponding to the received PDCP PDUs in a PDCP receive buffer; triggering a status reporting process initiated by the user equipment when an initial sequence number gap is detected based on one or more stored PDCP SDUs, wherein the status reporting process initiated by the user equipment performs sequence number gap monitoring to compile a PDCP status report; and upon detection of one or more predefined trigger events, transmitting a PDCP status report to the wireless network, wherein the PDCP status report includes the generated updated SN gap information. By utilizing the invention, PDCP status report initiated by UE can be supported.

Description

Method and user equipment for initiating PDCP (packet data Condition protocol) status report process

The present invention is a divisional application of patent application with application number of "202111561936.8" and title of "pattern drawing apparatus and pattern drawing method" of 2021, 12/20/day.

Technical Field

The present invention relates to wireless communications, and more particularly to packet data convergence protocol (packet data convergence protocol, PDCP) status reporting procedures.

Background

With the exponential growth of wireless data services, content delivery to large groups of mobile users has grown rapidly. Initial wireless multicast/broadcast services included streaming media services such as mobile television and IPTV. With the increasing demand for large groups of content delivery, the latest application development of mobile multicast services requires highly robust and critical communication services, such as group communication in case of disasters, and the necessity of public safety network related multicast services. Early 3GPP defined enhanced multimedia broadcast multicast service (enhanced multimedia broadcast multicast service, eMBMS) in the LTE standard, single-cell point-to-multipoint (SC-PTM) service and multicast broadcast single-frequency network (MBSFN) service. The 5G multicast broadcast service (multicast and broadcast service, MBS) is defined based on a unicast 5G core (5G core,5 gc) architecture. Various applications may rely on multicast transmitted communications such as live streaming, video distribution, vehicle-to-everything (V2X) communications, public Safety (PS) communications, file downloads, etc. In some cases, the cellular system may need to enable reliable multicast transmission to ensure reception quality at the UE side. Reliable transmission of some multicast traffic in NR systems requires feedback on the reception of the multicast transmission, which helps the network to make necessary retransmission of the content to the UE. A specific Radio Bearer (RB) should be introduced to provide a multicast service to the UE.

Improvements and enhancements are needed to support PDCP status reporting procedures.

Disclosure of Invention

An embodiment of the present invention provides a method for initiating a PDCP status report procedure, including: the user equipment receives PDCP PDU from the lower layer through the PDCP entity; storing PDCP SDUs corresponding to the received PDCP PDUs in a PDCP receive buffer; triggering a status reporting process initiated by the user equipment when an initial sequence number gap is detected based on one or more stored PDCP SDUs, wherein the status reporting process initiated by the user equipment performs sequence number gap monitoring to compile a PDCP status report; and upon detection of one or more predefined trigger events, transmitting a PDCP status report to the wireless network, wherein the PDCP status report includes the generated updated SN gap information.

Another embodiment of the present invention provides a user equipment, including: a transceiver for transmitting and receiving radio frequency signals in a wireless network; a PDCP entity for receiving PDCP PDUs from a lower layer; a PDCP control module for storing PDCP SDUs corresponding to the received PDCP PDUs in a PDCP receive buffer; a PDCP status report control module configured to trigger a user equipment initiated status report procedure when an initial sequence number gap is detected based on one or more stored PDCP SDUs, wherein the user equipment initiated status report procedure performs sequence number gap monitoring to compile a PDCP status report; and a PDCP status report transmitter for transmitting a PDCP status report to the wireless network after detecting one or more predefined trigger events, wherein the PDCP status report includes the generated updated SN gap information.

Another embodiment of the present invention provides a storage medium storing a program that, when executed, causes a user equipment to perform the steps of the method for initiating PDCP status reporting procedure set forth in the present invention.

By utilizing the invention, PDCP status report initiated by UE can be supported.

Drawings

Various embodiments of the present invention, as set forth by way of example, will be described in detail with reference to the following drawings, in which like reference numerals refer to like elements, and in which:

fig. 1 is a schematic system diagram of a wireless communication network supporting a PDCP status reporting procedure according to an embodiment of the present invention.

Fig. 2 is a schematic diagram of an exemplary NR wireless system with a centralized upper layer of NR radio interface stacks according to an embodiment of the present invention.

Fig. 3 is an exemplary diagram of a top-level PDCP status report flow diagram for supporting reliable MBS and MRB configuration according to an embodiment of the present invention.

Fig. 4 is a diagram of an exemplary protocol stack for MRB configuration with PDCP-based retransmissions, according to an embodiment of the present invention.

Fig. 5 is an exemplary diagram of conditions and procedures for UE-initiated PDCP status reporting according to an embodiment of the present invention.

Fig. 6 is an exemplary diagram of conditions for PDCP status reporting according to an embodiment of the present invention.

Fig. 7 is an exemplary diagram of a process of updating state variables and triggering PDCP status reports under control of a t-Reordering timer according to an embodiment of the invention.

Fig. 8 is an exemplary flow chart of a UE initiated PDCP status reporting procedure in accordance with an embodiment of the present invention.

Detailed Description

Reference will now be made in detail to some embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

The present invention provides methods, apparatus, processing systems, and computer readable media for a New Radio (NR) access technology or a 5G technology or other radio access technology. NR, etc. may support various wireless communication services such as enhanced mobile broadband for wide bandwidth, millimeter waves for high carrier frequencies, massive MTC for non-backward compatible machine type communication (machine type communication, MTC) technology, and/or critical tasks for ultra-reliable low-latency communications. These services may have delay and reliability requirements. These services may also have different transmission time intervals (transmission time interval, TTI) to meet respective quality of service (quality of service, qoS) requirements. Furthermore, these services may coexist in the same subframe.

Fig. 1 is a schematic system diagram of a wireless communication network supporting a PDCP status reporting procedure according to an embodiment of the present invention. The wireless communication network 100 includes one or more fixed infrastructure elements that form a network that is distributed over a geographic area. The infrastructure element may also be referred to as an access point, an access terminal, a base station, a node B, an evolved node B (eNode-B), a next generation node B (gNB), or other terminology used in the art. A base station may serve multiple mobile stations within a service area (e.g., a cell or a sector of a cell), e.g., a cell, or a cell sector. In some systems, one or more base stations are coupled to a controller to form an access network coupled to one or more core networks. The gnbs 106, 107, and 108 are base stations in a wireless network, and their service areas may or may not overlap with each other. In an embodiment, a User Equipment (UE) or mobile station 101 is located in a service area covered by the gnbs 106 and 107. As an example, the UE or mobile station 101 is located only in the service area of the gNB 106 and is connected with the gNB 106. The UE or mobile station 102 is located only in the service area of the gNB 107 and is connected to the gNB 107. gNB 106 is connected to gNB 107 through Xn interface 121. gNB 106 is connected to gNB 108 through Xn interface 122. 5G network entity 109 is connected to gnbs 106, 107, and 108 through NG connections 131, 132, and 133, respectively. In an embodiment, gNB 106 and gNB 107 provide the same MBMS service. When the UE 101 moves from the gNB 106 to the gNB 107, service continuity during handover is guaranteed and vice versa. The area covered by the gnbs 106 and 107 with the same MBMS service is a multicast service area for the MBMS service.

Fig. 1 further shows a simplified block schematic diagram of a base station and a mobile device/UE for multicast transmission. The gNB 106 has an antenna 156 that transmits and receives radio signals. RF transceiver circuitry 153 coupled to the antenna receives RF signals from antenna 156, converts the RF signals to baseband signals, and sends the baseband signals to processor 152. The RF transceiver 153 also converts baseband signals received from the processor 152 into RF signals and sends to the antenna 156. The processor 152 processes the received baseband signals and invokes different functional modules to perform the functional features in the gNB 106. Memory 151 stores program instructions and data 154 to control the operation of the gNB 106. The gNB 106 also includes a set of control modules 155 for performing functional tasks to communicate with the mobile station. These control modules may be implemented in circuitry, software, firmware, or a combination of the above.

Fig. 1 also includes a simplified block diagram of a UE, such as UE 101. The UE has an antenna 165 to send and receive radio signals. An RF transceiver circuit 163 coupled to the antenna receives RF signals from the antenna 165, converts the RF signals to baseband signals, and sends the baseband signals to the processor 162. In one embodiment, the RF transceiver 163 may include two RF modules (not shown) for transmission and reception of different frequency bands. The RF transceiver 163 also converts the baseband signal received from the processor 162 into an RF signal and transmits to the antenna 165. The processor 162 processes the received baseband signals and invokes different functional modules to perform the functional features in the UE 101. The memory 161 stores program instructions and data 164 to control the operation of the UE 101. The antenna 165 sends uplink transmissions to the antenna 156 of the gNB 106 and receives downlink transmissions from the antenna 156 of the gNB 106.

The UE 101 also includes a set of control modules for performing functional tasks. These control modules may be implemented in circuitry, software, firmware, or a combination of the above. In an embodiment, the UE also has a radio resource control (radio resource control, RRC) state controller 197, an MBS controller 198, and a protocol stack controller 199. The RRC state controller 197 controls the UE RRC state according to a command from the network and the UE status. The RRC supports the following states: RRC IDLE (rrc_idle), RRC CONNECTED (rrc_connected), and RRC INACTIVE (rrc_inactive). In an embodiment, the UE may receive multicast and broadcast services in RRC idle/inactive state. The UE starts a session receiving the service of interest to it using a multicast radio bearer (multicast radio bearer, MRB) setup procedure. The UE stops receiving the session by applying the MRB release procedure. MBS controller 198 controls the establishment/addition, reconfiguration/modification and release/removal of MRBs based on different sets of conditions for MRB establishment, reconfiguration and release. Protocol stack controller 199 is used to add, modify, or remove protocol stacks for MRBs.

The protocol stack includes a packet data convergence protocol (packet data convergence protocol, PDCP) layer 182, a radio link control (radio link control, RLC) layer 183, a medium access control (media access control, MAC) layer 184, and a Physical (PHY) layer (not shown). The PDCP layer (PDCP entity) 182 receives a PDCP Packet Data Unit (PDU) from a lower layer. In an embodiment, the PDCP layer supports a reordering (reordering) function 1821 for data transmission, maintenance of PDCP SNs, header compression and decompression using a robust header compression (robust header compression, ROHC) protocol, ciphering and deciphering, integrity protection and integrity verification, timer-based SDU discard, routing to separate bearers, repetition, reordering and in-order delivery, out-of-order delivery and repetition discard. In an embodiment, the receiving PDCP entity supporting the PDCP status reporting function 1822 sends a PDCP status report upon expiration of a Reordering timer (t-Reordering). In an embodiment, the PDCP status report triggers a PDCP retransmission of the network side peer transport PDCP entity. The PDCP control module 192 stores PDCP service data units (service data unit, SDUs) of received PDCP PDUs in a PDCP receive buffer, wherein the most recently received PDCP SDU has a Sequence Number (SN) and a superframe number (hyper frame number, HFN). The COUNT value rcvd_count= [ rcvd_hfn, rcvd_sn ] of the last received PDCP SDU. The PDCP status report control module 193 triggers a UE-initiated status report procedure upon detecting an initial SN gap based on one or more stored SDUs, wherein the UE-initiated status report procedure performs SN gap monitoring to compile a PDCP status report. The PDCP status report transmitter 194, upon detecting one or more predefined trigger events, transmits a PDCP status report to the wireless network, wherein the PDCP status report includes information of the generated updated SN gaps.

In one embodiment, the service data adaptation protocol (service data adaption protocol, SDAP) layer 181 is an optional configuration. In an embodiment, the RLC layer 183 supports functions of error correction, segmentation and reassembly, re-segmentation, repetition detection, re-establishment, etc. by automatic repeat request (automatic repeat request, ARQ). In an embodiment, a new procedure for RLC reconfiguration is performed, which may reconfigure an RLC entity to be associated to one or two logical channels. In another embodiment, the MAC layer 184 supports mapping, multiplexing, demultiplexing, hybrid automatic repeat request (hybrid automatic repeat request, HARQ), radio resource selection, etc. between logical channels and transport channels.

Fig. 2 is a schematic diagram of an exemplary NR wireless system with a centralized upper layer of NR radio interface stacks according to an embodiment of the present invention. Different protocol split options are possible between the upper layer (upper layer) of the Central Unit (CU)/gNB node and the lower layer (lower layer) of the Distributed Unit (DU)/gNB node. The functional division between the central unit and the gNB lower layers may depend on the transport layer. The low performance transmission between the central unit and the gNB lower layers may enable the higher protocol layers of the NR radio stack to be supported in the central unit, since the higher protocol layers have lower performance requirements on the transmission layers in terms of bandwidth, delay, synchronization and jitter. In one embodiment, the SDAP and PDCP layers are located at a central unit, while the RLC, MAC and physical layers are located at a distributed unit. The core unit (core unit) 201 is connected to a central unit 211 with a gNB upper layer 252. In an embodiment 250, the gNB upper layer 252 includes a PDCP layer and an optional SDAP layer. The central unit 211 is connected to distributed units 221, 222, and 223, wherein the distributed units 221, 222, and 223 correspond to cells 231, 232, and 233, respectively. Distributed units 221, 222, and 223 include a gNB underlayer 251. In an embodiment, the gNB lower layer 251 includes PHY, MAC, and RLC layers. In another embodiment 260, each gNB has a protocol stack 261 including SDAP, PDCP, RLC, MAC and a PHY layer.

Fig. 3 is an exemplary diagram of a top-level PDCP status report flow chart 300 for supporting reliable MBS and MRB configuration according to an embodiment of the present invention. In an embodiment, the UE monitors the SN of the PDCP SDU and triggers a UE-initiated PDCP status report. In step 301, the ue receives PDCP PDUs from the lower layer. In step 302, the ue stores PDCP SDUs in a receive buffer. In step 303, the ue checks the SN gap according to the received data packet, updating the state variable. In one embodiment, when an SN gap is detected, a reordering timer is started to monitor whether the SN gap is closed (closed). In step 304, the UE triggers a UE-initiated PDCP status report upon detection of one or more predefined trigger events.

In an embodiment, the UE-initiated PDCP status report is used for MBS. In some systems, such as NR, NR multicast/broadcast is transmitted within the coverage of a cell. In an embodiment, a multicast control channel (multicast control channel, MCCH) provides information of a list of NR multicast/broadcast services having ongoing sessions transmitted on a multicast traffic channel (multicast traffic channel, MTCH). At the physical layer, the MTCH is scheduled by the gNB in the search space of the physical downlink control channel (physical downlink control channel, PDCCH), which is scrambled by the group radio network temporary identity (group radio network temporary identification, G-RNTI). The UE decodes MTCH data of the multicast session in a multicast physical downlink shared channel (physical downlink shared channel, PDSCH). The multicast radio bearer provides multicast services that are carried by only the MTCH with the UE protocol stack, only the dedicated traffic channel (dedicated traffic channel, DTCH) with the UE protocol stack, or both the MTCH and DTCH with the UE protocol stack 301. In an embodiment 310, MRB 311 is configured to be associated with MTCH and DTCH. To support over-the-air multicast transmission of the downlink, one or more multicast MRBs may be established to correspond to the multicast stream for a particular multicast session. MRB may perform point-to-multipoint (PTM) transmission, point-to-point (PTP) transmission, and a combination of PTM and PTP transmission within a cell. Different configurations may be described as different transmission modes/channels/MRB types. In an embodiment 310 with a split (MRB) configuration, the MRB is configured with a PTM 312 leg and a PTP 313 leg.

In existing systems supporting MBMS/eMBMS, the radio bearer structure for multicast and broadcast transmissions is modeled in a manner independent of unicast transmissions. The transmission of the multicast/broadcast session adopts RLC unacknowledged mode (unacknowledged mode, UM) due to unidirectional transmission of the legacy MBMS/eMBMS service. In this case, there is no need to interact between multicast and unicast for a specific UE in RRC connected state. For NR networks, reliable transmission is required for providing new services through MBS. Conventional multicast transmissions do not guarantee that all UEs will receive successfully unless a very conservative link adaptation is performed, which can significantly reduce resource efficiency. In order to support reliable multicast transmission of MBS, each UE receiving service needs a feedback channel in uplink. The receiving UE may use the feedback channel to feed back its reception status with respect to the service to the network, and the network may perform necessary retransmission according to the feedback to improve reliability of transmission. From an uplink feedback perspective, the feedback channel may be used for layer 2 (L2) feedback, such as RLC status reports and/or PDCP status reports. In addition, a feedback channel may be used for HARQ feedback. Furthermore, the feedback should be a bi-directional channel between the UE and the network and it is assumed that the network can use this channel to perform the required retransmission of packets. The packet retransmission is an L2 retransmission (e.g., RLC retransmission and/or PDCP retransmission). Furthermore, the feedback channel may be used for HARQ retransmissions. In one embodiment, the MRB is associated with a multicast channel that receives MBS data packets and a unicast channel that sends feedback (e.g., PDCP status reports) and receives data retransmissions.

Fig. 4 is a diagram of an exemplary protocol stack for MRB configuration with PDCP-based retransmissions, according to an embodiment of the present invention. In PDCP based retransmissions 490, there is one PDCP entity 491 per MRB 496. Two logical channels (i.e., MTCH and DTCH) are associated with the PDCP entity, one RLC entity for each logical channel. RLC entity 492 corresponds to MTCH 4971 and RLC entity 493 corresponds to DTCH 4972. From the UE perspective, the PDCP status report triggering PDCP retransmission is delivered to the RLC entity 493 corresponding to the DTCH. From the network point of view, PDCP protocol data units PDUs for retransmission are delivered over DTCH. The MAC entity 494 maps the logical channels MTCH and DTCH to two transport channels, transport channel-1 4981 such as multicast channel (multicast channel, MCH) and downlink shared channel (downlink shared channel, DL-SCH), transport channel-2 4982 such as MCH and DL-SCH, respectively. The UE monitors two independent transport channels with different radio network temporary identities (radio network temporary identification, RNTI). The ROHC function and the security function are optional for multicast transmission. The RLC layer includes only segmentation and the ARQ function of the RLC layer moves to the PDCP layer. RLC 492 and RLC 493 are mapped to MAC entity 494 and are used to send data packets to PHY 495.

A network entity, such as a base station/gNB, transmits MBS data packets to N UEs over the PTM link and retransmits the MBS data packets over PTP links associated with the PDCP protocol stack based on feedback. The UE correspondingly configured with the PDCP-based protocol stack receives MBS data packets from the base station on the PTM RBs and sends feedback to the base station. The scheduling of multicast is independent of PTP transmissions. The protocol stacks of the base station and the UE include an SDAP layer 401, a PDCP layer 402, an RLC layer 403, and a MAC layer 404. The SDAP layer 401 processes QoS flows 481, including QoS flow processing 411 for UE-1 and QoS flow processing 412 for UE-N at the base station, and QoS flow processing 413 for the UE at the UE. The PDCP layer 402 includes an ROHC function and a security function. The ROHC function and the security function are optional for multicast transmission. The PDCP layer 402 includes the functions of ROHC 421 and security 424 for UE-1 multicast, ROHC 4212 and security 4242 for UE-1 unicast, ROHC 422 and security 425 for UE-N multicast, ROHC 4222 and security 4252 for UE-N unicast, and ROHC 423 and security 426 at the UE. RB 482 is processed in PDCP layer 402. The RLC layer 403 includes segmentation and ARQ functions at the base station including segmentation and ARQ 431 for UE-1 multicast, segmentation and ARQ 432 for UE-1 unicast, segmentation and ARQ 433 for UE-N multicast, segmentation and ARQ 434 for UE-N unicast; and segmentation and ARQ functions at the UE, including segmentation and ARQ 435 for unicast channels and segmentation and ARQ 436 for multicast channels. The RLC channel 483 is processed in the RLC layer 403. The MAC layer 404 includes the functions of scheduling and priority processing 441 at the base station, multiplexing 443 and HARQ 446 for UE-1, multiplexing 444 and HARQ 447 for UE-N at the base station; and functions at the UE for scheduling and prioritization 442 for the UE, multiplexing 445 and HARQ 448 for the UE. The MAC layer 404 processes the logical channels 484 and the transport channels 485.

According to an embodiment, PDCP status reporting is initiated by the UE when a SN gap is detected in the PDCP SDU receive buffer for a period of time. The PDCP status report is not triggered by a network command or a network configuration. The UE initiates a PDCP status reporting procedure based on the UE local conditions. In an embodiment, the time period is controlled by a reordering timer at the UE. The UE monitors SN of the received PDCP SDU. When the SN gap is detected in the receive buffer, the UE performs a UE-initiated PDCP status reporting procedure. The UE-initiated PDCP status report is generated upon detection of one or more predefined conditions. The UE compiles a PDCP status report and sends it to the wireless network. The following illustrations illustrate the conditions and operations under which the UE initiates the PDCP status reporting procedure.

Fig. 5 is an exemplary diagram of conditions and procedures for UE-initiated PDCP status reporting according to an embodiment of the present invention. In an embodiment, the UE initiates a PDCP status report procedure and sends a PDCP status report to the network. In an embodiment, the UE uses a t-reporting timer 502 to determine whether to trigger PDCP status reporting. In another embodiment, the UE also monitors a set of SN parameters 501. In an embodiment, the UE sets the count value rx_deliv to the count value of the first PDCP SDU that has not yet been delivered to the upper layer. The COUNT value rcvd_count= [ rcvd_hfn, rcvd_sn ] of the last received PDCP SDU. As each PDCP PDU is received, the UE takes a series of operations to determine whether to store the PDCP SDU in the receive buffer. The count value rx_next is the count value of the NEXT PDCP SDU expected to be received. The UE updates rx_next to rcvd_count+1. When RX_NEXT is greater than RX_DELIV, an SN gap is detected. The reorder count rx_reorder is set to rx_next when the SN gap is detected and updated when more data packets are received. The UE performs PDCP status reporting according to the count values (including rx_deliv, rx_next, and rx_reord). If the PDCP SDUs are stored in the receive buffer, PDCP reordering and status report triggering are performed. In another embodiment, the reorder count value rx_reorder is set to rx_next when sending PDCP status reports.

For condition 511, the UE determines if the SN gap is closed, e.g., rx_deliv > = rx_reord, and the t-Reordering timer is running. When the t-Reordering timer is still running, the SN gap is not closed, which means that all received out-of-order SDUs have been successfully received. If condition 511 is true, the UE stops and resets the t-Reordering timer in step 512. For condition 521, the UE determines whether a new SN gap occurs, i.e., rx_deliv < rx_next, and the t-Reordering timer is not running. If condition 521 is true, the UE updates RX_REORD to RX_NEXT in step 522 and starts a t-Reordering timer in step 523. For condition 531, the UE determines whether the existing SN gap is not closed and whether the t-Reordering timer expires. If condition 531 is true, it indicates that a UE-initiated PDCP status report needs to be sent. The ue triggers a status report at step 532, updates rx_reord to rx_next at step 533, and starts a t-Reordering timer at step 534. In an embodiment, the UE delivers PDCP SDUs to the upper layer when the t-Reordering timer expires. If there is no decompression before, the UE transmits to the upper layer according to the ascending order of the associated count value after head decompression. Starting from the COUNT value rx_deliv, all stored PDCP SDUs with consecutive associated rcvd_count COUNT values are delivered to an upper layer. The UE updates rx_deliv to a count value of a first PDCP SDU that has not been delivered to an upper layer, wherein the count value > rx_deliv.

Fig. 6 is an exemplary diagram of conditions for PDCP status reporting according to an embodiment of the present invention. In an embodiment, the UE initiates PDCP status reporting based on one or more predefined trigger events. PDCP status reports trigger PDCP-based retransmissions. In step 601, the ue monitors one or more predefined trigger events. The trigger event is one or more predefined/preconfigured events including expiration of a t-reporting timer 611, detection of an SN gap 612, and enabled UE capability 613 of the UE to initiate PDCP status reporting. If the PDCP status report is triggered by one or more predefined trigger events, the UE compiles the PDCP status report in step 621. The PDCP status report is sent to the network to trigger PDCP retransmissions.

Fig. 7 is an exemplary diagram of a process of updating state variables and triggering PDCP status reports under control of a t-Reordering timer according to an embodiment of the invention. In initial state T0 701, no SDU is received, and the PDCP SDU buffer is empty. The initial values of RX_NEXT and RX_DELIV are: rx_next=0 and rx_deliv=0. In the T1 state 702, when an SDU with a count value=0 is received, rx_next and rx_deliv are updated to rx_next=1 and rx_deliv=1. In states 701 and 702, the timer t-Reordering is not triggered, and the RX_REORD is not initialized because no PDCP SDUs are lost. In another embodiment, RX REORD is set to a non-initialized value. In the T2 state 703, SDUs with count value=0, 1, 2 have been received, and then SDUs with count value=17 are received. Since SDUs must be sequentially delivered to an upper layer, the first count value not delivered to an SDU is "3". The UE updates rx_deliv=3, rx_next=18. At T2 703, the UE detects an initial SN gap 736 when rx_deliv < rx_next. Rx_needed is updated to a count value subsequent to the count value associated with the current PDCP SDU, i.e., rx_next=18. The UE detects a trigger event condition that there is a SN gap and no t-Reordering timer is running. At step 737, a t-Reordering timer is started. Between the T2 703 and T3 704 states, a T-Reordering timer is running and SDUs with count values=3, 4, 10, 18, 19 are received. During this time, the UE sequentially delivers PDCP SDUs only in ascending order of the associated count value and updates rx_deliv=5. Rx_reord is updated to rx_next=20. In the T3 state 704, the T-playback timer expires. Since rx_deliv=5 and rx_reord=20, the updated SN gap 746 is not closed, PDCP status reporting is triggered at step 748 according to condition 531 of fig. 5. At step 749, the t-playback timer is restarted. The example in the figure does not show that before the t-Reordering timer expires, if the SN gap is closed, i.e. rx_deliv equals rx_reorder, the t-Reordering timer is stopped.

In an embodiment, the PDCP status report includes information of the generated updated SN gaps. In one embodiment 750, the updated SN gap information includes a first loss count (first missing count, FMC) and a bitmap (bitmap). For example, FMC of T3 state 704 is "5". The bit length allocated by the bitmap is equal to the count from the first missing PDCP SDU to the last out-of-sequence PDCP SDU (excluding the first missing PDCP SDU but including the last out-of-sequence PDCP SDU), rounded up to a multiple of "8", or at most one PDCP SDU with a PDCP control PDU size equal to 9000 bytes. The UE sets all PDCP SDUs that have not been received and, optionally, PDCP SDUs that failed decompression to "0" in the bitmap field. For all received PDCP SDUs, the UE sets to "1" in the bitmap field. For example, when fmc=5, the first bit of the bitmap starts at count value=6. Count = SDU missing for 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, the corresponding bit in the bitmap is set to "0". The SDU of count value = 10, 17, 18, 19 is correctly received, the corresponding bit in the bitmap is set to "1". Padding (padding) may be inserted when the bitmap is required to be rounded to a multiple of "8".

Fig. 8 is an exemplary flow chart of a UE initiated PDCP status reporting procedure in accordance with an embodiment of the present invention. In step 801, the ue receives PDCP PDUs from a lower layer through a PDCP entity. In step 802, the ue stores PDCP SDUs corresponding to the received PDCP PDUs in a PDCP receive buffer. In step 803, the UE triggers a UE-initiated status reporting procedure upon detecting an initial SN gap based on one or more stored SDUs, wherein the UE-initiated status reporting procedure performs SN gap monitoring to compile a PDCP status report. In step 804, the ue sends a PDCP status report to the wireless network after detecting one or more predefined trigger events, wherein the PDCP status report includes the generated updated SN gap information.

In one embodiment, a storage medium (e.g., a computer-readable storage medium) stores a program that, when executed, causes a UE to perform embodiments of the present invention.

Although the invention has been described in connection with specific embodiments for purposes of illustration, the invention is not limited thereto. Accordingly, various modifications, adaptations, and combinations of the various features of the described embodiments can be practiced without departing from the scope of the invention as set forth in the claims.

Claims

1. A method of initiating a packet data convergence protocol status reporting procedure, comprising:

the user equipment receives PDCP packet data unit PDU from the lower layer through the packet data convergence protocol PDCP entity;

storing PDCP service data units SDUs corresponding to the received PDCP PDUs in a PDCP receive buffer;

triggering a status reporting process initiated by the user equipment when an initial sequence number gap is detected based on one or more stored PDCP SDUs, wherein the status reporting process initiated by the user equipment performs sequence number gap monitoring to compile a PDCP status report; and

upon detection of one or more predefined trigger events, transmitting the PDCP status report to a wireless network, wherein the PDCP status report includes the generated updated sequence number gap information,

wherein the received PDCP PDUs are multicast data packets received from a multicast radio bearer for a multicast broadcast service associated with a multicast channel and a unicast channel for receiving multicast broadcast service data packets, and wherein the PDCP status report is sent to the wireless network over the associated unicast channel.

2. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 1, wherein PDCP SDUs stored therein with consecutive sequence numbers are delivered to an upper layer, a delivery count value rx_deliv is set to the count value of the first PDCP SDU that has not been delivered to the upper layer, and wherein the initial sequence number gap is detected when rx_next is greater than rx_deliv.

3. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 2, wherein a reorder count value rx_reord is set to rx_next upon detecting the initial sequence number gap.

4. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 2, wherein a reorder count value rx_reord is set to rx_next when the PDCP status report is transmitted.

5. The method of initiating a packet data convergence protocol status reporting procedure as claimed in claim 2, wherein when rx_deliv is detected to be equal to rx_next, the UE detects sequence number gap closure and resets the reorder count value rx_reord.

6. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 1, wherein the user device initiated status report procedure starts a reordering timer when the initial sequence number gap is detected and the reordering timer is not running.

7. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 6, wherein the one or more predefined trigger events comprise expiration of the reordering timer.

8. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 6, wherein the user device detects that a sequence number gap closes and stops the reordering timer.

9. The method of initiating a packet data convergence protocol status report procedure as claimed in claim 6, wherein the updated sequence number gap is based on a count value of a first PDCP SDU which has not yet been delivered to an upper layer and rx_next, and wherein the PDCP status report further comprises a bitmap of reception status of PDCP SDUs between a last delivered consecutive PDCP SDU and rx_next.

10. A user device, comprising:

a transceiver for transmitting and receiving radio frequency signals in a wireless network;

a packet data convergence protocol PDCP entity for receiving PDCP packet data units PDUs from a lower layer;

a PDCP control module for storing PDCP service data units SDUs corresponding to received PDCP PDUs in a PDCP receive buffer;

a PDCP status report control module configured to trigger a user equipment initiated status report procedure when an initial sequence number gap is detected based on one or more stored PDCP SDUs, wherein the user equipment initiated status report procedure performs sequence number gap monitoring to compile a PDCP status report; and

a PDCP status report transmitter for transmitting the PDCP status report to the wireless network upon detection of one or more predefined trigger events, wherein the PDCP status report includes the generated updated sequence number gap information,

11. The user equipment of claim 10, wherein the stored PDCP SDUs with consecutive sequence numbers are delivered to an upper layer, a delivery count value rx_deliv is set to a count value of a first PDCP SDU that has not been delivered to the upper layer, and wherein the initial sequence number gap is detected when rx_next is detected to be greater than rx_deliv.

12. The user equipment according to claim 11, characterized in that the reorder count value rx_reorder is set to rx_next upon detection of the initial sequence number gap.

13. The user equipment of claim 11, wherein a reorder count value rx_reorder is set to rx_next when the PDCP status report is sent.

14. The user equipment of claim 11, wherein when rx_deliv is detected to be equal to rx_next, the UE detects sequence number gap closure and resets a reorder count value rx_reord.

15. The user equipment of claim 10, wherein the user equipment initiated status reporting procedure starts a reordering timer when the initial sequence number gap is detected and the reordering timer is not running.

16. The user equipment of claim 15, wherein the one or more predefined trigger events comprise expiration of the reordering timer.

17. The user equipment of claim 15, wherein the user equipment detects that a sequence number gap is closed and stops the reordering timer.

18. The user equipment of claim 15, wherein the updated sequence number gap is based on a count value of a first PDCP SDU that has not yet been delivered to an upper layer and a count value rx_next of a NEXT PDCP SDU that is expected to be received, and wherein the PDCP status report further comprises a bitmap of reception status of PDCP SDUs between a last delivered consecutive PDCP SDU and rx_next.

19. A storage medium storing a program which when executed causes a user equipment to perform the steps of the method of initiating a packet data convergence protocol status reporting procedure as claimed in any one of claims 1 to 9.