Method and apparatus for controlling transmission control protocol (TCP) congestion in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a data transmission rate higher than that of a 4G communication system such as LTE. A method for a server in a wireless communication system, according to one embodiment of the present disclosure, comprises the steps of: receiving acknowledgement (ACK) packets from a base station; determining scheduling characteristics on the basis of the ACK packets; and performing transmission control protocol (TCP) congestion control on the basis of the scheduling characteristics.

Description

Method and device for controlling transmission control protocol (TCP) congestion in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more specifically, to a method and apparatus for managing congestion control of a transmission control protocol (TCP).

[0002] Looking back at the evolution of wireless communication through successive generations, technologies have been developed primarily for human-oriented services, such as voice, multimedia, and data. Following the commercialization of 5G (5th-generation) communication systems, connected devices, which have been increasing explosively, are expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction machinery, and factory equipment. Mobile devices are expected to evolve into various form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6G (6th-generation) era, efforts are underway to develop improved 6G communication systems to connect hundreds of billions of devices and objects to provide diverse services. For this reason, 6G communication systems are referred to as "beyond 5G" systems.

[0003] In the 6G communication system predicted to be realized around 2030, the maximum transmission speed is tera (i.e., 1,000 gigabits) bps, and the wireless latency is 100 microseconds (μsec). In other words, compared to the 5G communication system, the transmission speed in the 6G communication system is 50 times faster, and the wireless latency is reduced to one-tenth.

[0004] To achieve such high data transmission speeds and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz band (e.g., the 95 GHz to 3 terahertz (3 THz) band). In the terahertz band, due to more severe path loss and atmospheric absorption compared to the millimeter wave (mmWave) band introduced in 5G, the importance of technology capable of guaranteeing signal reach, or coverage, is expected to increase. As key technologies to ensure coverage, radio frequency (RF) devices, antennas, new waveforms that offer better coverage than orthogonal frequency division multiplexing (OFDM), beamforming, and multi-antenna transmission technologies such as massive multiple-input and multiple-output (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas must be developed. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing technology using orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS) are being discussed to improve coverage of terahertz band signals.

[0005] In addition, to improve frequency efficiency and system network, development is underway in 6G communication systems for full duplex technology, in which uplink and downlink simultaneously utilize the same frequency resources at the same time; network technology that integrates satellites and HAPS (high-altitude platform stations); network structure innovation technology that supports mobile base stations and enables network operation optimization and automation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes AI (artificial intelligence) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high performance communication and computing resources (mobile edge computing (MEC), cloud, etc.). In addition, attempts are continuing to further strengthen connectivity between devices, further optimize networks, promote the softwareization of network entities, and increase the openness of wireless communication through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe utilization of data, and the development of technologies regarding privacy maintenance methods.

[0006] Due to the research and development of such 6G communication systems, it is expected that a new dimension of hyper-connected experience will become possible through the hyper-connectivity of 6G communication systems, which encompasses not only connections between objects but also connections between people and objects. Specifically, it is projected that 6G communication systems will enable the provision of services such as truly immersive extended reality (truly immersive XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems with enhanced security and reliability, will be applied in various fields including industry, healthcare, automotive, and home appliances.

[0007] Meanwhile, emerging applications such as Virtual Reality (VR), high-quality video streaming, and cloud gaming require both high bandwidth and low latency. Accordingly, active research is being conducted on methods to satisfy the requirements for high bandwidth and low latency in cellular networks.

[0008] The present disclosure relates to a method and apparatus for controlling TCP congestion by considering resource allocation scheduling of mobile communication in a wireless communication system.

[0009] A method of a server in a wireless communication system according to one embodiment of the present disclosure comprises: receiving ACK packets from a base station; determining scheduling characteristics based on the ACK packets; and performing TCP congestion control based on the scheduling characteristics.

[0010] In a wireless communication system according to one embodiment of the present disclosure, a server comprises: a transceiver; and at least one processor; wherein the at least one processor is configured to receive ACK packets from a base station, determine scheduling characteristics based on the ACK packets, and perform TCP congestion control based on the scheduling characteristics.

[0011] The various embodiments of the present disclosure described above are merely some of the preferred embodiments of the present disclosure, and various embodiments reflecting the technical features of the various embodiments of the present disclosure can be derived and understood by those skilled in the art based on the detailed description to be described below.

[0012] The method and apparatus according to the embodiments of the present disclosure have the effect of improving user experience and communication performance by controlling TCP congestion by considering resource allocation scheduling, thereby satisfying the requirements for high bandwidth and low latency.

[0013] 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 from the description below.

[0014] Figure 1 is a diagram showing an example of basic components in a wireless communication system.

[0015] Figure 2 is a diagram showing an example of a method for controlling the TCP congestion window size in a wireless communication system.

[0016] FIG. 3 is a diagram illustrating an example of a method for controlling the TCP congestion window size according to packet delay in a wireless communication system.

[0017] Figure 4 is a diagram illustrating an example of the results of experiments on the performance of various congestion control algorithms in a wireless communication system.

[0018] Figure 5 is a diagram illustrating an example of the inevitable delay that occurs when a data packet is transmitted in a wireless communication system.

[0019] Figure 6 is a diagram illustrating an example of the inevitable delay that occurs when a data packet is transmitted in a wireless communication system.

[0020] FIG. 7 is a diagram illustrating an example of an operation for controlling TCP congestion based on resource allocation scheduling according to an embodiment of the present disclosure.

[0021] FIGS. 8a and 8b are flowcharts illustrating an example of the operation of a server that performs TCP congestion control based on resource allocation scheduling according to an embodiment of the present disclosure.

[0022] FIG. 9 is a diagram illustrating an example of an operation for estimating a scheduling unit to determine the characteristics of resource allocation scheduling for TCP congestion control according to one embodiment of the present disclosure.

[0023] FIG. 10 is a diagram illustrating the effect of delay experienced by packets within a set identified through a scheduling unit according to one embodiment of the present disclosure.

[0024] FIG. 11 is a diagram illustrating an example of a congestion window size control method for TCP congestion control according to one embodiment of the present disclosure.

[0025] FIG. 12 is a diagram illustrating an example of a step-by-step congestion window size control method for TCP congestion control according to one embodiment of the present disclosure.

[0026] FIGS. 13a, FIGS. 13b, and FIGS. 13c illustrate the results of comparing performance in terms of throughput and RTT when using an LTE network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0027] FIGS. 14a, FIGS. 14b, and FIGS. 14c illustrate the results of comparing performance in terms of throughput and RTT when using a 5G network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0028] FIG. 15 illustrates the results of comparing performance in terms of throughput and RTT in a mobile environment when using a 5G network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0029] FIG. 16 is a flowchart illustrating the operation of a server according to one embodiment of the present disclosure.

[0030] FIG. 17 is a structural diagram illustrating an example of the structure of a server according to one embodiment of the present disclosure.

[0031] The drawings are included as reference examples to aid in understanding the invention and are not limited to specific embodiments of the invention. The specific details depicted in the drawings are intended to supplement the overall technical background and context of the invention and may provide technical information beneficial to the invention even if not directly specified in the claims.

[0032] Hereinafter, embodiments of the present invention will be described in detail together with the accompanying drawings.

[0033] In describing the embodiments, technical details that are well known in the technical field to which the present invention belongs and are not directly related to the present invention are omitted. This is intended to convey the essence of the present invention more clearly without obscuring it by omitting unnecessary explanations.

[0034] For the same reason, some components in the attached drawings have been emphasized, omitted, or depicted schematically. Additionally, the dimensions of each component do not fully reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0035] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but can be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0036] At this time, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the computer also creates means for the instructions executed through the processor of other programmable data processing equipment to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in such computer-available or computer-readable memory can also produce a manufactured item containing means of instruction that perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0037] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to their corresponding functions.

[0038] In this embodiment, the term "part" refers to a software or hardware component, such as an FPGA or ASIC, and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to operate one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." Furthermore, the components and "parts" may be implemented to operate one or more CPUs within a device or secure multimedia card.

[0039] In the present disclosure, each of the phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “A, B or C,” “at least one of A, B and C,” and “at least one of A, B, or C” may include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as “first,” “second,” or “first” or “second” may be used simply to distinguish a corresponding component from another corresponding component and do not limit the corresponding components in other aspects (e.g., importance or order).

[0040] Hereinafter, a base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B (gNB), eNode B (eNB), Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. A terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. In this disclosure, a downlink (DL) refers to a wireless transmission path of a signal transmitted by a base station to a terminal, and an uplink (UL) refers to a wireless transmission path of a signal transmitted by a terminal to a base station. Furthermore, while LTE, LTE-A, or 5G systems may be described as examples below, embodiments of this disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A may be included therein, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person with skilled technical knowledge, without significantly departing from the scope of the present disclosure.

[0041] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0042] Hereinafter, various embodiments are described in detail with reference to the attached drawings. It should be noted that identical components in the attached drawings are indicated by the same reference numerals whenever possible. Furthermore, it should be noted that the drawings of the present invention attached below are provided to aid in understanding the present invention, and that the present invention is not limited to the forms or arrangements exemplified in the drawings. Additionally, detailed descriptions of known functions and configurations that may obscure the essence of the present invention will be omitted. It should be noted that in the following description, only the parts necessary for understanding the operation according to various embodiments of the present invention will be explained, and descriptions of other parts will be omitted so as not to distract from the essence of the present invention.

[0043] Figure 1 is a diagram showing an example of basic components in a wireless communication system.

[0044] Referring to FIG. 1, the wireless communication system may include at least one of a server (100), the internet (110), a base station (120), and a terminal (130).

[0045] The server (100) is operated by a service provider (e.g., an Internet service provider (ISP), a cloud service provider, etc.) and is connected to a base station (120) via the Internet (110). The server primarily performs functions such as data transmission, service provision, and user management. The service provider can provide various services or applications to users through the server.

[0046] The Internet (110) can provide a communication path connecting the server (100) and the base station (120). The base station (120) is connected to the Internet (110) and can communicate wirelessly with the user terminal (130). The base station (120) transmits and receives data to and from the terminal (130) using radio frequencies.

[0047] The terminal (130) is a wireless device (e.g., smartphone, tablet, etc.) used directly by the user, communicates wirelessly with the base station (120), and can use services provided by the server (100). The terminal (130) can transmit and receive data with the server (100) via TCP (transmission control protocol), thereby enabling stable and reliable data transmission. TCP guarantees the accuracy of data transmission and, as a connection-oriented protocol, can support reliable communication between the server and the terminal.

[0048] TCP congestion control is explained below.

[0049] TCP congestion control can be performed on TCP used between a server and a terminal to efficiently utilize network resources while preventing congestion and packet loss caused by excessive traffic growth. The purpose of TCP congestion control is to prevent congestion and packet loss resulting from excessive traffic growth while efficiently utilizing network resources.

[0050] Congestion control can alleviate network congestion by monitoring various indicators such as packet loss and delay in a network environment and dynamically adjusting the transmission window size.

[0051] TCP congestion control is broadly divided into two types: loss-based and delay-based. Figure 2 below describes a loss-based TCP congestion control method, and Figure 3 describes a delay-based TCP congestion control method.

[0052] Figure 2 is a diagram illustrating an example of a method for controlling the loss-based TCP congestion window size in a wireless communication system.

[0053] FIG. 2 is a diagram illustrating a method for controlling a TCP congestion window (CWND) by recognizing congestion based on whether packets are lost while operating a TCP congestion window between a server (200) and a UE (210).

[0054] Referring to FIG. 2, the capacity for data transmission between the server (200) and the UE (210) can be represented as a first capacity (capacity 1) (220) and a second capacity (capacity 2) (225). The bandwidth-delay product (BDP) (230) shown between the server (200) and the UE (210) represents the maximum amount of transmission data available in the network path, indicating the point where 100% of the bandwidth of the bottleneck network can be used.

[0055] Loss-based congestion control, such as TCP Reno and Cubic, controls congestion based on the occurrence of packet loss. To utilize 100% of the network bandwidth, loss-based congestion control continuously increases the TCP congestion window size, which is essentially the amount of data that can be transmitted to the network without a TCP ACK.

[0056] As shown in Figure 2, when TCP transmits more packets than the bandwidth of the bottleneck network, packets accumulate in the buffer of the bottleneck network. When the transmitted packets exceed the aforementioned capacities and the buffer of the bottleneck network becomes full, packet loss occurs, and loss-based congestion control can detect this packet loss, recognize that congestion is occurring, and control the size of the congestion window.

[0057] Figure 3 is a diagram showing an example of a method for controlling the TCP congestion window size according to packet delay in a wireless communication system.

[0058] FIG. 3 is a diagram illustrating a method for controlling a TCP congestion window (CWND) by recognizing congestion based on whether delay occurs while operating a TCP congestion window between a server (300) and a UE (310).

[0059] Referring to FIG. 3, the capacity for data transmission between the server (300) and the UE (310) can be represented as a first capacity (capacity 1) (320) and a second capacity (capacity 2) (325). The bandwidth-delay product (BDP) (330) shown between the server (300) and the UE (310) represents the maximum amount of transmission data available in the network path, indicating a point where 100% of the bandwidth of the bottleneck network can be used without experiencing queuing delay, which is the time that packets accumulate in the buffer and wait in the buffer.

[0060] Delay-based congestion control, such as TCP Vegas, Copa, ExLL, PropRate, etc., controls congestion based on the round trip time (RTT), which is the time taken from sending a TCP packet until receiving a TCP ACK. Delay-based congestion control attempts to adjust the TCP congestion window size to an optimal point called BDP (330).

[0061] Delay-based congestion control increases the congestion window size until it experiences a queuing delay in order to match the congestion window size to BDP (330) (i.e., to use 100% of the bandwidth). When TCP transmits more packets than the bandwidth of the bottleneck network, packets accumulate in the buffer and experience a queuing delay, and delay-based congestion control detects this increase in queuing delay through an increase in RTT and controls the congestion window size.

[0062] In the case of mobile communication, base stations have large buffers to respond to channel changes caused by user mobility or the characteristics of wireless communication. In this case, the loss-based congestion control described in Fig. 2 increases the size of the congestion window until the base station's large buffer is completely filled and packet loss occurs, causing packets to experience high queuing delays. Additionally, in the case of the delay-based congestion control described in Fig. 3, congestion control is performed by detecting an increase in queuing delay through an increase in RTT; however, in the case of mobile communication, inevitable delays occur due to the base station's scheduling operation even if there is no queuing delay, which increases the RTT and can degrade the performance of the delay-based congestion control.

[0063] To verify the performance of such packet loss-based congestion control and delay-based congestion control, an experimental environment such as the wireless communication system shown in Fig. 1 was configured, and downlink traffic was transmitted from a server to a UE using commercial mobile communication. The results of the experiment on the performance of various congestion control algorithms are shown in Fig. 4.

[0064] Figure 4 is a diagram illustrating an example of the results of experiments on the performance of various congestion control algorithms in a wireless communication system.

[0065] Referring to Figure 4, Cubic, a loss-based congestion control algorithm, was able to utilize 100% of the bandwidth but caused high delay due to high queuing delay.

[0066] Referring to Figure 4, ExLL, BBR, PropRate, Vegas, and Copa delay-based congestion control show that low throughput (Tput) is measured, indicating that 100% of the bandwidth cannot be utilized.

[0067] In other words, it can be seen that only the Manually Set method, which manually fixes the congestion window size close to the BDP, can achieve low latency while utilizing 100% of the bandwidth.

[0068] In FIGS. 5 and 6 below, the occurrence of an inevitable delay that increases the RTT affecting delay-based congestion control is explained, even if there is no queuing delay due to the scheduling operation of a base station in a mobile communication system in the case of delay-based congestion control described in FIG. 3.

[0069] Figure 5 is a diagram illustrating an example of the inevitable delay that occurs when a data packet is transmitted in a wireless communication system.

[0070] FIG. 5 is a diagram illustrating that when packets are transmitted between a server (500), a base station (510), and a UE (510), an inevitable delay (580) occurs due to the base station's scheduling operation affecting TCP congestion control.

[0071] The base station (510) attempts to transmit more data within the same bandwidth to maximize throughput. To achieve this, for the downlink, instead of allocating downlink resources evenly to all UEs, it allocates resources to UEs with good wireless channel environments to transmit more data within the same bandwidth. In other words, UEs do not receive downlink resources consistently and evenly, but rather receive resources in a bursty manner, taking into account factors such as the wireless channel environment. For example, when the wireless channel environment is good or when needed, a large amount of resources can be allocated quickly, while when the wireless channel environment is poor or there is no need for resource allocation, a small amount of resources can be allocated.

[0072] In the case of the uplink, for the energy efficiency of the base station and the UE, uplink resources are not always allocated; instead, the UE periodically notifies the base station that it has data to transmit in order to receive uplink resources. Consequently, the base station allocates resources in a bursty manner for both downlink and uplink, rather than consistently. As a result, the terminal waits for downlink or uplink resources, leading to inevitable delays caused by scheduling.

[0073] Referring to FIG. 5, the server (500) transmits a packet to the base station (510), and the packet reaches the base station (510) (Operation 530). The base station (510) transmits the packet to the UE (520) via a wireless resource (Operation 533). The UE (520) transmits an ACK for packet reception to the base station (510) (Operation 535).

[0074] FIG. 5 illustrates an example of resource allocation (540) for a UE performed at a base station (510) according to the previously described packet forwarding operations (operations 530, 533, 535).

[0075] Referring to FIG. 5, the base station (510) can receive a plurality of packets including packet i and packet j from the server (500) in the first slot (500). When the base station (510) transmits packets to the UE (520) for packets i and j and performs downlink scheduling and uplink scheduling to receive an ACK for the packets from the UE (520) (560, 570), an inevitable delay may occur due to consideration of the channel status of the UE (520).

[0076] For example, regarding packet i in FIG. 5, the base station (510) may have an inevitable delay (580) to consider the channel status of the UE (520) in the 4th slot and 7th slot before performing downlink scheduling to transmit packet i to the UE (520) in the 5th slot and 6th slot (563) and uplink scheduling to receive an ACK for packet i in the 8th slot (565).

[0077] Figure 6 is a diagram illustrating an example of the inevitable delay that occurs when a data packet is transmitted in a wireless communication system.

[0078] Referring to FIG. 6, the capacity for data transmission between the server (600) and the UE (610) can be represented as a first capacity (capacity 1) (620) and a second capacity (capacity 2) (625). The bandwidth-delay product (BDP) (630) shown between the server (600) and the UE (610) represents the maximum amount of transmission data available in the network path, indicating a point where 100% of the bandwidth of the bottleneck network can be used without experiencing queuing delay, which is the time packets accumulate in the buffer and wait in the buffer.

[0079] Delay-based congestion control can recognize the increase in RTT caused by the inevitable delay described in Fig. 5 as a queuing delay and perform congestion control.

[0080] Referring to FIG. 6, when the packet delay becomes greater than the threshold value due to the inevitable delay (640) caused by scheduling occurring at the base station, the server (600) may decide to reduce the congestion window size, which must be increased to use 100% of the bandwidth, by determining that the congestion window size is greater than the BDP (630), even though the current mobile communication bandwidth is not being used 100%. Additionally, it may misunderstand the reduction in the inevitable delay caused by scheduling as an improvement in the bandwidth of the bottleneck network and make a mistake by increasing the congestion window size even though the bandwidth is being used 100% and queuing delay is being experienced.

[0081] Through the above explanation, it can be seen that simple packet loss-based or delay-based congestion control methods may find it difficult to utilize 100% of the achievable bandwidth or simultaneously achieve low delay.

[0082] Accordingly, the present disclosure aims to achieve high bandwidth and low latency by minimizing the impact of inevitable delay on TCP congestion control by considering the scheduling characteristics of mobile communication when using wireless communication.

[0083] FIG. 7 is a diagram illustrating an example of an operation for controlling TCP congestion based on resource allocation scheduling according to an embodiment of the present disclosure.

[0084] FIG. 7 is a diagram illustrating the operation of a server (700) that performs TCP congestion control based on resource allocation scheduling when the server (700) transmits a packet to a UE (720) through a base station (710).

[0085] The present disclosure proposes the operation of a server (700) that performs TCP congestion control based on resource allocation scheduling as follows.

[0086] Referring to Fig. 7, the server can identify the characteristics of resource allocation scheduling at the TCP layer and perform congestion control based on this.

[0087] Referring to FIG. 7, the scheduling unit estimation and packet selection (730) operation is an operation to identify the scheduling characteristics of wireless communication based on TCP ACKs received from the UE (720) through the base station (710) and to select packets to be used for congestion control in order to reduce the impact of inevitable delays caused by scheduling. When the server (700) identifies the scheduling characteristics and selects packets, downlink / uplink resource allocation is required once each for the packet to pass through the mobile communication network and for the ACK to reach the server (700) again. That is, since the packet must go through both the downlink and the uplink, the downlink and uplink can be considered as a single set when identifying the scheduling characteristics. In one embodiment, if cellular characteristics are not observed during scheduling unit estimation, congestion control using a general congestion control algorithm applicable in various network environments (e.g., BBR (bottleneck bandwidth and round-trip propagation time)) can be used.

[0088] The step-wise congestion window control (740) operation is a step-wise congestion control operation based on selected packets to minimize the impact of inevitable delays on congestion window size control.

[0089] The pacing rate control (750) operation is an operation that adjusts the pacing rate, which is the interval between TCP packets being transmitted. The server can adjust the pacing rate, which is the interval between packets, using bandwidth measured based on selected packets. That is, the server (700) can perform a TCP pacing control operation to minimize packet delay while making maximum use of the link of the mobile communication network (i.e., cellular network).

[0090] FIGS. 8a and 8b are flowcharts illustrating an example of the operation of a server that performs TCP congestion control based on resource allocation scheduling according to an embodiment of the present disclosure.

[0091] The server operations in FIGS. 8a and 8b may correspond to specific operations for each operation (730, 740, 750) shown in FIG. 7.

[0092] Referring to FIG. 8a, in operation 800, the server can receive a TCP ACK from the terminal through the base station. The TCP ACK may refer to a TCP ACK for packet i.

[0093] In operation 810, the server for the TCP ACK It can calculate. In one example, the server It can be calculated as the difference between the time the TCP ACK arrived and the time the previous TCP ACK arrived.

[0094] In operation 815, the server can select a scheduling unit as the least common multiple of the most frequent intervals greater than 1ms.

[0095] In operation 820, the server is as follows It is possible to determine whether it is larger than the above scheduling unit.

[0096] In operation 830, the above If is smaller than the above scheduling unit, the server identifies that the set of downlink / uplink scheduling for the TCP ACK for packet i has not yet been terminated and may terminate the operation to wait for the packet with the least impact on inevitable delay.

[0097] In operation 840, the above If is greater than the above scheduling unit, the server and It can calculate. In one embodiment, the server It can be calculated as the time the TCP ACK arrived minus the time the packet for the TCP ACK was dispatched, and It can be determined as the minimum RTT among the RTTs to date.

[0098] Referring to Fig. 8b, in operation 845, the server and (i.e., exponentially weighted moving average (EWMA) bandwidth) can be calculated. The server and Examples of formulas for calculating are as shown in mathematical formula 1 and mathematical formula 2 below.

[0099] [Mathematical Formula 1]

[0100]

[0101] is RTT for packet i )am.

[0102] Is Indicates the number of TCP ACKs delivered to the server during that time.

[0103] [Mathematical Formula 2]

[0104]

[0105] In operation 850, when packet delay increases, the server can calculate the pacing rate and increase the spacing between packets to respond to inevitable delay and / or queuing delay. The pacing rate refers to the transmission speed set by the sender to send packets at a constant interval (or at a constant speed) when transmitting packets; as it increases, the spacing between packets increases, and as it decreases, the spacing decreases.

[0106] The server's pacing rate ( An example of calculating ) is as shown in mathematical formula 3 below.

[0107] [Mathematical Formula 3]

[0108]

[0109] This is a parameter for how aggressively bandwidth will be used, and for example, '2' can be assigned.

[0110] and is calculated in the previous operation 840 and It could be.

[0111] Referring to mathematical equation 3, as the RTT of a packet increases, the spacing between packets increases, which can resolve the queuing delay of the bottleneck network and allow packets to arrive at the base station at intervals corresponding to the downlink / uplink set, thereby reducing the impact of inevitable delays.

[0112] In operation 860, the server You can determine whether or not to recognize it.

[0113] In the case of, that is, In this case, in operation 870, the server uses Equation 1 to identify the cause of the RTT increase It can calculate.

[0114] In operation 875, the server As this approaches 0, the inevitable delay becomes dominant as a cause of RTT increase, so the reduction amount of the Congestion Window (CWND) ( ) can be controlled by calculating. In one embodiment, an example of a mathematical formula used by a server to calculate the reduction amount of the congestion window (CWND) is as shown in Mathematical Formula 4 below.

[0115] [Mathematical Formula 4]

[0116]

[0117]

[0118] In mathematical formula 4 is the crowded window size. This is a parameter that determines how sensitively the window size is reduced, and for example, '0.05' can be assigned.

[0119] is the value of the bandwidth of the set measured using mathematical formula 1, CD is the estimated queuing delay, and BR is a value added to compensate for bandwidth reduction.

[0120] At this time, The queuing delay (CD) can be adjusted by changing according to the cause of the RTT increase. If If it is close to 1 or greater than 1, it means that the base station has allocated sufficient downlink resources to the set relative to the current bandwidth, which may indicate that the cause of the increase in RTT is queuing delay.

[0121] on the other way If α becomes less than 1, it can be classified into two cases: one is when the inevitable delay resulting from scheduling predominantly prevents the base station from allocating sufficient downlink resources. In this case, As it decreases, the queuing delay is reduced, thereby mitigating the impact of inevitable delays. The second case is when bottleneck bandwidth is reduced. To address this, a BR is introduced. (EWMA bandwidth) and You can respond to bandwidth reduction by comparing (currently measured bandwidth).

[0122] Meanwhile, at Dongjak 860 If it is decided that it is not, that is, In this case, the server at operation 880 is currently and By comparing, the amount of increase in the congestion window (CWND) can be calculated and controlled by considering whether the current bandwidth has decreased and the congestion window (CWND) increase cycle by the scheduling unit. In one embodiment, an example of a mathematical formula used by the server to calculate the increased congestion window (CWND) is as shown in Equation 5 below.

[0123] [Mathematical Formula 5]

[0124]

[0125] In mathematical formula 5, It is calculated by multiplying the (EWMA bandwidth) by the SU (scheduling unit), which represents the number of packets that can be transmitted within the scheduling unit time in the current bandwidth; this value increases as the scheduling unit and bandwidth increase. If the scheduling unit is large, the time between sets becomes longer, which reduces the period required to determine the increase in the congestion window size (i.e., since the last packet of each set is used, the period decreases as the interval between sets increases). To compensate for the shortened period and utilize 100% of the bandwidth, the increase becomes greater as the scheduling unit increases. In addition, the current RTT ( ) is the previous RTT( If it decreases significantly compared to ), the increase becomes larger, and the larger the current RTT value itself, the smaller the increase becomes.

[0126] At this time, In Equation 4, the queuing delay (CD) part is excluded, and only the bandwidth reduction (BR) part is applied to reflect the reduction in bottleneck bandwidth, thereby reducing the congestion window size. This was applied to respond as quickly as possible when bandwidth is reduced.

[0127] finally, In calculating ...can be applied. That is, the server at operation 880 is the current packet's RTT ( ) is the RTT of the previous packet( Since it is determined that the congestion window size will be increased when it is equal to or decreased compared to ), a limit on the reduction can be set so that the final window size is not reduced due to the bandwidth reduction part.

[0128] Below, the specific operation details of the scheduling unit estimation and packet selection (730) operation, step-wise congestion window control (740) operation, and pacing rate control (750) operation illustrated in FIG. 7 will be explained.

[0129] FIG. 9 is a diagram illustrating an example of an operation for estimating a scheduling unit to determine the characteristics of resource allocation scheduling for TCP congestion control according to one embodiment of the present disclosure.

[0130] FIG. 9 may refer to the scheduling unit estimation operation in the scheduling unit estimation and packet selection (730) operation of FIG. 7.

[0131] Referring to FIG. 9, the server (900) transmits a packet to the base station (910), and the packet reaches the base station (910) (Operation 930). The base station (910) transmits the packet to the UE (920) via a wireless resource (Operation 933). The UE (920) transmits an ACK for packet reception to the base station (910) (Operation 935).

[0132] FIG. 9 illustrates an example of resource allocation (940) for a UE performed at a base station (910) according to the previously described packet forwarding operations (operations 930, 933, 935).

[0133] In FIG. 9, all packets in set i (960) share the same uplink resource, and from the server (900)'s perspective, since they share the same uplink resource, they can be identified as the same set regardless of when the downlink resource was allocated. Similarly, set j (970) can also be determined as the same set. At this time, the scheduling unit (980) can be defined as the minimum time interval difference between the downlink / uplink sets.

[0134] That is, when downlink resources to which at least one packet is transmitted and uplink resources to which at least one ACK corresponding to the at least one packet is transmitted are defined as a set, the scheduling unit (980) can be defined as the minimum time interval difference between the sets of downlink resources and uplink resources.

[0135] The scheduling unit (980) may represent a minimum unit for indicating how burstily the base station (910) schedules resources.

[0136] If the base station (910) collects packets more burstily and schedules them all at once, the scheduling unit will increase, and conversely, if the base station (910) schedules them non-burstily, the scheduling unit will decrease. The previously defined scheduling unit can be measured through the time difference (interval) between TCP ACKs continuously received from the server without information about the base station.

[0137] TCP ACKs are processed on the same uplink at the base station through downlink / uplink sets. If the time difference (interval) between TCP ACKs within a single set is calculated, in most cases, the time difference can be less than, for example, 1ms. On the other hand, when the first set ends and the next second set is waiting, the time difference between the last ACK of the finished first set and the first ACK of the next second set will be the time difference (interval) between the first set and the second set.

[0138] In one embodiment, a scheduling unit can be selected as the least common multiple of the most frequently occurring time difference (interval) among intervals greater than 1ms. The 1ms corresponds to one example of a predetermined time value for identifying time differences (intervals) between sets, and may be determined as a different value, but is not limited thereto.

[0139] The above scheduling unit indicates the minimum time difference between downlink / uplink sets, and how often packets can be transmitted via downlink / uplink at intervals.

[0140] Based on the selected scheduling unit, if the interval, which is the time difference between TCP ACKs, is greater than the selected scheduling unit, the server can identify that the current set has ended, meaning that all ACKs corresponding to the current set have arrived and ACKs corresponding to the next set have arrived.

[0141] Through this, the last packet of each set can be selected and used for congestion control. The reason for using the last packet of each set is that the last packet has the shortest waiting time for uplink resources in that set. In FIG. 9, the first packet of set i (960) has the longest waiting time for uplink resources in set i (960), but the last packet has the shortest waiting time for uplink resources. In other words, by selecting the last packet from the set, the impact of inevitable delay can be reduced.

[0142] Furthermore, since TCP uses a pacing method to transmit packets, there is a gap between packets when they are transmitted from the server to the UE (930, 933). However, due to the nature of waiting for the base station's uplink resources, packets sharing the same uplink (i.e., included in the same set) arrive at the server at the same time when transmitted from the UE to the server. Consequently, when measuring the RTT of the packets in that set at the server, the RTT shows a decreasing trend from the first packet to the last. In other words, while the packet departure time is delayed by pacing, the arrival time remains the same due to the base station's uplink. This reduction in RTT is due to the base station's uplink scheduling method, not an improvement in the bandwidth of the bottleneck network. Accordingly, selecting and using only the last packet from the set allows for a comparison of RTTs between the last packets of each set, thereby preventing the misidentification of a decrease in RTT caused by the base station uplink scheduling method within the same set as an improvement in network conditions (i.e., instead of performing internal comparisons within a set, packets from each set are selected and compared between sets).

[0143] FIG. 10 is a diagram illustrating the effect of delay experienced by packets within a set identified through a scheduling unit according to one embodiment of the present disclosure.

[0144] Figure 10 illustrates the consideration of the inevitable delay caused by packet scheduling in selecting packets to determine the characteristics of resource allocation scheduling for TCP congestion control.

[0145] Referring to FIG. 10, in the case of the RTT of the first packet (packet i) (1020) and the last packet (packet j) (1030) among the packets in set n (1010) identified through the scheduling unit described in FIG. 9, it can be seen that the RTT value of the first packet (packet i) (1020) is greater than the RTT value of the last packet (packet j) (1030).

[0146] This means that the first packet (packet i) (1020) has the longest waiting time for uplink resources compared to the last packet (packet j) (1030), and is therefore significantly affected by the inevitable delay resulting from the base station's scheduling. In other words, it can be seen that the more the last packet is selected within the set identified through the scheduling unit, the more the effect of the inevitable delay can be reduced.

[0147] FIG. 11 is a diagram illustrating an example of a congestion window size control method for TCP congestion control according to one embodiment of the present disclosure.

[0148] Figure 11 may refer to the step-wise congestion window control (740) operation of Figure 7.

[0149] FIG. 11 (a) illustrates a case where congestion window size control is performed in a non-step-wise manner, and FIG. 11 (b) illustrates a case where congestion window size control is performed in a step-wise manner.

[0150] The step-wise method changes the judgment criteria for controlling the congestion window size according to the situation, making it more robust against inevitable delays compared to the existing method (non-step-wise) that controls the congestion window size using fixed judgment criteria.

[0151] Referring to Fig. 11 (a), in the case of the non-step-wise method, a fixed judgment criterion is used, and when the RTT increases due to inevitable delay, it is assumed that a queuing delay has occurred, so the congestion window size is reduced, preventing it from approaching the BDP.

[0152] On the other hand, referring to Fig. 11 (b), in the step-wise method, if the server determines that the inevitable delay has increased, it reduces the congestion window size, and if it determines that the inevitable delay has decreased by resetting the judgment criteria, it compensates for the reduced window size, thereby allowing the congestion window size to be kept close to BDP even when the inevitable delay exists.

[0153] When the step-wise method is applied, if the RTT of the current packet is greater than the RTT of the previous packet, the congestion window size is reduced. In this case, Equation 4, which was explained earlier, can be used.

[0154] If the RTT of the current packet is smaller than the RTT of the previous packet, the size of the congestion window can be increased using Equation 5 described earlier.

[0155] FIG. 12 is a diagram illustrating an example of a step-by-step congestion window size control method for TCP congestion control according to one embodiment of the present disclosure.

[0156] FIG. 12 is a diagram illustrating the identification of whether the cause of the delay in increasing RTT for step-by-step congestion window size control is an inevitable delay (N) due to scheduling or a congestion delay (i.e., queuing delay (C)).

[0157] The server, in the description in the above mathematical formulas 4 and 5, By using BR, it is possible to identify whether the cause of the delay is an inevitable delay (N) caused by scheduling or a congestion delay (or, queuing delay (C)).

[0158] Referring to Fig. 12, when RTT increases in set j compared to set i, If this approaches or increases to 1, the cause of the increase in packet delay can be identified as queuing delay (or congestion delay (C)) rather than inevitable delay. On the other hand, If this is less than 1, the BR value in Equation 4 is additionally calculated to identify whether the increase in packet delay is due to inevitable delay or due to bandwidth reduction.

[0159] The server can identify the cause of the delay using mathematical formulas 4 and 5 as shown in Fig. 12 and control the step-by-step congestion window size as shown in Fig. 11.

[0160] FIGS. 13a to 15 below illustrate the results of comparing the performance of a TCP congestion control method according to one embodiment of the present disclosure and other congestion control algorithms.

[0161] For performance comparison, a network was configured as shown in FIG. 1, and downlink traffic was transmitted from the server to the UE via the Iperf3 application. The throughput and RTT when transmitting data for 10 seconds were compared with the TCP congestion control method proposed in this disclosure and other TCP congestion control algorithms to verify whether the TCP congestion control method proposed in this disclosure achieves high bandwidth usage and low latency in a mobile communication network.

[0162] In Figures 13a through 15, the points represent the average throughput and RTT for each algorithm, and the corners of the boxes represent the throughput and RTT points at 25% and 75%. The error bars represent the 5% and 95% points. In this case, the further to the top left of the graph, the better the corresponding TCP congestion control achieves high bandwidth and low latency simultaneously.

[0163] FIGS. 13a, FIGS. 13b, and FIGS. 13c illustrate the results of comparing performance in terms of throughput and RTT when using an LTE network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0164] Figures 13a, 13b, and 13c each illustrate the results of comparing performance using the communication networks of different operators.

[0165] FIGS. 14a, FIGS. 14b, and FIGS. 14c illustrate the results of comparing performance in terms of throughput and RTT when using a 5G network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0166] FIGS. 14a, FIGS. 14b, and FIGS. 14c each illustrate the results of comparing performance using the communication networks of different operators.

[0167] FIG. 15 illustrates the results of comparing performance in terms of throughput and RTT in a mobile environment when using a 5G network for a TCP congestion control method and other congestion control algorithms according to one embodiment of the present disclosure.

[0168] Figure 15 shows the results when RSRP changes are applied as (-85, -96, -105, -95, -85) when measuring throughput and RTT.

[0169] As can be seen in FIGS. 13a to 15 above, the point of the method proposed by the present disclosure is located to the upper left of the points of other TCP congestion control algorithms, showing high throughput and low latency, and thus exhibiting better performance.

[0170] FIG. 16 is a flowchart illustrating the operation of a server according to one embodiment of the present disclosure.

[0171] In step 1600, the server can receive ACK packets from the base station.

[0172] In step 1610, the server can determine scheduling characteristics based on the ACK packets.

[0173] In step 1620, the server can perform TCP congestion control based on the above scheduling characteristics.

[0174] In one embodiment, the scheduling characteristic may include a scheduling unit. In one embodiment, the scheduling unit may represent a minimum time interval difference between sets including at least one downlink resource and at least one corresponding uplink resource. In one embodiment, the at least one uplink resource may transmit an ACK packet corresponding to a packet transmitted from the at least one downlink resource.

[0175] In one embodiment, the scheduling unit may be determined to be one of the reception time difference (interval) values ​​between the nth received ACK packet and the n+1th received ACK packet that exceeds the defined threshold value.

[0176] In one embodiment, the scheduling unit may be determined as the least common multiple of the reception time difference (interval) values ​​of the nth received ACK packet and the n+1th received ACK packet, which exceed a predefined threshold.

[0177] In one embodiment, the server may select a packet to be used for TCP congestion control within a set including at least one downlink resource and at least one corresponding uplink resource based on the scheduling unit in an operation to determine the scheduling characteristics.

[0178] In one embodiment, the selected packet may be the last packet in a set including at least one downlink resource and at least one corresponding uplink resource.

[0179] In one embodiment, the server may control the congestion window based on the selected packet in an operation to perform TCP congestion control based on the scheduling characteristics. In one embodiment, the server may control the pacing rate of packet transmission based on the selected packet in an operation to perform TCP congestion control based on the scheduling characteristics.

[0180] In one embodiment, the server may estimate a queuing delay based on the bandwidth corresponding to the selected packet in an operation to control a congestion window based on the selected packet. In one embodiment, the server may control a congestion window based on the queuing delay and the bandwidth in an operation to control a congestion window based on the selected packet.

[0181] In one embodiment, the bandwidth may include an exponentially weighted moving average (EWMA) bandwidth.

[0182] In one embodiment, the server may increase the congestion window based on the increase cycle of the congestion window when the RTT for the selected packet is reduced in an operation to control the congestion window based on the selected packet.

[0183] In one embodiment, the server may control the pacing rate based on the bandwidth corresponding to the selected packet in an operation of controlling the pacing rate of packet transmission based on the selected packet.

[0184] FIG. 17 is a structural diagram illustrating an example of the structure of a server according to one embodiment of the present disclosure.

[0185] In FIG. 17, the server may include at least one of a processor (1701), a transceiver (1702), and a memory (1703). At least one of the processor (1701), the transceiver (1702), and the memory (1703) of the server may operate according to the method(s) described in the embodiments described above in FIG. 1 to 16. However, the components of the server are not limited to the examples described above. For example, the server may include more components or fewer components than the components described above. In addition, the processor (1701), the transceiver (1702), and the memory (1703) may be implemented in the form of at least one chip.

[0186] The transceiver (1702) is a collective term for a receiver and a transmitter, and can transmit and receive signals with a base station or other network entity through the transceiver (1702). At this time, the signal being transmitted and received may include at least one of control information and data. To this end, the transceiver (1702) may include an RF transmitter that up-converts and amplifies the frequency of the transmitted signal, and an RF receiver that low-noise amplifies the received signal and down-converts the frequency. This is merely one embodiment of the transceiver (1702), and the components of the transceiver (1702) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (1702) can receive a signal and output it to a processor (1701), and transmit the signal output from the processor (1701) to another network entity through a network.

[0187] The memory (1703) can store programs and data necessary for the operation of a server according to at least one of the embodiments of FIGS. 1 to 16. Additionally, the memory (03) can store control information and / or data included in signals obtained from the server. The memory (1703) may be composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD.

[0188] The processor (1701) can control a series of processes so that the server can operate according to at least one of the embodiments of FIGS. 1 to 16. The processor (1701) may include at least one processor.

[0189] Methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software. When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). 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 the methods according to the embodiments described in the claims or specification of the present disclosure.

[0190] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), 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.

[0191] Additionally, the above program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wireless LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to the device performing the embodiment of the present disclosure through an external port. Additionally, a separate storage device on the communication network may be connected to the device performing the embodiment of the present disclosure.

[0192] In the specific embodiments of the present disclosure described above, the components included in the invention 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, or even if a component is expressed in the singular form, it may be composed of a plural form.

[0193] 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. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. In a method of a server in a wireless communication system, A step of receiving ACK (acknowledgement) packets from a base station; A step of determining scheduling characteristics based on the above ACK packets; and A method characterized by including the step of performing TCP (transmission control protocol) congestion control based on the above scheduling characteristics.

2. In paragraph 1, the scheduling characteristic includes a scheduling unit, and The above scheduling unit represents the minimum time interval difference between sets including at least one downlink resource and at least one corresponding uplink resource, and A method characterized in that the at least one uplink resource transmits an ACK packet corresponding to a packet transmitted from the at least one downlink resource.

3. In paragraph 2, the scheduling unit is, A method characterized by being determined as one of the reception time difference (interval) values ​​between the nth received ACK packet and the n+1th received ACK packet, which exceeds a predefined threshold.

4. In paragraph 3, the scheduling unit is, A method characterized by being determined as the least common multiple of the reception time difference (interval) values ​​of the nth received ACK packet and the n+1th received ACK packet, which exceed a predefined threshold.

5. In paragraph 2, the step of determining the scheduling characteristics; is A method characterized by including the step of selecting a packet to be used for TCP congestion control within a set including at least one downlink resource and at least one corresponding uplink resource based on the above scheduling unit.

6. A method according to claim 5, wherein the selected packet is the last packet in a set comprising at least one downlink resource and at least one corresponding uplink resource.

7. In paragraph 5, the step of performing TCP congestion control based on the above scheduling characteristics; is, A step of controlling a congestion window based on the selected packet above; or A method characterized by including the step of controlling the pacing rate of packet transmission based on the selected packet.

8. In claim 7, the step of controlling the congestion window based on the selected packet; is, A step of estimating a queuing delay based on the bandwidth corresponding to the selected packet; and A method characterized by including the step of controlling a congestion window based on the queuing delay and the bandwidth.

9. A method according to claim 8, characterized in that the bandwidth includes an exponentially weighted moving average (EWMA) bandwidth.

10. In claim 7, the step of controlling the congestion window based on the selected packet; is, A method characterized by including the step of increasing the congestion window based on the increase cycle of the congestion window when the round trip time (RTT) for the selected packet is reduced.

11. In claim 7, the step of controlling the pacing rate of packet transmission based on the selected packet; is, A method characterized by including the step of controlling the pacing rate based on the bandwidth corresponding to the selected packet.

12. In a server in a wireless communication system, Transmitter / receiver; and It includes at least one processor; and the at least one processor, Receive ACK packets from the base station, Determining scheduling characteristics based on the above ACK packets, and A server characterized by being configured to perform TCP congestion control based on the above scheduling characteristics.

13. In Clause 12, the above scheduling characteristic includes a scheduling unit, and The above scheduling unit represents the minimum time interval difference between sets including at least one downlink resource and at least one corresponding uplink resource, and A server characterized in that the at least one uplink resource transmits an ACK packet corresponding to a packet transmitted from the at least one downlink resource.

14. In Clause 13, the above scheduling unit is, A server characterized by being determined as one of the reception time difference (interval) values ​​between the nth received ACK packet and the n+1th received ACK packet, which exceeds a predefined threshold.

15. In Clause 14, the above scheduling unit is, A server characterized by being determined by the least common multiple of the reception time difference (interval) values ​​of the n-th received ACK packet and the n+1-th received ACK packet, which exceed a predefined threshold.

Images