I have to revert this to be consistent with the OAI gNB.
But I think it is wrong to take the BWPSize from scc or scc_SIB, and the BWPStart from DLbwp[0].

Procedure fill_dmrs_mask is modified.
	- PDSCH Mapping Type B is supported
	- Modified according to sections 5.1.6.2 of Spec 38.214
	- Single and double symbol DMRS are handled in Type A and Type B

Mapping type according to the time domain allocation from DCI should be used to get the values of DMRS config
For sending sib1 - DCI FORMAT 1_0 will be used with SI_RNTI, UE should perform these actions
according to sections 5.1.6.2 of Spec 38.214

Additional DMRS set to pos2 in case of msg2 reception, msg3 transmission.

Mapping type B is added to RRC reconfig.
	- nr_dlsim updated to test typeA and typeB. Verified the changes.
	- RFSIM Validation of PDSCH Mapping TypeB  by changing timedomainallocation in configuration files.

corrections in PUCCH handling for dedicated configuration on initialBWP. first transmission handling for DL harq processes at UE.

added call to NAS for RRCSetupComplete message in UE. other minor modification in gNB/UE scheduling for SA

UE Configuration after SIB1 ok, RAR configuraiton/reception ok, Msg3 transmission / reception ok, CU fails when needing to at SRB1

In case of false positive PDSCH CRC check, a random MAC PDU is processed.
Currently pdu_len is unsigned 16 Bit, so we did break out of the processing loop only if we _exactly_ hit a residual pdu_len of 0, or we hit a LCID of DL_SCH_LCID_PADDING.
If we didn't hit either of these, pdu_len wrapped to a very positive value, and we continued processing the PDU even beyond its bounds!
This behavior was observed with SNR 1 dB and MCS 9.

So better make pdu_len signed and break out of the loop after processing at max. pdu_len Bytes!