This commit follows 7d9945e8.

lte-softmodem UE in S1 and lte-softmodem UE in noS1 modes behave
differently here.

This commit fixes the issue for thoses cases.

Other cases (eNB S1, eNB noS1, oaisim S1/noS1) have to be checked.

This commit is a continuation of 614d6bbe
(ue_ip: use correct instance).

Now in openair2/NETWORK_DRIVER/UE_IP/common.c the 'inst' is not
forced to 1 anymore, we take the value 'pdcph_p->inst'.

It turns out that 'pdcph_p->inst' is 0 instead of 1 when we
run lte-softmodem as an UE.

So let's modify PDCP to set 'inst' to 1 where it was set to 0 for
the UE softmodem case, and skip the places where it is reset to 0,
still for the UE softmodem case.

This may break things, I am not sure.

The problem was the following.

Run oaisim with two UEs:

    sudo ../cmake_targets/oaisim_build_oai/build/oaisim -O enb.conf -u2 -s15 -AAWGN -y1 -b1 -Q0

Then wait for both UEs to be connected. The interfaces "oip1" and "oip2" are
activated, with IP addresses 192.172.0.2 for the first UE and 192.172.0.3 for
the second.

Then on the EPC machine, do:

    ping 192.172.0.3

No reply.
On the oaisim machine, we see that the packets are sent to "oip1" instead
of "oip2".

The fix may break softmodem UE. The inst was forced to "1" for some reason.
To be checked.

Conflicts:
	openair1/PHY/INIT/lte_init.c
	openair1/PHY/LTE_TRANSPORT/dlsch_modulation.c
	openair1/PHY/LTE_TRANSPORT/power_control.c

Fixed bug related to the reporting of timing advance to the controller that severely dropped the performance of the remote scheduler

Imad ALAWE authored 8 years ago and FredericLeroy committed 8 years ago

In openairinterface5g many definitions in many layers of UE or eNB NB_MAX.
We created a file called openairinterface5g_limits.h
located at openairinterface5g_dir/targets/COMMON/ declaring the number max
of UE and eNB to be used in ALL layers depending on launching conditions
(LARGE_SCALE for example).

Imad ALAWE authored 8 years ago and FredericLeroy committed 8 years ago

When using abstraction mode, layer2_init_UE() and openair_rrc_ue_init()
are called according to first_sync state and only without MME support.

We added the global variable abstraction_flag to allow abstraction mode
when MME is enabled.
Openair2 is also used in lte-softmodem, so it must have a global variable
abstraction_flag. So we moved it out from the main() scope.

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...