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

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.

fixes after merge with develop. Partial UE/eNB separation in build to avoid problems with NFAPI in oaisim UE/RRU.
tested with simulator.

Summary of changes:
- Implementation of paging (see issue #255 in gitlab)
- Implementation of RRC RE-ESTABLISHMENT (see issue #256 in gitlab)
- Implementation of RRC CONNECTION RELEASE (see issue #257 in gitlab)

Some modifications with timers have been done.
Expect (and report) problems, thanks.

What has been tested:
- monolithic eNB 5 and 10MHz with one commercial UE. UDP and TCP
  traffic, uplink and downlink, with iperf (with a third party
  EPC, not openair-cn). TCP downlink traffic is not stable.
  Reason yet unknown. Will be fixed later.

Conflicts:
	targets/RT/USER/lte-softmodem.c

Conflicts:
	openair1/SCHED/fapi_l1.c
	openair1/SCHED/phy_procedures_lte_eNb.c
	openair2/LAYER2/MAC/config.c

Conflicts:
	openair2/LAYER2/MAC/config.c