CN117500089A - Method and user equipment for duplicate protocol data unit discarding - Google Patents

Abstract

A method and apparatus for duplicate protocol data unit discard. The user equipment establishes a direct path and an indirect path to communicate with the network. The user equipment also establishes a radio bearer, wherein the radio bearer is mapped to a first radio link control entity and a second radio link control entity, and wherein the first radio link control entity is for communicating with the network over a direct path and the second radio link control entity is for communicating with the network over an indirect path. In addition, when successful delivery of the first packet data convergence protocol data unit is acknowledged by the second radio link control entity, the packet data convergence protocol entity in the user equipment and associated with the radio bearer prevents an indication to the first radio link control entity to discard the first packet data convergence protocol data unit.

Description

Method and user equipment for duplicate protocol data unit discarding

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application Ser. No. 63/394,494 filed on 8/2 and U.S. provisional patent application Ser. No. 63/396,726 filed on 10/8/2022, the disclosures of which are incorporated herein by reference in their entireties.

Technical Field

The present disclosure relates generally to wireless communication networks and, more particularly, to a method and apparatus for duplicate protocol data unit (Protocol Data Unit, PDU) discard for multipath transmission in a wireless communication system.

Background

With the rapid increase in demand for large amounts of data to and from mobile communication devices, conventional mobile voice communication networks evolve into networks that communicate with internet protocol (Internet Protocol, IP) data packets. This IP packet communication may provide voice over IP, multimedia, multicast, and on-demand communication services to users of mobile communication devices.

An exemplary network structure is an evolved universal terrestrial radio access network (Evolved Universal Terrestrial Radio Access Network, E-UTRAN). The E-UTRAN system may provide high data throughput for implementing the above-described IP-bearing voice and multimedia services. Currently, the 3GPP standards organization is discussing new next generation (e.g., 5G) radio technologies. Thus, changes to the current body of the 3GPP standard are currently being submitted and considered to evolve and complete the 3GPP standard.

Disclosure of Invention

A method and apparatus for duplicate PDU discard. In one embodiment, a User Equipment (UE) establishes a direct path and an indirect path to communicate with a network. The UE also establishes a radio bearer, wherein the radio bearer is mapped to a first Radio Link Control (RLC) entity and a second RLC entity, and wherein the first RLC entity is for communicating with the network over the direct path and the second RLC entity is for communicating with the network over the indirect path. In addition, when successful delivery of the first Packet Data Convergence Protocol (PDCP) PDU is acknowledged by the second RLC entity, the PDCP entity in the UE and associated with the radio bearer prevents an indication to the first RLC entity to discard the first PDCP PDU.

Drawings

Fig. 1 illustrates a diagram of a wireless communication system according to an example embodiment;

fig. 2 is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an example embodiment;

FIG. 3 is a functional block diagram of a communication system according to an exemplary embodiment;

FIG. 4 is a functional block diagram of the program code of FIG. 3 according to one exemplary embodiment;

FIG. 5 is a reproduction of FIG. 4.4.1-1 of 3GPP TS 38.300V17.0.0;

FIG. 6 is a reproduction of FIG. 16.1.3-1 of 3GPP TS 38.300V17.0.0;

FIG. 7 is a reproduction of FIG. 4.2.1-1 of 3GPP TS 37.340V17.0.0.0;

fig. 8 is a reproduction of fig. 4.2.2-2 of 3GPP TS 37.340V17.0.0.0;

fig. 9 is a reproduction of fig. 4.2.2-4 of 3GPP TS 37.340V17.0.0.0;

FIG. 10 is a reproduction of FIG. 4.3.1.1-1 of 3GPP TS 37.340V17.0.0.0;

FIG. 11 is a reproduction of FIG. 4.3.2.1-1 of 3GPP TS 37.340V17.0.0.0;

fig. 12 is a reproduction of fig. 4.2.1-1 of 3GPP TS 38.323V17.0.0;

fig. 13 is a reproduction of fig. 4.2.2-1 of 3GPP TS 38.323V17.0.0;

fig. 14 is a reproduction of fig. 4.2.2-1 of 3GPP TS 38.351V17.0.0;

fig. 15 is a reproduction of fig. 4.2.2-2 of 3GPP TS 38.351V17.0.0;

fig. 16 is a reproduction of fig. 4.2.2-3 of 3GPP TS 38.351V17.0.0;

fig. 17 is a reproduction of fig. 5.5.1-1 of 3gpp TR 23.700-33V0.2.0;

fig. 18 illustrates bearer types for supporting multipath transmission in a (remote) UE according to an example embodiment;

FIG. 19 is a flowchart in accordance with an exemplary embodiment;

FIG. 20 is a flowchart in accordance with an exemplary embodiment;

FIG. 21 is a flowchart in accordance with an exemplary embodiment.

Detailed Description

The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), orthogonal Frequency Division Multiple Access (OFDMA), 3GPP long term evolution (Long Term Evolution, LTE) wireless access, 3GPP long term evolution advanced (Long Term Evolution Advanced, LTE-a), 3GPP2 ultra mobile broadband (Ultra Mobile Broadband, UMB), wiMax, 3GPP New Radio (NR), or some other modulation technique.

In particular, the exemplary wireless communication systems and apparatus described below may be designed to support one or more standards, such as those provided by a complex referred to herein as 3GPP, denominated "3 rd generation partnership project," including: TS 38.300V17.0.0, "NR; NR and NG-RAN overall description; stage 2 (version 17) "; TS 37.340V17.0.0, "E-UTRA and NR; multiple connectivity; stage 2 (version 17) "; TS 38.323V17.0.0, "NR; packet Data Convergence Protocol (PDCP) specification (release 17) "; "TS 38.351V17.1.0, NR; side link relay adaptation protocol (SRAP) specification (release 17) "; and TR 23.700-33V0.2.0, "system enhanced research on proximity-based services (ProSe) in 5G systems (5 GS); stage 2 (version 18) ". The standards and documents listed above are hereby expressly incorporated by reference in their entirety.

Fig. 1 illustrates a multiple access wireless communication system according to one embodiment of the present invention. The access network 100 (AN) includes multiple antenna groups, one including 104 and 106, another including 108 and 110, and yet another including 112 and 114. In fig. 1, only two antennas are shown for each antenna group, but more or fewer antennas may be utilized for each antenna group. An Access terminal 116 (AT) is in communication with antennas 112 and 114, where antennas 112 and 114 transmit information to Access terminal 116 over forward link 120 and receive information from Access terminal 116 over reverse link 118. An Access Terminal (AT) 122 is in communication with antennas 106 and 108, where antennas 106 and 108 transmit information to Access Terminal (AT) 122 over a forward link 126 and receive information from Access Terminal (AT) 122 over a reverse link 124. In an FDD system, communication links 118, 120, 124 and 126 may use different frequency for communication. For example, forward link 120 may use a different frequency than that used by reverse link 118.

The antennas of each group and/or the area in which they are designed to communicate are often referred to as a sector of the access network. In an embodiment, antenna groups each are designed to communicate to access terminals in a sector of the areas covered by access network 100.

In communication over forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve signal-to-noise ratio of forward links for the different access terminals 116 and 122. And, the access network using beamforming to transmit to access terminals scattered randomly through its coverage causes less interference to access terminals in neighboring cells than an access network transmitting through a single antenna to all its access terminals.

AN Access Network (AN) may be a fixed station or base station used for communicating with the terminals and may also be referred to as AN access point, a node B, a base station, AN enhanced base station, AN evolved node B (eNB), a network node, a network, or some other terminology. An Access Terminal (AT) may also be referred to as a User Equipment (UE), a wireless communication device, a terminal, an access terminal, or some other terminology.

Fig. 2 is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an Access Terminal (AT) or User Equipment (UE)) in a MIMO system 200. At the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a Transmit (TX) data processor 214.

In one embodiment, each data stream is transmitted through a respective transmit antenna. TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK or M-QAM) selected for that data stream to provide modulation symbols. Instructions executed by processor 230 may determine the data rate, coding, and modulation for each data stream.

The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 220 then applies N _T Providing the modulated symbol streams to N _T Transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. Then respectively from N _T The antennas 224a through 224t transmit N from the transmitters 222a through 222t _T And modulated signals.

At the receiver system 250, the signal is represented by N _R Each antenna 252 a-252 r receives the transmitted modulated signals and provides the signals received from each antenna 252 to a respective receiver (RCVR) 254 a-254 r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide corresponding "tapsThe "symbol stream" is received.

RX data processor 260 then proceeds to process the data from N based on a particular receiver _R The N is received and processed by a plurality of receivers 254 _R Providing N by receiving symbol streams _T The "detected" symbol streams. RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor 260 is complementary to that performed by TX MIMO processor 220 and TX data processor 214 at transmitter system 210.

The processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.

The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 238, which also receives traffic data for a number of data streams from a data source 236, modulated by a modulator 280, conditioned by transmitters 254a through 254r, and transmitted back to transmitter system 210.

At transmitter system 210, the modulated signals from receiver system 250 are received by antennas 224, conditioned by receivers 222, demodulated by a demodulator 240, and processed by a RX data processor 242 to extract the reverse link message transmitted by receiver system 250. Processor 230 then determines which pre-coding matrix to use to determine the beamforming weights and then processes the extracted message.

Turning to fig. 3, this figure shows an alternative simplified functional block diagram of a communication device in accordance with one embodiment of the present invention. As shown in fig. 3, a communication device 300 in a wireless communication system may be utilized for implementing UEs (or ATs) 116 and 122 in fig. 1 or base station (or AN) 100 in fig. 1, and the wireless communication system is preferably AN NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (central processing unit, CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 may receive signals input by a user through an input device 302 (e.g., a keyboard or keypad) and may output images and sounds through an output device 304 (e.g., a monitor or speaker). The transceiver 314 is used to receive and transmit wireless signals, pass the received signals to the control circuit 306, and wirelessly output signals generated by the control circuit 306. The AN 100 of fig. 1 may also be implemented with a communication device 300 in a wireless communication system.

Fig. 4 is a simplified block diagram of the program code 312 shown in fig. 3 according to one embodiment of the invention. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 typically performs radio resource control. Layer 2 portion 404 typically performs link control. Layer 1 portion 406 typically performs physical connections.

The 3gpp TS 38.300 specifies the user plane protocol stack, packet duplication and side chain relay for NR as follows:

4.4 radio protocol architecture

4.4.1 user plane

The lower diagram shows a protocol stack for the user plane, where SDAP, PDCP, RLC and MAC sublayer (terminating in the gNB on the network side) perform the functions listed in clause 6.

[3GPP TS 38.300V17.0.0, FIG. 4.4.1-1 entitled "user plane protocol Stack" is reproduced as FIG. 5]

[…]

16.1URLLC

[…]

16.1.3 packet replication

When duplicated for a radio bearer by RRC configuration, at least one secondary RLC entity is added to the radio bearer to handle duplicated PDCP PDUs, as depicted on figure 16.1.3-1, wherein the logical channels corresponding to the primary RLC entity are referred to as primary logical channels and the logical channels corresponding to the secondary RLC entity are referred to as secondary logical channels. All RLC entities have the same RLC mode. Thus, duplication at PDCP consists in submitting the same PDCP PDU multiple times: each active RLC entity for a radio bearer is submitted once. With multiple independent transmission paths, packet duplication thus increases reliability and reduces latency and is particularly beneficial for URLLC services.

[3GPP TS 38.300V17.0.0, FIG. 16.1.3-1 entitled "packet replication" is reproduced as FIG. 6]

Note that: PDCP control PDUs are not duplicated and are always submitted to the primary RLC entity.

When configuring duplication for DRBs, RRC also sets the state of PDCP duplication (active or inactive) at the time of (re) configuration. After configuration, the PDCP duplication status may then be dynamically controlled by means of MAC control elements in the DC, the UE applying MAC CE commands regardless of its origin (MCG or SCG). When replication is configured for SRBs, the state is always active and cannot be dynamically controlled. The RRC also sets the state of each of them (i.e., activates or deactivates) when configuring duplicates for DRBs with more than one secondary RLC entity. The MAC CE may then be used to dynamically control whether each of the configured secondary RLC entities for the DRB should be activated or deactivated, i.e. which of the RLC entities should be used for duplicate transmissions. The primary RLC entity cannot be deactivated. When the duplicate is deactivated for a DRB, all secondary RLC entities associated with this DRB are deactivated. When the secondary RLC entity is deactivated, it does not re-establish, does not empty the HARQ buffer, and the transmitting PDCP entity should indicate to the secondary RLC entity to discard all duplicate PDCP PDUs.

When activating replication for DRBs, the NG-RAN should ensure that at least one serving cell is activated for each logical channel associated with the active RLC entity of the DRB; and when deactivation of the SCell does not have any serving cell activated for the logical channel of the DRB, the NG-RAN should ensure that the deactivation is also replicated for the RLC entity associated with the logical channel.

When duplicate is activated, the original PDCP PDU and the corresponding duplicate should not be transmitted on the same carrier. The logical channels configured with duplicate radio bearers may belong to the same MAC entity (called CA duplication) or to different MAC entities (called DC duplication). When more than two replicates on the RLC entity are configured for the radio bearer, CA replication may also be configured in either or both of the MAC entities along with DC replication. In CA replication, logical channel mapping restrictions are used in the MAC entity to ensure that different logical channels of the radio bearer in the MAC entity are not transmitted on the same carrier. When CA replication is configured for an SRB, one of the logical channels associated with the SRB is mapped to SpCell.

When the CA copy is deactivated for the DRBs in the MAC entity (i.e., none or only one of the RLC entities of the DRBs in the MAC entity remains active), the logical channel mapping restriction of the logical channels of the DRBs is raised as long as the CA copy remains deactivated for the DRBs in the MAC entity.

When the RLC entity acknowledges delivery of the PDCP PDU, the PDCP entity should indicate to other RLC entities to discard it. In addition, in the case of CA duplication, when the RLC entity limited to SCell reaches the maximum number of retransmissions for PDCP PDUs, the UE informs the gNB but does not trigger RLF.

[…]

16.12 side link relay

16.12.1 general rule

Side link relay is introduced to support 5G ProSe UE-to-network relay (U2N relay) functionality (specified in TS 23.304[48 ]) to provide connectivity to the network for U2N remote UEs. Both L2 and L3U 2N relay architectures are supported. The L3U 2N relay architecture is transparent to the serving RAN of the U2N relay UE, except for the control side chain resources. Detailed architecture and procedures for L3U 2N relay can be found in TS 23.304[48].

The U2N relay UE should be in rrc_connected to perform relay of unicast data.

For L2U 2N relay operation, the following RRC state combinations are supported:

both the U2N relay and the U2N remote UE should be in RRC CONNECTED to perform the transmission/reception of the relayed unicast data; and

the U2N relay UE may be in rrc_idle, rrc_inactive, or rrc_connected, as long as all U2N remote UEs CONNECTED to the U2N relay UE are in rrc_inactive or rrc_idle.

For L2U 2N relay, the U2N remote UE may be configured only to use resource allocation pattern 2 (as specified in 5.7.2 and 16.9.3.1) for relaying data.

A single unicast link is established between one L2U 2N relay UE and one L2U 2N remote UE. Traffic of a U2N remote UE via a given U2N relay UE and traffic of the U2N relay UE should be separated in different Uu RLC channels through Uu.

3GPP TS 37.340 specifies multi-radio dual connectivity (MR-DC) as follows:

3.1 definition

[…]

MCG bearer: in MR-DC, there are only radio bearers with RLC bearers in the MCG (or two RLC bearers in case of CA packet duplication in the E-UTRAN cell group, or at most four RLC bearers in case of CA packet duplication in the NR cell group).

MN terminated bearer: in MR-DC, its PDCP is located at the radio bearer in the MN.

[…]

SCG bearer: in MR-DC, there are only radio bearers with RLC bearers in SCG (or two RLC bearers in case of CA packet duplication in E-UTRAN cell group, or at most four RLC bearers in case of CA packet duplication in NR cell group).

SN terminated bearer: in MR-DC, its PDCP is located at the radio bearer in the SN.

[…]

Split bearer: in MR-DC, there is a radio bearer for RLC bearers in both MCG and SCG.

[…]

4. Multi-radio dual connectivity

4.1 General rule

4.1.1 common MR-DC principle

Multi-radio dual connectivity (MR-DC) is a generalization of Dual Connectivity (DC) within E-UTRA described in TS 36.300[2], where multiple Rx/Tx capable UEs may be configured to utilize resources provided by two different nodes via non-ideal backhaul connections, one node providing NR access and another node providing E-UTRA or NR access. One node acts as a MN and the other node acts as a SN. The MN and SN are connected via a network interface, and at least the MN is connected to a core network.

The MN and/or SN may be operated with shared spectrum channel access.

All functions specified for the UE may be used for the IAB-MT unless otherwise indicated. Similar to what is specified for the UE, the IAB-MT may access the network using either network node or using two different nodes with EN-DC and NR-DC architectures. In EN-DC, backhaul traffic over the E-UTRA radio interface is not supported.

Note 1: MR-DC is designed based on the assumption of non-ideal backhaul between different nodes, but can also be used in the case of ideal backhaul.

And (2) injection: all MR-DC normative words and procedures in this version of the specification show the aggregate node case. Details about non-aggregate nodes for MR-DC operation are described in TS 38.401[7 ].

[…]

4.1.3.3NR-NR Dual connectivity

The NG-RAN supports NR-NR dual connectivity (NR-DC), where a UE is connected to one gNB acting as MN and another gNB acting as SN. In addition, NR-DC may also be used when the UE is connected to a single gNB that acts as both MN and SN and configures both MCG and SCG.

[…]

4.2 radio protocol architecture

4.2.1 control plane

In MR-DC, the UE has a single RRC state, based on the MN RRC and a single C-plane connection towards the core network. Fig. 4.2.1-1 shows a control plane architecture for MR-DC. Each radio node has its own RRC entity (E-UTRA version if the node is an eNB, or NR version if the node is a gNB) which can generate RRC PDUs to be sent to the UE.

The RRC PDU generated by the SN may be transmitted to the UE via the MN. The MN always sends the initial SN RRC configuration via MCG SRB (SRB 1), but subsequent reconfigurations may be transmitted via the MN or SN. When transmitting the RRC PDU from the SN, the MN does not modify the UE configuration provided by the SN.

In E-UTRA connected to EPC, SRB1 uses E-UTRA PDCP at initial connection establishment. If the UE supports EN-DC, after initial connection establishment, MCG SRB (SRB 1 and SRB 2) may be configured by the network to use E-UTRA PDCP or NR PDCP (SRB 1 and SRB2 are both configured with E-UTRA PDCP, or they are both configured with NR PDCP), regardless of whether EN-DC is configured. The change from E-UTRA PDCP to NR PDCP (or vice versa) is supported via a handover procedure (reconfiguration with mobility) or for an initial change of SRB1 from E-UTRA PDCP to NR PDCP, the change is supported by a reconfiguration without mobility prior to initial security activation.

If the SN is gNB (i.e., for EN-DC, NGEN-DC, and NR-DC), the UE may be configured to establish SRB (SRB 3) with the SN to enable the transmission of RRC PDU for the SN directly between the UE and the SN. The RRC PDU for the SN may be transmitted directly to the UE only for SN RRC reconfiguration without any coordination with the MN. If SRB3 is configured, measurement reporting for mobility within the SN may be done directly from the UE to the SN.

Split SRBs are supported for all MR-DC options, allowing duplication of RRC PDUs generated by the MN via the direct path and via the SN. The split SRB uses NR PDCP. This version of the specification does not support duplication of RRC PDUs generated by the SN via the MN and SN paths.

In EN-DC, the SCG configuration is maintained in the UE during suspension. During connection restart, if the UE supports restarting with EN-DC, the UE may be configured to release, resume, or reconfigure the SCG configuration. Otherwise, the UE releases the SCG configuration (but not the radio bearer configuration) during the restart initiation.

In MR-DC with 5GC, the UE stores PDCP/SDAP configuration and SCG configuration when it becomes RRC inactive. During connection restart, if the UE supports restarting with MR-DC, the UE may be configured to release, resume, or reconfigure the SCG configuration. Otherwise, it releases the SCG configuration.

[ FIG. 4.2.1-1 of the control plane architecture for EN-DC (left) and MR-DC (right) with 5GC "of 3GPP TS 37.340V17.0.0.0 is reproduced as FIG. 7]

4.2.2 user plane

In MR-DC, from the UE perspective, there are three bearer types: MCG bearers, SCG bearers, and split bearers. These three bearer types are depicted in fig. 4.2.2-1 for MR-DC with EPC (EN-DC) and in fig. 4.2.2-2 for MR-DC with 5GC (NGEN-DC, NE-DC and NR-DC).

In E-UTRA connected to EPC, if the UE supports EN-DC, the network can configure E-UTRA PDCP or NR PDCP for MN terminated MCG bearers, regardless of whether EN-DC is configured or not, while NR PDCP is always used for all other bearers. The change from E-UTRA to NR PDCP or vice versa may be performed via a reconfiguration procedure (with or without handover) using release and addition of DRBs or using a full configuration option.

In MR-DC with 5GC, NR PDCP is always used for all bearer types. In NGEN-DC, E-UTRA RLC/MAC is used in MN, while NR RLC/MAC is used in SN. In NE-DC, NR RLC/MAC is used in MN, while E-UTRA RLC/MAC is used in SN. In NR-DC, NR RLC/MAC is used in both MN and SN.

[…]

[3GPP TS 37.340V17.0.0.0, FIG. 4.2.2-2 of the radio protocol architecture for MCG, SCG and split bearers from the perspective of the UE in MR-DC with 5GC (NGEN-DC, NE-DC and NR-DC) is reproduced as FIG. 8]

From the network perspective, each bearer (MCG, SCG, and split bearer) may terminate in the MN or in the SN. Network side protocol termination options are shown in fig. 4.2.2-3 for MR-DC with EPC (EN-DC) and in fig. 4.2.2-4 for MR-DC with 5GC (NGEN-DC, NE-DC and NR-DC).

Note 1: even if only SCG bearers are configured for the UE, the logical channels are always configured at least in MCG for SRB1 and SRB2, i.e. this is still MR-DC configured and PCell is always present.

And (2) injection: if only MCG bearers are configured for the UE, i.e. there is no SCG, this is still considered an MR-DC configuration as long as at least one of the bearers terminates in the SN.

[…]

[3GPP TS 37.340V17.0.0.0, FIGS. 4.2.2-4 of the network side protocol termination options for MCG, SCG and split bearers in MR-DC with 5GC (NGEN-DC, NE-DC and NR-DC) are reproduced as FIG. 9]

4.3 network interface

4.3.1 control plane

4.3.1.1 common MR-DC principle

In MR-DC, there is an interface between MN and SN for control plane signaling and coordination. For each MR-DC UE there is also one control plane connection between the MN and the corresponding CN entity. The MN and SN involved in MR-DC for a certain UE control its radio resources and are mainly responsible for allocating the radio resources of its cell.

Fig. 4.3.1.1-1 shows the C-plane connectivity of MN and SN involved in MR-DC for a certain UE.

FIG. 4.3.1.1-1 entitled "C-plane connectivity for EN-DC (left) and MR-DC (right) with 5 GC" of [3GPP TS 37.340V17.0.0.0 ] is reproduced as FIG. 10]

4.3.1.2 MR-DC with EPC

In MR-DC (EN-DC) with EPC, the core network entity involved is the MME. The S1-MME terminates in the MN, and the MN and SN are interconnected via X2-C.

4.3.1.3 MR-DC with 5GC

In MR-DC (NGEN-DC, NE-DC and NR-DC) with 5GC, the core network entity involved is AMF. NG-C terminates in MN, and MN and SN are interconnected via Xn-C.

4.3.2 user plane

4.3.2.1 common MR-DC principle

There are different U-plane connectivity options for MN and SN involved in MR-DC for a certain UE, as shown in fig. 4.3.2.1-1. U-plane connectivity depends on configured bearer options:

-for MN terminated bearers, user plane connections to CN entities are terminated in the MN;

-for SN terminated bearers, user plane connections to CN entities are terminated in SN;

the transmission of user plane data over Uu involves MCG or SCG radio resources or both:

for MCG bearers, only MCG radio resources are involved;

for SCG bearers, only SCG radio resources are involved;

for split bearers, both MCG and SCG radio resources are involved.

For split bearers, MN-terminated SCG bearers and SN-terminated MCG bearers, PDCP data is transferred between MN and SN via the MN-SN user plane interface.

FIG. 4.3.2.1-1 entitled "U-plane connectivity for EN-DC (left) and MR-DC (right) with 5 GC" of [3GPP TS 37.340V17.0.0.0 ] is reproduced as FIG. 11]

[…]

4.3.2.3 MR-DC with 5GC

For MR-DC with 5GC (NGEN-DC, NE-DC, and gNB-to-NB NR-DC), the Xn-U interface is the user plane interface between MN and SN, and NG-U is the user plane interface between MN, SN, or both and UPF.

[…]

6.3PDCP sublayer

In EN-DC, CA replication can be applied in MN and SN (see [3 ]), but MCG bearer CA replication can be configured only in combination with E-UTRAN PDCP and can be configured only when DC replication is not configured for any split bearer.

In NGEN-DC, CA replication may be configured for SCG bearers only. In NE-DC, CA replication may be configured for MCG bearers only. In NR-DC, CA replication can be configured for both MCG and SCG bearers, and can be configured along with DC replication.

In MR-DC, the RoHC and EHCs may be configured for all bearer types (as described in TS 36.323[15] and TS 38.323[16 ]). In MR-DC with 5GC, UDC can be configured for all bearer types (as described in TS 38.323[16 ]).

6.4SDAP sub-layer

In MR-DC with 5GC, the network can host at most two SDAP protocol entities for each individual PDU session, one for MN and one for SN (see clause 8.1). The UE is configured with one SDAP protocol entity per PDU session.

[…]

The 3gpp TS 38.323 specifies the Packet Data Convergence Protocol (PDCP) architecture as follows:

4.2 architecture

4.2.1PDCP structure

Fig. 4.2.1.1 shows one possible structure for a PDCP sublayer; it should not limit the embodiments. The diagram is based on the radio interface protocol architecture defined in TS 38.300 < 2 >.

[3GPP TS 38.323V17.0.0 entitled "PDCP layer, structure View" FIG. 4.2.1-1 is reproduced as FIG. 12]

The PDCP sublayer is configured by the upper layer TS 38.331[3 ]. The PDCP sublayer is used for RBs mapped on logical channels of DCCH, DTCH, MTCH, SCCH and STCH types. The PDCP sublayer is not used for any other type of logical channel.

Each RB (except SRB0 for Uu interface) is associated with one PDCP entity. Each PDCP entity is associated with one, two, three, four, six or eight RLC entities, depending on RB characteristics (e.g., unidirectional/bidirectional or split/non-split) or RLC modes:

for split bearers, each PDCP entity is associated with two UM RLC entities (for the same direction), four UM RLC entities (two for each direction), or two AM RLC entities;

for RBs configured with PDCP duplication, each PDCP entity is associated with N UM RLC entities (for the same direction), 2×n UM RLC entities (N per direction), or N AM RLC entities, where 2< = N < = 4;

For DAPS bearers, each PDCP entity is associated with two UM RLC entities (one for the source cell and one for the target cell), four UM RLC entities (two for each direction on the source cell and the target cell), or two AM RLC entities (one for the source cell and one for the target cell);

for UM MRB, each PDCP entity is associated with one UM RLC entity (for MTCH or for downlink DTCH), two UM RLC entities (one for MTCH and one for downlink DTCH, or one for downlink DTCH and one for uplink DTCH), or three UM RLC entities (one for MTCH, one for downlink DTCH, and one for uplink DTCH);

for AM MRB, each PDCP entity is associated with one AM RLC entity (for downlink DTCH and uplink DTCH), or one UM RLC entity (for MTCH) and one AM RLC entity (for downlink DTCH and uplink DTCH);

otherwise, each PDCP entity is associated with one UM RLC entity, two UM RLC entities (one for each direction), or one AM RLC entity.

4.2.2PDCP entity

The PDCP entity is located in the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP entity carries data of one radio bearer. The PDCP entity is associated to the control plane or the user plane depending on which radio bearer it carries data for.

Fig. 4.2.2-1 is a functional view showing a PDCP entity for a PDCP sublayer; it should not limit the embodiments. The diagram is based on the radio interface protocol architecture defined in TS 38.300 < 2 >.

For split bearers and DAPS bearers, routing is performed in the transmitting PDCP entity.

The PDCP entity associated with the DRB/MRB may be configured by the upper layer TS 38.331[3] to use header compression or Uplink Data Compression (UDC). In this version of the specification, robust header compression protocol (ROHC), ethernet header compression protocol (EHC), and UDC are supported. Each header compression protocol is configured independently for DRBs/MRBs.

[3GPP TS 38.323V17.0.0 entitled "PDCP layer, functional view" FIG. 4.2.2-1 is reproduced as FIG. 13]

Fig. 4.2.2-2 is a functional view of a PDCP entity associated with a DAPS bearer for a PDCP sublayer; it should not limit the embodiments. The diagram is based on the radio interface protocol architecture defined in TS 38.300 < 2 >.

[…]

5.11PDCP replication

Activation/deactivation of 5.11.1PDCP replication

For PDCP entity configured with PDCP-multiplexing, the transmitting PDCP entity should:

-for SRB:

-activating PDCP duplication;

-for DRB:

-if activation of PDCP duplication is indicated for DRB:

-activating PDCP duplication for DRBs;

-if activation of PDCP duplication is indicated for at least one associated RLC entity:

-activating PDCP duplication for the indicated associated RLC entity;

-activating PDCP duplication for DRBs;

-if deactivation of PDCP duplication is indicated for DRB:

-deactivating PDCP duplication for DRBs;

-if deactivation of PDCP duplication is indicated for at least one associated RLC entity:

-deactivating PDCP duplication for the indicated associated RLC entity;

-if all associated RLC entities except the primary RLC entity are deactivated for PDCP duplication:

deactivating PDCP duplication for DRBs.

5.11.2 duplicate PDU discard

For PDCP entity configured with PDCP-multiplexing, the transmitting PDCP entity should:

-if successful delivery of PDCP data PDU is acknowledged by one of the associated AM RLC entities:

-indicating to the other AM RLC entity to discard duplicate PDCP data PDUs;

-if deactivation of PDCP duplication is indicated for DRB:

-indicating to RLC entities other than the primary RLC entity to discard all duplicate PDCP data PDUs;

-if deactivation of PDCP duplication is indicated for at least one associated RLC entity:

-indicating to the RLC entity deactivated for PDCP duplication to discard all duplicate PDCP data PDUs.

The functionality of the side link relay adaptation protocol (SRAP) sublayer is specified by 3gpp TS 38.351 as follows:

4. general rule

4.1 Introduction to the invention

The objective is to describe the SRAP architecture and SRAP entities from a functional point of view.

4.2SRAP architecture

4.2.1 general rules

This clause describes a model of SRAP, i.e., without specifying or limiting embodiments.

4.2.2SRAP entity

Fig. 4.2.2-1 shows one possible structure for an SRAP sublayer. The diagram is based on the radio interface protocol architecture defined in TS 38.300 < 2 >.

[3GPP TS 38.351V17.0.0, FIG. 4.2.2-1 entitled "SRAP Structure overview" is reproduced as FIG. 14]

On the U2N relay UE, the SRAP sublayer contains one SRAP entity at the Uu interface and a separate collocated SRAP entity at the PC5 interface. On the U2N remote UE, the SRAP sublayer contains only one SRAP entity at the PC5 interface.

Each SRAP entity has a transmit portion and a receive portion. Across the PC5 interface, the transmitting portion of the SRAP entity at the U2N remote UE has a corresponding receiving portion of the SRAP entity at the U2N relay UE, and vice versa. Across the Uu interface, the transmit portion of the SRAP entity at the U2N relay UE has a corresponding receive portion of the SRAP entity at the gNB, and vice versa.

Fig. 4.2.2-2 and fig. 4.2.2-3 show functional views of SRAP entities for SRAP sublayers at the PC5 interface and Uu interface, respectively.

Fig. 4.2.2-2, entitled "example of a functional view of SRAP sub-layer at PC5 interface" of 3GPP TS 38.351V17.0.0 is reproduced as fig. 15

Fig. 4.2.2-3, entitled "example of a functional view of SRAP sub-layer at Uu interface" of 3GPP TS 38.351V17.0.0 is reproduced as fig. 16

In the examples of fig. 4.2.2-2 and fig. 4.2.2-3, at the relay UE:

the receiving part on the SRAP entity of the Uu interface delivers SRAP data PDUs to the transmitting part on the collocated SRAP entity of the PC5 interface, and the receiving part on the SRAP entity of the PC5 interface delivers SRAP data PDUs to the transmitting part on the collocated SRAP entity of the Uu interface, except for the data packets for SRB0 (i.e. the data packets received from SL-RLC0, as specified in TS 38.331[3 ]). Alternatively, the receiving portion may deliver the SRAP SDU to the transmitting portion on the collocated SRAP entity. When delivering an SRAP SDU, the receiving part removes the SRAP header and the transmitting part adds the SRAP header with the same SRAP header content as the SRAP header content carried on the SRAP data PDU header before the removal. In an embodiment, delivering SRAP SDUs in this way is thus functionally equivalent to delivering SRAP data PDUs. The following specification thus relates to delivering SRAP packets to support alternative modes.

For a data packet corresponding to SRB0, the receiving part on the SRAP entity of the PC5 interface delivers the SRAP SDU to the transmitting part on the collocated SRAP entity of the Uu interface, and the transmitting part on the SRAP entity of the Uu interface adds the SRAP header according to clause 5.3.3.

For the data packet for SRB0, the receiving part on the SRAP entity of the Uu interface delivers the SRAP data PDU to the transmitting part on the collocated SRAP entity of the PC5 interface, and the transmitting part on the SRAP entity of the PC5 interface removes the SRAP header according to clause 5.2.2.

4.3 service

4.3.1 services provided to upper layers

The following services are provided by the SRAP sublayer to the upper layers:

-data transfer.

4.3.2 anticipating services from lower layers

The SRAP sublayer expects the following services from the lower layer per RLC entity (see TS 38.322[4 ]):

-an acknowledged data transfer service;

unacknowledged data transfer service.

4.4 Functions

The SRAP sublayer supports the following functions:

-data transfer;

-determination of a UE ID field and a bearer ID field for a data packet;

-determination of an egress link;

-determination of an egress RLC channel.

4.5 configuration

The configuration of the SRAP entity for the U2N remote UE includes:

-relaying a mapping of RLC channels from the radio bearer identified by the bearer ID field via RRC to egress PC 5;

-local identity via RRC.

The configuration of the SRAP entity for the U2N relay UE includes:

-local identity for each U2N remote UE via RRC;

-mapping from the UE ID field and the bearer ID field to the egress Uu relay RLC channel via RRC for each U2N remote UE;

mapping from UE ID field and bearer ID field to egress PC5 relay RLC channel via RRC for each U2N remote UE.

The 3GPP TR 23.700-33 is a technical report on the study of system enhancements of proximity-based services (Proximity based Service, proSe) in 5G systems (5G System,5 GS). The key problem #5 contained in the technical report and related solutions to the problem are provided below:

5.5 Critical problem #5: support for multipath transmission for UE to network relay

5.5.1 general description

Multipath transmission using only one direct network communication path and only one indirect network communication path with UE-to-network relay may be used to improve reliability or data rate for remote UEs. As shown in fig. 5.5.1-1, a UE may use path #1 and path #2 for multipath transmission, where path #1 is a direct network communication path and path #2 is an indirect network communication path with UE-to-network relay.

[ fig. 5.5.1-1 of 3GPP TR 23.700-33V0.2.0 entitled "example scenario of multipath transfer Using UE to network Relay" is reproduced as fig. 17]

At least the following needs to be studied:

-triggering whether and how the network grants and for connection establishment for multipath transmission, comprising:

whether and how to authorize the remote UE to use the multipath transmission for a particular ProSe service.

-what information is needed for remote UE or UE to network relay or network triggered multipath connection establishment and how to trigger.

How to provide/update rules for multipath transmission.

Whether and how to enhance existing procedures to set up/modify/release connections for multipath transmission.

Note 1: coordination with the RAN WG is required for RAN dependencies.

And (2) injection: coordination with the SA WG3 is required for security aspects.

And (3) injection: this KI covers layer 2 and layer 3 UE-to-network relay scenarios.

[…]

6.29 solution #29: multipath transmission for UE to network relay

6.29.1 description

In this solution, it is proposed to reuse the existing program as much as possible. Suppose a UE subscribes to a multipath transmission service. And the network may provide the authorization and policy parameters for the multipath transport service to the UE, as specified in TS 23.304[3 ].

The editor annotates: details of how to provision authorization and policy parameters for multipath delivery services are to be further investigated.

The editor annotates: whether this solution applies L2 is to be studied further.

The editor annotates: how to subscribe to multipath transmission services remains to be studied further.

6.29.2 procedure

In case a, the UE has established a Uu connection to deliver traffic to the target DN. When the UE is authorized to use the multipath transmission service. The UE triggers to discover the UE to network relay and attempts to establish a connection to the same target for data traffic as the existing mechanism specified in TS 23.304[3 ].

In case B, the UE has established a 3GPP connection to the target DN by the UE-to-network relay. When the UE is authorized to use the multipath transmission service. The UE triggers the establishment of a 3GPP connection via Uu as specified in TS 23.502[8], e.g. the establishment of a PDU session to deliver traffic to the same DN.

For case a and case B, how to integrate traffic from both Uu connections and connections relayed via the UE to the network depends on the application layer.

6.29.3 impact on services, entities and interfaces

Has no influence on 3 GPP.

[…]

According to 3gpp TS 38.300, when duplicating is configured by Radio Resource Control (RRC) for a radio bearer, at least one secondary Radio Link Control (RLC) entity is added to the radio bearer to handle the duplicated Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs), as depicted on fig. 16.1.3-1 (reproduced as fig. 6) of 3GPP TS 38.300V17.0.0, wherein the logical channel corresponding to the primary RLC entity is referred to as a primary logical channel and the logical channel corresponding to the secondary RLC entity is referred to as a secondary logical channel. All RLC entities have the same RLC mode. Thus, duplication at PDCP consists in submitting the same PDCP PDU multiple times: each active RLC entity for a radio bearer is submitted once. With multiple independent transmission paths, packet duplication thus increases reliability and reduces latency, and is particularly beneficial for ultra-reliable and low latency communication (URLLC) services.

When duplicating is configured for Data Radio Bearers (DRBs), the RRC also sets the state of PDCP duplication (active or inactive) at the time of (re) configuration. After configuration, the PDCP duplication status may then be dynamically controlled by means of a Medium Access Control (MAC) control element. When duplicate is activated, the original PDCP PDU and the corresponding duplicate should not be transmitted on the same carrier. Logical channels configured with duplicate radio bearers may belong to the same MAC entity (referred to as Carrier Aggregation (CA) duplication) or to different MAC entities (referred to as Dual Connectivity (DC) duplication). When more than two replicates on the RLC entity are configured for the radio bearer, CA replication may also be configured in either or both of the MAC entities along with DC replication. In CA replication, logical channel mapping restrictions are used in the MAC entity to ensure that different logical channels of the radio bearer in the MAC entity are not transmitted on the same carrier.

UE-to-network (U2N) relay is supported in release 17, which means that in case the remote UE cannot directly access the network, the relay UE will be used to support communication between the remote UE and the network. There are two different types of solutions for U2N relay, namely (based on) layer 2U2N relay and (based on) layer 3U2N relay.

Both model a discovery and model B discovery are supported for remote UEs to discover U2N relays. Model a uses a single discovery protocol message (i.e., discovery notification) and model B uses two discovery protocol messages (i.e., discovery solicitation and discovery response). In case there are multiple relay UEs in the vicinity of the remote UE, one of the relay UEs will be selected based on e.g. measurements on discovery messages transmitted by different relay UEs. After selecting the appropriate relay UE, the remote UE will then establish a PC5 unicast link with the relay UE to support U2N relay operation.

To access a service of interest from a Data Network (DN), a PDU session should be established with the DN, and the PDU session establishment request message contains single Network slice selection assistance information (Single Network Slice Selection Assistance Information, S-nsai) and a Data Network name (Data Network Name, DNN) associated with the PDU session. In the layer 2U2N relay solution, the remote UE establishes a PDU session with the network via the relay UE, while the relay UE establishes a PDU session with the network of the remote UE in the layer 3U2N relay solution.

The key issue #5 in 3gpp TR 23.700-33 describes support for multipath transmission for UE-to-network (U2N) relay in release 18. In this version multipath transmission uses only one direct network communication path and only one indirect network communication path with UE-to-network relay. This does not exclude more than one direct network communication path and/or more than one indirect network communication path for future versions.

3GPP TS 37.340 specifies NR dual connectivity (NR-DC). According to fig. 4.2.2-2 (reproduced as fig. 8) and fig. 4.2.2-4 (reproduced as fig. 9) in 3GPP TS 37.340V17.0.0, there may be 3 different bearer types to support NR-DC, namely a primary cell group (MCG) bearer, a Secondary Cell Group (SCG) bearer, and a split bearer. An MCG bearer is a radio bearer having an RLC bearer (or entity) only in the MCG, an SCG bearer is a radio bearer having an RLC bearer (or entity) only in the SCG, and a split bearer is a radio bearer having an RLC bearer (or entity) in both the MCG and the SCG. Each bearer may terminate in a primary node (MN) or a Secondary Node (SN). Similar to NR-DC, there may also be 3 different bearer types in NR to support multipath transmission:

(1) Direct bearing: a radio bearer having an RLC bearer (or RLC entity) only in the direct network communication path (i.e., uu RLC bearer or entity).

(2) Indirect bearing: a radio bearer having an RLC bearer (or RLC entity) only in an indirect network communication path (i.e., a PC5 (or SL) RLC bearer or entity).

(3) Split bearer: a radio bearer having an RLC bearer (or RLC entity) in both the direct network communication path and the indirect network communication path.

An exemplary diagram of the above 3 bearer types for supporting multipath transmission with layer 2U2N relay in a (remote) UE is shown in fig. 18. Fig. 18 illustrates bearer types used in a (remote) UE to support multipath transmission according to an example embodiment. In fig. 18, the split bearer and the indirect bearer may share the same PC5 RLC entity. It is also possible that the PC5 RLC entity is owned by only split bearers. In this case, the PC5 SRAP layer (or entity) may not be needed for split bearers.

It is possible that duplication may also be applied to multipath transmission. Thus, the radio bearer in release 18 may be configured with one or more RLC entities. According to 3gpp TS 38.300 and TS 38.323, when the RLC entity confirms the delivery of PDCP PDUs (or successful delivery of PDCP PDUs is confirmed by the RLC entity), the PDCP entity should indicate to other RLC entities of the radio bearer to discard duplicate PDCP PDUs. However, in the case of multipath transmission, RLC acknowledgement of transmission over the indirect path with respect to PDCP PDUs only means that the U2N relay has received PDCP PDUs. It is not determined whether the gNB can receive PDCP PDUs. This PDCP PDU may still be lost if the radio link between the U2N relay and the gNB is poor. Therefore, the PDCP entity should not indicate to other RLC entities on the direct path to discard this PDCP PDU. On the other hand, if RLC acknowledgements are received with respect to the delivery of PDCP PDUs over the direct path, the PDCP entity may still indicate to other RLC entities on the indirect path to discard PDCP PDUs.

In one embodiment, the radio bearer is a split bearer. Which may be a Data Radio Bearer (DRB) or a Signaling Radio Bearer (SRB). The PDCP entity is established by the UE for radio bearers. PDCP PDUs are PDCP data PDUs. And, the RLC entity is an AM RLC entity. In addition, a PDU session is established between the UE and the network, and the UE and the network communicate with each other during the PDU session.

An alternative solution may be that the RLC entity associated with the PDCP entity in the remote UE does not acknowledge successful delivery of PDCP PDUs to the PDCP entity so as not to trigger PDCP PDU dropping in other RLC entities on the direct path.

If an SRAP sublayer is placed between the PDCP sublayer and the PC5 RLC sublayer to support multipath transfer with layer 2U2N relay as shown in fig. 18, an SRAP entity will be established in the UE for mapping DRBs to PC5 relay RLC channels (or PC5 RLC entities). In this case, information or an indication to be exchanged between the PDCP entity and the PC5 RLC entity associated with the DRB is to be forwarded by the SRAP entity. For example, the SRAP entity forwards or delivers PDCP PDU successful delivery information from the PC5 RLC entity to the PDCP entity and a PDCP PDU discard indication from the PDCP entity to the PC5 RLC entity.

As discussed above, if successful delivery of PDCP PDUs is acknowledged by the RLC entity associated with the indirect path, the PDCP entity should not indicate to other RLC entities associated with the direct path to discard PDCP PDUs. Alternatively, it is possible that the RLC entity associated with the indirect path does not deliver information of successful delivery of the PDCP PDU to an upper layer (e.g., the SDAP entity and/or PDCP entity). Therefore, the PDCP entity will not trigger the discard of the corresponding PDCP PDU in the direct path.

Fig. 19 is a flow chart 1900 of a method for duplicate PDU discard. In step 1905, the UE establishes a direct path and an indirect path to communicate with the network. In step 1910, the UE establishes a radio bearer, wherein the radio bearer is mapped to a first RLC entity and a second RLC entity, and wherein the first RLC entity is for communicating with the network over a direct path and the second RLC entity is for communicating with the network over an indirect path. In step 1915, when successful delivery of the first PDCP PDU is acknowledged by the second RLC entity, the PDCP entity in the UE and associated with the radio bearer prevents an indication to the first RLC entity to discard the first PDCP PDU.

In one embodiment, the direct path may be established via a base station. An indirect path may be established via the layer 2UE to the network relay UE. The radio bearers may be split bearers or Data Radio Bearers (DRBs).

In one embodiment, the first RLC entity and the second RLC entity may be Acknowledged Mode (AM) RLC entities. The first RLC entity may be a Uu RLC entity and the second RLC entity may be a PC5 RLC entity.

In one embodiment, when successful delivery of the second PDCP PDU is acknowledged by the first RLC entity, the PDCP entity in the UE and associated with the radio bearer may indicate to the second RLC entity to discard the second PDCP PDU. A side link relay adaptation protocol (SRAP) entity between the PDCP entity and the second RLC entity may indicate to the second RLC entity to discard the second PDCP PDU due to a request from the PDCP entity.

In one embodiment, the PDCP entity may be established by the UE for a radio bearer. The first PDCP PDU and the second PDCP PDU may be PDCP data PDUs.

Referring now to fig. 3 and 4, in one exemplary embodiment of a method for a UE, UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable the UE to: (i) establishing a direct path and an indirect path to communicate with the network, (ii) establishing a radio bearer, wherein the radio bearer is mapped to a first RLC entity and a second RLC entity, and wherein the first RLC entity is configured to communicate with the network over the direct path and the second RLC entity is configured to communicate with the network over the indirect path, and (iii) preventing discarding of the first PDCP PDU from a Packet Data Convergence Protocol (PDCP) entity in the UE and associated with the radio bearer to the first RLC entity when successful delivery of the first PDCP PDU is acknowledged by the second RLC entity. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps or other acts and steps described herein.

Basically, when packet duplication is configured for a Data Radio Bearer (DRB) in release 17, a plurality of logical channels may be configured for a DRB. Some logical channels may belong to MCG and other logical channels may belong to SCG. Since the MCG and SCG may be deployed in different locations, the distance between the UE and the MCG and the distance between the UE and the SCG may vary. If the UE moves away from the SCG, the radio signal strength will weaken. In this case, it is beneficial for the network to add an indirect path (i.e., a communication path via the layer 2UE to the network relay) instead of a communication path via the SCG, which means that the SCG is released and an indirect path is added by the network via an RRC message (e.g., an RRC reconfiguration message). More specifically, all logical channels of the SCG configured to the DRB of the UE are replaced by the PC5 relay RLC channel of the indirect path. This may be achieved by releasing the SCG configuration and adding a configuration of an indirect path, which may include a PC5 relay RLC channel mapped to the DRB.

Fig. 20 is a flow chart 2000 of a method for supporting multipath transmission. In step 2005, the network node establishes a direct path to communicate with the UE, wherein a primary cell group (MCG) and a Secondary Cell Group (SCG) are configured for the UE over the direct path. In step 2010, the network node transmits an RRC message to the UE, wherein the RRC message includes information to indicate that SCG was released and to add an indirect path for the UE to the network relay UE via the UE.

Fig. 21 is a flow chart 2100 of a method for supporting multipath transmission. In step 2105, the UE establishes a direct path to communicate with the network node, wherein a primary cell group (MCG) and a Secondary Cell Group (SCG) are configured for the UE over the direct path. In step 2110, the UE receives an RRC message from the network node, wherein the RRC message includes information to indicate that SCG is released and to add an indirect path to the network relay UE via the UE for the UE. In step 2115, the UE releases the SCG and establishes an indirect path with the network node via the UE-to-network relay UE.

In one embodiment, at least one first logical channel belonging to the MCG and at least one second logical channel belonging to the SCG are configured for Data Radio Bearers (DRBs) for communication with the UE over a direct path.

In one embodiment, the RRC message contains information to configure at least one PC5 relay RLC channel mapped to the DRB for the UE. The at least one PC5 relay RLC channel is established for communication with the UE over an indirect path. The RRC message does not contain information to indicate that MCG is released.

In one embodiment, the UE-to-network relay UE is a layer 2 UE-to-network relay UE.

In one embodiment, a PC5 RRC connection or a PC5 unicast link is established between the UE and the layer 2 UE-to-network relay UE.

Referring now to fig. 3 and 4, in one exemplary embodiment of a method for a network node, the network node 300 comprises program code 312 stored in a memory 310. CPU 308 may execute program code 312 to enable a network node to: (i) Establishing a direct path to communicate with the UE, wherein a primary cell group (MCG) and a Secondary Cell Group (SCG) are configured for the UE over the direct path, (ii) transmitting an RRC message to the UE, wherein the RRC message includes information to indicate that the SCG is released and to add an indirect path to the UE via the UE to the network relay. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps or other acts and steps described herein.

Various aspects of the disclosure have been described above. It should be understood that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method practiced using any number of the aspects set forth herein. In addition, such apparatus may be implemented or such method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the above concepts, in some aspects, parallel channels may be established based on pulse repetition frequencies. In some aspects, parallel channels may be established based on pulse positions or offsets. In some aspects, parallel channels may be established based on a hopping sequence. In some aspects, parallel channels may be established based on pulse repetition frequency, pulse position, or offset, and time hopping sequences.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware (e.g., digital implementations, analog implementations, or combinations of both, which may be designed using source coding or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein as "software" or a "software module" for convenience), or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

Additionally, the various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. An IC may comprise a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions that reside within the IC, outside the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

It should be understood that any particular order or hierarchy of steps in any disclosed process is an example of an example approach. It should be understood that the specific order or hierarchy of steps in the process may be rearranged based on design preferences while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. Software modules (e.g., containing executable instructions and associated data) and other data may reside in data storage such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An example storage medium may be coupled to a machine, such as a computer/processor (which may be referred to herein as a "processor" for convenience), such that the processor can read information (e.g., code) from, and write information to, the storage medium. An example storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user equipment. In the alternative, the processor and the storage medium may reside as discrete components in a user device. Furthermore, in some aspects, any suitable computer program product may comprise a computer-readable medium comprising code relating to one or more of the aspects of the present disclosure. In some aspects, the computer program product may include packaging material.

While the invention has been described in connection with various aspects, it will be understood that the invention is capable of further modifications. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known and customary practice within the art to which the invention pertains.

Claims (20)

1. A method for duplicate protocol data unit discard, comprising:

the user equipment establishes a direct path and an indirect path to communicate with the network;

the user equipment establishes a radio bearer, wherein the radio bearer is mapped to a first radio link control entity and a second radio link control entity, and wherein the first radio link control entity is for communicating with the network over the direct path and the second radio link control entity is for communicating with the network over the indirect path;

when successful delivery of a first packet data convergence protocol data unit is acknowledged by the second radio link control entity, a packet data convergence protocol entity in the user equipment and associated with the radio bearer prevents an indication to the first radio link control entity to discard the first packet data convergence protocol data unit.

2. The method as recited in claim 1, further comprising:

when successful delivery of a second packet data convergence protocol data unit is acknowledged by the first radio link control entity, the packet data convergence protocol entity in the user equipment and associated with the radio bearer indicates to the second radio link control entity to discard the second packet data convergence protocol data unit.

3. The method according to claim 2, wherein a side link relay adaptation protocol entity between the packet data convergence protocol entity and the second radio link control entity indicates to the second radio link control entity to discard the second packet data convergence protocol data unit due to a request from the packet data convergence protocol entity.

4. The method of claim 1, wherein the direct path is established via a base station.

5. The method of claim 1, wherein the indirect path is established via a layer 2 user device to a network relay user device.

6. The method of claim 1, wherein the radio bearer is a split bearer.

7. The method according to claim 1, wherein the packet data convergence protocol entity is established by the user equipment for the radio bearer.

8. The method of claim 3, wherein the first and second packet data convergence protocol data units are packet data convergence protocol data units.

9. The method of claim 1, wherein the first radio link control entity and the second radio link control entity are acknowledged mode radio link control entities.

10. The method according to claim 1, wherein the first radio link control entity is a Uu radio link control entity and the second radio link control entity is a PC5 radio link control entity.

11. A user device, comprising:

a control circuit;

a processor mounted in the control circuit; and

a memory mounted in the control circuit and operatively coupled to the processor;

wherein the processor is configured to execute program code stored in the memory to:

Establishing a direct path and an indirect path to communicate with a network;

establishing a radio bearer, wherein the radio bearer maps to a first radio link control entity and a second radio link control entity, and wherein the first radio link control entity is for communicating with the network over the direct path and the second radio link control entity is for communicating with the network over the indirect path;

when successful delivery of a first packet data convergence protocol data unit is acknowledged by the second radio link control entity, preventing an indication to discard the first packet data convergence protocol data unit from a packet data convergence protocol entity in the user equipment and associated with the radio bearer to the first radio link control entity.

12. The user device of claim 11, wherein the processor is further configured to execute program code stored in the memory to:

when successful delivery of a second packet data convergence protocol data unit is acknowledged by the first radio link control entity, indicating to the second radio link control entity to discard the second packet data convergence protocol data unit from the packet data convergence protocol entity in the user equipment and associated with the radio bearer.

13. The user equipment according to claim 12, wherein a side link relay adaptation protocol entity between the packet data convergence protocol entity and the second radio link control entity indicates to the second radio link control entity to discard the second packet data convergence protocol data unit due to a request from the packet data convergence protocol entity.

14. The user equipment of claim 11, wherein the direct path is established via a base station.

15. The user equipment of claim 11, wherein the indirect path is established via a layer 2 user equipment to a network relay user equipment.

16. The user equipment of claim 11, wherein the radio bearer is a split bearer.

17. The user equipment according to claim 11, characterized in that the packet data convergence protocol entity is established by the user equipment for the radio bearer.

18. The user equipment of claim 11, wherein the first and second packet data convergence protocol data units are packet data convergence protocol data units.

19. The user equipment of claim 11, wherein the first radio link control entity and the second radio link control entity are acknowledged mode radio link control entities.

20. The user equipment according to claim 11, wherein the first radio link control entity is a Uu radio link control entity and the second radio link control entity is a PC5 radio link control entity.