EP1959693A1 - Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil - Google Patents

Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil Download PDF

Info

Publication number
EP1959693A1
EP1959693A1 EP07425087A EP07425087A EP1959693A1 EP 1959693 A1 EP1959693 A1 EP 1959693A1 EP 07425087 A EP07425087 A EP 07425087A EP 07425087 A EP07425087 A EP 07425087A EP 1959693 A1 EP1959693 A1 EP 1959693A1
Authority
EP
European Patent Office
Prior art keywords
base station
representation
user equipment
transport layer
acknowledgment
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.)
Withdrawn
Application number
EP07425087A
Other languages
German (de)
English (en)
Inventor
Simone Redana
Dzmitry Kliazovich
Nicola Riato
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks SpA
Original Assignee
Siemens Networks SpA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Siemens Networks SpA filed Critical Siemens Networks SpA
Priority to EP07425087A priority Critical patent/EP1959693A1/fr
Priority to AT08708997T priority patent/ATE521203T1/de
Priority to PCT/EP2008/051804 priority patent/WO2008101861A1/fr
Priority to EP08708997A priority patent/EP2130387B1/fr
Publication of EP1959693A1 publication Critical patent/EP1959693A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/10—Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface

Definitions

  • the present invention refers to data packet transmissions in broadband wireless communications networks, and more particularly it concerns a method of optimising error recovery mechanisms in communications using Transmission Control Protocol / Internet Protocol (TCP/IP) suite, so as to reduce overhead of uplink transmissions and delays.
  • TCP/IP Transmission Control Protocol / Internet Protocol
  • the invention is especially useful for classes of service communications where traffic is substantially asymmetric, with a predominance of the downlink component.
  • traffic is substantially asymmetric, with a predominance of the downlink component.
  • 3G LTE 3rd Generation Long Term Evolution
  • 3GPP 3rd Generation Partnership Group
  • the invention is preferably applied in 3G LTE systems and will be disclosed hereinafter in detail in connection with the preferred application.
  • 3G LTE is an attempt to step into wireless broadband taken by cellular providers and equipment vendors. Details on 3G LTE can be found in a number of documents of 3GPP: we mention for instance 3GPP Technical Report (TR) 10.164, "Physical layer aspects for evolved Universal Terrestrial Radio Access (UTRA)", 3GPP TR 10.913 "Requirements for Evolved UTRA", 3GPP TR 23.882 "3GPP System Architecture Evolution: Report on Technical Options and Conclusions” and 3GPP Technical Specification (TS) 36.300, "E-UTRA and E-UTRAN: Overall description”.
  • TR Technical Report
  • UTRA Universal Terrestrial Radio Access
  • 3GPP TR 10.913 Requirements for Evolved UTRA
  • 3GPP TR 23.882 3GPP System Architecture Evolution: Report on Technical Options and Conclusions
  • TS Technical Specification
  • 3G LTE introduces evolved radio interface with major enhancement coming from the use of Orthogonal Frequency Division Multiplexing (OFDM) and multiple antenna techniques.
  • OFDM Orthogonal Frequency Division Multiplexing
  • These technologies are already available on the market and are used e.g. in systems conforming to IEEE 802.16 standard, such as those proposed by the Worldwide Interoperability for Microwave Access (WiMAX) forum.
  • 3G LTE specifies evolution of network architecture (System Architecture Evolution, SAE), which is designed to contain fewer network nodes and is focused on packet data communications using the TCP/IP protocol suite, rather than on the traditional circuit-switched approach.
  • SAE System Architecture Evolution
  • 3G LTE 3G LTE, similar to other types of wireless networks, suffers from high error rates present at radio channel.
  • the TCP/IP protocol suite was originally designed for fixed wired networks where Bit Error Rate (BER) typically varies from 10 -6 to 10 -8 , while for wireless channels BER varies from 10 -1 to 10 -3 .
  • BER Bit Error Rate
  • 3G LTE employs an error recovery technique at the Link Layer (LL), including Automatic Repeat reQuest (ARQ) at the Radio Link Control (RLC) sublayer and Hybrid ARQ (HARQ) at the Medium Access Control (MAC) sublayer.
  • ARQ Automatic Repeat reQuest
  • RLC Radio Link Control
  • HARQ Hybrid ARQ
  • MAC Medium Access Control
  • the receiving system checks the Cyclic Redundancy Code (CRC). If the CRC is correct, an acknowledgment (ACK) is sent back to the sender and the received packet is forwarded to upper layers of the protocol stack for processing. If the CRC check fails, the packet is dropped silently or with negative ACK (NACK) notification sent to the sender.
  • CRC Cyclic Redundancy Code
  • ACK acknowledgment
  • NACK negative ACK
  • HARQ if the CRC is not correct, the packet is not dropped at the receiver side. It is stored for the case when retransmitted packet will be still erroneous and combined recovery can be attempted. This technique is known as "chase combining". Eventually the error is resolved or the maximum number of retransmissions is reached. Each following retransmission can contain additional redundancy information ("incremental redundancy").
  • the MAC implementation in 3G LTE considers a HARQ of stop-and-wait type, which provides the sender with a binary ACK/NACK feedback for every transmitted packet.
  • BER is equal to 10 -2 for no retransmission, 10 -3 after HARQ at the MAC layer, and 10 -6 after ARQ at the RLC layer.
  • the link layer is not the only layer employing error recovery mechanisms.
  • TCP reliability is obtained through the utilization of a positive acknowledgement scheme that specifies the TCP receiver to acknowledge data successfully received from the sender.
  • the TCP header reserves special fields for carrying acknowledgement information.
  • the TCP receiver can produce a TCP acknowledgment (TCP-ACK) as a standalone packet or, in case of bi-directional data exchange, encapsulate it into outgoing TCP segments.
  • TCP-ACK TCP acknowledgment
  • the TCP ACK as any other payload packet, requires a protocol overhead added at the lower protocol layers (IP, link and physical layers) and therefore consumes a relatively large amount of uplink bandwidth resources, thereby reducing overall system capacity.
  • the user equipment has to negotiate bandwidth for the uplink transmission, and this is a further uplink overhead and causes a delay increase due to the time elapsing between the bandwidth request and the bandwidth grant reception at the user equipment.
  • the relevant acknowledgment is sent to the Snoop Agent of the sender node through the link layer interface, and the sender node's agent generates the TCP ACK packet according to the selected TCP acknowledgment scheme.
  • the Snoop Agent of the receiver node drops the TCP ACK packet generated by the TCP layer of the same node.
  • the prior art solution has been studied for mostly static wireless networks, like those conforming to IEEE 802.11 standards, e.g. for Wireless Fidelity (WiFi) networks, and even if its concepts can be applied to a network supporting mobility like 3G LTE, application in a mobile environment is complex and costly.
  • the prior art solution entails the need of storing at a base station all TCP flow related information (sender sequence number, acknowledgement number, last acknowledged packet sequence number) for every flow traversing that base station. This entails that the base station is to support the whole of the TCP and IP protocol layers, and, in case UE performs soft (hard) mobility handover, the whole of the flow related information is to be transferred to the new base station, this being a time-consuming operation.
  • a further disadvantage is that the prior art solution is not susceptible of a gradual introduction in networks already deployed: indeed, in case the Snoop Agent is implemented in a UE but not in the eNB, the latter would never be able to send its TCP ACK to the packet source, so that a standing retransmission of packets would take place.
  • the invention provides, in a first aspect, a method comprising the steps of:
  • the representation of the transport layer acknowledgment can be generated at both the base station and the user equipment. In the alternative, it can be generated at the base station only and transmitted to the user equipment along with a data unit. In such case, at the user equipment the representation is extracted from the received data flow and transmitted back to the base station when the transport layer acknowledgment for that received data unit is generated.
  • the representation can be obtained by applying a hash function to predetermined header fields of a received data unit or of the transport layer acknowledgment.
  • the hash function can provide the checksum of said header fields.
  • the data units already include a checksum field in their headers the content of such field can be used as the representation, dispensing with an explicit generation thereof.
  • the invention provides, in a second aspect, a base station for a wireless communication system, having means for optimising error recovery procedures during a data transfer phase of downlink packet transmissions over a radio channel, wherein said optimising means comprise:
  • the invention provides, in a third aspect, a user equipment for use in a wireless communication system, comprising means for optimising error recovery procedures during a data transfer phase of downlink data transmissions over a radio channel, wherein said optimising means comprise a generating unit arranged to:
  • the generating unit is replaced by a unit extracting the representation generated at the base station from a received data flow and transmitting said representation back to the base station.
  • Fig. 1 illustrates the logical high-level architecture of a 3G LTE system 1.
  • Users 10 communicate with evolved packet core 30 via the evolved radio access network (E-UTRAN) 20 including base stations (enhanced Nodes B, eNBs), not shown in this Figure.
  • Evolved packet core 30 provides local mobility management between eNBs and internetworking with previously released 2G, 2.5G and 3G systems (block GERAN/UTRAN 40), as well as with IP-based 3GPP wireless local area networks (block 50 labelled WLAN 3GPP IP Access) and with non-3GPP wireless technologies like WiFi, WiMAX or even with wired networks (block 60 labelled "non-3GPP IP access").
  • Evolved Packet Core 30 is connected also with external packet data networks like network 70.
  • Network 70 may be an operator-external public or private packet data network or an intra-operator packet data network, e.g. for provision of IP Multimedia services. Further details about 3G LTE are not necessary for the understanding of the invention and can be found in the above-mentioned 3GPP documents.
  • Fig. 2 illustrates a conventional TCP data packet delivery in 3G LTE network.
  • a single packet delivery from a file server 80 to user equipment 10 via eNB 21 and radio channel 100 is considered.
  • the problem to be solved by the invention essentially occurs in unidirectional transmissions, since in case of bi-directional transmissions the TCP ACK can be encapsulated into an uplink data packet.
  • both 3G LTE and standards IEEE 802.11 and 802.16 concern classes of services for which traffic is generally asymmetric, with the downlink component being predominant.
  • Enhanced Node B 21 upon reception of a TCP data packet from file server 80, forwards the received data packet over radio link 100 to the appropriate UE 10. For this downlink transmission, an overhead associated with physical, link and network layer headers (PHY/LUIP headers) is added to the TCP packet.
  • the MAC layer upon reception of the packet, the MAC layer generates and sends the HARQ ACK response (positive or negative, as the case may be) to eNB 21.
  • the received TCP data packet is forwarded up to the TCP layer of the protocol stack and, at the end of the processing in the stack, in case of successful packet delivery to UE 10, the TCP layer of UE 10 can generate a TCP layer acknowledgment TCP ACK to be sent to eNB 21.
  • TCP ACK As known to the skilled in the art, generation of the TCP ACK for each data packet is not necessary, and other options can be envisaged (e.g., delayed or selective TCP ACK).
  • eNB 21 will acknowledge the delivery of this and previously received data packets to file server 80 through an acknowledgment packet TCP ACK.
  • the ARQ process at the RLC layer is not shown, since the preferred embodiment of the invention described hereinafter exploits the HARQ acknowledgment at the MAC layer.
  • the TCP ACK generated by UE 10 is an ordinary payload for the UE link layer and is to be associated with PHY/LUIP overhead, so that it demands important uplink resources.
  • a TCP ACK packet is comprised of TCP (at least 20 bytes) and IP (20 bytes) headers, plus the Packet Data Convergence Protocol (PDCP) and RLC headers and the PHY CRC.
  • PDCP Packet Data Convergence Protocol
  • RLC Packet Data Convergence Protocol
  • UE 10 must request uplink resources for the TCP ACK packet transmission over radio channel 100 (this adding to the uplink overhead) and wait for receiving the respective grant, and the TCP ACK packet delivery to eNB 21 is to be acknowledged by the eNB HARQ entity.
  • the whole procedure is also rather complex and time-consuming.
  • controllers 23, 13 of enhanced Node B 21 and user equipment 10 are equipped with respective entities, preferably implemented as software modules, which, during the data transfer phase of a data connection, provide for substituting the transmission of a standalone TCP ACK packet over radio link 100 with the transmission of a much shorter MAC layer message including a representation of the TCP ACK packet.
  • the two entities are referred to as ARQ Proxy (for enhanced Node B 21) and ARQ client (for user equipment 10) and are shown in Fig. 3 by blocks 24 and 14, respectively.
  • ARQ Proxy for enhanced Node B 21
  • ARQ client for user equipment 10
  • the substitution of a standalone TCP ACK packet with a much shorter MAC message is based on the application of a same hash function to predefined header fields of a packet in both enhanced Node B 21 and user equipment 10 and on the use of the resulting hash table in enhanced Node B 21.
  • ARQ proxy 24 includes a TCP ACK generator 25 that sniffs the packets destined to the various UEs 10 and generates the TCP ACK packet acknowledging the reception of the data packet.
  • generator 25 has access to the headers of the network and transport layers and simply copies the required fields (IP addresses, port numbers and flow sequence number) into corresponding fields of a previously allocated TCP ACK packet template stored inside TCP ACK generator 25.
  • the generated TCP ACK is not immediately released into evolved network core 30 (for being sent to file server 80, if it is located outside network core 30), but it is stored in a hash table 27 together with a corresponding hash value (hereinafter referred to as TCP ACK index) computed by hash value calculator 26.
  • TCP ACK index a hash value computed by hash value calculator 26.
  • the actual release into network core 30 takes place at a later moment and is driven by the receiver, as it will become apparent below.
  • TCP ACK and the relevant hash value are generated and stored, the original TCP data packet continues its path towards UE 10.
  • the TCP ACK index is computed by index calculator 26 by using IP and TCP header fields of the TCP ACK packet or the received data packet as an input for the hash function. Taking into account the manner in which the TCP ACK is generated from the data packet, the result is a representation of the TCP ACK also in the second case.
  • ARQ proxy 24 and ARQ client 14 must operate on the same kind of packet (data or ACK). The drawing assumes that the hash function is applied to the header of the received data packet.
  • any hash function ensuring a sufficiently low probability of collisions could be employed to this end.
  • the chosen function must result in a limited resource demand for such transmission.
  • a function leading to a 16-bit index could be suitable.
  • the hash function provides a checksum of the input value. Hash functions are well known to the skilled in the art and no further details are necessary.
  • ARQ Client 14 essentially consists of a TCP ACK index calculator identical to calculator 26 in ARQ Proxy 24. In case of an outgoing standalone TCP ACK packet, the index calculator in ARQ Client 14 applies the same hash function as ARQ Proxy 24 to the same packet fields.
  • the computed index is passed to eNB 21 together with the HARQ acknowledgment and causes the reading of the proper TCP ACK from table 27 and its release into network core 30.
  • the index can thus be interpreted also as a request, from user UE 10 to eNB 21, to release the base station TCP ACK.
  • the index is delivered to eNB 21 by using an interface between ARQ Proxy 24 and ARQ client 14 defined at the MAC layer.
  • the standalone uplink TCP ACK packets with a length of the order of the tens of bytes are replaced by MAC layer messages that are e.g. 16 bit (2 byte) long.
  • each TCP ACK stored in hash table 27 has a lifetime that is assigned at the moment of TCP ACK generation. When the lifetime is exceeded, the relevant item is silently dropped from the hash table. By this mechanism, eNB 21 ensures that memory resources are freed for TCP ACKs not requested by UE.
  • the lifetime value can be set to be equal to TCP timeout.
  • ARQ client 14 Two positions are envisaged for ARQ client 14 in the UE's protocol stack: in enhanced transport layer TCP 15 ( Fig. 5A ) or standalone, on top MAC layer 16 ( Fig. 5B ).
  • ARQ client 14 is implemented inside the transport layer, whenever a TCP ACK is produced as a standalone packet by ACK generation module 17, ARQ client 14 generates the corresponding TCP ACK index and sends it to HARQ module 18 in MAC layer 16 for transmission to eNB 21. If the HARQ ACK message has an insufficient capacity to accommodate the index itself (this being the present situation for LTE) HARQ module 18 is to request bandwidth resources to eNB 21 for TCP ACK index transmission. The request is made by setting a bit ("resource reservation bit") forming an extension of said HARQ ACK message. One bit is sufficient, since the index has a constant and predetermined length (e.g. 16 bits) and hence also the resources needed for its transmission are constant and known to both UE 10 and eNB 21, which therefore can provide the UE with a grant of sufficient size. Note also that the transmission of one bit does not create any problem from the resource availability standpoint.
  • the originally generated TCP ACK packet travels the protocol stack down, and this involves corresponding processing at every layer, output queuing delay, and other procedures commonly performed by the protocol stack. Whichever comes first to the physical layer for transmission, the TCP ACK packet or the corresponding hash value, will be transmitted while the other one is cancelled. However, in general, the processing of the TCP ACK packet will be more time-consuming than the generation and processing of the index, so that the probability that the actual TCP ACK packet is to be transmitted is low. On the other hand, some form of transport layer acknowledgment (the index or the actual TCP ACK) has to be transmitted by user equipment 10 for the correct system operation.
  • ARQ Client 14 is preferably implemented as a standalone module positioned on top the MAC layer. Such implementation does not require the modification of the protocol stack core (TCP and IP layers) and can be introduced on the driver level or inside the network interface firmware.
  • ARQ client 14 has access to both input and output queues 11, 12.
  • ARQ client temporarily stores the headers and sniffs all outgoing packets produced at the transport layer to detect standalone TCP ACK packets.
  • ARQ Client 14 computes the index and passes it to HARQ module 18, while the original TCP ACK packet continues its outgoing path down the protocol stack. As before, whichever comes first to the physical layer for transmission, the TCP ACK packet or the corresponding index, will be transmitted while the other one is cancelled.
  • the described technique enables the design of hash value based ACK generation not synchronized with a particular HARQ ACK message. Indeed, as it will be readily appreciated by the skilled in the art, due to the processing involved during the travel of a packet along the protocol stack, the TCP ACK arrival at the physical layer will generally occur later than the HARQ ACK generation. In case a hash value transmission was not requested with the HARQ ACK generated for a TCP packet freshly received, it can be requested with a next outgoing HARQ ACK. However, in case MAC layer did not succeed to pass the index and TCP ACK is arrived down to the physical layer, it is transmitted like in a conventional system where the ARQ proxy and client are not provided.
  • the invention can be applied during the data transfer phase and TCP ACKs corresponding to the connection establishment or termination phases must be transmitted as such. Moreover, even during the data transfer phase, the invention can be applied provided the TCP ACK does not contain information that would become lost in the conversion into the TCP ACK index, as it could be for instance the case where a window ("rwnd" field in TCP header) different from the last advertised one is signalled.
  • Duplicate TCP ACKs advertising the loss of a packet could however be substituted according to the invention, provided the corresponding entries in the hash table are kept present until reception of the TCP ACK with the next sequence number or, more simply, until the timeout expiration.
  • Figs. 6 and 7 depict in more detail the above-described operations of ARQ proxy 24 and ARQ client 14, respectively, assuming that transmission of the resource reservation bit is necessary.
  • the starting step 600 of the process is the arrival of new data at eNB 21.
  • the operations proceed differently depending on whether a data item comes from evolved packet core 30 or from user equipment 10.
  • TCP ACK is generated (step 602)
  • the TCP ACK index is computed by applying the chosen hash function to the IP and TCP headers (step 603)
  • the TCP ACK and the index are stored into hash table 27 (step 604) and then the data packet is forwarded to the concerned user equipment 10 (step 605).
  • the process ends (step 606).
  • step 601 If the check of step 601 reveals that the data item is not a TCP data packet, the data item is immediately forwarded to user equipment 10 and the process ends.
  • HARQ predefined reservation request HARQ predefined reservation request
  • the reservation request is passed to the scheduler (step 608) and the process ends.
  • a further check is made on whether the data item is a standalone TCP ACK index (step 609).
  • the process stops.
  • ARQ proxy 14 retrieves the associated TCP ACK from hash table 27 (step 610) and forwards it to evolved packet core 30 (step 611). The process ends.
  • ARQ Client 14 Fig. 7A
  • HARQ module 18 Fig. 7B
  • ARQ Client 14 As shown in Fig. 7A , the operations at ARQ Client 14 are started by a notification about a TCP ACK generation (step 700). In order to proceed, ARQ client 14 needs the following input parameters (step 701):
  • ARQ Client 14 After having received the input parameters, ARQ Client 14 generates (step 702) the TCP ACK index by applying the hash function to the TCP and IP headers of the received data packet or the TCP ACK packet, in a manner similar to what performed by ARQ Proxy 24 at step 603 ( Fig. 6 ). Then, ARQ Client 14 sends to HARQ module 18 a request including the TCP ACK index and the memory pointer (step 703), whereafter the process ends.
  • the operations are started by the reception of the request from ARQ Client 14 together with its enclosures (step 710). Then, the predefined reservation bit is set in the next outgoing HARQ feedback message (step 711) and, when the resource grant is received (output yes of step 712), it is checked that the TCP ACK pointer is not null (step 714). This check assumes that the TCP ACK pointer is reset to NULL if the TCP ACK packet has arrived at the physical layer, and then has been transmitted, before HARQ entity has been granted the resources for the index transmission or, generally, before the index is ready for transmission. If the TCP ACK pointer is null, the process immediately ends (step 716), otherwise the index is sent to eNB (step 714) and the TCP ACK is removed (step 715).
  • Fig. 8 The operations of ARQ proxy 24 and ARQ client 14 are summarised in Fig. 8 , where the interactions among the different protocol layers are depicted. Fig. 8 is self-explanatory in light of the preceding description. For sake of simplicity, the transmission of the reservation bit has not been explicitly indicated.
  • a variant embodiment could take into account that the TCP packet header already contains a hash value for the TCP and IP headers in the checksum field. Thus it is possible to use this checksum as the TCP ACK index, so that explicit application of a hash function is no longer necessary.
  • the index is generated by directly reading the checksum field from the data packet header and storing it into table 27 together with the TCP ACK generated.
  • the checksum of the received data packet is extracted and forwarded to HARQ module like the generic hash value in the embodiment described above.
  • Another variant embodiment could exploit the fact that, besides the checksum field, other header fields in a packet have a content univocally identifying a packet and therefore can be used as the index representative of the TCP ACK: an example is the sequence number field in the TCP header.
  • the considerations made above for the use of the checksum field apply also in this case, even if the index is no longer a hash value.
  • the TCP ACK index is a data packet field and thus it is transmitted by eNB 21 to UE 10.
  • This principle can be generalised and applied also when the TCP ACK index is not a part of the data packet but is explicitly calculated.
  • the TCP ACK index needs to be generated only by ARQ Proxy 24 (e.g. by means of a hash function, like in the first embodiment) and will be forwarded to UE 10 along with the data packet.
  • ARQ Proxy 24 e.g. by means of a hash function, like in the first embodiment
  • the index will be extracted from the received packet flow and passed to ARQ Client 14 for transmission to eNB when the TCP ACK packet relevant to the received data packet is detected.
  • the TCP ACK index needs not to be inserted into or associated with a lower layer acknowledgment of data unit reception at the user equipment 10, but it can be inserted into or associated with any feedback message at the PHY or LL layers sent by UE 10 to eNB 21, e.g. in the feedback messages containing Channel Quality Indicators (CQI) and so on.
  • CQI Channel Quality Indicators
  • the MAC layer includes a service specific Convergence Sublayer (CS) performing the following functions:
  • the Packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), Point-to-Point Protocol (PPP), and IEEE Standard 802.3 (Ethernet).
  • IP Internet Protocol
  • PPP Point-to-Point Protocol
  • Ethernet IEEE Standard 802.3
  • ARQ proxy/client entities should be implemented on top the Packet CS, since all input information for both ARQ proxy/client elements are already available therein.
  • the ARQ client implementation corresponds to the standalone configuration proposed for 3G LTE systems (see Fig. 5B ).
  • each tile is composed by 8 subcarriers modulated with QPSK symbols, so that 16 bits per tile can be transmitted, the three unused tiles make a total amount of 48 bits available for transmitting, for example, a 16 bit long index with some protection
  • any PHY/LL feedback can be used, as said above.
  • IEEE 802.11 standard implements a stop-and-wait ARQ at the link layer (LL), and every frame successfully transmitted should be acknowledged by a LL ACK, which is a standalone frame of 14 bytes.
  • One field of that frame (the Duration field) contains 14 unused bits that could be used for uplink transmission of the index. In this case, the reservation bit is not necessary.
  • the index can be generated by means of a hash function, as for 3G LTE systems.
  • An alternative method is to use the 12-bit link layer sequence control number included in the MAC frames. In such case, if the mobile node (corresponding to a UE in 3G LTE) is to send a TCP ACK, it simply extracts the 12-bit sequence control number of the data frame with which the original TCP data packet was received and inserts it into the duration field of the ACK frame.
  • This alternative method may be preferable in that it is well fitted also when fragmentation is used, since all fragments of a frame carry the same sequence number.
  • the mobile station when the mobile station is able to decide to request TCP ACK generation at the base station, i.e. to transmit the TCP ACK index, within 10 microseconds, which correspond to the Short InterFrame Space (SIFS).
  • SIFS Short InterFrame Space
  • the "index" can be a single bit included into the LL ACK acknowledging the TCP data packet to request the TCP ACK release from the base station.
  • the base station upon receiving that bit, releases the TCP ACK generated for the TCP data packet carried in the frame that is being acknowledged by this link layer ACK.
  • the single bit feedback technique could of course be used also in case of synchronous HARQ in 3G LTE systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
EP07425087A 2007-02-19 2007-02-19 Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil Withdrawn EP1959693A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP07425087A EP1959693A1 (fr) 2007-02-19 2007-02-19 Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil
AT08708997T ATE521203T1 (de) 2007-02-19 2008-02-14 Schichtübergreifende fehlerbehebungsoptimierung in drahtlosen systemen
PCT/EP2008/051804 WO2008101861A1 (fr) 2007-02-19 2008-02-14 Optimisation d'extraction d'erreurs inter-couche dans des systèmes sans fil
EP08708997A EP2130387B1 (fr) 2007-02-19 2008-02-14 Optimisation d'extraction d'erreurs inter-couche dans des systèmes sans fil

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP07425087A EP1959693A1 (fr) 2007-02-19 2007-02-19 Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil

Publications (1)

Publication Number Publication Date
EP1959693A1 true EP1959693A1 (fr) 2008-08-20

Family

ID=38171193

Family Applications (2)

Application Number Title Priority Date Filing Date
EP07425087A Withdrawn EP1959693A1 (fr) 2007-02-19 2007-02-19 Optimisation de la rectification d'erreurs à travers des couches dans des systèmes sans fil
EP08708997A Not-in-force EP2130387B1 (fr) 2007-02-19 2008-02-14 Optimisation d'extraction d'erreurs inter-couche dans des systèmes sans fil

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP08708997A Not-in-force EP2130387B1 (fr) 2007-02-19 2008-02-14 Optimisation d'extraction d'erreurs inter-couche dans des systèmes sans fil

Country Status (3)

Country Link
EP (2) EP1959693A1 (fr)
AT (1) ATE521203T1 (fr)
WO (1) WO2008101861A1 (fr)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009101004A1 (fr) * 2008-02-12 2009-08-20 Ipwireless Inc Procédé et agencement pour un contrôle de flux tcp
EP2341685A1 (fr) * 2009-12-30 2011-07-06 Motorola Mobility, Inc. Procédé et appareil de programmation d'accusé de réception dans un système de communication sans fil
US8364482B2 (en) 2008-06-05 2013-01-29 Qualcomm Incorporated System and method for obtaining a message type identifier through an in-band modem
US8503517B2 (en) 2008-06-05 2013-08-06 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8725502B2 (en) 2008-06-05 2014-05-13 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8743864B2 (en) 2009-06-16 2014-06-03 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8855100B2 (en) 2009-06-16 2014-10-07 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
WO2014182344A1 (fr) * 2013-05-07 2014-11-13 Intel IP Corporation Procédés et agencements de signalisation d'une politique d'accusé de réception dans une trame courte
US8958441B2 (en) 2008-06-05 2015-02-17 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8964788B2 (en) 2008-06-05 2015-02-24 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US9083521B2 (en) 2008-06-05 2015-07-14 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
JP2016526831A (ja) * 2013-06-21 2016-09-05 コンヴィーダ ワイヤレス， エルエルシー データ伝送のためのクロス層およびクロスアプリケーション肯定応答
EP3151608A4 (fr) * 2014-06-25 2017-06-28 Huawei Technologies Co., Ltd. Procédé et dispositif de transmission de données
WO2017200435A1 (fr) * 2016-05-17 2017-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Station de base radio à connaissance d'ack tcp
CN108463986A (zh) * 2016-01-12 2018-08-28 富士通株式会社 无线通信装置、无线通信系统和无线通信方法
CN111190768A (zh) * 2019-12-25 2020-05-22 中科驭数（北京）科技有限公司 数据库执行错误恢复方法、数据库访问方法及装置
US10693619B2 (en) 2016-01-12 2020-06-23 Fujitsu Limited Device, system and method for data communications in a wireless network
US20210329488A1 (en) * 2020-04-20 2021-10-21 Qualcomm Incorporated Physical Uplink Control Channel With Buffer Status Report
CN116132166A (zh) * 2023-02-03 2023-05-16 网易（杭州）网络有限公司 基于区块链的通信方法、装置、设备及存储介质
US11758513B2 (en) * 2020-04-20 2023-09-12 Qualcomm Incorporated Physical uplink control channel with uplink message short data field

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2502332B (en) * 2012-05-24 2014-11-12 Broadcom Corp Methods, apparatus and computer programs for contention based transmissions
US9660768B2 (en) 2015-01-26 2017-05-23 Link Labs, Inc. Dense acknowledgement broadcast/multicast

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5627829A (en) * 1993-10-07 1997-05-06 Gleeson; Bryan J. Method for reducing unnecessary traffic over a computer network
WO2001078426A1 (fr) * 2000-04-07 2001-10-18 Proxim, Inc. Amelioration du trafic asymetrique de donnees dans des reseaux amdp/ec

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5627829A (en) * 1993-10-07 1997-05-06 Gleeson; Bryan J. Method for reducing unnecessary traffic over a computer network
WO2001078426A1 (fr) * 2000-04-07 2001-10-18 Proxim, Inc. Amelioration du trafic asymetrique de donnees dans des reseaux amdp/ec

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KLIAZOVICH D ET AL: "A cross-layer scheme for TCP performance improvement in wireless LANs", GLOBAL TELECOMMUNICATIONS CONFERENCE, 2004. GLOBECOM '04. IEEE DALLAS, TX, USA 29 NOV.-3 DEC., 2004, PISCATAWAY, NJ, USA,IEEE, 29 November 2004 (2004-11-29), pages 840 - 844, XP010757643, ISBN: 0-7803-8794-5 *
QIXIANG PANG ET AL: "Performance Improvement of 802.11 Wireless Access Network with TCP ACK Agent and Auto-Zoom Backoff Algorithm", VEHICULAR TECHNOLOGY CONFERENCE, 2005. VTC 2005-SPRING. 2005 IEEE 61ST STOCKHOLM, SWEDEN 30 APRIL - 01 MAY 2005, PISCATAWAY, NJ, USA,IEEE, 30 May 2005 (2005-05-30), pages 2046 - 2050, XP010855786, ISBN: 0-7803-8887-9 *

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8320250B2 (en) 2008-02-12 2012-11-27 Nvidia Corporation Method and arrangement for TCP flow control
WO2009101004A1 (fr) * 2008-02-12 2009-08-20 Ipwireless Inc Procédé et agencement pour un contrôle de flux tcp
US8825480B2 (en) 2008-06-05 2014-09-02 Qualcomm Incorporated Apparatus and method of obtaining non-speech data embedded in vocoder packet
US8964788B2 (en) 2008-06-05 2015-02-24 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8364482B2 (en) 2008-06-05 2013-01-29 Qualcomm Incorporated System and method for obtaining a message type identifier through an in-band modem
US8503517B2 (en) 2008-06-05 2013-08-06 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8725502B2 (en) 2008-06-05 2014-05-13 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US9083521B2 (en) 2008-06-05 2015-07-14 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8958441B2 (en) 2008-06-05 2015-02-17 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8855100B2 (en) 2009-06-16 2014-10-07 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8743864B2 (en) 2009-06-16 2014-06-03 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8279822B2 (en) 2009-12-30 2012-10-02 Motorola Mobility Llc Method and apparatus for scheduling an acknowledgement in a wireless communication system
EP2341685A1 (fr) * 2009-12-30 2011-07-06 Motorola Mobility, Inc. Procédé et appareil de programmation d'accusé de réception dans un système de communication sans fil
WO2014182344A1 (fr) * 2013-05-07 2014-11-13 Intel IP Corporation Procédés et agencements de signalisation d'une politique d'accusé de réception dans une trame courte
RU2599960C2 (ru) * 2013-05-07 2016-10-20 ИНТЕЛ АйПи КОРПОРЕЙШН Способы и устройства для передачи политики подтверждения в коротком кадре
US9979511B2 (en) 2013-06-21 2018-05-22 Convida Wireless, LLP Cross-layer and cross-application acknowledgment for data transmission
JP2016526831A (ja) * 2013-06-21 2016-09-05 コンヴィーダ ワイヤレス， エルエルシー データ伝送のためのクロス層およびクロスアプリケーション肯定応答
US10425194B2 (en) 2013-06-21 2019-09-24 Convida Wireless, Llc Cross-layer and cross-application acknowledgment for data transmission
EP3151608A4 (fr) * 2014-06-25 2017-06-28 Huawei Technologies Co., Ltd. Procédé et dispositif de transmission de données
US10104578B2 (en) 2014-06-25 2018-10-16 Huawei Technologies Co., Ltd. Data transmission method and device
JP2017526223A (ja) * 2014-06-25 2017-09-07 ホアウェイ・テクノロジーズ・カンパニー・リミテッド データ送信方法及びデバイス
US10693619B2 (en) 2016-01-12 2020-06-23 Fujitsu Limited Device, system and method for data communications in a wireless network
US10863485B2 (en) 2016-01-12 2020-12-08 Fujitsu Limited Radio communication device, radio communication system, and radio communication method
US20180324790A1 (en) * 2016-01-12 2018-11-08 Fujitsu Limited Radio communication device, radio communication system, and radio communication method
EP3404897A4 (fr) * 2016-01-12 2018-12-26 Fujitsu Limited Dispositif de communication sans fil, système de communication sans fil et procédé de communication sans fil
CN108463986A (zh) * 2016-01-12 2018-08-28 富士通株式会社 无线通信装置、无线通信系统和无线通信方法
CN108463986B (zh) * 2016-01-12 2021-03-09 富士通株式会社 无线通信装置、无线通信系统和无线通信方法
JPWO2017122268A1 (ja) * 2016-01-12 2018-11-01 富士通株式会社 無線通信装置、無線通信システム、及び無線通信方法
WO2017200435A1 (fr) * 2016-05-17 2017-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Station de base radio à connaissance d'ack tcp
CN111190768B (zh) * 2019-12-25 2020-10-16 中科驭数（北京）科技有限公司 数据库执行错误恢复方法、数据库访问方法及装置
CN111190768A (zh) * 2019-12-25 2020-05-22 中科驭数（北京）科技有限公司 数据库执行错误恢复方法、数据库访问方法及装置
US20210329488A1 (en) * 2020-04-20 2021-10-21 Qualcomm Incorporated Physical Uplink Control Channel With Buffer Status Report
US11523301B2 (en) * 2020-04-20 2022-12-06 Qualcomm Incorporated Physical uplink control channel with buffer status report
US11758513B2 (en) * 2020-04-20 2023-09-12 Qualcomm Incorporated Physical uplink control channel with uplink message short data field
CN116132166A (zh) * 2023-02-03 2023-05-16 网易（杭州）网络有限公司 基于区块链的通信方法、装置、设备及存储介质

Also Published As

Publication number Publication date
WO2008101861A1 (fr) 2008-08-28
EP2130387B1 (fr) 2011-08-17
ATE521203T1 (de) 2011-09-15
EP2130387A1 (fr) 2009-12-09

Similar Documents

Publication Publication Date Title
EP2130387B1 (fr) Optimisation d'extraction d'erreurs inter-couche dans des systèmes sans fil
US11825295B2 (en) Method for scheduling in mobile communication and apparatus thereof
AU2005253495B2 (en) Transmitting and receiving control protocol data unit having processing time information
RU2461147C2 (ru) Способ обработки радиопротокола в системе подвижной связи и передатчик подвижной связи
AU2006229508B2 (en) Method of generating lower layer data block in wireless mobile communication system
US9565699B2 (en) Method of performing polling procedure in a wireless communication system
GB2574876A (en) Transmission techniques in a cellular network
EP2469750A1 (fr) Procédé et dispositif de commande de transmission de données de liaison descendante dans un système de communication à relais à plusieurs bonds
KR101635433B1 (ko) 재전송 요청을 위한 제어 메시지를 처리하는 방법 및 장치
WO2009022877A2 (fr) Procédé permettant la transmission et le traitement d'un bloc de données d'une couche de protocole spécifique dans un système de communication sans fil
JPWO2008123160A1 (ja) 再送要求送信方法及び受信側装置
JP5124591B2 (ja) Ｒａｎにおける連続するデータユニットの表示の方法
KR101084136B1 (ko) 무선 통신 시스템의 송수신 단에서 상태정보를 포함하는ｐｄｕ를 송수신하는 방법
US8839064B2 (en) Communication system and method for transmitting or receiving packets therein
US20240014939A1 (en) Radio Link Control Cumulative Mode for New Radio
WO2023028950A1 (fr) Mode cumulatif de commande de liaison radio pour une nouvelle radio
KR20080106385A (ko) 패킷 데이터 분할 재전송 방법

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

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

AKX Designation fees paid
REG Reference to a national code

Ref country code: DE

Ref legal event code: 8566

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090221