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.

When the program exits it has to stop the streaming of the USRP.
The function exit_fun is supposed to do that. When quitting with
control+c (very common case) this function is not called. The
code is very unclear there, so let's add a stop_rf in the RU,
as there is already a start_rf.

If we don't call trx_end_func, then at the next run the USRP
device may be in an unstable state and behave improperly.

If the program crashes then the USRP device may be in an
unstable state. The only solution to this problem is to reset
the USRP device.

Maybe there is a way to clean the state of the device when we
open it, before we start using it. Sort of a cleanup before
use. That could be a better solution to "bad state after program
crash".

What has been tested:
- monolithic eNB only

The one in lte-enb.c disrupts the realtime. Using a B200mini with
20MHz bandwidth leads to the UE unable to connect for it seesms like
the UL and DL are not properly time synched because of this sleep
of one second that happens after the USRP streaming has started.
We see some random access attempts but the decoded preamble is
wrong.

This may be dependant on the setup. I had sporadic errors with
a B210, where sometimes the UE could connect and sometimes not.

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

Summary of changes:
- fix dlsim/ulsim
- fix centOS compilation
- Move the accounting phase of the DL pre-processor in a separate procedure
  and fix some issues
- additional Mac stats and Improvements
- minor fix in test setup v2

Merge remote-tracking branch 'origin/fix-centos-network-device-compilation' into develop_integration_2018_w08

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

With value 4 when connecting one UE and doing some downlink
iperf TCP there is a crash. Probably due to the multiple wrong
RA detected leading to uplink failure of fake UE that never
sends Msg3 (because, well, there is no other UE).

This is another problem that will be fixed at some point.

Anyway, this value 4 fails. Let's put back 3.

Merge remote-tracking branch 'origin/fix-centos-compilation-2018-w08' into develop_integration_2018_w08

The following was not working properly:

    ./build_oai -I -w USRP

After this commit it works.

And so does:

  ./build_oai --eNB -w USRP

Conflicts:
	openair1/PHY/INIT/lte_init.c

Summary of changes:
- a lot of work on flexran
- several compilation bugfixes
- some bugfixes for some bad conflict resolutions
- various bugs fixed

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.