- 11 Mar, 2018 1 commit
-
-
Raymond Knopp authored
Conflicts: cmake_targets/CMakeLists.txt openair1/PHY/INIT/lte_init_ru.c openair1/PHY/defs.h openair2/ENB_APP/enb_paramdef.h targets/RT/USER/lte-ru.c
-
- 10 Mar, 2018 1 commit
-
-
Raymond Knopp authored
-
- 09 Mar, 2018 10 commits
-
-
Raymond Knopp authored
-
Raymond Knopp authored
modifications to default configuration files for oaisim and some minor chanes to lte-ru.c for simulator target
-
Cedric Roux authored
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.
-
Cedric Roux authored
End of line character has to be unix-style, not dos-style.
-
Cedric Roux authored
-
Cedric Roux authored
* bug fix in the FlexRAN API (correct a check) * bug fix for sending the right RNTI in a FlexRAN message
-
Cedric Roux authored
-
Cedric Roux authored
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.
-
Cedric Roux authored
Merge remote-tracking branch 'origin/develop-nbiotconf-shlibloader' into develop_integration_2018_w10 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.
-
Cedric Roux authored
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.
-
- 08 Mar, 2018 6 commits
-
-
oai authored
-
oai authored
-
oai authored
-
Cedric Roux authored
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
-
Cedric Roux authored
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.
-
Cedric Roux authored
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.
-
- 07 Mar, 2018 1 commit
-
-
Raymond Knopp authored
-
- 06 Mar, 2018 1 commit
-
-
Raymond Knopp authored
-
- 05 Mar, 2018 3 commits
-
-
Younes authored
Merge branch 'ru_rau_enhancement' of https://gitlab.eurecom.fr/oai/openairinterface5g into ru_rau_enhancement
-
Younes authored
-
Raymond Knopp authored
-
- 04 Mar, 2018 2 commits
-
-
Raymond Knopp authored
Merge branch 'ru_rau_enhancement' of https://gitlab.eurecom.fr/oai/openairinterface5g into ru_rau_enhancement
-
Raymond Knopp authored
-
- 03 Mar, 2018 2 commits
-
-
Younes authored
-
Raymond Knopp authored
-
- 02 Mar, 2018 10 commits
-
-
Raymond Knopp authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Raymond Knopp authored
Merge branch 'ru_rau_enhancement' of https://gitlab.eurecom.fr/oai/openairinterface5g into ru_rau_enhancement
-
Younes authored
-
Younes authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Younes authored
-
Cedric Roux authored
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.
-
- 01 Mar, 2018 1 commit
-
-
Robert Schmidt authored
has been introduced in commit 365ca71a
-
- 26 Feb, 2018 2 commits
-
-
Cedric Roux authored
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
-
Cedric Roux authored
Merge remote-tracking branch 'origin/fix-centos-network-device-compilation' into develop_integration_2018_w08
-