EP2749118A1 - Methods and arrangements for improving transmission control protocol performance in a cellular network - Google Patents
Methods and arrangements for improving transmission control protocol performance in a cellular networkInfo
- Publication number
- EP2749118A1 EP2749118A1 EP11876384.6A EP11876384A EP2749118A1 EP 2749118 A1 EP2749118 A1 EP 2749118A1 EP 11876384 A EP11876384 A EP 11876384A EP 2749118 A1 EP2749118 A1 EP 2749118A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- tcp
- user equipment
- packet
- sequence
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000001413 cellular effect Effects 0.000 title claims abstract description 52
- 238000000034 method Methods 0.000 title claims abstract description 26
- 230000005540 biological transmission Effects 0.000 title claims abstract description 17
- 230000007423 decrease Effects 0.000 claims description 11
- 102100039124 Methyl-CpG-binding protein 2 Human genes 0.000 claims description 10
- 238000007689 inspection Methods 0.000 claims description 6
- 230000001934 delay Effects 0.000 abstract description 10
- 230000009471 action Effects 0.000 description 47
- 230000003111 delayed effect Effects 0.000 description 31
- 101000666730 Homo sapiens T-complex protein 1 subunit alpha Proteins 0.000 description 16
- 102100038410 T-complex protein 1 subunit alpha Human genes 0.000 description 16
- 238000002360 preparation method Methods 0.000 description 14
- 101100206196 Arabidopsis thaliana TCP3 gene Proteins 0.000 description 13
- 101100260060 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) CCT3 gene Proteins 0.000 description 13
- 101100206195 Arabidopsis thaliana TCP2 gene Proteins 0.000 description 12
- 101100536570 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) CCT2 gene Proteins 0.000 description 12
- 230000037361 pathway Effects 0.000 description 11
- 238000005516 engineering process Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 8
- 238000005259 measurement Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 230000002035 prolonged effect Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 230000003247 decreasing effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000003139 buffering effect Effects 0.000 description 3
- 101710117064 Trimethylamine corrinoid protein 1 Proteins 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 101710117056 Trimethylamine corrinoid protein 2 Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
Definitions
- Embodiments herein relate to a network node and a method in a network node. In particular, embodiments herein relate to improving transmission control protocol performance in a cellular network.
- UEs User Equipments
- RAN Radio Access Network
- CNs core networks
- a user equipment is a mobile terminal by which a subscriber can access services offered by an operator's core network.
- the user equipments may be for example communication devices such as mobile telephones, cellular telephones, laptops or tablet computers, sometimes referred to as surf plates, with wireless capability.
- the user equipments may be portable, pocket-storable, hand-held, computer-comprised, or vehicle- mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another mobile station or a server.
- User equipments are enabled to communicate wirelessly in the cellular network.
- the communication may be performed e.g. between two user equipments, between a user equipment and a regular telephone and/or between the user equipment and a server via the radio access network and possibly one or more core networks, comprised within the cellular network.
- the cellular network covers a geographical area which is divided into cell areas. Each cell area is served by a base station, e.g. a Radio Base Station (RBS), which sometimes may be referred to as e.g. "eNB”, “eNodeB”, “NodeB”, “B node”, or BTS (Base Transceiver Station), depending on the technology and terminology used.
- RBS Radio Base Station
- the base stations may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also on cell size.
- a cell is the geographical area where radio coverage is provided by the base station at a base station site.
- One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies.
- the base stations communicate over the air interface operating on radio frequencies with the user equipments within range of the base stations.
- radio network controller e.g. a Radio Network Controller (RNC) in Universal Mobile Telecommunications System (UMTS), and/or to each other.
- RNC Radio Network Controller
- UMTS Universal Mobile Telecommunications System
- the radio network controller also sometimes termed a Base Station Controller (BSC) e.g. in GSM, may supervise and coordinate various activities of the plural base stations connected thereto.
- BSC Base Station Controller
- GSM is an abbreviation for Global System for Mobile Communications
- base stations which may be referred to as eNodeBs or eNBs, may be directly connected to one or more core networks.
- UMTS is a third generation, 3G, mobile communication system, which evolved from the second generation, 2G, mobile communication system GSM, and is intended to provide improved mobile communication services based on Wideband Code Division
- WCDMA Code Division Multiple Access
- UTRAN is essentially a radio access network using wideband code division multiple access for user equipments.
- the 3GPP has undertaken to evolve further the UTRAN and
- GSM Global System for Mobile communications
- a base station as described above will be referred to as a base station or a Radio Base Station (RBS).
- RBS Radio Base Station
- a user equipment as described above, will in this disclosure be referred to as a user equipment or a UE.
- the expression DownLink (DL) will be used for the transmission path from the base station to the user equipment.
- the expression UpLink (UL) will be used for the transmission path in the opposite direction i.e. from the user equipment to the base station.
- ⁇ Cellular communication networks evolve towards higher data rates, together with improved capacity and coverage.
- standardization body technologies like GSM, High Speed Packet Access (HSPA) and LTE have been and are currently developed.
- the concept of a cellular system is that it has a large number of base stations covering a geographical area, providing mobility to the user equipments. Therefore, it is a requirement of the cellular network that, as a user equipment moves from one cell to another, it must be possible to hand an ongoing call or data session over from one base station to another with small disruptions.
- a handover is hence a change of serving cell for the user equipment, from a so called source cell to a so called target cell. There is a time period during the handover execution when neither the source cell nor the target cell can reach the user equipment. This will in the following be referred to as a handover outage.
- Transmission Control Protocol is a reliable, connection-oriented protocol used in the cellular network for transferring data in segments from a sender node to a destination node.
- Data and/or acknowledgement (ACK) of receipt of data are transferred in so called TCP packets, which comprises a header and a number of data bits.
- the reliability of TCP is achieved by the sender node, such as a user equipment or a server, assigning a sequence number to each TCP packet it sends in a session to a destination node which may also be for example a user equipment or a server.
- the sequence number is indicated in the header of the TCP packet.
- the time period from when the TCP packet is sent until its acknowledgment is received by the sender node is the TCP packets so called Round Trip Time, RTT.
- TCP timeout may occur in the sender node.
- a TCP timeout may result in the sending node going into a so called slow start in which it retransmits the unacknowledged TCP packet, using the same sequence number, and waits for it to be acknowledged before a new TCP packet in the same session is transferred.
- the pre-defined timer period is called Retransmission Time Out (RTO).
- TCP sessions to or from a user equipment may be interrupted by TCP timeouts that occur in relation to handovers of the user equipment. This is because the handover outage may prevent TCP packets and/or acknowledgements from being transmitted to or from the user equipment in due time, which may hence result in the RTO being exceeded, and a TCP timeout to occur. This results in unsatisfactory performance and throughput for the TCP sessions.
- the object is achieved by a method in a network node for improving transmission control protocol, TCP, performance in a cellular network.
- the network node handles TCP packet transferral between a user equipment in the cellular network and a server.
- the user equipment and the server are configured to adapt a retransmission timeout setting based on round trip times for performed TCP packet transferrals.
- the network node When the network node obtains an indication of a handover outage being upcoming for the user equipment, the network node deliberately delays, in a time period preceding the indicated handover outage, a transferral of a TCP packet between the server and the user equipment to increase the round trip time for the TCP packet.
- the object is achieved by a network node for improving transmission control protocol, TCP, performance in a cellular network.
- the network node is adapted to handle TCP packet transferal between a user equipment in the cellular network and a server.
- the user equipment and the server are configured to adapt a retransmission timeout setting based on round trip times for performed TCP packet transferals.
- the network node comprises a delaying unit.
- the delaying unit is configured to, when obtaining an indication of a handover outage being upcoming for the user equipment, deliberately delay, in a time period preceding the indicated handover outage, a transferal of a TCP packet between the server and the user equipment to increase the round trip time for the TCP packet.
- the round trip time for the TCP packet is increased. Since this increased round trip time will be used for adaption of the retransmission timeout, the retransmission timeout will be adapted to allow for the duration time of the handover outage. Thanks to this, TCP timeouts due to handover are reduced, slow stars are avoided, and performance such as throughput of TCP sessions is improved. This provides an improved TCP performance in the cellular network.
- Figure 1 is a schematic block diagram illustrating an embodiment of a cellular network.
- Figure 2 is a combined signalling scheme and flowchart illustrating embodiments in a cellular network.
- Figure 3a is a schematic illustration of an embodiment of a flow of data packets.
- Figure 3b is a graph illustrating estimated RTT values versus packet number.
- Figure 4a is a schematic illustration of an embodiment of a flow of data packets.
- Figure 4b is a graph illustrating estimated RTT values versus packet number.
- Figure 5 is a table illustrating features of some embodiments herein.
- Figure 6 is a table illustrating features of some embodiments herein.
- Figure 7 is a flowchart depicting embodiments of a method in a network node.
- Figure 8 is a schematic block diagram illustrating embodiments of a network node.
- FIG. 1 depicts a cellular network 100.
- the cellular network 100 is in this example an LTE cellular network, but may in other embodiments be a WCDMA cellular network, a GSM cellular network, any 3GPP cellular network, a combination thereof, or any other cellular network.
- the cellular network 100 comprises a first base station 105 serving a first cell 110.
- the cellular network 100 further comprises a second base station 115 serving a second cell 120.
- the first base station 105 and the second base station 1 15 are in this example eNBs, but may in other embodiments be of another type and may in different embodiments be referred to by different names such as for example RBS, eNodeB, NodeB, B node, or BTS, depending on the technology and terminology used.
- the first base station 105 and the second base station 1 15 may in some embodiments be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station.
- the cellular network 100 further comprises a serving gateway 125 and a Packet data network (PDN) gateway 130.
- PDN Packet data network
- a user equipment 135 is located in the first cell 1 10 and is served by the first base station 105.
- the user equipment 135 may be for example a communication device such as a mobile telephone, a cellular telephone, a dongle, a laptop, or tablet computer, sometimes referred to as a surf plate, with wireless capability.
- the user equipment may be portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the cellular network 100, with a server 140.
- the term server is here to be interpreted broadly, as an entity with which the user equipment 135 is enabled to communicate using Transmission Control Protocol (TCP).
- TCP Transmission Control Protocol
- the server 140 may hence be another entity such as another in the figure 1 not shown user equipment.
- the interface between the first base station 105 and the second base station 1 10 is an X2 interface
- the interface between the base stations 105, 1 10 and the serving gateway 125 is a S1 U interface
- the interface between the serving gateway 125 and the PDN gateway 130 is an S5 interface
- the interface between the PDN gateway 130 and the operator PDN 150 is an SGI.
- MME Mobility Management Entity
- the TCP packet pathway 145 may traverse other nodes than the previously mentioned and the interface between these nodes may be different from the previously mentioned interfaces.
- the reliability of TCP may be achieved by assigning a sequence number to each TCP data packet, i.e. segment, in a TCP session.
- a TCP packet comprising data is sent from the server 140 to the user equipment 135, or vice versa, a timer is started in the sender node, i.e. in the server 140 or in the user equipment 1 35 whichever sends the TCP packet. If an acknowledgement is not received from the destination node, i.e. from the other one of the user equipment 135 and the server 140, within a pre-defined timer period, the data is retransmitted from the sender node.
- the predefined timer period is called Retransmission Time Out (RTO).
- a TCP packet comprising an acknowledgement may also comprise data. There may for this reason be a first field in the header of each TCP packet which is used for indicating the sequence number of the TCP packet itself, and a second field in the header which is used for acknowledgement of received TCP packets, i.e. for indicating the sequence number of received TCP packets.
- the value of the RTO in the sender node relies on the previous statistics of a Round Trip Time (RTT).
- RTT Round Trip Time
- the Round Trip Time is the time, counted from the moment a TCP packet is transmitted until the moment the same TCP packet is acknowledged.
- TCP packet is hence within the context of this disclosure understood either a TCP packet comprising data or a TCP packet comprising the acknowledgement of the TCP packet comprising data.
- TCP implementations attempt to predict a future RTT by averaging previous RTTs into a "Smoothed" RTT estimate (SRTT).
- SRTT Smoothed RTT estimate
- the sending node 135 or 140 calculates how long it takes for it to be acknowledged, producing a sequence of round-trip time samples: S(1 ), S(2), S(3), where S(i) is the sample associated to the i-th segment. There are two ways to measure S(1 ), S(2), etc.
- the first way is to measure the time from when a TCP packet is sent until it is acknowledged.
- the second way is to embed a time stamp in each outgoing TCP packet containing data.
- the timestamp is then echoed back by the destination node when the data is acknowledged.
- This second method has some advantages on links with a large bandwidth delay product.
- a default value for a may be 0.125.
- the parameter ⁇ may be set in such a way that the RTO represents an upper bound of the RTT.
- a too high RTO would add unnecessary delay and reduce the throughput in the case when a TCP packet is lost.
- a minimum RTO which specifies the minimum RTO for a TCP session.
- the minimum RTO may not be smaller than 1 second, due to Operating System (OS) time granularity and network speed at that time.
- OS Operating System
- the default value for minimum RTO is 200 ms. Furthermore, it has been suggested by that this minimum RTO may not be needed at all.
- TCP has a flow control procedure that reacts in two different ways.
- the destination node will send a duplicate acknowledgement, and the sending node will reduce a window size to one-half of a current window size when three duplicate acknowledgements are received i.e., fast recovery of TCP.
- TCP timeout occurs and the transmitter will set its window size to one segment, i.e., a so called slow start, leading to a significant impact on the TCP throughput.
- the concept of the cellular system 100 is that it has large number base stations of which two, the first base station 105 and the second base station 1 15 are shown in the figure 1 , covering a geographical area.
- the cellular network 100 provides mobility to user equipments such as the in figure 1 shown user equipment 135, by performing a handover from the first cell 1 10, to the second cell 120, when the user equipment 135 moves from the first cell 1 10 to the second cell 120, so that the user equipment 135 becomes served by the second cell 120 instead of the first cell 130.
- the handover may happen between cells within the same Radio Access
- RAT e.g., when a connection is handed over from an LTE cell to another LTE cell. Also an inter-RAT handover may happen, e.g., from an LTE cell to a WCDMA cell.
- the purpose of the Intra-LTE handover feature is to manage handovers of the user equipment 135 from one LTE cell to another. This ensures that the user equipment 135 is served by the best cell at all times.
- the handover is network controlled based upon user equipment 135 measurement reports of the serving first cell 105 and neighboring cells such as the second cell 120. However, during the execution of the handover, the user equipment 135 will not be able to communicate neither with the first cell 105 or the second cell 1 10. This is because during the handover, there is a so called handover outage time when the user equipment cannot be reached from either of the two cells 1 10 and 120.
- TCP packets arriving at the first base station 105 during the handover outage time need to be forwarded to the target, second base station 1 15, which will use the target, second cell 120 to send the TCP packets to user equipment 135 when the handover outage is over.
- the TCP packet forwarding may be implemented through the X2 interface.
- the duration time of the handover outage may in average be about 90ms, and some handovers may have a significantly larger handover outage time, for example above 200 ms.
- Inter-RAT handovers between LTE and WCDMA in general have a longer outage time.
- An RTT on the Internet varies depending on the location of the server in question. It may vary from less than one millisecond, if the server is close, to up to hundreds of milliseconds, if the server is far away. For example, an RTT across the Atlantic Ocean is about 100 ms.
- the end-to-end RTT also depends on the used radio access technology. Field measurements show, e.g. , that the LTE RAN RTT is around 20ms.
- RTO may occur because of TCP packets not being received within the expected RTT limit at the sender node.
- FTP File Transfer Protocol
- the user equipment 135 is handed over from the first cell 1 10 to the second cell 120 during the download of the file. Assuming that the handover outage time is 90 ms, then, with the normal RTT of 60 ms, the total RTT for the TCP packets experiencing the handover will be about 150 ms.
- TCP timeout will occur in this example, and TCP will enter slow-start phase with significantly reduced throughput.
- TCP packets arriving at the first base station 105 during and after the handover outage may need to be forwarded to the second base station 1 15 through the X2 interface, which requires system resources.
- Some TCP end hosts e.g. the user equipment 135 or the server 140, may have a configured minimum RTO of 200 ms. In such cases, a TCP timeout will not occur in the above scenario, as the RTO will be 200 ms instead of 120 ms.
- TCP timeout will still happen. Therefore, a minimum RTO of 200 ms will only protect from some of the TCP timeouts. Also, with a smaller configured minimum RTO, or with removal of minimum RTO, TCP timeouts will occur more frequently.
- FIG. 2 illustrates how, according to some embodiments herein, TCP timeouts due to handover outage may be avoided by a method in a network node for improving TCP performance in the cellular network 100.
- the network node in question carrying out the method is in this example the first base station 105.
- the network node may be any other suitable network node forming part of the TCP pathway 145, such as or example the serving gateway 125 or the PDN gateway 130.
- a first TCP data packet, TCP 1 comprising data in a TCP session from the server 140 to the user equipment 135, leaves the server 140.
- the server 140 keeps track of the sending time of the first TCP data packet TCP1 . This may, as previously mentioned, be done for example by starting a timer in the server 140 when the first TCP data packet TCP1 is sent, or by embedding a time stamp in the first TCP data packet TCP1.
- the first TCP data packet TCP1 is received by the first base station 105 which is on the pathway 145.
- the pathway 145 of the TCP packets may comprise other network nodes, which are omitted here.
- the first TCP data packet TCP1 traverses the first base station 105 and is sent by the first base station 105 over a radio interface in the first cell 1 10 to the user equipment 135.
- the user equipment 135 receives the first TCP data packet TCP1.
- the user equipment 135 sends an acknowledgement, TCP1 ACK, back to the server 140 upon receiving the TCP 1 in action 202. This is done to
- the TCP1 ACK is sent over the air interface and is received by the first base station 105.
- the TCP1 ACK traverses the base station 105, which sends it towards the server 140.
- the TCP1 ACK is then received by the server 140.
- the server 140 determines a RTT, RTT1 , of the first TCP data packet TCP1 .
- the RTT1 is calculated as the time that passed between the sending of the first TCP data packet TCP1 from the server 140 in action 201 , to the receipt of the TCP1 ACK by the server 140 in action 204.
- the server 140 also calculates a SRTT taking the RTT1 into account. This may be done according to any of the previously described ways.
- the first base station 105 receives a measurement report from the user equipment 135.
- the measurement report is an indication that a handover is upcoming for the user equipment 135 from the first cell 1 10 to the second cell 120.
- the first base station 105 starts handover preparations. Since the upcoming handover will cause a handover outage which prolongs RTTs of TCP packets between the server 140 and the user equipment 135 during the handover execution, there is now a risk for TCP timeouts, as previously explained.
- a second TCP data packet, TCP2 is sent from the server 140 in the time period preceding the expected handover outage.
- the second TCP data packet TCP2 traverses the first base station 105 and reaches the user equipment 135
- the user equipment 135 sends an acknowledgement, TCP2 ACK towards the server 140.
- the TCP2 ACK is received by the first base station 105, and this time, the TCP 2 ACK is not directly sent towards the server 140 by the base station 105, as was the normal case with the TCP1 ACK as described above.
- the first base station 105 delays the TCP2 ACK, to increase its RTT, RTT2.
- the delaying may be performed by buffering the TCP2 ACK. Note that this delaying is performed deliberately, and is not to be confused with another, small, delay which may always occur when the TCP packets traverses the first base station 105.
- the purpose of the deliberate delay is to prepare for the handover outage, by causing an increased RTT2, and hence an increased RTO.
- the TCP2 may be represented by a sequence of several individual TCP packets which in this action are individually delayed by different suitable delays to gradually increase the RTO. How the individual delays may be chosen will be discussed in more detail further down in this disclosure.
- Embodiments herein can hence, thanks to the delaying performed in this action, prevent TCP timeouts by the first base station 105, or another suitable network node along the pathway 145 of the TCP packets, delaying TCP packets in a time period preceding the expected handover outage.
- the RTT for TCP packets going between the server 140 and the user equipment 135 shortly before the handover will be prolonged by the deliberate delay.
- the RTO will hence be set at a higher level before the handover outage occurs and allow for prolonged RTTs during the handover.
- the first base station 105 may delay several TCP packets on their way to and/or from the user equipment 135 to gradually increase the SRTT.
- the consequences of the delaying will be illustrated in the following actions below.
- the delayed TCP2 ACK is sent towards the server 140 from the first base station 105.
- the delayed TCP2 ACK is received by the server 140.
- the RTT of the delayed TCP2 ACK, RTT2, and the corresponding SRTT is calculated by the server 140.
- the RTT2 is longer than RTT1 , and hence the corresponding SRTT is increased, which in turn will cause an increased RTO.
- handover execution starts in the involved nodes, i.e. in the first base station 105, the second base station 1 10, and the user equipment 135.
- the handover execution involves several not shown steps and actions. In this example, these actions are referred to simply as handover execution.
- handover execution During the time the handover execution lasts, there is a handover outage, as indicated by the dashed arrow in the figure 2.
- a third TCP data packet, TCP3, is sent from the server 40 towards the user equipment 135.
- this third TCP data packet TCP3 may be received by either the first base station 105 or the second base station 1 15. If the third TCP data packet TCP3 is received by the first base station 105, the first base station 105 forwards the third TCP data packet TCP3 to the second base station 1 15. Hence, in this action the third TCP data packet TCP3 is received by the second base station 1 15 either directly or via the first base station 105.
- the user equipment 135 cannot be reached by, as previously explained. Therefore, the third TCP data packet TCP3 cannot be sent to the user equipment 135 until the handover outage is over.
- the second base station 105 may now transmit the third TCP data packet TCP3 to the user equipment 135, and the third TCP data packet TCP3 is received by the user equipment 135.
- an acknowledgement of the third TCP data packet TCP3, TCP3 ACK is sent from the user equipment 135 to the second base station 1 15 which is now its serving base station via its new serving cell, i.e. the second cell 120.
- the TCP3 ACK is then sent towards the server 140 by the second base station 105.
- the RTT related to third TCP data packet TCP3 is also illustrated by a dashed arrow in the figure 2. As can be seen, this RTT3 is rather long, because it was prolonged by the handover outage. Still, thanks to the delaying in action 2 1 , the RTO in the server 140 was adapted to make allowance for the prolonged RTT3, and no TCP timeout had to occur in the server 140 due to the handover outage.
- the above example served to illustrate how some embodiments herein improves TCP performance during a handover by delaying TCP packets arriving in a network node along the pathway 145 in a time period preceding the handover outage.
- a further advantage of embodiments herein is that by delaying the TCP packets and increasing the RTT, TCP packets may be sent at a slower rate from the server 140 during the handover. That is, in the above example, it is likely that third TCP data packet TCP3 represents fewer individual TCP packets. This decreases an amount of TCP packets that need to be forwarded from the first base station 105 to the second base station 1 15. This saves resources.
- the above example may for example correspond to a case where the user equipment 135 is downloading a file from the server 140.
- the user equipment 135 will send TCP ACKs of the TCP data packets to the server 140 in uplink.
- the sender i.e. the server 140 in this example, continuously measures and estimates RTT and RTO based on when the TCP ACKs arrive.
- the sender may send more TCP data packets based on the window size limitation in TCP.
- Some embodiments herein suggest that the first base station 105 should start delaying the uplink TCP ACKs to the server 140 when a handover decision has been taken for the user equipment 135.
- the server 140 After the delaying, the server 140 will receive delayed TCP ACKs, and thus increase the RTT estimate of the TCP packets to come. The RTO will in turn also increase, and this will decrease the risk of a TCP timeout during handover outage time. Also, it has been dicussed that by delaying the TCP ACKs, the server 40 may be blocked from sending more TCP packets, which in turn results in fewer TCP packets to be forwarded from the first, serving, base station 105 to the second, target, base station 1 10 during handover.
- the TCP data packets are uplink TCP data packets, from user equipment 135 to the server 140. Then it the user equipment 135 that computes RTT and decides TCP timeouts.
- the first base station 105 may instead delay, or buffer, TCP ACK packets on their way to the user equipment 135. This will increase the user equipment 135 RTT estimate, and may avoid a potential TCP timeout in the user equipment 135.
- the first base station 105 has a DPI (Deep Packet Inspection) module. Based on the DPI module's analysis of TCP flows, the first base station may know if a TCP session contains downlink and/or uplink data.
- DPI Deep Packet Inspection
- the DPI module may compute the RTT from the first base station 105 to the user equipment 135, by taking the difference of TCP packet arrive time at the first base station 105 and the ACK arrive time for the given TCP packet at the first base station 105.
- the DPI may also be able to compute the
- RTT from the first base station 105 to the server 140. This RTTs may be useful for choosing a suitable delay, since it may be used for example for estimating the RTO in the sender node.
- the DPI module may start to monitor a certain TCP flow only when a measurement report from a user equipment 135 is received as in the action 206 above, or when a handover decision has been taken.
- the handover execution time, or the outage time may also be an important input parameter to determine the delay, or delays to be used.
- the first base station 105 may contain a handover module to monitor handover execution time to its neighboring base stations, such as the second base station 1 15, and store them into a database. Based on previous handover execution times to different neighboring base stations, the first base station 105 may then estimate the average, as well as lower and upper bounds for, handover execution times, and thus of expected handover outage duration.
- the first base station 105 may start to deliberately delay TCP packets. In general, it should delay packets to increase the RTT and sender's estimate of RTO so that TCP timeout will not occur. Also, the procedure may need to gradually increase the delay so that TCP timeout does not occur on these deliberately TCP packets.
- the first base station 105 may delay the TCP packets the same amount of time as handover outage time. In this way, not so much queuing is required in the first base station 105, and hopefully, the server 140 will send TCP packets directly to the target, i.e. to the second base station 1 15, if the system is able to re-configure the forwarding path 145 quickly. Therefore, the handover outage time may be chosen as an upper bound on the delay of the TCP packets.
- a next question may be how to gradually increase the delay until it reaches the handover outage time.
- D(i) denote the extra delay we introduce to packet i.
- SRTT(0) may be observed from a DPI module if the TCP session contains both uplink and downlink data. If the TCP session has only downlink data, only a part of the SRTT(0) from the user equipment 135 to the first base station 105 may be observed.
- the base station 105 may not be able to measure the time it takes for the TCP packets to travel from the first base station 105 to the server 140.
- this part may also be used as the SRTT(O), but then the delay may be increased in a slower rate.
- the RTT S(1 ) of the delayed TCP packet may be computed by adding D(i) with average RTT before handover.
- the SRTT(2) may also be computed based on the formula:
- the retransmission timeout RTO(2) may also be computed using:
- the first base station 105 may then delay further TCP packets following the first TCP packet, and so on, with a time based on the formula:
- SRTT(i+1 ) and RTO(i+1 ) may be computed.
- the individual TCP packets may be delayed until D(i) reaches the handover outage time.
- Figure 3a diagrams a flow of TCP packets passing through the first base station 105 and being delayed in the downlink.
- the figure 3a diagrams the flow of the TCP packets in the downlink as they go through the first base station 105.
- the horizontal axis is time and the square boxes are the individual TCP packets.
- a time period 300 preceding the handover outage It is in this time period that the TCP packets are delayed.
- the time period 300 may be the handover preparation time.
- a duration time 310 of the handover outage is illustrated.
- the server 140 sends the TCP packets to the first base station 105 in a steady stream.
- the TCP packets leaving the first base station 105, going to the user equipment 1 35, are delayed to increase the estimate of RTT.
- the delay of the individual TCP packets may first be increased in the beginning of the sequence of TCP packets, and then be decreased towards the end of the sequence. This is to gradually increase the RTT of the individual TCP packets in the beginning of the sequence to gradually adapt the RTO, while increasing the RTT sufficiently by decreasing the delay of the individual TCP packets towards the end of the sequence.
- arrows are drawn to indicate which incoming TCP packet corresponds to which outgoing TCP packet, and the inclination of the individual arrows hence illustrate how much each individual TCP packet is deliberately delayed by the first base station 105.
- Figure 3b illustrates, schematically and by way of example, the estimated RTT at the user equipment 135 sender node when downlink TCP packets including ACKs are delayed according to a scheme as that described in relation to figure 3a. Note that the delay of downlink TCP packets result in an increase of estimated RTT for uplink data transfer.
- the first base station 105 may delay downlink TCP ACKs from the server 140 to the user equipment 135. The first base station 105 may then increase the delay of the individual TCP packets gradually as has previously been described, so that no TCP timeout will occur for the delayed TCP packets. In addition, all the TCP ACKs may be sent out to the user equipment 135 before the user equipment 135 gets detached from the first base station 105, i.e. , before the start of the handover outage.
- the start of the handover outage may be a RRC connection reconfiguration.
- FIG 4a illustrates a flow of TCP packets passing through the first base station 105 and being delayed in the uplink instead according to some embodiments herein.
- the TCP packets depicted as in the figure 4a are hence uplink TCP packets.
- a time period 400 preceding the handover outage It is in this time period that the TCP packets are delayed.
- the time period 400 may be the handover preparation time.
- a duration time 410 of the handover outage is illustrated.
- the horizontal axis is time and the square boxes are the individual uplink TCP packets.
- the user equipment 135 sends the TCP packets to the first base station 105 in a steady stream.
- TCP packets leaving the first base station 105, going to the server 40, are delayed after the handover decision has been taken to increase the estimate of RTT.
- the delay of the individual TCP packets may increase in the beginning of the sequence to gradually increase the RTT estimate and the RTO.
- some delayed TCP packets towards the end of the sequence need not leave the first base station 105 before the handover outage occurs.
- arrows are drawn to indicate which incoming TCP packet corresponds to which outgoing TCP packet, and the inclination of the individual arrows hence illustrate how much each individual TCP packet is deliberately delayed by the first base station 105.
- Figure 4b illustrates, schematically and by way of example, the estimated RTT at the server 140 for downlink data transfer when the uplink TCP packets including ACKs are delayed according to a scheme as that described in relation to figure 4a.
- TCP specific parameters For the first base station 105 to deliberately delay the TCP packets, it may be useful to know TCP specific parameters at the user equipment 135 and/or at the server 140, for example RTOmin.
- the default value for RTOmin is 200 ms.
- the same value is also used in Android phones, as they are based on Linux.
- other type of phones such as IPhone or others using Windows mobile as OS probably has its own default setting for RTOmin.
- IMEI International Mobile Equipment Identity
- the duration of the time between the time instant that the first base station 105 obtains an indication that a handover is upcoming, to the time instant that the first base station 105 loses connection to the user equipment 135, i.e. the start of the handover outage, may be referred to as the handover preparation time.
- This may be the time used for delaying downlink TCP packets. In the uplink, the delaying may continue after the start of the handover outage since the TCP packets may still be sent from the first base station 105 to the server 140 during the handover outage as illustrated in figure 4a.
- the indication of a handover being upcoming may be for example a measurement report as in the example in figure 2, or a handover decision.
- the handover preparation time may be from a handover decision to a RRC connection reconfiguration.
- a minimum handover preparation time may be 19 ms, and an average handover preparation time may be 32 ms, based on more than 1 million samples of data.
- a further question is how much time the first base station 105 may buffer each individual TCP packet.
- the maximum buffering time may be the handover preparation time, as when the user equipment 135 loses the connection to the first base station 105, no TCP packets may be sent to the user equipment 135.
- the TCP ACKs may still be delayed towards the server 140. So in the uplink TCP packet case the first base station 105 may delay TCP packets up to the handover outage time to significantly increase estimated RTT and RTO.
- FIG. 5 shows details in a table of an example of TCP packet delays in the downlink.
- the TCP packets are TCP ACKs from the server 140 to the user equipment 135.
- TCP packet number i.e. the time instant at which the TCP packet arrives at the first base station 105
- outgoing time i.e. the time instant that the delayed TCP packet is sent from the first base station 105 to the user equipment 135.
- the outgoing time for different TCP packets may differ slightly but all are sent shortly before the handover outage.
- all packets are sent out at time 32.
- the handover preparation time is 32 ms
- the handover outage time is 90 ms
- RTT of packets is 60 ms before the handover
- one TCP packet arrives every millisecond, which corresponds to 12Mbit/s.
- the first TCP packet experiencing handover will have an RTT of around 150 ms.
- FIG 3b relating to delaying of downlink TCP packets, and in the table in figure 5, it is shown that the estimated RTT, and the corresponding SRTT and RTO, initially increase, and that in the illustrated example the RTO may be increased to above 150 ms. However, RTT and hence RTO starts to decrease after some TCP packets when less time may be used for delaying TCP packets arriving shortly before the handover outage, e.g. shortly before RRC connection reconfiguration.
- Figure 6 shows details in a table of an example of TCP packet delays in the uplink.
- the TCP packets are TCP ACKs from the user equipment 135 to the server 140.
- TCP packet number i.e. the time instant at which the TCP packet arrives at the first base station 105
- outgoing time i.e. the time instant that the delayed TCP packet is sent from the first base station 105 to the server 140.
- the handover preparation time is 32 ms
- the handover outage time is 90 ms
- RTT of packets is 60 ms before the handover
- one TCP packet arrives every millisecond, which corresponds to 12Mbit/s.
- the first TCP packet experiencing handover will have an RTT of around 150 ms.
- the RTO may be increased to a much higher value than 150 ms.
- outgoing time could be 60 ms as this packet may be delayed at most 60 ms without causing a TCP timeout.
- uplink TCP ACKs from the user equipment 135 to the server 140 may be delayed in a very efficient way, and thanks to this, TCP timeouts may with a high probability timeouts be avoided.
- the maximum TCP packet delay may be limited to the handover preparation time of roughly 32 ms, so it it may in some cases be uncertain if all TCP timeouts may be avoided. Therefore, two additional ways to improve the algorithm further in the case of delaying downlink TCP ACKs according to some embodiments herein will shortly be describe in the following.
- the first approach is to stop sending TCP ACKs to the user equipment 135 when the RTO is above 150 ms and is decreasing, and instead forward the remaining TCP packets to the second base station 1 15. For example, for the TCP packet details in the table in figure 5, after sending the first 16 packets, the last 16 packets may be sent to the second base station 1 10.
- the user equipment 135, which is the sender in this example, will then have an RTO of 158.6 ms.
- the second approach is to use the TCP timestamp option.
- the timestamp option is now used by default in Linux implementations.
- the basic idea is that the TCP data sender puts the TCP data packet sending time on the TCP data packet.
- the TCP data packet receiver copies this time into the TCP ACK for this TCP data packet, and the sender may then use this sending time of the TCP data packet and the receipt time of the TCP ACK to compute RTT of the TCP packet.
- the sending time of the TCP ACK is altered in the first base station 105, the computed RTT may be increased, thus avoiding a timeout.
- this approach alters the TCP packet itself, it may some unwanted side effects.
- Embodiments herein provide advantages in both uplink and downlink TCP data transfer.
- embodiments herein reduce the number of TCP timeouts during handover which in turn improves the TCP performance.
- embodiments herein may reduce the amount of TCP packet forwarding between the first base station 105 and the second base station 1 15.
- the number of TCP timeouts may also be reduced.
- the network node handles TCP packet transferral between the user equipment 135 in the cellular network 100 and the server 140.
- the user equipment 135 and the server 140 are as previously mentioned configured to adapt a retransmission timeout, RTO, setting based on round trip times, RTTs, for performed TCP packet transferrals.
- RTO retransmission timeout
- the cellular network 100 and the user equipment 135 may be of any of the previously described types.
- the network node may be the first base station 105, the serving gateway 125 or the PDN gateway 130, which too may be of any of the previously described types.
- the network node may be the core network router within control of an operator of the cellular network 100, or another suitable network node along the pathway of the TCP packet.
- round trip time is understood the time it takes for a TCP packet comprising data, i.e. a TCP data packet, to go from its sender to its destination, plus the time it takes for a TCP packet comprising an acknowledgement of receipt of the data to go from the destination to the sender.
- TCP packet is hence understood either the TCP packet comprising the data or the TCP packet comprising the acknowledgement of the data.
- TCP packet transferral is understood forming part of a TCP packets pathway between the server 140 and the user equipment 135.
- the upcoming handover may be an inter-frequency handover or an intra- frequency handover, it may also be an inter-system handover or an intra-system handover.
- the server 140 may be another entity such as another user equipment.
- the method comprises the action 704 which will be described below.
- the method may further comprise one or more of the optional actions701 -703 which will be described first.
- the network node 105, 125, 130 obtains an estimate of an expected round trip time for the TCP packet.
- the estimated of the expected round trip time may be obtained in any of the previously described ways.
- the expected round trip time is based on a deep packet inspection of a previously transferred TCP packet.
- the network node 105, 125, 130 obtains an estimate of an expected duration time of the handover outage.
- the network node 105, 125, 130 obtains a TCP
- TCP parameter which TCP parameter is specific to the user equipment 135 and/or to the server 140.
- the TCP parameter may be for example the minimum RTO for the user equipment
- the network node, 105, 123, 130 deliberately delays a transferral of the TCP packet between the server 140 and the user equipment 135 to increase the round trip time for the TCP packet.
- the TCP packet is delayed when the network node obtains an indication of a handover outage 310, 410 being upcoming for the user equipment 135.
- the delaying is performed in a time period (300, 400) preceding the indicated handover outage 310, 410.
- the RTO in the sender i.e. the user equipment 135 or the server 140 is increased. This makes allowance for the handover outage time due to which RTT is prolonged for TCP packets sent during the handover. Such prolonged RTTs would otherwise likely have caused unnecessary TCP timeouts in the sender. Thanks to embodiments herein, such TCP timeouts are avoided.
- the delaying in action 704 may be performed based on the expected round trip time.
- the delaying in action 704 may be performed based on the estimate of the expected duration time of the handover outage.
- the delaying in action 704 may be performed based on the TCP parameter.
- the TCP packet is represented by a sequence of individual TCP packets.
- the delaying performed in action 704 may then comprise delaying the individual TCP packets in the sequence. This may be done in any of the previously described ways, and an advantage with this is that a gradual adaption and satisfactory increase of the RTO adaptation is possible.
- the TCP packets in the sequence are downlink TCP packets, the delaying of the individual TCP packets decreases towards the end of the sequence.
- the delaying of the individual TCP packets then first increases in the beginning of the sequence, and then decreases towards the end of the sequence.
- the delayed TCP packets need be sent before the indicated handover outage occurs, gradually decreasing the delay between the individual TCP packets to send as many TCP packets as possible soon before the handover timeout occurs enables a larger increase of the RTO setting.
- the TCP packets in the sequence are uplink TCP packets, and the delaying of the individual TCP packets increases in the beginning of the sequence. According to some embodiments, the delaying of the individual TCP packets then first increases in the beginning of the sequence, and then becomes steady towards the end of the sequence.
- the indication is obtained from an entity in control of the upcoming handover such as for example the first base station 105 or an MME.
- the indication may be for example a measurement report or a handover decision.
- the network node 105, 125, 130 comprises an arrangement schematically depicted in figure 8.
- the network node 105, 125, 130 is adapted to handle TCP packet transferral between the user equipment 135 in the cellular network 100 and the server 140.
- the user equipment 135 and the server 140 are configured to adapt a retransmission timeout, RT0, setting based on round trip times for performed TCP packet transferals.
- the network node 105, 125, 130 may be the first base station 105, the serving gateway 125 or the PDN gateway 130, which too may be of any of the previously described types.
- the term “configured to” used herein may also be referred to as “arranged to”.
- the term “unit” may comprise software implementations and/or hardware circuitry.
- the network node comprises a delaying unit 800.
- the delaying unit 800 is configured to, when obtaining an indication of a handover outage 310, 410 being upcoming for the user equipment 135, deliberately delay, in a time period 300, 400 preceding the indicated handover outage 310, 410, a transferal of a TCP packet between the server 140 and the user equipment 135 to increase the round trip time for the TCP packet.
- the TCP packet may be represented by a sequence of TCP packets, and the delaying unit 800 may then further be configured to delay the individual TCP packets in the sequence.
- the TCP packets in the sequence may be downlink TCP packets, and the delaying unit 800 may further be configured to decrease the delay of the individual TCP packets towards the end of the sequence.
- the delaying unit 800 may further be configured to first increase the delay of the individual TCP packets in the beginning of the sequence, and then decrease the delay of the individual TCP packets towards the end of the sequence.
- the TCP packets in the sequence are uplink TCP packets, and the delaying unit 800 may further be configured to increase the delay of the individual TCP packets in the beginning of the sequence.
- the delaying unit 800 is further configured to first increase the delay of the individual TCP packets in the beginning of the sequence, and then let the delay become steady towards the end of the sequence.
- the delaying unit 800 is further configured to obtain the indication from an entity in control of the upcoming handover.
- the network node 105, 125, 130 further comprises an obtaining unit 810.
- the obtaining unit 810 may be configured to obtain an estimate of an expected round trip time for the TCP packet.
- the delaying unit 800 may then further be configured to delay the TCP packet based on the expected round trip time.
- the expected round trip time is based on a deep packet inspection of a previously transferred TCP packet.
- the obtaining unit 810 may be configured to obtain an estimate of an expected duration time of the handover outage, then the delaying unit 800 may further be configured to delay the TCP packet based on the expected duration time of the handover outage.
- the obtaining unit 810 may be configured to obtain a TCP parameter, which TCP parameter is specific to the user equipment 135 and/or the server 140. Then, the delaying unit 800 may further be configured to delay the TCP packet based on the TCP parameter. It is to be understood that the obtaining unit 810 referred to above may in some embodiments be several different obtaining units.
- the network node comprises a transceiver 820 which is configured to receive and transmit TCP packets.
- the embodiments of the network node 105, 125, 130 for improving transmission control protocol, TCP, performance in the cellular network 100 may be implemented through one or more processors, such as a processor 830 in the depicted network node 105, 125, 130 in figure 9, together with computer program code for performing the actions of embodiments herein.
- the program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the network node 105, 125, 130.
- One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick.
- the computer program code may furthermore be provided as pure program code on a server and downloaded to network node 105, 25, 130 e.g. remotely.
- the network node 105, 125, 130 may further comprise a memory 840 comprising one or more memory units.
- the memory 840 may be arranged to be used to store data or for buffering one or more TCP packets to delay them . It may further be arranged to store applications to perform the actions of the embodiments herein when being executed in network node 105, 125, 130.
- Some embodiments of the network node 105, 125, 130 for improving transmission control protocol, TCP, performance in the cellular network 100 may further comprise a deep packet inspection unit 850 as previously described.
Abstract
Description
Claims
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/SE2011/051408 WO2013077786A1 (en) | 2011-11-23 | 2011-11-23 | Methods and arrangements for improving transmission control protocol performance in a cellular network |
Publications (3)
Publication Number | Publication Date |
---|---|
EP2749118A1 true EP2749118A1 (en) | 2014-07-02 |
EP2749118A4 EP2749118A4 (en) | 2015-03-25 |
EP2749118B1 EP2749118B1 (en) | 2018-01-10 |
Family
ID=48470127
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP11876384.6A Not-in-force EP2749118B1 (en) | 2011-11-23 | 2011-11-23 | Improving tcp performance in a cellular network |
Country Status (3)
Country | Link |
---|---|
US (1) | US9788362B2 (en) |
EP (1) | EP2749118B1 (en) |
WO (1) | WO2013077786A1 (en) |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7675854B2 (en) | 2006-02-21 | 2010-03-09 | A10 Networks, Inc. | System and method for an adaptive TCP SYN cookie with time validation |
US8312507B2 (en) | 2006-10-17 | 2012-11-13 | A10 Networks, Inc. | System and method to apply network traffic policy to an application session |
US9960967B2 (en) | 2009-10-21 | 2018-05-01 | A10 Networks, Inc. | Determining an application delivery server based on geo-location information |
US9215275B2 (en) | 2010-09-30 | 2015-12-15 | A10 Networks, Inc. | System and method to balance servers based on server load status |
US9609052B2 (en) | 2010-12-02 | 2017-03-28 | A10 Networks, Inc. | Distributing application traffic to servers based on dynamic service response time |
US8897154B2 (en) | 2011-10-24 | 2014-11-25 | A10 Networks, Inc. | Combining stateless and stateful server load balancing |
US9094364B2 (en) | 2011-12-23 | 2015-07-28 | A10 Networks, Inc. | Methods to manage services over a service gateway |
US10044582B2 (en) | 2012-01-28 | 2018-08-07 | A10 Networks, Inc. | Generating secure name records |
US8782221B2 (en) | 2012-07-05 | 2014-07-15 | A10 Networks, Inc. | Method to allocate buffer for TCP proxy session based on dynamic network conditions |
US9843484B2 (en) | 2012-09-25 | 2017-12-12 | A10 Networks, Inc. | Graceful scaling in software driven networks |
US9705800B2 (en) | 2012-09-25 | 2017-07-11 | A10 Networks, Inc. | Load distribution in data networks |
US10021174B2 (en) | 2012-09-25 | 2018-07-10 | A10 Networks, Inc. | Distributing service sessions |
US10002141B2 (en) | 2012-09-25 | 2018-06-19 | A10 Networks, Inc. | Distributed database in software driven networks |
US10136355B2 (en) | 2012-11-26 | 2018-11-20 | Vasona Networks, Inc. | Reducing signaling load on a mobile network |
US9338225B2 (en) | 2012-12-06 | 2016-05-10 | A10 Networks, Inc. | Forwarding policies on a virtual service network |
US9531846B2 (en) * | 2013-01-23 | 2016-12-27 | A10 Networks, Inc. | Reducing buffer usage for TCP proxy session based on delayed acknowledgement |
JP2014165551A (en) * | 2013-02-21 | 2014-09-08 | Fujitsu Ltd | Communication device, communication method, program, and communication system |
US9900252B2 (en) | 2013-03-08 | 2018-02-20 | A10 Networks, Inc. | Application delivery controller and global server load balancer |
WO2014144837A1 (en) | 2013-03-15 | 2014-09-18 | A10 Networks, Inc. | Processing data packets using a policy based network path |
US10027761B2 (en) | 2013-05-03 | 2018-07-17 | A10 Networks, Inc. | Facilitating a secure 3 party network session by a network device |
US10038693B2 (en) | 2013-05-03 | 2018-07-31 | A10 Networks, Inc. | Facilitating secure network traffic by an application delivery controller |
CN103401665B (en) * | 2013-06-28 | 2016-12-28 | 国家超级计算深圳中心(深圳云计算中心) | The optimization method and device of retransmission timeout timer in cluster storage system |
US10341881B2 (en) | 2013-11-12 | 2019-07-02 | Vasona Networks, Inc. | Supervision of data in a wireless network |
US10039028B2 (en) | 2013-11-12 | 2018-07-31 | Vasona Networks Inc. | Congestion in a wireless network |
MX368603B (en) * | 2013-11-12 | 2019-10-09 | Vasona Networks Inc | Supervision of data in a wireless network. |
US10230770B2 (en) | 2013-12-02 | 2019-03-12 | A10 Networks, Inc. | Network proxy layer for policy-based application proxies |
EP2882163A1 (en) * | 2013-12-09 | 2015-06-10 | Alcatel Lucent | Method and system for scheduling a push data transmission |
US10020979B1 (en) | 2014-03-25 | 2018-07-10 | A10 Networks, Inc. | Allocating resources in multi-core computing environments |
US9942152B2 (en) | 2014-03-25 | 2018-04-10 | A10 Networks, Inc. | Forwarding data packets using a service-based forwarding policy |
US9942162B2 (en) | 2014-03-31 | 2018-04-10 | A10 Networks, Inc. | Active application response delay time |
US9806943B2 (en) | 2014-04-24 | 2017-10-31 | A10 Networks, Inc. | Enabling planned upgrade/downgrade of network devices without impacting network sessions |
US9906422B2 (en) | 2014-05-16 | 2018-02-27 | A10 Networks, Inc. | Distributed system to determine a server's health |
US9986061B2 (en) | 2014-06-03 | 2018-05-29 | A10 Networks, Inc. | Programming a data network device using user defined scripts |
US9992229B2 (en) | 2014-06-03 | 2018-06-05 | A10 Networks, Inc. | Programming a data network device using user defined scripts with licenses |
US10129122B2 (en) | 2014-06-03 | 2018-11-13 | A10 Networks, Inc. | User defined objects for network devices |
US9009332B1 (en) * | 2014-07-18 | 2015-04-14 | Kaspersky Lab Zao | Protection against network-based malicious activity utilizing transparent proxy services |
WO2016100890A1 (en) * | 2014-12-19 | 2016-06-23 | Nokia Solutions And Networks Oy | Smooth bandwidth-delay product variation inside wireless networks |
CN115038065A (en) * | 2015-06-02 | 2022-09-09 | 瑞典爱立信有限公司 | Network node and method therein for handover in a wireless communication network |
JP6545827B2 (en) | 2015-06-02 | 2019-07-17 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | Communication device for handover in a wireless communication network and method thereof |
US10581976B2 (en) | 2015-08-12 | 2020-03-03 | A10 Networks, Inc. | Transmission control of protocol state exchange for dynamic stateful service insertion |
US10243791B2 (en) | 2015-08-13 | 2019-03-26 | A10 Networks, Inc. | Automated adjustment of subscriber policies |
US10096203B2 (en) * | 2015-12-15 | 2018-10-09 | Igt Canada Solutions Ulc | Automatic electronic gaming system timeout calibration |
US10318288B2 (en) | 2016-01-13 | 2019-06-11 | A10 Networks, Inc. | System and method to process a chain of network applications |
KR102537960B1 (en) * | 2016-01-20 | 2023-05-31 | 삼성전자주식회사 | Apparatus and method for controlling transmission in a high thoughput werelless network |
US20180041415A1 (en) * | 2016-08-03 | 2018-02-08 | Qualcomm Incorporated | Mitigation of transmission control protocol throughput degradation in communication devices due to predictable radio impairment events |
US10389835B2 (en) | 2017-01-10 | 2019-08-20 | A10 Networks, Inc. | Application aware systems and methods to process user loadable network applications |
US11503500B2 (en) | 2017-11-28 | 2022-11-15 | Samsung Electronics Co., Ltd. | Method and a user equipment (UE) for transport layer optimization using a preemptive cross layer signaling |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2372406A (en) * | 2001-02-20 | 2002-08-21 | Motorola Inc | Preparing for handover in a communication system |
US20070254664A1 (en) * | 2006-04-28 | 2007-11-01 | Alcatel Lucent | Method of performing a handover |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7184401B2 (en) * | 2001-02-05 | 2007-02-27 | Interdigital Technology Corporation | Link-aware transmission control protocol |
US20020167948A1 (en) * | 2001-05-09 | 2002-11-14 | Dayong Chen | Communications methods, apparatus, computer program products and data structures using segment sequence numbers |
US6947444B2 (en) * | 2001-06-06 | 2005-09-20 | Ipr Licensing, Inc. | Method and apparatus for improving utilization efficiency of wireless links for web-based applications |
KR20050085742A (en) | 2002-12-19 | 2005-08-29 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | Protecting real-time data in wireless networks |
US7321567B2 (en) * | 2003-09-30 | 2008-01-22 | Motorola, Inc. | Method and apparatus for preventing a spurious retransmission after a planned interruption of communications |
KR100619949B1 (en) * | 2004-10-29 | 2006-09-13 | 엘지전자 주식회사 | Method for controlling tcp flow in fast mobile network |
KR100883790B1 (en) * | 2005-10-17 | 2009-02-19 | 삼성전자주식회사 | Apparatus and method for processing handover in a multi-hop relay broadband wireless access communication system |
JP5108244B2 (en) * | 2006-03-30 | 2012-12-26 | 株式会社エヌ・ティ・ティ・ドコモ | Communication terminal and retransmission control method |
KR100846344B1 (en) * | 2007-01-05 | 2008-07-15 | 삼성전자주식회사 | Apparatus and method for reducing transmission control protocol latency in portable communication system |
CN101114999B (en) * | 2007-08-26 | 2010-08-04 | 上海华为技术有限公司 | Data transmission control method and data transmission set |
US20090149185A1 (en) * | 2007-12-06 | 2009-06-11 | Motorola Inc | Method and apparatus for reducing missed paging messages and paging latency during cell reselection in a wireless network |
KR101056209B1 (en) * | 2009-04-14 | 2011-08-11 | 포항공과대학교 산학협력단 | SIP client device with adaptive codec conversion method and adaptive codec conversion function in handover between heterogeneous networks |
WO2012126509A1 (en) * | 2011-03-21 | 2012-09-27 | Nokia Siemens Networks Oy | Method and apparatus to improve tcp performance in mobile networks |
-
2011
- 2011-11-23 WO PCT/SE2011/051408 patent/WO2013077786A1/en active Application Filing
- 2011-11-23 EP EP11876384.6A patent/EP2749118B1/en not_active Not-in-force
- 2011-11-23 US US14/356,195 patent/US9788362B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2372406A (en) * | 2001-02-20 | 2002-08-21 | Motorola Inc | Preparing for handover in a communication system |
US20070254664A1 (en) * | 2006-04-28 | 2007-11-01 | Alcatel Lucent | Method of performing a handover |
Non-Patent Citations (2)
Title |
---|
DURST R C ET AL: "TCP EXTENSIONS FOR SPACE COMMUNICATIONS", ACM WIRELESS NETWORKS, vol. 3, no. 5, October 1997 (1997-10), pages 389-403, XP000728936, ISSN: 1022-0038, DOI: 10.1023/A:1019190124953 * |
See also references of WO2013077786A1 * |
Also Published As
Publication number | Publication date |
---|---|
US9788362B2 (en) | 2017-10-10 |
US20140286313A1 (en) | 2014-09-25 |
EP2749118A4 (en) | 2015-03-25 |
WO2013077786A1 (en) | 2013-05-30 |
EP2749118B1 (en) | 2018-01-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9788362B2 (en) | Methods and arrangements for improving transmission control protocol performance in a cellular network | |
KR101564697B1 (en) | Method and apparatus to improve tcp performance in mobile networks | |
US9954789B2 (en) | Efficient discard mechanism in small cell deployment | |
EP2862389B1 (en) | Handover prediction using historical data | |
US11477845B2 (en) | Network node and methods therein for packet data convergence protocol (PDCP) reordering | |
Racz et al. | Handover performance in 3GPP long term evolution (LTE) systems | |
WO2015170530A1 (en) | Communication system | |
JP6628227B2 (en) | Method and apparatus for improving communication quality in a mobile communication network | |
US10412634B2 (en) | Predictive adaptive queue management | |
EP3308596A1 (en) | Methods and network nodes for evaluating a connection | |
WO2013167647A1 (en) | Mechanism for controlling buffer setting in flow control | |
JP6006440B2 (en) | Apparatus and method for modem assisted video phone | |
WO2008119384A1 (en) | Buffer transfer in a communications network | |
JP5182218B2 (en) | Mobile communication system and radio base station apparatus | |
EP3410658B1 (en) | Congestion control method, apparatus, and related device | |
Ben Halima | Service-Aware Performance Optimization of Wireless Access Networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20140324 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAX | Request for extension of the european patent (deleted) | ||
A4 | Supplementary search report drawn up and despatched |
Effective date: 20150220 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 29/06 20060101ALI20150216BHEP Ipc: H04W 36/08 20090101ALI20150216BHEP Ipc: H04W 80/06 20090101AFI20150216BHEP |
|
17Q | First examination report despatched |
Effective date: 20150306 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
INTG | Intention to grant announced |
Effective date: 20171016 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP Ref country code: AT Ref legal event code: REF Ref document number: 963761 Country of ref document: AT Kind code of ref document: T Effective date: 20180115 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602011045043 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20180110 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 963761 Country of ref document: AT Kind code of ref document: T Effective date: 20180110 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180410 Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180411 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180410 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180510 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602011045043 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
26N | No opposition filed |
Effective date: 20181011 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181123 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20181130 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: MM4A |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181130 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181123 Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20181123 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20180110 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20180110 Ref country code: HU Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO Effective date: 20111123 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20211129 Year of fee payment: 11 Ref country code: DE Payment date: 20211126 Year of fee payment: 11 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R119 Ref document number: 602011045043 Country of ref document: DE |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20221123 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20221123 Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230601 |