WO2017137564A1

WO2017137564A1 - Automatic repeat request mechanisms

Info

Publication number: WO2017137564A1
Application number: PCT/EP2017/053011
Authority: WO
Inventors: Martin Hans; Andreas Schmidt; Maik Bienas
Original assignee: Ipcom Gmbh & Co. Kg
Priority date: 2016-02-10
Filing date: 2017-02-10
Publication date: 2017-08-17
Also published as: RU2761016C2; EP3414858A1; RU2019124262A; RU2019124262A3

Abstract

The present invention provides a method of performing an automatic repeat request mechanism in a mobile communication system, the method comprising sending user data from a first device to a second device over a logical channel and sending over a control channel an associated control message from a medium access control layer of the first device to a medium access control layer of the second device, the associated control message comprising a logical channel identifier for identifying the logical channel over which the user data is transmitted.

Description

Automatic Repeat Request Mechanisms

The present invention relates to a mechanism for sending repeat requests in a mobile communication network.

In UMTS and LTE two automatic repeat request (ARQ) mechanisms are used in different protocol layers. In the radio link control, RLC, layer, the mechanism is referred as "ARQ" and in the media access control, MAC, layer the mechanism is referred to as hybrid ARQ, HARQ. Both mechanisms are used to increase transmission reliability by providing feedback as to whether data transmitted has been received or whether a retransmission is necessary.

To date, the MAC-HARQ mechanism is always used for packet data transmission, with one HARQ entity per transport channel, i.e. usually one per device. The MAC-HARQ is configured per entity, i.e. per transport channel or one configuration per device.

The known RLC-ARQ is configurable depending on the required service, with one RLC- ARQ entity per logical channel, i.e. usually one per service (TCP-socket, application, or similar) and potentially multiple configurations per device. The RLC-ARQ is configured individually per logical channel, for example a maximum number of repeated

transmissions, a window size or timer (number of lost packets or time waited for before a newer packet is given to upper layers).

A comparison of both ARQ mechanisms shows that there are significant differences and it is considered to make sense to have both ARQ layers, despite the delay introduced by ARQ. The HARQ process is designed for fast feedback in a fixed relation of one

ACK NACK feedback for every transport block (TB), therefore no feedback polling is needed, the relation between feedback and data transmission is implicit, and

retransmissions come consecutively on the same process, so a relation between retransmissions and original data transmission is implicit. The HARQ uses an "n-channel- stop-and-wait" mechanism with the number n of channels (called "processes" in

UMTS/LTE) chosen so that a fluent transmission is possible, and retransmissions may contain different redundancy versions of the original data, the versions being provided by the PHY layer as a coding result.

In contrast, the RLC ARQ process is designed to allow for configuration of each RLC ARQ entity to match the logical channel delay and error rate requirements. Feedback and retransmissions are sent asynchronously so that packet numbering is required for reference in ACK/NACK feedback packets and in retransmission packets. Feedback is sent on request from the transmitter (poll) or autonomously by the receiver when it detects missing packets and packets (RLC PDUs) are transmitted and re-transmitted in their original version, as no redundancy versions are available in the RLC layer.

In general there are two design options for an ARQ mechanism depending on which side decides if and how data needs to be retransmitted or new data should be sent and how. If the receiver has control it requests the transmitter to (re-) transmit either old or new data and decides on the transmission parameters. A test whether a maximum number of retransmissions is exceeded and the choice of transmission parameters including redundancy versions, modulation, coding and resources to be used is done in the receiver and the selected parameters are fed back to the transmitting side to react accordingly. Receiver-based control of HARQ is applied, for example, in the uplink of an LTE system where the UE can be explicitly requested and the base station has control.

If the transmitter has control, the receiver needs to inform the transmitter about success of reception by sending feedback information in form of an ACK or NACK. The decision if (re-) transmission of old or new data takes place is done in the transmitter based on the feedback, on maximum number of re-transmissions and other parameters. The transmission parameters may be decided in the transmitter as well. Transmitter-based control of HARQ is applied, for example in the downlink of an LTE system where the UE sends ACK NACK feedback to the base station and the base station has control. Wireless transmission links are generally lossy to a certain degree. On a radio link that does not apply sequential delivery of packets in all cases, as is the case with multiple HARQ processes, in addition to loss, the order of packets can change, too. Typical services are very sensitive to packet re-ordering, therefore in-sequence delivery is applied in the RLC layer. A mechanism that detects and corrects packet re-ordering is required.

The principle is based on sequence numbers and packet buffering. To avoid stalling the transmission in case packets are lost a maximum time to wait is predefined. After the time expires the received packets waiting are delivered in-sequence to the higher layer with gaps for the lost packets. A maximum wait time can be realized with a maximum number of packets received while waiting. The predefined maximum wait time is thus an important parameter that influences the packet loss rate and the delay. ARQ and HARQ is described in detail in telecommunication standards and related text books. In the patent literature, US 8,072,981 describes a method of transmitting packet sequence numbers in parallel to actual data. Packets are provided with sequence numbers which are transmitted over a separate channel, for example a control channel or a dedicated channel with the data being transmitted via a shared traffic channel.

US 2009/0268707 A1 describes a HARQ mechanism in which a counter is signalled from a transmitter to a receiver to indicate how often a specific packet has been transmitted.

US 2008/0123660 A1 describes a system in which at the network side on the S1 interface between the eNode-B and the access gateway each packet is tagged with a QoS tag. The tag may be stripped off at the eNode-B and not transmitted to the UE. The eNode-B uses the information in the QoS tag to control the transmission of packets including HARQ process selection. The QoS tag is transmitted together with the packet in the same channel.

US 2007/0201369 A1 describes grouping logical flow channels by traffic priority to form an aggregate data flow which is then compared with a threshold value to obtain an indication value which is transmitted from a UE to a base station. The present invention provides a method of performing an automatic repeat request mechanism in a mobile communication system, the method comprising sending user data from a first device to a second device over a logical channel and sending over a control channel an associated control message from a medium access control layer of the first device to a medium access control layer of the second device, the associated control message comprising a logical channel identifier for identifying the logical channel over which the user data is transmitted.

The invention also provides the corresponding transmitter and receiver devices. The present invention is suitable as a design for a single ARQ entity for use in a next generation mobile communication system that replaces the currently used dual ARQ mechanisms "HARQ in MAC and "ARQ in RLC" i.e. to eliminate RLC-ARQ while introducing flexibility and service awareness into MAC-HARQ. This will increase the service reliability as the HARQ parameters could be adapted dynamically to the current needs of the service and reduce the transmission delay as the re-ordering process speeds up.

In one aspect of the invention a logical channel ID is transmitted with a sequence number separated from related user data and with increased reception robustness. The transmission of the logical channel ID allows to use service (QoS) specific HARQ- parameters. The separated transmission of the sequence number enables awareness for transmitted packets at the receiver even in case that the user data part of the transmission was not successfully received and therefore allows faster proceeding after a packet was discarded. There is no need for timer-based discard and the corresponding wait time that increases transmission delay. The invention provides an ARQ mechanism in the MAC layer that replaces the currently used dual ARQ concept with an ARQ on RLC layer and a HARQ on MAC layer.

The ARQ mechanism provides flexible ARQ parameters per service (i.e. per logical channel) so that configuration of delay and reliability according to QoS demands is possible. To enable a receiver-controlled HARQ that is logical channel aware, the logical channel associated with the data currently transmitted is indicated to the receiver. This indicated information is termed a logical channel identity (LogChID) that may have various physical appearances, discussed in more detail in the description of the preferred embodiments.

To enable a transmitter-controlled ARQ mechanism that is logical channel aware, no new signalling is necessary (as the transmitter has the knowledge which logical channel is transmitted). A feature is that the MAC-layer executes the ARQ mechanism dependant on the logical channel of the data to be transmitted, in particular whether to retransmit packets and which redundancy version to use is decided dependant on the logical channel.

Parameters influencing this decision may be configured via configuration protocols, e.g. by the network to the UE.

As indicated above, logical channels are typically established per user service and they have a related quality of service, QoS, setting. Therefore, "QoS" or "service" may _

alternatively replace the term "logical channel" and thus the signalling means described herein may signal logical channels (e.g. in form of a channel ID), QoS settings (in various forms like an index to a list of settings) or a Service (in various forms like an IP- Address/Port-Number pair or alike). Here, the term "logical channel" is used because the model goes in-line with the current UMTS and LTE architecture and is easy to read, but there is no restriction related to that wording.

To enable logical channel dependent functions in the receiver even if data has not been successfully received, the LogChID has to be received successfully. For bad link conditions this means a more reliable transmission of the LogChID compared to data transmission is desirable. Thus, the signalling of a LogChID is preferably done on a highly reliable control channel in parallel to the actual data transmission.

The LogChID transmission can use the same channel but different (preferably constant) coding that ensures the most reliable transport. However, different coding used in parallel constitutes a different channel in the usual model. As a new channel would deliver control data instead of actual user data, the LogChID should be delivered on a control channel. Alternative delivery mechanisms are not excluded but it is a feature of this invention to use highly reliable mechanisms different from those used for data transmission.

The number of bits needed to communicate the LogChID naturally increases as the number of possible logical channels increases. As the coding and modulation on a control channel is such that a most reliable transmission is ensured, each bit consumes a lot more physical resources than each bit of data on a data channel, thus LogChID signalling may be very expensive in terms of resources required. Therefore, a grouping of logical channels into groups of channels that have the same or similar QoS demands may reduce the number of signalling bits. A logical channel group and related logical channel group ID for signalling is already known from LTE for Buffer Status Reporting, e.g. the buffer status is reported once for the whole group of channels. The ID could be re-used or a new group ID can be used. In any case the grouping of logical channels would be configurable by the network with the knowledge of the QoS demand of logical channels.

As described above, the time to wait for lost packets is an important factor when the delay introduced by an ARQ mechanism should be reduced. Looking at the principles of the current HARQ mechanism the knowledge about delivery success or failure of a packet is available in the receiver, yet it is unused for discarding packets. The reason is that for packets not successfully received the header information within that packets cannot be read either and thus the sequence number of a packet finally not transmitted is unknown to the receiver. As a consequence, the receiver has to apply the abovementioned time to wait for the packet before discarding it and providing further packets to higher layer. It is thus a further aspect of this invention to deliver a packet identifier, e.g. in the form of a sequence number, on a separate control channel to allow the receiver to uniquely identify lost packets and thus flush a re-ordering buffer much faster than otherwise and thereby reduce overall delay significantly. In the case of receiver-controlled ARQ the fact that a packet is finally lost and cannot be retransmitted is defined by the receiver and thus known immediately after the last intended packet transmission has failed. In that case, taking a sequence number received on a control channel into account, information about the failure can be given to the reordering entity (RLC in LTE and UMTS) for immediate processing.

In the case of transmitter-controlled ARQ the fact that a packet is finally lost is not known to the receiver immediately after an intended packet transmission has failed, because only the transmitter defines whether the packet is retransmitted or not. There are possibilities for the receiver to make use of the sequence number of failed transmissions. Assuming a data packet is always retransmitted on the same HARQ-process in consecutive transmission attempts (as done in UMTS and LTE), a clear indication of final transmission failure can be derived from transmission of a different packet on the same process. So, after the last unsuccessful transmission of a packet the receiver feeds back a NACK and waits for the next packet to arrive on that process. If that is a packet with different

LogChID and/or sequence number than the one ACK'ed, the NACK'ed packet is declared lost and the re-ordering entity is informed.

To further reduce the delay on the link it is possible for the transmitter to mark a last transmission attempt of a packet on the control channel (e.g. as part of the sequence number information) so that the receiver can immediately declare the packet lost when the packet is not successfully received.

In one aspect of the invention, packet numbering is assumed per logical channel (as today in LTE and UMTS), therefore a sequence number received is only meaningful if the logical channel is known. Therefore, in conjunction with the sequence number signalling a signalling reduction of the LogChID into a logical channel group ID as proposed alternatively above is not feasible. Advantageously, a full LogChID signalling together with a signalling of a sequence number is performed.

Control channels in general are a sparse resource; therefore, means to reduce signalling are beneficial. In general, the length of a sequence number has to be long enough to allow a wide enough value range to differentiate all packets that can be on the way from the transmitter to the receiver in parallel while taking worst-case assumptions into account. For the mechanism described above for HARQ processing and logical channel identification on a control channel, a sequence number could be maintained on both sides (transmitter and receiver) without any explicit sequence number signalling simply by synchronously counting packets per logical channel including packets not successfully transmitted.

In real life, however, unforeseen failure cases happen, e.g. failure of delivery even on the control channel, and thus a synchronous counting mechanism without explicit

synchronization means is doomed to fail. As a trade-off between control channel resources and sequence number synchronization in one aspect of the invention a shorter piece of information derived from the sequence number, e.g. only a part of the sequence number is sent. As an example, the n least significant bits with n in the range of 2 to 5 can be sent. The receiver can derive the rest of the sequence number taking the history of received sequence numbers from the control channel into account assuming less that n consecutive transmission failures on a control channel.

In a further aspect of the invention, a control channel for ARQ related information like LogChID and sequence numbers is used. In particular, for the uplink, where most probably a receiver-controlled, i.e. base station controlled, HARQ is applied; the control channel resources need to be unambiguously mapped to respective data channel (shared channel) resources. The mapping can be explicit using additional signalling of the resource mapping or implicit with a fixed relation. The amount of resources needed for the proposed HARQ control signalling depends on the number of packets transmitted; therefore they may vary from transmission to transmission. Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Fig. 1 shows a prior art HARQ uplink architecture;

Fig. 2 shows a prior art HARQ downlink architecture;

Fig. 3 is a message sequence chart for a receiver controlled HARQ process;

Fig. 4 is an alternative message sequence chart of a receiver controlled HARQ process; Fig. 5 is a message sequence chart of a transmitter controlled HARQ process; and Fig. 6 is an alternative message sequence chart of a transmitter controlled HARQ process.

As a preliminary remark, it is to be noted that various embodiments of the current invention use a communication system with two entities, a mobile terminal, also termed user equipment, UE, and a base station, BS, connected via a cellular mobile

communication link. The layer 2 architecture model of both the UE and the BS are very similar to that depicted in the telecommunications standard 3GPP TS 36.300, figure 6-1 and the protocol stack is assumed to be as depicted in the same document, figure 4.3.1-1. The data transmission takes place on a single downlink and uplink shared channel (DL- SCH and UL-SCH, resp.) and control channels are available for DL (Physical Downlink Control Channel, PDCCH) and UL (Physical Uplink Control Channel, PUCCH) as in the TS 36.300, figure 5.3.1-1 and 5.3.1-2. An implicit mapping of PUCCH signalling to packets on a DL-SCH is assumed.

Fig. 1 shows a current uplink (UL) architecture and is used to illustrate various

embodiments of the invention. It is assumed that there are a number of logical channels, six in figure 1 , being offered by the MAC layer to the RLC. Over each of the logical channels service specific data arrives from higher layers on the UE side for the UL and the same data is transmitted at the respective logical channels on the base station (BS) side after successful transmission.

Data of multiple logical channels may be multiplexed by the MAC layer as described in state of the art taking logical channel priorities into account so that for example data of logical channels with higher priority is always transmitted before transmission of data of logical channels with lower priority takes place. The multiplexing results in one or more data streams that are transmitted to the physical layer, so called transport channels. Fig. 1 only shows one transport channel, the UL shared channel, but the invention is not so limited and may be used over multiple transport channels. Fig. 1 also does not show a clear mapping of functions to either MAC or physical layer as this is not relevant to the invention and may vary in different architectural models. The steps for implementing the invention take place in the MAC and/or the physical layer depending on implementation.

On the transport channel HARQ is applied which results in multiple HARQ processes, each running a stop-and-wait mechanism. The processes are mapped to a physical channel representing the actual physical resource in a strict time relation, indicated in Fig. 1 with a circular arrow. In Fig. 1 four HARQ processes are assumed for better readability although in real deployments the number of processes will probably be higher.

Also shown in Fig. 1 is a control channel (Physical Uplink Control Channel PUCCH) that can transmit HARQ control information in the UL in parallel to the shared channel. Fig. 2 is very similar to Fig. 1 showing architecture with the same assumptions but for the downlink, DL. It is not described in further detail here.

Describing now various embodiments with concrete message flows, we assume a setup configured with two logical channels (again to ease readability) with the following

LogChlD, priority, Services and QoS demands (PER indicating an acceptable packet error rate):

LogCHID Priority Service QoS demand

Data rate Max PER

delay

1 2 Browsing 1 MBps 300 ms Τθ³

2 1 i Voice over IP I 200 KBps 20 ms 10^-3

Logical channel 2 contains voice data only which typically appears in small packets that can be delivered as a single packet over the physical resource. Logical channel 1 contains browsing data that may consist of bigger packets that are segmented into packets of sizes that fit the available physical resources.

Fig. 3 shows a message sequence chart for a receiver-controlled HARQ process with two RLC entities for the two respective logical channels and a MAC layer for each entity (transmitter, receiver). The MAC layer is detailed so that four HARQ processes are shown, HARQ-P1 to HARQ-P4. Fig. 3 shows data for the lower priority logical channel to arrive at RLC1 and being segmented into multiple PDUs 1- 6; which are transmitted as transmit resources become available. Data for the higher priority logical channel 2 arrives during the timeline represented by Fig. 3 resulting in a single RLC PDU per data packet arrival without the need to segment the data. The HARQ processes P1 to P4 are executed consecutively and each transmission on the physical channel PUSCH is either positively (ACK) or negatively (NACK) acknowledged depending on a decoding result at the receiver. For each packet successfully received a feedback is sent that acknowledges the reception and indicates new data to be transmitted next on the respective process. Note that the ACK and the "new data indicator" may be transmitted together on the same channel or separate and they may be transmitted together with other information regarding the modulation and coding scheme and other transmit parameters to be used. Fig. 3 only contains the information relevant for this invention.

In case a packet has not been successfully received, a negative acknowledgement is fed back and a decision is done in the receiver as to whether the packet shall be retransmitted (and if so, which redundancy version of the packet shall be used) or new data shall be transmitted. Again, more parameters may be contained in the feedback and the NACK, the indication to retransmit or transmit new data and redundancy version may be sent on the same or different channels and any of the indications may be implicitly contained in any of the other indications. Fig. 3 also shows the transmission of a LogChID on a PUCCH resource in parallel to a data transmission. The LogChID is shown to be transmitted between the MAC entities (without specifying a process, just for readability and not restricting). A LogChID is transmitted in parallel to every packet transmitted on the PUSCH and is shown in Fig. 3 as a dashed line between the MAC entities.

With the knowledge of the logical channel of each packet, whether successfully received (indicated by a transmission line ending with an arrow head) or not (indicated by a transmission line terminating with a cross), the receiver is in a position to make a decision. In Fig. 3, after unsuccessful reception of PDU 1 of logical channel 1, a decision is made to retransmit the packet with an incremented redundancy version rv 1 , the decision point denoted D11 (in the figures, a redundancy version 0 is not specifically indicated for readability, PDUs without rv number are rvO). Only with the new signalling of the logical channel the receiver can make that decision based on the configuration for the specific service that uses logical channel 1.

At point D21 a similar decision is made for logical channel 2 after unsuccessful reception of PDU 1. The decision is based on the specific configuration of logical channel 2.

The difference in treatment of the logical channels becomes obvious in decision points D12 and D22: After the retransmission of PDU 1 of logical channel 1 is not received, it is decided at D12 to retransmit the packet again with incremented redundancy version (and again at D13); whereas at D22 for logical channel 2 it is decided to transmit new data despite the fact that PDU 1 has not yet been received. The decision at D22 has been made due to delay constraints of that logical channel.

The difference in performing the HARQ is possible with signalling of the logical channel on a control channel.

Fig. 4 shows a similar example; yet with the signalling of PDU sequence numbers in addition to LogChID on a control channel. As may be seen, after an unsuccessful reception of the retransmission of PDU 1 of logical channel 2 in redundancy version 1 , the receiver can indicate the PDU 1 immediately as being finally lost after the logical channel dependant decision not to retransmit the packet again. This is possible as a result of the control channel signalling of logical channel and sequence number.

After successful reception of PDU 2 of logical channel 2 shortly after, the RLC layer can deliver the resulting data without delaying it while waiting for PDU 1 to be received or a timer to expire. Thus the delay has been significantly reduced with the new signalling.

Figs. 5 and 6 show again a similar example with the difference that the HARQ mechanism is transmitter-controlled and only ACK or NACK are fed back from receiver to transmitter. At decision point D11 it is decided to retransmit PDU 1 of logical channel 1 and similar at D21 for logical channel 2. The decisions are made based on the knowledge of the logical channel and its configuration regarding the QoS demand of the respective service. At D12 again a decision is made to retransmit PDU 1 of logical channel 1 with a new redundancy version whereas at D22 it is decided not to retransmit PDU 1 of logical channel 2 due to delay constraints of that logical channel. Now, it takes up to transmission of the next (new) packet on HARQ process 3 to realize at the receiver that no further attempt is made to transmit PDU 1 of logical channel 2. After RLC is informed about final discard of PDU 1 the RLC layer will deliver PDU 2 that has been received and buffered before. As clear from figure 5, the delay has been reduced significantly compared to a timer on RLC level waiting for PDU 1 after PDU 2 has been received.

However, indicating that a transmission on the control channel is the last attempt for that PDU can reduce the delay further. As a result that PDU can be discarded immediately after unsuccessful reception of the PDU. This is shown in figure 6 with the otherwise unchanged example.

Alternative embodiments will now be described. Redundant signalling may be introduced. The LogChID and sequence number signalling on a control channel may be performed in addition to the known signalling of the same information in a AC-header that is added to each packet transmitted. In that case a redundant control information transmission could further increase transmission reliability for this information.

If means are applied to reduce the signalling amount on the control channel, e.g. logical channel group signalling or a reduced signalling of the sequence number, a redundant inclusion of the information in a MAC-header may be used by the receiver to verify calculated sequence numbers or received logical channel groups and detect errors.

On the other hand, the new signalling on the control channel can replace the signalling in the MAC-header, thereby reducing the data volume on the shared channel.

The sequence number may be reduced. As mention before, means for reduced or no signalling of sequence numbers may be applied to reduce signalling on the control channel. This may be implemented as follows.

The receiver maintains a variable that indicates the highest received sequence number, MAX-R-SN_n , for each logical channel n that is initialized to zero. The receiver maintains a variable that indicates the currently received sequence number, PRO-R-SN_p , for each HARQ process p. When new data (not a retransmission) is indicated to be transmitted on HARQ process a for logical channel k, then MAX-R-SN_k is incremented and PRO-R-SN_a is set to MAX-R-SN_k

When a packet is successfully received on process a, is PRO-R-SN_a is considered the sequence number for that packet. When a packet transmission is detected to be finally unsuccessfully on process a, PRO-R-SN_a is considered the sequence number of the lost packet and the re-ordering entity is informed correspondingly. The final loss of the packet may be explicitly signalled as "last attempt", or explicit indication of new data on that process may indicate loss of the previous packet on that process, or the decision to discard the packet may be done in the receiver.

As a synchronization mechanism, a part of the sequence number may be explicitly transmitted on the control channel or in the MAC-header or both. A comparison of the received part of the sequence number and the calculated sequence number takes place.

If both match, the transmitting and receiving side of the HARQ mechanism are considered in sync. If there is mismatch, the received sequence numbers are used to correct the calculation as follows: the MAC is reset on both side, a full transmission of sequence numbers is triggered, and the calculation is simply reset to the values received.

The size of the sequence number signalling, e.g. the number of least significant bits, may be variable: it can be increased (up to a max) for every detected loss of synchronization and it can be decreased (down to a miri) for a number of packets being in-sync. The principles of the present invention have been described to work with a synchronous HARQ process in which ACK/NACK and other feedback is transmitted in a strict time relation to the original data and retransmissions are sent on the same process. This should not restrict the functionality of logical channel and/or sequence number signalling. The new functionality even provides packet identifications that could be re-used to change the HARQ mechanisms. A selective-repeat HARQ could be used with MAC-HARQ by providing sequence numbers and LogChID with ACK/NACK. This would eliminate the necessity to maintain HARQ processes, a linear transmission of packets could be used. Asynchronous retransmission could be allowed, i.e. retransmission could occur on any HARQ process (only with explicit sequence number transmission). While the invention concerns the removal of ARQ functionality from the RLC layer, the RLC layer may still perform the functions of buffering, re-ordering, and segmentation and re-assembly.

Claims

1. A method of performing an automatic repeat request mechanism in a mobile communication system, the method comprising sending user data from a first device to a second device over a logical channel and sending over a control channel an associated control message from a medium access control layer of the first device to a medium access control layer of the second device, the associated control message comprising a logical channel identifier for identifying the logical channel over which the user data is transmitted.

2. The method of claim 1 further comprising the second device in response to a received associated control message sending a second control message comprising either an acknowledgement, ACK, of receipt of the associated user data or a negative acknowledgement, NACK, of receipt of the associated user data to the first device.

3. The method of claim 2, wherein the second device sends the second control message to the first device using a control channel corresponding to the logical channel used by the first device to send the user data.

4. The method of any preceding claim, wherein the control channel is a physical channel different from a shared physical channel used to transmit the user data over the logical channel.

5. The method of claim 4, wherein the associated control message is transmitted in parallel with the user data.

6. The method of any preceding claim, wherein in addition to the logical channel identifier, the associated control message comprises a sequence number.

7. The method according to any preceding claim, wherein the second device controls retransmission of the user data and/or transmission of new user data.

8. The method of any one of claims 1 to 6, wherein the first device controls retransmission of the user data and/or transmission of new user data.

9. The method according to any one of claims 1 to 3 wherein the control channel uses a different coding scheme to that of the logical channel to provide more reliable data transmission.

10. A transmitter device for transmitting user data to a receiver, the transmitter device being arranged to transmit a packet of user data over a logical channel to the receiver and to transmit over a control channel an associated control message from a medium access control layer of the transmitter device to a medium access control layer of the receiver, the associated control message comprising a logical channel identifier for identifying the logical channel over which the user data packet is transmitted.

11. A receiver for receiving over a logical channel a packet of user data from a transmitting device according to claim 10 and for receiving at a medium access control layer of the receiver an associated control message transmitted over a control channel, the associated control message comprising a logical channel identifier, wherein the receiver is arranged to process the associated control message to create an

acknowledgement message indicating whether the packet of user data has been received successfully or not.