1. 23 Oct, 2017 1 commit
  2. 24 Aug, 2017 1 commit
    • 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
  3. 23 Aug, 2017 1 commit
    • Cedric Roux's avatar
      mobipass standalone driver · c866677a
      Cedric Roux authored
      How to use:
      
      1 - compilation of softmodem:
        ./build_oai --eNB -t ETHERNET
      
      2 - compilation of mobipass driver:
        cd cmake_targets/lte_build_oai/build
        make oai_mobipass
        ln -sf liboai_mobipass.so liboai_transpro.so
      
      3 - configuration:
        edit the configuration file, set "node_timing" to
        "synch_to_mobipass_standalone"
        that is, have the line:
          node_timing               = "synch_to_mobipass_standalone";
      
      4 - run:
        run as usual: sudo ./lte-softmodem -C <configuration file>
      c866677a
  4. 21 Aug, 2017 1 commit
  5. 08 Aug, 2017 2 commits
    • Cedric Roux's avatar
      hotfix: protobuf-c compilation failure · 45212d3b
      Cedric Roux authored
      protobuf-c does not compile anymore.
      
      Let's handle this a bit better.
      
      We now install protobuf and protobuf-c only for the
      flexran agent. That is, if you want to use the flexran
      agent, you need to install protobuf/protobuf-c and
      you do it this way:
      
        ./build_oai -I -a
      
      (you add -a)
      
      Other targets don't need protobuf nor protobuf-c, so
      it's not installed by the -I command of build_oai,
      unless you pass -a with -I.
      
      Also, we now use protobuf 3.3.0, not 2.6.1. The code
      has been adapted, a quick test seems to indicate that
      the system works, but it has not been intensively tested.
      45212d3b
    • Cedric Roux's avatar
      hotfix: protobuf-c compilation failure · 17b9a9e9
      Cedric Roux authored
      protobuf-c does not compile anymore.
      
      Let's handle this a bit better.
      
      We now install protobuf and protobuf-c only for the
      flexran agent. That is, if you want to use the flexran
      agent, you need to install protobuf/protobuf-c and
      you do it this way:
      
        ./build_oai -I -a
      
      (you add -a)
      
      Other targets don't need protobuf nor protobuf-c, so
      it's not installed by the -I command of build_oai,
      unless you pass -a with -I.
      
      Also, we now use protobuf 3.3.0, not 2.6.1. The code
      has been adapted, a quick test seems to indicate that
      the system works, but it has not been intensively tested.
      17b9a9e9
  6. 21 Jun, 2017 2 commits
  7. 16 Jun, 2017 1 commit
  8. 08 Jun, 2017 1 commit
  9. 06 Jun, 2017 1 commit
  10. 02 Jun, 2017 4 commits
  11. 31 May, 2017 3 commits
  12. 19 May, 2017 2 commits
    • Cedric Roux's avatar
      fix run_enb_ue_virt_noS1 and run_enb_ue_virt_s1 · 8e57a58d
      Cedric Roux authored
      Problems reported by Jorge Muñoz Castañer <jorgem@gti.uvigo.es>.
      
      - use Rel14 binaries (those are produced by default)
      - let -x option work to have graphical output
      - fix VCD missing 'echo'
      8e57a58d
    • Gabriel's avatar
      UE logging change : · fe350d5b
      Gabriel authored
      --ue-trace : Enabling UE trace for debug
      --ue-timing : Enabling UE timing trace
      --ue-no-log : Disabling all LOG_X traces
      fe350d5b
  13. 17 May, 2017 1 commit
  14. 15 May, 2017 1 commit
  15. 12 May, 2017 1 commit
  16. 14 Apr, 2017 2 commits
  17. 12 Apr, 2017 1 commit
  18. 28 Mar, 2017 7 commits
  19. 27 Mar, 2017 1 commit
  20. 25 Mar, 2017 1 commit
    • Cedric Roux's avatar
      remove asn1 compilation fixes that went to asn1c (IMPORTANT: reinstall asn1c!) · d0e2938b
      Cedric Roux authored
      The files NativeInteger.c.diff and constr_SET_OF.c.diff
      from asn1c were generating compilation warnings. We had
      local patches applied on generated files by asn1c.
      
      A new version of asn1c has been pushed to
      https://gitlab.eurecom.fr/oai/asn1c
      (commit 224dc1f991b7e7ad705ce92e171b942f87b7b7e7)
      making obsolete the fixes we do here.
      
      So we now remove those fixes.
      
      *************************
      * IMPORTANT BEGIN       *
      *************************
      
      Everyone should update their asn1c installation.
      
      The simplest is to do:
      
          source oaienv
          cd cmake_targets
          ./build_oai -I
      
      *************************
      * IMPORTANT END         *
      *************************
      d0e2938b
  21. 24 Mar, 2017 2 commits
    • Cedric Roux's avatar
      bugfix: fix nos1 compilation · af8ce457
      Cedric Roux authored
      af8ce457
    • Cedric Roux's avatar
      remove asn1 compilation fixes that went to asn1c (IMPORTANT: reinstall asn1c!) · b5a03474
      Cedric Roux authored
      The files NativeInteger.c.diff and constr_SET_OF.c.diff
      from asn1c were generating compilation warnings. We had
      local patches applied on generated files by asn1c.
      
      A new version of asn1c has been pushed to
      https://gitlab.eurecom.fr/oai/asn1c
      (commit 224dc1f991b7e7ad705ce92e171b942f87b7b7e7)
      making obsolete the fixes we do here.
      
      So we now remove those fixes.
      
      *************************
      * IMPORTANT BEGIN       *
      *************************
      
      Everyone should update their asn1c installation.
      
      The simplest is to do:
      
          source oaienv
          cd cmake_targets
          ./build_oai -I
      
      *************************
      * IMPORTANT END         *
      *************************
      b5a03474
  22. 23 Mar, 2017 2 commits
    • Cedric Roux's avatar
      RRC Rel14 · 4fcb6272
      Cedric Roux authored
      - import RRC ASN.1 defintions from the specifications
        (file openair2/RRC/LITE/MESSAGES/asn1c/ASN1_files/RRC-e10.asn)
        contrary to rel8/10, all modules have been imported, maybe it's too much
        to refine in case of problems
      - deal with rel14 in fix_asn1
      - all code that was for Rel10 is now for Rel10/Rel14
      - some incompatible changes (mostly in naming) were resolved in favor
        of rel14, see in openair2/RRC/LITE/defs.h
      - unsure about the rlc layer, some arrays have changed (values appended),
        I only changed the definition and in tests in the code, I changed
        the index limit, maybe it's not enough
      
      Rel14 is the default compilation mode.
      4fcb6272
    • Cedric Roux's avatar
      fix issue 227 - UE IP settings disrupts realtime · cff91499
      Cedric Roux authored
      see oai/openairinterface5g#227
      
      When the UE connects to the eNodeB and receives its IP address from the
      network, it calls system() to set it in the linux kernel world. This call
      is not done in a realtime thread, but in the NAS, which uses its own thread,
      independent of the realtime processing.
      
      In some situations this totally disrupts realtime processing.
      
      It is difficult to know precisely why that happens, but it seems that calling
      fork(), as system() does, in a multi-threaded program is not a good idea. (So
      say several people on the internet.) It is not clear why the softmodem is
      impacted, but it seems that fork() is really what triggers the disruption.
      Several tests lead to that conclusion.
      
      To fix the problem, we create a child background process very early in main()
      (before anything else basically). Then instead of calling system(), the main
      process sends the string to the background process. The background process
      gets the string, passes it to system() and reports the success/failure back
      to the main process.
      
      This solution involves a lot of system calls, but calling system() in the
      first place is not cheap either. As long as no realtime thread uses this
      mechanism, things should be fine. Time will tell.
      cff91499
  23. 21 Mar, 2017 1 commit