An error occurred fetching the project authors.
  1. 05 Mar, 2019 5 commits
    • Konstantinos Alexandris's avatar
      x2: some cleanup in instance management · 02193f4b
      Konstantinos Alexandris authored
      - manage target eNB based on target cell id received by measurement report
        for Handover Request
      - manage source eNB based on association id for Handover Request Ack
      - use only x2ap instance and not x2ap data instance points to x2ap instance
      02193f4b
    • Konstantinos Alexandris's avatar
      x2: bug fixes · 31797221
      Konstantinos Alexandris authored
      - free correctly in rrc_eNB_free_mem_UE_context
      - check for existence of ue_context.handover_info in rrc_enb_process_itti_msg
      - check return value sctp_peeloff in sctp_handle_new_association_req_multi
        and exit in case of failure
      31797221
    • Konstantinos Alexandris's avatar
    • Konstantinos Alexandris's avatar
    • Konstantinos Alexandris's avatar
      bugfix: fix realtime issues with RRC (race condition) · eb59c2cd
      Konstantinos Alexandris authored
      When testing x2 handover, we found a race issue between the
      RRC thread and the phy/mac thread (which is calling rrc_rx_tx).
      
      The UE context was updated by the RRC thread but in the middle of
      the update (which consists of several function calls and variables'
      updates) the context was accessed by rrc_rx_tx. At this point, the
      context was in an inconsistent state.
      
      The solution is to access RRC data in the RRC thread only.
      The function rrc_rx_tx now just sends an ITTI message to the
      RRC thread. When receiving this message, the RRC thread does
      the processing that was done by the function rrc_rx_tx (in
      the new function rrc_subframe_process).
      
      This way, the race condition disappears.
      
      However we now send an ITTI message from the phy/mac thread to
      the RRC thread at each subframe. That might increase the processing
      time of the eNB. So maybe it's not the best solution. It may also
      improve the realtime performance because less work is done by the
      phy/mac realtime thread. To be checked somehow.
      
      Also, it may be possible that some other RRC functions are still
      called by the phy/mac thread, which should also be checked and
      replaced by ITTI messages (if this solution is considered to be
      correct).
      eb59c2cd
  2. 27 Feb, 2019 1 commit
    • Cedric Roux's avatar
      bugfix: fix PDCP sequence management (plus some cleanup) · e3782b5c
      Cedric Roux authored
      With the introduction of X2AP into develop, the UEs now have to regularly
      send measurement reports.
      
      In the logs of the eNB, we see:
      
      [OSA]   Mismatch found in integrity for algorithm 2,
              got e0.a0.c2.66, expecting a5.9c.cb.57
      [PDCP]   [OSA][RB 1] eNB failed to validate MAC-I of incoming PDU
      
      This is a bug in the PDCP layer that uses wrong parameters to compute the
      integrity.
      
      This commit fixes this bug.
      
      The function pdcp_is_rx_seq_number_valid was removed. Its processing
      has been directly integrated into the function pdcp_data_ind.
      
      The function pdcp_mark_current_pdu_as_received is not called anymore.
      Its processing was not used later on, so as of today, not calling it does
      not introduce any functional change.
      
      The function pdcp_validate_security takes now as parameters both
      SN and HFN. Same for the function pdcp_get_next_count_rx.
      
      Useless constants PDCP_SN_5BIT, PDCP_SN_7BIT and PDCP_SN_12BIT have been
      removed.
      
      The compilation option ENABLE_SECURITY has been removed. It's now always
      on. (This may impact some use cases.)
      
      The PDCP for DRB using RLC AM is not correct. It was not correct before
      this commit (apart from the integrity bug). We should deal with a list
      of PDUs and transmit packets to upper layers as detailed in the specs.
      Today we transmit the PDU as soon as we get it. We don't care about
      duplicates, in-order delivery, timeouts.
      
      Also, we don't deal with "PDCP re-establishment". Not sure how that impacts
      the software.
      
      And, last but not least, there is still no ROHC.
      e3782b5c
  3. 25 Feb, 2019 1 commit
  4. 17 Feb, 2019 1 commit
  5. 15 Feb, 2019 1 commit
  6. 13 Feb, 2019 1 commit
  7. 12 Feb, 2019 1 commit
  8. 21 Jan, 2019 3 commits
  9. 16 Jan, 2019 1 commit
  10. 07 Jan, 2019 1 commit
    • Cedric Roux's avatar
      fix a lot of file mode · aea6b4b5
      Cedric Roux authored
      For whatever reason most of the files had their permission
      changed from 644 to 755, which is not wanted.
      aea6b4b5
  11. 23 Dec, 2018 1 commit
  12. 18 Dec, 2018 1 commit
  13. 20 Nov, 2018 3 commits
  14. 18 Nov, 2018 1 commit
  15. 16 Nov, 2018 1 commit
  16. 15 Nov, 2018 1 commit
  17. 13 Nov, 2018 2 commits
  18. 05 Nov, 2018 2 commits
  19. 03 Nov, 2018 2 commits
  20. 02 Nov, 2018 1 commit
  21. 31 Oct, 2018 1 commit
  22. 26 Oct, 2018 2 commits
  23. 25 Oct, 2018 1 commit
  24. 23 Oct, 2018 3 commits
  25. 17 Oct, 2018 1 commit
  26. 20 Sep, 2018 1 commit