The agent_id is a uint64 consisting of: module ID (i.e. mod_id, the several
instances of OAI at once, 16 bit), the enb_id from the configuration file (32
bit) and the cell_id from the configuration file (16 bit).

The module ID is part of the agent ID but it is easier to have it directly in
the struct.

The PHICH was not programmed for the last round (4) because it was
not programmed in rx_sdu but in schedule_ulsch_rnti, only in case
of a programmed retransmission (there is obviously no retransmission
programmed after the last round).

The case of Msg3 is not handled. To be done somehow.

The code is too complex. This commit may not be enough.

End of line character has to be unix-style, not dos-style.

This is hack-level development.

With this commit you can do UDP DL traffic of say 100Mb/s over
a 5MHz link with one connected UE and the eNB should not crash
because of memory exhaustion. Of course on the receiver side
you won't get 100Mb/s and many many lost packets. But the system
should not crash. 1Gb/s does not work. So in any case try to
remain within some reasonable limits. There is no reason to
push more than twice the maximum achievable throughput of
the link.

This work is based on a patch proposed by Francesco Gringoli.

The code was very unclear and potentially buggy.
This new version is more robust.

We can waste up to 2 bytes because the last header in the MAC PDU
does not contain a length field and when we request data from RLC
we suppose a 3-bytes MAC header. This might be optimized at some
point, but the benefit would be low.

This commit also contains some general cleanup:
- formatting
- variables' types: let's use 'int' instead of trying to be clever
  by using small types that may generate bugs if the value is
  too big
- remove 'tpc_accumulated' which was globally used for all UEs
  and has no purpose other than logging. We may want to rework
  a bit the TPC machinery at some point. As the code is today
  we may repeatedly send TPC over and over without caring about
  the 3GPP limits, in which case no one knows how the UE is
  supposed to behave: does it clamp the current max value or does
  it accumulate over and over and take the clamped value to compute
  its actual power? If we send a reverse TPC (reduce power instead
  of increase) does it do it immediately or does it have to decrease
  n+1 times if we previously ordered it to increase n times?)

We do not address the problem of prioritizing LCIDs. As of today there
is only one dedicated traffic channel (DTCH), so it's not a problem
at this point.

What has been tested:
- monolithic eNB 5/10/20MHz with one cots UE, TCP/UDP UL/DL. At 20MHz the
  machine used was not capable of keeping up, generating lots of Us
  and Ls when the throughput reaches 60Mb/s. USRP B210 was used.

Running TCP DL traffic with one connected UE showed a lot of
fluctuations in throughput. After analysis it was found that
sometimes the RLC UM PDU was not correct. It contained one byte
more than it should. On the receiver side, the TCP packet
contained in the RLC packet seems to be rejected by the TCP
stack of the UE (it has one byte more than it should),
leading to a brutal reduction of the throughput, probably due
to some congestion detection in the TCP implementation.
Or something.

This hotfix seems to solve the problem. Using iperf in downlink
with a 5MHz eNB, we see no more fluctuations, the traffic is
very steady at 16.8Mb/s, as reported by the iperf server running
on the phone. (17.5 in the PHY plot of the T tracer.)

A rewrite of both the MAC and RLC UM packet generation is needed.
The code is way too complex for what it does and may contain
several similar problems that only trigger in specific rare
conditions.

has been introduced in commit 365ca71a

added compilation directives for nasmesh and ue_ip kernel modules to allow for building on RHEL systems.

Without this revert, the following does not compile:

    ./build_oai --oaisim

- remove spaces at the end of lines
- remove useless dead code
  use: git show -p <this commit> -w
  to see it clearly

Some more fixes for some bad conflict resolutions.

I ran:

    git diff 2018.w04 2018.w05

And saw some problems with config_sib2.

There was also something strange in openair2/LAYER2/openair2_proc.c
in the function dump_eNB_l2_stats. Maybe the fix is wrong for
this one. To be checked.

Doing an iperf UDP uplink test, we could reach only 6Mb/s
with very good radio conditions instead of around 8Mb/s.

It turns out the MCS was limited to 16.

With this commit, we are back to a bit more than 8Mb/s
as it used to be.

(This is with a 5MHz bandwidth.)

The following compilation failed before this commit:

    ./build_oai --eNB -w USRP -c --T-tracer

The following compilation did not work anymore:

    ./build_oai --eNB -c -w USRP --noS1

Neither did:

    ./build_oai --UE --noS1

Doing airplane mode off to connect a cots UE followed by airplane mode on
to disconnect it gives very bad results (bad disconnection with lots of
UL failures followed by lots of logs in the eNB). It used to work properly
after the work done by Xu Bo.

It turns out that in 2018.w04 things were still working okay. But
in 2018.w05 no.

So I ran:

    git diff 2018.w04 2018.w05

And I checked all the modifications that I thought were relevant
(everything related to the UE, oaisim, if4 and fapi has not been checked).

This commits takes back the version of 2018.w04.

The modifications in openair2/RRC/LITE/rrc_eNB.c are necessary, I think.

The other modifications may not be necessary or even wrong. To be checked
at some point.

- move IMSI extraction code to function, remove FLEXRAN comp. directive
- refactor the code, esp. don't do deep if-nesting
- remove m-tmsi part (does not give correct value)
- copy complete IMSI info to UE context, decode in RAN API

Original Author: Xenofon Foukas
Changed formatting
does not compile
RS: cast to get rid of compiler warning
-> ImsiEpsMobileIdentity_t to ImsiMobileIdentity_t which is defined the same
way

This is done better by commit 6210eb05.