- a new section in the configuration file to select security algorithms,
with new code to deal with it
- cleanup CG-ConfigInfo: specs seem to indicate that we must not
add mcg_RB_Config; the gNB has to deal with that
- as a consequence, modify fill_default_rbconfig() that is called in
every cases and needs security and bearer parameters
The new section in the configuration file looks like:
security = {
# preferred ciphering algorithms
# the first one of the list that an UE supports in chosen
# valid values: nea0, nea1, nea2, nea3
ciphering_algorithms = ( "nea0", "nea2" );
# preferred integrity algorithms
# the first one of the list that an UE supports in chosen
# valid values: nia0, nia1, nia2, nia3
integrity_algorithms = ( "nia0" );
};
The code is forced to use nea2, no matter what the UE supports.
After 2^18 PDCP packets, it will fail to work (we don't use HFN yet).
These limitations will be fixed in later commits.
The existing security function was not reused, because it does too
much memory allocation and initializes the security context at each
ciphering. So here comes nr_pdcp_security_nea2_cipher(). And also
the ciphering is done inplace. To be changed if necessary.
There was a problem with several UEs in the wireshark log. It seems that
wireshark needs the UE id otherwise it gets confused and sees retransmissions
where it's just another UE connecting and doing the same as a previous
UE.
Let's put kind of a UE id. Each RNTI seen by macpdu2wireshark gets an UE id
assigned the first time it's seen in a trace.
This is a bit hackish but seems to be fine.
We could have added UE_id in all the traces, that is change the T() calls
in the softmodem. It was less work to do it as it is, ie. only touch
macpdu2wireshark.c.
The RAR uses the same UE id all the time, may be a problem. To be refined
if needed.
The necessity of SOstart/SOend was understood after email exchanges with
David Breaux <davidbreaux67@gmail.com>.
See openair2/LAYER2/rlc_v2/tests/test46.h for some details.
Basically if we NACK without SOstart/SOend then the other end of the RLC
channel will consider all the bytes as NACKed and will have to resend them
all. If another status is then reported before all the bytes are sent,
and because we don't use SOstart/SOend this status will NACK all the bytes
again, then all the bytes are to be sent again. And the cycle repeats.
It will end with a max retx reached (which triggers RLF, Radio Link Failure).
The function put_bit in openair2/LAYER2/rlc_v2/rlc_pdu.c has been changed
too, maybe introducing some performance issues.
There was a problem with SN size. It was hardcoded to 12 bits (so max
sn = 4095) but we configure the UE with 18 bits. After a while, iperf
didn't work anymore because of this (what a surprise!).
So let's get the correct value from pdcp_Config.
And while we're at it, let's store also discard_timer and t_reordering
that will be used later by a proper NR PDCP layer (which is currently
work in progress).
RLC has timers. We need to keep track of time. We chose to not use
realtime but 'processing time'. That is we send a tick to RLC for every
subframe when it is processed by the softmodem. Before this commit we
used to increase time in the function mac_rlc_status_ind which may not be
called every subframe (especially in TDD mode). So we need another way
to keep track of time.
We introduce rlc_tick() and call it in eNB_dlsch_ulsch_scheduler, which
is called every subframe, both in FDD and TDD.
We also call rlc_tick() in the function ru_thread_synch() because
pdcp_run() and rrc_rx_tx() are called there too.
It may not be the best solution. To be revised if needed.
Note: the UE has not been touched. Some modification is needed for the UE
too, most probably.
This "error" is not a real error.
openair2/LAYER2/nr_rlc/tests/test.c includes testXX.h to define the array
int test[] and by design test[2] always exists.
Let's simply suppress the reporting of this error.
The T tracer macpdu2wireshark has been modified to handle the new traces.
The usage is the same as for LTE.
In NR the RACH is logged as an LTE RACH. Maybe we'll change that in the
future. Looking at the source code of wireshark, I could not find any
way to report NR RACH. Maybe they forgot it. Or I did not search correctly...
A test with band 79 was not working. It turns out that the computation
of the frequency from the NR-ARFCN was giving a wrong value.
After fixing band 79 as found in this commit, the frequency was correct.
The array nr_bandtable has then been reviewed fully and all the values
that were wrong have been changed. The check of correctness was done
using the website https://www.sqimway.com/nr_band.php
dedicated_DRB was not set properly when the NSA UE sends
ReconfigurationComplete so the wrong code was executed below
(we had dedicated_DRB == 0). Let's put a value that does
nothing (-1 seems fine).
After the UE disconnects, the next connection fails
because the gNB cannot decode Msg3. The root cause
seems to be this ul_valid_re_per_slot not set to 0.
Setting it before the test fixes the problem and
does not seem to impact anything else.
Some data remains in the PHY of the gNB after UE removal by
upper layers. After some connection/deconnection/reconnection
the gNB will exit because there is no free space in PHY.
This commit adds some global variables shared by MAC and PHY.
The function mac_remove_nr_ue puts UEs to be removed in it
and the function rxtx removes what needs to be removed.
This is a hack. It will be removed at some point in time.
The real way to remove in the PHY should be to release
data after some time of inactivity in the PHY, which would
mean the UE has been removed in upper layers. Kind of
timer-based thing. There should be no communication between
PHY and MAC.
This commit introduces several enhancements in X2AP and RRC to deal
with ENDC. The main goal is to deal with UE's on/off and with various
errors.
The following work is included:
- DC prep and DC overall X2 timers
- X2 messages for UE release and DC timers' timeout
Open problems:
- what to do when the UE sends an scg Failure? This commit removes
the UE. And this removal may not be correctly done
- UE removal in the gNB's PHY layer (a next commit is coming,
but it is hackish and will need a rework)
RLC has timers. We need to keep track of time. We chose to not use
realtime but 'processing time'. That is we send a tick to RLC for every
subframe when it is processed by the softmodem. Before this commit we
used to increase time in the function mac_rlc_status_ind which is called
for every subframe in the eNB, but not in the gNB (at least not in the
current gNB). So we need another way to keep track of time.
The function gNB_dlsch_ulsch_scheduler is called for every slot. It seems
to be the perfect candidate to send a tick to RLC for every subframe. We
take care of subcarrier spacing to send every subframe (one subframe is
always 1ms), not every slot (slot duration depends on subcarrier spacing).
It may not be the best solution. To be revised if needed.
Note: the UE has not been fixed. Some modification is needed for the UE
too, most probably.
c_SRS was 61, which does not fit for 106 PRBs as it seems. Value 0 works.
Maybe not the right thing to do though (see 38.211 6.4.1.4.3,
table 6.4.1.4.3-1).
Also it seems necessary to pass desired LTE/NR bands when requesting
LTE UE capabilities. Today this is hardcoded, to be done better at
some point. We should get the bands from the eNB configuration and
the eNB/gNB X2 exchanges.
c_SRS was 61, which does not fit for 106 PRBs as it seems. Value 0 works.
Maybe not the right thing to do though (see 38.211 6.4.1.4.3,
table 6.4.1.4.3-1).
Also it seems necessary to pass desired LTE/NR bands when requesting
LTE UE capabilities. Today this is hardcoded, to be done better at
some point. We should get the bands from the eNB configuration and
the eNB/gNB X2 exchanges.
When running the softmodem, we get the error:
fill_ulsch UE_id 0 nb_rb = 0
The code has changed some time ago and this log was left but is not
meaningful anymore.
hack: in schedule_ue_spec, 3 bytes are "reserved" (this should be
done better). An RLC AM entity may ask for only 2 bytes for
ACKing and get a TBS of 32 bits and due to these 3 reserved bytes we may
end up with only 1 byte left for RLC, which is not enough. This hack
prevents the problem. To be done better at some point. If the function
schedule_ue_spec is (has been) reworked, this hack can be removed.
Dig for "TBS - ta_len - header_length_total - sdu_length_total - 3"
in schedule_ue_spec.
This should be done better at some point.
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...
Cedric Roux