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?
Not sure if the problem is in the MAC layer or in the RLC v2 layer.
Maybe the buffer status reporting in RLC v2 is not good. Let's remove
two AssertFatal in the MAC for the time being.
Limitation: this fix only works if there is only one eNB,
because we force module_id = 0 in the function deliver_sdu where
(as the code is today) we have no way to know which module_id is
concerned. More generally, the rlc v2 does not work with more than
1 eNB.
The old method was wrong.
The new method is better, but not accurate, especially when the
TX buffer contains SDU of size > 2047 bytes.
Plus it's probably too slow.
To be refined at some point.
This commit introduces an alternative RLC implementation
based on 36.322 version 8. AM and UM done, TM not done.
See openair2/LAYER2/rlc_v2/TODO for missing parts.
Seems like the UEs in the CI don't like when asked to report NR UE
capabilities. So let's first ask for eutra capabilities and then
dig into them to check for en-dc support and only then ask for
NR capabilities. We chose to ask for NR capabilities after receiving
RRCConnectionReconfigurationComplete. That may not be the best thing
to do.
Today, we do nothing with those capabilities. We could completely skip
asking them to the UE, but since the code is there and since it may be
useful in the future, let's do it. Hopefully, it should not hurt too much.
An NR-capable UE will transmit some NR measurements.
Once received, the whole process on nr-cell addition is started.
It will fail quickly.
Many things are still missing.
What is not handled properly with this commit:
- in x2ap_eNB_handle_sgNB_add_req we hardcode the gNB ID
- nr triggering is done if we receive a measurement but this measurement is
not analyzed at all
- no timers (T_dc_overall, T_dc_prep) and as is the code fails and then the
next triggering after UE reconnection will not work (x2 ID are not well
handled here and there in the code)
Note also that the gNB part has not been looked at all for this commit.
This is work in progress...
In TDD mode, CQI requests are not possible in special subframes (at
least for some TDD configurations, see 36.213 7.2.3 that says "a
DL subframe is valid if it does not contain a DwPTS field if the
length is less than 7680 Ts").
In the code, we simply disable CQI requests in special subframes,
no matter what the length of DwPTS.
A problem can arise if the DCI0 for a given UE are sent only in
those special subframes. In this case the UE will never report
CQI and the eNB will use low MCS for this UE, impacting performances.
Another, related, problem is when there are several UEs. There again
one UE might always get its DCI0 in special subframes and thus never
report CQI. There again, performance issues.
This commit is an attempt to improve the situation.
It does two things.
1 - tag the UE as schedulable in the function UE_is_to_be_scheduled
if the cqi_req_timer is expired
2 - use cqi_req_timer as a criterium when ordering UEs for UL scheduling
The value chosen for the expiration of the cqi_req_timer in
UE_is_to_be_scheduled is quite high (300) because as the code is
today we may overschedule the UE for short bursts until we receive
a CQI from the UE. [TODO: fix the code properly to avoid this behavior.]
Note: the fairRR scheduler has not been analyzed and this commit may
not fix anything in case the fairRR scheduler is used.
- send RRC Connection Reconfiguration with dummy ENDC data by doing:
telnet localhost 9001
and press enter when the ENDC UE is connected to the eNB to send it
For whatever reason, ru->frame_parms was NULL and the RRU crashed.
Let's allocated memory.
Also, don't do fp = ru->frame_parms in ru_thread, it seems that it
takes the value before allocation (so: NULL) and the code crashes
later on.
Maybe it's not the correct solution. To be refined at some point.
The 5G phone OPPO has a very big UE capability (> 2KB).
We need bigger buffers to transfer this, especially in x2 handover.
Also the sctp messages need a bigger buffer.
Note: in sctp, we didn't check for partial messages, it's now
done. When detected, we exit. To be redone differently
if needed. (Look for "if (!(flags & MSG_EOR))".)
This used to be done to ease power estimation in the UE,
but this is not correct. Let's put no energy in the REs
with no DCI data, which is what needs to be done.
Plus it consumes a lot of CPU because of calling taus()
way too much.
To be used when you send data to another host.
On the other host, to avoid ICMP traffic about the port
not being open, do:
./nc -l -u -p 9999 > /dev/null
You need to restart this command each time you run macpdu2wireshark.
You can use any other program that will accept UDP packets on the
port 9999 (default port of macpdu2wireshark, change if you use another
port of course).
Some computation has been fixed in PUCCH reception.
SNR has been fixed, uses measurement instead of
a fixed value for the noise.
normalized_rx_power and target_rx_power have been removed,
replaced by snr and target_snr. All the files using those
variables have been updated.
The value was set to 20 which means -120 dB. Setting this value means
that the UE reports an event only if the RSRP of the serving cell
is lower than -120 dB.
In the lab, we get values of around -70, and to go as low as -120
means a very degraded environment. This is not practical.
Let's disactivate the setting of this parameter for the moment so that
the UE reports an event without taking into consideration the RSRP
of the serving cell.
With this hotfix, the X2 handover works much better.
When pushing traffic with iperf the UE was crashing.
The argument passed to pthread_mutex_timedlock is absolute time based
on the CLOCK_REALTIME timer, not relative time. That seems to be the
root cause of the bug. (That there is a timeout is another story.)
This commit uses absolute value.
Also we separate cases between IS_SOFTMODEM_BASICSIM / IS_SOFTMODEM_RFSIM
and standard realtime UE. In the 'sim' modes we don't care about
timeout and just call pthread_mutex_lock. It seems to be the idea
of the original work. If not, then to be fixed.
In the configuration file, to enable measurements, add:
enable_measurement_reports = "yes";
Note that if x2 is enabled then the option 'enable_measurement_reports'
is not taken into account and the measurements are enabled.
Not much major changes. In openair1/PHY/LTE_UE_TRANSPORT/dci_tools_ue.c,
in the function generate_ue_dlsch_params_from_dci,
'harq_pid' was removed and dci_info_extarcted.harq_pid is now used for
all cases.
The ue T tracer only deals with PHY signals (no MAC, RLC, PDCP, RRC).
- size of PUCCH has been fixed to:
- 2 RBs for N_RB_UL = 25 (1 RB at top of resource grid, 1 RB at bottom)
- 4 RBs for N_RB_UL = 50
- 6 RBs for N_RB_UL = 100
this is arbitrary and will need some rework at some point.
This may be also wrong. PUCCH size actually depends on DL traffic
(if the ack/nack is not done in PUSCH) and scheduling request
configurations.
- add sched_frame %= 1024 at one needed place
- reserve RBs for retransmission
this was not done so new transmissions were scheduled in the same
RBs. Since the code works with the notion of 'first_rb' only, it
was decided to skip all RBs lower than those retransmitted. This
works but is not correct (imagine we have to retransmit RB 23, then
all RBs < 23 will not be used for new transmission). The work to
fix this properly is complex, a lot has to change, so let's do it
this simple way for now.
- sort_ue_ul was not correct
- add the function maxround_ul to use the correct 'round' (the one
from DL was used, which is totally wrong)
- be sure to use the correct frame/subframe to get the correct HARQ pid
For retransmission, let's use cqi_req used for the 1st transmission.
Maybe incorrect, should check the specs. (In the worst case, we
simply won't decode this transmission at all. No big deal.)
end_of_burst_delay is used to stop TX only "after a while".
If we stop right after effective signal, with USRP B210 and
B200mini, we observe a high EVM on the S subframe (on the
PSS).
A value of 400 (for 30.72MHz) solves this issue. This is
the default.
This default value can be changed in the configuration file.
For example:
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 20
att_rx = 0;
bands = [7];
max_pdschReferenceSignalPower = -27;
max_rxgain = 105;
eNB_instances = [0];
sf_extension = 312;
end_of_burst_delay = 200;
}
);
Here we would set a value of 200.
The value to put in the configuration file is for
30.72MHz. The value is scaled accordingly at runtime
(thus only one value to set for every RB configuration,
25, 50 or 100, leading to less problems when adapting
configuration files).
This option is for experts and should not be changed
randomly.
Start of burst is to start TDD DL transmission in the driver
(tested with USRP for the moment).
End of burst is to stop DL transmission.
Start of burst can only happen for a DL subframe when the
previous subframe was an UL subframe.
End of burst can only happen for an S subframe.
It's impossible for a subframe to be both the start of a burst
and the end of a burst.
This can be checked with eg. http://niviuk.free.fr/lte_resource_grid.html
(or reading the specs).
Cedric Roux