Summary of changes:
- some work on better parallel processing of eNB
try the eNB with options: --fepw --codingw
- small changes for multi-UE simulation and simulation accuracy
(UE power levels)
- initial work for the UE to use TUN device instead of ue_ip.ko
only done for oaisim, default bearer, compile with:
./build_oai --ue-nas-use-tun <rest of options>
- fix compilation of dlsim/ulsim/oaisim by defining some needed
global variables
- fix compilation of oaisim: compile coding and params_libconfig
- fix running of if4p5 with low CPU count (oaisim was not working
on the machine 'haswell' because of this)
This work is based on work by NTT.
To use the code, do:
./build_oai --oaisim --ue-nas-use-tun -t ETHERNET -c
This commit only handles oaisim in S1 mode.
We won't handle noS1 mode.
Summary of changes:
- free configmodule memory when shutting down
It is possible to restart the lte-softmodem via the FlexRAN controller.
For this to work, the end_configmodule() method needs to be called when
shutting the lte-softmodem down so that the configuration can be read
again during a restart.
- Feature agent
Implements an agent ID, consisting of the OAI module ID, the OAI eNB ID
and the cell ID. The agent reads this information in its configuration
read function and forwards it to the controller.
This MR also contains some code forwarding SI info to the controller.
- various bugs fixed
- remove start_background_system from eNB softmodem
- fix memory leak when doing traffic
- disable ITTI dump (does someone uses this?)
- disable U-plane inactivity timer: it's very simple to put this back,
but as of now it comes with its own problems that we don't have time
to check/fix
Only ulsim and dlsim compile. The others (dlsim_tm4 pucchsim prachsim
pdcchsim pbchsim mbmssim) have been disabled.
Command line to compile: ./build_oai --phy_simulators
When doing TCP downlink traffic with iperf for several
hours, the memory consumption of lte-softmodem does not
stop to grow.
After analysis, this commit seems to be the only fix needed.
To be checked somehow.
The PHICH was not programmed for the last round (4) because it was
not programmed in rx_sdu but in schedule_ulsch_rnti, only in case
of a programmed retransmission (there is obviously no retransmission
programmed after the last round).
The case of Msg3 is not handled. To be done somehow.
Summary of changes:
- bug fix in the FlexRAN API (correct a check)
- bug fix for sending the right RNTI in a FlexRAN message
- fixes small bug in ulsim which kills one RX antenna in channel simulation.
Another simple but bad bug in ulsch_demodulation.c (bad access of avgU
array). This probably resulted in a performance degradation for non-ideal
channels, even for 1 antenna. The avgU was read in position 1 instead of
0 for 1-antenna and in positions 1 and 2 instead of 0 and 1 for 2-antennas.
- work from Nokia:
1) shared library loader, with integration for oai devices, encoder and telnet server
2) telnet server (use build-oai --build-telnetsrv option and --telnetsrv softmodem option)
3) UE/eNB in different executables (lte-uesoftmodem and lte-softmodem + noS1 variants)
4) config module fixes and extensions
5) very preliminary NB-IoT integration preparation, using shared lib loader ( use make NB-IoT to build, after building the eNB softmodem)
6) Rename NB-IoT configuration sources from nbiot_ to NB-IoT_ to be consistent with other NB-IoT developments.
- various bugs fixed:
- try to avoid "buffer full" problem when pushing DL traffic
- add a stop_rf function in the RU
- cleanup - remove unnecessary calls to get_cpu_freq_GHz
(was disrupting realtime at startup, generating lots of UU and LL)
- cleanup MAC PDU generation
Compilation with Rel10 is not functional anymore.
Compilation of unitary simulator is not functional anymore.
fixes small bug in ulsim which kills one RX antenna in channel simulation.
Another simple but bad bug in ulsch_demodulation.c (bad access of avgU
array). This probably resulted in a performance degradation for non-ideal
channels, even for 1 antenna. The avgU was read in position 1 instead of
0 for 1-antenna and in positions 1 and 2 instead of 0 and 1 for 2-antennas.
1) shared library loader, with integration for oai devices, encoder and telnet server
2) telnet server (use build-oai --build-telnetsrv option and --telnetsrv softmodem option)
3) UE/eNB in different executables (lte-uesoftmodem and lte-softmodem + noS1 variants)
4) config module fixes and extensions
5) very preliminary NB-IoT integration preparation, using shared lib loader ( use make NB-IoT to build, after building the eNB softmodem)
6) Rename NB-IoT configuration sources from nbiot_ to NB-IoT_ to be consistent with other NB-IoT developments.
This is hack-level development.
With this commit you can do UDP DL traffic of say 100Mb/s over
a 5MHz link with one connected UE and the eNB should not crash
because of memory exhaustion. Of course on the receiver side
you won't get 100Mb/s and many many lost packets. But the system
should not crash. 1Gb/s does not work. So in any case try to
remain within some reasonable limits. There is no reason to
push more than twice the maximum achievable throughput of
the link.
This work is based on a patch proposed by Francesco Gringoli.
When the program exits it has to stop the streaming of the USRP.
The function exit_fun is supposed to do that. When quitting with
control+c (very common case) this function is not called. The
code is very unclear there, so let's add a stop_rf in the RU,
as there is already a start_rf.
If we don't call trx_end_func, then at the next run the USRP
device may be in an unstable state and behave improperly.
If the program crashes then the USRP device may be in an
unstable state. The only solution to this problem is to reset
the USRP device.
Maybe there is a way to clean the state of the device when we
open it, before we start using it. Sort of a cleanup before
use. That could be a better solution to "bad state after program
crash".
What has been tested:
- monolithic eNB only
The one in lte-enb.c disrupts the realtime. Using a B200mini with
20MHz bandwidth leads to the UE unable to connect for it seesms like
the UL and DL are not properly time synched because of this sleep
of one second that happens after the USRP streaming has started.
We see some random access attempts but the decoded preamble is
wrong.
This may be dependant on the setup. I had sporadic errors with
a B210, where sometimes the UE could connect and sometimes not.
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.
Some more fixes for some bad conflict resolutions.
I ran:
git diff 2018.w04 2018.w05
And saw some problems with config_sib2.
There was also something strange in openair2/LAYER2/openair2_proc.c
in the function dump_eNB_l2_stats. Maybe the fix is wrong for
this one. To be checked.
Doing an iperf UDP uplink test, we could reach only 6Mb/s
with very good radio conditions instead of around 8Mb/s.
It turns out the MCS was limited to 16.
With this commit, we are back to a bit more than 8Mb/s
as it used to be.
(This is with a 5MHz bandwidth.)
Doing airplane mode off to connect a cots UE followed by airplane mode on
to disconnect it gives very bad results (bad disconnection with lots of
UL failures followed by lots of logs in the eNB). It used to work properly
after the work done by Xu Bo.
It turns out that in 2018.w04 things were still working okay. But
in 2018.w05 no.
So I ran:
git diff 2018.w04 2018.w05
And I checked all the modifications that I thought were relevant
(everything related to the UE, oaisim, if4 and fapi has not been checked).
This commits takes back the version of 2018.w04.
The modifications in openair2/RRC/LITE/rrc_eNB.c are necessary, I think.
The other modifications may not be necessary or even wrong. To be checked
at some point.
Summary of changes:
- fix MAC indentation
- bug fixes:
- fix uplink over-scheduling
- fix CQI updating (it was done even when it shouldn't)
- fix rrc rel10 compilation
- some minor bug fixes related to ASN.1
'_' 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.
The problem that may happen is that when the UE does not transmit
on PUCCH (for whatever reason) we may get no signal at all, and
thus compute a very low CQI. Later on we may ask the UE to transmit
louder which may lead to saturation and more problems.
The solution is simple: don't care about CQI in case of DTX
(and NACK also, as done for PUSCH).
Only FDD case done.
For TDD it seems that:
- nfapi structures are not correct. See nfapi_harq_indication_tdd_rel13_t
in nfapi/open-nFAPI/nfapi/public_inc/nfapi_interface.h, all the cases
(bundling, multiplex, ...) use nfapi_harq_indication_tdd_harq_data_t
- the function extract_harq does not handle TDD
S1AP specs say:
initialUEMessage S1AP-ELEMENTARY-PROCEDURE ::= {
INITIATING MESSAGE InitialUEMessage
PROCEDURE CODE id-initialUEMessage
CRITICALITY ignore
}
So let's use "ignore", not "reject".
The online decoder http://asn1-playground.oss.com/ did
not decode a message encoded by the eNB because of this.
Only the S1AP messages captured while doing a simple connection
of one UE have been tested with the online decoder.
So, not all the S1AP messages have been checked, maybe some
instances of this problem are still there.
It does not seem to harm the actual UE<->eNB<->EPC communication
(because we don't check the integrity of messages or because
asn1c does not do it), so it's not a big deal.
As reported by Emad Alizade:
According to "Issue255 256 257 paging reesta release" that has been
merged in develop version, we have a question: In rrc_eNB_free_UE()
function only all ulsch related memory of user has been cleaned, but
I think not only ulsch memory but also dlsch memory must be cleaned.
I tested the latest develop version and with repetition UE attach-detach
procedures we find that the dlsch memory has not been cleaned and after
repeat this sequence (45 times) assertion with cause UE_id!=-1 (no free
or exiting dlsch_context, dci_tools.c: fill_dci_and_dlsch() ) occurred
and no UE will be attached to system.
The fixes in this commit are from Emad Alizade.
Summary of changes:
- Implementation of paging (see issue #255 in gitlab)
- Implementation of RRC RE-ESTABLISHMENT (see issue #256 in gitlab)
- Implementation of RRC CONNECTION RELEASE (see issue #257 in gitlab)
Some modifications with timers have been done.
Expect (and report) problems, thanks.
What has been tested:
- monolithic eNB 5 and 10MHz with one commercial UE. UDP and TCP
traffic, uplink and downlink, with iperf (with a third party
EPC, not openair-cn). TCP downlink traffic is not stable.
Reason yet unknown. Will be fixed later.
Summary of changes:
- integration of Cisco work on nFAPI.
See commits 7757b9e7e7
and 922b5b595a for details.
- support Ubuntu 17.04 and 17.10
- bugfix: DCI padding bits
This bug made the system non-working because the DCIs for
SIBs were wrong. See commit c5ca2bd862
for details.
- fix issue 281: IQ record/playback explicit filename segv.
This commit fixes issues introduced by the previous commit.
Summary of work:
- cleanup:
- fix LOG_XX to be less verbose
- fix cmake_targets/CMakeLists.txt
- fix oaienv
- remove dead code
- bug fixes:
- in openair1/SCHED/fapi_l1.c we had:
eNB->pdcch_vars[subframe&1].num_dci = number_dci;
should be:
eNB->pdcch_vars[subframe&1].num_dci = 0;
This bug let the PHY send more DCIs than what should have been
sent because num_dci is incremented later on in the code.
This fix may be a problem for fapi mode, to be checked.
- add new T VCD traces
- revert openair1/PHY/TOOLS/file_output.c to 'develop' version
- remove thread_id in logRecord/logRecord_mt
- revert (and adapt) configuration files
- be careful when doing frame++, we need to % 1024
- revert target_rx_power in openair2/LAYER2/MAC/eNB_scheduler_ulsch.c
- NFAPI:
- the open-nFAPI code has been included in the repository. See nfapi/README.
Maybe we should "git clone" the Cisco repository instead. We have to be
careful of availability though.
What has been tested:
- monolithic eNB FDD 5/10MHz with one UE, iperf UDP/TCP uplink/downlink
Anything else may fail to work, especially the FAPI mode, which has not
been tested at all.
It has been chosen to not include the full history of commits
from David. He included a binary version of wireshark, probably
a modified one that understands NFAPI. Wireshark is released under
the GPL license, we cannot include it in the repository. We could
have done a next commit to remove this binary. But then it would
still be present in the history of commits, which may not be allowed.
And it would take space on disk. We could edit the history to remove
wireshark entirely. But this operation is too complicated.
There was also a pcap capture file, which has nothing to do in
the history of commits and would take space on disk. There again,
it's too difficult to edit the history to remove it.
There was a file .gitignore that was also removed.
The original history can be found on David's repository:
https://gitlab.eurecom.fr/daveprice/openairinterface5g/
The branch is: nfapi-ru-rau-split.
A copy of that branch has been included in the internal OAI
repository, for those who have access to it.
The branch is the same. The last commit ID is
9106438239e0bc626ff1fa1d97d911caadd0fbb9.
You can compare the current commit with the commit 9106...
to see what differs.
The current commit has to be considered non-working.
The commit following the current commit will fix problems with
the work in the current commit.
If you use git bisect, don't spend time analyzing the current
commit.
Basically, build_helper has been adapted so that:
./buil_oai -I -w USRP
works for Ubuntu 17.04 and 17.10.
Concerning those systems:
- compilation with "--eNB --UE -w USRP" works
- the enb softmodem runs on 17.04 (not tested on 17.10)
- nothing else has been tested.
Users should report any problem.
The problem is the following (as reported by an user):
"one UE is attached to OAI system. UE is near the antenna. Try to detach
the UE and attach again. Repeat this procedure for 5-6 times. OAI system
does not work and any the UE can not attach to this system. I use TEMS
software and I can see MIB signaling on this UE but UE can not decode SIB1
and SIB2."
What happens is that the DCI for SIB1 and SIB2 is not cleared before
use. That is the bits in the 'padding' field keep the values that were
set before. If the structure has been used to transmit other DCIs
(eg. for UEs) in the past, it may be reused with some of those bits set
to 1. When receiving this DCI, the UE won't accept it because it
gets some bits at 1 where it expects them to be 0.
The short-term/quick solution is to clear the 'padding' field.
A better solution would be to rewrite this part of the code,
which is way too complicated for what it does. But this takes
too much time.
In dci.h the field 'dummy' of some structures was renamed to 'padding'.
The fields 'padding32' and 'padding64' were also renamed to 'padding'
for consistency.
Some structures (DCI2B_1_5MHz_TDD, DCI2B_10MHz_FDD, DCI2D_1_5MHz_FDD,
DCI2D_5MHz_FDD, DCI2D_10MHz_FDD) had a 'padding' field at the end, which
was renamed to 'padding0'. I don't know if this field should be here at all.
To me this field looks very suspicious. When we test DCIs 2B and 2D we
should be careful.
Cedric Roux