this commit is here to help debug the previous ones.

It has to be reverted at some point.

We put an abort() at this point in the code, because
if the previous commit is correct, the program will
never comme here.

The previous version did not seem to work properly with
several UEs. I too often ended up with a list 'next' where
next[i] = i, leading to an infinite loop, crashing the
processing.

The sorting functions were hard to understand and too slow
anyway (O(n*n)).

We now use qsort_r and comparison functions, that should
define the same order as the previous version.

One important point is that the "next" lists and the "head"
variable are now considered invalid before calling sort_UE.

So all the code (coming before sort_UE) that looped using those
variables has been rewritten to loop over all possible UEs and
the first instruction of the loop is to exit the loop if the UE
is not 'active'. There is room for improvement here. We will
reintroduce a list of some kind at some point. Let's first
have something that works and then optimize. Today NUMBER_OF_UE_MAX
is 16, that's not a big deal.

Consequently, the add_new_ue and rrc_mac_remove_ue have also
been rewritten, hopefully for the better.

This commit is not a basic work and may introduce some
problems.

The RA process may be in the state:
RA_active == FALSE and wait_ack_Msg4 == 1

Testing only the rnti should be enough, if everything else works
properly.

Also, don't break, just in case. (Not sure it makes a
difference.)

The previous version was calling taus(), which
may return any value in [0..65535].

The new version restricts it to [1024..59999]
(arbitrary values, big enough, and in the valid range).

It also checks that the new RNTI is not already present
in the MAC.

I think we should also check that it's not used by a RA
process.

The "loop" thing may not be the best solution either.

To be refined.

A RA process is not available if
and RA_template[i].wait_ack_Msg4 != 0

We can have RA_active==FALSE and wait_ack_Msg4==1,
in which case the RA process is in use and cannot
be reassigned.

What if it's -1? Is it possible?
We catch the case and abort.

We may do a proper fix if the case happen.
I don't think it will, but who knows...

RRC does not work very well when one UE goes away and comes
back in some situations.

This commit is an attempt at making things work better.

It is probably not the end of the story.

It resulted in wrong log message, leading to complicated
debugging.

Modern UEs have very long UE capabilities.
It disrupts realtime behaviour of the modem.

Let's put a simple log message indicating we got the
UE capabilities.

Here is the problem:
    Sometimes the UE has no PHY context but
    is still present in the MAC with 'ul_failure_timer' = 0 and
    'ul_out_of_sync' = 0. It seems wrong and the UE stays there forever. Let's
    start an UL out of sync procedure in this case.
    The root cause of this problem has to be found and corrected.
    In the meantime, this hack...

This has to be redone at some point.

Here is the problem:
    UE comes. SRB2 is configured via message to RRC.
    At some point the RLC AM is created but not configured yet.
    At this moment (I think) MAC calls mac_rlc_status_ind
    which calls this function. But the init was not finished yet
    and we have a crash below when testing mem_block != NULL.

The "solution" is to test if rlc->input_sdus is NULL.
This is a very dirty hack. I would say the solution
is to use proper locking mechanism because RLC is used
by two threads: PHY/MAC on one hand and RRC on another
hand (I think).

The management of uplink failure generates a DCI to send
a RA PDCCH order. It calls add_ue_spec_dci which increases
DCI_pdu[CC_id]->Num_ue_spec_dci, but this was reset to 0
*after* the DCI generation. Let's reset *before*.

Bug reported by Liang Yong on openair5g-user mailing list.

The function may return NULL if the UE has been dropped
in the PHY layer but is still present in the MAC layer.

Deal with the NULL case everywhere it's needed.

I am not sure this is the correct solution.

The problem seems to be that the RRH GW does not use ITTI
and thus the type 'as_nas_info_t' is not defined, and then
the compilation fails.

The simple fix is to include 'as_message.h' in
'openair2/RRC/LITE/defs.h' if ENABLE_ITTI is not
defined. Maybe it's not good. RRH GW compiles with this fix.

It is defined both in openair2/COMMON/commonDef.h and
openair2/COMMON/platform_types.h.

Removing one or the other definition creates many problems
when compiling this or that part of the system (ue_ip.ko,
at_nas_ue). Let's keep both and protect the definitions
inside #ifdefs.

Some of them might not be correctly handled.
I put /* TODO: XXX */ where I didn't know if
the fix was correct.

The LOG_X macros emit a lot of warnings when compiling with the T
because they call the function logRecord (or logRecord_mt)
which has not been "marked" as calling printf, so gcc won't
emit typical printf warnings.

With the T, they directly translate to sprintf, so those warnings
pop up, much more verbose due to several macro expansions.

Let's make them pop up all the time so it's easier to fix them.

fixes for precoding (turning off if nb_antennas_tx=1), configuration files, timing advance with 3/4 sampling on 20 MHz, logging in MAC

see issue #178

see issue #177

fix incorrect fss_pusch calculation
fix the incorrrect HARQ-PID checking
remove incorrect checking on downlink DCI HARQ PID value
fix incorrect downlink ACK/NACK feedback procedures in TDD
fix no activating PDSCH decoding when DL-DCI is indicating a downlink retransmission

see issue #176

bugfix for DCCH2/SRB2 in eNB_scheduler_dlsch.c, demultiplexing SIMD alignment issue in ulsch_decoding.c, IF5 fronthaul modification in lte-enb.c

see issue #164

add logs and asserts to catch the double dequeue of the same head PDCP SDU from pdcp_sdu_fifo during flushing

see issue #164

see issue #166