1. 29 May, 2018 1 commit
  2. 28 May, 2018 1 commit
  3. 24 May, 2018 1 commit
  4. 15 May, 2018 2 commits
    • Cedric Roux's avatar
      fix: let ue_ip.ko compile · f9aac56e
      Cedric Roux authored
      MAX_MOBILES_PER_ENB cannot be used to compile ue_ip
      because it is defined in platform_constants.h and this
      cannot be included to compile a kernel module.
      
      Let's use NUMBER_OF_UE_MAX as it was before instead.
      f9aac56e
    • Cedric Roux's avatar
      fix: hacks to have the UE functional again · f7b3ea03
      Cedric Roux authored
      The new 'basic simulator' is now functional.
      A proper solution is needed to deal with SIB18/19/21
      for the D2D functionality.
      f7b3ea03
  5. 11 May, 2018 1 commit
    • Cedric Roux's avatar
      fix rdtsc usage · ad46183e
      Cedric Roux authored
      One user had a problem compiling oaisim.
      This commit fixes it.
      
      The compilation log was saying:
      
          targets/RT/USER/lte-ue.c:
          In function UE_thread_rxn_txnp4:
      
          openair2/UTIL/LOG/log.h:370:3:
          error: inconsistent operand constraints in an asm
      
               __asm__ volatile ("rdtsc" : "=a" (a), "=d" (d));
      
               ^
      ad46183e
  6. 09 May, 2018 1 commit
    • Cedric Roux's avatar
      import work from the branch nfapi-L2-emulator to merge it to develop · f254107b
      Cedric Roux authored
      It was not possible to merge the branch directly, because the
      history of this branch contains files that cannot be in the
      repository, namely wireshark from Cisco work on nFAPI.
      
      As for Cisco work on nFAPI, a special commit containing all the
      work is thus created.
      
      Below is the output of the command:
      git log --graph 184d51c6..61276d87
      
      184d51c6 is the commit ID of the develop
      branch prior to the merge.
      
      61276d87 is the commit ID of the
      nfapi-L2-emulator branch prior to the merge.
      
      The commit 61276d87 (and all its
      history) will be removed from the main OAI repository. It is
      present in the internal OAI repository for those who have access
      to it.
      
      There was also some cleanup done on the code.
      
      Some changes were necessary to have the eNB functional. They may have an
      impact on the FAPI ...
      f254107b
  7. 02 May, 2018 1 commit
  8. 29 Apr, 2018 1 commit
  9. 25 Apr, 2018 1 commit
  10. 24 Apr, 2018 1 commit
  11. 22 Apr, 2018 1 commit
  12. 16 Apr, 2018 1 commit
    • Bi-Ruei, Chiu's avatar
      Compare version number using MAKE_VERSION macro to provide better SW configuration: · 5c23af77
      Bi-Ruei, Chiu authored and Cedric Roux's avatar Cedric Roux committed
      1. Previous SW configuration for different RRC version relies on whether macro Rel10,
         Rel14 defined or not by checking #ifdef Rel14 or #if defined(Rel10) || defined(R14).
         Whenever there is a newer RRC version, e.g. Rel15, it will be very a tedious and
         error-prone job to add defined(Rel15) in every place.
      
      2. Some RRC messages are defined in release 13 instead of release 14, NB-IoT
         feature is one of such example. Our code shall reflect this fact instead of using
         an afterward version number in software configuration.
      
      3. Some RRC messages or some fields of certain RRC messages are added in the middle
         a release, e.g. SystemInformationBlockType1_v1310_IEs_t defined in RRC 13.1.0
         and RRC 9.2.0 made some changes to SIB12 and SIB13 so we have sib12_v920 and
         sib13_v920 fields in SIB12 and SIB13's struct.
         We need a finer grain of control when using ASN1 from different RRC version.
      
      4. S1AP also has this problem that it use UPDATE_RELEASE_9 and UPDATE_RELEASE_10 to
         differentiate between various S1AP version.
      
      This commit propose using MAKE_VERSION(x,y,z) to designate the version number and
      modify current conditional compilation accordingly.
      
      Note: 2018/04/16, Modified based on Cedric's comment.
      5c23af77
  13. 12 Apr, 2018 1 commit
  14. 09 Apr, 2018 1 commit
  15. 08 Apr, 2018 1 commit
  16. 06 Apr, 2018 3 commits
  17. 05 Apr, 2018 2 commits
  18. 23 Mar, 2018 3 commits
  19. 22 Mar, 2018 3 commits
  20. 21 Mar, 2018 1 commit
  21. 20 Mar, 2018 1 commit
  22. 19 Mar, 2018 1 commit
    • Cedric Roux's avatar
      bugfix: send UL NACK (on PHICH) at the right place · d3938147
      Cedric Roux authored
      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.
      d3938147
  23. 15 Mar, 2018 1 commit
  24. 14 Mar, 2018 1 commit
  25. 09 Mar, 2018 3 commits
  26. 08 Mar, 2018 4 commits
    • oai's avatar
      more NB-IoT integration · da50d68b
      oai authored
      da50d68b
    • oai's avatar
    • oai's avatar
    • Cedric Roux's avatar
      cleanup MAC PDU generation (plus some general cleanup) · 1a8d81ba
      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.
      1a8d81ba
  27. 05 Mar, 2018 1 commit