Actually you only see MSG3 good crc in UE logs
Then you see:
e[32m PDCCH for RAR_MSG (rnti 267,ueIndex 7) at 2256425 e[0m
MSG3 CRC_GOODe[32m PDCCH for CONTENTION_RESL_MSG (rnti 20014,ueIndex 512) at 2256440 e[0m
wrong value of UE index =512, correcting to 0
So MSG4 cannot be transmitted due to wrong UE index.
So try making another reset to gNodeB and clear all alarms major and critical.
Your gNodeB fails in transmitting msg4.
I understand. Are you sure can’t I see msg4 because gNodeB fails in transmitting msg4, and the problem of course UE index?
And just by reset I could solve the problem?
Do something until you won’t see this anymore “wrong value of UE index =512, correcting to 0”.
Should be 7 not 0.
But I have as u see in the log the ack of msg4.
It’s [32m CONTENTION_ACK_RECD for ue_index [0] [0m
So there is transmission and ack for msg4.
I am looking at bottom of the log.
You need ueindex=7 no ueindex=0.
This is your UE: index7.
So you need this: [32m CONTENTION_ACK_RECD for ue_index [7] which is missing in your log.
Got you, appreciated.
So just doing reset will solve the problem of UE index?
Not sure about that.
But this is your problem.
That you need to fix.
So the correct id isn’t 512?
You mentioned it’s 7…
It’s random number only sent in msg3.
Same number transmit in contention resolution to match.
But I mean why index 0 is incorrect?
It should be 512 not 7, right?
In my case I mean.
Update to all you guys:
Appreciated your help, now I have attach to the network, did three full reboot system for gNB + RRH and now it there’s successfull in RRC setup.
Thanks! 
Glad to hear.
On this type of issue, troubleshooting can become really difficult.
On early IODT days we saw it happening due to lots of stuff (Frequency and timing tracking loop, wrong DCI config, etc…) and this not solvable overnight.
Happy it worked!
Luckily you manage to clear all alarms.
This was the issues: alarms at AAU or gNodeB.
Not me, the reboot reset did.
But Im afraid that the Throughput isn’t good …still not checked but will update.
Do you get rank4, MCS27 and ibler = 0?
This is what you need to find the right location for it.
And DL grant = 100% and PRB usage maximum.
Can analyse from Uu log.
Very tough to get 100% scheduling rate, IMHO.
Unless you can ensure cell is completely unloaded.
You’re right, but he is in the lab, no other users there.
Still… 100% scheduling rate is a really good number !
If you wanna maximize throughput you might also want to look at TDD pattern.
Ensure you have more room for DL.
(if TDD)
