MR !1054 : gNB_multi-threading_rework
-Replacing the existing multi-threading pipeline with threadPool library, simpler and more robust
-Updated dlsim to print stats to matlab file.
-Small fix for UE Ulsch coding.
MR !1063 : T_tracer__add_gnb_tracer
Minimalist gnb tracer to trace (for the moment) rxdataF when some decoding for PUCCH or PUSCH has been done
MR !1070 : nr_pdcp_improvements
Implement data transfer (38.331 5.2): - transmit operation (in nr_pdcp_entity_recv_sdu) - receive operation (in nr_pdcp_entity_recv_pdu) - t-Reordering expiration
MR !1076 : PBCHNRTCFIX
Issue Details: If bchPayload is changed to non-zero value, then the test case used to fail.
Solution: While final check against UE decoded bchpayload and input bchpayload, the AND operation with 0xff is missing along with RIGHT SHIFT operation for input bchpayload.
MR !973 : s1_subnormal
LTE update in S1 functions from Fujitsu.
-NNSF
-S1AP auto recovery.
-Handling unexpected messages.
-Fix memory leak.
MR !1048 : develop_SA_RA
-Draft and initial trigger of RA procedures upon SIB1 reception.
-Improvements on SA SIB1 reception.
-Get Msg3 from RRC to MAC layer (this fixes random Msg3).
-Fix Tables 7.4.1.1.2-1/2 from 38.211.
The discard timer is used by the PDCP layer to discard packets that were not
transmitted to RLC after some time.
We don't really need it for the moment, maybe never for the default
bearer which is a best-effort bearer passing all kind of IP traffic.
Maybe for voice over IP kind of traffic it's important, or realtime
applications.
I ran an iperf UDP uplink test and saw no error on the PHY layer but still
lots of packets lost in the iperf logs, which was very surprising. By
analyzing the logs in wireshark I saw that, with the current scheduler,
an IP packet sent by the UE took 40ms to be sent piece by piece to the
gNB, and then the next uplink IP packet was never sent at all because
the discard timer was expired, leading to the high count of packets lost
in the iperf logs.
So let's put infinity for the moment for the discard timer. From my
understanding of the moment it's not a problem. If for some reason we
should set it to some non-infinity value, then we can change later.
hardy