What is happens in 5G after msg4 timer expiration (16ms)?

Specs & Protocol Testing
1

Hi Experts.

I’m trying to understand in 5G what is happening after msg4 timer expiration (16ms).

Per my understanding UE will need to go from msg1 again, but then I don’t get it for what is needed t300 which is usually 1sec.

In the logs I can clearly see a lot of circles msg1-msg4 until rrcSetupRequst is failed.

But in those repetitions I don’t see again RrcSetupRequst until t300 expired.

So anyone knows what is happening in those repetitions after msg4 timer expiration until Rrc setup fail?

What is msg3 in those repetitions?

2

Once UE higher layer prepare for RRC setup request, it indicates to lower layer and T300 starts at higher layer.

At msg4 CT timer expiry, lower layer again attempt RACH process and it goes on till T300 expires.

After T300 expiry higher layer indicate lower layer about RACh abort, and then fresh RRC Setup request starts with T300 start again.

3

T300 is related to RRC layer RACH process is related to MAC layer.

Are not connected one with another eg RACH process continue till max attempts are done, is not related to T300.

4

OK, so in that case what represent msg3 as Rrr SetupRequest is not going again until t300 expiration?

Does it carry only C-rnti mac?

5

If the UE does not have a C-RNTI then UE sends CCCH SDUs (such as RRCSetupRequest, etc.) on Msg3. These CCCH SDUs contain the contention resolution identity, and then the UE uses TC-RNTI to successfully decode the PDCCH of Msg4 and it can also successfully solve the Msg4. Contention Resolution Identity MAC CE, and the identity in the MAC CE is the same as that sent by the UE in Msg3.

:point_down:

6

I don’t think so.

Original question is asking about RACH cycles upon msg4 timer expiry.

This cycle continues only till T300 expires.

After that fresh RRC setup request starts, and hence t300 also.

7

But 300 is like 3-4 seconds.

By that time RACh process is anyway long finished.

Even with 10 retransmissions RACH is ending in less than 1 second

See this example:

image
image1066×1586 142 KB

Even when failing at msg4 is ending in less than 700 msec:

image
image950×1236 134 KB

8

Ok. I mean to say here, the limit is either max RACH attempt or T300 expiry.

9

Hmm …not sure that T300 expiry can stop RACH process once initiated. Let me read MAC procedures to find the answer to this question.

There is no mention about T300 in MAC specs 38.321

Because it’s an RRC timer not a MAC parameter or MAC timer.

It says in 38331:

5.3.3.7	T300 expiry
The UE shall:
1>	if timer T300 expires:
2>	reset MAC, release the MAC configuration and re-establish RLC for all RBs that are established;
10

T300 is upper limit of RACH cycles.

You are observing RACH process early finish because T300 i set up in that way.

Design guideline of T300 is roughly as below:

T300 >= preambTxMax * (20ms) + harqMaxMsg3 * 8ms + raContResoT

So based on default values it can be assumed as

T300 >= 10 * 20 ms + 5 * 8ms + 64ms = 304 ms

No operator keep it low value in order to avoid rach failure.

But if T300 is kept low for example 200ms, then parameters like preambTxMax etc do not matter and RACH is aborted.