Hi all.
I read at many places that the first Harq ACK/NACK is for RRC setup in RACH!
But then u also hear if RRC setup request is to be retransmitted (means it was NACKed), it would be sent again with DCI info!
So doesn’t that make RRC setup request the first msgs which uses HARQ Ack/Nack?
I guess for connection request there is no Harq feeback because many UE may attempt with common resource.
What UE does… after expiry of contention resolution timer expiry… UE retransmit the connection request.
Doesn’t it restart the RACH process after contention expiry?
No, first will try max number of msg3 retransmission… if still fails then go for rach preamble with increase power.
And but how does the network know UE needs DCI for this retransmission?
There is!
RRCConnectionRequest is one of the MSG3.
26.321 5.1.5 Contention Resolution
(...)
Once Msg3 is transmitted, the MAC entity shall:
- else:
- start mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission.
But are these HARQ retransmission based on harq feedback or there is some other mechanism triggering it?
26.321 5.1.5 Contention Resolution
(...)
- if mac-ContentionResolutionTimer expires:
- except for BL UEs or UEs in CE or NB-IoT UEs:
- discard the Temporary C-RNTI;
- consider the Contention Resolution not successful.
- if the Contention Resolution is considered not successful the MAC entity shall:
- flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;
- if the notification of power ramping suspension has not been received from lower layers:
- increment PREAMBLE_TRANSMISSION_COUNTER by 1;
- else:
- if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
- indicate a Random Access problem to upper layers.
- based on the backoff parameter, select a random backoff time according to a uniform distribution between 0
and the Backoff Parameter Value;
- delay the subsequent Random Access transmission by the backoff time;
- proceed to the selection of a Random Access Resource (see clause 5.1.2).
Maybe some MAC expert can comment, but as per my understansing for msg3 …there is no harq feedback.
HARQ is HARQ, there is feedback.
Also, there are configuration parameter that: “Indicates the maximum number of HARQ transmissions used for message 3 of the contention-based random access procedure.”
Yes, but for this feedback is not required i guess.
If multiple UEare in contention then HARQ feeback would cause confusion to UE.
A UE may consider false positive.
Thats why contention resolution timer is used i guess.
Typical ‘Contention Based’ RACH Procedure is as follows :
i) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)
ii) UE <-- NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message)
iii) UE --> NW : L2/L3 message
iv) Message for early contention resolution
Now let's assume that a contention happened at step i).
For example, two UEs sent PRACH. In this case, both of the UE will recieve the same T_C-RNTI and resource allocation at step ii). And as a result, both UE would send L2/L3 message through the same resource allocation(meaning with the same time/frequency location) to NW at step iii).
What would happen when both UE transmit the exact same information on the exact same time/frequency location ?
One possibility is that these two signal act as interference to each other and NW decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from NW and they all think that RACH process has failed and go back to step i).
The other possibility would be that NW could successfully decode the message from only one UE and failed to decode it from the other UE. In this case, the UE with the successful L2/L3 decoding on NW side will get the HARQ ACK from Network. This HARQ ACK process for step iii) message is called "contention resolution" process.
36.321 MAC layer, section 5.3.2.2
HARQ feedback is not done during contention phase, and even it does not make sense for harq feedback during contention phase.
Last image seems to clear the doubt.
Thanks @Manu_Saini and @marcengo!
But one question still remains… What triggers Msg3 retransmissions?
contention resolution timer expiry
So your concern is if feedback is provided via PHICH/DCI or implicitly via something else?
But from the same spec… it should lead to step 1… PRACH!
Yes, what is the feedback which will trigger msg3 retransmission?
UE will send msg3 and will start contetion resolution timer.
And if contention is not resolved before expiry of this timer and then UE retransmit msg3.
This retransmission will be done msg3-retx count times.
If still contention not resolved then go to step 1.
In a Log, it looks like we have PHICH, people.
2019 Jul 29 12:36:34.984 [12] 0xB169 LTE UE Identification Message (MSG3) Report
SFN = 704
Sub-fn = 2