Skip to content
Snippets Groups Projects
  1. Sep 28, 2018
  2. Aug 23, 2018
    • Konstantinos Alexandris's avatar
      minor fixes for x2 + modify conf files · 3b3b9718
      Konstantinos Alexandris authored
      The configuration file has now to contain ENB_IPV4_ADDRESS_FOR_X2C and
      ENB_PORT_FOR_X2C in the NETWORK_INTERFACES section.
      
      For example:
      
          NETWORK_INTERFACES :
          {
              ENB_INTERFACE_NAME_FOR_S1_MME            = "eth0";
              ENB_IPV4_ADDRESS_FOR_S1_MME              = "192.168.12.111/24";
              ENB_INTERFACE_NAME_FOR_S1U               = "eth0";
              ENB_IPV4_ADDRESS_FOR_S1U                 = "192.168.12.111/24";
              ENB_PORT_FOR_S1U                         = 2152; # Spec 2152
      
              ENB_IPV4_ADDRESS_FOR_X2C                 = "192.168.12.111/24";
              ENB_PORT_FOR_X2C                         = 36422; # Spec 36422
          };
      3b3b9718
  3. Jul 30, 2018
  4. Jul 05, 2018
  5. Jun 30, 2018
  6. Jun 29, 2018
  7. Jun 28, 2018
  8. Jun 14, 2018
    • Cedric Roux's avatar
      set value of pucch_n1_AN to 0 everywhere by default · cce51f69
      Cedric Roux authored
      Since now pucch_n1_AN is taken from the configuration file,
      it has to be set to 0. Value 32 will not work well, at least
      in FDD. This has to be handled properly at some point
      (do not use uplink resource blocks used by PUCCH for PUSCH).
      cce51f69
  9. Feb 22, 2018
  10. Feb 09, 2018
    • Cedric Roux's avatar
      bugfix: fix eNB name in configuration files · 11fe5f97
      Cedric Roux authored
      '_' 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.
      11fe5f97
  11. Oct 23, 2017
  12. Oct 18, 2017
  13. Oct 17, 2017
  14. Aug 24, 2017
    • Cedric Roux's avatar
      improve multi-UEs scenario · 622b919b
      Cedric Roux authored
      This commits contains several fixes to improve a multi-UE scenario.
      
      This is not the end of the story.
      
      Summary of work:
      ================
      
      1 - improve SR (scheduling requests):
      
          We configured n1pucch == 3 for scheduling requests, for all
          UEs. We now use 71 - UE_id/10.
      
          For it to work, it is vital that pucch_nRB_CQI in the configuration
          file is set to 0, otherwise the SR will go to an RB used for
          PUSCH and uplink decoding will fail whenever an UE does SR.
      
          Note that we will have problems with 20MHz when we use a CCE that
          let the UE send the ACK/NACK using a n1pucch allocated for SR,
          because when the PDCCH is of size 3, we can have 87 CCEs
          and it may lead to an n1pucch colliding with one for SR.
      
          The work done in this patch is a quick solution, seems to work
          with 10MHz.
      
          The real solution is to disable the use of those CCEs that would
          lead an UE to use a n1pucch colliding with an SR n1pucch. Then
          we can use whatever n1pucch we want for SR, as long as the
          scheduler protects them.
      
          Impacted files: configuration files
                          openair2/RRC/LITE/MESSAGES/asn1_msg.c
      
      2 - some fixes for uplink scheduling:
      
          - Do not use PRACH for PUSCH, that leads to too many false
          PRACH detection. Plus the PUSCH receiving may fail if one
          UE uses the PRACH at the same time.
      
          - Take care of retransmissions. That was not done at all, so
          we could allocate one RB to several UEs. The current design
          of the code makes it hard to do it properly, so we chose a
          quick and dirty solution, which is to increase "first_rb"
          to skip any RB used for retransmission. In this process we
          may skip a lot of free RBs. A proper solution is needed here.
      
          - Do not allocate the last RB. This one is used for PUCCH.
          It was sometimes allocated to PUSCH.
      
          - In the pre-processor we didn't pre-allocate RBs to UEs
          with an empty buffer status. We didn't check if the UE
          sent an SR. For example in a three UEs scenario, we
          could have the third UE never scheduled in the uplink.
      
          - rb_table_index was not decreased properly, so we allocated
          too much RBs to some UEs and thus not enough to others.
      
          Impacted files: openair2/LAYER2/MAC/eNB_scheduler_ulsch.c
                          openair2/LAYER2/MAC/pre_processor.c
                          openair1/SCHED/phy_procedures_lte_eNb.c
      
      3 - some fixes for downlink scheduling:
      
          - The check on CCE allocation was not correct. We did something
          like:
      
              if (cce allocation is possible) {
                prepare
              }
      
          We should have done:
      
              save current cce allocation
              if (cce allocation is possible) {
                allocate cce
                prepare
              }
              reset current cce allocation
      
          Basically, when we scheduled several UEs, they were checked
          separately, and the totality of them was not checked.
      
          Impacted file: openair2/LAYER2/MAC/eNB_scheduler_dlsch.c
      
          - The retransmissions are probably not handled correctly.
          Check in openair2/LAYER2/MAC/pre_processor.c, near
          the comment "// control channel or retransmission",
          the case "round > 0" was added. It's probably not enough,
          even maybe not correct.
      
          - Change SF05_LIMIT with SF0_LIMIT. We accept to use
          central blocks in SF 5. The code was also not correct,
          vrb_map was not set properly because the loop on j
          was wrong for the last RBG (which can have one less
          RB than the others).
      
          This is not satisfying. The real solution is to use the
          central RBs and check that the MCS used is compatible
          with the numbers of resource elements allocated (we don't
          want to put too more data bits than what fits).
      
      4 - some fixes in PUCCH decoding:
      
          See: openair1/PHY/LTE_TRANSPORT/pucch.c
      
          Probably not enough. Some more work and analysis is
          required for a proper use of the PUCCH. What we see
          is that the PUCCH constellation gets wrong when there
          are several UEs, meaning the received ACK/NACK is
          not properly decoded (this, or something else...).
      
      5 - several fixes/checks added here and there:
      
          - The final allocate_CCEs in eNB_dlsch_ulsch_scheduler
            is checked and we brutally exit if it fails.
      
          - We exit in get_num_pdcch_symbols in case of failure
            (this should never happen anyway, no big deal normally).
      
          - Some logs added or changed to error/warning instead
            of debug.
      
          - In dlsch_scheduler_pre_processor an abort() was added.
            The code here looks suspicious.
      
          - In assign_max_mcs_min_rb, rb_table_index was not set
            to 2, the value 0 was used. This was not correct.
      
      What remains to be done:
      ========================
      
          - Correct CCE allocation (take into account SR n1pucch,
            check that all the n1pucch that will be used are "compatible").
      
          - Take into account the PHICH when scheduling uplink. As of
            today it is very possible to have two UEs use the same PHICH
            group and PHICH sequence index. We can use n_DMRS in the DCI
            to have uniqueness (see 36.213 table 9.1.2-2). We can drop an
            allocation if there is no free PHICH group/sequence index for
            a given UE.
      
          - When there is an uplink retransmission in the PRACH, we have
            to disable PRACH detection. It is possible that one UE does
            PRACH at the same time, but then what to do? We could use
            DCI0-based retransmission in this specific case maybe...
      
          - Handle free RBs in uplink in a much better way in case of
            a retransmission. We may have a lot of free unused RBs with
            the current code.
      
          - Check downlink retransmissions. Not much has been done there.
      
          - Surely more stuff not clear yet. In some situations we don't
            have a good behavior of the system. Hard to describe more
            precisely at this point.
      622b919b
  15. Jun 08, 2017
  16. Jun 02, 2017
  17. May 31, 2017
  18. Apr 14, 2017
  19. Apr 12, 2017
  20. Mar 27, 2017
  21. Mar 17, 2017
  22. Mar 10, 2017
    • Cedric Roux's avatar
      test setup v2: add TDD tests · 8e8fec1e
      Cedric Roux authored
      New tests: 0186xx for TDD with the huawei 3276 dongle.
      All necessary files to configure and use it have been added.
      Existing code has been adapted for the TDD tests.
      Only the test setup v2 has been adapted.
      The file test_case_list.xml has been changed to add tests
      0186xx, but only to work with test setup v2. It won't
      work with test setup v1. To be completed if needed.
      
      The tests are similar to FDD tests.
      Throughputs for TDD have to be adjusted, the throughputs
      of FDD are used for the moment.
      8e8fec1e
    • Cedric Roux's avatar
      cleanup test setup README file · e6cd9873
      Cedric Roux authored
      e6cd9873
  23. Feb 13, 2017
  24. Feb 03, 2017
  25. Jan 30, 2017
  26. Jan 24, 2017
  27. Jan 09, 2017
    • Rohit Gupta's avatar
      test setup v2: fix bad throughput for bandirch dongle · 9162c069
      Rohit Gupta authored
      The throughput for the bandrich dongle was limited to 13Mb/s in downlink
      UDP with iperf, with lots of packets lost (we sent 15Mb/s). TCP was
      working fine.
      
      Replacing /dev/ttyUSB2 by /dev/ttyUSB0 for wvdial solves the issue.
      
      We also had to have separate data/control links. (See bandrich.txt
      in cmake_targets/autotests/v2/actions for full details.)
      9162c069
  28. Jan 06, 2017
  29. Dec 14, 2016
  30. Dec 09, 2016
  31. Dec 02, 2016
Loading