RU2761016C2 - Automatic repeat request mechanisms - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to information technology and namely to a mechanism for sending repeat requests in a mobile network. Disclosed is a method for using an automatic repeat request mechanism in a mobile communication system. The method includes sending user data from the first device to the second device via a logical channel and sending a corresponding control message from a medium access control level of the first device to a medium access control level of the second device via a control channel. The method further includes the following actions of the second device in response to the received corresponding control message: sending the second control message to the first device including an acknowledgment (ACK) of the receipt of the corresponding user data or a negative acknowledgment (NACK) of the receipt of the corresponding user data and determining the quality of service for the logical channel based on the configuration and sending a specific request to the first device.

EFFECT: invention increases the reliability of the transmission of requests.

9 cl, 1 tbl, 6 dwg

Description

Technology area

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

State of the art

UMTS and LTE systems use two Automatic Repeat reQuest (ARQ) mechanisms at different protocol layers. At the radio link control (RLC) level, this mechanism is referred to as ARQ, and at the media access control (MAC) level, as hybrid ARQ (HARQ, Hybrid ARQ). Both mechanisms are used to improve the reliability of the transmission by providing feedback on whether the transmitted data has been received or whether it needs to be retransmitted.

Today, the MAC-HARQ mechanism is always used for packet data transmission, with one HARQ entity per transport channel, that is, there is usually one entity per device. The MAC-HARQ mechanism is configurable per entity (per transport channel), that is, there is one configuration per device.

The prior art RLC-ARQ mechanism is configured depending on the required service, while using one RLC-ARQ mechanism object per logical channel, that is, usually one object per service or type of service (for example, TCP socket, application, etc.). and there are potentially multiple configurations per device. The RLC-ARQ mechanism is configured individually for each logical channel. For example, it is configurable, the maximum number of retransmissions, the window size or timer (the number of lost packets or the time to wait before sending a new packet to the upper layers).

A comparison of the two ARQ mechanisms shows that there are significant differences between them, and it is considered advisable to have both ARQ layers, despite the delay introduced by the ARQ mechanisms. The HARQ process is designed for fast feedback. In this case, there is a fixed ratio - one ACK / NACK feedback per Transport Block (TB), In this case, feedback polling is not required, the relationship between feedback and data transmission is implicit, and retransmissions occur sequentially in the same process. Therefore, the relationship between retransmissions and the original data transmission is also implicit. The HARQ mechanism uses an "n-channel-stop-and-wait" mechanism, where the number of channels n (in UMTS / LTE systems they are called "processes") are chosen to allow uninterrupted transmission, and retransmissions may contain different versions of the redundancy of the original data, while these versions are implemented by the PHY layer (physical layer) as a result of the encoding.

In contrast, the RLC-ARQ process is designed to allow the configuration of each RLC-ARQ mechanism entity to meet the logical channel delay and error rate requirements. Feedback and retransmissions are sent asynchronously, so packet numbering is required for ACK / NACK feedback packets and retransmission packets to match. Feedback is sent on request from the transmitter (when polling) or autonomously by the receiver if it detects missing packets, while the packets (RLC PDUs) are transmitted and retransmitted in their original version, since there is no implementation of redundancy versions at the RLC level.

In general, there are two options for implementing the ARQ mechanism, depending on which side decides whether to retransmit data and how to do it or send new data and how to do it. If the receiver is in control, it requests the transmitter to send new data (or retransmit old data) and decides on the transmission parameters. Checking whether the maximum number of retransmissions has been exceeded, as well as the selection of transmission parameters, including redundancy version, modulation, coding and resources used, are performed at the receiver, and the selected parameters are transmitted to the transmitting side for an appropriate response. Receiver-side HARQ control is applied, for example, in the LTE uplink, where a User Equipment (UE) can be explicitly requested and control is performed by a base station.

If the transmitter is in control, the receiver should inform it of successful reception by sending feedback information in the form of ACK or NACK signals. The decision to perform the transmission of new data (or retransmission of old data) is made at the transmitter based on the feedback, the maximum number of retransmissions, and other parameters. The transmission parameters can also be set by the transmitter. The transmitter-side HARQ control is applied, for example, in the LTE downlink, where the UE sends ACK / NACK feedback to the base station and the base station takes control.

Wireless transmission lines generally have some loss. In a radio link that does not use sequential packet delivery in all cases, as is provided, for example, in a link with multiple HARQ processes, in addition to losses, packet reordering can also occur. Typical services are very sensitive to packet reordering, so sequential delivery is applied at the RLC layer. This requires a mechanism to detect and correct packet reordering.

Its principle of operation is based on sequence numbers and on packet buffering. To avoid transmission stalls in the event of packet loss, the maximum latency is predefined. After this time, pending received packets are sequentially delivered to the upper layer. However, there are gaps for lost packets.

The maximum latency can be achieved with the maximum number of packets received during latency. Thus, a predetermined maximum latency is an important parameter affecting the packet loss rate and latency.

The ARQ and HARQ mechanisms are detailed in telecommunication standards and related textbooks. US Pat. No. 8,072,981 describes a method for transmitting packet sequence numbers in parallel with actual data. Packets are provided with sequence numbers, which are transmitted over a separate channel, for example, a control channel or a dedicated channel, and data is transmitted over a common traffic channel.

US 20090268707 A1 describes a HARQ mechanism in which a transmitter reports counter readings to a receiver to indicate how often a particular packet has been transmitted.

US 20080123660 A1 describes a system in which, on the network side, at the S1 interface between the eNode-B and the access gateway, each packet is labeled with a Quality of Service (QoS) label. This mark may be removed by the eNode-B and not transmitted to the UE. The eNode-B uses the information from the QoS label to control packet transmission, which includes the selection of the HARQ process. The QoS tag is sent along with the packet on the same channel.

US 20070201369 A1 describes the grouping of logical flow channels by traffic priority to form a combined data flow, which is then compared with a threshold value to obtain an indicator value transmitted by the UE to the base station.

Disclosure of invention

The invention provides a method for implementing an automatic repeat request mechanism in a mobile communication system, including sending user data from a first device to a second device over a logical channel and sending a corresponding control message from the medium access control layer of the first device to the medium access control layer of the second device through the control channel. This control message includes a logical channel identifier for identifying a logical channel on which user data is transmitted.

The invention also provides suitable transmitter and receiver devices.

The present invention is suitable for application in the next generation mobile communication system as a solution using a single ARQ entity replacing the currently duplicated ARQ mechanisms: "MAC HARQ" and "RLC ARQ". This eliminates the RLC-ARQ mechanism and provides the MAC-HARQ mechanism with flexibility and service awareness, which improves service reliability as HARQ parameters can dynamically adapt to current service needs, and also reduces transmission delay as the packet reordering process is accelerated.

In one aspect of the invention, the logical channel identifier is transmitted with a sequence number separated from the corresponding user data and with improved reception stability. The transmission of the logical channel identifier allows the use of the parameters of the HARQ mechanism depending on the service (from QoS). Separate transmission of the sequence number ensures that the receiver is aware of the transmitted packets even if the part of the transmission related to user data has not been successfully received, which ensures a quick continuation of work after the packet is discarded. There is no need for timer drops and corresponding latency increases transmission latency.

The invention provides ARQ at the MAC layer, replacing the current dual ARQ concept of ARQ at the RLC and HARQ at the MAC.

The ARQ mechanism provides the flexibility to assign ARQ parameters to each service (ie, to each logical channel), so that it becomes possible to adjust latency and reliability to meet QoS requirements. To implement a receiver-driven logical channel-aware HARQ mechanism, a logical channel associated with the data currently being transmitted is indicated to the receiver. This indication is referred to as a Logical Channel ID (LogChID), which can take various physical forms, discussed in more detail in the description of the preferred embodiments.

No new signaling is required to implement a transmitter-controlled logical channel-aware ARQ mechanism (since the transmitter knows which logical channel is being transmitted).

The peculiarity is that the MAC layer performs the ARQ mechanism depending on the logical channel of the data to be transmitted. For example, it is up to the logical channel to decide whether to retransmit packets and which version of redundancy to choose. Parameters influencing this decision can be set via configuration protocols, for example, at the UE over the network.

As stated above, logical channels are usually set up for each service for a user and have a corresponding quality of service (QoS). For this reason, the terms "QoS" or "service" may alternatively replace the term "logical channel". Thus, the signaling tools described in this document can report logical channels (for example, in the form of a channel identifier), quality of service settings (in various forms, for example, in the form of a pointer to a list of settings) or a service (in various forms , for example, in the form of a pair of IP address and port number, etc.). Here, the term "logical channel" is used because of its readability and also because the logical channel paradigm is consistent with the current architecture of UMTS and LTE systems. However, this wording does not impose any restrictions.

In order to implement logical channel dependent functions in the receiver, even if the data was not successfully received, the logical channel identifier LogChID must be successfully obtained. In the case of poor link conditions, this means that a more reliable transmission of the LogChID is desirable compared to the transmission of data. Thus, the signaling of the LogChID is preferably carried out over a highly reliable control channel in parallel with the transmission of the actual data.

In this case, the channel itself used to transmit the LogChID identifier can be the same, but with a different (preferably constant) coding that provides the most reliable transmission. However, in the conventional model, a different coding used in parallel means a different channel. Since such a new channel delivers control data instead of the actual user data, the LogChID can be said to be delivered over the control channel. Alternative delivery mechanisms are not excluded, but the hallmark of the present invention is the use of highly reliable mechanisms other than those used for data transmission.

Obviously, the number of bits required to transmit the LogChID increases as the number of possible logical channels increases. Since the coding and modulation on the control channel must provide the most reliable transmission, each bit consumes much more physical resources than each data bit on the data channel, so signaling the LogChID can be very expensive in terms of resource consumption. Therefore, grouping logical channels having the same or similar quality of service requirements into channel groups can reduce the number of signaling bits. The logical channel group and the corresponding logical channel group ID for signaling are already known to the LTE system from the Buffer Status Reporting. For example, the buffer status is reported at one time for the entire channel group. You can reuse this ID or use a new group ID. In either case, the logical channel grouping can be configured by the network based on the QoS requirements for the logical channels.

As described above, the latency for lost packets is an important factor if you want to reduce the delay introduced by the ARQ mechanism. The principles of the current HARQ mechanism are that the successful / non-delivery information is available at the receiver, but is not used to discard the packets. The reason for this is that for packets that were not successfully received, the header information within those packets also cannot be read, and thus the receiver does not know the sequence number of the packet that was ultimately not transmitted. As a consequence, the receiver MUST use the aforementioned time to wait for a packet before discarding it and transmitting the rest of the packets to a higher layer.

Thus, another aspect of this invention is the delivery of the packet identifier, for example, in the form of a sequence number, on a separate control channel to allow the receiver to uniquely identify the lost packets and thus flush the reordering buffer much faster and thereby significantly reduce the overall latency. ...

In the case of a receiver-driven ARQ mechanism, the fact that a packet is permanently lost and cannot be retransmitted is determined by the receiver and is thus known immediately after the intended last transmission of the packet has failed. In this case, taking into account the sequence number received on the control channel, information about this failure can be transmitted to the reordering entity (at the RLC level in LTE and UMTS systems) for immediate processing.

In the case of a transmitter-controlled ARQ mechanism, the fact that the packet is finally lost is not known to the receiver immediately after the intended transmission of the packet fails, since only the transmitter determines whether the packet is to be retransmitted. In this case, the receiver can use the sequence number of the failed transmissions. Assuming that successive transmission attempts always retransmit a data packet in the same HARQ process (as is done in UMTS and LTE systems), it is possible to get a clear indication of the final transmission failure when transmitting another packet in the same process. Thus, after the last unsuccessful packet transmission, the receiver sends a negative acknowledgment NACK and waits for the next packet in this process. If the next packet has a different LogChID and / or a different sequence number than the packet to which the NACK belongs, then the packet to which the NACK belongs is declared lost, and the reordering entity is informed of this.

To further reduce link latency, the transmitter can mark the last packet transmission attempt on the control channel (eg, as part of the sequence number information) so that if the packet is not successfully received, the receiver can immediately declare the packet lost.

In one aspect of the invention, packet numbering is assumed for each logical channel (as currently in LTE and UMTS systems), so the resulting sequence number is meaningful only when the logical channel is known. Therefore, signaling the LogChID in combination with signaling the sequence number in the logical channel group identifier ID, as suggested above, is impractical. Advantageously, full signaling of the LogChID is performed along with signaling of the sequence number.

Control channels are, in general, a scarce resource, hence means to reduce signaling are useful. As a rule, the length of the sequence number should be sufficient to provide a sufficiently wide range of its values and to distinguish all packets that may be in parallel on the path from the transmitter to the receiver, based on the worst assumption.

In the mechanism described above for HARQ processing and logical channel identification in the control channel, the sequence number can be maintained on both sides (both the transmitter and the receiver) without any explicit signaling of the sequence number, but simply by synchronously counting packets in each logical channel, including those packets that were not successfully transmitted.

However, in real life, unexpected failures do occur, such as a delivery failure even on the control channel. Thus, in a synchronous counting mechanism without an explicit means of synchronization, failure is inevitable.

In one aspect of the invention, a shorter piece of information derived from the sequence number is used as a tradeoff between control channel resources and sequence number synchronization. For example, only part of the sequence number is sent. In particular, n least significant bits may be sent, with n in the range 2 to 5. The receiver may determine the remainder of the sequence number by taking into account the history of sequence numbers received on the control channel and assuming that the number of consecutive transmission failures on the control channel is less than n .

In another aspect of the invention, the control channel is used for information related to the ARQ mechanism, such as the LogChID and sequence numbers. In particular, for an uplink that employs the HARQ mechanism, which is likely to be controlled by the receiver (i.e., the base station), the resources of the control channel must be uniquely mapped to the resources of the corresponding data channel (common channel). This mapping can be explicit, using additional resource mapping signaling, or implicit, with a fixed ratio.

The amount of resources required for the proposed HARQ control signaling depends on the number of packets transmitted, so it can vary from transmission to transmission.

Brief Description of Drawings

In the following, by way of example only, preferred embodiments of the invention are described with reference to the accompanying drawings.

FIG. 1 shows the architecture of the prior art uplink HARQ mechanism.

FIG. 2 shows the architecture of a downlink HARQ mechanism in the prior art.

FIG. 3 shows a message sequence for a receiver-driven HARQ process.

FIG. 4 shows an alternative message sequence for a receiver-driven HARQ process.

FIG. 5 shows a message sequence for a transmitter-controlled HARQ process.

FIG. 6 shows an alternate message sequence for a transmitter-controlled HARQ process.

Implementation of the invention

As a preliminary note, various embodiments of the present invention utilize a two-entity communication system with a mobile terminal, also referred to as a user device (UE), and a base station (BS), which are connected by a cellular mobile communication line. The Layer 2 architectural model for both the UE and BS is very similar to the model presented in the telecommunications standard 3GPP TS 36.300 in Fig. 6-1, and the protocol stack is as shown in the same document in Fig. 4.3.1-1.

Data transmission occurs on one downlink and uplink common channel (DL-SCH and UL-SCH, respectively). Control channels are available for the downlink (Physical Downlink Control Channel, PDCCH) and for the uplink (Physical Uplink Control Channel, PUCCH) as shown in TS 36.300 in Fig. 1-1 and fig. 5.3.1-2. Implicit mapping of PUCCH signaling to packets on the DL-SCH is assumed.

FIG. 1 shows the current prior art uplink (UL) architecture. It is used to illustrate various embodiments of the invention. It is assumed that there are a number of logical channels (there are six in FIG. 1) offered by the MAC layer for the RLC layer. In the case of a UL channel on each of the logical channels, service-specific data comes from the upper layers on the UE side, and the same data is transmitted on the corresponding logical channels on the BS side after it has been successfully transmitted.

Multiple logical channel data can be multiplexed at the MAC layer as described in the prior art, taking into account the priorities of the logical channels such that, for example, high priority logical channel data is always transmitted before low priority logical channel data is transmitted. Multiplexing results in one or more data streams that are transmitted to the physical layer, these are the so-called transport channels. FIG. 1 shows only one transport channel, the UL common channel, but the invention is not limited to this and can be used on multiple transport channels. FIG. 1 also does not show a clear mapping of functions to either the MAC layer or the physical layer, since this is not relevant to the invention and may vary in different architectural models. The steps of the implementation of the invention occur at the MAC and / or physical layer, depending on the implementation.

The transport channel uses the HARQ mechanism, which results in multiple HARQ processes, each of which performs a stop-and-wait mechanism. Processes are mapped to the physical channel, which is the actual physical resource, in the strict timing shown in FIG. 1 circular arrow. FIG. 1, for simplicity, it is assumed that there are four HARQ processes; nevertheless, in real conditions, the number of processes can be

FIG. 1 also shows a Physical Uplink Control Channel (PUCCH) that can transmit HARQ mechanism control information in the UL uplink in parallel with a common channel.

FIG. 2, which is very similar to FIG. 1, the architecture is shown with the same assumptions but for the DL downlink. It is not described in detail here.

Various embodiments with specific message streams are described below, assuming a dual logical channel configuration (for simplicity) with the following parameters: LogChID, priority, services and quality of service requirements (PER (Packet Error Rate) parameter denotes acceptable error rate for packet transfer).

LogChID Priority Service QoS requirement Baud rate Maximum latency PER one 2 Browsing (Internet) 1 MB / s 300 ms 10 ^-9 2 one Voice over IP 200 KB / s 20 ms 10 ^-3

Logical channel 2 contains only voice data, usually appearing as small packets that can be delivered as a single packet using a physical resource. Logical channel 1 contains browsing (Internet) data, which can be composed of large packets, segmented into packets sized to match the available physical resources.

FIG. 3 shows a message sequence for a receiver-driven HARQ process with two RLC entities for two corresponding logical channels and with a MAC layer for each entity (transmitter, receiver). For the MAC layer, four HARQ processes are shown, HARQ-P1 to HARQ-P4.

FIG. 3 shows data for a low priority logical channel, which is fed to the RLC1 layer and further segmented into several PDUs 1 to PDU 6, and which is transmitted when transmission resources become available. Data for logical channel 2 with high priority is provided in the sequence shown in FIG. 3, which results in one RLC PDU for each data packet arrival, without the need for data segmentation. The HARQ-P1-HARQ-P4 processes are performed sequentially and each physical PUSCH transmission is acknowledged either positively (ACK) or negatively (NACK), depending on the decoding result at the receiver.

For each successfully received packet, feedback is sent confirming its receipt and indicating new data that must be transmitted further in the corresponding process. It should be noted that the ACK signal and the "new data indicator" can be transmitted together on the same channel or separately, and they can be transmitted along with other information regarding the modulation and coding scheme and other used transmission parameters. FIG. 3 provides only information pertaining to this invention.

If the packet was not successfully received, then a negative acknowledgment is sent and the receiver decides whether this packet should be retransmitted (and if so, which version of redundancy for this packet should be used), or new ones should be sent. data. It should be noted again that the feedback can contain more parameters, while the NACK signal, an indication of retransmission or transmission of new data and a redundancy version can be sent in one or in different channels, and any of these indications can be implicitly contained in any of other indications.

FIG. 3 also shows the transmission of the LogChID using the PUCCH resource in parallel with the transmission of data. The LogChID is shown to be passed between MAC layer entities (no process specified for simplicity and not to limit the invention). The LogChID transmitted in parallel with each packet on the PUSCH is shown in FIG. 3 as a dashed line between MAC entities.

With the knowledge of the logical channel of each packet, whether it was successfully received (indicated by a transmission line with an arrow) or not (indicated by a transmission line with a cross), the receiver can make a decision. FIG. 3, after unsuccessful reception of PDU 1 of logical channel 1, it is decided to retransmit the packet with increased version of redundancy (rv1), the decision point is denoted as D11. For readability purposes, redundancy version 0 is not specifically indicated in the drawings, and PDUs without a redundancy version number are PDUs with redundancy version rv0. Only with new logical channel signaling, the receiver can make this decision based on the configuration for a particular service using logical channel 1.

At D21, a similar decision was made for logical channel 2 after the PDU 1 was unsuccessfully received. The decision is based on the specific configuration of logical channel 2.

The difference in logical channel processing becomes apparent at decision points D12 and D22. In particular, after the retransmission of PDU 1 of logical channel 1 is not received, at point D12 it is decided to retransmit the packet with an increased version of redundancy (and the same at point D13); and at point D22, for logical channel 2, it is decided to transmit new data even though PDU 1 has not yet been received. The decision at D22 was made due to latency constraints on this logical channel.

This difference in the implementation of the HARQ mechanism is possible when signaling a logical channel on the control channel.

FIG. 4 shows a similar example, but signaling PDU sequence numbers in addition to the LogChID on the control channel. As can be seen, upon unsuccessful reception of a retransmission of logical channel 2 PDU 1 with redundancy version rv1, the receiver can immediately indicate PDU 1 as permanently lost after deciding not to retransmit the packet again, given the logical channel assignment. This is possible by using signaling on the control channel to indicate the logical channel and sequence number.

Shortly after successful reception of logical channel 2 PDU 2, the RLC layer can deliver the resulting data without delaying it waiting for PDU 1 to be received or waiting for a timer to expire. Thus, with the new signaling, the latency is significantly reduced.

FIG. 5 and FIG. 6 shows a similar example with the difference that the HARQ mechanism is controlled by the transmitter, and the ACK or NACK signals are sent as feedback from the receiver to the transmitter. At D11, a decision was made to retransmit PDU 1 for logical channel 1, at D21, a similar decision was made for logical channel 2. Decisions are made based on knowledge of the logical channel and its configuration regarding the QoS requirements for the corresponding service. D12 also decides to retransmit logical channel 1 PDU 1 with a new version of redundancy, and D22 decides not to retransmit logical channel 2 PDU 1 due to latency constraints on that logical channel.

The transmission of the next (new) packet in the HARQ-P3 process is now required in order for the receiver to understand that there will be no further attempts to transmit PDU 1 of logical channel 2. After the RLC layer is informed of the final discard of PDU 1, the RLC layer delivers PDU 2 that was previously received and buffered. As seen in FIG. 5, the latency has been significantly reduced compared to using the RLC layer timer waiting for PDU 1 after receiving PDU 2.

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

Alternative embodiments are described below.

Redundant alarms can be introduced. Signaling of the LogChID and sequence number on the control channel can be performed in addition to the known signaling of the same information in the MAC header that is appended to each transmitted packet. In this case, redundant transmission of control information can further improve the reliability of transmission of this information.

If means are used to reduce the amount of signaling on the control channel, such as group signaling of logical channels or abbreviated signaling of the sequence number, then the redundant inclusion of information in the MAC header can be used by the receiver to check the calculated sequence numbers or received logical channel groups and to detect errors.

On the other hand, new signaling on the control channel can replace the signaling in the MAC header and thus reduce the amount of data on the common channel.

The length of the sequence number can be reduced. As previously mentioned, means for reducing the amount of signaling of sequence numbers or eliminating it altogether can be used to reduce the amount of signaling on the control channel. This can be done as follows.

The receiver stores a variable that indicates the highest received sequence number, MAX-R-SN _n, for each logical channel n , which is initially zero. The receiver stores a variable indicating the currently received PRO-R-SN _p sequence number for each HARQ process p . When it is indicated that new data (not repeated data) is transmitted in the HARQ process a for logical channel k , then the MAX-R-SN _{k is} incremented and the PRO-R-SN _{a is} set to MAX-R-SN _k .

When a packet is successfully received in process a , the PRO-R-SN of _{a is} considered the sequence number of that packet. If it is found that the transmission of a packet in process a finally fails, the PRO-R-SN number _{a is} considered the sequence number of the lost packet, and the reordering entity is informed of this. Final packet loss may be explicitly indicated as "last attempt", or the loss of a previous packet in a particular process may be indicated by an explicit indication of new data being transmitted in that process, or the receiver may decide to discard the packet.

From the point of view of the synchronization mechanism, part of the sequence number can be explicitly transmitted in the control channel or in the MAC header, or both. Next, a comparison is made between the obtained part of the serial number and the calculated serial number.

If there is a match, the transmitting and receiving sides of the HARQ mechanism are considered synchronized. If there is a mismatch, the obtained sequence numbers are used to correct the computation as follows: the MAC level is cleared on both sides, a full transmission of the sequence numbers is started, and the result of the computation is simply assumed equal to the received values.

The amount of signaling of the sequence number, for example, the number of least significant bits, can be variable: it can be increased (up to a maximum) for each detected loss of synchronization, and can be reduced (down to a minimum) if a certain number of packets remain in synchronization.

The principles of the present invention are described in relation to a synchronous HARQ process, in which ACK / NACK signals and other feedback are sent in strict timing with the original data, and retransmissions are sent in the same process. This should not limit the functionality of logical channel and / or sequence number signaling. The new functionality even provides packet identification, which can be used to modify HARQ mechanisms. Selective repetition HARQ can be used with MAC-HARQ using sequence numbers and LogChID with ACK / NACK signals. This eliminates the need to support HARQ processes and allows linear packet transmission. In this case, asynchronous retransmission can be allowed, that is, the retransmission can occur in any HARQ process (but only with the explicit transmission of the sequence number).

Although the invention relates to the removal of ARQ functions from the RLC layer, the RLC layer can still perform buffering, reordering, segmentation, and reassembly functions.

Claims (11)

1. A method for implementing an automatic repeat request mechanism in a mobile communication system, including sending user data from a first device to a second device via a logical channel and sending a corresponding control message from the medium access control level of the first device to the medium access control level of the second device over a control channel, wherein the corresponding control message includes a logical channel identifier for identifying a logical channel over which user data is transmitted, the second device has a stored quality of service configuration for the logical channel, and the method further includes the following actions of the second device in response to corresponding control message received: - sending to the first device a second control message including an acknowledgment (ACK) of the receipt of the corresponding user data or a negative acknowledgment (NACK) of the receipt of the corresponding user data; and - determining, based on the configuration of the quality of service for the logical channel, identified by the logical channel identifier contained in the received corresponding control message, whether to request retransmission of user data or to request the transmission of new user data on the logical channel from the first device, and send a specific request into the first device. 2. The method according to claim 1, characterized in that in the event that it is determined that the second device should request the transmission of new user data over the logical channel in response to the received corresponding control message, the medium access control layer of the second device informs the higher layer protocol of the second device to permanently discard the current user data. 3. The method according to claim. 2, characterized in that for sending the second control message from the second device to the first device, a control channel is used corresponding to the logical channel used to send user data from the first device. 4. A method as claimed in any preceding claim, wherein the control channel is a different physical channel from the common physical channel used to transmit user data over the logical channel. 5. The method according to claim 4, characterized in that the corresponding control message is transmitted in parallel with the user data. 6. A method according to any preceding claim, wherein the corresponding control message includes a sequence number in addition to the logical channel identifier. 7. A method according to any one of claims. 1-3, characterized in that to ensure more reliable data transmission in the control channel, a coding scheme is used that is different from the coding scheme of the logical channel. 8. A transmitting device for transmitting user data to a receiver over a logical channel multiplexed with other logical channels in relation to an automatic repeat request (ARQ) object of a medium access control layer, configured to transmit a user data packet to a receiver over a logical channel and transmit the corresponding a control message from the medium access control layer of the transmitting device to the medium access control layer of the receiver via the control channel, wherein the corresponding control message includes a logical channel identifier for identifying the logical channel over which the user data packet is transmitted, and the transmitting device has a saved configuration quality of service for the logical user data channel and is configured in response to the received second control message containing a negative acknowledgment (NACK) of the receipt of the user data packet sent by by the transmitting device, based on the QoS configuration for the logical channel of user data, whether to request retransmission of user data or to request transmission of new user data on the logical channel. 9. A receiver designed to receive on a logical channel a user data packet from a transmitting device described in clause 8, and to receive at the media access control level of the receiver a corresponding control message transmitted over a control channel and including a logical channel identifier, when the receiver has a saved configuration of the logical channel quality of service, and is also configured to process the corresponding control message to generate an acknowledgment message indicating whether the user data packet was successfully received or not, determining based on the quality of service configuration for the logical channel identified by the logical channel identifier, whether to request retransmission of user data or to request transmission of new user data over a logical channel from the transmitter, and send a specific request to the transmitter.

Images