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)
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.
This commit introduces X2AP timers (t_reloc_prep, tx2_reloc_overall).
You need to set the values in the configuration file.
X2AP can be enabled or disabled in the configuration file too (disabled
by default).
Some deadcode was removed.
Since now pucch_n1_AN is taken from the configuration file,
it has to be set to 0. Value 32 will not work well, at least
in FDD. This has to be handled properly at some point
(do not use uplink resource blocks used by PUCCH for PUSCH).
'_' is not a valid character.
S1AP specs say:
ENBname ::= PrintableString (SIZE (1..150,...))
And X.680 (08/2015) 41.4 table 10 lists the valid characters for
PrintableString. '_' is not there. We replace by '-' which is there.
Connection of eNB to ppenair-cn has not been tested. There is no reason
why it would fail.
This commits contains several fixes to improve a multi-UE scenario.
This is not the end of the story.
Summary of work:
================
1 - improve SR (scheduling requests):
We configured n1pucch == 3 for scheduling requests, for all
UEs. We now use 71 - UE_id/10.
For it to work, it is vital that pucch_nRB_CQI in the configuration
file is set to 0, otherwise the SR will go to an RB used for
PUSCH and uplink decoding will fail whenever an UE does SR.
Note that we will have problems with 20MHz when we use a CCE that
let the UE send the ACK/NACK using a n1pucch allocated for SR,
because when the PDCCH is of size 3, we can have 87 CCEs
and it may lead to an n1pucch colliding with one for SR.
The work done in this patch is a quick solution, seems to work
with 10MHz.
The real solution is to disable the use of those CCEs that would
lead an UE to use a n1pucch colliding with an SR n1pucch. Then
we can use whatever n1pucch we want for SR, as long as the
scheduler protects them.
Impacted files: configuration files
openair2/RRC/LITE/MESSAGES/asn1_msg.c
2 - some fixes for uplink scheduling:
- Do not use PRACH for PUSCH, that leads to too many false
PRACH detection. Plus the PUSCH receiving may fail if one
UE uses the PRACH at the same time.
- Take care of retransmissions. That was not done at all, so
we could allocate one RB to several UEs. The current design
of the code makes it hard to do it properly, so we chose a
quick and dirty solution, which is to increase "first_rb"
to skip any RB used for retransmission. In this process we
may skip a lot of free RBs. A proper solution is needed here.
- Do not allocate the last RB. This one is used for PUCCH.
It was sometimes allocated to PUSCH.
- In the pre-processor we didn't pre-allocate RBs to UEs
with an empty buffer status. We didn't check if the UE
sent an SR. For example in a three UEs scenario, we
could have the third UE never scheduled in the uplink.
- rb_table_index was not decreased properly, so we allocated
too much RBs to some UEs and thus not enough to others.
Impacted files: openair2/LAYER2/MAC/eNB_scheduler_ulsch.c
openair2/LAYER2/MAC/pre_processor.c
openair1/SCHED/phy_procedures_lte_eNb.c
3 - some fixes for downlink scheduling:
- The check on CCE allocation was not correct. We did something
like:
if (cce allocation is possible) {
prepare
}
We should have done:
save current cce allocation
if (cce allocation is possible) {
allocate cce
prepare
}
reset current cce allocation
Basically, when we scheduled several UEs, they were checked
separately, and the totality of them was not checked.
Impacted file: openair2/LAYER2/MAC/eNB_scheduler_dlsch.c
- The retransmissions are probably not handled correctly.
Check in openair2/LAYER2/MAC/pre_processor.c, near
the comment "// control channel or retransmission",
the case "round > 0" was added. It's probably not enough,
even maybe not correct.
- Change SF05_LIMIT with SF0_LIMIT. We accept to use
central blocks in SF 5. The code was also not correct,
vrb_map was not set properly because the loop on j
was wrong for the last RBG (which can have one less
RB than the others).
This is not satisfying. The real solution is to use the
central RBs and check that the MCS used is compatible
with the numbers of resource elements allocated (we don't
want to put too more data bits than what fits).
4 - some fixes in PUCCH decoding:
See: openair1/PHY/LTE_TRANSPORT/pucch.c
Probably not enough. Some more work and analysis is
required for a proper use of the PUCCH. What we see
is that the PUCCH constellation gets wrong when there
are several UEs, meaning the received ACK/NACK is
not properly decoded (this, or something else...).
5 - several fixes/checks added here and there:
- The final allocate_CCEs in eNB_dlsch_ulsch_scheduler
is checked and we brutally exit if it fails.
- We exit in get_num_pdcch_symbols in case of failure
(this should never happen anyway, no big deal normally).
- Some logs added or changed to error/warning instead
of debug.
- In dlsch_scheduler_pre_processor an abort() was added.
The code here looks suspicious.
- In assign_max_mcs_min_rb, rb_table_index was not set
to 2, the value 0 was used. This was not correct.
What remains to be done:
========================
- Correct CCE allocation (take into account SR n1pucch,
check that all the n1pucch that will be used are "compatible").
- Take into account the PHICH when scheduling uplink. As of
today it is very possible to have two UEs use the same PHICH
group and PHICH sequence index. We can use n_DMRS in the DCI
to have uniqueness (see 36.213 table 9.1.2-2). We can drop an
allocation if there is no free PHICH group/sequence index for
a given UE.
- When there is an uplink retransmission in the PRACH, we have
to disable PRACH detection. It is possible that one UE does
PRACH at the same time, but then what to do? We could use
DCI0-based retransmission in this specific case maybe...
- Handle free RBs in uplink in a much better way in case of
a retransmission. We may have a lot of free unused RBs with
the current code.
- Check downlink retransmissions. Not much has been done there.
- Surely more stuff not clear yet. In some situations we don't
have a good behavior of the system. Hard to describe more
precisely at this point.
Raymond Knopp