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.

Merge remote-tracking branch 'origin/oaisim-compilation-ubuntu-17-10_2018-w07' into develop_integration_2018_w07

The following did not work before this commit
on ubuntu 17.10:

    ./build_oai --oaisim -c

oaisim has not been tested. It may fail to work. To be tested.

This is done better by commit 6210eb056f880a52edfe9de64c6839154a5c7429.

The branch has been rebased to current origin/develop before merge.

Not sure that the use of __KERNEL__ is the correct solution.
To be checked at some point.

After this commit, the following works:
./build_oai --UE -c

I tried to change rx and tx attenuation by the config file, but they are not changed. The bug is because att_rx and att_tx do not put in RC.rru when local_rf is "yes" in config file. We need to put att_rx and att_rx for both local_rf = "yes" and "no". Also RF config which send to RF device must be fill by this parameters.

removed NFAPI libraries from oaisim target. added #define to allow ue_ip.ko to compile. This should be revisited, there's a problem in CMakelists.txt, no flags.cmake generate for all 3 kernel modules.

Summary of changes:
- fix MAC indentation
- bug fixes:
  - fix uplink over-scheduling
  - fix CQI updating (it was done even when it shouldn't)
  - fix rrc rel10 compilation
  - some minor bug fixes related to ASN.1

'_' is not a valid character.

S1AP specs say:

    ENBname ::= PrintableString (SIZE (1..150,...))

And X.680 (08/2015) 41.4 table 10 lists the valid characters for
PrintableString. '_' is not there. We replace by '-' which is there.

Connection of eNB to ppenair-cn has not been tested. There is no reason
why it would fail.

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c
	openair2/LAYER2/MAC/eNB_scheduler_ulsch.c

Merge remote-tracking branch 'origin/fix-rrc-rel10-compilation-2018-w06' into develop_integration_2018_w06

Conflicts:
	openair2/LAYER2/MAC/eNB_scheduler_RA.c
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c

The unused bits are the lower bits, so we need to shift.

Not sure that the value 1 is what we want though.

The problem that may happen is that when the UE does not transmit
on PUCCH (for whatever reason) we may get no signal at all, and
thus compute a very low CQI. Later on we may ask the UE to transmit
louder which may lead to saturation and more problems.

The solution is simple: don't care about CQI in case of DTX
(and NACK also, as done for PUSCH).

Only FDD case done.
For TDD it seems that:
- nfapi structures are not correct. See nfapi_harq_indication_tdd_rel13_t
  in nfapi/open-nFAPI/nfapi/public_inc/nfapi_interface.h, all the cases
  (bundling, multiplex, ...) use nfapi_harq_indication_tdd_harq_data_t
- the function extract_harq does not handle TDD

There is too much UL scheduling because the buffer status is
overestimated.

This commit tries to make things simpler.

The following compilation did not work anymore:

    ./build_oai --eNB -w USRP -r Rel10 -c

(Rel8 still does not work.)

S1AP specs say:

    initialUEMessage S1AP-ELEMENTARY-PROCEDURE ::= {
        INITIATING MESSAGE      InitialUEMessage
        PROCEDURE CODE          id-initialUEMessage
        CRITICALITY             ignore
    }

So let's use "ignore", not "reject".

The online decoder http://asn1-playground.oss.com/ did
not decode a message encoded by the eNB because of this.

Only the S1AP messages captured while doing a simple connection
of one UE have been tested with the online decoder.

So, not all the S1AP messages have been checked, maybe some
instances of this problem are still there.

It does not seem to harm the actual UE<->eNB<->EPC communication
(because we don't check the integrity of messages or because
asn1c does not do it), so it's not a big deal.

Conflicts:
	openair2/LAYER2/MAC/config.c
	openair2/LAYER2/MAC/eNB_scheduler.c
	openair2/LAYER2/MAC/eNB_scheduler_primitives.c

Summary of changes:
- noS1 fixes
- various bugs fixed

Merge branch 'develop-nos1-fixes' of https://gitlab.eurecom.fr/oai/openairinterface5g into develop-nos1-fixes

Merge branch 'develop-nos1-fixes' of https://gitlab.eurecom.fr/oai/openairinterface5g into develop-nos1-fixes

Merge branch 'develop-nos1-fixes' of https://gitlab.eurecom.fr/oai/openairinterface5g into develop-nos1-fixes

Conflicts:
	cmake_targets/CMakeLists.txt
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair2/RRC/LITE/rrc_UE.c
	openair2/RRC/LITE/rrc_common.c
	targets/SIMU/USER/oaisim_functions.c

Conflicts:
	cmake_targets/CMakeLists.txt
	openair1/PHY/LTE_TRANSPORT/dci_tools.c
	openair2/RRC/LITE/rrc_UE.c

Summary of changes:
- heavy code cleanup (#ifdef removal)
- bugfixes