1. 28 Mar, 2017 2 commits
  2. 27 Mar, 2017 1 commit
    • Cedric Roux's avatar
      bugfix: workaround a problem with timestamp and LMSSDR. · fa0b8668
      Cedric Roux authored
      We have a strange problem with the timestamp of the very
      first packets received from the LimeSDR that leads to
      a complete failure of the eNB.
      A simple workaround is to discard the first RX packet
      just after a "start" of the device.
      We also change the value of "tx_sample_advance" to a more
      reasonable value. The problem of timestamp was "solved"
      differently in the past and at the time we needed to put
      a much higher value.
      This may have to be refined at some point.
  3. 24 Mar, 2017 21 commits
  4. 23 Mar, 2017 4 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.
    • Cedric Roux's avatar
      fix issue 227 - UE IP settings disrupts realtime · cff91499
      Cedric Roux authored
      see https://gitlab.eurecom.fr/oai/openairinterface5g/issues/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.
    • Cedric Roux's avatar
      minor fixes · 89f747a2
      Cedric Roux authored
    • Cedric Roux's avatar
      fixes for IF5 · 238b22e5
      Cedric Roux authored
      This work was done by Bruno Mongazon.
  5. 21 Mar, 2017 2 commits
  6. 20 Mar, 2017 2 commits
  7. 16 Mar, 2017 1 commit
  8. 15 Mar, 2017 1 commit
  9. 14 Mar, 2017 1 commit
  10. 13 Mar, 2017 2 commits
  11. 10 Mar, 2017 3 commits