Conflicts:
	openair1/PHY/NR_TRANSPORT/nr_transport.h
	openair1/PHY/NR_TRANSPORT/nr_transport_common_proto.h
	openair1/PHY/NR_TRANSPORT/nr_transport_proto_common.h
	openair1/SCHED_NR/phy_procedures_nr_gNB.c
	openair1/SIMULATION/NR_PHY/prachsim.c
	openair2/GNB_APP/RRC_nr_paramsvalues.h
	openair2/LAYER2/NR_MAC_gNB/gNB_scheduler.c
	openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_phytest.c
	openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_primitives.c
	openair2/LAYER2/NR_MAC_gNB/mac_proto.h
	openair2/LAYER2/NR_MAC_gNB/nr_mac_gNB.h

- the issue popped up with the new rx/tx implementation  at the UE
- this was causing false processing of DLSCH PDU and reception of false
  TA commands

- Apply a value which cannot be interpreted as any valid LCID at the MAC layer of the receiver gNB (as per 38.321 Table 6.2.1-2),
to avoid forwarding the random PDU to the upper layers in noS1 mode.

- this is needed because in the current implementation of the gNB
  the scrambling rnti is 0 for the RA and dci rnti otherwise

- monitoring RA window
- taking RA_offset into account
- workaround to generate PRACH only when the RAR has not been received yet (RA is idle)

Develop Integration Branch -- 2020 week 19

The following Merge Requests were included:

* MR [810] : NR PUCCH
* MR [812] : fix 20 compilation warnings
* MR [815] : rlc v2 -- coverity scan fixes
* MR [816] : hotfix: fix compilation of UE with --musim

Also add fixes for CI

- the commit fixes also the selection of the thread_id in TX procedures
- DCI configuration is currently limited to slot 1 and 7

- including temporary hotfix for the polar rnti

The following was failing:
./build_oai --UE --musim

Not sure this fix is correct, but it seems consistent with
the rest of platform_constants.h.

Minor fixes, doesn't change anything. Not sure these are 'bugs' either,
but let's be polite with coverity scan...

One thing was not changed.
Coverity scan says:
*** CID 357991:  Memory - illegal accesses  (USE_AFTER_FREE)
/home/carabe/raphael/openairinterface5g/openair2/LAYER2/rlc_v2/rlc_entity_am.c: 507 in tx_list_remove_sn()
501         } else {
502           prev = cur;
503           cur = cur->next;
504         }
505       }
506
>>>     CID 357991:  Memory - illegal accesses  (USE_AFTER_FREE)
>>>     Using freed pointer "head.next".
507       return head.next;
508     }
509
510     void cleanup_sdu_list(rlc_entity_am_t *entity)
511     {
512       rlc_sdu_t head;

But as far as I understand, there is no problem. We don't access
head.next at all if it has been freed. Or is there some aliasing
going on there (pointer aliasing)? I doubt it. False positive?

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

-- check if C file has a GNU GPL license
-- check if C file has s suspect license
-- check if C header is having correct circular dependency protection (with Laurent Thomas's help)
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

also use the high 6 bits from MIB when calculating decoded_frame_rx after the initial synchronization

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Conflicts:
	executables/nr-ue.c
	openair1/PHY/NR_TRANSPORT/nr_dci_tools.c
	openair1/PHY/NR_UE_TRANSPORT/nr_prach.c
	openair1/PHY/defs_RU.h
	openair1/SCHED_NR_UE/phy_procedures_nr_ue.c
	openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_primitives.c
	openair2/RRC/NR/rrc_gNB_nsa.c
	openair2/X2AP/x2ap_eNB_handler.c

Develop Integration Branch -- 2020 week 17

See merge request oai/openairinterface5g!809

Conflicts:
	cmake_targets/autotests/test_case_list.xml
	executables/nr-gnb.c
	openair1/PHY/INIT/nr_init.c
	openair1/PHY/TOOLS/tools_defs.h
	openair1/PHY/defs_gNB.h
	openair1/SCHED_NR/phy_procedures_nr_gNB.c