This was causing oaisim to fail way too often at the startup
of a connection.
Things should go better with this patch.
It may not be the end of the story, the use of retrans_num_bytes_to_retransmit
is not clear to me. The problem I see is: what if the max number of
retransimission has been reached (if that has a meaning at all in RLC AM)?
will this value be decreased or not?
The code was changing the rnti in the red-black tree without
removing/reinserting the context. This is wrong because the
rnti is a key of the red-black tree and you cannot change the
key in a stored item at will.
There are also modifications of the function mac_eNB_rrc_ul_failure
which has to remove the UE in any case.
And rrc_mac_remove_ue has been changed for the case where
the UE is not found.
It creates more problems than it solves.
We replace this approach by a straightforward
synchronous one.
Now in the downlink, at frame f and subframe s
we use HARQ process (f * 10 + s) % 8.
This is similar to uplink scheduling.
set transmission mode in phy_config_dedicated_[UE|eNB] after RRCConnectionReconfiguration(eNB) and RRCConnectionReconfigurationComplete(UE)
add ue_TransmissionMode in RrcConfigurationReq
added ue_transmission_mode and nb_antenna_ports to eNB config file
transmisison mode gets set with RRCReconfiguration
The T has 2 processes: the tracee and the local tracer
if the tracee dies (segfault or whatever) the tracee
may still be running.
So there is a third process that monitors those two others
and kill everything when one dies.
The problem is that this third process has to be the parent
of the two others. That makes debugging the tracee with gdb
impossible. This new option disables the third monitor process.
Rohit Gupta