1. 11 Feb, 2025 9 commits
    • Robert Schmidt's avatar
      Merge remote-tracking branch 'origin/fix-cuup-assert-reconnect' into integration_2025_w06 (!3243) · 1be038c8
      Robert Schmidt authored
      Reset E1 UE contexts after E1 Setup Response
      
      38.463 sec. 8.2.3 says
      
      > This procedure also re-initialises the E1AP UE-related contexts (if
      > any) and erases all related signalling connections in the two nodes
      > like a Reset procedure would do.
      
      Hence, delete all contexts after reception of E1 Setup Response. This
      minimizes a risk of receiving an E1 bearer setup req for an existing UE,
      which currently leads to an assert [we trust the CU-CP does not send the
      same UE ID twice, as we only "mirror" the existing UE ID].  After this
      MR, this is what happens if these entities fail:
      
      - CU-CP fails: all context lost implicitly, upon reconnection, both DU
        and CU-UP reset all contexts (like "start from zero")
      - DU fails: CU-CP triggers NGAP UE context release request immediately
        (radio connection with UE lost), all UE contexts attached to this DU
        cleared (like "start from zero" for affected DU)
      - CU-UP fails: initially, nothing (UE has no user plane); upon
        reconnection of CU-UP, CU-CP triggers NGAP UE context release request
        (cause radio connection with UE lost) and sends F1 Reset to DU, all UE
        contexts associated to this DU cleared (like "start from zero")
      
      for the last case, a possible improvement could be to use the F1 Reset
      message to only clear affected UE conetxts. I chose not to do this,
      because this MR is very big now already, and possible "victim" UEs
      that were not at that CU-UP will reconnect as well
      1be038c8
    • Robert Schmidt's avatar
      Reset CU-CP E1 UE context after E1 Setup Response · e8661f5a
      Robert Schmidt authored
      As in deba3ae0 ("Reset CU-UP E1 UE contexts after E1 Setup
      Response"), the CU-CP should reset the E1 UE contexts after E1 Setup
      Response. 38.463 sec. 8.2.3 says
      
      > This procedure also re-initialises the E1AP UE-related contexts (if
      > any) and erases all related signalling connections in the two nodes like
      > a Reset procedure would do.
      
      In the case of CU-CP, this is a bit more complicated. More precisely, we
      need to wait for the CU-UP to be available again before informing the DU
      about the loss (implemented via an F1 Reset message), because otherwise,
      the UE might reconnect immediately, before the CU-UP is online again.
      
      Hence, on connection loss, we mark affected UEs (by setting their E1
      association ID to 0); as long as the CU-UP does not connect, nothing
      will happen (but UEs don't have user plane). Upon CU-UP connecting
      again, we request release of the UEs via NGAP (similarly to what is done
      if the DU goes offline, see invalidate_du_connections()), free the UE
      contexts locally, and send an F1 Reset message to the DU, because
      38.473 sec 8.2.1.2.1 says
      
      > a failure at the gNB-CU [...] has resulted in the loss of some or
      > all transaction reference information [...] a RESET message shall be
      > sent to the gNB-DU.
      
      The core should accept and send an NGAP release command message; since
      no UE contexts are to be found (already deleted), the CU-CP will just
      send a release complete (together with some warnings).
      
      It might be possible to more gracefully handle the situation (e.g., as
      described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but
      
      - we lack the PDCP SN exchange
      - the current procedure has the advantage of being equivalent to
        "restart of the entire gNB", with less downtown.
      e8661f5a
    • Robert Schmidt's avatar
      Refactor rrc_remove_ue() to not send NGAP ctxt release cplt · d2bb779e
      Robert Schmidt authored
      The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP)
      context. However, we don't send NGAP UE context release at that moment
      (we will instead *request* the release); more generally, it's not clear
      that every user of rrc_remove_ue() wants to actually send this message.
      Hence, refactor the code by separately calling
      rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.
      d2bb779e
    • Robert Schmidt's avatar
      ff106c41
    • Robert Schmidt's avatar
      df365d9a
    • Robert Schmidt's avatar
      Use (CU-initiated) F1 Reset in stack · 4c9ed9d7
      Robert Schmidt authored
      4c9ed9d7
    • Robert Schmidt's avatar
      9157e22c
    • Robert Schmidt's avatar
      Merge remote-tracking branch 'origin/nfapi-fixes-4x4-100MHz' into integration_2025_w06 (!3251) · 9b4e0677
      Robert Schmidt authored
      nFAPI: make 4-layer on 100MHz work
      
      5G nFAPI headers specify 32 bits for the length field, so use it also
      when segmenting messages. This should stabilize 4-layer MIMO operation
      on 100MHz with nFAPI.
      9b4e0677
    • Robert Schmidt's avatar
      Merge remote-tracking branch 'origin/rfsim-deadlock-avoidance' into integration_2025_w06 (!3246) · 7d4f7ebb
      Robert Schmidt authored
      Deadlock avoidance in rfsimulator
      
      This change introduces a countermeasure for deadlock in rfsimulator. The
      deadlock happens when all entities are waiting for new data to come in,
      and happens with 2+ clients, when a new client connects. I think this
      issue is due to ordering of fullwrite calls, resulting in out-of-order
      delivery of packets and eventually trashing the packets on the receiving
      side. The out-of-order delivery warnings are printed just before the
      system deadlocks but I have not found a better solution so far. The
      workaround makes the server never lock up permanently by ignoring the
      client failure to write on time after 10 tries.
      
      This was tested locally for both UE as server and gNB as server and
      works correctly, causing the deadlock to clear and the added log to be
      printed several times when the deadlock is detected, after which the
      system goes back to normal.
      
      I have some gdb output of the executables during deadlock:
      
          UE:
      
          $7 = {conn_sock = 98, lastReceivedTS = 3226163740, headerMode = true, trashingPacket = false, th = {size = 13184, nbAnt = 1, timestamp = 3226150556, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a500018a8 "\200\063", remainToTransfer = 24,
            circularBufEnd = 0x7f6a503b3ac0 "", circularBuf = 0x7f6a501f1ac0, channel_model = 0x0}
          (gdb) p t->buf[5]
          $8 = {conn_sock = 97, lastReceivedTS = 0, headerMode = true, trashingPacket = false, th = {size = 0, nbAnt = 0, timestamp = 0, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a50001900 "", remainToTransfer = 24, circularBufEnd = 0x7f6a50575ad0 "",
            circularBuf = 0x7f6a503b3ad0, channel_model = 0x0}
      
          nextRxTimestamp 3225937740
          nsamps = 30720
      
          gNB 1:
          (gdb) p t->buf[0]
          $4 = {conn_sock = 95, lastReceivedTS = 3226026876, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
            transferPtr = 0x7f8dfc003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7f8e1c3ff010 "", circularBuf = 0x7f8e1c23d010, channel_model = 0x0}
          nextRxTimestamp 3225996956
      
          gNB 2:
          lastReceivedTS = 3226026875
          $2 = {conn_sock = 95, lastReceivedTS = 3226026875, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0},
            transferPtr = 0x744898003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7448bc2e7010 "", circularBuf = 0x7448bc125010, channel_model = 0x0}
      
          nextRxTimestamp 3226026875
      
      As you can see all executables are in have_to_wait state.
      7d4f7ebb
  2. 10 Feb, 2025 4 commits
  3. 08 Feb, 2025 2 commits
    • Robert Schmidt's avatar
      nFAPI/PNF: Correctly set message length when segmenting · 609969f4
      Robert Schmidt authored
      Make the same change as in parent commit, i.e., write the full 32-bit
      segment size.
      
      I could not test this, as we do not reach these rx_data.indication
      length. It's based on the fix in the parent commit, and to avoid future
      bad surprises.
      609969f4
    • Robert Schmidt's avatar
      nFAPI/VNF: Correctly set message length when segmenting · 2067831e
      Robert Schmidt authored
      The 5G nFAPI message length is 32bits. In particular tx_data.requests
      can be longer than 64kB. When segmenting, we should correctly write the
      message of the current segment (across all 32bits), because the
      length would interpreted wrongly otherwise.
      
      This fixes a bug in which tx_data.requests were discarded for 4-layer DL
      MIMO on 100 MHz with this message:
      
          P7 unpack message length is greater than the message buffer
      
      Further, increase the type of various (segment-related) variables to 32
      bits. Currently, the maximum segment size is sxt to 65000 bytes (and in
      will likely remain, because the maximum UDP size is 65536);
      nevertheless, increase it in case we will ever go beyond this.
      
      See also commit dee68e63 ("nFAPI: increase maximum segment size to
      65000")
      2067831e
  4. 07 Feb, 2025 8 commits
  5. 05 Feb, 2025 4 commits
  6. 04 Feb, 2025 9 commits
  7. 03 Feb, 2025 3 commits
    • Robert Schmidt's avatar
      Merge branch 'integration_2025_w05' into 'develop' · 0053a3d0
      Robert Schmidt authored
      Integration: `2025.w05`
      
      Closes #885
      
      See merge request oai/openairinterface5g!3233
      
      * !3102 Dockerized development environment
      * !3185 Add IQ file recording and IQ file viewer to ImScope
      * !3218 more layer1 cleaning
      * !3224 Ensure execution of processSlotTX in order in NR UE
      * !3231 Bugfix in frame and slot setting for ULSCH beam allocation
      * !3229 Verify the integrity protection of the RRCReestablishment message
      * !3230 FHI72: fix for single distributed antenna array for xran F release
      * !2984 NAS 5GS refactor
      * !3235 Parametrized JenkinsNode and JenkinsResource
      * !2799 Changes to support multiple TDD patterns
      * !3208 Downgrade gNB power limit LOG from "warning" to "debug"
      0053a3d0
    • Robert Schmidt's avatar
      Merge remote-tracking branch 'origin/avoid-powerlimit-flood' into integration_2025_w05 (!3208) · 616c6775
      Robert Schmidt authored
      Downgrade gNB power limit LOG from "warning" to "debug"
      
      Downgrade the UE power limited LOG from LOG_W to LOG_D. This is to avoid
      flooding stdout when UE in low coverage enters power limited state for a
      longer period of time. The same information can be inferred from the
      periodic UE print which also contains PH value (negative PH values
      indicate that the UE is power limited)
      
      Also, correct some typos in PH calculation.
      
      Closes #885
      616c6775
    • Robert Schmidt's avatar
      Merge remote-tracking branch 'origin/Mult_TDD_Pattern' into integration_2025_w05 (!2799) · 1cb82bae
      Robert Schmidt authored
      Changes to support multiple TDD patterns
      
      - Updated the configuration changes for 2 Patterns
      - Update the TDD table configuration for NFAPI
      - Added the tdd bitmap for the period
      - Adapted the bitmap for UL/DL for the multi TDD pattern
      - Updated the RACH procedure for multi TDD pattern
      - Updated DL and UL scheduler for multi TDD pattern
      1cb82bae
  8. 31 Jan, 2025 1 commit