The symptom: when two UEs do uplink traffic at the same time, the
eNB fails to decode data sometimes. This has been seen with FDD
and 50 RBs. This generates a cascade of other problems leading to
disconnection/reconnection events seen in the log.
The problem: there are probably many, but one obvious bug was found
while analyzing some logs. Scheduling in the same TTI one UE's uplink
traffic and random access (msg3) was done in the same RB.
This commit fixes this simple case. It is probably not the end of
the story.
This is a hotfix, that does not change the code much.
We need to use vrb_map_UL properly all over the places. Today is
not used, but this is the way to go (most probably).
The bug popped up when one UE was doing TCP UL iperf and a second UE
attempted to connect. A crash of the eNB happened because we changed
the wrong NFAPI structure in a TTI where both UEs are scheduled.
Something like that.
- there can be a race between the FlexRAN agent reading the RC.mac and its
allocation in main.c
- In order to circumvent this, change the allocation by allocating
everything "into" a local variable
- finally "make it visible" by storing the pointer in RC.mac
- until now, on every iteration, the scheduler checked for changed parameter
(and verified some)
- this functionality moves to the FlexRAN Agent, which verifies all parameters
* individually, e.g. Max MCS <= 28 for DL
* group-based, e.g. the sum of slice percentages is <= 100
- slice configuration changes are only applied if all verifications pass
- it is assumed in the scheduler, that configuration passed from outside is
correct and can be used "as-is"
fix accounting setting
- uncomment "Couldn't find RNTI for UE X" in UE_RNTI() and rb_alloc in
pre_processor_reset() as they only inflate the debug output with little
benefited
- "doing ue_schedule_spec" is now displayed for individual UEs (and individual
CCs)
- show messages when not scheduling UE in ue_schedule_spec() due to invalid
slice or if not in RRC_CONNECTED
- slice multiplexing resorts UE_list for its purposes with restoring the
original order
- in order to keep the order in UE_list, resort to original order after
multiplexing
- ideally, this would happen in the multiplexing but currently, the slice_idx
is not passed to multiplexing (it does not care), so this cannot be done ATM
Incoming slice configuration changes are buffered in an intermediate structure.
The MAC scheduler periodically polls the agent about changes. If there has been
a slice configuration change, apply it.
- introduce structure in RC for slicing conf (UL/DL)
- move global variables regarding slice configuration into RC
- change ue_slice_membership(): consider UL/DL
- remove the unnecessary header files
- set default parameters: one slice
Cedric Roux