Patent Description:
The present disclosure relates generally to methods and apparatus for wireless communications, and, in particular embodiments, to methods and apparatus for efficient packet transmission.

The Third Generation Partnership Project (3GPP) has introduced a packet duplication scheme at the Packet Data Convergence Protocol (PDCP) layer (hence the scheme referred to as PDCP duplication) of long term evolution (LTE) and <NUM> new radio (NR) standards, respectively, to provide a simple solution for improving reliability and reducing latency in wireless networks. <FIG> illustrates diagram <NUM> of an example data transmission from a user equipment (UE) <NUM> to a network <NUM> via a radio bearer (RB) that is configured with PDCP duplication. As shown in <FIG>, two communication paths <NUM> and <NUM>, which are also referred to as legs or radio links, exist between UE <NUM> and network <NUM>. To enable data transmission with PDCP duplication over communication paths <NUM> and <NUM>, one PDCP entity <NUM>, two (one primary and one secondary) radio link control (RLC) entities <NUM> and <NUM>, and associated media access control (MAC) and physical (PHY) entities <NUM> located below RLC entities <NUM> and <NUM> are configured on UE <NUM>, and one PDCP entity <NUM>, two (one primary and one secondary) RLC entities <NUM> and <NUM>, and associated media access control (MAC) and physical (PHY) entities <NUM> located below RLC entities <NUM> and <NUM> are configured on network <NUM> for the RB. The configuration of PDCP entity <NUM>, RLC entities <NUM> and <NUM>, and MAC and PHY entities <NUM> is performed and controlled by a radio resource control (RRC) entity <NUM> of network <NUM>. On UE <NUM>, the configuration of PDCP entity <NUM>, RLC entities <NUM> and <NUM>, and MAC and PHY entities <NUM> is performed by an RRC entity <NUM> located above PDCP entity <NUM> of UE <NUM> but controlled by network <NUM> through over-the-air RRC signaling between RRC entities <NUM> and <NUM>. The arrows in <FIG> indicate that data is being transmitted from UE <NUM> and network <NUM> in this example.

Network <NUM> may also have a need to transmit data to UE <NUM> via this RB with PDCP duplication in order to meet the reliability and latency requirements in the reverse direction. If RLC entities <NUM>-<NUM> in <FIG> are configured as the acknowledged mode (AM) RLC entities, RLC entities <NUM>-<NUM> can also be used for data transmission with PDCP duplication from network <NUM> to UE <NUM>. This is because an AM RLC entity comprises of a transmitting side and a receiving side, and therefore supports bi-directional communications. If RLC entities <NUM>-<NUM> in <FIG> are configured as the unacknowledged mode (UM) RLC entities, another pair of UM RLC entities (not shown in <FIG>) need to be configured on each of UE <NUM> and network <NUM> for data transmission in the reverse direction, so that on each of UE <NUM> and network <NUM>, one pair of transmitting UM RLC entities are used for transmitting data with PDCP duplication and one pair of receiving UM RLC entities are used for receiving data with PDCP duplication. This is because a UM RLC entity can be either a transmitting UM RLC entity (which is only capable of transmitting data) or a receiving UM RLC entity (which is only capable of receiving data), but not both.

The various functional entities illustrated on UE <NUM> in <FIG> are normally located within a single UE device. Meanwhile, the various functional entities on network <NUM> side in <FIG> may be co-located within a single network node, such as an enhanced Node B (eNB) or a next generation Node B (gNB), for example, when PDCP duplication is provided using carrier aggregation (CA). Alternatively, when PDCP duplication is provided using dual connectivity (DC), the PDCP entity (such as PDCP entity <NUM>) is in a hosting eNB or gNB referred to as the master node (MN), while the two underlying RLC entities (such as RLC entities <NUM> and <NUM>) and the associated MAC and PHY entities (such as MAC and PHY entities <NUM>, which, for example, would consist of two pairs of MAC and PHY entities) are respectively located at the MN and a secondary eNB or gNB referred to as the secondary node. Furthermore, a logical gNB may be partitioned into a centralized unit (CU) plus one or more differently located distributed units (DUs), with the PDCP entity (such as PDCP entity <NUM>) being located in the gNB-CU and the two underlying RLC entities (such as RLC entities <NUM> and <NUM>) and the associated MAC and PHY entities (such as MAC and PHY entities <NUM>) being located in one or more gNB-DUs.

As shown in <FIG>, on UE <NUM> side, a data in the form of a PDCP service data unit (SDU) is obtained from a higher layer entity above PDCP entity <NUM> and processed by PDCP entity <NUM> to produce a PDCP protocol data unit (PDU). Examples of the higher layer entity above the PDCP entity include RRC entity <NUM> (as shown in <FIG>), when the RB is a signaling RB (SRB), and a service data adaptation protocol (SDAP) entity for <NUM> NR or an Internet protocol (IP) entity for LTE (neither being shown in <FIG>), when the RB is a data RB (DRB). Then, the PDCP PDU is duplicated by PDCP entity <NUM> and a copy of the PDCP PDU is delivered to each of RLC entities <NUM> and <NUM>. Each of RLC entities <NUM> and <NUM> includes the PDCP PDU in one RLC PDU, or if the PDCP PDU is oversized, includes segments of the PDCP PDU in more than one RLC PDUs, and then delivers the RLC PDU(s) to MAC and PHY entities <NUM> for transmissions over associated radio links <NUM> and <NUM>, respectively. Although two radio links are shown in <FIG>, it is possible to configure PDCP duplication with more than two radio links.

On network <NUM> side, when a PDCP PDU is successfully received over both radio links <NUM> and <NUM>, PDCP entity <NUM> of network <NUM> detects and discards a duplicated copy so that the PDCP PDU is delivered to the higher layer entity on network <NUM> side only once. When a PDCP PDU is successfully received over one radio link but not over the other, PDCP entity <NUM> of network <NUM> delivers the received PDCP PDU to the associated higher layer entity. Therefore, the impact of losing the PDCP PDU over the other radio link is mitigated. Only when the transmissions of the PDCP PDU over both radio links are lost, does the PDCP entity of the network experience the loss of the PDCP PDU. Hence, PDCP duplication improves reliability through redundancy and path diversity. The path diversity can be frequency diversity when the different radio links are provided through different frequency carriers (i.e., using CA), or spatial diversity when the different radio links are provided through differently located transmitting nodes (i.e., using DC), or a combination thereof. Robustness is not only improved for data in the user plane (i.e., when the RB is a DRB) but also for signaling messages in the control plane (i.e., when the RB is an SRB). PDCP duplication also reduces jitters by minimizing the variance in latency.

<CIT> discloses: Techniques provided herein select an operating mode from a plurality of operating modes. Various implementations establish a radio bearer with at least one network entity over a network using a first Radio Link Control (RLC) protocol entity and a second RLC protocol entity. Various implementations determine whether packet duplication is enabled for the radio bearer by processing Packet Data Convergence Protocol (PDCP) configuration settings. In response to determining that packet duplication is enabled, various implementations duplicate uplink data packets over the network by submitting the uplink data packets to both the first RLC protocol entity and the second RLC entity. In response to determining that packet duplication is disabled and split bearer is enabled, various implementations select one of the first RLC protocol entity and the second RLC protocol entity for uplink data packet transmission.

<CIT> discloses a media access control layer multiplexing method and devices. Information indication for PDCP (Packet Data Convergence Protocol) data duplication is realized between a network and a terminal, PDCP PDU and PDCP data duplication is guaranteed to be not multiplexed in one transmission block, and PDCP duplication reliability gain is further guaranteed.

According to a first aspect, a method implemented by a device is provided according to appended claim <NUM>.

According to a second aspect, an apparatus is provided according to appended claim <NUM>. The apparatus is configured to perform the method according to the first aspect.

According to a third aspect, a computer program product is provided according to appended claim <NUM>. The computer program product comprises an instruction, wherein when the instruction is executed by one or more processor, cause the one or more processor to perform the method according to the first aspect.

Further advantageous embodiments of the invention are set out in the appended dependent claims.

An advantage of a preferred embodiment is that radio resource efficiency is improved by providing more time to identify, and based thereon, to cancel the unnecessary duplicated transmissions, while the reliability and latency performance during data transmission are improved by maintaining the necessary duplicated transmissions.

Yet another advantage of a preferred embodiment is that the enhanced packet duplication and transmission cancellation techniques not only work for AM DRBs, but also for SRBs and UM DRBs.

Practice of the foregoing embodiments facilitates ultra-reliable and low-latency communication (URLLC).

The structure and use of disclosed embodiments are discussed in detail below. It should be appreciated, however, that the present disclosure provides many applicable concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific structure and use of embodiments, and do not limit the scope of the disclosure.

The benefits of using Packet Data Convergence Protocol (PDCP) duplication, as specified in 3GPP Release <NUM> standards, come with a price, i.e., the system-wise radio efficiency is reduced, because additional radio resources, in frequency and/or spatial domains, are needed for transmitting the duplicated packets. In certain scenarios, the benefits of using PDCP duplication may be limited, hence may be unjustified due to the lower radio efficiency. For example, when the channel conditions over one or both radio links are good, the additional radio resources used in transmitting the duplicated packets are mostly wasted. For another example, if the latency over the Xn interface between the master node (MN) and the secondary node is high with the MN being the data anchor towards the network, then, latency reduction achieved by using the secondary node for the duplicated transmissions may be marginal. Hence, a dynamic control mechanism is introduced in Third Generation Partnership Project (3GPP) Release <NUM> standards, wherein PDCP duplication, once configured between a data-transmitting device and data-receiving device (e.g., user equipment (UE) <NUM> and network <NUM> in <FIG>), can be dynamically activated when and where it is beneficial and de-activated when and where the use of it is unjustified. However, the dynamic control mechanism incurs additional signaling overheads, e.g., the media access control (MAC) control elements (CEs) that carries the activation or de-activation command, and the measurement reports of radio conditions or radio link performance, based which decisions to activate or de-activate PDCP duplication may be made.

Besides the dynamic activation/de-activation of PDCP duplication, 3GPP technical specification (TS) <NUM> also specifies that when a transmitting radio link control (RLC) entity (such as RLC entity <NUM> in <FIG>) acknowledges the transmission of a PDCP protocol data unit (PDU) being successful, the transmitting PDCP entity (such as PDCP entity <NUM>) shall indicate to the other transmitting RLC entity (such as RLC entity <NUM>) to cancel any pending transmissions of the same PDCP PDU in order to avoid unnecessary duplicated transmission. For example, the transmitting RLC entity may determine the transmission of a PDCP PDU being successful based on an RLC Status PDU feedback received from the counterpart RLC entity of the data-receiving device. The RLC Status PDU may be received from the counterpart RLC entity in response to a timer expiration, a data volume exceeding a threshold, or an explicit request sent by the transmitting RLC entity. In any case, RLC Status PDUs aren't meant to be transmitted frequently due to the signaling overhead involved.

On the other hand, schedulers associated with the two radio links, respectively, are racing against each other in scheduling the transmissions of the same PDCP PDUs over the respective radio link at about the same time. Therefore, despite the transmission cancellation scheme specified in the standard, in practice, transmissions of many duplicated packets may not be cancelled in time to avoid the unnecessary transmissions over the air. The transmission of a duplicated PDCP PDU, where the transmission occurs after the PDCP PDU has been successfully transmitted (i.e., has been received by the counterpart) at least once over one of the multiple radio links, is herein and hereafter referred to as an unnecessary duplicated transmission. The transmission of a duplicated PDCP PDU over a radio link won't result in a duplicate being received when the transmissions of the same PDCP PDU over the other radio link(s) have exhausted the maximal number of automatic repeat request (ARQ) retransmissions (for acknowledged mode (AM) RLC) or hybrid ARQ (HARQ) retransmissions (for unacknowledged mode (UM) RLC) and still failed. Therefore, this later type of duplicated transmissions is truly needed, and is herein and hereafter referred to as the necessary duplicated transmission. However, the RLC Status PDU, as specified in 3GPP TS <NUM> and TS <NUM>, is only available for AM RLC. Hence, the transmission cancellation scheme based on the RLC feedback (e.g., carried in an RLC Status PDU) only works for signaling RBs (SRBs) and data RBs (DRBs) that use AM RLC (which DRBs are referred to as AM DRBs) but doesn't work for DRBs that use UM RLC (which DRBs are referred to as UM DRBs). UM DRBs are often used for real-time multimedia services, such as real-time video streaming, augmented reality (AR), virtual reality (VR), and interactive gaming. When PDCP duplication is used in delivering these services over multiple radio links of a UM DRB, unnecessary duplicated transmissions are unavoidable due to a lack of the RLC feedback. Hence, the radio efficiency is low in these situations.

Therefore, there is a need for methods and apparatus to overcome the above drawbacks in order to further improve the radio efficiency when PDCP duplication is used to improve reliability and to lower latency and jitter. Example embodiments enable a data-transmitting device, which utilizes PDCP duplication for transmitting data, to cancel as many unnecessary duplicated transmissions as possible. Example embodiments also enable the data-transmitting device to determine, as early as possible, which pending duplicated transmissions are necessary and which ones are unnecessary, in order to achieve the first goal.

According to example embodiments, methods and apparatus are provided for a device to transmit data using packet duplication with high radio efficiency. The device obtains a stream of packets to be transmitted; stores the stream of packets in each buffer of a plurality of buffers; transmits packets stored in the plurality of buffers over a plurality of radio links, wherein the packets stored in the each buffer of the plurality of buffers are transmitted over a unique radio link of the plurality of radio links in an order unique for that radio link; and while transmitting the packets stored in the plurality of buffers over the plurality of radio links, receives information of one or more packets of the stream of packets being successfully received by a peer device. The device discards the one or more packets from the each buffer of the plurality of buffers (so as to prevent them from being transmitted again) based on the information of the one or more packets of the stream of packets being successfully received by the peer device. In other words, by transmitting the same stream of packets in different orders over different radio links, the radio resources on the different radio links can be used for initially transmitting different packets of the stream of packets while different remaining packets of the stream of packets can be queued in the respective buffers for pending transmissions over the different radio links, in case that any of the different packets initially transmitted fails. This helps to avoid the race condition between the different radio links.

When the different packets are successfully transmitted over the different radio links, the respective duplicated copies of the successfully transmitted packets, which are still being queued in the buffers of associated radio links that have not had an opportunity to transmit the duplicates of the successfully transmitted packets, are therefore discarded. Hence, no further transmission of these packets is attempted by any other radio links. When the transmission of a packet over a radio link has failed (e.g., having exhausted the maximal number of ARQ (for AM RLC) or HARQ (for UM RLC) re-transmissions and still failed), the packet will be discarded by the transmitting RLC entity associated with that radio link (e.g., removed from the transmission buffer of that transmitting RLC entity), but a duplicated copy of the same packet is still being queued in the buffer(s) of the transmitting RLC entity(s) associated with the other radio link(s) for pending transmissions.

While the conventional PDCP duplication method has the issue that the race condition between the different radio links undermines the effectiveness of the transmission cancellation scheme, the enhancement described herein helps to avoid the race condition and provides more time between the first moment that a packet being successfully transmitted over one radio link is determined (e.g., by receiving a feedback from the peer device) and the moment(s) that the other radio link(s) are scheduled to transmit the same packet. And as a result, the chance to cancel the pending transmission(s) of the duplicated copy(s) of the same packet over the other radio link(s) in time is increased. In short, the enhancement described herein yields a higher chance to avoid the unnecessary duplicated transmissions, achieving the first goal as described above.

In an embodiment, in order to enable the transmissions of the packets stored in the plurality of buffers over the plurality of radio links with orderings that are unique for the respective radio links, a logical function block (referred to as a re-sequence block) is added to the data-transmitting device associated with one or more of the plurality of radio links. The re-sequence block causes the order, in which packets of the stream of packets are submitted to the lower layer entities (such as MAC and PHY entities <NUM> in <FIG>) for transmission, be altered comparing with a natural order, the natural order being the order that these packets are obtained from a higher layer (such as RRC, SDAP, or IP) entity or the order of the PDCP sequence numbers (SNs) that these packets are respectively assigned with by the transmitting PDCP entity (such as PDCP entity <NUM>), for example, wherein the PDCP SN assignment occurs before the re-sequence block.

In a first embodiment, no re-sequence block is added to a first radio link of the plurality of radio links while a re-sequence block is added to each of the remaining radio links, with each of the re-sequence blocks being configured with a unique alteration pattern (or algorithm), so that packets of the same stream of packets are to be transmitted in the natural order over the first radio link while packets of the same stream of packets are to be transmitted in a uniquely altered order over the remaining radio link(s). In a second embodiment, a re-sequence block is added to each of the plurality of radio links, with each of the re-sequence blocks being configured with a unique alteration pattern (or algorithm). In a special case of the second embodiment, the re-sequence block added to the first radio link is a null block, meaning that no alteration is made to the transmission order (comparing with the natural order) of the stream of packets. In this situation, the second embodiment effectively becomes the first embodiment. Therefore, the first embodiment is a special case of the second embodiment, wherein one of the plurality of re-sequence blocks of the second embodiment being a null block.

In accordance with a first example architecture embodiment, the conventional transmitting PDCP entity can be enhanced by adding one or more re-sequence block(s) at the bottom of the transmitting PDCP entity (such as PDCP entity <NUM> in <FIG>), after the PDCP duplication function block. Each of the one or more re-sequence blocks may include a buffer (memory) for performing the re-sequence function and/or storing the stream of packets, before delivering the stream of packets in the respective order (the natural order or a uniquely altered order) to the associated lower layers for transmission.

<FIG> illustrates a diagram <NUM> of an example of an enhanced transmitting PDCP entity <NUM>, with a corresponding receiving PDCP entity <NUM>, wherein transmitting PDCP entity <NUM> duplicates a stream of PDCP PDUs for two radio links (referred to as Link <NUM> and Link <NUM> in <FIG>). Enhanced transmitting PDCP entity <NUM> differs from a conventional transmitting PDCP entity in that a re-sequence block <NUM> is added to transmitting PDCP entity <NUM>, after a PDCP duplication and routing block <NUM>, on the path towards an underlying RLC entity associated with Link <NUM>, while no re-sequence block is added on the path toward another underlying RLC entity associated with Link <NUM>.

<FIG> illustrates a diagram <NUM> of another example of an enhanced transmitting PDCP entity <NUM>, with a corresponding receiving PDCP entity <NUM>, wherein transmitting PDCP entity <NUM> duplicates a stream of PDCP PDUs for two radio links (referred to as Link <NUM> and Link <NUM> in <FIG>). Enhanced transmitting PDCP entity <NUM> differs from the conventional transmitting PDCP entity in that two re-sequence blocks <NUM> and <NUM> are added to transmitting PDCP entity <NUM>, after the PDCP duplication and routing block <NUM>, on the paths towards both underlying RLC entities, with each of re-sequence blocks <NUM> and <NUM> being configured with a unique alteration pattern (or algorithm).

The enhanced transmitting PDCP entities illustrated in <FIG> and <FIG> may be implemented in a UE or a network node, such as an eNB, a gNB, or a gNB-CU. In both examples, the two RLC entities located below the transmitting PDCP entity can both be AM RLC entities or UM RLC entities. As discussed before, the example illustrated in <FIG> is effectively a special case of the example illustrated in <FIG>, with the re-sequence block added for Link <NUM> in <FIG> being a null block. Furthermore, although <FIG> and <FIG> illustrate PDCP entities that duplicate streams of PDCP PDUs over two radio links, the example embodiments are capable of duplicating the streams over a plurality of radio links. Therefore, the discussion of two radio links should not be construed as being limiting to the scope of the example embodiments.

In accordance with a second example architecture embodiment, a re-sequence block may be added to one or more transmitting RLC entities (such as RLC entities <NUM> and <NUM> in <FIG>), either added as a separate function block before the RLC header generation and transmission buffer block, or combined with the RLC header generation and transmission buffer block to form a modified RLC header generation and transmission buffer block that performs the re-sequence function in addition to the storing and RLC header generation functions.

<FIG> illustrates a diagram <NUM> of a first example of two enhanced AM RLC entities <NUM> and <NUM> used in PDCP duplication. Enhanced AM RLC entities <NUM> and <NUM> differ from a conventional AM RLC entity in that a re-sequence block, such as re-sequence blocks <NUM> and <NUM>, is added to the transmitting side of AM RLC entities <NUM> and <NUM>, respectively, AM RLC entities <NUM> and <NUM> being associated with two radio links (shown as Link <NUM> and Link <NUM><NUM> in <FIG>), respectively, with each of re-sequence blocks <NUM> and <NUM> being configured with a unique alteration pattern (or algorithm).

<FIG> illustrates a diagram <NUM> of a second example of two enhanced transmitting UM RLC entities <NUM> and <NUM> (on the left sides of Link <NUM><NUM> and Link <NUM><NUM>, respectively, in <FIG>) used in PDCP duplication, with corresponding receiving UM RLC entities <NUM> and <NUM> illustrated on the right sides of the respective radio links. Enhanced transmitting UM RLC entities <NUM> and <NUM> differ from a conventional transmitting UM RLC entity in that a re-sequence block, such as re-sequence blocks <NUM> and <NUM>, is added to transmitting UM RLC entities <NUM> and <NUM>, respectively, transmitting UM RLC entities <NUM> and <NUM> being associated with Link <NUM><NUM> and Link <NUM><NUM>, respectively, with each of re-sequence blocks <NUM> and <NUM> being configured with a unique alteration pattern (or algorithm).

Enhanced AM RLC entities <NUM> and <NUM> or enhanced transmitting UM RLC entities <NUM> and <NUM> may be implemented in a UE or one or more network nodes, such as eNBs, gNBs, or gNB-DUs. Re-sequence blocks <NUM>, <NUM>, <NUM>, and <NUM> are shown in <FIG> and <FIG> as being placed, as separate blocks, before RLC header generation and transmission buffer blocks <NUM>, <NUM>, <NUM>, and <NUM> of the respective RLC entities. Alternatively, each re-sequence block may be combined with the respective RLC header generation and transmission buffer block to form a modified RLC header generation and transmission buffer block that performs the re-sequence function in addition to the storing and RLC header generation functions. As an example, re-sequence block <NUM> may be combined with RLC header generation and transmission buffer block <NUM>. As discussed before, a re-sequence block added to one of the multiple radio links (such as Link <NUM><NUM> and <NUM> of <FIG> and <FIG>) can be a null block. Hence, the use of the second embodiment as presented in the illustration and description of <FIG> and <FIG> should not be interpreted as excluding the use of the first embodiment described previously.

In accordance with a first example PDCP duplication scheme, the re-sequence block added for one of two radio links that are configured for PDCP duplication, such as re-sequence blocks <NUM>, <NUM>, and <NUM> added for Link <NUM> in <FIG>, <FIG>, and <FIG>, respectively, is a null block. Or, in another words, no re-sequence block is added for that radio link, as illustrated in <FIG>. Meanwhile, the re-sequence block added for the other radio link (such as re-sequence blocks <NUM>, <NUM>, <NUM>, and <NUM> added for Link <NUM> in <FIG>, <FIG>, <FIG>, and <FIG>, respectively) is a last-in first-out (LIFO) buffer. It is noted that the conventional transmission buffer in an RLC entity (such as RLC header generation and transmission buffer blocks <NUM> and <NUM> in <FIG> and <FIG>) works as a first-in first-out (FIFO) buffer.

<FIG> illustrates a diagram <NUM> of how data packets are written into and read out from a FIFO buffer. Steps <NUM>-<NUM> illustrate packets #<NUM>-#<NUM> being written into a FIFO buffer, while steps <NUM>-<NUM> illustrates packets #<NUM>-#<NUM> being read out from the FIFO buffer. As an example, packet #<NUM> is the first packet written into the FIFO buffer (step <NUM>), and packet #<NUM> is the first packet read out of the FIFO buffer (step <NUM>). <FIG> illustrates a diagram <NUM> of how data packets are written into and read out from a LIFO buffer. Steps <NUM>-<NUM> illustrate packets #<NUM>-#<NUM> being written into a LIFO buffer, while steps <NUM>-<NUM> illustrates packets #<NUM>-#<NUM> being read out from the LIFO buffer. As an example, packet #<NUM> is the last packet written into the LIFO buffer (step <NUM>), and packet #<NUM> is the first packet read out of the LIFO buffer (step <NUM>).

<FIG> illustrates a diagram <NUM> of an example of a stream of packets in the form of PDCP PDUs being transmitted in a FIFO manner for one of the two radio links (e.g., Link <NUM> in <FIG>) and in a LIFO manner for the other of the two radio links (e.g., Link <NUM><NUM> in <FIG>), in accordance with the first example PDCP duplication scheme described above. A re-sequence block <NUM>, which is a LIFO buffer as illustrated in <FIG>, is added for Link <NUM><NUM>, while no re-sequence block is added for Link <NUM><NUM>. A conventional transmission buffer <NUM> in a RLC header generation and transmission buffer block of the RLC entity associated with Link <NUM><NUM> is a FIFO buffer, as illustrated in <FIG>. Therefore, in the absence of a re-sequence block for Link <NUM><NUM>, the stream of PDCP PDUs are submitted in a FIFO manner to the underlying MAC and PHY entities associated with Link <NUM><NUM> for transmission. Meanwhile, a conventional transmission buffer <NUM> in a RLC header generation and transmission buffer block of the RLC entity associated with Link <NUM><NUM> is also a FIFO buffer. However, with re-sequence <NUM> being added for Link <NUM><NUM>, the same (duplicated) stream of PDCP PDUs are effectively submitted in a LIFO manner to the underlying MAC and PHY entities associated with Link <NUM><NUM> for transmission.

In <FIG>, re-sequence block <NUM> is shown as being added across a border line between PDCP layer <NUM> and RLC layer <NUM>, to reflect the possible variations, wherein re-sequence block <NUM> may be located at PDCP entity <NUM>, as illustrated in <FIG>, or at the transmitting side of the AM RLC entity or the transmitting UM RLC entity associated with Link <NUM><NUM>, such as illustrated in <FIG> and <FIG>, respectively, with re-sequence blocks <NUM> and <NUM> added for Link <NUM> in <FIG> and <FIG>, respectively, being a null block. In the latter two cases where re-sequence block <NUM> is located at the transmitting side of the AM RLC entity or transmitting UM RLC entity, re-sequence block <NUM> may be a separate buffer located before the RLC header generation and transmission buffer block, as illustrated in <FIG> and <FIG>, with conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of the RLC entity associated with Link <NUM><NUM> being a FIFO buffer.

Alternatively, re-sequence block <NUM> may simply replace conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of the RLC entity associated with Link <NUM><NUM>, with the RLC header being generated for each PDCP PDU after the PDCP PDU is read out from the LIFO buffer for delivery to the lower layer.

As shown in <FIG>, N PDCP PDUs (labeled from <NUM> to N, e.g., <NUM> to N being the respective PDCP SNs of the N PDCP PDUs) are generated by the transmitting PDCP entity from N PDCP SDUs obtained from the higher layer entity above the transmitting PDCP entity. Each PDCP PDU includes, in a PDCP header of the PDCP PDU (which headers are not shown in <FIG>), a unique PDCP SN assigned by the transmitting PDCP entity in an incremental manner. Additional processing, such as header compression, integrity protection, and ciphering, as shown in various function blocks in <FIG>, may be performed on the PDCP SDUs when generating the PDCP PDUs. Then, the stream of the PDCP PDUs is duplicated for Link <NUM> and Link <NUM><NUM> by the duplication and routing block (as shown in <FIG>) of the transmitting PDCP entity. The first duplicated stream of the N PDCP PDUs are directly submitted to a first underlying RLC entity associated with Link <NUM><NUM> and stored in conventional transmission buffer <NUM> (which is a FIFO buffer) in the RLC header generation and transmission buffer block of the first RLC entity. When transmission opportunity presents at the lower layer (i.e., MAC and PHY) entities associated with Link <NUM>, the first duplicated stream of the N PDCP PDUs stored in conventional transmission buffer <NUM> are read out in the natural order, with each PDCP PDU being added with an RLC header (shown in <FIG> as "Hdr" followed by a number) to generate an RLC PDU.

A PDCP PDU may generate more than one RLC PDUs if the PDCP PDU is oversized and therefore, needs to be segmented into multiple segments, with each of the more than one RLC PDUs carrying one of the multiple segments. In which case, the RLC headers added to each of the more than one RLC PDUs share a same RLC SN that is unique to the PDCP PDU, where the RLC SN assists the data-receiving device in reassembling the multiple segments back into the whole PDCP PDU. The effect of RLC segmentation isn't shown in <FIG> for simplicity. Then, the generated RLC PDUs are submitted, in the order that they are generated, to the lower layers for transmissions over Link <NUM><NUM>.

Meanwhile, the second duplicated stream of the N PDCP PDUs are submitted to re-sequence block <NUM> (which is a LIFO buffer) first, and are either stored in re-sequence block <NUM>, if re-sequence block <NUM> has replaced conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of a second RLC entity associated with Link <NUM><NUM>. Alternatively, the second duplicated stream of the N PDCP PDUs are read out from re-sequence block <NUM> (in the LIFO manner) and then stored in conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of the second RLC entity in the order that they are read out from re-sequence block <NUM>, if re-sequence block <NUM> is a separate buffer located before the RLC header generation and transmission buffer block of the second RLC entity.

When a transmission opportunity presents at the lower layers associated with Link <NUM><NUM>, the second duplicated stream of the N PDCP PDUs, which are either stored in re-sequence block <NUM>, if re-sequence block <NUM> has replaced conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of the second RLC entity, or stored in conventional transmission buffer <NUM>, if re-sequence block <NUM> is a separate buffer located before the RLC header generation and transmission buffer block of the second RLC entity, are read out in the altered order (comparing with the natural sequential order), due to the use of re-sequence block <NUM>. Each PDCP PDU read out is added with an RLC header to generate an RLC PDU. Then, the generated RLC PDUs are submitted, in the order that they are generated, to the lower layers for transmissions over Link <NUM><NUM>.

Therefore, as shown in <FIG>, the stream of N PDCP PDUs is to be transmitted over Link <NUM><NUM> in sequential order from <NUM> to N, while they are to be transmitted over Link <NUM><NUM> in reverse order from N to <NUM>. <FIG> further shows that, as PDCP PDUs #<NUM><NUM> and #N <NUM> are successfully transmitted (shown as being checked by a check mark) over Link <NUM><NUM> and Link <NUM><NUM>, respectively, the duplicated copies of them are discarded (e.g., duplicate PDCP PDU #<NUM><NUM> is discarded due to successful transmission of PDCP PDU #<NUM><NUM>, and duplicate PDCP PDU #N <NUM> is discarded due to successful transmission of PDCP PDU #N <NUM>) from the back of the transmission buffer of the respective RLC entity associated the other radio link, the transmission buffer being either re-sequence block <NUM> (which is a LIFO buffer), if re-sequence block <NUM> is combined with and thereby replaces conventional transmission buffer <NUM> in the RLC header generation and transmission buffer block of the second RLC entity, or conventional transmission buffer <NUM>, if re-sequence block <NUM> is a separate buffer located before the RLC header generation and transmission buffer block of the second RLC entity. <FIG> shows that there is no race condition between Link <NUM><NUM> and Link <NUM><NUM>, and there is ample time to cancel the unnecessary duplicated transmissions.

In accordance with a second example PDCP duplication scheme, a re-sequence block is added for each of multiple radio links that are configured for PDCP duplication, e.g., a re-sequence block is added for each of the two radio links at the transmitting PDCP entity, as illustrated in <FIG>, or at the transmitting side of each AM RLC entity, as illustrated in <FIG>, or at each transmitting UM RLC entity, as illustrated in <FIG>, wherein each of the re-sequence blocks comprises of two (FIFO) buffers, with a first FIFO buffer being referred to as the prioritized buffer and a second FIFO buffer being referred to as the unprioritized buffer. Furthermore, the stream of PDCP PDUs may be logically partitioned into M mutually exclusive sets of PDCP PDUs, where M is the number of radio links being used for PDCP duplication. A first re-sequence block associated with a first radio link of the multiple radio links (such as Link <NUM> in <FIG>, <FIG>, and <FIG>) stores a first set of the M sets of PDCP PDUs into its prioritized buffer and the remaining sets of PDCP PDUs into its unprioritized buffer. A second re-sequence block associated with a second radio link of the multiple radio links (such as Link <NUM> in <FIG>, <FIG>, and <FIG>) stores a second set of the M sets of PDCP PDUs into its prioritized buffer and the remaining sets of PDCP PDUs into its unprioritized buffer, and so on and so forth. Then, for each radio link, when a transmission opportunity presents at the lower layers associated with the radio link, as a general guideline, the re-sequence block associated with that radio link may attempt to empty its prioritized buffer first before attempting to empty its unprioritized buffer.

As an example, if the re-sequence blocks (each comprising the dual buffers) are added at the bottom of the transmitting PDCP entity, as illustrated in <FIG>, then when a first underlying RLC entity requests for more PDCP PDUs to be delivered, a first re-sequence block associated with the first underlying RLC entity may first attempt to deliver the PDCP PDUs stored in its prioritized buffer (in sequence) to the first underlying RLC entity if its prioritized buffer isn't empty, and the first re-sequence block may then attempt to deliver the PDCP PDUs stored in its unprioritized buffer (in sequence) to the first underlying RLC entity when its prioritized buffer is empty. Similarly, the other re-sequence blocks may also first attempt to deliver the PDCP PDUs stored in their respective prioritized buffers before attempting to deliver the PDCP PDUs stored in their respective unprioritized buffers.

As another example, if the re-sequence blocks are added at the transmitting side of each underlying AM RLC entity (as illustrated in <FIG>) or at each transmitting UM RLC entity (as illustrated in <FIG>), then the re-sequence blocks may be added, as a separate block, before the respective RLC header generation and transmission buffer blocks, as shown in <FIG> and <FIG>. Alternatively, the re-sequence blocks may be combined with the RLC header generation and transmission buffer blocks to form modified RLC header generation and transmission buffer blocks, respectively, wherein the conventional transmission buffer in the RLC header generation and transmission buffer block is replaced by the dual buffers and an RLC header is generated for (and an RLC SN is assigned to) a PDCP PDU after the PDCP PDU is read out from one of the dual buffers for delivery to the segmentation block below.

When a transmission opportunity presents at the lower layers associated with an RLC entity, as a general guideline, the PDCP PDUs stored in the prioritized buffer of that RLC entity may first be delivered, in sequence, to the segmentation block below when the prioritized buffer isn't empty, and the PDCP PDUs stored in the unprioritized buffer of that RLC entity may be delivered, in sequence, to the segmentation block below when the prioritized buffer of that RLC entity is empty.

The later approach of having the dual buffers replacing the conventional transmission buffer in the RLC header generation and transmission buffer block has an advantage of requiring less memory than the former two approaches, both of which add the multiple dual buffers, either at the transmitting PDCP entity or at the RLC entities as separate function blocks, in addition to the transmission buffers that currently exist in the RLC header generation and transmission buffer blocks.

<FIG> illustrates a diagram <NUM> of the transmission of an example stream of packets (PDCP PDUs), wherein a re-sequence block is added for each of two radio links <NUM> and <NUM> that are configured for PDCP duplication, each re-sequence block comprising the dual (prioritized and unprioritized) buffers, in accordance with the second example PDCP duplication scheme described above. In <FIG>, re-sequence blocks <NUM> and <NUM> are shown as being added across a border line between the PDCP layer and the RLC layer, to reflect the possible variations, wherein re-sequence blocks <NUM> and <NUM> may be located at the PDCP entity (as illustrated in <FIG>), at the transmitting side of each underlying AM RLC entity (as illustrated in <FIG>), or at each transmitting UM RLC entity (as illustrated in <FIG>). In the latter two cases where re-sequence blocks <NUM> and <NUM> are added at the transmitting RLC entities, re-sequence blocks <NUM> and <NUM> may be added, as a separate block, before the respective RLC header generation and transmission buffer block, as shown in <FIG> and <FIG>. Alternatively, re-sequence blocks <NUM> and <NUM> (the dual buffers) may replace the conventional transmission buffer in the RLC header generation and transmission buffer block to form a modified RLC header generation and transmission buffer block, with the RLC header being generated for (and an RLC SN being assigned to) a PDCP PDU after the PDCP PDU is read out from one of the dual buffers.

As shown in <FIG>, when receiving the stream of PDCP PDUs, a first re-sequence block <NUM> (shown as Re-sequence Block <NUM>) associated with Link <NUM> stores PDCP PDUs assigned with an odd PDCP SN in its prioritized buffer <NUM> and PDCP PDUs assigned with an even PDCP SN in its unprioritized buffer <NUM>, while a second re-sequence block <NUM> (shown as Re-sequence Block <NUM>) associated with Link <NUM><NUM> stores PDCP PDUs assigned with an even PDCP SN in its prioritized buffer <NUM> and PDCP PDUs assigned with an odd PDCP SN in its unprioritized buffer <NUM>. Therefore, Re-sequence Block <NUM><NUM> prioritizes PDCP PDUs with an odd PDCP SN over PDCP PDUs with an even PDCP SN, while Re-sequence Block <NUM><NUM> does the opposite.

When a transmission opportunity presents at the lower (i.e., MAC and PHY) layers associated with Link <NUM>, Re-sequence Block <NUM><NUM> may first read out the PDCP PDUs stored in prioritized buffer <NUM>, in sequence (i.e., in the order that the PDCP PDUs are written into prioritized buffer <NUM>), when prioritized buffer <NUM> isn't empty. Re-sequence Block <NUM><NUM> may read out the PDCP PDUs stored in unprioritized buffer <NUM> when prioritized buffer <NUM> is empty. Then, an RLC header (shown as "Hdr" followed by an integer in <FIG>) is generated for each PDCP PDU being read out to form one or more RLC PDUs. As described previously, an oversized PDCP PDU may be segmented into multiple segments, which are be carried in multiple RLC PDUs, respectively. The effect of segmentation isn't shown in <FIG> for simplicity. Then, the generated RLC PDUs are submitted, in the order that they are generated, to the lower layers for transmissions over Link <NUM><NUM>. Similarly, when a transmission opportunity presents at the lower (i.e., MAC and PHY) layers associated with Link <NUM><NUM>, Re-sequence Block <NUM><NUM> may first attempt to read out the PDCP PDUs stored in prioritized buffer <NUM> before attempting to read out the PDCP PDUs stored in unprioritized buffer <NUM>.

<FIG> further shows that, as PDCP PDUs with odd (or even) PDCP SNs are successfully transmitted (shown as being checked by a check mark) over Link <NUM><NUM> (or Link <NUM><NUM>), the duplicated copies of them are discarded (shown as being deleted by a deletion line) from unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM> (or unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM>). As an example, PDCP PDUs #<NUM><NUM> and #<NUM><NUM> are successfully transmitted, duplicate PDCP PDUs #<NUM><NUM> and #<NUM><NUM> are discarded from unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM> and unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM>, respectively. <FIG> also shows that, as PDCP PDUs #<NUM><NUM> and #(2N-<NUM>) <NUM> are transmitted unsuccessfully (shown as being crossed by an X mark) over Link <NUM><NUM> and Link <NUM><NUM>, respectively, the duplicated copy of them (duplicate PDCP PDUs #<NUM><NUM> and #(2N-<NUM>) <NUM>) are kept in unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM> and unprioritized buffer <NUM> of Re-sequence Block <NUM><NUM>, respectively. Furthermore, when a transmission opportunity presents over Link <NUM><NUM> and prioritized buffer <NUM> is empty, the remaining PDCP PDUs in unprioritized buffers <NUM> may be read out for transmission over Link <NUM><NUM>, as a necessary duplicated transmission as defined before. Similarly, when a transmission opportunity presents over Link <NUM><NUM> and prioritized buffer <NUM> is empty, the remaining PDCP PDUs in unprioritized buffers <NUM> may be read out for transmission over Link <NUM><NUM>.

Partitioning a stream of PDCP PDUs by odd and even PDCP SNs for different prioritization over different radio links is a simple example of partitioning and is suitable when the number of radio links is two and the two radio links have similar performance, e.g., in terms of throughput and/or transmission error rate. As a generalization of the concept described herein, a stream of PDCP PDUs can be partitioned into a set of prioritized PDCP PDUs and a set of unprioritized PDCP PDUs for each radio link in accordance with the PDCP SNs of the PDCP PDUs and a formula that is unique for the each radio link. The sets of prioritized PDCP PDUs for different radio links may be mutually exclusive to minimize the race condition between the different radio links.

For example, if the number of radio links used in packet duplication is three and the throughput ratio among the three radio links (Link <NUM>, Link <NUM>, and Link <NUM>) is roughly <NUM>:<NUM>:<NUM>, then for Link <NUM>, PDCP PDUs with a PDCP SN equal to 4n, where n is an integer, are designated as prioritized PDCP PDUs and PDCP PDUs with a PDCP SN unequal to 4n are designated as unprioritized PDCP PDUs; for Link <NUM>, PDCP PDUs with a PDCP SN equal to (4n+<NUM>) or (4n+<NUM>) are designated as prioritized PDCP PDUs and PDCP PDUs with a PDCP SN unequal to (4n+<NUM>) and (4n+<NUM>) are designated as unprioritized PDCP PDUs; and for Link <NUM>, PDCP PDUs with a PDCP SN equal to (4n+<NUM>) are designated as prioritized PDCP PDUs and PDCP PDUs with a PDCP SN unequal to (4n+<NUM>) are designated as unprioritized PDCP PDUs. In other words, if Priority(X, R) represents the priority values of a stream of PDCP PDUs for radio link R, where X represents a vector of the PDCP SNs associated with the stream of PDCP PDUs, and R is the index of a radio link over which the stream of PDCP PDUs are to be transmitted, for the example described above, then the Priority(X, R) values can be determined as the following: <MAT> <MAT> <MAT> where mod represents the modulo operation, OR represents the logical or operation, and '==' represents the evaluation of an equality between the number on the left and the number on the right, and produces logic value <NUM> when the equality is true and logic value <NUM> when the equality is false. A Priority(X, R) value equal to <NUM> means that the associated PDCP PDU is a prioritized PDCP PDU for radio link R. A Priority(X, R) value equal to <NUM> means that the associated PDCP PDU is an unprioritized PDCP PDU for radio link R. A reversal of the assignment of the <NUM> and <NUM> values is possible. Then, the dual buffers associated with each radio link can sort out incoming stream of PDCP PDUs based on the Priority(X, R) values determined for the respective radio link, i.e., PDCP PDUs with Priority(X, R) value equal to <NUM> are to be stored in the prioritized buffer for radio link R, and PDCP PDUs with Priority(X, R) value equal to <NUM> are to be stored in the unprioritized buffer for radio link R.

In an embodiment, when multiple radio links are configured for PDCP duplication for uplink transmissions (which are transmissions in the direction from the UE to the network), the network may configure the UE with the formulas that are unique for different radio links and are to be used by the UE for computing the Priority(X, R) values of the stream of PDCP PDUs for each of the different radio links, and based thereon, placing the PDCP PDUs in the prioritized buffer or unprioritized buffer associated with the respective radio link. Such formulas may be modified whenever the network adds an additional secondary radio link to or removes a secondary radio link from the PDCP duplication configuration. Information of the formulas or modifications to the formulas may be conveyed from the network to the UE via radio resource control (RRC) signaling, such as a RRCReconfiguration message.

In an embodiment, when multiple radio links are configured for PDCP duplication for downlink transmissions (which are transmissions in the direction from the network to the UE), the transmitting PDCP entity, if the re-sequence block is located in the transmitting PDCP entity as shown in <FIG>, or the transmitting RLC entities, if the re-sequence block is located in the transmitting RLC entities as shown in <FIG> and <FIG>, may be configured with the formulas that are unique for different radio links and are to be used for computing the Priority(X, R) values of the stream of PDCP PDUs for each of the different radio links, and based thereon, placing the PDCP PDUs in the prioritized buffer or unprioritized buffer associated with the respective radio link.

In the embodiment where the PDCP duplication is configured for downlink transmissions, as described previously, when PDCP duplication is provided using dual connectivity (DC) (i.e., through differently located transmitting nodes), the transmitting PDCP entity and some underlying RLC entity(s) are in the MN, while other underlying RLC entity(s) are in the secondary node. In a centralized unit - distributed unit (CU-DU) split network, the transmitting PDCP entity may be centrally located in a gNB-CU, while the different underlying transmitting RLC entities may be placed in differently located gNB-DUs. In these situations, adding the function for executing a unique formula in each of the multiple transmitting RLC entities in order to sort out the priority of PDCP PDUs for the each transmitting RLC entity requires the MN and the secondary node or all gNB-DUs have the same interpretation and execution of the provided formulas. Hence, the demand for the standardization efforts and implementation efforts for ensuring interoperability between the MN and secondary node or among the gNB-CU and gNB-DUs, which may be manufactured by different vendors, is increased. On the other hand, adding the multiple dual buffers in the transmitting PDCP entity, although easing the interoperability requirement between the MN and secondary node or among the gNB-CU and gNB-DUs, increases the memory requirement (as compared to using the dual buffers to replace the conventional transmission buffer in the RLC header generation and transmission buffer block in the multiple transmitting RLC entities).

Therefore, in accordance with a third example architecture embodiment, some functions of the re-sequence block, such as determining the Priority(X, R) value of each PDCP PDU for each of the multiple radio links, are performed at the transmitting PDCP entity, as illustrated in <FIG>, while some other functions of the re-sequence block, such as storing the PDCP PDU into one of the dual buffers in accordance with the determined Priority(X, R) value, are performed at the transmitting RLC entities, for example, as illustrated in <FIG> and <FIG>, or as previously discussed, with the dual buffers replacing the conventional transmission buffer in the RLC header generation and transmission buffer block and with the RLC header being generated for (an RLC SN being assigned to) a PDCP PDU after the PDCP PDU is read out from one of the dual buffers for transmission.

More specifically, in accordance with a third example PDCP duplication scheme, as the Routing/Duplication block in the transmitting PDCP entity duplicates the stream of PDCP PDUs for the multiple radio links, the transmitting PDCP entity also determines the Priority(X, R) value of each PDCP PDU for each of the multiple radio links. For example, the Priority(X, R) value may be determined based on the PDCP SN of the PDCP PDU (as X), the index of the radio link (as R), and the formulas that the transmitting PDCP entity is configured with. Then, the transmitting PDCP entity conveys each PDCP PDU of the stream of PDCP PDUs to each underlying RLC entity, along with an indication of the Priority(X,R) value determined for the each PDCP PDU for the radio link associated with the each underlying RLC entity. Then, each underlying RLC entity stores each PDCP PDU of the stream of PDCP PDUs in its prioritized or unprioritized buffer in accordance with the Priority(X, R) value conveyed and associated with the each PDCP PDU. When a transmission opportunity presents at the lower layers associated with an RLC entity, as a general guideline, the PDCP PDUs stored in the prioritized buffer of that RLC entity may be first delivered, in sequence, along with the RLC headers generated for them, to the segmentation block below when the prioritized buffer isn't empty, and the PDCP PDUs stored in the unprioritized buffer of that RLC entity may be delivered, in sequence, along with the RLC headers generated for them, to the segmentation block below when the prioritized buffer is empty.

<FIG> and <FIG> illustrate a diagram <NUM> of the transmission of an example stream of packets (PDCP PDUs) being transmitted over three radio links (shown as Link <NUM><NUM>, Link <NUM><NUM>, and Link <NUM><NUM> in <FIG> and <FIG>), in accordance with the third example PDCP duplication scheme. As shown in <FIG> and <FIG>, while duplicating the stream of PDCP PDUs for the three radio links, the transmitting PDCP entity determines that a PDCP PDU with a PDCP SN equal to (3n+<NUM>), where n is an integer, is a prioritized PDCP PDU for Link <NUM><NUM> and an unprioritized PDCP PDU for Link <NUM><NUM> and Link <NUM><NUM>, and based thereon, attaches a priority indication of "P" (or value <NUM>), representing prioritized, to the copy of that PDCP PDU for Link <NUM><NUM>, and attaches a priority indication of "U" (or value zero), representing unprioritized, to the copy of that PDCP PDU for Link <NUM><NUM> and Link <NUM><NUM>. The transmitting PDCP entity also determines that a PDCP PDU with a PDCP SN equal to (3n+<NUM>) is a prioritized PDCP PDU for Link <NUM><NUM> and an unprioritized PDCP PDU for Link <NUM><NUM> and Link <NUM><NUM>, and based thereon, attaches a priority indication of "P" or "U" to the respective copy of that PDCP PDU accordingly. The transmitting PDCP entity also determines that a PDCP PDU with a PDCP SN equal to 3n is a prioritized PDCP PDU for Link <NUM><NUM> and an unprioritized PDCP PDU for Link <NUM><NUM> and Link <NUM><NUM>, and based thereon, attaches a priority indication of "P" or "U" to the respective copy of that PDCP PDU accordingly. Then, the transmitting PDCP entity conveys the stream of PDCP PDUs to each underlying RLC entity, along with the associated priority indications.

As shown in <FIG> and <FIG>, the RLC header generation and transmission buffer (labeled RLC Hdr/Bffr) block of each underlying RLC entity contains the dual buffers (prioritized buffer and unprioritized buffer), instead of the conventional transmission buffer. For example, RLC Hdr/Bffr block <NUM><NUM>, which serves Link <NUM><NUM>, contains prioritized buffer <NUM> and unprioritized buffer <NUM>; RLC Hdr/Bffr block <NUM><NUM>, which serves Link <NUM><NUM>, contains prioritized buffer <NUM> and unprioritized buffer <NUM>; and RLC Hdr/Bffr block <NUM><NUM>, which serves Link <NUM><NUM>, contains prioritized buffer <NUM> and unprioritized buffer <NUM>. The stream of PDCP PDUs obtained from the transmitting PDCP entity are sorted into prioritized buffer and unprioritized buffer of each RLC entity based on the associated priority indications provided to the each RLC entity. For example, as shown in <FIG> and <FIG>, PDCP PDU #<NUM> is sorted into prioritized buffer <NUM> for Link <NUM><NUM>, unprioritized buffer <NUM> for Link <NUM><NUM>, and unprioritized buffer <NUM> for Link <NUM><NUM>. When a transmission opportunity presents at the lower layers of Link <NUM><NUM>, Link <NUM><NUM>, or Link <NUM><NUM>, the associated dual buffers may attempt to empty its prioritized buffer before attempting to empty its unprioritized buffer. As shown in <FIG> and <FIG>, PDCP PDUs #<NUM><NUM>, #<NUM><NUM>, and #<NUM><NUM> are successfully transmitted (shown as being checked by a check mark) over Link <NUM><NUM>, Link <NUM><NUM>, and Link <NUM><NUM>, respectively, the duplicate copies of them are removed from the unprioritized buffers associated with the other radio links, respectively. For example, duplicated PDCP PDUs #<NUM><NUM> and <NUM> are removed from unprioritized buffers <NUM> and <NUM> (shown as being deleted by a deletion line), respectively, duplicated PDCP PDUs #<NUM><NUM> and <NUM> are removed from unprioritized buffers <NUM> and <NUM>, respectively, and duplicated PDCP PDUs #<NUM><NUM> and <NUM> are removed from unprioritized buffers <NUM> and <NUM>.

In the second and third example PDCP duplication schemes described above, generally speaking, data stored in a prioritized buffer are submitted for transmission before data stored in the corresponding unprioritized buffer of the same re-sequence block. However, as new data may continue to arrive from the higher layer above the transmitting PDCP entity for transmission, the newly arrived data continues to be sorted into the prioritized buffer or the unprioritized buffer of each radio link according to the respective prioritization algorithm or the respective priority indication. Therefore, it is totally possible that a prioritized buffer may not be truly empty for an extended amount of time. In this situation, if data stored in the unprioritized buffer of a first radio link needs to be transmitted because the transmission of the same data (as a prioritized data) has been attempted over a second radio link and failed, then the data may have to wait for a period that is too long to meet a latency requirement (if the data must wait until the prioritized buffer of the first radio link is completely empty), in which case, the data stored in the unprioritized buffer will lose its function as a backup to boost the overall transmission reliability.

Therefore, apparatus and methods are provided herein, which may be used to limit how long the pending transmission of a duplicated (and unprioritized) data over a radio link may be deferred if the transmission of the duplicated data hasn't yet been cancelled due to a successful transmission of the same data over another radio link. In one embodiment, if the PDCP SN of the next data to be transmitted from the prioritized buffer has exceeded the PDCP SN of the next data to be transmitted from the unprioritized buffer of the same radio link by more than a pre-specified threshold, the next data in the unprioritized buffer is to be transmitted first; otherwise, the next data in the prioritized buffer is to be transmitted first. Using the illustration in <FIG> and <FIG> as an example, if the pre-specified threshold is <NUM>, then, after PDCP PDUs #<NUM> and #<NUM> queued in prioritized buffer <NUM> are transmitted over Link <NUM><NUM>, the next PDCP PDU queued in prioritied buffer <NUM> is PDCP PDU #<NUM> (which isn't shown in <FIG> and <FIG> due to limited space). Then, when a transmission opportunity present at the lower layer of Link <NUM><NUM>, the RLC entity serving Link <NUM><NUM> determines which PDCP PDU is the first PDCP PDU currently queued in unprioritized buffer <NUM> for transmission. By that moment, if duplicated PDCP PDU #<NUM><NUM> has already been removed from unprioritized buffer <NUM>, e.g., due to the successful transmission of PDCP PDU #<NUM><NUM> over Link <NUM><NUM>, the first PDCP PDU still queued in unprioritized buffer <NUM> is a next unprioritized PDCP PDU (for Link <NUM><NUM>) having a PDCP SN greater than <NUM> (such as <NUM>, <NUM>, <NUM>, etc.). In this situation, PDCP PDU #<NUM> queued in prioritied buffer <NUM> takes priority and therefore is transmitted first. On the other hand, if duplicated PDCP PDU #<NUM><NUM> hasn't been removed from unprioritized buffer <NUM> yet, duplicated PDCP PDU #<NUM><NUM> takes priority over PDCP PDU #<NUM> queued in prioritized buffer <NUM>, because <NUM> minus <NUM> exceeds the threshold of <NUM>.

Generally speaking, the larger the pre-specified threshold (for the gap between the two PDCP SNs) is, the greater the chance to cancel an unnecessary duplicated transmission. The pre-specified threshold may be determined based on how much delay can be tolerated in successfully delivering the data over any of the multiple radio links. The longer the delay that can be tolerated, the larger the pre-specified threshold.

In another embodiment, if a negative acknowledgement (NACK) of a data transmitted (as a prioritized data) over a first radio link has been explicitly received from the data recipient, then a copy of the same data queued in the unprioritized buffer of a second radio link may take a priority over data in the prioritized buffer of the second radio link and therefore be the next to be transmitted over the second radio link. Examples of the explicit NACK received include a HARQ NACK, an ARQ NACK, and for <NUM> NR UL transmissions, an explicit retransmission grant for a retransmission of the failed data transmission. Using the illustration in <FIG> as an example, after PDCP PDU #<NUM><NUM> is unsuccessfully transmitted over Link <NUM><NUM>, e.g., after a HARQ NACK or an RLC NACK (which is an ARQ NACK at the RLC sublayer) indicating a failure in decoding PDCP PDU #<NUM><NUM>, or for UL transmission, a retransmission grant has been received from the data recipient, then when a next transmission opportunity presents at the lower layers of Link <NUM><NUM>, duplicated PDCP PDU #<NUM><NUM> queued in unprioritized buffer <NUM> takes priority over a next PDCP PDU queued in prioritized buffer <NUM> for transmission and therefore is transmitted before the next PDCP PDU queued in prioritized buffer <NUM>, instead of waiting until the last prioritized PDCP PDU for Link <NUM><NUM> (e.g., PDCP PDU #2N) is cleared, as shown in <FIG>.

The second example PDCP duplication scheme, more specifically, the variant of it with the re-sequence blocks being located in the RLC entities, and the third example PDCP duplication scheme described previously have an advantage of reducing memory requirement by replacing the conventional transmission buffer in the RLC header generation and transmission buffer block in the underlying RLC entities with the dual buffers. On the other hand, the second example PDCP duplication scheme, more specifically, the variant of the second example PDCP duplication scheme with the re-sequence blocks being located in the transmitting PDCP entity, and the third example PDCP duplication scheme have an advantage in that the priority values of the PDCP PDUs for the multiple radio links are determined centrally by the transmitting PDCP entity.

In the situation of the second example PDCP duplication scheme with the re-sequence blocks being located in the transmitting PDCP entity, the underlying RLC entities may be unaware that the order of the PDCP PDUs has been altered and they each submit PDCP PDUs to the lower layers for transmission in the order that the PDCP PDUs are provided to them. In the situation of the third example PDCP duplication scheme, the underlying RLC entities each receives a PDCP PDU along with a priority value of the PDCP PDU that is indicated to them so that they can store the PDCP PDU in the corresponding buffer in accordance with the priority value. In both situations, the underlying RLC entities don't need to know how the transmitting PDCP entity determines the priority values of the PDCP PDUs or what formulas are being used and the transmitting PDCP entity bears the responsibility for ensuring the prioritized PDCP PDUs designated for different radio links are mutually exclusive in order to minimize the race condition among the different radio links, and thereby making it easier to achieve interoperability between the MN and secondary node or among the gNB-CU and gNB-DUs, which may be manufactured by different vendors.

On the UE side, conveying a PDCP PDU along with an indication of the associated priority value from the transmitting PDCP entity to each underlying RLC entity can be readily handled in implementation of internal communications between the PDCP entity and the underlying RLC entities, because they normally are co-located within the same UE device. However, on the network side, when the transmitting PDCP entity and the underlying RLC entities aren't co-located or manufactured by a same vendor, e.g., being in gNB-CU and gNB-DUs, respectively, or being in the MN and secondary node, respectively, the indicating of the priority values needs to be standardized in order to facilitate interoperability between these network equipments. For example, a message referred to as a GPRS Tunnelling Protocol (GTP) encapsulated user Plane Data Unit (G-PDU) message, as specified in 3GPP TS <NUM>, can currently be used for conveying a PDCP PDU across the interface between the MN and the secondary node (which interface is referred to as the Xn interface) or between the gNB-CU and gNB-DUs (which interface is referred to as the F1 interface), wherein the PDCP PDU is carried in a Transport PDU (T-PDU) field in the G-PDU message.

Therefore, according to an example embodiment, a currently available Spare bit (i.e., a reserved bit) in a GTP user (GTP-U) Extension Header in the G-PDU message can be converted and used as the priority indication bit, with a value <NUM> in this bit indicating the associated PDCP PDU is a prioritized PDCP PDU and a value <NUM> (zero) in this bit indicating the associated PDCP PDU is an unprioritized PDCP PDU. A reversal of the value meanings is possible. For example, the GTP-U Extension Header contains an NR RAN Container, as specified in TS <NUM>, and the NR RAN Container contains a DL USER DATA (PDU Type <NUM>) frame, as specified in TS <NUM>, and a currently available Spare bit in the DL USER DATA (PDU Type <NUM>) frame, as specified in TS <NUM> v16. <NUM>, can be converted to and specified as the priority indication bit.

According to example embodiments, methods and apparatus are also provided for a device to transmit a status report regarding a first stream of packets received from a peer device over a plurality of radio links (i.e., the second goal described before), the status report being transmitted in order to assist the peer device in preventing duplicated copies of the first stream of packets from being transmitted to the device (i.e., the first goal described before). The device may be a UE, an eNB, a gNB, or a gNB-CU. The device receives a plurality of second streams of packets over the plurality of radio links, each second stream of packets being a subset of the first stream of packets. The device detects duplicated packets among the plurality of the second streams of packets, and based thereon, forms the first stream of packets comprising the union of packets in the plurality of the second streams of packets by removing the duplicated packets detected and reordering the remaining packets in the union. Then, the device transmits a status report to the peer device, the status report comprising information associated with packets among the first stream of packets and their status as received. The status report may further include information associated with packets not among the first stream of packets and their status of not received (but still expected). The current RLC Status PDU feedback scheme, as described before, provides for the reception status of packets received within a single radio link. Furthermore, the RLC Status PDU is available only for AM RLC, not for UM RLC. Therefore, the new status report for PDCP duplication should be carried out above the RLC sublayer, i.e., at the PDCP sublayer.

In accordance with an example embodiment, the status report has the same format and content as the conventional PDCP Status Report, which is a PDCP Control PDU specified in 3GPP TS <NUM>. Rules are added for triggering transmissions of the PDCP Status Report when PDCP duplication is configured. <FIG> illustrates a diagram <NUM> of the format and content of the PDCP Status Report. As shown in <FIG>, the PDCP Status Report includes a First Missing COUNT (FMC) field <NUM>, which indicates the COUNT value of the first missing PDCP SDU that hasn't been delivered to the higher layer yet but is still expected, and optionally a Bitmap field <NUM>. The COUNT value of a PDCP SDU comprises a Hyper Frame Number (HFN) and the PDCP SN assigned to the PDCP SDU when forming the associated PDCP PDU. The HFN value is initialized to value <NUM> (zero). On a transmitting PDCP entity, when the PDCP SN wrap-around (carry-over) occurs during PDCP SN assignment, the HFN is incremented by <NUM> and then is used in forming the COUNT values associated with that PDCP SN and those PDCP SNs assigned thereafter until the PDCP SN wrap-around occurs again. A receiving PDCP entity keeps tracking the HFN value by monitoring the PDCP SN wrap-around events among the PDCP PDUs received, and then reconstructs the COUNT value of a received PDCP SDU by concatenating the HFN value and the PDCP SN associated with the received PDCP SDU. Bitmap field <NUM> is included in the PDCP Status Report when at least one PDCP SDU is received but can't be delivered to the higher layer due to the missing PDCP SDU(s) ahead of it. Each bit in the Bitmap field indicates a status of a PDCP SDU with a COUNT value greater than the FMC value, with the first bit in the Bitmap corresponds to the first PDCP SDU after the first missing PDCP SDU. A value <NUM> in a bit in the Bitmap field indicates that the corresponding PDCP SDU hasn't been received, and a value <NUM> in the bit indicates that the corresponding PDCP SDU has been received successfully.

Therefore, by transmitting the PDCP Status Report to the data-transmitting PDCP entity, the data-receiving PDCP entity informs the transmitting PDCP entity that any PDCP SDUs with a COUNT value less than the FMC value have been delivered to the higher layer (hence has been received), and if Bitmap field <NUM> is present in the PDCP Status Report, any PDCP SDUs with a corresponding bit in the Bitmap field being set to value <NUM> have been received. Therefore, any duplicated copies of these received PDCP SDUs, or PDCP PDUs or RLC PDUs that are generated from these PDCP SDUs, if not transmitted yet, can be discarded by the data-transmitting device.

Currently, the motivation to transmit a PDCP Status Report is to indicate, during a mobility event such as a handover or radio link failure recovery event, packets not received but still expected, so that the lost packets can be retransmitted to ensure low packet loss due to the mobility event. Therefore, the PDCP Status Report can currently be used on an AM DRB, but not on a UM DRB or an SRB. This is because AM DRBs tend to be used for data that require low packet loss rate during mobility events, and retransmission is a solution for such applications. However, for UM DRBs, any packet loss during mobility events is currently either tolerated or mitigated through other means such as a human repeating a voice. For SRBs, data being transmitted over an SRB are control messages, which cannot be lost during a mobility event in the first place, otherwise the mobility event cannot be successfully completed. On the other hand, for PDCP duplication, the motivation to transmit a PDCP Status Report is to indicate packets already received so that a duplicate of the received packets can be discarded without the transmission taking place. Therefore, in accordance with an example embodiment of the present disclosure, the PDCP Status Report can be used on UM DRBs and SRBs (as well as AM DRBs) that are configured with PDCP duplication.

According to the current 3GPP specifications, a transmission of the PDCP Status Report by the PDCP entity can be triggered only by RRC signaling or an RRC event. There are no specifications nor motivations for the PDCP entity to initiate a transmission of the PDCP Status Report on its own. However, in accordance with an example embodiment of the present disclosure, a transmission of the PDCP Status Report can be initiated by the data-receiving PDCP entity without being requested by the associated RRC entities (including the peer's RRC entity) above it or any event (such as a mobility event) occurring at the RRC layer. For example, in the first example PDCP duplication scheme described above and illustrated in <FIG>, when the PDCP SNs of two PDCP PDUs that are most recently received over Link <NUM> and Link <NUM><NUM>, respectively, are approaching one another (e.g., a gap between these two PDCP SNs is below a specific threshold), the data-receiving PDCP entity can determine, on its own, that it is the time to send a PDCP Status Report to assist the data-transmitting PDCP entity with cancelling duplicated transmissions of data that have been successfully transmitted, otherwise, the unnecessary duplicated transmissions may occur. In accordance with an alternative example embodiment, the PDCP Status Report may be transmitted by the data-receiving PDCP entity in response to receiving a request from the data-transmitting PDCP entity of the peer device, the data-transmitting PDCP entity initiating the request without itself being requested by the associated RRC entities (including the peer's RRC entity) above it or any event occurring at the RRC layer. The request to solicit a PDCP Status Report may be conveyed in a new PDCP Control PDU referred to as the PDCP Status Request, e.g., with the PDU type being value <NUM>.

Alternatively, the request to solicit a PDCP Status Report may be conveyed in a new Poll bit in the PDCP header of a PDCP PDU carrying data (which is also referred to as a PDCP Data PDU) from the data-transmitting PDCP entity to the data-receiving PDCP entity. The new Poll bit may take the place of one of the currently reserved R bits in the PDCP header of the PDCP (Data) PDU. For example, when the data-transmitting PDCP entity is about to transmit the last PDCP PDU available in its buffer(s), the data-transmitting PDCP entity may set the Poll bit in the PDCP header of the last PDCP PDU to value <NUM> to request its peer entity (i.e., the data-receiving PDCP entity) to send back a PDCP Status Report. An alternate definition of the value requesting the peer entity to send back the PDCP Status Report is possible.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a device. Operations <NUM> may be indicative of operations occurring in a device as the device transmits a stream of packets with packet duplication over a plurality of communication links. The device may be a UE or a network node such as an eNB or a gNB.

Operations <NUM> begin with the device storing the stream of packets in each of a first and second buffers (step <NUM>), the first and second buffers being respectively associated with a first and second radio links between the device and a peer device, the second radio link being different from the first radio link. The storing may occur after the stream of the packets is duplicated for the first and second radio links. The device begins submitting packets stored in the first buffer for transmission in a first order over the first radio link and submitting packets stored in the second buffer for transmission in a second order over the second radio link (step <NUM>), the second order being different from the first order. For example, the first order is FIFO and the second order is LIFO, the first buffer being a FIFO buffer and the second buffer being a LIFO buffer. For another example, the stream of packets are partitioned into a first set of packets and a second set of packets, the first order is to transmit the first set of packets before transmitting the second set of packets, and the second order is to transmit the second set of packets before transmitting the first set of packets.

While submitting the packets stored in the first and second buffers for transmission over the first and the second radio links, respectively, the device determines whether it has received an indication of a packet of the stream of packets having been received by the peer device (step <NUM>). If the device determines that it has received the indication of a packet of the stream of packets having been received by the peer device, the device discards the packet (as indicated by the indication) from the first and second buffers (step <NUM>). In other words, if the device has received an indication of a packet (or packets) of the stream of packets having been received by the peer device, the packet (or packets) have been received by the peer device, and the device discards the packet (or packets) indicated by the indication from the first and second buffers. After step <NUM> or if the device determines that it has not received an indication of a packet of the stream of packets having been received by the peer device (hence being successfully transmitted) in step <NUM>, the device further determines whether the first and second buffers are empty (step <NUM>). If no, the device goes back to step <NUM> to continue to transmit remaining packets in the first and second buffers in the respective orders over the first and second radio links, respectively. If the first and second buffers are empty, operations <NUM> may end.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in a PDCP entity of a device. Operations <NUM> may be indicative of operations occurring in a PDCP entity of a device as the device uses the PDCP entity for submitting a stream of packets to a plurality of RLC entities for transmission over a plurality of radio links. The device may be a UE or a network node such as an eNB, a gNB, or a gNB-CU.

Operations <NUM> begin with the PDCP entity of the device generating a stream of packets (step <NUM>). For example, the stream of packets is a stream of PDCP PDUs. The stream of PDCP PDUs is generated from a stream of PDCP SDUs that is obtained from a higher layer entity above the PDCP entity of the device. The higher layer entity may be an RRC entity, a SDAP entity, or an IP entity. The PDCP entity of the device may assign a PDCP SN to each packet of the stream of packets in an incremental manner. Then, the PDCP entity of the device determines a priority value for each packet of the stream of packets for each RLC entity of the plurality of RLC entities (step <NUM>). Each priority value indicates that the associated packet is a prioritized packet or an unprioritized packet for the associated RLC entity. For example, the PDCP entity may determine a priority value for a packet based on a PDCP SN assigned to the packet and a formula that is unique for the each RLC entity, wherein the PDCP SN is an input to the formula. The uniqueness of the formula for the each RLC entity may be achieved by using a unique index number associated with a radio link (and hence unique for the RLC entity associated with the radio link) as an input to the formula.

The PDCP entity of the device conveys each packet of the stream of packets to each RLC entity of the plurality of RLC entities, respectively, among with the priority value of the each packet determined for the each RLC entity (step <NUM>). For example, the packet and the associated priority value may be conveyed to an RLC entity located within the device through internal cross-layer communication between the PDCP entity and the RLC entity. For another example, the packet and associated priority value may be conveyed to an RLC entity that isn't co-located with the PDCP entity using a G-PDU message over the Xn interface between the device (which is an MN hosting the PDCP entity) and a secondary node hosting the RLC entity, or over the F1 interface between the device (which is a gNB-CU hosting the PDCP entity) and a gNB-DU hosting the RLC entity, the packet being carried in the T-PDU field of the G-PDU message and the priority value being carried in a priority indication field in an GTP-U Extension Header of the G-PDU message.

The PDCP entity of the device determines whether it has received an indication of a packet (or packets) of the stream of packets having been received by a peer device (step <NUM>). If no, the PDCP entity of the device goes back to step <NUM>. If yes, the PDCP entity of the device indicates to the plurality of RLC entities to discard the packet (or packets) (step <NUM>). The PDCP entity of the device further determines whether all packets of the stream of packets have been received by the peer device (step <NUM>). If no, the PDCP entity of the device goes back to step <NUM>. If yes, operations <NUM> may end.

<FIG> illustrates a flow diagram of example operations <NUM> occurring in an RLC entity of a device. Operations <NUM> may be indicative of operations occurring in an RLC entity of a device, as the device uses the RLC entity for transmitting a stream of packets over one radio link of a plurality of radio links. The device may be a UE or a network node such as an eNB, a gNB, or a gNB-DU.

Operations <NUM> begin with the RLC entity of the device obtaining a stream of packets along with priority values associated with the stream of packets, respectively (step <NUM>). For example, the stream of packets is a stream of PDCP PDUs obtained from a PDCP entity that the RLC entity is associated with. In one example, the PDCP entity is located within the device, in which case the stream of packets along with the associated priority values are obtained from the PDCP entity through internal cross-layer communication between the PDCP entity and the RLC entity. In another example, the PDCP entity isn't located in the device, in which case each packet of the stream of packets along with the associated priority value is obtained from the PDCP entity using a G-PDU message over the Xn interface between the device (which is a secondary node hosting the RLC entity) and an MN hosting the PDCP entity, or over the F1 interface between the device (which is a gNB-DU hosting the RLC entity) and a gNB-CU hosting the PDCP entity, the packet being carried in the T-PDU field of the G-PDU message and the priority value being carried in a priority indication field in an GTP-U Extension Header of the G-PDU message. The RLC entity of the device stores each packet of the stream of packets in a prioritized buffer or an unprioritized buffer in accordance with the priority value associated with the each packet (step <NUM>). For example, the RLC entity of the device stores a packet with a priority value of <NUM> (for prioritized) in the prioritized buffer and a packet with a priority value of <NUM> (for unprioritized) in the unprioritized buffer.

The RLC entity of the device determines whether it has received an indication of a packet of the stream of packets having been received by a peer device (step <NUM>). For example, when the RLC entity and a second RLC entity that is serving a second radio link of the plurality of radio links are not co-located within the same device, the second RLC entity, in response to receipt of a positive acknowledgment from a peer device, may send a second indication indicating that the packet of the stream of packets has been received by the peer device to the PDCP entity (which both the first and the second RLC entities are associated with). The PDCP entity, in response to receipt of the second indication from the second RLC entity, sends the indication to the RLC entity, where the positive acknowledgement may comprise an HARQ ACK or an RLC ACK associated with the transmission of the packet over the second radio link, or for <NUM> NR UL transmissions, a timer expired at the transmitter, the timer being started when the packet is transmitted over the second radio link and to be stopped and reset if a retransmission scheduling grant for a retransmission of the packet over the second radio link is received before the timer expires. For another example, when the RLC entity and a second RLC entity serving a second radio link of the plurality of radio links are co-located within the same device, the indication may be exchanged directly from the second RLC entity to the RLC entity instead of having to go through the transmitting PDCP entity. In this situation, the RLC entity may receive the indication from the second RLC entity, where the second RLC entity provides the indication based on the receipt of a positive acknowledgement that the second RLC entity received from a peer device.

If the RLC entity of the device determines that it has not received the indication in step <NUM>, the RLC entity of the device goes to step <NUM>. If the RLC entity of the device determines that it has received the indication in step <NUM>, the RLC entity of the device discards the packet from the prioritized buffer or the unprioritized buffer, whichever one has the packet queued for transmission (step <NUM>).

The RLC entity of the device determines whether a transmission opportunity is present at its associated lower layer (MAC and PHY) entities (step <NUM>). If no, the RLC entity of the device goes back to step <NUM>. If yes, the RLC entity of the device further determines whether its prioritized buffer is empty (step <NUM>). If the prioritized buffer isn't empty, the RLC entity of the device delivers a next packet queued in its prioritized buffer to the lower layer entities for transmission over the one radio link of the plurality of radio links (step <NUM>). If the prioritized buffer is empty, the RLC entity of the device further determines whether both its prioritized and unprioritized buffers are empty (step <NUM>). If no, the RLC entity of the device delivers a next packet queued in its unprioritized buffer to the lower layer entities for transmission over the one radio link of the plurality of radio links (step <NUM>). The RLC entity of the device goes back to step <NUM>. If the RLC entity of the device determines that both buffers are empty in step <NUM>, operations <NUM> may end.

As an alternative to steps <NUM>-<NUM> illustrated in <FIG>, when arriving at step <NUM>, the RLC entity of the device determines whether the PDCP SN of the next data to be transmitted from its prioritized buffer has exceeded the PDCP SN of the next data to be transmitted from its unprioritized buffer by more than a pre-specified threshold. If yes, the RLC entity submits the next data in its unprioritized buffer to the lower layers for a transmission first. If no, the RLC entity submits the next data in its prioritized buffer to the lower layers for a transmission first. When both buffers are empty, the alternative operations may end.

As a second alternative to steps <NUM>-<NUM> illustrated in <FIG>, when arriving at step <NUM>, the RLC entity of the device determines whether there is a data in its unprioritized buffer, a duplicate of which data has been transmitted by another RLC entity over another radio link of the plurality of radio links but that transmission has failed. If yes, the RLC entity submits that data to the lower layers for a transmission first. If no, the RLC entity submits the next data in its prioritized buffer to the lower layers for a transmission first. When both buffers are empty, the second alternative operations may end.

<FIG> illustrates a flow diagram of example operations occurring in a device. Operations <NUM> may be indicative of operations occurring in a device, as the device receives streams of packets with packet duplication over a plurality of radio links. The device may be a UE or a network node such as an eNB, a gNB, or a gNB-CU.

Operations <NUM> begin with the device receiving, from a peer device, a first stream of packets over a first radio link of the plurality of radio links and a second stream of packets over a second radio link of the plurality of radio links (step <NUM>). For example, the stream of packets is a stream of PDCP PDUs. The device detects for duplicated packet(s) between the first and second stream of packets (step <NUM>). For example, the device may detect a duplicated packet based on the PDCP SNs respectively associated with a first packet of the first stream of packets and a second packet of the second stream of packets being equal, and based thereon, determines that the second packet is a duplicated packet. For another example, if the COUNT value associated with a third packet of the first or second stream of packets is less than a FMC value that has previously been reported by the data recipient, the device determines that the third packet has been delivered to its higher layer previously, and based thereon, determines that the third packet is a duplicated packet.

The device forms a third stream of packets as the union of the first and second streams of packets by removing the duplicated packets detected and re-ordering the remaining packets in the union, e.g., in accordance with the PDCP SNs associated with the remaining packets (step <NUM>). The device transmits information of the third stream of packets received (step <NUM>). For example, the device may transmit a control message (e.g., a PDCP Status Report) to the peer device, the control message including information of the third stream of packets and their respective status as received. The control message may further include information associated with a fourth stream of packets and their respective status as not received. The device may transmit the control message when the device determines that a criterion is met. For example, if the PDCP PDUs received over the first radio link are transmitted in the FIFO manner and the PDCP PDUs received over the second radio link are transmitted in the LIFO manner, as illustrated in <FIG>, then when the gap between the PDCP SNs of two most recently received PDCP PDUs over the first and second radio links, respectively, is less than a specific threshold, it is appropriate for the device to send the control message to enable the peer device to cancel any unnecessary duplicated transmissions that are still pending. For another example, if the PDCP PDUs are transmitted using the dual buffers over both the first and the second radio links, as illustrated in <FIG>, then when the gap between the PDCP SNs of two most recently received PDCP PDUs over the first and second radio links, respectively, is more than a specific threshold, it is appropriate for the device to send the control message to enable the peer device to cancel any unnecessary duplicated transmissions that are still pending. The device may transmit the control message when the device receives an explicit request from the peer device, e.g., a Poll bit in the PDCP header of a PDCP PDU received from the peer device being set to <NUM>. Then, operations <NUM> may end.

<FIG> illustrates an example communication system <NUM>. In general, the system <NUM> enables multiple wireless or wired users to transmit and receive data and other content. The system <NUM> may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

In this example, the communication system <NUM> includes electronic devices (ED) 1310a-1310c, radio access networks (RANs) 1320a-1320b, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>. While certain numbers of these components or elements are shown in <FIG>, any number of these components or elements may be included in the system <NUM>.

The EDs 1310a-1310c are configured to operate or communicate in the system <NUM>. For example, the EDs 1310a-1310c are configured to transmit or receive via wireless or wired communication channels. Each ED 1310a-1310c represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device.

The RANs 1320a-1320b here include base stations 1370a-1370b, respectively. Each base station 1370a-1370b is configured to wirelessly interface with one or more of the EDs 1310a-1310c to enable access to the core network <NUM>, the PSTN <NUM>, the Internet <NUM>, or the other networks <NUM>. For example, the base stations 1370a-1370b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNB), a Next Generation (NG) NodeB (gNB), a gNB centralized unit (gNB-CU), a gNB distributed unit (gNB-DU), a Home NodeB, a Home eNodeB, a site controller, an access point (AP), or a wireless router. The EDs 1310a-1310c are configured to interface and communicate with the Internet <NUM> and may access the core network <NUM>, the PSTN <NUM>, or the other networks <NUM>.

In the embodiment shown in <FIG>, the base station 1370a forms part of the RAN 1320a, which may include other base stations, elements, or devices. Also, the base station 1370b forms part of the RAN 1320b, which may include other base stations, elements, or devices. Each base station 1370a-1370b operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a"cell. " In some embodiments, multiple-input multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

The base stations 1370a-1370b communicate with one or more of the EDs 1310a-1310c over one or more air interfaces <NUM> using wireless communication links. The air interfaces <NUM> may utilize any suitable radio access technology.

It is contemplated that the system <NUM> may use multiple channel access functionality, including such schemes as described above. In particular embodiments, the base stations and EDs implement <NUM> New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may be utilized.

The RANs 1320a-1320b are in communication with the core network <NUM> to provide the EDs 1310a-1310c with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs 1320a-1320b or the core network <NUM> may be in direct or indirect communication with one or more other RANs (not shown). The core network <NUM> may also serve as a gateway access for other networks (such as the PSTN <NUM>, the Internet <NUM>, and the other networks <NUM>). In addition, some or all of the EDs 1310a-1310c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet <NUM>.

<FIG> and <FIG> illustrate example devices that may implement the methods and teachings according to this disclosure. In particular, <FIG> illustrates an example ED <NUM>, and.

<FIG> illustrates an example base station <NUM>.

The ED <NUM> also includes at least one transceiver <NUM>. The transceiver <NUM> is configured to modulate data or other content for transmission by at least one antenna or NIC (Network Interface Controller) <NUM>. The transceiver <NUM> is also configured to demodulate data or other content received by the at least one antenna <NUM>. Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission or processing signals received wirelessly or by wire. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers <NUM> could be used in the ED <NUM>, and one or multiple antennas <NUM> could be used in the ED <NUM>. Although shown as a single functional unit, a transceiver <NUM> could also be implemented using at least one transmitter and at least one separate receiver.

The ED <NUM> further includes one or more input/output devices <NUM> or interfaces (such as a wired interface to the Internet <NUM>). The input/output devices <NUM> facilitate interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

In addition, the ED <NUM> includes at least one memory <NUM>. The memory <NUM> stores instructions and data used, generated, or collected by the ED <NUM>. For example, the memory <NUM> could store software or firmware instructions executed by the processing unit(s) <NUM> and data used to reduce or eliminate interference in incoming signals. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like.

Each transceiver <NUM> includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver <NUM> further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver <NUM>, a transmitter and a receiver could be separate components. Each antenna <NUM> includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna <NUM> is shown here as being coupled to the transceiver <NUM>, one or more antennas <NUM> could be coupled to the transceiver(s) <NUM>, allowing separate antennas <NUM> to be coupled to the transmitter and the receiver if equipped as separate components. Each memory <NUM> includes any suitable volatile or non-volatile storage and retrieval device(s). Each input/output device <NUM> facilitates interaction with a user or other devices (network communications) in the network. Each input/output device <NUM> includes any suitable structure for providing information to or receiving/providing information from a user, including network interface communications.

<FIG> is a block diagram of a computing system <NUM> that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system <NUM> includes a processing unit <NUM>. The processing unit includes a central processing unit (CPU) <NUM>, memory <NUM>, and may further include a mass storage device <NUM>, a video adapter <NUM>, and an I/O interface <NUM> connected to a bus <NUM>.

The video adapter <NUM> and the I/O interface <NUM> provide interfaces to couple external input and output devices to the processing unit <NUM>. As illustrated, examples of input and output devices include a display <NUM> coupled to the video adapter <NUM> and a mouse, keyboard, or printer <NUM> coupled to the I/O interface <NUM>. Other devices may be coupled to the processing unit <NUM>, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

The processing unit <NUM> also includes one or more network interfaces <NUM>, which may comprise wired links, such as an Ethernet cable, or wireless links to access nodes or different networks. The network interfaces <NUM> allow the processing unit <NUM> to communicate with remote units via the networks. For example, the network interfaces <NUM> may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit <NUM> is coupled to a local-area network <NUM> or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

It should be appreciated that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. For example, a signal may be transmitted by a transmitting unit or a transmitting module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by a storing unit or module, a discarding unit or module, a partitioning unit or module, an identifying unit or module, a detecting unit or module, or a conveying unit or module. The respective units or modules may be hardware, software, or a combination thereof. For instance, one or more of the units or modules may be an integrated circuit, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

Claim 1:
A method implemented by a device (<NUM>), the method comprising:
submitting, by the device (<NUM>), a stream of packets to lower layers associated with a first communication link between the device (<NUM>) and a peer device for transmissions in a first order over the first communication link;
submitting, by the device (<NUM>), the stream of packets to lower layers associated with a second communication link between the device (<NUM>) and the peer device for transmissions in a second order over the second communication link, the second order being different from the first order, and the second communication link being different from the first communication link; and
determining, by the device (<NUM>), receipt of an indication indicating one or more packets of the stream of packets being successfully transmitted over the second communication link while submitting the stream of packets for the transmissions over the first and second communication links, and based thereon, causing the one or more packets to be discarded from a first transmission buffer associated with the first communication link; characterized in that the method
further comprises:
determining, by the device (<NUM>), a first set of packets from the stream of packets as prioritized packets for the first communication link and unprioritized packets for the second communication link; and
determining, by the device (<NUM>), a second set of packets from the stream of packets as unprioritized packets for the first communication link and prioritized packets for the second communication link, the second set of packets being different from the first set of packets.