The code was very unclear and potentially buggy.
This new version is more robust.
We can waste up to 2 bytes because the last header in the MAC PDU
does not contain a length field and when we request data from RLC
we suppose a 3-bytes MAC header. This might be optimized at some
point, but the benefit would be low.
This commit also contains some general cleanup:
- formatting
- variables' types: let's use 'int' instead of trying to be clever
by using small types that may generate bugs if the value is
too big
- remove 'tpc_accumulated' which was globally used for all UEs
and has no purpose other than logging. We may want to rework
a bit the TPC machinery at some point. As the code is today
we may repeatedly send TPC over and over without caring about
the 3GPP limits, in which case no one knows how the UE is
supposed to behave: does it clamp the current max value or does
it accumulate over and over and take the clamped value to compute
its actual power? If we send a reverse TPC (reduce power instead
of increase) does it do it immediately or does it have to decrease
n+1 times if we previously ordered it to increase n times?)
We do not address the problem of prioritizing LCIDs. As of today there
is only one dedicated traffic channel (DTCH), so it's not a problem
at this point.
What has been tested:
- monolithic eNB 5/10/20MHz with one cots UE, TCP/UDP UL/DL. At 20MHz the
machine used was not capable of keeping up, generating lots of Us
and Ls when the throughput reaches 60Mb/s. USRP B210 was used.
Running TCP DL traffic with one connected UE showed a lot of
fluctuations in throughput. After analysis it was found that
sometimes the RLC UM PDU was not correct. It contained one byte
more than it should. On the receiver side, the TCP packet
contained in the RLC packet seems to be rejected by the TCP
stack of the UE (it has one byte more than it should),
leading to a brutal reduction of the throughput, probably due
to some congestion detection in the TCP implementation.
Or something.
This hotfix seems to solve the problem. Using iperf in downlink
with a 5MHz eNB, we see no more fluctuations, the traffic is
very steady at 16.8Mb/s, as reported by the iperf server running
on the phone. (17.5 in the PHY plot of the T tracer.)
A rewrite of both the MAC and RLC UM packet generation is needed.
The code is way too complex for what it does and may contain
several similar problems that only trigger in specific rare
conditions.
Summary of changes:
- fix dlsim/ulsim
- fix centOS compilation
- Move the accounting phase of the DL pre-processor in a separate procedure
and fix some issues
- additional Mac stats and Improvements
- minor fix in test setup v2
With value 4 when connecting one UE and doing some downlink
iperf TCP there is a crash. Probably due to the multiple wrong
RA detected leading to uplink failure of fake UE that never
sends Msg3 (because, well, there is no other UE).
This is another problem that will be fixed at some point.
Anyway, this value 4 fails. Let's put back 3.
Cedric Roux