1. Previous SW configuration for different RRC version relies on whether macro Rel10,
   Rel14 defined or not by checking #ifdef Rel14 or #if defined(Rel10) || defined(R14).
   Whenever there is a newer RRC version, e.g. Rel15, it will be very a tedious and
   error-prone job to add defined(Rel15) in every place.

2. Some RRC messages are defined in release 13 instead of release 14, NB-IoT
   feature is one of such example. Our code shall reflect this fact instead of using
   an afterward version number in software configuration.

3. Some RRC messages or some fields of certain RRC messages are added in the middle
   a release, e.g. SystemInformationBlockType1_v1310_IEs_t defined in RRC 13.1.0
   and RRC 9.2.0 made some changes to SIB12 and SIB13 so we have sib12_v920 and
   sib13_v920 fields in SIB12 and SIB13's struct.
   We need a finer grain of control when using ASN1 from different RRC version.

4. S1AP also has this problem that it use UPDATE_RELEASE_9 and UPDATE_RELEASE_10 to
   differentiate between various S1AP version.

This commit propose using MAKE_VERSION(x,y,z) to designate the version number and
modify current conditional compilation accordingly.

Note: 2018/04/16, Modified based on Cedric's comment.

158 does not work well with the eNB softmodem.

modifications for simulator : power normalizations for UE TX, small changes to SNR targets for power control, default UE power (23 dBm now)

This work is based on work by NTT.

To use the code, do:
./build_oai --oaisim --ue-nas-use-tun -t ETHERNET -c

This commit only handles oaisim in S1 mode.

We won't handle noS1 mode.

Only ulsim and dlsim compile. The others (dlsim_tm4 pucchsim prachsim
pdcchsim pbchsim mbmssim) have been disabled.

Command line to compile: ./build_oai --phy_simulators

It is annoying and does not seem to work properly.
To be checked/reworked if needed.

Keep in mind that we also want oaisim to be functional.

if the FlexRAN agent is disabled, do not read all the data and skip reading
of more information

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