This seems different from what we read in the specs…
I don’t see why the UE wouldn’t be able to read PHICH before the RRC establishment, but indeed the spec looks different from it.
I’ll take a better look later.
TS 36.321 - 5.1.5 Contention Resolution
It talks about going to step 1 at expiry of contention resolution timer.
Simply there is no need for such extra signalling msg, since after timer expiry UE will try again…
PHICH overhead is minimal, plus, HARQ for UL is 4ms, resolution will vary according to NW, but typically 32ms or 64ms.
It would dramatically increase de latency.
If I was the eNB I would use it.
From latency point of view, yes I agree .
But on the other hand you have the UL interference impact as well.
Just one note: this is DL HARQ operation, not Uplink.
As per my knowledge, during Rach, only the 4 known messages will occur.
Harq (witu related Ack/Nack) would occur in the RRC Connected mode, in another meaning wjen the UE is downloading /upload data
HARQ can be over PUCCH (ACK/NACK) - - - DL
HARQ can be over PDCCH (DCI: NDI - - > 0 or 1) - - UL
4 TSs of HARQ, one for uplink and 3 for downlink
There is no DL msg with TC-RNTI expect rrc setup, which definitely has a harq feedback.
I am not some protocol expert but long time ago i worked on this scenario and reached the following conclusion. Please note that its based solely on my “own understsanding” and sharing it just for reference.
So to simplify things lets take the two scenarios.
First “UE Send MSG3 but MSG4 not Received” and secondly “NACK Received for MSG3”
UE Send MSG3 but MSG4 not Received
When UE send MSG3 two timers start in parallel. One is T300 and other one is Contention Resolution Timer
If the UE do not receive msg4 (Contention Resolution message) within this timer, then it go back to Step 1 i.e. transmitting Random Access Preamble
Please note that Contention Resolution Timer expires while T300 is still running because T300 > Contention Resolution Timer.
Assume that events were successful till MSG3 i-e eNB receive MSG3 but no MSG4 received in DL. Now UE will send the preamble again after Contention Resolution timer expiry and this time all next events in chain become successful (and all this happened before expiry of T300).
In above mentioned scenario eNB received MSG3 twice before expiry of T300 (As indicated by tick marks). This new attempt will be pegged in pmRrcConnEstabReatt in Ericsson. These Re-Establishments are subtracted from accessibility formula.
If the Random Access attempt of a UE fails, either because the preamble sent by the UE was not detected by the eNB or the UE lost the contention resolution, the UE has to start the process over again. To avoid contention and overload, the eNB can signal the UEs that they have to wait a certain time before they try to connect again. The parameter that controls this is called the Backoff indicator (BI) and is signaled by the eNB in the random access response.
NACK Received for MSG3
If there is a HARQ NACK for msg3 (RRCconnectionRequest) and it has to be re-transmitted then this Contention Resolution Timer will be re-started
UE wait for NACK or CRT (Contention Resolution Timer) expiry. NACK can be received any time before CRT Expiry. If NACK received (before CRT Expiry) UE will do Re-Transmission (How Many Retransmissions from UE Side -> It is given in SIB 2 under maxHARQMsg3Tx). If no NACK Received and CRT Expires UE send preamble again with stepped up (As shown in bellow figure)
After reading multiple articles I reached this conclusion so far… Would love if someone relate it with 3GPP [Either +vely or -vely]…
According to the specs there can be no harq ACK/NACK for Msg3 and hence our confusion of what can trigger a Msg3 retransmission.
Also, how resource are given fot msg3 retransmission?(dci I feel) And how Network knows now I need to give resources for msg3 retransmission.
Btw… Good explanation @AbdurRehman87
Many Thanks brother…
In my humble opinion since we have maxHARQ-Msg3Tx parameter and its communicated in all vendors in SIB2 so HARQ phenomenon [ACK/NACK] must be there for MSG3…
I will the mechanism for these retransmission lie in Contention resolution timer and not Harq ACK/NACK.
Because otherwise contention resolution would have less meaning.
As the UE whose msg3 will be received.
Will simply receive a Harq ACK.
As per my understanding, if msg4 is not received, there will be 1 of 2 conditions:
- there will be RRC conn reject
if this the case, it will trigger T302 only until it expires then ue will send another msg3 (retry)
- no reply until T300 expires
if this the case, UE will retransmit msg3
for both above cases UE will wait for eNB response, and can do the iteration (retry/retransmit msg3) until N300 value times or until it receives msg4
UMTS uses T300 in combination with N300 to manage re-transmissions of the RRC Connection Request message. LTE does not have an N300 parameter.
In case which i discussed “UE Send MSG3 but MSG4 not received” there is no Reject msg. Simply No reply received for MSG3. Since there is No Reject so T302 will not trigger.