Apparatus and method for triggering duplication for packets

Abstract

According to the present invention, at least one processor of a CU may be set to: obtain a first DDDS from a first RLC entity; obtain a second DDDS from a second RLC entity; determine, on the basis of the first DDDS, a first loss rate for packets transmitted via a first transmission path between the PDCP entity and the first RLC entity; determine, on the basis of the second DDDS, a second loss rate for packets transmitted via a second transmission path between the PDCP entity and the second RLC entity; and in accordance with a determination that the difference between the first loss rate and the second loss rate exceeds a threshold rate, transmit the packets via both the first transmission path and the second transmission path on the basis of duplicating packets to be transmitted via the transmission path associated with the higher loss rate among the first loss rate and the second loss rate.

Description

Device and method for triggering replication for packets

[0001] The following descriptions relate to a device and method for triggering duplication of packets.

[0002] A central unit (CU) can be connected to a distributed unit (DU) and a second DU through a split bearer. The CU can transmit packets to a terminal through the split bearer. For example, the CU can transmit first packets among the packets to the terminal through the first DU. The CU can transmit second packets among the packets to the terminal through the second DU. The terminal can reorder the first packets and the second packets based on the packet data convergence protocol (PDCP) sequence numbers of the first packets and the PDCP sequence numbers of the second packets.

[0003] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure.

[0004] A central unit (CU) comprising a packet data convergence protocol (PDCP) entity is provided. The CU may include a communication circuit. The CU may include a memory comprising one or more storage media that stores instructions. The CU may include at least one processor comprising a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a first downlink data delivery status (DDDS) from a first radio link control (RLC) entity connected to the PDCP entity via a split bearer. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a second DDDS from a second RLC entity connected to the PDCP entity via the split bearer. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity based on the first DDDS. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity based on the second DDDS.When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the packets to be transmitted through both the first transmission path and the second transmission path based on the determination that the difference between the first loss rate and the second loss rate exceeds a threshold rate, by duplicating the packets to be transmitted through the transmission path associated with the higher loss rate between the first loss rate and the second loss rate.

[0005] A method is provided to be performed by a central unit (CU) including a packet data convergence protocol (PDCP) entity. The method may include an operation of obtaining a first downlink data delivery status (DDDS) from a first radio link control (RLC) entity connected to the PDCP entity via a split bearer. The method may include an operation of obtaining a second DDDS from a second RLC entity connected to the PDCP entity via the split bearer. The method may include an operation of determining a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity based on the first DDDS. The method may include an operation of determining a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity based on the second DDDS. The above method may include the operation of transmitting said packets through both the first transmission path and the second transmission path, based on duplicating said packets to be transmitted through the transmission path associated with the higher of the first loss ratio and the second loss ratio, according to a determination that the difference between said first loss ratio and the second loss ratio exceeds a threshold ratio.

[0006] In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components.

[0007] Figure 1 illustrates an example of a wireless communication system.

[0008] Figure 2 illustrates an example of a protocol stack in the user plane.

[0009] Figure 3 illustrates an example of functional separation.

[0010] Figure 4 illustrates an example of reordering performed at the PDCP layer.

[0011] FIGS. 5A and FIGS. 5B illustrate examples of dual connections in a wireless communication system.

[0012] Figure 6 illustrates the components of the CU.

[0013] Figure 7 is a flowchart showing the operations of the CU to trigger PDCP replication.

[0014] Figure 8 is a flowchart showing the operations of the CU for performing PDCP replication.

[0015] Figure 9 is a flowchart showing the operations of the CU to stop PDCP replication.

[0016] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0017] In the various embodiments of the present disclosure described below, a hardware-based approach is described as an example. However, since the various embodiments of the present disclosure include techniques using both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0018] Terms referring to signals used in the following description (e.g., packet, message, signal, information, signaling), terms referring to resources (e.g., section, symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occasion)), terms for operation states (e.g., step, operation, procedure)), terms referring to data (e.g., packet, message, user stream, information, bit, symbol, codeword)), terms referring to channels, terms referring to network entities (DU (distributed unit), RU (radio unit), CU (central unit), CU-CP (control plane), CU-UP (user plane), O-DU (O-RAN (open radio access network) DU), O-RU (O-RAN RU), O-CU (O-RAN CU), Terms such as O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP), and terms referring to components of the device are examples provided for convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. Furthermore, terms such as '...part', '...device', '...object', '...body' used below may refer to at least one shape structure or a unit that processes a function.

[0019] Additionally, in this disclosure, expressions of "greater than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled; however, this is merely for the purpose of expressing an example and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" may be replaced with "less than," and conditions described as "greater than and less than" may be replaced with "greater than and less than." Furthermore, "A" to "B" below refer to at least one of elements from A (including A) to B (including B). Below, "C" and / or "D" refers to including at least one of "C" or "D," i.e., {"C", "D", "C" and "D"}.

[0020] The present disclosure describes embodiments using terms used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project)), but this is merely illustrative. The embodiments of the present disclosure may also be applied to other communication and broadcasting systems.

[0021] Figure 1 illustrates an example of a wireless communication system.

[0022] Referring to FIG. 1, FIG. 1 illustrates a base station (110) and a terminal (120) as part of nodes using a wireless channel in a wireless communication system. FIG. 1 illustrates only one base station, but the wireless communication system may include other base stations identical or similar to the base station (110).

[0023] A base station (110) is a network infrastructure that provides wireless access to a terminal (120). The base station (110) has coverage defined based on the distance over which it can transmit signals. In addition to being a base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5G node (5th generation node)', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having an equivalent technical meaning.

[0024] A terminal (120) is a device used by a user and communicates with a base station (110) via a wireless channel. The link from the base station (110) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (110) is referred to as an uplink (UL). Additionally, although not shown in FIG. 1, the terminal (120) and another terminal can communicate with each other via a wireless channel. In this case, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without user involvement. For example, the terminal (120) may be a device that performs machine type communication (MTC) and may not be carried by the user. In addition, for example, the terminal (120) may be a narrowband (NB) IoT (internet of things) device.

[0025] The terminal (120) may be referred to as 'user equipment (UE)', 'customer premises equipment (CPE)', 'mobile station', 'subscriber station', 'remote terminal', 'wireless terminal', 'electronic device', or 'user device' or other terms having an equivalent technical meaning.

[0026] The base station (110) can perform beamforming with the terminal (120). The base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). Additionally, the base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or FR 2-1, FR 2-2, FR 2-3), FR 3) of NR) and a millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). To improve channel gain, the base station (110) and the terminal (120) can perform beamforming. Here, beamforming may include transmit beamforming and receive beamforming. The base station (110) and the terminal (120) can assign directivity to the transmitted signal or the received signal. To this end, the base station (110) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through a resource that has a QCL relationship with the resource that transmitted the serving beams.

[0027] If large-scale characteristics of the channel that transmitted the symbol on the first antenna port can be inferred from the channel that transmitted the symbol on the second antenna port, the first antenna port and the second antenna port can be evaluated as being in a QCL relationship. For example, the large-scale characteristics may include at least one of a delay spread, a Doppler spread, a Doppler shift, an average gain, an average delay, and a spatial receiver parameter.

[0028] In FIG. 1, it is described that both the base station (110) and the terminal (120) perform beamforming, but the embodiments of the present disclosure are not necessarily limited thereto. In some embodiments, the terminal may or may not perform beamforming. Also, the base station may or may not perform beamforming. That is, either the base station or the terminal may perform beamforming, or neither the base station nor the terminal may perform beamforming.

[0029] In the present disclosure, a beam refers to a spatial flow of a signal in a wireless channel, formed by one or more antennas (or antenna elements), and this formation process may be referred to as beamforming. Beamforming may include at least one of analog beamforming or digital beamforming (e.g., precoding). A reference signal transmitted based on beamforming may include, for example, a demodulation-reference signal (DM-RS), a channel state information-reference signal (CSI-RS), a synchronization signal / physical broadcast channel (SS / PBCH), or a sounding reference signal (SRS). Additionally, an IE such as a CSI-RS resource or an SRS-resource may be used as a configuration for each reference signal, and such a configuration may include information associated with the beam. Information associated with a beam may refer to whether the configuration (e.g., CSI-RS resource) uses the same spatial domain filter as other configurations (e.g., other CSI-RS resources within the same CSI-RS resource set) or a different spatial domain filter, or which reference signal it is quasi-colocated with, and if so, what type (e.g., QCL type A, B, C, D).

[0030] Conventionally, in communication systems with a relatively large cell radius of base stations, each base station was installed to include the functions of a digital processing unit (or DU (distributed unit)) and an RF (radio frequency) processing unit (RF processing unit, or RU (radio unit)). However, as high frequency bands are used in 4G (4th generation) and / or subsequent communication systems (e.g., 5G) and the cell coverage of base stations decreases, the number of base stations required to cover a specific area has increased. Consequently, the burden of installation costs for operators to install base stations has also increased. To minimize base station installation costs, a structure has been proposed in which the DU and RU of a base station are separated, with one or more RUs connected to a single DU via a wired network, and one or more geographically distributed RUs deployed to cover a specific area. Below, with reference to FIG. 2, deployment structures and extension examples of base stations according to various embodiments of the present disclosure are described.

[0031] Figure 2 illustrates an example of a protocol stack in the user plane.

[0032] Referring to FIG. 2, the wireless protocol of the user plane of the terminal (120) may include an SDAP (service data adaptation protocol) layer (201), a PDCP (packet data convergence protocol) layer (202), an RLC (radio link control) layer (203), a MAC (medium access control) layer (204), and a PHY (physical) layer (205). The wireless protocol of the user plane of the base station (110) may include an SDAP layer (211), a PDCP layer (212), an RLC layer (213), a MAC layer (214), and a PHY layer (215).

[0033] The main functions of the SDAP layer (201, 211) may include at least one of the following functions.

[0034] - User data transfer function (transfer of user plane data)

[0035] - Mapping function between a QoS flow and a DRB for both DL and UL for uplink and downlink

[0036] - Marking QoS flow ID in both DL and UL packets for uplink and downlink

[0037] - A function that maps reflective QoS flow to the data bearer for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

[0038] For SDAP layers (201, 211), the terminal (120) may receive a radio resource control (RRC) message indicating whether to use the header of the SDAP layer (201, 211) or the function of the SDAP layer (201, 211) for each PDCP layer, for each bearer, or for each logical channel. If the SDAP header is set, the terminal (120) may be instructed to update or reset the mapping information for the QoS flows of the uplink and downlink and the data bearer using the NAS (non-access stratum) QoS (quality of service) reflective setting 1-bit indicator (NAS reflective QoS) and the AS (access stratum) QoS reflective setting 1-bit indicator (AS reflective QoS) of the SDAP header. The SDAP header may include QoS flow ID (identifier) ​​information indicating QoS. QoS information can be used for data processing priorities, scheduling information, etc., to support smooth service.

[0039] The main functions of the PDCP layer (202, 212) may include some of the following functions.

[0040] - Header compression and decompression features (ROHC only)

[0041] - User data transfer function (Transfer of user data)

[0042] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0043] - Out-of-sequence delivery of upper layer PDUs

[0044] - Reordering function (PDCP PDU reordering for reception)

[0045] - Duplicate detection function (Duplicate detection of lower layer SDUs)

[0046] - Retransmission of PDCP SDUs

[0047] - Encryption and decryption functions (Ciphering and deciphering)

[0048] - Timer-based SDU discard in uplink.

[0049] In the above description, the reordering function of the PDCP layer (202, 212) may mean a function that reorders PDCP PDUs received from a lower layer in order based on the PDCP SN (sequence number). In one example, the reordering function of the PDCP layer (202, 212) may include a function that transmits data to an upper layer in the reordered order. In one example, the reordering function of the PDCP layer (202, 212) may include a function that transmits data to an upper layer without considering the order. In one example, the reordering function of the PDCP layer (202, 212) may include a function that records lost PDCP PDUs by reordering them. In one example, the reordering function of the PDCP layer (202, 212) may include a function that transmits a status report regarding the lost PDCP PDUs to the transmitting side. In one example, the reordering function of the PDCP layer (202, 212) may include a function to request retransmission of lost PDCP PDUs.

[0050] The main functions of the RLC layer (203, 213) may include at least one of the following functions.

[0051] - Data transfer function (Transfer of upper layer PDUs)

[0052] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0053] - Out-of-sequence delivery of upper layer PDUs

[0054] - ARQ function (Error Correction through ARQ)

[0055] - Concatenation, segmentation, and reassembly functions of RLC SDUs

[0056] - Re-segmentation function (Re-segmentation of RLC data PDUs)

[0057] - Reordering function (Reordering of RLC data PDUs)

[0058] - Duplicate detection

[0059] - Error detection function (Protocol error detection)

[0060] - RLC SDU discard function

[0061] RLC re-establishment function

[0062] In the above description, the in-sequence delivery function of the RLC layer (203, 213) may mean a function of delivering RLC SDUs received from a lower layer to an upper layer in order. When a single RLC SDU is received divided into multiple RLC SDUs, the in-sequence delivery function of the RLC layer (203, 213) may include a function of reassembling and delivering the multiple RLC SDUs. In one example, the in-sequence delivery function of the RLC layer (203, 213) may include a function of rearranging the received RLC PDUs based on an RLC SN or PDCP SN. In one example, the in-sequence delivery function of the RLC layer (203, 213) may include a function of recording lost RLC PDUs by rearranging the order. In one example, the sequential delivery function of the RLC layer (203, 213) may include a function to deliver a status report for lost RLC PDUs to the transmitting side. In one example, the sequential delivery function of the RLC layer (203, 213) may include a function to request retransmission of lost RLC PDUs. In one example, the sequential delivery function of the RLC layer (203, 213) may include a function to deliver only the RLC SDUs prior to the lost RLC SDU in order to the upper layer if there is a lost RLC SDU. In one example, the sequential delivery function of the RLC layer (203, 213) may include a function to deliver all RLC SDUs received before the timer started to the upper layer in order if a predetermined timer has expired even if there is a lost RLC SDU. In one example, the sequential delivery function of the RLC layer (203, 213) may include the function of delivering all RLC SDUs received up to now to the upper layer in order when a predetermined timer expires, even if there are lost RLC SDUs.

[0063] The RLC layer (203, 213) can process the RLC PDUs in the order they are received, regardless of the order of the SN (out of sequence delivery), and deliver them to the PDCP layer (202, 212).

[0064] When the RLC layer (203, 213) receives a segment, it can receive segments stored in a buffer or subsequent segments, reconstruct them into a single complete RLC PDU, and then transmit it to the PDCP layer (202, 212).

[0065] The RLC layer (203, 213) may or may not include a concatenation function. The concatenation function may be performed in the MAC layer (202, 212) or replaced by the multiplexing function of the MAC layer (202, 212).

[0066] The MAC layer (204, 214) may be connected to one or more RLC layers configured in the terminal (120), and the main function of the MAC layer (204, 214) may include at least one of the following functions.

[0067] - Mapping function (Mapping between logical channels and transport channels)

[0068] - Multiplexing and demultiplexing functions (Multiplexing / demultiplexing of MAC SDUs)

[0069] - Scheduling information reporting function

[0070] - HARQ function (Error correction through HARQ)

[0071] - Priority handling between logical channels of one UE

[0072] - Priority handling between UEs by means of dynamic scheduling

[0073] - MBMS service identification function

[0074] - Transport format selection function

[0075] - Padding

[0076] The PHY layer (205, 215) can perform the operation of channel coding and modulating upper layer data, converting it into OFDM (orthogonal frequency division multiplexing) symbols and transmitting them to a wireless channel, or demodulating OFDM symbols received through a wireless channel and channel decoding them to transmit them to an upper layer.

[0077] FIG. 3 illustrates an example of functional separation. The base station (110) may operate as an eNB or a gNB depending on the radio access technology (RAT) provided. The base station (110) may be implemented in a distributed deployment according to a central unit (CU) configured to perform the functions of the upper layers of the access network and a distributed unit (DU) configured to perform the functions of the lower layers.

[0078] Referring to FIG. 3, the CU (310) is connected to the DU (320) and can perform functions of layers higher than the DU (320). The CU (310) can perform functions of the SDAP (service data adaptation protocol) layer (311) and the PDCP (packet data convergence protocol) layer (312). The CU (310) can transmit or receive messages through the DU (320) and the F1 interface (330) (e.g., F1-U). The CU (310) can be referred to as a node hosting PDCP entities for the PDCP layer (312) in terms of performing functions for the PDCP layer (312). The DU (320) can be referred to as a corresponding node as a node interacting with the node hosting the PDCP entities for flow control. In the user plane, the DU (320) can perform the functions of the RLC (radio link control) layer (321), MAC (medium access control) layer (322), and PHY (physical) layer (323). To explain the functions of the SDAP layer (311) of the CU (310), the description of the SDAP layer (211) in FIG. 2 may be referenced. To explain the functions of the PDCP layer (312) of the CU (310), the description of the PDCP layer (212) in FIG. 2 may be referenced. To explain the functions of the RLC layer (321) of the DU (320), the description of the RLC layer (213) in FIG. 2 may be referenced. To explain the functions of the MAC layer (322) of the DU (320), the description of the MAC layer (214) in FIG. 2 may be referenced. For an explanation of the functions of the PHY layer (323) of the DU (320), the explanation of the PHY layer (215) of FIG. 2 may be referenced.

[0079] In FIG. 3, the DU (320) is depicted as being responsible for the PHY layer (323), but embodiments of the present disclosure are not limited thereto. Depending on the embodiment, the DU (320) may perform some functions (high PHY) of the PHY layer (323), and a radio unit (RU) connected to the DU (320) may be responsible for the remaining functions (low PHY) of the PHY layer (323).

[0080] In FIG. 3, a CU (310) is shown connected to one DU (320), but embodiments of the present disclosure are not limited thereto. Depending on the embodiment, the DU (320) may be connected to a plurality of DUs.

[0081] Figure 4 illustrates an example of reordering performed at the PDCP layer. The PDCP (packet data convergence protocol) layer can provide a reordering function to ensure the order of packets in the NR (new radio) standard. When referring to data at the PDCP layer, the terms SDU (service data unit) or PDU (protocol data unit) may be used. For example, data containing a PDCP header may be referred to as PDU, PDCP PDU, or a term having an equivalent technical or functional meaning. For example, data not containing a PDCP header may be referred to as SDU, PDCP SDU, or another term having an equivalent technical or functional meaning.

[0082] Referring to FIG. 4, communication can be performed between a transmitting PDCP entity (410) and a receiving PDCP entity (460). The transmitting PDCP entity (410) and the receiving PDCP entity (460) can be distinguished according to the entity transmitting data and the entity receiving data. For example, in downlink data transmission, the transmitting PDCP entity (410) corresponds to a base station (110) (or a central unit (CU) (310)), and the receiving PDCP entity (460) corresponds to a terminal (120). For example, in uplink data transmission, the transmitting PDCP entity (410) corresponds to a terminal (120), and the receiving PDCP entity (460) corresponds to a base station (110) (or a central unit (310)). In the following, a case is described where the transmitting PDCP entity (410) is a base station (110) (or CU (310)) and the receiving PDCP entity (460) is a terminal (120).

[0083] The transmitting PDCP entity (410) can obtain data (e.g., PDCP SDU) from an upper layer (e.g., SDAP (service data adaptation protocol) layer, RRC (radio resource control) layer). The transmitting PDCP entity (410) can perform sequence numbering (415). The transmitting PDCP entity (410) can determine a count value for the data through sequence numbering (415). For example, the transmitting PDCP entity (410) can determine a count value corresponding to the state variable 'TX_NEXT'. The transmitting PDCP entity (410) can associate the count value with the data. The transmitting PDCP entity (410) can determine a sequence number (SN) for the data. For example, the transmitting PDCP entity (410) can determine the SN of the PDCP PDU based on the state variable 'TX_NEXT' and a modulo operation. The SN may be an integer greater than or equal to 0 and less than [2[PDCP_size] ? 1]. 'PDCP_size' may be configured by an upper layer (e.g., RRC). 'PDCP_size' may be 12-bit or 18-bit. Subsequently, the transmitting PDCP entity (410) may increment the state variable 'TX_NEXT' by 1. That is, the state variable 'TX_NEXT' may be the count value of the next PDCP SDU to be transmitted.

[0084] Although not illustrated in FIG. 4, the transmitting PDCP entity (410) can perform various functions in addition to sequence numbering (415). For example, the transmitting PDCP entity (410) can perform header compression on the data using ROHC (robust header compression). For example, the transmitting PDCP entity (410) can perform integrity protection and ciphering. For example, the transmitting PDCP entity (410) can generate a PDCP PDU by adding a PDCP header to the data. The transmitting PDCP entity (410) can transmit the result of the above functions (e.g., PDCP PDU) to the receiving PDCP entity (460). For example, the result can be provided to another node (e.g., terminal (120)) via an RLC entity, a MAC entity, and a wireless interface.

[0085] A receiving PDCP entity (460) can receive data (e.g., PDCP PDU) from a lower layer (e.g., RLC layer). Variables may be defined to describe the operations of the receiving PDCP entity (460).

[0086] - HFN (hyper frame number): The HFN portion of the state variable (i.e., the number of MSBs (most significant bits) equal to the HFN length)

[0087] - SN (sequence number): The SN portion of the state variable (i.e., the number of LSB (least significant bits) equal to the PDCP SN length)

[0088] - RCVD_SN: The PDCP SN of the received PDCP data PDU included in the PDU header

[0089] - RCVD_HFN: HFN of the received PDCP data PDU calculated by the receiving PDCP entity (560)

[0090] - RCVD_COUNT: COUNT of received PDCP data PDU = [RCVD_HFN, RCVD_SN].

[0091] A receiving PDCP entity (460) may receive a PDCP PDU from a lower layer (e.g., RLC). The PDCP PDU may be data transmitted from a transmitting PDCP entity (410). The receiving PDCP entity (460) may determine a count value (e.g., 'RCVD_COUNT') of the received PDCP PDU. After determining the count value (e.g., 'RCVD_COUNT') of the received PDCP PDU, the receiving PDCP entity (460) may perform deciphering and integrity verification. If the integrity verification fails, the receiving PDCP entity (460) may discard the PDCP PDU. The receiving PDCP entity (460) may discard the PDCP PDU if it has previously received a PDCP PDU corresponding to the count value, or if the count value is smaller than the count value ('RX_DELIV') (hereinafter, waiting start count value) of the first PDCP SDU that is still waiting and has not been passed to an upper layer (e.g., SDAP, RRC).

[0092] The receiving PDCP entity (460) can perform a sequential delivery function and a reordering procedure (465) for said sequential delivery function. The receiving PDCP entity (460) can store a PDCP SDU corresponding to the PDCP PDU in a receiving buffer if the PDCP PDU is not deleted by the procedures described above. The receiving PDCP entity (460) can determine whether the count value of the received PDCP PDU (e.g., 'RCVD_COUNT') is greater than or equal to the count value (RX_NEXT) of the PDCP SDU expected to be received (hereinafter, expected count value). If the count value of the received PDCP PDU (e.g., 'RCVD_COUNT') is greater than or equal to the expected count value (RX_NEXT), the receiving PDCP entity (460) may update the expected count value to the value of the received PDCP PDU count value (e.g., 'RCVD_COUNT') plus 1. This is because the receiving PDCP entity (460) expects the reception of PDCP SDUs having consecutive count values. The receiving PDCP entity (460) may determine whether the count value of the received PDCP PDU (e.g., 'RCVD_COUNT') is equal to the starting count value ('RX_DELIV'). The receiving PDCP entity (460) can forward all stored PDCP SDUs corresponding to consecutive count values ​​starting from the starting count value ('RX_DELIV') to the upper layer (e.g., SDAP, RRC) if the count value (e.g., 'RCVD_COUNT') of the received PDCP PDU is equal to the starting count value ('RX_DELIV'). The starting count value ('RX_DELIV') can be updated to the count value of the first PDCP SDU that is greater than the current starting count value ('RX_DELIV') and has not been forwarded to the upper layer (e.g., SDAP, RRC).

[0093] The receiving PDCP entity (460) may stop and reset the reorder timer if the reorder timer is running and the start count value is greater than or equal to the count value ('RX_REORD') (hereinafter referred to as the reorder start value) following the count value associated with the PDCP PDU that triggered the reorder timer. The receiving PDCP entity (460) may update the reorder start value ('RX_REORD') to the expected count value (RX_NEXT) if the reorder timer is not running and the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT). If the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) may start the reorder timer. Even though there is data that has not yet been delivered to the upper layer (e.g., SDAP), since the expected count value points to the PDCP SDU following the said data, the receiving PDCP entity (460) can deliver all stored PDCP SDUs associated with a count value smaller than the reorder start value ('RX_REORD') to the upper layer (e.g., SDAP, RRC) when the reorder timer expires. Even if the intended data (e.g., PDCP SDU) has not been received because the reorder timer has expired, the PDCP SDUs currently stored in the receiving buffer can be reported to the upper layer. The receiving PDCP entity (460) can deliver all stored PDCP SDUs having consecutive count values ​​starting from the reorder start value ('RX_REORD') to the upper layer (e.g., SDAP, RRC) when the reorder timer expires. The start count value ('RX_DELIV') can be updated with the count value of the first PDCP SDU that is greater than the reorder start value ('RX_REORD') and has not been passed to the upper layer (e.g., SDAP, RRC).The receiving PDCP entity (460) can update the reorder start value ('RX_REORD') to the expected count value (RX_NEXT) if the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT). If the start count value ('RX_DELIV') is less than the expected count value (RX_NEXT), the receiving PDCP entity (460) can start a reorder timer. Even though there is data that has not yet been delivered to the upper layer (e.g., SDAP, RRC), the expected count value points to the PDCP SDU following the data, so the receiving PDCP entity (460) can start the reorder timer as a reorder procedure (465).

[0094] The receiving PDCP entity (460) can update the reorder start value ('RX_REORD') to the expected count value (RX_NEXT) when the reorder timer is reconfigured. The receiving PDCP entity (460) can stop and restart the reorder timer when the reorder timer is reconfigured.

[0095] In example (471), a situation is described where a PDCP PDU with a count value of '5' is lost. For example, a transmitting PDCP entity (410) can sequentially transmit data with count values ​​of 2, 3, 4, …, 9. A receiving PDCP entity (460) can receive a PDCP PDU with a count value of '2'. The receiving PDCP entity (460) can obtain a PDCP SDU from the above PDCP PDU. The receiving PDCP entity (460) can forward the above PDCP SDU with a count value of '2' to an upper layer (e.g., SDAP, RRC). Subsequently, the receiving PDCP entity (460) can expect a PDCP PDU with a count value of '3'. The receiving PDCP entity (460) can receive a PDCP PDU with a count value of '3'. The receiving PDCP entity (460) can obtain a PDCP SDU from the PDCP PDU. The receiving PDCP entity (460) can forward the PDCP SDU with a count value of '3' to an upper layer (e.g., SDAP, RRC). Subsequently, the receiving PDCP entity (460) can expect a PDCP PDU with a count value of '4'. The receiving PDCP entity (460) can receive a PDCP PDU with a count value of '4'. The receiving PDCP entity (460) can obtain a PDCP SDU from the PDCP PDU. The receiving PDCP entity (460) can forward the PDCP SDU with a count value of '4' to an upper layer (e.g., SDAP, RRC). Subsequently, the receiving PDCP entity (460) can set the starting count value ('RX_DELIV') to '5'. The receiving PDCP entity (460) can expect a PDCP PDU with a count value of '5'.

[0096] The receiving PDCP entity (460) may receive a PDCP PDU with a count value of '6' while expecting a PDCP PDU with a count value of '5'. Since the PDCP PDU with a count value of '6' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data transfer to the upper layer (e.g., SDAP, RRC). This is because the PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP PDU with a count value of '6' in the receiving buffer (481). The receiving PDCP entity (460) may start a reordering timer. Since the PDCP PDU with a count value of '6' has been received, the receiving PDCP entity (460) may expect a PDCP PDU with a count value of '7'. For example, the receiving PDCP entity (460) can set the expected count value (RX_NEXT) to '7'. The receiving PDCP entity (460) can update the reorder start value ('RX_REORD') to the expected count value (RX_NEXT) (e.g., '7').

[0097] The receiving PDCP entity (460) may receive a PDCP PDU with a count value of '7' while expecting a PDCP PDU with a count value of '7'. Since the PDCP PDU with a count value of '7' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (560) may not perform data transfer to the upper layer (e.g., SDAP, RRC). This is because a PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP PDU with a count value of '7' in the receiving buffer (481). The reordering timer may be running. Since a PDCP PDU with a count value of '7' has been received, the receiving PDCP entity (460) may expect a PDCP PDU with a count value of '8'.

[0098] The receiving PDCP entity (460) may receive a PDCP PDU with a count value of '8' while expecting a PDCP PDU with a count value of '8'. Since the PDCP PDU with a count value of '8' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data transfer to the upper layer (e.g., SDAP, RRC). This is because a PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP PDU with a count value of '8' in the receiving buffer (481). Afterward, the reorder timer may expire. When the above reorder timer expires, the receiving PDCP entity (460) may forward to the upper layer (e.g., SDAP, RRC) a stored PDCP SDU having a count value smaller than the reorder start value ('RX_REORD') (e.g., 7) and a stored PDCP SDU having consecutive count values ​​greater than or equal to the reorder start value ('RX_REORD') '7' (e.g., a PDCP SDU with a count value of '7', a PDCP SDU with a count value of '8').

[0099] In Example (472), a situation is described where a PDCP PDU with a count value of '5' is received late. As in Example (471), the receiving PDCP entity (460) may receive a PDCP PDU with a count value of '6' while expecting a PDCP PDU with a count value of '5'. Since the PDCP PDU with a count value of '6' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data transfer to the upper layer (e.g., SDAP, RRC). This is because the PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP PDU with a count value of '6' in the receiving buffer (482). The receiving PDCP entity (460) may start a reordering timer. Since a PDCP PDU with a count value of '6' has been received, the receiving PDCP entity (460) can expect a PDCP PDU with a count value of '7'. For example, the receiving PDCP entity (460) can set the expected count value (RX_NEXT) to '7'. The receiving PDCP entity (460) can update the reorder start value ('RX_REORD') to the expected count value (RX_NEXT) (e.g., '7').

[0100] The receiving PDCP entity (460) may receive a PDCP PDU with a count value of '7' while expecting a PDCP PDU with a count value of '7'. Since the PDCP PDU with a count value of '7' has been received but the starting count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may not perform data transfer to the upper layer (e.g., SDAP, RRC). This is because a PDCP SDU with a count value of '5' has not yet been received. The receiving PDCP entity (460) may store the PDCP SDU corresponding to the PDCP PDU with a count value of '7' in the receiving buffer (482). The reordering timer may be running. Since a PDCP PDU with a count value of '7' has been received, the receiving PDCP entity (460) may expect a PDCP PDU with a count value of '8'.

[0101] The receiving PDCP entity (460) may receive a PDCP PDU with a count value of '5' while expecting a PDCP PDU with a count value of '8'. The receiving PDCP entity (460) may receive a PDCP PDU corresponding to the start count value ('RX_DELIV') before the reordering timer expires. Since the start count value ('RX_DELIV') is '5', the receiving PDCP entity (460) may perform data transfer to an upper layer (e.g., SDAP, RRC). The receiving PDCP entity (460) may store a PDCP SDU corresponding to the PDCP PDU with a count value of '5' in the receiving buffer (482). The receiving buffer (482) may store a PDCP SDU associated with a count value of '6', a PDCP SDU associated with a count value of '7', and a PDCP SDU associated with a count value of '5'. The receiving PDCP entity (460) can forward the stored PDCP SDUs to the upper layer (e.g., SDAP, RRC) in ascending order starting from '5'. Meanwhile, a PDCP PDU with a count value of '5' is received, but since the expected count value (RX_NEXT) is '8', the expected count value (RX_NEXT) is not updated.

[0102] The PDCP layer of the NR specification may provide a reordering function (e.g., reordering procedure (465)) that guarantees the packet order for uplink packets. The reordering function may be performed by a receiving PDCP entity (460). When the reordering timer expires or the intended PDCP PDU is received, the receiving PDCP entity (460) may correct the packet order by sorting the PDCP SDUs in ascending order of count values ​​(values ​​corresponding to SN) and delivering the sorted PDCP SDUs to the upper layer (e.g., SDAP, RRC). Referring to the usual procedures, if the PDCP SDU of a specific SN is not received while the reordering timer is operating, the receiving PDCP entity (460) may wait without delivering the PDCP SDU(s) to the upper layer until the reordering timer expires. Afterward, when the reorder timer expires, the PDCP SDU(s) stored in the receive buffer of the receiving PDCP entity (460) can be transferred to the upper layer (e.g., SDAP, RRC).

[0103] FIGS. 5A and FIGS. 5B illustrate examples of dual connections in a wireless communication system.

[0104] FIG. 5a illustrates an example of dual connectivity (DC) between a terminal (120) and a plurality of base stations (110-1, 110-2). Referring to the example, the terminal (120) may be configured in a dual connectivity utilizing a first base station (110-1) and a second base station (110-2). The dual connectivity technology is a technology that increases frequency usage efficiency by simultaneously connecting the terminal (120) to two independent heterogeneous or homogeneous radio communication cell groups having separate radio resource control entities, thereby utilizing frequency resources on component carriers of cells within each cell group located in different frequency bands for the transmission and reception of signals. For example, the terminal (120) may be connected to two different radio resource entities (e.g., a first base station (110-1) and a second base station (110-2)) and utilize radio resources allocated by each radio resource entity. In a multi-radio DC (MR-DC), a terminal (120) in a radio resource control (RRC) connection state (e.g., RRC_CONNECTED) may be configured to use radio resources provided by two independent schedulers. Each scheduler may be located at an NG-RAN node (e.g., a first base station (110-1), a second base station (110-2)). One of the nodes may be a master node (MN) and the other may be a secondary node (SN). The MN and the SN are connected via a network interface, and the MN may be connected to a core network (CN). The SN may or may not be connected to the core network.

[0105] MN may provide a master cell group (MCG). In addition to MN, MN may be referred to as an M-NODE, M-NG-RAN node, or other terms having an equivalent technical meaning. MCG may include one or more cells. MCG may include a primary cell (PCell). MCG may include a plurality of aggregated cells. MCG may include a PCell and one or more secondary cells (SCell). SN may provide a secondary cell group (SCG). In addition to SN, SN may be referred to as an S-NODE, S-NG-RAN node, or other terms having an equivalent technical meaning. SCG may include one or more cells. SCG may include a plurality of aggregated cells. SCG, like MCG, may include a PCell and / or SCell. A cell functioning as a PCell within an SCG may be referred to as a primary secondary cell (PSCell). Hereinafter, the term SpCell (special cell) may be used as a term including PCell and PSCell. For example, SpCell in MCG may represent PCell, and SpCell in SCG may represent PSCell.

[0106] The types of DC can be defined as follows.

[0107] 1) EN-DC (EUTRA (evolved universal terrestrial radio access) NR (new radio) dual connectivity): dual connectivity in which an eNB is connected to an EPC (evolved packet core) and a terminal is connected to an Enb operating as an MN and a gNB operating as an SN (act as). The gNB may be referred to as an en-gNB, and the en-gNB may or may not be connected to an EPC.

[0108] 2) NGEN-DC: A dual connection in which an eNB is connected to a 5GC (5G core), and a terminal is connected to an eNB operating as an MN and a Gnb operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0109] 3) NE-DC: A dual connection in which a gNB is connected to a 5GC, and a terminal is connected to a gNB operating as an MN and an eNB operating as an SN. Here, the eNB may be referred to as ng-eNB.

[0110] 4) NR-DC: A dual connection in which gNBs are connected to the 5GC, and terminals are connected to a gNB operating as an MN and a gNB operating as an SN. NR-DC can also be used when a UE is connected to a single gNB to perform both the roles of MN and SN and to configure both the MCG and SCG.

[0111] The terminal (120) may support MR-DC. The terminal (120) may be connected to a first base station (110-1) and a second base station (110-2). The first base station (110-1) may be connected to the terminal (120) as an MN and the second base station (110-2) as an SN. However, this is merely an example and the present disclosure is not limited thereto. For example, the first base station (110-1) may be connected to the terminal (120) as an SN and the second base station (110-2) as an MN.

[0112] FIG. 5b illustrates an example of a dual connection between a terminal (120), a first DU (510), a second DU (520), and a CU (310). For example, base stations (e.g., base station (110), first base station (110-1), second base station (110-2)) may be separated into a CU and a DU. Unlike multiple independent base stations (e.g., first base station (110-1), second base station (110-2)) serving the terminal (120), one CU and multiple DUs may serve the terminal (120). For example, the CU (310) may be connected to the first DU (510) and the second DU (520) via a split bearer. The CU (310) may be connected to each of the first DU (510) and the second DU (520) via an F1 interface. The first DU (510) may provide one or more cells. For example, one or more cells provided by the first DU (510) may be referred to as MCG (or SCG). The second DU (520) may provide one or more cells. For example, one or more cells provided by the second DU (520) may be referred to as SCG (or MCG). In terms of the terminal (120), the CU (310) and the first DU (510) may operate as logical nodes corresponding to one base station. In terms of the terminal (120), the CU (310) and the second DU (520) may operate as logical nodes corresponding to another base station different from the one base station.

[0113] In the present disclosure, base stations (e.g., base station (110), first base station (110-1), second base station (110-2)) may be implemented in a distributed arrangement according to a CU configured to perform upper-layer functions of an access network and a DU configured to perform lower-layer functions. The CU and DU may represent independent network entities (or network nodes, network equipment, network devices) for the access network. A CU may be connected to one or more DUs. A CU may perform functions of a layer higher than a DU (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)). A DU may perform functions of a lower layer (e.g., radio link control (RLC), medium access control (MAC), and physical (PHY)).

[0114] Figure 6 illustrates the components of the CU.

[0115] Referring to FIG. 6, the CU (310) may include a processor (601), a memory (602), and a transceiver (603). For example, the processor (601), the memory (602), and the transceiver (603) may be electronically and / or operably coupled with each other by a communication bus. Operatably coupled hardware components may mean that a direct or indirect connection between the hardware components is established wired or wirelessly so that a second hardware component (e.g., memory (602) and / or transceiver (603)) is controlled by a first hardware component (e.g., processor (601)). The hardware components illustrated in FIG. 6 are illustrated based on different blocks, but the present disclosure is not limited thereto. For example, at least a portion of the hardware components shown in FIG. 6 (e.g., processor (601), memory (602) and / or transceiver (603)) may be included in a single integrated circuit such as a system on chip (SoC) or a system in package (SIP).

[0116] In one embodiment, the CU (310) may include a processor (601). The processor (601) may include a hardware component for processing data based on one or more instructions. The processor (601) may include various processing circuits and / or a number of processors. For example, the term “processor” as used herein, including in the claims, may include various processing circuits including at least one processor, and one or more of said at least one processor may be configured to perform the various functions described below in a distributed manner, individually and / or collectively. As used below, where “processor,” “at least one processor,” and “one or more processors” are described as being configured to perform various functions, these terms encompass, for example but not limited to, situations where one processor performs some of the cited functions and another processor(s) perform other parts of the cited functions, and also situations where one processor can perform all of the cited functions. Additionally, the at least one processor may include a combination of processors that perform various enumerated / disclosed functions, for example, in a distributed manner. The at least one processor may execute program instructions to achieve or perform various functions.

[0117] In one embodiment, the CU (310) may include a memory (602). The memory (602) may include a hardware component for storing data and / or instructions that are input to or output from the processor (601). For example, the memory (602) may include a volatile memory such as random-access memory (RAM) and / or a non-volatile memory such as read-only memory (ROM). The volatile memory may include, for example, at least one of dynamic RAM (DRAM), static RAM (SRAM), cache RAM, and pseudo SRAM (PSRAM). The non-volatile memory may include, for example, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, a hard disk, a compact disk, and an embedded multimedia card (eMMC).

[0118] In one embodiment, one or more instructions (or commands) representing operations and / or operations performed by the processor (601) may be stored in the memory (602) of the CU (310). A set of one or more instructions may be referred to as a program, firmware, operating system, process, routine, sub-routine, and / or application. Hereinafter, the statement that an application is installed in the CU (310) may mean that one or more instructions provided in the form of an application are stored in the memory (602), and that one or more applications are stored in an executable format by the processor (601).

[0119] In one embodiment, the CU may include a transceiver (603). The transceiver (603) may perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (603) may include a wired interface for controlling a direct connection between devices through a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (603) may transmit an electrical signal to another device through a copper wire or perform conversion between an electrical signal and an optical signal. According to one embodiment, the CU (310) may communicate with a DU (distributed unit) (e.g., a first DU (510) and / or a second DU (520)) through the transceiver (603). The transceiver (603) may also perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (603) can perform a conversion function between a baseband signal and a bit sequence according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (603) generates complex symbols by encoding and modulating the transmitted bit sequence. Also, when receiving data, the transceiver (603) restores the received bit sequence by demodulating and decoding the baseband signal. Additionally, the transceiver (603) may include a plurality of transmission and reception paths. According to one embodiment, the CU (310) may be a base station (110) and may communicate with the terminal (120) directly through a wireless access network or communicate with the terminal (120) through a radio unit (RU).

[0120] The transceiver (603) transmits and receives signals as described above. Accordingly, all or part of the transceiver (603) may be referred to as a communication circuit, a communication unit, a transmitting unit, a receiving unit, a transceiver, or other terms having an equivalent technical or functional meaning. Although only the transceiver (603) is shown in FIG. 5, according to other embodiments, the CU (310) may include two or more transceivers.

[0121] The configuration of the CU (310) shown in FIG. 6 is merely an example, and the examples of components of the CU (310) for performing embodiments of the present disclosure are not limited to the configuration shown in FIG. 6. In some embodiments, some configurations may be added, deleted, or changed. The descriptions of the processor (601), memory (602), and transceiver (603) of FIG. 6 may be applied in the same way to the processor, memory, and transceiver of the base station (110) of FIG. 1.

[0122] Referring to the description in FIGS. 1 through 6, the CU (310) can be connected to the first DU (510) and the second DU (520) through a split bearer. The CU (310) can transmit packets to the terminal (120) through the split bearer. For example, the CU (310) can transmit first packets among the packets to the terminal (120) through the first DU (510). The CU (310) can transmit second packets among the packets to the terminal (120) through the second DU (520). The packets may have consecutive PDCP sequence numbers. For example, the PDCP sequence numbers of the first packets transmitted through the first DU (510) and the PDCP sequence numbers of the second packets transmitted through the second DU (520) may be different. The first packets and the second packets can be reordered based on PDCP sequence numbers at the terminal (120).

[0123] The distance between the CU (310) and the first DU (510) and / or the distance between the CU (310) and the second DU (510) may be far. Therefore, network devices (e.g., routers, switches) for relaying packets between the CU (310) and the DUs may exist on the interfaces. For example, one or more first network devices may exist on the first interface between the CU (310) and the first DU (510). For example, one or more second network devices may exist on the second interface between the CU (310) and the second DU (520).

[0124] During the process of network devices relaying packets, packets may be lost. For example, a network device may be unable to deliver packets received from the CU (310) to the DU (510) and / or DU (520) due to performance degradation caused by the capability and / or aging of the network device. Among the cases described above, there may be a case where the difference between the first loss rate on the first interface between the CU (310) and the first DU (510) and the second loss rate on the second interface between the CU (310) and the second DU (520) is large. In such a case, some of the packets transmitted through the interface with the large loss rate among the interfaces may not be delivered to the terminal (120) or may be delivered late. The terminal (120) may wait for the packets until the reordering timer expires. Since the terminal (120) waits for the packets, latency may occur. Additionally, if the packets are not received by the terminal (120) until the reorder timer expires, the terminal (120) may forward only the remaining packets stored in the buffer to an upper layer (e.g., the SDAP (service data adaptation protocol) layer). Since some packets are missing, TCP (transmission control protocol) retransmission may occur. TCP performance may be degraded as a result of TCP retransmission.

[0125] As described above, when the CU (310) is connected to the first DU (510) and the second DU (520) through a split bearer, if the loss rate of either path increases, the overall performance may be degraded. Below, to solve the problems described above, the CU (310) that triggers PDCP duplication and the method performed by the CU (310) are described.

[0126] FIG. 7 is a flowchart illustrating the operations of a CU for triggering PDCP replication. The operations of FIG. 7 may be performed by a CU (central unit) (310). For example, at least some of the operations may be controlled by a processor (601) of the CU (310). In the following description, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed. For example, at least two operations may be performed in parallel. In the following description, the operations of FIG. 7 are described as being performed by the CU (310), but the present disclosure is not limited thereto. For example, the operations of FIG. 7 may be performed by a base station (110) configured to perform the functions of the CU (310) and the functions of the DU (distributed unit) (320).

[0127] Referring to FIG. 7, in operation 701, a CU (310) according to one embodiment may obtain a DDDS (downlink data delivery status) from a first RLC (radio link control) entity. For example, the CU (310) may be connected to a first DU (distributed unit) (510) and a second DU (520) via a split bearer as shown in FIG. 5b. In one example, the first RLC entity may be configured within the first DU (510). In one example, the second RLC entity may be configured within the second DU (520).

[0128] In one embodiment, the CU (310) may assign sequence numbers (SN) to packets (e.g., downlink packets). For example, the CU (310) may assign consecutive sequence numbers to each packet. For example, the sequence number may be an NR-U sequence number. The NR-U sequence number may be used to detect lost packets on a first interface (e.g., F1-U interface) between the CU (310) and the first RLC entity at the first RLC entity.

[0129] In one embodiment, the CU (310) may transmit downlink user data (DUD) to the first RLC entity, including a packet, a sequence number, and / or a report polling field (or, a parameter, an information element (IE)). In one example, the DUD may be referred to as protocol data unit (PDU) type 0. For example, the report polling field may indicate whether a request for the provision of DDDS is made. While transmitting DUDs containing packets, the report polling field may indicate that a request for the provision of DDDS is not made.

[0130] In one embodiment, the CU (310) may, after transmitting the packets to the first RLC entity, transmit a DUD to the first RLC entity that includes a reporting polling field indicating a request for DDDS. For example, the DUD for requesting DDDS may be transmitted periodically. In one example, the first period for transmitting the DUD for requesting DDDS may be predefined. The CU (310) may obtain DDDS from the first RLC entity in response to the DUD for requesting DDDS. In one example, the DDDS may be referred to as PDU type 1. For example, the DDDS may include information about packets lost on a first interface (e.g., F1-U interface) between the CU (310) and the first RLC entity. For example, information about lost packets may include the number of one or more lost sequence number ranges, the start sequence number of the corresponding range, and / or the end sequence number of the corresponding range.

[0131] In operation 702, a CU (310) according to one embodiment can obtain DDDS from a second RLC entity (e.g., the second DU (520) of FIG. 5).

[0132] In one embodiment, the CU (310) may assign sequence numbers to packets (e.g., downlink packets). For example, the CU (310) may assign consecutive sequence numbers to each packet. For example, the sequence number may be an NR-U sequence number. The NR-U sequence number may be used to detect lost packets on a second interface (e.g., F1-U interface) between the CU (310) and the second RLC entity at the second RLC entity.

[0133] In one embodiment, the CU (310) may transmit a DUD to the second RLC entity that includes a packet, a sequence number, and / or a report polling field (or, parameter, IE). In one example, the DUD may be referred to as PDU type 0. For example, the report polling field may indicate whether to request the provision of DDDS. While transmitting DUDs containing packets, the report polling field may indicate that not to request the provision of DDDS. For example, packets transmitted through the second RLC entity may be different from packets transmitted through the first RLC entity described in operation 701. For example, the PDCP sequence numbers of packets transmitted through the first RLC entity and the PDCP SNs of packets transmitted through the second RLC entity may be different. The packets transmitted through the first RLC entity and the packets transmitted through the second RLC entity can be reordered at the terminal (120) as described in FIG. 4.

[0134] In one embodiment, the CU (310) may, after transmitting the packets to the second RLC entity, transmit a DUD to the second RLC entity that includes a report polling field indicating a request for DDDS. For example, the DUD for requesting DDDS may be transmitted periodically. In one example, the period for transmitting the DUD for requesting DDDS may be the same as or different from the first period described above. The CU (310) may obtain DDDS from the second RLC entity in response to the DUD for requesting DDDS. In one example, the DDDS may be referred to as PDU type 1. For example, the DDDS may include information about packets lost on a second interface (e.g., F1-U interface) between the CU (310) and the second RLC entity. For example, information about lost packets may include the number of one or more lost sequence number ranges, the start sequence number of the range, and / or the end sequence number of the range.

[0135] In operation 703, the CU (310) according to one embodiment can determine a first loss rate for packets transmitted through the first RLC entity and a second loss rate for packets transmitted through the second RLC entity.

[0136] In one embodiment, the CU (310) may determine a first loss rate for packets transmitted through the first RLC entity based on DDDS obtained from the first RLC entity. For example, the CU (310) may determine the number of lost packets among the packets transmitted through the first RLC entity based on information about lost packets included in the DDDS. In one example, the CU (310) may flush packets stored in the PDCP buffer before obtaining the DDDS based on the expiration of a timer. In one example, the lost packets may be packets among the packets indicated by the DDDS that cannot be retransmitted due to a PDCP buffer flush. The CU (310) may determine the first loss rate by determining the number of lost packets per unit time. In one example, the unit time may be configurable.

[0137] In one embodiment, the CU (310) may determine a second loss rate for packets transmitted through the second RLC entity based on the DDDS obtained from the second RLC entity. For example, the CU (310) may determine the number of lost packets among the packets transmitted through the second RLC entity based on information about lost packets included in the DDDS. In one example, the lost packets may be packets among the packets indicated by the DDDS that cannot be retransmitted due to PDCP buffer flushing. The CU (310) may determine the second loss rate by determining the number of lost packets per unit time. In one example, the unit time may be configurable. However, the method of determining the loss rate as described above is merely an example, and the present disclosure is not limited thereto. For example, the loss rate may be determined in various ways based on the number of lost packets.

[0138] In operation 704, the CU (310) according to one embodiment can determine whether the difference between the first loss rate and the second loss rate exceeds a threshold rate. For example, if the difference between the first loss rate and the second loss rate exceeds a threshold rate, latency due to PDCP sequence number reordering may be caused at the terminal (120).

[0139] In operation 705, the CU (310) according to one embodiment may perform PDCP duplication upon determining that the difference between the first loss ratio and the second loss ratio exceeds a threshold ratio.

[0140] In one embodiment, CU (310) can determine whether the first loss ratio exceeds the second loss ratio based on the determination that the difference between the first loss ratio and the second loss ratio exceeds the threshold ratio.

[0141] For example, a first loss rate exceeding a second loss rate may indicate that the loss of packets transmitted through the first RLC entity causes delays due to PDCP reordering and TCP (transmission control protocol) performance degradation at the terminal (120). Therefore, the CU (310) may duplicate packets to be transmitted through the first RLC entity upon determining that the first loss rate exceeds the second loss rate. The CU (310) may transmit packets through the first RLC entity and duplicate packets through the second RLC entity. As described above, if packet loss is relatively large on the first interface between the CU (310) and the first RLC entity, the CU (310) may perform PDCP duplication on packets to be transmitted through the first interface. Since the packets are transmitted not only through the first interface but also through the second interface between the CU (310) and the second RLC entity, delay and TCP performance degradation due to PDCP reordering at the terminal (120) can be reduced.

[0142] In another example, a second loss rate exceeding a first loss rate may indicate that the loss of packets transmitted through the second RLC entity causes delays and TCP performance degradation due to PDCP reordering at the terminal (120). Therefore, the CU (310) may duplicate packets to be transmitted through the second RLC entity upon determining that the second loss rate exceeds the first loss rate. The CU (310) may transmit packets through the second RLC entity and duplicate packets through the first RLC entity. As described above, if packet loss is relatively large on the second interface between the CU (310) and the second RLC entity, the CU (310) may perform PDCP duplication on packets to be transmitted through the second interface. Since the packets are transmitted not only through the second interface but also through the first interface between the CU (310) and the first RLC entity, delay and TCP performance degradation due to PDCP reordering at the terminal (120) can be reduced.

[0143] In operation 706, the CU (310) according to one embodiment may wait until the next period based on the determination that the difference between the first loss ratio and the second loss ratio is less than or equal to a threshold ratio. For example, the CU (310) may perform operation 701 after waiting until the next period.

[0144] FIG. 8 is a flowchart illustrating the operations of a CU for performing PDCP replication. The operations of FIG. 8 may be performed by a CU (central unit) (310). For example, at least some of the operations may be performed by a processor (601) of the CU (310). In the following description, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed. For example, at least two operations may be performed in parallel. In the following description, the operations of FIG. 8 are described as being performed by the CU (310), but the present disclosure is not limited thereto. For example, the operations of FIG. 8 may be performed by a base station (110) configured to perform the functions of the CU (310) and the functions of the DU (distributed unit) (320). The operations described in FIG. 8 may correspond to at least some of the operations 705 of FIG. 7.

[0145] Referring to FIG. 8, in operation 801, a CU (310) according to one embodiment may determine whether a first loss rate exceeds a second loss rate. For example, the CU (310) may be connected to a first DU (distributed unit) (510) and a second DU (520) via a split bearer as shown in FIG. 5b. The first loss rate may represent the packet loss rate per unit time on a first interface (e.g., F1-U interface) between the CU (310) and the first DU (510). The second loss rate may represent the packet loss rate per unit time on a second interface (e.g., F1-U interface) between the CU (310) and the second DU (520). In one example, the first DU (510) may be referred to as a first RLC (radio link control) entity. In one example, the second DU (520) may be referred to as the second RLC entity.

[0146] In one embodiment, the CU (310) may determine a first loss rate. For example, after transmitting packets to the first DU (510), the CU (310) may transmit downlink user data (DUD) to the first DU (510), including a report polling field indicating a request for downlink data delivery status (DDDS). In one example, the DUD may be referred to as protocol data unit (PDU) type 0. For example, the DUD for requesting DDDS may be transmitted periodically. The first period for transmitting the DUD for requesting DDDS may be predefined. The CU (310) may obtain DDDS from the first DU (510) in response to the DUD for requesting DDDS. In one example, the DDDS may be referred to as PDU type 1. For example, the DDDS may include information about lost packets on the first interface between the CU (310) and the first DU (510). For example, the information about lost packets may include the number of one or more lost sequence number ranges, the start sequence number of the corresponding range, and / or the end sequence number of the corresponding range. In one example, regarding the information about lost packets, Section 5.5.2.2 of 3GPP (3rd generation partnership project) TS (technical specification) 38.425 may be referenced. For example, the CU (310) may determine the number of lost packets among the packets transmitted through the first DU (510) based on the DDDS. In one example, the CU (310) may flush the packets stored in the PDCP buffer based on the expiration of a timer before acquiring the DDDS.In one example, the lost packets may be packets among the packets marked by DDDS that cannot be retransmitted due to a PDCP buffer flush. The CU (310) may determine a first loss rate by determining the number of lost packets per unit time. In one example, the unit time may be configurable.

[0147] In one embodiment, the CU (310) may determine a second loss rate. For example, after transmitting packets to the second DU (520), the CU (310) may transmit a DUD to the second DU (520) that includes a report polling field indicating a request for DDDS. For example, the DUD for requesting DDDS may be transmitted periodically. The period for transmitting the DUD for requesting DDDS may be the same as or different from the first period described above. The CU (310) may obtain DDDS from the second DU (520) in response to the DUD for requesting DDDS. For example, the DDDS may include information about packets lost on the second interface between the CU (310) and the second DU (520). For example, information regarding lost packets may include the number of one or more lost sequence number ranges, the start sequence number of the range, and / or the end sequence number of the range. The CU (310) may determine the number of lost packets among the packets transmitted through the second DU (520) based on the DDDS. In one example, the CU (310) may flush packets stored in the PDCP buffer prior to acquiring the DDDS based on the expiration of a timer. In one example, the lost packets may be packets among the packets indicated by the DDDS that cannot be retransmitted due to the PDCP buffer flush. The CU (310) may determine a second loss rate by determining the number of lost packets per unit time. However, the method of determining the loss rate as described above is merely an example and the present disclosure is not limited thereto. For example, the loss rate may be determined in various ways based on the number of lost packets.

[0148] In one embodiment, CU (310) can determine whether the first loss ratio exceeds the second loss ratio.

[0149] For example, a first loss ratio exceeding a second loss ratio may indicate that packet loss on the first interface between the CU (310) and the first DU (510) causes latency and TCP (transmission control protocol) performance degradation due to PDCP (packet data convergence) reordering at the terminal (120).

[0150] In another example, a second loss rate exceeding a first loss rate may indicate that packet loss on the second interface between the CU (310) and the second DU (520) causes delay and TCP performance degradation due to PDCP reordering at the terminal (120).

[0151] In operation 802, according to one embodiment, the CU (310) may transmit packets through both the first transmission path and the second transmission path based on duplicating packets to be transmitted through the first transmission path upon determining that the first loss rate exceeds the second loss rate. For example, the CU (310) may transmit packets through the first DU (510) and duplicated packets through the second DU (520). As described above, if the packet loss at the first interface between the CU (310) and the first DU (510) is relatively large, the CU (310) may perform PDCP duplication on the packets to be transmitted through the first interface. Since the packets are transmitted not only through the first interface but also through the second interface between the CU (310) and the second DU (520), delay and TCP performance degradation due to PDCP reordering at the terminal (120) may be reduced.

[0152] In operation 803, according to one embodiment, the CU (310) may transmit packets through both the first transmission path and the second transmission path based on duplicating packets to be transmitted through the second transmission path according to a determination that the first loss rate is less than or equal to the second loss rate. For example, the CU (310) may transmit packets through the second DU (520) and duplicate packets through the first DU (510). As described above, if packet loss is relatively large at the second interface between the CU (310) and the second DU (520), the CU (310) may duplicate packets to be transmitted through the second interface. Since the packets are transmitted not only through the second interface but also through the first interface between the CU (310) and the first DU (510), delay and TCP performance degradation due to PDCP reordering at the terminal (120) may be reduced.

[0153] FIG. 9 is a flowchart illustrating the operations of a CU for stopping PDCP replication. The operations of FIG. 9 may be performed by a CU (central unit) (310). For example, at least some of the operations may be performed by a processor (601) of the CU (310). In the following description, each operation may be performed sequentially, but is not necessarily performed sequentially. For example, the order of each operation may be changed. For example, at least two operations may be performed in parallel. In the following description, the operations of FIG. 9 are described as being performed by the CU (310), but the present disclosure is not limited thereto. For example, the operations of FIG. 9 may be performed by a base station (110) configured to perform the functions of the CU (310) and the functions of the DU (distributed unit) (320). The operations described in FIG. 9 may be performed subsequently to operation 705 of FIG. 7 or operation 802 (or operation 803) of FIG. 8.

[0154] Referring to FIG. 9, in operation 901, a CU (310) according to one embodiment may determine a third loss rate for packets transmitted through a first RLC (radio link control) entity and a fourth loss rate for packets transmitted through a second RLC entity while PDCP (packet data convergence protocol) duplication is performed. For example, the CU (310) may be connected to a first DU (distributed unit) (510) and a second DU (520) via a split bearer as shown in FIG. 5b. For example, the first RLC entity may be the first DU (510). The second RLC entity may be the second DU (520). For example, the third loss ratio may represent the packet loss ratio per unit time on the first interface (e.g., F1-U interface) between the CU (310) and the first RLC entity. The fourth loss ratio may represent the packet loss ratio per unit time on the second interface (e.g., F1-U interface) between the CU (310) and the second RLC entity.

[0155] In one embodiment, the CU (310) may determine a third loss rate. For example, after transmitting packets to the first RLC entity, the CU (310) may transmit downlink user data (DUD) to the first RLC entity, including a report polling field indicating a request for downlink data delivery status (DDDS). In one example, the DUD may be referred to as protocol data unit (PDU) type 0. For example, the DUD for requesting DDDS may be transmitted periodically. The first period for transmitting DDDS may be predefined. The CU (310) may obtain DDDS from the first RLC entity in response to the DUD for requesting DDDS. In one example, the DDDS may be referred to as PDU type 1. For example, the DDDS may include information about lost packets on a first interface between the CU (310) and the first RLC entity. For example, the information about lost packets may include the number of one or more lost sequence number ranges, the start sequence number of the corresponding range, and / or the end sequence number of the corresponding range. Based on the information about the lost packets, the CU (310) may determine the number of lost packets among the packets transmitted to the first RLC entity. In one example, the CU (310) may flush the packets stored in the PDCP buffer based on the expiration of a timer before acquiring the DDDS. In one example, the lost packets may be packets among the packets indicated by the DDDS that cannot be retransmitted due to the PDCP buffer flush. The CU (310) may determine a first loss rate by determining the number of lost packets per unit time.In one example, the unit time can be configured.

[0156] In one embodiment, the CU (310) may determine a fourth loss rate. For example, after transmitting packets to the second RLC entity, the CU (310) may transmit a DUD to the second RLC entity that includes a report polling field indicating a request for DDDS. For example, the DUD for requesting DDDS may be transmitted periodically. The period for transmitting the DUD for requesting DDDS may be the same as the first period described above. The CU (310) may obtain DDDS from the second RLC entity in response to the DUD for requesting DDDS. For example, the DDDS may include information about packets lost on the second interface between the CU (310) and the second DU (520). For example, the information about the lost packets may include the number of one or more loss sequence number ranges, the start sequence number of the range, and / or the end sequence number of the range. CU (310) can determine the number of lost packets among the packets transmitted to the second RLC entity based on information regarding the lost packets. In one example, CU (310) can flush the packets stored in the PDCP buffer based on the expiration of a timer before acquiring the DDDS. In one example, the lost packets may be packets among the packets indicated by the DDDS that cannot be retransmitted due to the PDCP buffer flush. CU (310) can determine the fourth loss rate by determining the number of lost packets per unit time. However, the method of determining the loss rate as described above is merely an example and the present disclosure is not limited thereto. For example, the loss rate may be determined in various ways based on the number of lost packets.

[0157] In operation 902, the CU (310) according to one embodiment can determine whether the difference between the third loss ratio and the fourth loss ratio exceeds a threshold ratio.

[0158] In operation 903, the CU (310) according to one embodiment may continue to perform PDCP replication upon determining that the difference between the third loss rate and the fourth loss rate exceeds a threshold rate. For example, if the difference exceeds a threshold rate, delay and TCP performance degradation due to PDCP reordering may be caused at the terminal (120) by the difference between the loss rate of the first transmission path associated with the first RLC entity and the loss rate of the second transmission path associated with the second RLC entity. Therefore, the CU (310) may reduce the delay and TCP performance degradation due to PDCP reordering by continuing to perform PDCP replication.

[0159] In operation 904, the CU (310) according to one embodiment may refrain from performing PDCP replication based on the determination that the difference between the third loss rate and the fourth loss rate is less than a threshold rate. For example, if the difference is less than or equal to the threshold rate, the delay and TCP performance degradation due to PDCP reordering at the terminal (120) may be reduced by the difference between the loss rate of the first transmission path associated with the first RLC entity and the loss rate of the second transmission path associated with the second RLC entity. Therefore, the CU (310) may stop performing PDCP replication.

[0160] The technical problems to be solved in this disclosure are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which this disclosure belongs.

[0161] A central unit (CU) including a packet data convergence protocol (PDCP) entity as described above may include a communication circuit. The CU may include a memory that stores instructions and includes one or more storage media. The CU may include at least one processor including a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a first downlink data delivery status (DDDS) from a first radio link control (RLC) entity connected to the PDCP entity via a split bearer. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a second DDDS from a second RLC entity connected to the PDCP entity via the split bearer. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity based on the first DDDS. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity based on the second DDDS.When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the packets to be transmitted through both the first transmission path and the second transmission path based on the determination that the difference between the first loss rate and the second loss rate exceeds a threshold rate, by duplicating the packets to be transmitted through the transmission path associated with the higher loss rate between the first loss rate and the second loss rate.

[0162] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to send downlink user data (DUD) to the first RLC entity, including report polling for requesting the first DDDS. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to send DUD to the second RLC entity, including report polling for requesting the second DDDS.

[0163] For example, the first DDDS may include information regarding the range of first packets lost on a first interface between the PDCP entity and the first RLC entity. The second DDDS may include information regarding the range of second packets lost on a second interface between the PDCP entity and the second RLC entity.

[0164] For example, the range of the first packets lost on the first interface may be indicated based on the start sequence of the first packets and the end sequence of the first packets. The range of the second packets lost on the second interface may be indicated based on the start sequence of the second packets and the end sequence of the second packets.

[0165] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the first packets and the second packets to be flushed from the buffer of the PDCP entity before acquiring the first DDDS and the second DDDS.

[0166] For example, the first transmission path between the PDCP entity and the first RLC entity may include one or more first routers and one or more first switches. The second transmission path between the PDCP entity and the second RLC entity may include one or more second routers and one or more second switches.

[0167] For example, at least some of the packets transmitted through the first transmission path may be lost on the first transmission path. At least some of the packets transmitted through the second transmission path may be lost on the second transmission path.

[0168] For example, when the instructions are executed individually or collectively by the at least one processor, the CU may cause the packets to be transmitted through the first transmission path to be duplicated upon a determination that the first loss rate exceeds the second loss rate. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the packets to be transmitted through the first transmission path. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the duplicated packets to be transmitted through the second transmission path.

[0169] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a third DDDS from the first RLC entity connected to the PDCP entity through the split bearer. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to obtain a fourth DDDS from the second RLC entity connected to the PDCP entity through the split bearer. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a third loss rate for packets transmitted through the first transmission path based on the third DDDS. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine a fourth loss rate for packets transmitted through the second transmission path based on the fourth DDDS. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to refrain from duplicating packets to be transmitted through the first transmission path based on the determination that the difference between the third loss rate and the fourth loss rate is less than or equal to the threshold rate.

[0170] For example, the first RLC entity may be configured within the first DU (distributed unit). The second RLC entity may be configured within the second DU.

[0171] A method performed by a central unit (CU) including a packet data convergence protocol (PDCP) entity as described above may include an operation of obtaining a first downlink data delivery status (DDDS) from a radio link control (RLC) entity connected to the PDCP entity through a split bearer. The method may include an operation of obtaining a second DDDS from a second RLC entity connected to the PDCP entity through the split bearer. The method may include an operation of determining a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity based on the first DDDS. The method may include an operation of determining a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity based on the second DDDS. The above method may include the operation of transmitting said packets through both the first transmission path and the second transmission path, based on duplicating said packets to be transmitted through the transmission path associated with the higher of the first loss ratio and the second loss ratio, according to a determination that the difference between said first loss ratio and the second loss ratio exceeds a threshold ratio.

[0172] For example, the above method may include the operation of transmitting downlink user data (DUD) to the first RLC entity, including report polling for requesting the first DDDS. The above method may include the operation of transmitting DUD to the second RLC entity, including report polling for requesting the second DDDS.

[0173] For example, the first DDDS may include information regarding the range of first packets lost on a first interface between the PDCP entity and the first RLC entity. The second DDDS may include information regarding the range of second packets lost on a second interface between the PDCP entity and the second RLC entity.

[0174] For example, the range of the first packets lost on the first interface may be indicated based on the start sequence of the first packets and the end sequence of the first packets. The range of the second packets lost on the second interface may be indicated based on the start sequence of the second packets and the end sequence of the second packets.

[0175] For example, the above method may include the operation of flushing the first packets and the second packets from the buffer of the PDCP entity before acquiring the first DDDS and the second DDDS.

[0176] For example, the first transmission path between the PDCP entity and the first RLC entity may include one or more first routers and one or more first switches. The second transmission path between the PDCP entity and the second RLC entity may include one or more second routers and one or more second switches.

[0177] For example, at least some of the packets transmitted through the first transmission path may be lost on the first transmission path. At least some of the packets transmitted through the second transmission path may be lost on the second transmission path.

[0178] For example, the above method may include an operation of duplicating packets to be transmitted through the first transmission path based on a determination that the first loss rate exceeds the second loss rate. The above method may include an operation of transmitting the packets through the first transmission path. The above method may include an operation of transmitting the duplicated packets through the second transmission path.

[0179] For example, the method may include an operation of obtaining a third DDDS from the first RLC entity connected to the PDCP entity through the split bearer. The method may include an operation of obtaining a fourth DDDS from the second RLC entity connected to the PDCP entity through the split bearer. The method may include an operation of determining a third loss rate for packets transmitted through the first transmission path and a fourth loss rate for packets transmitted through the second transmission path based on the third DDDS and the fourth DDDS. The method may include an operation of refraining from duplicating packets to be transmitted through the first transmission path based on a determination that the difference between the third loss rate and the fourth loss rate is less than or equal to the threshold rate.

[0180] For example, the first RLC entity may be configured within the first DU (distributed unit). The second RLC entity may be configured within the second DU.

[0181] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs.

[0182] For one or more embodiments, at least one of the components described in one or more of the prior art drawings may be configured to perform one or more operations, techniques, processes and / or methods as described in the present disclosure. For example, a processor (e.g., a baseband processor) described in the present disclosure in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described in the present disclosure. As another example, circuits associated with user equipment (UE), a base station, a network element, etc., as described above in relation to one or more of the prior art drawings may be configured to operate according to one or more examples described herein.

[0183] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless otherwise explicitly stated. The foregoing description of one or more embodiments is for illustrative and explanatory purposes only, and is not intended to limit or exhaust the scope of the embodiments in the exact form disclosed. Modifications and variations are possible in light of the foregoing teachings or may be obtained from the practice of various embodiments.

[0184] Methods according to the claims or embodiments described in the specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0185] When implemented in software, a computer-readable storage medium (e.g., a non-transient computer-readable storage medium) storing one or more programs (software modules) may be provided. One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the claims or embodiments described in the specification of this disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0186] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0187] Additionally, the program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, LAN (local area network), WAN (wide area network), or SAN (storage area network), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present disclosure.

[0188] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0189] According to the embodiments, one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added. Generally or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components in the same or similar manner as those performed by the corresponding component among the plurality of components prior to the integration. According to the embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0190] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure.

Claims

1. In a central unit (CU) including a packet data convergence protocol (PDCP) entity, Communication circuit; Memory for storing instructions and including one or more storage media; and It includes at least one processor comprising a processing circuit, and When the above instructions are executed individually or collectively by the at least one processor, the CU, Obtaining a first DDDS (downlink data delivery status) from a first RLC (radio link control) entity connected to the above PDCP entity through a split bearer, and Obtain a second DDDS from a second RLC entity connected through the above PDCP entity and the above split bearer, and Based on the first DDDS above, a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity is determined, and Based on the second DDDS above, determine a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity, and Based on the determination that the difference between the first loss ratio and the second loss ratio exceeds a threshold ratio, causing the packets to be transmitted through both the first transmission path and the second transmission path by duplicating the packets to be transmitted through the transmission path associated with the higher loss ratio between the first loss ratio and the second loss ratio. CU.

2. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Sending DUD (downlink user data) including report polling to request the first DDDS to the first RLC entity, and Causing to transmit a DUD to the second RLC entity, including a report polling to request the second DDDS. CU.

3. In Paragraph 1, The first DDDS includes information regarding the range of first packets lost on a first interface between the PDCP entity and the first RLC entity, and The second DDDS includes information regarding the range of second packets lost on the second interface between the PDCP entity and the second RLC entity, CU.

4. In Paragraph 3, The range of the first packets lost on the first interface is indicated based on the start sequence of the first packets and the end sequence of the first packets, and The range of the second packets lost on the second interface is indicated based on the start sequence of the second packets and the end sequence of the second packets, CU.

5. In Paragraph 3, When the above instructions are executed individually or collectively by the at least one processor, the CU, Causing the first packets and the second packets to be flushed from the buffer of the PDCP entity before acquiring the first DDDS and the second DDDS, CU.

6. In Paragraph 1, The first transmission path between the PDCP entity and the first RLC entity includes one or more first routers and one or more first switches, and The second transmission path between the PDCP entity and the second RLC entity comprises one or more second routers and one or more second switches, CU.

7. In Paragraph 6, At least some of the packets transmitted through the first transmission path are lost on the first transmission path, and At least some of the packets transmitted through the second transmission path are lost on the second transmission path, CU.

8. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Based on the determination that the first loss ratio exceeds the second loss ratio, the packets to be transmitted through the first transmission path are duplicated, and The above packets are transmitted through the first transmission path, and Causing the above duplicated packets to be transmitted through the second transmission path, CU.

9. In Paragraph 8, When the above instructions are executed individually or collectively by the at least one processor, the CU, Obtain a third DDDS from the first RLC entity connected through the PDCP entity and the split bearer, and Obtain a fourth DDDS from the second RLC entity connected through the PDCP entity and the split bearer, and Based on the above third DDDS, a third loss rate for packets transmitted through the first transmission path is determined, and Based on the above-mentioned fourth DDDS, a fourth loss rate for packets transmitted through the above-mentioned second transmission path is determined, and Causing to refrain from duplicating packets to be transmitted through the first transmission path based on the determination that the difference between the third loss ratio and the fourth loss ratio is less than or equal to the threshold ratio, CU.

10. In Paragraph 1, The above-mentioned first RLC entity is configured within the first DU (distributed unit), and The above second RLC entity is configured within the second DU, CU.

11. A method performed by a central unit (CU) including a packet data convergence protocol (PDCP) entity, An operation to obtain a first DDDS (downlink data delivery status) from a first RLC (radio link control) entity connected to the above PDCP entity through a split bearer; The operation of obtaining a second DDDS from a second RLC entity connected through the above PDCP entity and the above split bearer; An operation to determine a first loss rate for packets transmitted through a first transmission path between the PDCP entity and the first RLC entity based on the first DDDS; An operation to determine a second loss rate for packets transmitted through a second transmission path between the PDCP entity and the second RLC entity based on the second DDDS; and Based on a determination that the difference between the first loss ratio and the second loss ratio exceeds a threshold ratio, the operation of transmitting said packets through both the first transmission path and the second transmission path, wherein the packets to be transmitted through the transmission path associated with the higher loss ratio between the first loss ratio and the second loss ratio are duplicated. method.

12. In Paragraph 11, The operation of transmitting DUD (downlink user data) including report polling for requesting the first DDDS to the first RLC entity; and Further including the operation of transmitting a DUD to the second RLC entity, which includes a report polling to request the second DDDS. method.

13. In Paragraph 11, The first DDDS includes information regarding the range of first packets lost on a first interface between the PDCP entity and the first RLC entity, and The second DDDS includes information regarding the range of second packets lost on the second interface between the PDCP entity and the second RLC entity, method.

14. In Paragraph 13, The range of the first packets lost on the first interface is indicated based on the start sequence of the first packets and the end sequence of the first packets, and The range of the second packets lost on the second interface is indicated based on the start sequence of the second packets and the end sequence of the second packets, method.

15. In Paragraph 13, Further including the operation of flushing the first packets and the second packets from the buffer of the PDCP entity before acquiring the first DDDS and the second DDDS, method.

Images