Tag Archives: HARQ

IMTx: NET02x (4G Network Essentials) – Radio Interface – 4. Transmission Reliability in Radio

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

Radio is always subject to interference, we talked before about how coding is used on the physical layer to try and correct these errors.

The MAC layer (Media Access Control) handles error correction, and performs multiplexing of services to the same UE at the same time (multiplexing).

Automatic Repeat Request (ARQ)

When data is sent a CRC (Cyclic Redunancy Check) is added, containing a checksum equivalent of the data contained in the message.

The receiver runs the same CRC calculation on the data, and if the CRC value is not equal to the CRC value it received it knows the data is not correct/complete.

There are 3 scenarios shown below:

Scenario 1 – Data is sent and the CRC calculated by the sender matches the CRC calculated by the reciver.
An ACK is sent to confirm the data was received correctly.

Scenario 2 – Data is sent and the CRC calculated by the sender does not match the CRC calculated by the receiver.
The receiver sends a NACK (Negative Ack),
The sender sends the data again, the CRC this time matches, so an ACK is sent to confirm the data was received correctly.

Scenario 3 – Data is sent by not ACK or NACK was received. This could mean the data was not received, or the ACK/NACK was not received.
The sender then sends the message again.
This process is repeated a set number of times after which if no response is received the sender gives up.

Acknowledgement

This technique is called Send and Wait ARQ, because the sender must send the data and wait for an ACK/NACK, and will automatically request re-transmission.

Because CRC may take some time to calculate the ACK/NACK is given time to process by the receiver and the ACK/NACK is sent 4ms after it was received.

If a NACK is received the data is re-transmitted 4ms after receipt of the NACK.

This means all up it takes up to 8ms (8 subframes) to send the data, wait for the response and send again if needed. During this time no other data would be sent.

As you can imagine this isn’t a particularly efficient use of time or resources, so the EUTRAN specs define 8 Send and Wait processes in parallel.

While the first process is blocked waiting for an ACK/NACK, another process can transmit. This is called Parallel Send and Wait.

The problem with this is it can lead to data being received out of sequence, as if data is sent and a re-transmission is needed (NACK received by sender) that data will be received after the data sent 8 frames after it.

Here we can see Block 2 was lost, a NACK was sent and a re-transmission occurs 8 subframes later, long after Block 3 and Block 4 were received.

The MAC layer does not deal with re-sequencing, this is managed by the RLC layer above the MAC layer.

Hybrid ARQ

LTE relies on Hybrid ARQ. To increase redundancy and increase the possibility of decoding a corrupted message correctly.

We talked about coding – sending multiple copies of the same data and comparing them to find the common features that would indicate correct data, Hybrid ARQ functions in much the same way.

To increase error correction performance the receiver keeps the invalid/corrupt messages it sends a NACK for, so it can compare it to the re-transmitted version and hopefully correctly decode the message even if the re-transmission is corrupted.

It is called Hybird because the MAC layer has to communicate to the physical layer to let is know this is a re-transmission and not a new transmission.

Multiplexing on the MAC Layer

You may use your smartphone (UE) for a voice call while looking up something online and getting push notifications, while these are 3 distinct streams of data, there is only one stream of data to and from the eNB <-> UE.

These different types of data all need to be combined into one “pipe” between the eNB and UE, this is known as multiplexing.

The RLC layer has multiple types of data arranged in logical channels, but this data has to be put into a MAC PDU and sent over the air.

In the standard networking model, data in an upper layer is called SDU “Service Data Units”, and data in a lower layer is called a PDU “Protocol Data Units”.

To form the transport blocks the MAC layer must take each of the SDUs from the RLC layer, and put it into the transport block, as show in the image above.

The MAC header contains the delineation of what data is for which SDU on the RLC layer.