- 21 May, 2024 30 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
This function applied an sf_ahead, bigger than the actual slot indication message sending (so a message could NEVER arrive on time!). Reduce to zero, because this is when it should arrive for us.
-
Robert Schmidt authored
The previous designs seems to do: loop { poll_ind_queue() if (msg) scheduler; pselect() on messages; handle_message { if slot_ind put_ind_queue() } } So basically, we artificially put a queue for slot indications in the middle, but still handle it in the same thread(!). This for some reason results in a big slow down if the PNF runs faster. Now, we just do pselect(), waiting for messages. We handle the slot indication immediately (the schedule should take some microseconds), then return to pselect().
-
Robert Schmidt authored
-
hsum authored
In the previous patch, an issue was identified where the number of slots in the TDD table was hardcoded inconsistently during packing and unpacking. This led to a mismatch in the number of slots processed, causing errors during execution. Upon further investigation, it was found that the number of slots in the TDD table should be determined dynamically based on the value of mu, derived from the configured tdd-UL-DL-ConfigurationCommon. To address this issue, this commit introduces dynamic allocation of memory for the TDD table during unpacking based on the value of mu. Additionally, the packing process now calculates the number of slots to pack dynamically, ensuring consistency between packing and unpacking. This change resolves the discrepancy in the number of slots processed during packing and unpacking, ensuring that the PNF receives a complete and accurate TDD table.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
diff --git a/nfapi/open-nFAPI/nfapi/src/nfapi_p5.c b/nfapi/open-nFAPI/nfapi/src/nfapi_p5.c index d58dc98a3d..26153f755a 100644 --- a/nfapi/open-nFAPI/nfapi/src/nfapi_p5.c +++ b/nfapi/open-nFAPI/nfapi/src/nfapi_p5.c @@ -30,6 +30,7 @@ #include <errno.h> #include <pthread.h> #include <stdint.h> +#include <assert.h> #include <nfapi_interface.h> #include <nfapi.h> @@ -1838,6 +1839,19 @@ static uint8_t pack_nr_config_request(void *msg, uint8_t **ppWritePackedMsg, uin retval &= pack_nr_tlv(NFAPI_NR_CONFIG_TDD_PERIOD_TAG, &(pNfapiMsg->tdd_table.tdd_period), ppWritePackedMsg, end, &pack_uint8_tlv_value); numTLVs++; + + assert(6 == pNfapiMsg->tdd_table.tdd_period.value); + for (int i = 0; i < 20; i++) { + for (int k = 0; k < 14; k++) { + pack_nr_tlv(NFAPI_NR_CONFIG_SLOT_CONFIG_TAG, + &pNfapiMsg->tdd_table.max_tdd_periodicity_list[i].max_num_of_symbol_per_slot_list[k].slot_config, + ppWritePackedMsg, + end, + &pack_uint8_tlv_value); + numTLVs++; + } + } + // probably near here // END TDD Table // START Measurement Config @@ -3336,6 +3350,7 @@ static uint8_t unpack_nr_config_request(uint8_t **ppReadPackedMsg, uint8_t *end, } } else { NFAPI_TRACE(NFAPI_TRACE_ERROR, "Unknown TAG value: 0x%04x\n", generic_tl.tag); + assert(0); if (++numBadTags > MAX_BAD_TAG) { NFAPI_TRACE(NFAPI_TRACE_ERROR, "Supplied message has had too many bad tags\n"); return 0;
-
Robert Schmidt authored
-
Rúben Soares da Silva authored
Assign NFAPI_NR_CONFIG_SLOT_CONFIG_TAG tag in TLVs used for transmitting the TDD Slot configuration through CONFIG.request.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
The same function is called in nr_start_resp_cb(), why there and not here?
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
In the PNF, there is no gNBs section. So we cannot rely on it
-
Robert Schmidt authored
-
Robert Schmidt authored
Remove useless message bytes printing Print message if callback missing less newlines in log logs
-
Jaroslava Fiedlerova authored
-
- 16 May, 2024 1 commit
-
-
Robert Schmidt authored
uper_encode_to_buffer() of asn1c returns the number of BITS that have been encoded; if we use this, we need to calculate the resulting number of bytes (rounding up) to get the right buffer size. Note that do_NR_ULInformationTransfer() uses uper_encode_to_new_buffer() which returns the number of BYTES, hence, in this similar function, we should not modify the return value.
-
- 07 May, 2024 1 commit
-
-
Robert Schmidt authored
Integration `2024.w18` See merge request oai/openairinterface5g!2713 * !2705 Fix CRC check in UE DCI detection * !2708 Adding few more NR bands to the list of supported ones * !2701 gNB archi fixes * !2203 DL-MMSE * !2684 remove asserts on min RX/TX, set the RX/TX shift as 2 in the UE * !2594 F1AP refactoring to align with O-RAN.WG5.C.1-v11
-
- 06 May, 2024 8 commits
-
-
Jaroslava Fiedlerova authored
-
Jaroslava Fiedlerova authored
-
Robert Schmidt authored
Taking the example of the AMF Set ID, the previous version of the macro used another macro to encode the number, then marked the last 6 bits in the bit string (of length 16/2 bytes) as unused. This is wrong, because, assuming AMF Set ID=3, it basically truncates the number by encoding all 16 bits and cutting off the last 6, like this: ------------------- encode 16 bits 0000 0000 0000 0011 ------------ take these 10 bits So what remains is these bit positions of the number: (16,15,14,13,12,11,10,9,8,7) -- the last 6 bits are cut (and the first 6 are either 0 or garbage, because they don't exist). Instead, manually encode bits (10,9,8,7,6,5,4,3) in the first byte, and (2,1) in the second byte of the bit string, like so: ------------ encode 10 bits 0000 0000 1100 0000 ------------ take these 10 bits Do the same with the pointer. The AMF Region ID above is correct, as it is exactly 8 bits.
-
Robert Schmidt authored
We can optionally indicate the PDU session IDs. At least with OAI 5GC, that should help it clean up.
-
Robert Schmidt authored
In the case of PDU sessions in the NG UE context setup request, we first have to set up security. Hence, in this commit, implement the "delayed" set up of theses PDU sessions, and acknowledge the setup request after reconfiguration, as requested by O-RAN.WG5.C.1-v11.
-
Robert Schmidt authored
Trigger UE ctxt setup response for the case of "registration request" (no PDU sessions in UE Context setup response), as mandated by O-RAN.WG5.C.1-v11.
-
Robert Schmidt authored
As of this commit, since we now send the UE security command as a DL NAS message, there is no F1 UE Context setup request. Hence, instead of sending a UE context modif request, send the UE context setup request after the E1 bearer setup response (which logically also makes more sense, as the E1 setup procedure comes before the F1 setup procedure).
-
Robert Schmidt authored
This reverts commit 0f100a6e, which introduced a hack to possibly wait with a PDU session setup at the RRC in case a RRC UE capability transaction (requesting UE capabilities from a UE) was ongoing. This happened, as we delayed the UE capabilities to after the first RRC reconfiguration; in that case, certain UEs were requesting the next PDU session, and if RRC did not delay the new PDU session (as requested from the core), this procedure might occur while UE capability enquiry was ongoing, leading to failures in these transactions.
-