Apparatus and method for performing traffic flow control on basis of wireless quality

Abstract

This central unit (CU) may comprise at least one processor. The at least one processor is configured to: transmit, to a radio link control (RLC) entity, a first message for requesting radio quality assistance information, according to a determination that an amount of downlink traffic stored in a buffer of a packet data convergence protocol (PDCP) entity of the CU exceeds a threshold value; determine, on the basis of receiving a second message including the radio quality assistance information from the RLC entity, whether congestion occurs in a downlink on the basis of the radio quality assistance information; and, according to a determination that the congestion occurs in the downlink, set an explicit congestion notification echo (ECE) flag in a transmission control protocol (TCP) header of uplink traffic, and then transmit the uplink traffic to a server.

Description

Device and method for performing traffic flow control based on wireless quality

[0001] The following descriptions relate to an apparatus and method for performing traffic flow control based on wireless quality.

[0002] When the radio quality between a terminal and the base station deteriorates, the base station may temporarily store some of the downlink traffic in a buffer of the PDCP (packet data convergence protocol) layer. In a new radio (NR) system, as the amount of downlink traffic related to the user increases, a buffer overflow may occur in the PDCP layer of the base station. As a result of the buffer overflow in the PDCP layer, some of the downlink traffic related to the user is lost, which may lead to a deterioration in the quality of service.

[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) is provided. The CU 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 that includes a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to transmit a first message to a radio link control (RLC) entity to request radio quality assistance information upon a determination that the amount of downlink traffic stored in the buffer of the packet data convergence protocol (PDCP) entity of the CU exceeds a threshold value. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine whether congestion occurs in the downlink based on the radio quality assistance information upon receiving a second message containing the radio quality assistance information from the RLC entity. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the uplink traffic to be sent to the server after setting the ECE (explicit congestion notification echo) flag in the TCP (transmission control protocol) header of the uplink traffic, based on the determination that the congestion occurs on the downlink.

[0005] A method performed by a CU is provided. The method may include the operation of sending a first message to a radio link control (RLC) entity to request radio quality assistance information upon the determination that the amount of downlink traffic stored in the buffer of the packet data convergence protocol (PDCP) entity of the CU exceeds a threshold value. The method may include the operation of determining whether congestion occurs in the downlink based on the radio quality assistance information upon receiving a second message containing the radio quality assistance information from the RLC entity. The method may include the operation of sending the uplink traffic to a server after setting an explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic upon the determination that congestion occurs in the downlink.

[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 the network architecture.

[0011] Figure 5 illustrates the components of the CU.

[0012] Figure 6 is a flowchart showing the operations of the CU to reduce the TCP window size of the server.

[0013] Figure 7 illustrates signaling to reduce the TCP window size of the server.

[0014] FIG. 8 illustrates a block diagram for explaining the operations of a CU to reduce the TCP window size of a server.

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

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

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

[0018] 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"}.

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

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

[0021] 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).

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

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

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

[0025] 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 impart 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.

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

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

[0028] 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).

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

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

[0031] 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).

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

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

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

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

[0036] - 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).

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

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

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

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

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

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

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

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

[0045] - Retransmission of PDCP SDUs

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

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

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

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

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

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

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

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

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

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

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

[0057] - Duplicate detection

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

[0059] - RLC SDU discard function

[0060] RLC re-establishment function

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

[0062] 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).

[0063] 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).

[0064] 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).

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

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

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

[0068] - Scheduling information reporting function

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

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

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

[0072] - MBMS service identification function

[0073] - Transport format selection function

[0074] - Padding

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

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

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

[0078] 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).

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

[0080] FIG. 4 illustrates a network architecture. For example, the network architecture of FIG. 4 illustrates a standalone (SA) deployment structure (401) and a non-standalone (NSA) deployment structure (402).

[0081] Referring to the SA structure (401), the terminal (120) can be configured in a single connection using the base station (410). For example, the base station (410) can receive downlink traffic from a server. In one example, the downlink traffic may be referred to as S1 traffic. The packet data convergence protocol (PDCP) layer (411) of the base station (410) can distribute the downlink traffic to the radio link control (RLC) layer (412). For example, the PDCP layer (411) of the base station (410) can distribute the downlink traffic to the RLC layer (412) based on the downlink data delivery status (DDDS) (or desired buffer size (DBS) included in the DDDS) obtained from the RLC layer (412). In one example, some of the downlink traffic is provided to the RLC layer (412), and some of the downlink traffic may be temporarily stored in a buffer of the PDCP layer (411). By temporarily storing some of the downlink traffic in the buffer of the PDCP layer (411), loss of downlink traffic can be prevented. In an example that is not limited, the SA structure (401) may be implemented as a distributed deployment according to a central unit (CU) (310) that performs the functions of the PDCP layer (411) and a DU (320) that performs the functions of the RLC layer (412).

[0082] Referring to the NSA structure (402), the terminal (120) may be configured with dual connectivity (DC) utilizing the base station (420) and the base station (430). 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, and utilizing frequency resources on the component carriers of the 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., base station (420) and base station (430)) and utilize the 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., base station (420) and / or base station (430). One of the nodes may be a master node (MN) and the other may be a secondary node (SN). The MN and 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.

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

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

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

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

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

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

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

[0090] A base station (420) can receive downlink traffic from a server. In one example, the downlink traffic may be referred to as S1 traffic. The PDCP layer (421) of the base station (420) can distribute downlink traffic to the RLC layer (422) and the RLC layer (431). For example, the PDCP layer (421) can distribute downlink traffic to the RLC layer (422) and the RLC layer (431) based on the DDDS (or DBS included in the DDDS) obtained from the RLC layer (422) and the DDDS (or DBS included in the DDDS) obtained from the RLC layer (431). In one example, some of the downlink traffic is distributed to the RLC layer (422) and the RLC layer (431), and some of the downlink traffic may be temporarily stored in the buffer of the PDCP layer (421). Loss of downlink traffic can be prevented by temporarily storing some of the downlink traffic in a buffer of the PDCP layer (421). In examples not limited to, the NSA structure (402) can be implemented as a distributed deployment according to a central unit (CU) (310) that performs the functions of the PDCP layer (421), a DU (320) that performs the functions of the RLC layer (422), and a DU that performs the functions of the RLC layer (422).

[0091] As described above, the PDCP layer (411, 421) can prevent the loss of downlink traffic by temporarily storing a portion of the downlink traffic in a buffer. However, due to the development of wireless communication technology, the amount of downlink traffic is increasing. As the amount of downlink traffic increases, a buffer overflow may occur in the PDCP layer (411, 421). As a result of the buffer overflow occurring in the PDCP layer (411, 421), some of the downlink traffic related to the terminal (120) is lost, which may degrade the quality of service.

[0092] To prevent loss of downlink traffic, traffic flow control may be used. Traffic flow control may be performed in an end-to-end manner. In one example, a base station (410, 420) may set the explicit congestion notification (ECN) field of the internet protocol (IP) header of the downlink traffic to congestion experienced (CE) (e.g., 11). After setting the ECN field of the downlink traffic IP header to CE, the base station (410, 420) may transmit the corresponding downlink traffic to a terminal (120). Based on the ECN field set to CE, the terminal (120) may set the explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic and then transmit the uplink traffic to a server. The server may reduce the TCP window size (or congestion window size) in response to receiving uplink traffic with the ECE flag set. By reducing the TCP window size (or congestion window size), the amount of downlink traffic may be reduced.

[0093] As described above, since traffic flow control is performed in an end-to-end manner, buffer overflow may not be prevented in advance. For example, a buffer overflow may occur in the PDCP layer (411, 412) while traffic flow control is performed through signaling between the base station (410, 420) and the terminal (120) as described above. For example, since immediate traffic flow control cannot be performed at the base station (410, 420), a buffer overflow may occur in the PDCP layer (411, 412). To prevent buffer overflow from occurring, traffic flow control needs to be performed at the base station (410, 420). To perform traffic flow control at the base station (410, 420), the buffer state and radio quality of the PDCP layer (411, 421) may be utilized. In the following, a device and method for preventing buffer overflow from occurring in advance by requesting the server to reduce the TCP window size (or congestion window size) based on the buffer state and wireless quality of the PDCP layer (411, 421) are described.

[0094] Figure 5 illustrates the components of the CU.

[0095] Referring to FIG. 5, the CU (310) may include a processor (501), a memory (502), and a transceiver (503). For example, the processor (501), the memory (502), and the transceiver (503) 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 (502) and / or transceiver (503)) is controlled by a first hardware component (e.g., processor (501)). The hardware components illustrated in FIG. 5 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. 2 (e.g., processor (501), memory (502) and / or transceiver (503)) may be included in a single integrated circuit such as a system on chip (SoC) or a system in package (SIP).

[0096] In one embodiment, the CU (310) may include a processor (501). The processor (501) may include a hardware component for processing data based on one or more instructions. The processor (501) 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 the 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 other 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.

[0097] In one embodiment, the CU (310) may include a memory (502). The memory (502) may include a hardware component for storing data and / or instructions that are input to or output from the processor (501). For example, the memory (502) 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).

[0098] In one embodiment, one or more instructions (or commands) representing operations and / or operations performed by the processor (501) may be stored in the memory (502) 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 (502), and that one or more applications are stored in an executable format by the processor (501).

[0099] In one embodiment, the CU may include a transceiver (503). The transceiver (5035) may perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (503) 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 (503) 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., DU (320)) through the transceiver (503). The transceiver (503) may also perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (503) may perform conversion between a baseband signal and a bit sequence according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (503) generates complex symbols by encoding and modulating the transmitted bit sequence. Also, when receiving data, the transceiver (503) restores the received bit sequence by demodulating and decoding the baseband signal. Additionally, the transceiver (503) 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).

[0100] The transceiver (503) transmits and receives signals as described above. Accordingly, all or part of the transceiver (503) 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 (503) is shown in FIG. 5, according to other embodiments, the CU (310) may include two or more transceivers.

[0101] The configuration of the CU (310) shown in FIG. 5 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. 5. In some embodiments, some configurations may be added, deleted, or changed. The descriptions of the processor (501), memory (502), and transceiver (503) of FIG. 5 may be applied in the same way to the processor, memory, and transceiver of the base station (110) of FIG. 1.

[0102] FIG. 6 is a flowchart illustrating the operations of a CU for reducing the TCP window size of a server. The operations of FIG. 6 may be performed by the CU (central unit) (310) of FIG. 5. For example, at least some of the operations may be controlled by the processor (501) of the CU (310). In the following, 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, the operations of FIG. 6 are described as being performed by the CU (310), but the present disclosure is not limited thereto. For example, the operations of FIG. 6 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).

[0103] Referring to FIG. 6, in operation 601, a CU (310) according to one embodiment can determine whether the buffer occupancy of a PDCP (packet data convergence protocol) entity exceeds a threshold value. For example, the buffer occupancy may represent the amount of downlink traffic stored in the buffer of the PDCP entity. For example, the threshold value may be predefined.

[0104] In one embodiment, the CU (310) may receive downlink traffic from a server (or application server). The downlink traffic may be received through an internet protocol (IP) network and a component of a core network (CN), such as a serving gateway (S-GW) or a user plane function (UPF). For example, the CU (310) may store at least a portion of the downlink traffic in a buffer based on a downlink data delivery status (DDDS) obtained from an RLC entity (or a desired buffer size (DBS) included in the DDDS). In one example, the DDDS may be referred to as a protocol data unit (PDU) type 1. The CU (310) may determine whether the amount of downlink traffic stored in the buffer of a PDCP entity exceeds a threshold value. In a non-limiting example, CU (310) can determine whether the buffer remaining capacity of a PDCP entity is below a threshold value. For example, the threshold value associated with the buffer remaining capacity and the threshold value associated with the buffer occupancy may be different from each other.

[0105] In one embodiment, the CU (310) may perform operation 602 upon determining that the buffer occupancy of the PDCP entity exceeds a threshold value. The CU (310) may perform operation 601 upon determining that the buffer occupancy of the PDCP entity is less than a threshold value. For example, the CU (310) may perform operation 601 when next downlink traffic is received. In another example, the CU (310) may perform operation 601 after a predefined time interval.

[0106] In operation 602, a CU (310) according to one embodiment may transmit (or provide) a first message to a radio link control (RLC) entity to request radio quality assistance information. For example, the CU (310) may transmit (or provide) a first message to the RLC entity to request radio quality assistance information upon determining that the buffer occupancy of a PDCP entity exceeds a threshold value. In one example, the first message may be referred to as downlink user data or PDU type 0. For example, the first message may include an information element (or parameter) for requesting radio quality assistance information. The IE (or parameter) may indicate whether radio quality assistance information is being requested. In one example, the IE may be referred to as an assistance information report polling flag. In one example, the IE (or parameter) may be set to 1 to request wireless quality assistance information. However, this is merely an example and the present disclosure is not limited thereto. For example, the IE (or parameter) may be set to 0 to request wireless quality assistance information.

[0107] In operation 603, a CU (310) according to one embodiment may receive a second message containing radio quality assistance information from an RLC entity. For example, the CU (310) may receive a second message containing radio quality assistance information from an RLC entity in response to a first message. In one example, the second message may be referred to as PDU type 2 or assistance information data. For example, the radio quality assistance information may include an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, an average HARQ retransmission, a DL (downlink) radio quality index, an average number of HARQ transmissions, or a combination thereof.

[0108] In operation 604, a CU (310) according to one embodiment may determine whether congestion occurs in the downlink. For example, the CU (310) may determine whether congestion occurs in the downlink based on wireless quality auxiliary information. For example, the CU (310) may determine that congestion has occurred in the downlink if it is determined that the terminal (120) is in a weak electric field based on wireless quality auxiliary information. In one example, the CU (310) may determine that congestion has occurred in the downlink based on the identification that the average CQI is below a threshold CQI. In one example, the CU (310) may determine that congestion has occurred in the downlink based on the identification that the average HARQ failure exceeds a threshold failure count. In one example, the CU (310) may determine that congestion has occurred on the downlink based on the identification that the average HARQ retransmission exceeds a threshold count. In one example, the CU (310) may determine that congestion has occurred on the downlink based on the identification that the DL radio quality index is below a threshold index. However, the examples described above are merely examples and the present disclosure is not limited thereto. For example, the CU (310) may determine whether congestion has occurred on the downlink based on the average CQI, average HARQ failures, average HARQ retransmissions, DL (downlink) radio quality index, and the average number of HARQ transmissions included in the radio quality auxiliary information.

[0109] In one embodiment, the CU (310) may perform operation 605 upon determining that congestion has occurred on the downlink. For example, the CU (310) may perform operation 601 upon determining that congestion has not occurred on the downlink. For example, the CU (310) may perform operation 601 when the next downlink traffic is received. In another example, the CU (310) may perform operation 601 after a predefined time interval.

[0110] In operation 605, a CU (310) according to one embodiment may send the uplink traffic to a server (or application server) after setting an explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic. For example, the CU (310) may send the uplink traffic to a server after setting an ECE flag in the TCP header of the uplink traffic based on a determination that congestion has occurred on the downlink.

[0111] In one embodiment, the CU (310) may receive uplink traffic from an RLC entity. For example, the uplink traffic may have the same flow and / or the same TCP session as the downlink that is congested. The uplink traffic may include a TCP header. In one example, the TCP header may be configured as shown in Table 1 below.

[0112] Source Port Destination Port Sequence Number Acknowledgment Number Header Length Reserved CWRECEURGACKPSHRSTSYNFIN Window Size TCP Checksum Urgent Pointer

[0113] Referring to Table 1, the TCP header may include a source port, a destination port, a sequence number, an acknowledgment number, a header length, reserved bits, a congestion window reduced (CWR), an explicit congestion notification echo (ECE), an urgent (URG), an acknowledgment (ACK), a push (PSH), a reset (RST), a synchronize (SYN), a finish (FIN), a window size, a TCP checksum, and an urgent pointer.

[0114] In one embodiment, the CU (310) may set an ECE flag in the TCP header of the uplink traffic upon determining that congestion has occurred in the downlink. For example, by setting an ECE flag in the TCP header of the uplink traffic, congestion avoidance action may be triggered by the server. Congestion avoidance action may involve reducing the server's TCP window size (or congestion window size). By reducing the server's TCP window size (or congestion window size), the transmission rate (or amount of data transmitted) of the downlink traffic may be reduced. By reducing the transmission rate (or amount of data transmitted) of the downlink traffic, a buffer overflow may be prevented in advance. In one example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 1. However, this is merely an example and the present disclosure is not limited thereto. For example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 0.

[0115] In one embodiment, since the value of the ECE flag is changed, the TCP checksum for verifying the integrity of the TCP segment needs to be changed. For example, the CU (310) can change the TCP checksum of the TCP header based on setting the ECE flag. The CU (310) can update the TCP checksum bits of the TCP header based on the determined TCP checksum.

[0116] In one embodiment, the CU (310) may send uplink traffic to the server having a TCP header with the ECE flag set. For example, the TCP header of the uplink traffic may include an ECE flag set to 1 and an updated TCP checksum. For example, the uplink traffic may be sent to the server through a component of the core network (e.g., S-GW or UPF) and an IP network.

[0117] In operation 606, a CU (310) according to one embodiment may receive downlink traffic from a server having a TCP header with a CWR (congestion window reduced) flag set. For example, the downlink traffic may be received through an IP network and a component of a core network (e.g., an S-GW or a UPF). In one example, the CWR flag may be an acknowledgment to an ECE flag set to 1. In one example, the CWR flag may be intended to inform the CU (310) that the TCP window size (or congestion window size) has been reduced in response to a request from the CU (310). In response to receiving downlink traffic having a TCP header with a CWR flag set, the CU (310) may stop (or refrain) from setting the ECE flag in the TCP header of the uplink traffic.

[0118] As described above, the CU (310) can perform traffic flow control based on the buffer state and wireless quality of the PDCP entity. For example, the CU (310) can reduce the amount of downlink traffic by sending uplink traffic to the server that includes a TCP header with the ECE flag set. In this way, by reducing the amount of downlink traffic in advance based on the buffer state and wireless quality, the CU (310) can prevent buffer overflow from occurring.

[0119] FIG. 7 illustrates signaling for reducing the TCP window size of a server. The operations of FIG. 7 may be performed by the central unit (CU) (310) of FIG. 5. For example, at least some of the operations may be controlled by the processor (501) 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 distributed unit (DU) (320).

[0120] Referring to FIG. 7, in operation 701, a CU (310) according to one embodiment can transmit a protocol data unit (PDU) type 0 to a DU (320).

[0121] In one embodiment, the CU (310) may receive downlink traffic from the server (710). The downlink traffic may be received through an internet protocol (IP) network and a component of the core network (CN) (e.g., a serving-gateway (S-GW) or a user plane function (UPF)). For example, the CU (310) may store at least a portion of the downlink traffic in a buffer based on a downlink data delivery status (DDDS) (or desired buffer size (DBS) included in the DDDS) obtained from a radio link control (RLC) entity of the DU (320). In one example, the DDDS may be referred to as a protocol data unit (PDU) type 1. The CU (310) may determine whether the amount of downlink traffic stored in the buffer of the PDCP entity (or buffer occupancy) exceeds a threshold value. In a non-limiting example, CU (310) can determine whether the buffer remaining capacity of a PDCP entity is below a threshold value. For example, the threshold value associated with the buffer remaining capacity and the threshold value associated with the buffer occupancy may be different from each other.

[0122] In one embodiment, the CU (310) may transmit a PDU type 0 to the DU (320) to request radio quality assistance information upon determining that the buffer occupancy of a PDCP entity exceeds a threshold value. In one example, the PDU type 0 may be referred to as downlink (DL) user data. For example, the PDU type 0 may include an information element (IE) (or parameter) for requesting radio quality assistance information. The IE (or parameter) may indicate whether radio quality assistance information is being requested. In one example, the IE may be referred to as an assistance information report polling flag. In one example, the IE (or parameter) may be set to 1 to request radio quality assistance information. However, this is merely an example and the present disclosure is not limited thereto. For example, to request wireless quality auxiliary information, the above IE (or parameter) may be set to 0.

[0123] In operation 702, a CU (310) according to one embodiment may receive a PDU type 2 from a DU (320). For example, the CU (310) may receive a PDU type 2 containing radio quality assistance information from the DU (320) in response to a PDU type 0. In one example, the PDU type 2 may be referred to as assistance information data. For example, the radio quality assistance information may include an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, an average HARQ retransmission, a DL (downlink) radio quality index, an average number of HARQ transmissions, or a combination thereof.

[0124] In operation 703, a CU (310) according to one embodiment may receive uplink traffic from a DU (320). For example, the uplink traffic may have the same flow and / or the same TCP session as the downlink that is congested.

[0125] In operation 704, the CU (310) according to one embodiment may set the ECE flag of the TCP header. In one example, the TCP header may be configured as shown in Table 1 above. For example, the TCP header may include a source port, a destination port, a sequence number, an acknowledgment number, a header length, reserved bits, a congestion window reduced (CWR), an explicit congestion notification echo (ECE), an urgent (URG), an acknowledgment (ACK), a push (PSH), a reset (RST), a synchronize (SYN), a finish (FIN), a window size, a TCP checksum, and an urgent pointer.

[0126] In one embodiment, the CU (310) can determine whether congestion occurs in the downlink. For example, the CU (310) can determine whether congestion occurs in the downlink based on wireless quality auxiliary information. For example, the CU (310) can determine that congestion has occurred in the downlink if it is determined that the terminal (120) is in a weak electric field based on wireless quality auxiliary information. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average CQI is below a threshold CQI. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average HARQ failures exceed a threshold failure count. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average HARQ retransmissions exceed a threshold count. In one example, the CU (310) may determine that congestion has occurred in the downlink based on the identification that the DL radio quality index is below a threshold index. However, the examples described above are merely examples and the present disclosure is not limited thereto. For example, the CU (310) may determine whether congestion has occurred in the downlink based on the average CQI, average HARQ failures, average HARQ retransmissions, DL (downlink) radio quality index, and the average number of HARQ transmissions included in the radio quality auxiliary information.

[0127] In one embodiment, the CU (310) may set an explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic upon determining that congestion has occurred in the downlink. For example, by setting the ECE flag in the TCP header of the uplink traffic, congestion avoidance action may be triggered by the server. Congestion avoidance action may involve reducing the server's TCP window size (or congestion window size). By reducing the server's TCP window size (or congestion window size), the transmission rate (or amount of data transmitted) of the downlink traffic may be reduced. By reducing the transmission rate (or amount of data transmitted) of the downlink traffic, a buffer overflow may be prevented in advance. In one example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 1. However, this is merely an example and the present disclosure is not limited thereto. For example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 0.

[0128] In one embodiment, since the value of the ECE flag is changed, the TCP checksum for verifying the integrity of the TCP segment needs to be changed. For example, the CU (310) can change the TCP checksum of the TCP header based on setting the ECE flag. The CU (310) can update the TCP checksum bits of the TCP header based on the changed TCP checksum.

[0129] In operation 705, a CU (310) according to one embodiment may transmit uplink traffic to a server (710). For example, the TCP header of the uplink traffic may include an ECE flag set to 1 and an updated TCP checksum. For example, the uplink traffic may be transmitted to the server through a component of the core network (e.g., an S-GW or UPF) and an IP network.

[0130] In operation 706, a CU (310) according to one embodiment may receive downlink traffic from a server (710). For example, downlink traffic may be received through an IP network and a component of a core network (e.g., an S-GW or a UPF). For example, downlink traffic may have a TCP header with a CWR flag set. In one example, the CWR flag may be an acknowledgment to an ECE flag set to 1. In one example, the CWR flag may be intended to inform the CU (310) that the TCP window size (or congestion window size) has been reduced in response to a request from the CU (310). In response to receiving downlink traffic having a TCP header with a CWR flag set, the CU (310) may stop (or refrain) from setting the ECE flag in the TCP header of uplink traffic.

[0131] FIG. 8 illustrates a block diagram for explaining the operations of a CU to reduce the TCP window size of a server.

[0132] Referring to FIG. 8, the system may include a central unit (CU) (310), a distributed unit (DU) (320), a UPF (810), an internet protocol (IP) (820), and a server (710). FIG. 8 illustrates a UPF (810) as a component of a core network (CN), but this is merely an example and the present disclosure is not limited thereto. For example, the UPF (810) may be replaced with a serving gateway (S-GW) associated with a long-term evolution (LTE) core network.

[0133] Referring to FIG. 8, the CU (310) can perform the functions of the SDAP (service data adaptation protocol) layer (311) and the PDCP (packet data convergence protocol) layer (312). For example, the DU (320) can perform the functions of the RLC (radio link control) layer (321), the MAC (medium access control) layer (322), and the PHY (physical) layer (323). In FIG. 8, the DU (320) is shown as being responsible for the PHY layer (323), but embodiments of the present disclosure are not limited thereto. Depending on the implementation example, the DU (320) may perform some functions (high PHY) of the PHY layer (323), and a RU (radio unit) connected to the DU (320) may be responsible for the remaining functions (low PHY) of the PHY layer (323). In the following, the operations of FIG. 8 are described based on a distributed deployment according to CU (310) and DU (320), 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 CU (310) and the functions of DU (320).

[0134] In operation 801, the CU (310) according to one embodiment can transmit a first message to the DU (320).

[0135] In one embodiment, the CU (310) may receive downlink traffic from the server (710). The downlink traffic may be received through an internet protocol (IP) network and a component of the core network (CN) (e.g., a serving-gateway (S-GW) or a user plane function (UPF)). For example, the CU (310) may store at least a portion of the downlink traffic in a buffer based on a downlink data delivery status (DDDS) (or desired buffer size (DBS) included in the DDDS) obtained from a radio link control (RLC) entity of the DU (320). In one example, the DDDS may be referred to as a protocol data unit (PDU) type 1. The CU (310) may determine whether the amount of downlink traffic stored in the buffer of the PDCP entity (or buffer occupancy) exceeds a threshold value. In a non-limiting example, CU (310) can determine whether the buffer remaining capacity of a PDCP entity is below a threshold value. For example, the threshold value associated with the buffer remaining capacity and the threshold value associated with the buffer occupancy may be different from each other.

[0136] In one embodiment, the CU (310) may transmit a first message to the DU (320) to request radio quality assistance information upon determining that the buffer occupancy of a PDCP entity exceeds a threshold value. In one example, the first message may be referred to as PDU type 0 or DL ​​(downlink) user data. For example, the first message may include an information element (or parameter) for requesting radio quality assistance information. The IE (or parameter) may indicate whether radio quality assistance information is being requested. In one example, the IE may be referred to as an assistance information report polling flag. In one example, the IE (or parameter) may be set to 1 to request radio quality assistance information. However, this is merely an example and the present disclosure is not limited thereto. For example, to request wireless quality auxiliary information, the above IE (or parameter) may be set to 0.

[0137] In operation 802, a CU (310) according to one embodiment may receive a second message from a DU (320). For example, the CU (310) may receive a second message containing radio quality assistance information from the DU (320) in response to a first message. In one example, the second message may be referred to as PDU type 2 or assistance information data. For example, the radio quality assistance information may include an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, an average HARQ retransmission, a DL (downlink) radio quality index, an average number of HARQ transmissions, or a combination thereof.

[0138] In operation 803, the CU (310) according to one embodiment can transmit uplink traffic to the server (710).

[0139] In one embodiment, the CU (310) can determine whether congestion occurs in the downlink. For example, the CU (310) can determine whether congestion occurs in the downlink based on wireless quality auxiliary information. For example, the CU (310) can determine that congestion has occurred in the downlink if it is determined that the terminal (120) is in a weak electric field based on wireless quality auxiliary information. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average CQI is below a threshold CQI. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average HARQ failures exceed a threshold failure count. In one example, the CU (310) can determine that congestion has occurred in the downlink based on the identification that the average HARQ retransmissions exceed a threshold count. In one example, the CU (310) may determine that congestion has occurred in the downlink based on the identification that the DL radio quality index is below a threshold index. However, the examples described above are merely examples and the present disclosure is not limited thereto. For example, the CU (310) may determine whether congestion has occurred in the downlink based on the average CQI, average HARQ failures, average HARQ retransmissions, DL (downlink) radio quality index, and the average number of HARQ transmissions included in the radio quality auxiliary information.

[0140] In one embodiment, the CU (310) may set an explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic upon determining that congestion has occurred in the downlink. For example, by setting the ECE flag in the TCP header of the uplink traffic, congestion avoidance action may be triggered by the server. Congestion avoidance action may involve reducing the server's TCP window size (or congestion window size). By reducing the server's TCP window size (or congestion window size), the transmission rate (or amount of data transmitted) of the downlink traffic may be reduced. By reducing the transmission rate (or amount of data transmitted) of the downlink traffic, a buffer overflow may be prevented in advance. In one example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 1. However, this is merely an example and the present disclosure is not limited thereto. For example, setting the ECE flag may mean setting the value of the ECE flag (or bit) to 0.

[0141] In one embodiment, since the value of the ECE flag is changed, the TCP checksum for verifying the integrity of the TCP segment needs to be changed. For example, the CU (310) can change the TCP checksum of the TCP header based on setting the ECE flag. The CU (310) can update the TCP checksum bits of the TCP header based on the changed TCP checksum.

[0142] In one embodiment, the CU (310) may transmit uplink traffic to the server (710). For example, the TCP header of the uplink traffic may include an ECE flag set to 1 and an updated TCP checksum. For example, the uplink traffic may be transmitted to the server (710) via the UPF (810) and the IP network (820).

[0143] In operation 804, a CU (310) according to one embodiment may receive downlink traffic from a server (720). For example, downlink traffic may be received through a UPF (810) and an IP network (820). For example, downlink traffic may have a TCP header with a CWR flag set. In one example, the CWR flag may be an acknowledgment to an ECE flag set to 1. In one example, the CWR flag may be intended to inform the CU (310) that the TCP window size (or congestion window size) has been reduced in response to a request from the CU (310). In response to receiving downlink traffic having a TCP header with a CWR flag set, the CU (310) may stop setting the ECE flag in the TCP header of the uplink traffic.

[0144] 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 pertains.

[0145] A central unit (CU) 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 that includes a processing circuit. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to transmit a first message to a radio link control (RLC) entity to request radio quality assistance information upon a determination that the amount of downlink traffic stored in the buffer of the packet data convergence protocol (PDCP) entity of the CU exceeds a threshold value. When the instructions are executed individually or collectively by the at least one processor, the CU may cause the CU to determine whether congestion occurs in the downlink based on the radio quality assistance information upon receiving a second message containing the radio quality assistance information from the RLC entity. When the above instructions are executed individually or collectively by the at least one processor, the CU may cause the uplink traffic to be sent to the server after setting the ECE (explicit congestion notification echo) flag in the TCP (transmission control protocol) header of the uplink traffic, based on the determination that the congestion occurs on the downlink.

[0146] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the server to receive downlink traffic having a TCP header with a CWR (congestion window reduced) flag set in response to the uplink traffic having a TCP header with the ECE flag set.

[0147] For example, the ECE flag may be for requesting a reduction in the congestion window size of the server. The CWR flag may be an acknowledgment to the request.

[0148] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may be caused to refrain from setting the ECE flag in the TCP header of the second uplink traffic in response to receiving the downlink traffic from the server having the TCP header with the CWR flag set.

[0149] For example, the above wireless quality auxiliary information may include at least one of an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, or an average HARQ retransmission.

[0150] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the congestion of the downlink to occur based on the determination that the average CQI included in the wireless quality auxiliary information is less than the threshold CQI.

[0151] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the checksum field of the TCP header to be changed based on setting the ECE flag in the TCP header of the uplink traffic.

[0152] For example, when the above instructions are executed individually or collectively by the at least one processor, the CU may cause the assistance information report polling flag to be set in the first message upon the determination that the amount of downlink traffic stored in the buffer of the PDCP entity exceeds the threshold value.

[0153] For example, the above RLC entity can be configured in a DU (distributed unit).

[0154] For example, the first message above may be a protocol data unit (PDU) type 0. The second message above may be a PDU type 2.

[0155] A method performed by a central unit (CU) as described above may include the operation of transmitting a first message to a radio link control (RLC) entity to request radio quality assistance information upon a determination that the amount of downlink traffic stored in the buffer of the packet data convergence protocol (PDCP) entity of the CU exceeds a threshold value. The method may include the operation of determining whether congestion occurs in the downlink based on the radio quality assistance information, upon receiving a second message containing the radio quality assistance information from the RLC entity. The method may include the operation of transmitting the uplink traffic to a server after setting an explicit congestion notification echo (ECE) flag in the transmission control protocol (TCP) header of the uplink traffic upon a determination that congestion occurs in the downlink.

[0156] For example, the above method may include the operation of receiving downlink traffic having a TCP header with a CWR (congestion window reduced) flag set from the server in response to the uplink traffic having a TCP header with the ECE flag set.

[0157] For example, the ECE flag may be for requesting a reduction in the congestion window size of the server. The CWR flag may be an acknowledgment to the request.

[0158] For example, the above method may include an action of refraining from setting an ECE flag in the TCP header of a second uplink traffic in response to receiving from the server the downlink traffic having a TCP header with the CWR flag set.

[0159] For example, the above wireless quality auxiliary information may include at least one of an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, or an average HARQ retransmission.

[0160] For example, the above method may include an operation to determine that the congestion of the downlink occurs based on a determination that the average CQI included in the wireless quality auxiliary information is less than a threshold CQI.

[0161] For example, the above method may include an operation to change the checksum field of the TCP header based on setting the ECE flag in the TCP header of the uplink traffic.

[0162] For example, the above method may include an operation of setting an assistance information report polling flag in the first message upon determining that the amount of downlink traffic stored in the buffer of the PDCP entity exceeds the threshold value.

[0163] For example, the above RLC entity can be configured in a DU (distributed unit).

[0164] For example, the first message above may be a protocol data unit (PDU) type 0. The second message above may be a PDU type 2.

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

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

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

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

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

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

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

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

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

[0174] 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 the CU (central unit), 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, Based on the determination that the amount of downlink traffic stored in the buffer of the PDCP (packet data convergence protocol) entity of the above CU exceeds a threshold, a first message to request radio quality assistance information is transmitted to the RLC (radio link control) entity, and Based on receiving a second message containing the radio quality auxiliary information from the above RLC entity, determining whether congestion occurs in the downlink based on the radio quality auxiliary information, and Causing to send the uplink traffic to the server after setting the ECE (explicit congestion notification echo) flag in the TCP (transmission control protocol) header of the uplink traffic, based on the determination that the above congestion occurs on the above downlink. CU.

2. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Causing to receive downlink traffic from the server having a TCP header with a CWR (congestion window reduced) flag set in response to the uplink traffic having a TCP header with the ECE flag set, CU.

3. In Paragraph 2, The above ECE flag is intended to request a reduction in the congestion window size of the server, and The above CWR flag is an acknowledgment to the above request, CU.

4. In Paragraph 2, When the above instructions are executed individually or collectively by the at least one processor, the CU, In response to receiving from the server the downlink traffic having a TCP header with the above CWR flag set, causing to refrain from setting the ECE flag in the TCP header of the second uplink traffic. CU.

5. In Paragraph 1, The above wireless quality auxiliary information includes at least one of an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, or an average HARQ retransmission. CU.

6. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Causing to determine that the congestion of the downlink occurs based on the determination that the average CQI included in the above wireless quality auxiliary information is below the threshold CQI, CU.

7. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Causing the checksum field of the TCP header to be modified based on setting the ECE flag in the TCP header of the uplink traffic, CU.

8. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the CU, Causing to set an assistance information report polling flag in the first message upon determination that the amount of downlink traffic stored in the buffer of the PDCP entity exceeds the threshold value CU.

9. In Paragraph 1, The above RLC entity is configured in a DU (distributed unit), CU.

10. In Paragraph 1, The first message above is a PDU (protocol data unit) type 0, and, The above second message is a PDU type 2, CU.

11. In a method performed by a CU (central unit), The operation of transmitting a first message to an RLC (radio link control) entity to request radio quality assistance information upon determining that the amount of downlink traffic stored in the buffer of the PDCP (packet data convergence protocol) entity of the above CU exceeds a threshold value; An operation to determine whether congestion occurs in the downlink based on the wireless quality auxiliary information, based on receiving a second message including the wireless quality auxiliary information from the above RLC entity; and Based on the determination that the above-mentioned downlink is congested, the operation of sending the uplink traffic to a server after setting the ECE (explicit congestion notification echo) flag in the TCP (transmission control protocol) header of the uplink traffic, method.

12. In Paragraph 11, further comprising the operation of receiving downlink traffic having a TCP header with a CWR (congestion window reduced) flag set from the server in response to the uplink traffic having a TCP header with the ECE flag set, method.

13. In Paragraph 12, The above ECE flag is intended to request a reduction in the congestion window size of the server, and The above CWR flag is an acknowledgment to the above request, method.

14. In Paragraph 12, In response to receiving from the server the downlink traffic having a TCP header with the above CWR flag set, the operation further includes refraining from setting the ECE flag in the TCP header of the second uplink traffic. method.

15. In Paragraph 11, The above wireless quality auxiliary information includes at least one of an average CQI (channel quality indicator), an average HARQ (hybrid automatic repeat request) failure, or an average HARQ retransmission. method.

Images