Conflicts:
	openair2/LAYER2/MAC/config.c

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

Conflicts:
	openair2/LAYER2/MAC/config.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

Merge remote-tracking branch 'origin/issue-285-connect-disconnect-multiple-time' into develop_integration_2018_w04

Conflicts:
	openair1/PHY/LTE_TRANSPORT/ulsch_decoding.c
	openair1/SCHED/defs.h
	openair2/LAYER2/PDCP_v10.1.0/pdcp.c
	openair2/RRC/LITE/rrc_eNB.c

As reported by Emad Alizade:

    According to "Issue255 256 257 paging reesta release" that has been
    merged in develop version, we have a question: In rrc_eNB_free_UE()
    function only all ulsch related memory of user has been cleaned, but
    I think not only ulsch memory but also dlsch memory must be cleaned.
    I tested the latest develop version and with repetition UE attach-detach
    procedures we find that the dlsch memory has not been cleaned and after
    repeat this sequence (45 times) assertion with cause UE_id!=-1 (no free
    or exiting dlsch_context, dci_tools.c: fill_dci_and_dlsch() ) occurred
    and no UE will be attached to system.

The fixes in this commit are from Emad Alizade.