EP1794921B1 - Decoding method - Google Patents
Decoding method Download PDFInfo
- Publication number
- EP1794921B1 EP1794921B1 EP05796975A EP05796975A EP1794921B1 EP 1794921 B1 EP1794921 B1 EP 1794921B1 EP 05796975 A EP05796975 A EP 05796975A EP 05796975 A EP05796975 A EP 05796975A EP 1794921 B1 EP1794921 B1 EP 1794921B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- rsn
- information
- packet
- redundancy version
- receiver
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 238000012790 confirmation Methods 0.000 claims abstract description 9
- 230000005540 biological transmission Effects 0.000 claims description 79
- 230000008569 process Effects 0.000 claims description 7
- 230000011664 signaling Effects 0.000 description 34
- 230000009897 systematic effect Effects 0.000 description 22
- 230000001360 synchronised effect Effects 0.000 description 6
- 230000009286 beneficial effect Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 5
- 208000037918 transfusion-transmitted disease Diseases 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 230000000875 corresponding effect Effects 0.000 description 2
- 238000011010 flushing procedure Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 101150069124 RAN1 gene Proteins 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005562 fading Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0045—Arrangements at the receiver end
-
- 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/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0041—Arrangements at the transmitter end
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0067—Rate matching
- H04L1/0068—Rate matching by puncturing
-
- 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
-
- 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/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
- H04L1/1816—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of the same, encoded, message
-
- 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/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
- H04L1/1819—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
-
- 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/1835—Buffer management
- H04L1/1845—Combining techniques, e.g. code combining
-
- 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/1867—Arrangements specially adapted for the transmitter end
- H04L1/1896—ARQ related signaling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
- H04L5/0055—Physical resource allocation for ACK/NACK
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0064—Concatenated codes
- H04L1/0066—Parallel concatenated codes
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0072—Error control for data other than payload data, e.g. control data
Definitions
- a soft handover takes place, e.g. if a terminal, which has established a data connection with a first base station approaches a second base station.
- a transition phase there is a connection to both base stations, in order to ensure a smooth or soft transition when going from one cell, governed by the first base station to the second cell, governed by the second base station.
- This selection has the advantage that the selection of the redundancy version can be done taking into account the transmission properties, e.g. whether the receiver has previous versions of the data packets which it can use for decoding. Thus better decoding results can be achieved. At the same time no or only little additional effort is performed for additional signaling.
- the present invention gives also an enhancement of the "Retransmission Sequence Number” (RSN) concept, which allows reducing the value range of RSN while still allowing it to be used to determine which packets to combine, at least for most cases, in particular in those cases where the number of retransmissions does not exceed the maximum value of the RSN.
- RSN Retransmission Sequence Number
- the first and/or the second retransmission numbers according to this application can be designed to be a "Retransmission Sequence Number" according to the previous description.
- the terminal UE sends data packets to the base station BS.
- the base station acknowledges the correct or incorrect receipt with a ACK or a NACK, which is sent back to the terminal UE.
- RSN retransmission numbers according to this invention.
- RSNMAX can be a maximum retransmission number.
- the RSN is increased and reaches RSNMAX.
- the receiver detects this, the time difference since the last received RSN is 2, and the last received RSN (1) plus this time difference gives 3, which is at least RSNMAX. Therefore the packet is combined with the last packet at time 2 according to case 2.
- the RSN stays at RSNMAX.
- RSN is RSNMAX
- a new packet could have been sent at time 8
- the RSN would have been reset and could have increased to 3 since then as shown in the line Hyp. Therefore the receiver does not know for sure whether the packet received at time 11 can be combined with the packet at time 7 or not, therefore it has to make a conservative assumption i.e. not combine the data. This is indicated by the letter f at time 11 in line 3.
- the relation of RV to RSN can be signaled from the receiver to the transmitter before of the transmission, in particular for RSN ⁇ RSNMAX.
- e ini describes the initial error between the current or actual and the desired puncturing ratio, e plus a stepwidth for changing the error and , e minus another step width, used in the rate matching algorithm .
- the section Chapter 4.5.4.3 "HARQ Second Rate Matching Stage" describes how to calculate these parameters from the input parameters N sys , N data and r max , wherein N sys denotes the number of systematic bits, that is bits carrying information in contrast to parity bits used for encoding, N data denotes the total number of bits, i.e. parity bits and systematic bits and r max denotes the maximum value of r plus one.
- N sys denotes the number of systematic bits, that is bits carrying information in contrast to parity bits used for encoding
- N data denotes the total number of bits, i.e. parity bits and systematic bits
- r max denotes the maximum value of r plus one.
- Such a redundancy version is typically self decodable, that means, that it can be decoded by itself, unless of course the reception is too noisy.
- Path loss is the degradation of a signal transmitted over a certain connection between e.g. a terminal and a base station. The signal takes a certain way, the path. Due to reflection, interferences etc it is subject to a degradation.
- the path loss to the second base station becomes better, it is advantageous, if all the redundancy versions are self-decodable., as The second base station might otherwise not be able to immediately decode the packets after such a switch, as it might not have received the initial transmission of a data packet, which is self decodable, but only later transmissions, which are by itself not self decodable:
- Puncturing is done in order to reduce the overall number of bits, e.g. to adapt the overall number to a fixed capacity of a transmission.
- the puncturing of bits is done such, that no or only as little as possible information is lost. Therefore often mainly parity bits are punctured.
- the selection of redundancy versions is based not only on the RSN but also on the fact whether puncturing or repetition is used for rate matching.
- the coding rate is the number of bits before the coding divided by the number of bits after coding and after rate matching.
- Rate matching is the puncturing or repeating of bits in order to achieve a desired final number of data in a certain time interval or correspondingly a desired data rate.
- turbo codes are used for coding of the payload data.
- Payload data are the data actually carrying information, in contrast for data used for signaling etc.
- the code rate of a turbo code without rate matching is not exactly1/3 but slightly lower, because additionally so called “termination bits" are appended at the end of the encoded data.
- this difference is small enough to be irrelevant. Therefore, in the detailed embodiments it is possible to either compute the coding rate taking the termination bits into account or not. The result will generally be equal.
- RVs based on the RSN and the code-rate is realized: Table 2: Relation between RSN value and E-DCH RV Index coding rate 1/3 ⁇ rate ⁇ 1/2 1/2 ⁇ rate ⁇ 5/6 rate ⁇ 5/6 or rate ⁇ 1/3 RSN value E-DCH RV Index E-DCH RV Index E-DCH RV Index 0 0 0 0 1 2 3 1 2 0 2 3 3 ⁇ TTIN/N ARQ ⁇ mod 2 *2 ⁇ TTIN/N ARQ ⁇ mod 3 ⁇ TTIN/N ARQ ⁇ mod 4
- the redundancy version Index for the E-DCH is shown for various coding rates and different retransmission sequence numbers RSN.
- TTI time transmission interval
- NARQ is the number of Hybrid ARQ processes that is how many transmissions of individual data packets are performed in parallel. E.g. there is the transmission and retransmission of a data packet A. At the same time transmission and retransmission of data packet B or further data packets has already begun.
- the usage of the TTIN instead of the CFN is necessary, if a CFN contains more than one TTI in order to distinguish the TTIs within one CFN. This depends on the set up of the individual data connection and the system within which the data connection is established. Therefore, the conditions can be generalized for other numbers of TTIs contained in a frame.
- the code rate is one, only the systematic bits are transmitted in the initial transmission, the first and second retransmissions contain each 50% of the parity bits. So one non-self-decodable RV is ideal for Rate 2/3 and two non-self-decodable RV are ideal for rate 1. As 5/6 is the arithmetic mean of 2/3 and 1, we propose to use this value for the transition between one and two non-self-decodable transmissions. Obviously other thresholds are possible as well, down to 2/3 as 2/3 is the maximum rate where all parity bits can be transmitted with on self-decodable and one non-self-decodable transmission.
- the threshold of rate 1/2 can also be set somewhat higher, e.g. at the arithmetic mean between 1/2 and 2/3 which is 7/12 or any value between 1/2 and 7/12.
- the UE User Equipment, a synonym for mobile station
- the transition point i.e. the minimum coding rate at which also non-self-decodable transmission are used, can be selected to correspond to the maximum data rate which is admissible in SHO.
- the E-DCCH carries overhead information related to the payload-data, e.g. the used transport format i.e. the number of payload bits, and is necessary to decode the payload-data. So if the base station could not decode the E-DCCH it will not be able to make any use of the data transmitted on E-DCDCH. The base station can determine that the E-DCCH was not detected correctly e.g.
- this signaling is called CNAK (Control- NACK).
- CNAK Control- NACK
- this document does not disclose any information how the re-selection of the first RV shall be realized in conjunction with the RSN scheme.
- Node B reception scenarios is relevant, in particular the citation below, which starts at the third paragraph of this section:
- the table below shows 3 different scenarios, which can occur when UE sends the initial transmission of a data packet.
- the second column in the table describes the reception status at Node B for each scenario, the third column shows the preferred UE behavior in such situation.
- Scenario 2 describes the case when Node B decodes the E-DPCCH correctly, but the CRC on the E-DPDCH fails.
- Node B can use the received energy on the E-DPDCH when combining it with further retransmissions. Therefore UE shall retransmit according to the specified RV sequence in this case.
- the UE behaviour is different depending on whether the 1st or 2nd scenario has occurred.
- the first base station will not be aware of the fact, that the second base station has acknowledged the first packet and therefore is not aware that a new packet is transmitted. However, as it will anyhow flush the buffer from the first packet it does not matter whether now the first or the next packet is transmitted.
- the base station can still correctly receive the next packet.
- the first packet is lost in this case, but not due to the enhancement of the RSN-protocol but simply due to the false reception of the ACK.
- This error case is already possible without the RSN-protocol enhancement, when a NAK is miss-interpreted as an ACK, i.e. the enhanced RSN protocol does not cause any further degradation.
- This invention has presented enhancements to the RSN. It should be noted that there are also other possibilities to provide similar functionality by other means or somewhat different signaling.
- One such proposal is the NDI (New Data Indicator).
- the NDI is incremented modulo a maximum value for every new packet but is identical for retransmission of a packet.
- the NDI scheme may be more robust in cases where there are many retransmissions, because then the NDI is only incremented seldom and there is less risk that it becomes no more unambiguous (e.g. due to wrap around).
- either the RSN or NDI scheme can be used depending on properties of the connection. That means that even in a single connection sometimes RSN and sometimes NDI can be used depending on the property. Such properties may include the fact whether the connection is or is not in Soft Handover, or the used packet size or coding rate.
- the selected property can be determined by the transmitter and receiver without additional explicit signaling. In this case no extra signaling overhead is introduced.
- the HARQ related signaling information is transmitted with every E-DCH packet transmission together with the E-TFC information. Its function is to inform the Node B about the used redundancy version (X rv value) needed for the de-rate matching as well as to trigger the flushing of the Node B soft buffer.
- the redundancy versions and the ordering in which the redundancy versions are applied should be controlled by the network e.g. through higher layer signaling or it can be specified for every TFC using a fixed mapping rule.
- the rule is known to both the UE and the network and can implemented "hard-wired".
- three redundancy versions (one for the initial transmission, one for the first and one for the second retransmission) should be specified or signaled from higher layers.
- the applied redundancy version is signaled from the UE to the Node B.
- the RSN is incremented with every retransmission and set to 0 with every initial transmission. In case the number of retransmissions exceeds two the RSN is set to 3 for all further retransmissions.
- This has the advantage that the number of bits for the RSN can be lower than log 2 (N max ) without losing IR gain since the number of different RVs is typically lower than the maximum number of transmissions N max .
- the RV selection is CFN based to achieve further gain.
- the 2 bit RSN as described for the no SHO case is no longer needed and can be reused.
- the most important issue for the HARQ related signaling in SHO is to avoid Node B buffer corruption
- the NDI is incremented at the UE with every initial transmission. Compared to the RSN the NDI provides a higher reliability especially in case the residual BLER after the first retransmission is targeted to 1%).
- the proposal comprises also the RV selection in SHO, which is done implicitly using the CFN e.g. as described in [2,3].
- the RVs for the initial transmission and the first and second retransmission is signaled by the network whereas the actual usage is indicated by the UEs RSN.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
Abstract
Description
- The invention concerns a method for transmission of an information content and a telecommunication device for performing that method.
- Often for a better decoding result several transmissions of the same data packet are combined. Combining data packets is already known for communication systems where packet transmission is employed. One example of such a transmission system is the so called E-DCH scheme (E-DCH: Enhanced Dedicated Channel, basically an improvement of the existing UMTS uplink channel) which is right now being standardized as an enhancement of the UMTS system (UMTS: Universal Mobile Telecommunication System).
- The outlines of the E-DCH scheme can be found in the 3GPP RAN 1 technical report TR 25.896 v2.0.0 "Feasibility Study for Enhanced Uplink for UTRA FDD (Release 6)", R1-040392, February 2004, Malaga, Spain.
- This scheme is designed to make use of a HARQ (HARQ: Hybrid ARQ, Hybrid Automatic Repeat reQuest) scheme. In this scheme packets are transmitted, and if they are not received correctly, a retransmission is transmitted upon receipt of a negative confirmation of the receiver, a so called "not acknowledge" (NACK) If the receipt has been correct a positive confirmation is sent, the so called "Acknowledge" (ACK). In the case of more than one transmission of the same data packet, at the receiver both the initial transmission and the retransmission is used for decoding the packet. Therein "soft bit decisions" making use of the information of both data packets is used. This means, that to every bit of the data packet of transmission or retransmission a quantity is assigned which is correlated with the probability, whether the bit is 1 or 0. The decoding is then done considering both quantities.
- This gives a better performance, as if only the retransmission would be used without regarding previous transmissions (hybrid ARQ with selection combining).
- In order to a proper function of this scheme as explained above, it should be ensured, that both received transmissions actually relate to the same transmitted (higher layer) packet i.e. both transmissions are derived from the same information content, the same "higher layer" packet (but may be transmitted using different packets on layer 1). Layer refers here to the OSI (Open System Interconnection) model. Due to transmission properties, which are considered in layer 1, the representation of information for a certain application, the application itself being taken care of in a higher layer) may be different for transmission and retransmission.
- There are several ways to ensure this: one is a so called synchronous retransmission protocol. In this protocol a retransmission is sent at a fixed time interval after the initial transmission or also the previous retransmission, if more than one retransmission is foreseen. In this way the receiver knows at which times it can expect retransmissions of a given packet.
- However, the receiver still does not know, whether two transmissions at compatible times actually relate to the same packet, or whether already the transmission of a new packet has been started. This is in particular the case if the receiver is not able to receive all packets but misses some, e.g. due to interference. If the transmission employs soft handover (SHO), that means that more than one receiver tries to receive the packets, it may well be that one receiver has not been able to receive a packet, but another receiver has been able to do so and acknowledged the packet. In this case a new packet can be transmitted next. The receiver which did not receive the first packet has no knowledge on the acknowledgement send by the other receiver and therefore must now somehow recognize that this new packet cannot be combined with any previously received packets.
- In respect of the E-DCH a soft handover takes place, e.g. if a terminal, which has established a data connection with a first base station approaches a second base station. In a transition phase there is a connection to both base stations, in order to ensure a smooth or soft transition when going from one cell, governed by the first base station to the second cell, governed by the second base station.
- For an easy recognition, it is further possible to introduce a so called Retransmission Sequence Number (RSN) or retransmission counter:
This counter is reset (e.g. to 0) if a new data packet is transmitted, and it is incremented with each retransmission. If the receiver compares the difference in RSN with the difference in time (taking into consideration the synchronous retransmission protocol and the known time difference between retransmission), the receiver can combine the receptions if the differences in time an RSN match and not combine them if the differences do not match. - It is a problem according to the state of the art, that the value range of the RSN is at least as large as the maximum number of possible retransmissions: Typically if a packet cannot be transmitted with a maximum number of retransmission this packet is dropped and the next packet is transmitted. The maximum number of possible retransmissions can be quite high. This can cause an excessive amount of signaling information, as the RSN has to be transmitted with every packet transmission and retransmission.
- Document "On the coding gain of incremental redundancy over chase combining ", by Jung-Fu Cheng, GLOBECDM 2003, discusses the relative merits of the Chase Combining and Incremental Redundancy schemes in the context of HARQ protocols.
- Based on this state of the art, it is therefore an object of the invention to provide a possibility of improving a transmission of data packets, wherein a retransmission of data packets is foreseen.
- It is a further task of the presented invention to present an improved retransmission method.
- This object is achieved by what is disclosed in the independent claims. Advantageous embodiments are subject of the dependent claims.
- According to the invention a data packet is transmitted from a sender to a receiver. In the data packet information is contained, which is represented by bit sequence. For transmission this bit sequence is transformed into a redundancy version, that is one out of more possible representations suited for transmission. In case the receiver does not receive the data packet correctly, it sends a confirmation, e.g. a NACK, to the sender. Upon this receipt the sender retransmits the information in a second data packet, which might be different from the first one. For this retransmission a second redundancy version is used, which might be different from the first one. The selection of the redundancy version for the second transmission is based on a coding parameter, which denotes whether the redundancy version is self-decodable, that means decodable only by itself or not.
- This selection has the advantage that the selection of the redundancy version can be done taking into account the transmission properties, e.g. whether the receiver has previous versions of the data packets which it can use for decoding. Thus better decoding results can be achieved. At the same time no or only little additional effort is performed for additional signaling.
- Further aspects and criteria of the selection of the redundancy version are detailed in the description of embodiments and Figures.
- The present invention gives also an enhancement of the "Retransmission Sequence Number" (RSN) concept, which allows reducing the value range of RSN while still allowing it to be used to determine which packets to combine, at least for most cases, in particular in those cases where the number of retransmissions does not exceed the maximum value of the RSN. The first and/or the second retransmission numbers according to this application can be designed to be a "Retransmission Sequence Number" according to the previous description.
- There may now be some cases where the receiver can now no longer tell whether packets have to be combined, but these cases are rare enough and will not severely harm the performance. It is more valuable to reduce the number of bits needed to encode the RSN, say from 3 bits to 2 bits, which gives a significant reduction of the resources needed to transmit this "overhead" information along with the packet data.
- Further advantages and embodiments are detailed in the following using Figures, of which show:
- Fig.1: A connection between a terminal and a base station.
- In Fig. 1 a terminal U is depicted, which has a connection E-DCH to a base station BS.
- The terminal may be any communication device, e.g. as a mobile phone, a PDA (personal digital assistant), a mobile computer etc.
The base station may be any central unit in a communication system CS. The communication system can be represented e.g. by a mobile communications network such as UMTS (Universal system of mobile communication), a local area network such as WLAN (wireless local area network) or a broadcast system.
The connection E-DCH may be any data link between the terminal UE and the base station BS, wherein data packets are transmitted. Except of the Enhanced Uplink Dedicated Channel it may be the HS-DSCH (High-Speed Downlink Shared Channel), or ... or any other data link such as a broadcast connection. - The terminal UE sends data packets to the base station BS. The base station acknowledges the correct or incorrect receipt with a ACK or a NACK, which is sent back to the terminal UE.
- In case of a NACK, the terminal UE retransmits the data packet. As laid out above, the data packet is the same from the information content, but may employ a different encoding e.g. a different subset of the coded bits.
- In the following description, the retransmission numbers according to this invention are abbreviated as RSN.
- According to the invention the RSN concept used as follows: If a new packet is being transmitted (i.e. at the first transmission of a new packet), the RSN is reset to 0.
- If a retransmission of a packet is transmitted, and the RSN is still below its maximum value, then the RSN is incremented. If a retransmission of a packet is transmitted, and the RSN has already reached its maximum value, then the RSN is not incremented but remains at the maximum value in contrast to previous proposals. This has the advantage, that the space needed for signaling can be limited to a previously set value.
- We name the maximum value of RSN as RSNMAX for the further discussion (RSNMAX can be a maximum retransmission number.
- The receiver can combine a received packet with the previously received packet, if e.g. one of the following conditions 1 or 2 holds. For this purpose it will take into account also the RSN of the previously received packet (the last received packet) and the time difference since the reception of that packet (the time difference can be a delay time consisting of a number of retransmission time steps e.g. according to the claims). Note that the time difference is identical to the number of increments of the RSN since that last packet, provided that no new packed has been transmitted and that the limitation of RSN to RSNMAX has not happened yet.
- A combination of the data packets is possible, if
- 1) the RSN is smaller than RSNMAX and the difference in RSN is identical with the difference in transmission time (in this case there was neither an overflow of the RSN nor has a new initial packet been sent) or
- 2) the RSN is identical to RSNMAX, the last received packet has been received with the difference in time being at most RSNMAX and the RSN of that last packet plus the time difference is at least RSNMAX. In this case there may have been an overflow of the RSN, but the packet received corresponds to the last received packet, otherwise the RSN would have been reset to 0 after that last packet, and would not have been increased to RSNMAX because the time difference since then is too small.
- The packets may be not combined for example in the following cases 3 or 4:
- 3) the RSN is smaller than RSNMAX and the difference in RSN is not identical with the difference in transmission time (in this case there was no overflow of the RSN and a new initial packet been sent, therefore the data relating to the old packet can be safely deleted) or
- 4) the RSN is identical to RSNMAX and the last received packet has been received with the difference in time being more than RSNMAX. In this case the receiver cannot determine whether the actual and the last received packets are to be combined, i.e. cannot determine whether there have only been retransmissions of this packet been sent, or whether already a new packet and so many retransmissions of this new packet have been sent, so that the RSN has already reached RSNMAX. Therefore, in order to avoid a potential mixing up of data of different packets, the information relating to the old packet will have to be deleted.
- In the case that the RSN is identical to RSNMAX it is actually not possible that the last received packet has been received with the difference in time being less than RSNMAX and the RSN of that last packet plus the time difference is smaller than RSNMAX. Consequently, strictly speaking, the RSN of the last packet plus the time difference needs not necessarily be computed and compared to RSNMAX. However it is easy to do and in this case some rare error cases may be detected, where the RSN has been decoded incorrectly. This is unlikely as the RSN will have to be coded/protected suitably anyhow, but as the calculation is so easy, it would be advantageous to do it and to exploit this extra consistency check.
- For a further explanation of the present invention, we will present some more detailed examples by reference to the following Table 0:
T 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 RS N 0 0 1 2 3 3 3 3 3 3 3 3 0 1 2 3 3 3 3 RX 0 - 1f - 3 - - 3 - - - 3f 0 - 2 Hyp 0 1 2 0 1 2 0 1 2 3 3 0 1 - In the first line the time T (in units of transmission times i.e. time difference of retransmission in the synchronous retransmission protocol). The time T may be denoted in a fixed number of time slots or so called TTI (time transmission interval).
- In the second line the actually transmitted RSN.
- In the third line the received RSN, which is denoted as RX, if no RSN has been received (e.g. due to interference), this missing receipt is indicated by a dash (-).
Furthermore a "f" indicates that the buffer has been cleared i.e. that the receiver assumes, that the actually received packet cannot be combined with the previous one. - In the forth line, for explanatory purposes, an other potential sequence of transmitted RSN is given to show whether it is possible, that the same RSN has been received but a new packet has already been sent.
- According to the present example, at time 0 the RSN is set to 0 and a packet is transmitted.
At time 1 a new packet is transmitted and the RSN is reset to 0 again. This RSN is however not received by the receiver (-). - At time 2, a retransmission of the packet transmitted already at time 1 is transmitted. The receiver recognizes that this packet is not to be combined with the previously received packet, i.e. the packet transmitted at time 0, because the actual RSN is smaller than RSNMAX and the difference of the actual RSN minus the last received RSN (which was 0 at time 0) is 1-0=1 does not match the time difference which is 2 (time 2 minus time 0). This is according to case 3 set out above. Note that if still a retransmission of the packet from time 0 was sent, then the RSN would by now have been incremented to 2 as indicated in the line Hyp. Therefore the receiver can rule out this case, this means, it does not perform a combination.
- At time 3 a retransmission is transmitted, but not received.
- At time 4 a retransmission is transmitted, the RSN is increased and reaches RSNMAX. The receiver detects this, the time difference since the last received RSN is 2, and the last received RSN (1) plus this time difference gives 3, which is at least RSNMAX. Therefore the packet is combined with the last packet at time 2 according to case 2.
- At time 5 to 6 retransmissions are sent, the RSN stays at RSNMAX.
- At time 7 a retransmission is sent, still the RSN stays at RSNMAX. The receiver combines this packet with the previously received packet at time 4 according to rule 2: RSN is RSNMAX, the time difference is 3, i.e. at most RSNMAX and the previous RSN plus the time difference is 6 i.e. at least RSNMAX. If a new packet had been sent since time 4, the RSN would have been reset and could have increased at most to 2 since then as shown in the line Hyp.
- At time 8 to 10 retransmissions are sent, the RSN stays at RSNMAX.
- At time 11 a retransmission is sent, still the RSN stays at RSNMAX. The receiver does not combine this packet with the previously received packet at time 7 according to rule 4: RSN is RSNMAX, the time difference is 11-7=4, i.e. larger than RSNMAX. A new packet could have been sent at time 8, the RSN would have been reset and could have increased to 3 since then as shown in the line Hyp. Therefore the receiver does not know for sure whether the packet received at time 11 can be combined with the packet at time 7 or not, therefore it has to make a conservative assumption i.e. not combine the data. This is indicated by the letter f at time 11 in line 3.
- At time 12 a new packet is sent and received and RSN is reset to 0.
- At time 13 a retransmission is sent but not received and RSN is incremented to 1.
- At time 14 a further retransmission is sent and received and the RSN is incremented to 2. The receiver combines this packet with the previously received packet at time 12 according to rule 1: The RSN 2 is still smaller than RSNMAX and the difference in RSN 2-0=2 is identical with the difference in transmission time 14-12=2. The line Hyp shows that if a new packet had been sent (but missed) at time 13 than the RSN would not be 2 but 1.
- Up to now embodiments have been detailed, which are already applicable, if an identical data packet has been retransmitted.
Furthermore, it is possible, that in a HARQ system for the same content not identical packets (this is called "chase combining") but e.g. differently encoded packets are sent, known e.g. as different redundancy versions (also called "incremental redundancy").
In this case, also an indication which redundancy version is transmitted with a given packet can be used. This would additionally increase the overhead information. Therefore the signaling of the redundancy version can be performed implicitly with the RSN or implicitly with the time at which the packet is sent. Both transmitter and Receiver can calculate the applied redundancy version (RV) from either the RSN or transmission time (or equivalently to the transmission time a transmission frame number or connection frame number, also called CFN, the latter will be used in the following without intention to restrict others.) - For the improved RSN as presented in this invention, the determination of the RV can be done as follows: For the values of RSN below RSNMAX, the RV can be calculated from the RSN. However, when RSN reaches RSNMAX, it will remain at this value for all the remaining retransmissions of the packet. Therefore in this case, it is better to calculate the RV not from RSN but from the CFN. In summary, according to this aspect of the invention the RV is calculated from the RSN if RSN<RSNMAX and from CFN if RSN=RSNMAX.
- In a further embodiment of the invention, the relation of RV to RSN can be signaled from the receiver to the transmitter before of the transmission, in particular for RSN < RSNMAX.
- In a further embodiment there may be a default relationship predefined between transmitter and receiver, which can be replaced by a signaled relationship. The relationship can be signaled e.g. for some values for RSN, in particular for the most often used ones, while for others, e.g. the less often used ones, default values are used. Alternatively, if different packet sizes or coding schemes can be used by the system (this applies in particular for AMC (Adaptive Modulation and Coding) schemes), default values can be used for some sizes/schemes and explicit signaled RV values can be used for others.
- Further more there are coding methods, which distinguish between two classes of coded bits, namely systematic bits and parity bits. Basically systematic bits correspond to the information to be transmitted while parity bits provide redundancy information. In such cases it may be beneficial to emphasize systematic bits for the initial transmission, but parity bits in at least some of the retransmissions. In this case it is possible to not signal the fact to emphasize systematic bits in the initial transmission. This can save some transmission bandwidth for signaling the RV to RSN relation. Further more, it may even be sufficient to always use a predefined RV for the initial transmission and only provide explicit signaling of RV to RSN relations for (some of the) retransmissions. Further more, for the case RSN = RSNMAX, it can also be beneficial to emphasize systematic bits. This is in particular true for low encoding rates (i.e. there is a significant redundancy available in a transmitted packet). Then it is possible to also not signal explicitly to emphasize systematic bits for the case RSN = RSNMAX.
The following examples deal with a retransmission of redundancy versions. One important aspect is how the selection of the redundancy version is performed, as this often influences the effectiveness of a combined decoding of a data packet as transmitted originally taken together with a retransmission, which is in this case a redundancy version. - The exact selection of the redundancy version depending on the RSN will be detailed in the following sections. It will be apparent to those versed in the art, that these aspects can be advantageously combined with any aspect of the previously disclosed embodiments. As well, these aspects can be applied independently.
- It has been proposed, to select different redundancy versions based on a so called RV index (Redundancy Version Index). The RV index basically defines all the parameters, which are needed to define a specific redundancy version. This indexing enables an easy reference to a particular redundancy version, because only a single parameter i.e. the RV index needs to be specified. This specification is particularly transmitted or "signaled" from the terminal UE to the base station BS The general aspects such as the general signaling architecture regarding E-DCH are discussed in R1-041408 3GPP TR 25.808 V0.2.3 (2004-10) Technical Report 3rd Generation Partnership Project; FDD Enhanced Uplink; Physical Layer Aspects.
- One proposal for a relation between the RV index and derived parameters is given in R1-041354, Editor (Siemens), "CR 25.212 - Introduction of E-DCH", November 2004, Shin Yokohama, Japan in its section "4.8.4.3 HARQ Rate Matching Stage".
In particular the relation of the parameters s and r to the E-DC-RV index is relevant:
The parameters of the rate matching stage depend on the value of the RV parameters s and r. The s and r combinations corresponding to each RV allowed for the E-DCH are listed in Table 15. The first transmission attempt of a transport block shall use a RV that emphasizes the systematic bits (RV with s=1). Higher layer signaling is used to control the number of redundancy versions the UE shall use.Table 1: RV for E-DCH E-DCH RV Index S r 0 1 0 1 0 0 2 1 1 3 0 1 - The following parameters are used:
- Nsys = Np1 = Np2 = Ne,j /3
- Ndata = Ne,data,j
- rmax = 2
- The exact way how these parameters are used to determine the actually used rate-matching pattern are described in the above cited section of R1-041354, Editor (Siemens), "CR 25.212 - Introduction of E-DCH", November 2004, Shin Yokohama, Japan. This way can be applied also for the various embodiments presented here.
- In particular, the following two sections of this document shows, how the rate matching pattern is derived. The first citation, chapter 4.2.7.5 "Rate matching pattern determination" deals with the exact determination of the rate matching pattern based on the parameters eplus, eminus and eini. Of these parameters eini describes the initial error between the current or actual and the desired puncturing ratio, eplus a stepwidth for changing the error and , eminus another step width, used in the rate matching algorithm .The section Chapter 4.5.4.3 "HARQ Second Rate Matching Stage" describes how to calculate these parameters from the input parameters Nsys, Ndata and rmax , wherein Nsys denotes the number of systematic bits, that is bits carrying information in contrast to parity bits used for encoding, Ndata denotes the total number of bits, i.e. parity bits and systematic bits and rmax denotes the maximum value of r plus one. In Chapter 4.5.4.3. from this document shows how the parameters, in particular eplus, eminus and eini for the algorithm in section 4.2.7.5 are set:
The parameter s specifies whether the RV is self decodable, this means decodable if only this RV is considered. Decodable means in this respect, that the information content of the data packet, represented by the redundancy version can be found out. If s=1, then when puncturing during rate matching the so called systematic bits are prioritized over the parity bits of the turbo code. Such a redundancy version is typically self decodable, that means, that it can be decoded by itself, unless of course the reception is too noisy. This is not the case when s=0 (parity bits are prioritized), where it can happen that a RV cannot be decoded by itself, even in the absence of noise, but only together with an other RV. Therefore the first transmission of a packet should always be self-decodable, i.e. employ s=1. - During soft-handover (SHO) it may happen, that one base station does receive the packets from the mobile station up to a certain time, while another base station receives the packets after that time. This happens, if the instantaneous path loss to the second base station becomes better than the path loss to the first one, which can happen easily due to fast fading. Path loss is the degradation of a signal transmitted over a certain connection between e.g. a terminal and a base station. The signal takes a certain way, the path. Due to reflection, interferences etc it is subject to a degradation.
- If the path loss to the second base station becomes better, it is advantageous, if all the redundancy versions are self-decodable., as The second base station might otherwise not be able to immediately decode the packets after such a switch, as it might not have received the initial transmission of a data packet, which is self decodable, but only later transmissions, which are by itself not self decodable:
- This intention is also covered in the sections 4.2.7.5 and 4.5.4.3 described above.
- The inventors have found out, that surprisingly this means not necessarily, that s=1 should be selected for every RV, if the connection or data transmission is currently in SHO. The reason is, that s=0 only creates a non-self-decodable RV if puncturing is applied as described above. By puncturing the canceling of individual bits is described. Puncturing is done in order to reduce the overall number of bits, e.g. to adapt the overall number to a fixed capacity of a transmission. The puncturing of bits is done such, that no or only as little as possible information is lost. Therefore often mainly parity bits are punctured.
- If now repetition is performed, then all coded bits are transmitted anyhow, some of them are even repeated. Therefore s=0 can be safely selected. In this case s=0 simply selects another redundancy version than s=1.
- Using different RVs enhances the performance (so called incremental redundancy (IR)) and the more different RVs can be selected the better. So the general rule to use s=1 in soft handover as given in the citation is actually not beneficial in this case but should be modified for the case of repetition.
- Therefore according to an advantageous embodiment the selection of redundancy versions is based not only on the RSN but also on the fact whether puncturing or repetition is used for rate matching.
- Another criterion which is taken into account additionally or alternatively, is the coding rate. The coding rate is the number of bits before the coding divided by the number of bits after coding and after rate matching. Rate matching is the puncturing or repeating of bits in order to achieve a desired final number of data in a certain time interval or correspondingly a desired data rate.
- Typically, for E-DCH, so called "turbo codes" are used for coding of the payload data. Payload data are the data actually carrying information, in contrast for data used for signaling etc. These turbo codes have a code rate of (approximately) 1/3 i.e. for every bit to be coded three coded bits are generated, namely one systematic bit and two parity bits. If the code rate (after rate matching) is smaller than 1/3 then repetition is used during rate matching, if the code rate is larger than 1/3 then puncturing is used. Therefore the decision which RVs to use, and in particular whether to use s=0 can be based advantageously on the (coding) rate.
- In this context it should be noted, that the code rate of a turbo code without rate matching is not exactly1/3 but slightly lower, because additionally so called "termination bits" are appended at the end of the encoded data. However, for the purpose of the embodiments described in the context of this application, this difference is small enough to be irrelevant. Therefore, in the detailed embodiments it is possible to either compute the coding rate taking the termination bits into account or not. The result will generally be equal.
- According to a further advantageous embodiment the following selection of RVs based on the RSN and the code-rate is realized:
Table 2: Relation between RSN value and E-DCH RV Index coding rate 1/3< rate < 1/2 1/2 ≤ rate < 5/6 rate≥5/6 or rate≤1/3 RSN value E-DCH RV Index E-DCH RV Index E-DCH RV Index 0 0 0 0 1 2 3 1 2 0 2 3 3 └TTIN/NARQ┘ mod 2 *2 └TTIN/NARQ┘ mod 3 └TTIN/NARQ┘ mod 4 - In table 2 the redundancy version Index for the E-DCH is shown for various coding rates and different retransmission sequence numbers RSN.
The E-DCH RV Index is computed from the RSN value, the used coding rate and, if RSN = 3, also from the TTIN (TTI(time transmission interval)-number). For UMTS, if choosing 10 ms for a TTI, then the TTI number is equal to the connection frame number CFN, for 2 ms TTI we define
where the subframe number counts the five TTIs which are within a given CFN, stating from 0 for the first TTI to 4 for the last TTI. In other words, a subframe has for UMTS a length of 5 TTIs. - NARQ is the number of Hybrid ARQ processes that is how many transmissions of individual data packets are performed in parallel. E.g. there is the transmission and retransmission of a data packet A. At the same time transmission and retransmission of data packet B or further data packets has already begun. The usage of the TTIN instead of the CFN is necessary, if a CFN contains more than one TTI in order to distinguish the TTIs within one CFN. This depends on the set up of the individual data connection and the system within which the data connection is established. Therefore, the conditions can be generalized for other numbers of TTIs contained in a frame. The division by the number of NARQ, the number of ARQ processes, is necessary, because a retransmission will not be scheduled immediately after the previous transmission, but only after reception of the corresponding acknowledgement (ACK or NACK). As explained above, in the meantime data packets are transmitted using different HARQ processes.
- As can be seen when comparing the last and the second column of table x above, E-DCH RV index is always chosen so that s=1 (i.e. E-DCH RV index is 0 or 2, compare Table 2 above) is used in the second column. In the last column which is used if the rate is smaller than 1/3, i.e. for repetition, s=0 is used as well (E-DCH RV index 1 and/or 3).
Therefore, according to a further embodiment s=1 for 1/3< rate <1/2 is used as shown in table 2. According to another embodiment s=0 is not used, even if the data link or the data transmission is not in SHO. In this way, it is not necessary to establish a common understanding whether SHO is used or not, which facilitates e.g. the signaling for the following reasons:
Because the initiation of SHO always is somewhat delayed due to the delay of the associated signaling, and because this signaling delay is not necessarily equal for the signaling from the RNC (radio network controller), from where the handover is typically initiated, to the base stations and the terminals or mobile stations, a perfect synchronization of a common understanding is cumbersome. By the above embodiment this necessity of determining whether a SHO is currently performed is avoided. - Selecting only two RVs for this case is not disadvantageous as it was considered before, because for these rates two RVs are sufficient to transmit: Via two retransmissions, all bits which are generated by the turbo coder can be transmitted: For rate 1/2, after rate matching, all systematic and half the parity bits are transmitted in one RV in the other RV, again all systematic and the other half of the parity bits are transmitted. Therefore the usage of a non-self-decodable RV, which could transmit even more parity bits, is not necessary for this code rate but only for higher code rates. The inventors have found out that prior art methods would be disadvantageous in the aspect of systematic bits, because in general the systematic bits should be emphasized more than the parity bits, also when taking multiple RVs together.
- Therefore only for higher code rates than 1/2, we propose to use s=0, i.e. non self-decodable RVs for the retransmission. In particular, if 1/2 ≤ rate < 5/6 we propose to use one non self-decodable RV, see the middle column in table 9. At code rate 2/3 the first RV, which is self-decodable contains all systematic bits and 1/4 of the parity bits, the second RV, which is non-self-decodable contains purely parity bits i.e. 3/4 of the parity bits. Therefore, up to rate (2/3), it is possible to transmit all bits with two redundancy versions. At higher rates, it is necessary to use more than one non-self-decodable RV: If the code rate is one, only the systematic bits are transmitted in the initial transmission, the first and second retransmissions contain each 50% of the parity bits. So one non-self-decodable RV is ideal for Rate 2/3 and two non-self-decodable RV are ideal for rate 1. As 5/6 is the arithmetic mean of 2/3 and 1, we propose to use this value for the transition between one and two non-self-decodable transmissions. Obviously other thresholds are possible as well, down to 2/3 as 2/3 is the maximum rate
where all parity bits can be transmitted with on self-decodable and one non-self-decodable transmission. Likewise the threshold of rate 1/2 can also be set somewhat higher, e.g. at the arithmetic mean between 1/2 and 2/3 which is 7/12 or any value between 1/2 and 7/12. Further more it was decided that the UE (User Equipment, a synonym for mobile station) should only use a given maximum data rate when in Soft Handover. The reason is that mobile stations in soft handover will create interference in two cells, so limiting their data rates beneficially influences the situation in two cells. At this maximum data rate a certain coding rate will apply. So in an embodiment of this invention, the transition point i.e. the minimum coding rate at which also non-self-decodable transmission are used, can be selected to correspond to the maximum data rate which is admissible in SHO. - In the right column, for code rates above 5/6, as was show above two non-self-decodable RVs are proposed, see table x.
- As stated above, the RVs are explicitly allocated to the first three transmissions, where RSN < RSNMAX. If RSN reaches RSNMAX, which is 3 in the example given above, the Redundancy version is calculated based on the TTIN. This has the advantage, that different RVs are used for successive transmissions, even if always the same RSN (i.e. RSNMAX) is used. Only for the first transmission with RSN=RSNMAX, it would be advantageous to select the optimum RV, however then always this RV would have to be used after RSN reaches RSNMAX, which is clearly undesirable. For the different rates some care needs to be taken, when selecting the formula that selects the RVs, this is detailed below:
- If 1/3 < rate < 1/2, then only self-decodable RVs are used, so only these should be selected as well for RSN> RSNMAX. This is realized by └TTIN/NARQ┘ mod 2 *2 in table x above.
- If 1/2 ≤ rate < 5/6 (or generally in the middle column), one non self-decodable transmission is needed. Still the systematic bits should be prioritized, therefore two self-decodable RVs are used. For RSN=1 the E-DCH RV index 3 is selected, while for RSN=3, via the formula, the RVs 0,1,2 are selected cyclically. In this way some further gain can be reached, as different non-self-decodable RVs are used for RSN=1 and RSN=3, this gives some additional IR gain. This is realized by └TTIN/NARQ┘ mod 3 in table x above.
- If the rate≥5/6 (or 2/3 as explained above), then two non-self-decodable RVs are necessary to cover all parity bits. In order to also emphasize the systematic bits in this case, we propose to use 4 RVs for RSN=3, two non-self-decodable ones, and two (not only the minimum of 1) self-decodable RV. This is realized by └TTIN/NARQ┘ mod 4.
- Here └ ┘ means rounding down to the largest integer, which is not larger than x, also sometimes called floor(x) or int(x).
- In the following embodiments a further, different, enhancement to the RSN scheme is employed, which can again be used either in combination with or independent from the other enhancements presented in this invention.
- In R1-041339, Panasonic, Downlink signaling related issues for Enhanced Uplink, November 2004, Shin Yokohama, Japan it was proposed, that a terminal UE should retransmit the initial redundancy version, if the E-DCCH data could not be decoded. The E-DCCH carries overhead information related to the payload-data, e.g. the used transport format i.e. the number of payload bits, and is necessary to decode the payload-data. So if the base station could not decode the E-DCCH it will not be able to make any use of the data transmitted on E-DCDCH. The base station can determine that the E-DCCH was not detected correctly e.g. if a CRC (cyclic redundancy check is appended to the E-DCCH data. If the base station cannot make use of the first RV, then in R1-041339, Panasonic, Downlink signaling related issues for Enhanced Uplink, November 2004, Shin Yokohama, Japan it was proposed to retransmit the first RV again, in order to make sure that the first RV which is actually available for the base station is a self-decodable transmission. In this document several proposals are made how this is signaled to the mobile station, e.g. by introduction of a third state apart from ACK and NACK. In the context of the described embodiments the exact way of signaling is not critical, therefore any signaling used in a HARQ process can be applied.
In the frame of this application this signaling is called CNAK (Control- NACK). However, this document does not disclose any information how the re-selection of the first RV shall be realized in conjunction with the RSN scheme.
In this document in particular the section "Node B reception scenarios" is relevant, in particular the citation below, which starts at the third paragraph of this section:
The table below shows 3 different scenarios, which can occur when UE sends the initial transmission of a data packet. The second column in the table describes the reception status at Node B for each scenario, the third column shows the preferred UE behavior in such situation.UE transmission Node B reception status UE behaviour depending on Node B reception 1 E-DPCCH sent with self-decodable RV Node B decodes E-DPCCH, but CRC of E-DPCCH fails UE retransmits self-decodable RV of the data packet. 2 E-DPCCH sent with self-decodable RV Node B successfully decodes E-DPCCH, CRC on E-DPDCH fails UE sends next RV of the data packet according to the RSN 3 E-DPCCH sent with self-decodable RV Node B successfully decode both E-DPCCH and E-DPDCH UE sends next data packet
In case the E-DPCCH cannot be decoded correctly, as listed as the first scenario in the table, Node B cannot process the data received on E-DPDCH. A decoding of the received data is not possible and therefore Node B discards the data. In our view it would be beneficial to transmit the self-decodable RV again in such a situation. When UE sends retransmissions according to the specified RV sequence, a decoding of the data packet is only possible after the transmission of the next self-decodable RV, which may lead to an increased delay. Therefore we prefer to retransmit the self-decodable RV (initial transmission) in such a scenario. Scenario 2 describes the case when Node B decodes the E-DPCCH correctly, but the CRC on the E-DPDCH fails. Here Node B can use the received energy on the E-DPDCH when combining it with further retransmissions. Therefore UE shall retransmit according to the specified RV sequence in this case. We propose that the UE behaviour is different depending on whether the 1st or 2nd scenario has occurred. - There are basically two possibilities: One possibility would be to assign the first RV not only to RSN=0 but also to RSN=1 in this case, consequently, the next RVs would also be shifted to the respective next RSN-value. While this approach is feasible, there is a a better approach used in an embodiment: If the mobile station receives a CNAK, then the next transmission is sent again with RSN=0 and consequently with the first, self-decodable RV. At first sight this may seem to imply that the RSN protocol as described above could no longer be used in this case. However, it can be enhanced to also support this case: Both base station and mobile station are aware of this situation via the CNAK signaling. Both can therefore take this fact into account for the RSN-protocol. Further more, the base station may anyhow decide to flush the soft buffer as it could not make use of the first transmission, this is already in accordance with the handling of the RSN-protocol. If this happens in Soft-Handover, then other base stations are typically not aware that the first base station has transmitted a CNAK. However, due to the RSN-protocol they can detect that a new RSN=0 transmission is sent and flush their soft buffer. While flushing the buffer is not strictly necessary in this case, it has the effect that the other base stations become aware of the fact, that the RV sequence is reset, and will therefore use the correct RV. Otherwise, these other base stations would use a wrong RV, consequently they would not have any chance to decode the packet, this would be a waste of resources. Even if one of the other base stations in soft handover could detect the packet correctly already for the first transmission, the RSN protocol still works fine: Then this base station sends an ACK at the same time when the first base station transmits a CNAK. The mobile station will then transmit the next packet, as usual using RSN=0. The first base station will not be aware of the fact, that the second base station has acknowledged the first packet and therefore is not aware that a new packet is transmitted. However, as it will anyhow flush the buffer from the first packet it does not matter whether now the first or the next packet is transmitted.
- Even if the mobile station or the terminal UE erroneously misinterprets the CNAK as an ACK, the base station can still correctly receive the next packet. The first packet is lost in this case, but not due to the enhancement of the RSN-protocol but simply due to the false reception of the ACK. This error case is already possible without the RSN-protocol enhancement, when a NAK is miss-interpreted as an ACK, i.e. the enhanced RSN protocol does not cause any further degradation.
- This invention has presented enhancements to the RSN. It should be noted that there are also other possibilities to provide similar functionality by other means or somewhat different signaling. One such proposal is the NDI (New Data Indicator). The NDI is incremented modulo a maximum value for every new packet but is identical for retransmission of a packet. The NDI scheme may be more robust in cases where there are many retransmissions, because then the NDI is only incremented seldom and there is less risk that it becomes no more unambiguous (e.g. due to wrap around).
- According to a further aspect of this invention, either the RSN or NDI scheme can be used depending on properties of the connection. That means that even in a single connection sometimes RSN and sometimes NDI can be used depending on the property. Such properties may include the fact whether the connection is or is not in Soft Handover, or the used packet size or coding rate.
- In a preferred embodiment the selected property can be determined by the transmitter and receiver without additional explicit signaling. In this case no extra signaling overhead is introduced.
- It will be apparent to those versed in the art, that the presented invention can be combined beneficially by combining aspects presented in this application with one another or with other known procedures. The invention which was described by example above is therefore considered to be also applicable to those cases. In particular the examples and the description should not be understood to limit the scope of the invention.
- In the following further examples, explanations, embodiments and variants of the present invention are given:
- In the last meeting substantial progress regarding the HARQ definition for E-DCH was made. An important agreement was to have a synchronous protocol with synchronous retransmissions and to have HARQ with IR and Chase combining.
- Further while operating IR it was agreed that the redundancy versions are taken in a given order and that the first transmission always emphasizes the systematic bits (s=1). For retransmissions in non SHO both emphasizing and non emphasizing of systematic bits should be possible (s=0 or s=1).
- Another agreement for SHO was that the utilization of transmissions always emphasizing the systematic bits (s=1) is generally considered to be beneficial.
- Starting from these facts and the agreement that the RV may be linked to the CFN for some E-TFCs and explicitly signaled for other E-TFCs this contribution proposes a solution for the signaling of the HARQ related information.
- The HARQ related signaling information is transmitted with every E-DCH packet transmission together with the E-TFC information. Its function is to inform the Node B about the used redundancy version (Xrv value) needed for the de-rate matching as well as to trigger the flushing of the Node B soft buffer.
- The redundancy versions and the ordering in which the redundancy versions are applied should be controlled by the network e.g. through higher layer signaling or it can be specified for every TFC using a fixed mapping rule. The rule is known to both the UE and the network and can implemented "hard-wired". In our view for each TFC three redundancy versions (one for the initial transmission, one for the first and one for the second retransmission) should be specified or signaled from higher layers.
- In the following due to the different requirements regarding the reliability of the new data indication and the different link efficiency gains for the RV selection in SHO and no SHO we separate the discussion for both cases.
- In case of no SHO we propose a 2 bit RSN as described inR1-040958, Ericsson, "E-DCH Physical Layer Hybrid ARQ Processing", Prague, Czech Republic, August 2004, where it is disclosed to include a RSN in uplink signaling and derive the Redundancy Version based on the RSN. This including of the RSN in signaling has also been described above in the context of the introduction of the RSN.
- Thus the applied redundancy version is signaled from the UE to the Node B. Additionally the RSN provides the functionality of new data indication (in case the RSN=0 the soft buffer is indicated to be flushed). The RSN is incremented with every retransmission and set to 0 with every initial transmission. In case the number of retransmissions exceeds two the RSN is set to 3 for all further retransmissions. This has the advantage that the number of bits for the RSN can be lower than log2(Nmax) without losing IR gain since the number of different RVs is typically lower than the maximum number of transmissions Nmax. For RSN=3 the RV selection is CFN based to achieve further gain.
- As described in R1-040906, Motorola, "Synchronous HARQ and reliable signaling during SHO (Enhanced Uplink)", Prague, Czech Republic, August 2004 in case of SHO specific TFCs are chosen by the UE. Generally the SHO TFCs provide lower rates. For lower rates it was already shown during the study item phase that the IR link efficiency gain compared to Chase combining is around 0.3 dB. However the performance difference between different IR schemes and also between IR schemes with different RV orderings is negligible small, as it has been shown in R1-040719, Qualcomm, "Link Performance with different RV for Low Data Rates", Cannes, France, June 2004.
- Consequently to achieve the best performance also in SHO we propose to use specific TFCs together with IR. To specify an explicit rule for the RV selection is not reasonable due to the negligible differences of the IR schemes. Therefore we propose to do the RV selection implicitly and based on the CFN similar as described already in several other contributions [2,3].
- In SHO then the 2 bit RSN as described for the no SHO case is no longer needed and can be reused. Keeping in mind that the most important issue for the HARQ related signaling in SHO is to avoid Node B buffer corruption we propose to reuse the 2 RSN bits as a 2 bit NDI. In contrast to the RSN, which is incremented per retransmission, the NDI is incremented at the UE with every initial transmission. Compared to the RSN the NDI provides a higher reliability especially in case the residual BLER after the first retransmission is targeted to 1%).
- In this document we propose to use only 2 bits for the HARQ related UL E-DCH signaling information used to provide the new data indication and the RV selection functionality.
- Depending on the chosen TFC the counter is incremented on a per retransmission (=RSN) or a per initial transmission basis (=NDI) to support the NDI or RV selection functionality as good as possible.
- Background for this solution is the given fact, that in case of SHO the NDI reliability is much more critical than in non SHO and that the RV selection in non SHO has much more influence on the performance than in SHO.
- Further the proposal comprises also the RV selection in SHO, which is done implicitly using the CFN e.g. as described in [2,3]. In case of no SHO the RVs for the initial transmission and the first and second retransmission is signaled by the network whereas the actual usage is indicated by the UEs RSN.
-
- E-DCH:
- Enhanced Dedicated Channel, basically an improvement of the existing UMTS uplink channel.
- E-DCDH:
- Enhanced Dedicated Data Channel, carries the payload-data of E-DCH.
- E-DCCH:
- Enhanced Dedicated Control Channel, carries overhead data (L1 signaling) for E-DCDCH.
- IR:
- Incremental Redundancy
- SHO:
- Soft Handover
- CFN:
- Connection Frame Number
- E-TFC:
- Enhanced Transport Format Combination
- UE:
- User Equipment, mobile station.
- log2:
- logarithm base 2
- UL:
- Uplink
- RSN:
- Retransmission Sequence Number
- RSNMAX:
- Maximum value of Retransmission Sequence Number
- TTIN:
- TTI-number
- TTI:
- Transmission Time Interval
- CFN:
- Connection Frame Number
- ARQ:
- Automated Retransmission reQestHARQ: Hybrid ARQ
- ACK:
- Acknowledge
- NACK:
- Not Acknowledge
- └x┘ :
- floor(x) i.e. the largest integer which is not larger than x.
- RV:
- Redundancy Version
- NARQ:
- Number of Hybrid ARQ processes
- UE:
- User Equipment, a synonym for mobile station or terminal
Claims (12)
- Method for transmission of an information content contained in at least one data packet, which is transmitted from a sender (UE) to a receiver (BS) via a data link (E-DCH) wherein said information is represented by a bit sequence, which is encoded into a transmittable redundancy version of a hybrid ARQ protocol and whereina. Initial transmitting of the information for a first time in a first data packet from the sender (UE) to the receiver (BS), wherein the information is represented by a first redundancy version, which is self-decodable;b. Receiving a confirmation confirming an incorrect receipt from the receiver (BS) at the sender (UE);c. Retransmitting the information at least a first time in a second data packet from the sender (UE) to the receiver (BS) upon receipt of the confirmation in step b), wherein for representation of the information a second redundancy version is used, the selection of which is performed in dependence on the coding rate, selecting a self-decodable redundancy version if the coding rate is lower than a predefined upper coding rate.
- Method according to claim 1, wherein the predefined upper coding rate is equal to 1/2.
- Method according to claim 1 or 2, wherein the selection in step c) is based on a puncturing parameter describing, whether the redundancy version has been produced with or without a puncturing of the bit sequence.
- Method according to any of the previous claims, wherein the selection in step c) is based on a transmission number parameter describing the number n of retransmissions of information in a n-th data packet.
- Method according to claim 4, wherein a set of redundancy versions can be derived from the bit sequence and for a first range of numbers of transmissions a first subset of this set of redundancy versions is available and for a further range of numbers of transmissions a further subset is available.
- Method according to claim 5, wherein the first subset and the second subset are partly or completely distinct.
- Method according to any of the previous claims 4 to 6, wherein the further subset is a superset of the first subset.
- Method according to any of the previous claims, wherein at least a second information content is sent analogously to the first information content and wherein the number of information contents sent in parallel is determined and this number is used as process number parameter for the selection of the redundancy version.
- Method according to any of the previous claims, wherein at least two out of the parameters are combined to a superior parameter.
- Method according to any of the previous claims, wherein further a control confirmation indicating incorrect decoding of a redundancy version is foreseen and upon receipt of a control confirmation a retransmission number is reset to an original value.
- Method according to any of the previous claims, wherein the redundancy version is described by a parameter s, which denotes, whether the redundancy version is self decodable.
- Telecommunication device (UE) comprising means arranged for performing the method according to any of the claims 1 - 11.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP05796975A EP1794921B1 (en) | 2004-09-15 | 2005-09-15 | Decoding method |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP04021970A EP1638238A1 (en) | 2004-09-15 | 2004-09-15 | Method for combining data packets by a telecommunication device |
EP04027144A EP1657844A1 (en) | 2004-11-15 | 2004-11-15 | Decoding method |
EP05796975A EP1794921B1 (en) | 2004-09-15 | 2005-09-15 | Decoding method |
PCT/EP2005/054578 WO2006030019A2 (en) | 2004-09-15 | 2005-09-15 | Decoding method |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1794921A2 EP1794921A2 (en) | 2007-06-13 |
EP1794921B1 true EP1794921B1 (en) | 2009-04-15 |
Family
ID=35811557
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP05796975A Active EP1794921B1 (en) | 2004-09-15 | 2005-09-15 | Decoding method |
Country Status (9)
Country | Link |
---|---|
US (5) | US8645786B2 (en) |
EP (1) | EP1794921B1 (en) |
KR (1) | KR101116419B1 (en) |
AT (1) | ATE429092T1 (en) |
BR (1) | BRPI0515440A (en) |
DE (1) | DE602005013987D1 (en) |
HK (1) | HK1204722A1 (en) |
RU (1) | RU2386215C2 (en) |
WO (1) | WO2006030019A2 (en) |
Families Citing this family (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8645786B2 (en) | 2004-09-15 | 2014-02-04 | Nokia Siemens Networks Gmbh & Co. Kg | Decoding method |
US7437161B2 (en) * | 2005-03-16 | 2008-10-14 | Lucent Technologies Inc. | Method of fast data transmission of mobile stations via the same base station |
KR100913872B1 (en) * | 2006-01-18 | 2009-08-26 | 삼성전자주식회사 | Apparatus and method for transmitting/receiving data in a communication system |
US7502981B2 (en) * | 2006-04-19 | 2009-03-10 | Motorola, Inc. | Automatic repeat request (ARQ) scheme |
KR100888503B1 (en) * | 2006-12-01 | 2009-03-12 | 한국전자통신연구원 | Method and apparatus for derate matching in communication system |
ES2949260T3 (en) * | 2007-06-18 | 2023-09-27 | Optis Wireless Technology Llc | Procedure and arrangement in a mobile telecommunications network for HARQ Hybrid Automatic Repeat Request with TTI transmission time slot grouping and with incremental redundancy |
US7865813B2 (en) | 2007-07-30 | 2011-01-04 | Marvell International Ltd. | Rate matching for a wireless communications systems |
CN101119182B (en) * | 2007-08-13 | 2013-02-27 | 中兴通讯股份有限公司 | Bit priority selection method of high-order modulation |
ES2373240T3 (en) | 2007-12-20 | 2012-02-01 | Panasonic Corporation | CONTROL CHANNEL SIGNALING USING A COMMON SIGNALING FIELD FOR TRANSPORT FORMAT AND REDUNDANCY VERSION. |
US8917598B2 (en) | 2007-12-21 | 2014-12-23 | Qualcomm Incorporated | Downlink flow control |
US8699487B2 (en) | 2008-02-04 | 2014-04-15 | Qualcomm Incorporated | Uplink delay budget feedback |
US8656239B2 (en) | 2008-02-12 | 2014-02-18 | Qualcomm Incorporated | Control of data transmission based on HARQ in a wireless communication system |
US8441981B2 (en) * | 2008-02-14 | 2013-05-14 | Qualcomm Incorporated | Exploiting known rate matching information in blind decoding of downlink wireless data transmissions |
CN102084683B (en) | 2008-03-12 | 2016-09-28 | 松下电器(美国)知识产权公司 | Radio communication device, wireless communication system and wireless communications method |
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 |
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 |
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 |
WO2010016669A2 (en) * | 2008-08-04 | 2010-02-11 | Samsung Electronics Co., Ltd. | Signal transmission method and apparatus for user equipment in mobile communication system |
WO2010031873A1 (en) * | 2008-09-22 | 2010-03-25 | Nokia Siemens Networks Oy | Method and apparatus for providing signaling of redundancy versions |
KR101634177B1 (en) * | 2009-01-15 | 2016-06-28 | 엘지전자 주식회사 | Method for processing and transmitting of data packet |
US8855100B2 (en) | 2009-06-16 | 2014-10-07 | Qualcomm Incorporated | System and method for supporting higher-layer protocol messaging in an in-band modem |
WO2011039575A1 (en) * | 2009-10-02 | 2011-04-07 | Nokia Siemens Networks Oy | Dynamic allocation for control channel and data channel within a subframe |
US9088346B2 (en) | 2010-06-30 | 2015-07-21 | Comtech Ef Data Corp. | System and method for a broadcast recovery carrier channel for static and dynamic carrier systems |
EP2629442B1 (en) | 2012-02-14 | 2014-12-10 | Telefonaktiebolaget L M Ericsson (publ) | Redundancy version selection based on receiving quality and transport format |
WO2015122956A1 (en) * | 2014-02-12 | 2015-08-20 | Comtech Ef Data Corp. | System and method for a broadcast recovery carrier channel |
WO2017069676A1 (en) * | 2015-10-19 | 2017-04-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Soft buffer handling with limited memory access bandwidth |
BR112018077102A8 (en) * | 2016-06-30 | 2022-06-28 | Sharp Kk | TERMINAL DEVICE, BASE STATION DEVICE, COMMUNICATION METHOD AND INTEGRATED CIRCUIT |
EP3665813A1 (en) | 2017-08-11 | 2020-06-17 | Telefonaktiebolaget LM Ericsson (Publ) | Redundancy versions in a hybrid automatic repeat request, harq, process |
US10904898B2 (en) * | 2017-11-16 | 2021-01-26 | Qualcomm Incorporated | Multi-slot scheduling with repetitive transmission of a transport block with different redundancy versions |
US10680778B2 (en) | 2018-02-16 | 2020-06-09 | At&T Intellectual Property I, L.P. | Reducing control channel overhead in 5G or other next generation networks |
US10841063B2 (en) | 2018-04-06 | 2020-11-17 | At&T Intellectual Property I, L.P. | Indicating a number of codewords in 5G wireless communication systems |
US10834748B2 (en) | 2018-05-11 | 2020-11-10 | At&T Intellectual Property I, L.P. | Indication of additional information in 5G systems with legacy downlink control channel |
DE102019206666B3 (en) * | 2019-05-09 | 2020-06-10 | Audi Ag | Method and control device for configuring a channel coding during the transmission of data packets from a transmitting device to a receiving device and motor vehicle |
Family Cites Families (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3870824A (en) | 1973-05-29 | 1975-03-11 | Vidar Corp | Redundant data transmission system |
FR2655221B1 (en) | 1989-11-28 | 1994-04-15 | Alcatel Transmission Faisceaux H | METHOD FOR AUTOMATIC RETRANSMISSION REQUEST FOR DUPLEX DIGITAL TRANSMISSION INSTALLATION WITH AT LEAST ONE NOISE RETURN TRACK AND INSTALLATION FOR IMPLEMENTING THIS PROCESS. |
US5657325A (en) * | 1995-03-31 | 1997-08-12 | Lucent Technologies Inc. | Transmitter and method for transmitting information packets with incremental redundancy |
FI103540B1 (en) | 1997-04-28 | 1999-07-15 | Nokia Mobile Phones Ltd | Method of transmitting packet-shaped data in a mobile telephone system |
US6208663B1 (en) | 1997-08-29 | 2001-03-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for block ARQ with reselection of FEC coding and/or modulation |
US6704898B1 (en) | 1998-10-23 | 2004-03-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Combined hybrid automatic retransmission request scheme |
EP1145476A1 (en) | 1999-01-29 | 2001-10-17 | Nokia Corporation | Signalling method in an incremental redundancy communication system whereby data blocks can be combined |
WO2001022747A1 (en) | 1999-09-22 | 2001-03-29 | Motorola Inc. | Selecting channels for retransmission of data packets |
US6308294B1 (en) * | 1999-11-17 | 2001-10-23 | Motorola, Inc. | Adaptive hybrid ARQ using turbo code structure |
US7072307B2 (en) * | 2000-01-20 | 2006-07-04 | Nortel Networks Limited | Hybrid ARQ schemes with soft combining in variable rate packet data applications |
DE60005150T2 (en) | 2000-05-17 | 2004-04-01 | Matsushita Electric Industrial Co., Ltd., Kadoma | Hybrid ARQ procedure for data packet transmission |
EP1168702A1 (en) | 2000-06-30 | 2002-01-02 | Motorola, Inc. | Data transmission system using a hybrid automatic repeat request protocol |
US7746953B1 (en) | 2000-09-12 | 2010-06-29 | Alcatel-Lucent Usa Inc. | Method and apparatus for asynchronous incremental redundancy transmission in a communication system |
WO2002033877A1 (en) | 2000-10-21 | 2002-04-25 | Samsung Electronics Co., Ltd | Data transmitting/receiving method in harq data communication system |
KR100525384B1 (en) * | 2000-10-31 | 2005-11-02 | 엘지전자 주식회사 | Method for controlling packet retransmission in mobile communication system |
GB0110125D0 (en) * | 2001-04-25 | 2001-06-20 | Koninkl Philips Electronics Nv | Radio communication system |
EP1286491B1 (en) | 2001-08-22 | 2004-06-30 | Matsushita Electric Industrial Co., Ltd. | Multichannel ARQ method and apparatus |
US7260770B2 (en) | 2001-10-22 | 2007-08-21 | Motorola, Inc. | Block puncturing for turbo code based incremental redundancy |
US7372837B2 (en) * | 2001-10-26 | 2008-05-13 | Texas Instrument Incorporated | Incremental redundancy using two stage rate matching for automatic repeat request to obtain high speed transmission |
KR100557167B1 (en) * | 2001-11-02 | 2006-03-03 | 삼성전자주식회사 | Apparatus and method for transmitting/receiving of re-transmit in a mobile communication system |
DE60114849T2 (en) | 2001-11-16 | 2006-04-20 | Matsushita Electric Industrial Co., Ltd., Kadoma | ARQ retransmission with request repeating scheme that uses multiple redundancy versions and receiver / sender for it |
AU2002328708A1 (en) | 2001-12-10 | 2003-07-09 | Nortel Networks Limited | Adaptive multi-mode harq system and method |
GB2383491B (en) | 2001-12-20 | 2005-01-19 | Motorola Inc | Packet data re-transmission |
US6700867B2 (en) * | 2001-12-20 | 2004-03-02 | Motorola, Inc. | Method and system for reduced memory hybrid automatic repeat request |
EP1635498B1 (en) | 2002-01-07 | 2011-03-02 | Siemens Aktiengesellschaft | Method and device for transferring data wherein a bit rate adaptation model is signalled between the transmitter and the receiver |
SG107576A1 (en) | 2002-01-17 | 2004-12-29 | Oki Techno Ct Singapore Pte | Communication system employing turbo codes and a hybrid automatic repeat request scheme |
US7000173B2 (en) * | 2002-02-11 | 2006-02-14 | Motorola, Inc. | Turbo code based incremental redundancy |
US7287206B2 (en) | 2002-02-13 | 2007-10-23 | Interdigital Technology Corporation | Transport block set transmission using hybrid automatic repeat request |
US7640486B2 (en) * | 2002-02-15 | 2009-12-29 | Siemens Aktiengesellschaft | Method for rate matching |
AU2002315928A1 (en) * | 2002-04-09 | 2003-10-23 | Nec Australia Pty Ltd | Improved signalling scheme for high speed downlink packet access |
CN1288872C (en) | 2002-04-24 | 2006-12-06 | 三星电子株式会社 | Apparatus and method for supporting qutomatic repeat request of high speed wireless packet data communication system |
US6631127B1 (en) * | 2002-05-29 | 2003-10-07 | Motorola, Inc, | Apparatus and method for dynamically selecting an ARQ method |
US7301929B2 (en) * | 2002-08-09 | 2007-11-27 | Spyder Navigations, L.L.C. | Method and system for transport block size signaling based on modulation type for HSDPA |
US6996114B2 (en) * | 2002-10-25 | 2006-02-07 | Nokia Corporation | Method for rate matching to support incremental redundancy with flexible layer one |
KR100584431B1 (en) * | 2003-02-14 | 2006-05-26 | 삼성전자주식회사 | System and method for uplink data retransmission in code division multiple access communication system |
US7813322B2 (en) | 2003-02-19 | 2010-10-12 | Qualcomm Incorporated | Efficient automatic repeat request methods and apparatus |
JP4224337B2 (en) * | 2003-04-04 | 2009-02-12 | パナソニック株式会社 | Radio transmission apparatus and radio transmission method |
US7414989B2 (en) | 2003-05-07 | 2008-08-19 | Motorola, Inc. | ACK/NACK determination reliability for a communication device |
US7385954B2 (en) * | 2003-07-16 | 2008-06-10 | Lucent Technologies Inc. | Method of transmitting or retransmitting packets in a communication system |
US7155655B2 (en) | 2003-07-22 | 2006-12-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Adaptive hybrid ARQ algorithms |
DE10344765A1 (en) | 2003-09-26 | 2005-04-14 | Siemens Ag | Method for transmitting control data |
US7925953B2 (en) | 2003-10-07 | 2011-04-12 | Nokia Corporation | Redundancy strategy selection scheme |
US7388848B2 (en) | 2004-03-26 | 2008-06-17 | Spyder Navigations L.L.C. | Method and apparatus for transport format signaling with HARQ |
US7366477B2 (en) | 2004-05-06 | 2008-04-29 | Nokia Corporation | Redundancy version implementation for an uplink enhanced dedicated channel |
US8645786B2 (en) | 2004-09-15 | 2014-02-04 | Nokia Siemens Networks Gmbh & Co. Kg | Decoding method |
EP1638238A1 (en) | 2004-09-15 | 2006-03-22 | Siemens Aktiengesellschaft | Method for combining data packets by a telecommunication device |
US7237170B2 (en) * | 2004-10-06 | 2007-06-26 | Motorola, Inc. | Packet transmission redundancy selection apparatus and method |
KR100972353B1 (en) | 2005-01-05 | 2010-07-26 | 노키아 코포레이션 | Method, apparatus and system for providing a frame protocol data frame header |
WO2006101347A1 (en) | 2005-03-22 | 2006-09-28 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting packet data |
-
2005
- 2005-09-15 US US11/661,006 patent/US8645786B2/en active Active
- 2005-09-15 RU RU2007114037/09A patent/RU2386215C2/en not_active IP Right Cessation
- 2005-09-15 DE DE602005013987T patent/DE602005013987D1/en active Active
- 2005-09-15 BR BRPI0515440-5A patent/BRPI0515440A/en not_active IP Right Cessation
- 2005-09-15 AT AT05796975T patent/ATE429092T1/en not_active IP Right Cessation
- 2005-09-15 WO PCT/EP2005/054578 patent/WO2006030019A2/en active Application Filing
- 2005-09-15 KR KR1020077004998A patent/KR101116419B1/en not_active IP Right Cessation
- 2005-09-15 EP EP05796975A patent/EP1794921B1/en active Active
-
2013
- 2013-12-26 US US14/140,833 patent/US20140115415A1/en not_active Abandoned
-
2014
- 2014-06-19 US US14/309,787 patent/US8935588B2/en active Active
-
2015
- 2015-04-17 US US14/690,298 patent/US9294233B2/en active Active
- 2015-05-29 HK HK15105112.5A patent/HK1204722A1/en unknown
-
2016
- 2016-02-10 US US15/040,901 patent/US20160164639A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20140115415A1 (en) | 2014-04-24 |
DE602005013987D1 (en) | 2009-05-28 |
WO2006030019A3 (en) | 2006-06-08 |
US20160164639A1 (en) | 2016-06-09 |
US9294233B2 (en) | 2016-03-22 |
BRPI0515440A (en) | 2008-07-29 |
KR20070064425A (en) | 2007-06-20 |
RU2007114037A (en) | 2008-10-27 |
US8645786B2 (en) | 2014-02-04 |
US20150229445A1 (en) | 2015-08-13 |
CN104253679A (en) | 2014-12-31 |
ATE429092T1 (en) | 2009-05-15 |
US8935588B2 (en) | 2015-01-13 |
US20140304565A1 (en) | 2014-10-09 |
RU2386215C2 (en) | 2010-04-10 |
KR101116419B1 (en) | 2012-03-07 |
US20070255994A1 (en) | 2007-11-01 |
EP1794921A2 (en) | 2007-06-13 |
HK1204722A1 (en) | 2015-11-27 |
WO2006030019A2 (en) | 2006-03-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1794921B1 (en) | Decoding method | |
EP2461515B1 (en) | Method for combining data packets by a telecommunication device | |
EP3577806B1 (en) | Enhancements for retransmission due to conflicting transmissions for different services | |
CA2446700C (en) | Hybrid automatic repeat request (harq) scheme with in-sequence delivery of packets | |
EP1594247A2 (en) | Method and apparatus for determining rate matching parameters for a transport channel in a mobile telecommunication system | |
KR20050106350A (en) | A method and apparatus for tti change considering harq process for enhanced uplink dedicated channel | |
US20100146354A1 (en) | Method and apparatus for h-arq in a wireless communication system | |
JP4734186B2 (en) | Mobile terminal device, reception control method in the same device, and wireless transmission system | |
US20120084618A1 (en) | Jointly encoding a scheduling request indicator and acknowledgments/negative acknowledgments | |
KR101433834B1 (en) | Apparatus and method for transmission time interval reconfiguration in mobile communication system | |
US20130039266A1 (en) | System and method to increase link adaptation performance with multi-level feedback | |
KR20100043098A (en) | Methods and apparatuses for transmitting non-decodable packets | |
EP2409447A1 (en) | Methods and arrangements in a wireless telecommunication system | |
EP1657844A1 (en) | Decoding method | |
EP2557724B1 (en) | System and method to increase link adaptation performance with multi-level feedback | |
CN104253679B (en) | Coding/decoding method |
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: 20070122 |
|
AK | Designated contracting states |
Kind code of ref document: A2 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 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG |
|
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: NOKIA SIEMENS NETWORKS S.P.A. |
|
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG |
|
DAX | Request for extension of the european patent (deleted) | ||
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 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 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REF | Corresponds to: |
Ref document number: 602005013987 Country of ref document: DE Date of ref document: 20090528 Kind code of ref document: P |
|
NLV1 | Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act | ||
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: 20090415 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: 20090915 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: 20090415 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: 20090415 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: 20090726 |
|
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: 20090415 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: 20090715 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: 20090415 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: 20090415 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: 20090415 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: 20090815 |
|
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: 20090415 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: 20090415 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: 20090415 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: 20090415 |
|
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: 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: 20090415 Ref country code: BE 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: 20090415 |
|
26N | No opposition filed |
Effective date: 20100118 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
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: 20090715 |
|
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 NON-PAYMENT OF DUE FEES Effective date: 20090930 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: MM4A |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: ST Effective date: 20100531 |
|
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: 20090915 Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20090930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20090930 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: 20090716 Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20090930 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
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: 20090415 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20090915 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
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 Effective date: 20091016 |
|
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: 20090415 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
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: 20090415 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R081 Ref document number: 602005013987 Country of ref document: DE Owner name: CELLULAR COMMUNICATIONS EQUIPMENT GMBH, DE Free format text: FORMER OWNER: NOKIA SIEMENS NETWORKS GMBH & CO. KG, 81541 MUENCHEN, DE |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R082 Ref document number: 602005013987 Country of ref document: DE Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, DE Ref country code: DE Ref legal event code: R081 Ref document number: 602005013987 Country of ref document: DE Owner name: CELLULAR COMMUNICATIONS EQUIPMENT GMBH, DE Free format text: FORMER OWNER: CELLULAR COMMUNICATIONS EQUIPMENT LLC, PLANO, TEX., US |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20150909 Year of fee payment: 11 |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20160915 |
|
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: 20160915 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R082 Ref document number: 602005013987 Country of ref document: DE Representative=s name: WINTER, BRANDL - PARTNERSCHAFT MBB, PATENTANWA, DE |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R082 Ref document number: 602005013987 Country of ref document: DE Representative=s name: WINTER, BRANDL - PARTNERSCHAFT MBB, PATENTANWA, DE Ref country code: DE Ref legal event code: R081 Ref document number: 602005013987 Country of ref document: DE Owner name: VIVO MOBILE COMMUNICATION CO., LTD., DONGGUAN, CN Free format text: FORMER OWNER: CELLULAR COMMUNICATIONS EQUIPMENT GMBH, 80336 MUENCHEN, DE |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230526 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20240730 Year of fee payment: 20 |