The independent retransmission of TB1 will take data from the last PUSCH
report, when both TB were active and keep it for all the retransmission
rounds.
Now the TPMI for the retransmissions of TB1 is passed from the command
line with -K(tpmi): -K0 for Alamouti, -K5 for PUSCH column1 , etc.
This hotfix does not change the processing at all.
At this point, stat_re == 0, so the behavior is the
same as before. But the code was wrong. There should
have been no test, it's a NACK, period.
It creates more problems than it solves.
We replace this approach by a straightforward
synchronous one.
Now in the downlink, at frame f and subframe s
we use HARQ process (f * 10 + s) % 8.
This is similar to uplink scheduling.
set transmission mode in phy_config_dedicated_[UE|eNB] after RRCConnectionReconfiguration(eNB) and RRCConnectionReconfigurationComplete(UE)
add ue_TransmissionMode in RrcConfigurationReq
added ue_transmission_mode and nb_antenna_ports to eNB config file
transmisison mode gets set with RRCReconfiguration
That led to uplink two resource blocks to fail being decoded (not always),
due to wrong channel estimation. (As was the previous hotfix for five
resource blocks.)
This commit also includes some cleanup of some historical code that is
not relevant anymore.
T
I did some compilation tests using `./build_oai -s --run-group "0101*"`, all was fine.
I ran `lte-softmodem` with the sequans and let it run for a while with both
uplink and downlink UDP low throughput traffic, all was fine.
I ran some TCP tests, downlink 14 Mb/s (because the sequans does not report
a CQI of 15 but 14 maximum, so we don't go to maximum MCS, so 14 Mb/s instead
of 16) with a very clean radio (almost no error in the HARQ processes).
For uplink things are not so clean, it starts at 6 Mb/s and after a while goes
down to 2/3 Mbit/s. Lot's of errors in the HARQ processes, mostly uplink but
also downlink.
This is a both with and without T activated.
So to me it's fine.
The T tracer is a debugging tool. When it's not enabled,
it has zero impact on the processing. I think we need to
do very little tests before merging. I'll let you decide
but to me it's okay!
See merge request !36