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.
- FAPI structures not to be used as config_req at MAC since that FAPI is
just for communication between MAC and PHY
- additional frame_type member added to the FAPI struct
- removed commented out code
- improved logging in UL channel estimation
- minor fixes according to OAI coding guidelines
- moving fetching TDD configuration parameters in nr-ue.c only in TDD case
In FDD mode, the UE_mode switches to PUSCH mode before the initial TA value was applied.
Because of this, the ta_command was misinterpreted.
Fix this by adding 31 to the initial TA comamnd and handle it the same as TA updates.
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
To keep track of time the function nr_pdcp_wakeup_timer_thread has been
added and is called by the gNB's MAC scheduler via nr_pdcp_tick.
(The UE has not been modified.)
A thread has been introduced to set time of all the existing PDCP
entities in the system. This probably does not scale well with many
PDCP entities (many UEs connected to the gNB). To be changed at some
point when needed. Hopefully, with a few UEs this mechanism won't be
too problematic (ie. won't cause realtime problems).
The problem with time in PDCP is that SDUs are kept if some are
missing, to do reordering. A timer is started and when it expires
we have to transmit the SDUs even if some are still missing. We
want to do that as soon as possible. So we have to check timers
often (every millisecond).
In RLC the time is set when there is some activity (SDU or PDU
received). In PDCP we cannot wait for this kind of activity. We
would keep packets longer than necessary, which may disturb
upper layers (think: TCP). That is why we introduced the thread,
as a simple mechanism to keep packets no longer than necessary.
The locking done by this thread may create realtime issues.
The whole logic of time keeping can be changed later if it turns
out that it is not efficient.
The functions dealing with DRB AM have been removed. All the types
of PDCP entities (DRB AM, DRB UM, SRB) use the same mechanism for
transmit and receive operations. So the code has been made common
for all those types.
We don't deal with:
- entity re-establishment, entity release or entity suspend
- SDU discard (the timer is present but not used)
- status reporting
- data recovery
- data volume calculation
- header compression / decompression
There is no plan to implement those features in a near future.
Integrity protection is not done yet, and will be implemented soon.
Minimalist gnb tracer to trace (for the moment) rxdataF when some
decoding for PUCCH or PUSCH has been done.
Important: T_BUFFER_MAX and T_CACHE_SIZE have been changed. T_BUFFER_MAX
is twice as big as before. T_CACHE_SIZE has been devided by two. Globally,
the memory usage of the T tracer is the same, but since we divided by two
the number of buffers in the cache, we may hit some realtime problems if
all the buffers are busy at some point. The simple solution would be to
use 8192*2 for T_CACHE_SIZE as it was, but then we double the memory usage
of the T tracer. This, or another solution, to be defined.
MR1029 : Benetel driver update
This MR fixes an issue with the driver for the 4G Benetel RRUs.
Power levels on the 5G side were adapted to avoid saturation of the signals.
5G performance is now the same as with USRP.
Support for 2 antennas for both 4G and 5G was added
MR1062 : fixing the RE offset for each Rx antenna in pusch channel estimation
francescomani