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.
* assuming num_dl_slots and num_ul_slots are including also
slots with dl/ul symbols respectively
* refactor set_tdd_config_nr
* moved function to MAC
* fill max_num_of_symbol_per_slot_list depending on slot type
* use new set_tdd_config_nr in stack
* minor refactor in config.c to improve readability (scs)
Co-authored-by: Guido Casati <guido.casati@firecell.io>
This function packs P7 messages. At least RX_data.indication messages
might be much bigger than the global buffer that is used here. Allocate
the buffer on the stack, and make it bigger. Do not use the global
buffer, it's simply not necessary; increasing the global tx buffer size
might have negative effects elsewhere in the code.
That change might make the function reentrant. The mutex seems to only
guards the codec config. However, leave it to not introduce any
regressions as of now.
At both the PNF and the VNF, introduce a separate numerology field, and
pass the numerology when converting time information using macros from
nfapi_interface.h. The actually numerology is still hardcoded to 1 (as it
was before), but the follow-up commits will put a suitable numerology.
In both cases, but the numerology next to the frame/slot information.
The next commits will modify the time macros used in the 5G nFAPI code
to handle different numerologies. As a preparation, remove all the
usages of these macros where they really don't matter (e.g., don't
convert if we don't need to).
the L1 needs both a PDU (in TX_data.req) as well instructions for
the actual transmission (in DL_TTI.req) to encode a PDSCH message. In
nFAPI, it can happen that a DL_TTI.request message has been received
(configuring the PDSCH transmission), without the TX_data.request having
reached the PNF. The L1 assumes to have the PDU.
To avoid problems, ensure that only the pair of DL_TTI.req/TX_data.req
is delivered. Otherwise, drop either message.
nFAPI has a mechanism to segment messages that are too big for transport
over a given medium (see e.g. SCF 225, section 2.3.2).
The maximum segment size of 10000 makes that for larger payloads, e.g.
TX_data.request, many small segments are to be sent. This can create or
increase delays on the transport. On the other hand, the currently only
available transport mechanism, UDP, allows to transport packets of up to
almost 65535 bytes. Correspondingly, increase the maximum segment size
so that less segments are to be created, and potentially, less delay is
to be incurred. # Please enter the commit message for your changes.
Lines starting
Avoid delays in tx_data.request handling by avoiding big malloc()s and
copy operations. Reimplement function to (1) peek the frame/slot
numbers, (2) decide on buffer, and (3) unpack directly into
pre-allocated memory.
Co-authored-by: hsum <ming-hong.hsu@eurecom.fr>
Co-authored-by: chenyi <Yi-Quan.Chen@eurecom.fr>
Co-authored-by: Rúben Soares Silva <rsilva@allbesmart.pt>
The next commits refactor the rx handling of messages in the PNF. To
efficiently handle them, provide a "peek()" function that gives us the
frame/slot for which a message is destined. This allows to decide if a
message is on time and select a destination buffer, before unpacking it
completely, avoiding copies.
The time that a message between PNF/VNF to arrive depends mostly on the
transport. To allow for some delays, there is a slot_ahead time, during
which the VNF is allowed to schedule and send instructions to the PNF.
This can be multiple slots; the 1ms hitherto given might typically too
short. Increase to 10ms, to encompass a wider range of slot_ahead times.
Make the corresponding log message of when old (stale) message are
removed a bit clearer with respect to times.
This is the first commit in which nFAPI works. Follow-up commits improve
performance.
The function now utilizes simpler variable names and logic to determine
if a given NR P7 request falls within the timing window.
The logic for determining if a request is within the timing window is as follows:
- The function calculates the absolute difference between the current
and received SFN slots, taking into account the possibility of
wraparound.
- If the absolute difference is greater than half of the maximum SFN
slot value, it subtracts this difference from the maximum SFN slot
value to get the actual difference.
- The function then checks if this difference is less than or equal to
the specified timing window. If it is, the request is considered to be
within the window.
Additionally, the commit updates the function signature to return a
boolean value for better readability and consistency.
Changes made:
- Simplified variable names for readability
- Improved logic for handling wraparound scenarios
- Updated function signature to return a boolean value
Co-authored-by: Rúben Soares Silva <rsilva@allbesmart.pt>
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.
The parent commit cleans up and groups oai_exit in one place,
nr-softmodem-common.h. Therefore, this 5G file is included in the 4G
defs_common.h (at least it's mostly 4G), which is not nice. Instead,
define oai_exit also in 4G softmodem-common.h, and include this in
defs_common.h. Remove the cyclic inclusion of defs_common.h in
softmodem-common.h, and resolve all subsequent errors around unknown
types and extern definition mismatches.
Update NR P5 and P7 nFAPI headers to have 32-bit message_length
In the NR functions, this causes the header parameters following message_length to have their position shifted by 2 bytes, due to the increase in message_length size.
Change needed to accommodate SCF222.10.02 Table 3-3
Separates nfapi_p4_p5_message_header_t and nfapi_nr_p4_p5_message_header_t
Change the callbacks signature to accept/return void* intead of expecting a particular header type, being the NR/LTE distinction done inside the callback functions.
Create NR related functions for nFAPI transmit timestamp and checksum calculation.
Move nfapi_p7_codec_config_t and nfapi_p4_p5_codec_config_t to separate header to be shared between LTE and NR VNF/PNF
Move nfapi_nr_timing_info_t into NR header.
Move NR specific function declarations to NR header.
Testing showed that some messages could be at least slightly bigger than
the previous maximum size of 8192. Given that the maximum transport
block could be larger, increase this value to 32768.
Will be reused from other files in later commits.
Added packing/unpacking procedures for STOP.indication and ERROR.indication.
Separate a packing function for STOP.request for use in the NR FAPI library.
remove several unused files
remove mem_block_t that is never used in a different way than a simple heap buffer
move up IP address type and remove duplications of the same struct declaration
Creation and usage of packing/unpacking functions for DCI payload
Update Proxy commit id for CI
Apply formatting on changed functions and fix pull/push return value checking
- Fix 4G and 5G discrepancy in TLV padding requirements: 4G does not
need padding, whereas 5G needs, so make separate set of function for
padding for NR
- Fix packing/unpacking for (n)FAPI PARAM and CONFIG.request/response
messages
- Handle message padding to next 32-bit boundary, as per SCF
specification in packing and unpacking functions
- Account for message header size upon receiving message in PNF and VNF
At this point we are successfully able to build.
Additionally, we can run the scenario,
however, it does not pass. It seems that the gNB
is not connecting to the proxy correctly. Just
wanted to push the progress so far. FYI, the items
that had to be changed to correct the linking issues
were the following:
- mac_rrc_data_ind_ue vs. nr_mac_rrc_data_ind_ue
- rrc_data_req vs. nr_rrc_data_req
- mac_rrc_data_req_ue vs. nr_mac_rrc_data_req_ue
- rrc_data_req_ue vs. rrc_data_req_nr_ue
- rrc_data_req vs. nr_rrc_data_req
The listed functions should be declard in the LTE/NR
UE directory depending on the functionality. Several
were mixed. i.e.: LTE functions being called in NR UE.
Also, removing siWindowLength, siWindowLength_int,
SIBType, SIBPeriod, and siPeriod_int from the NR UE RRC.
These variable were not used in the NR UE and are defined
for LTE only.
Lastly, in the NR_IF_Module.c of the NR UE, the global
variable def_dci_pdu_rel15 is not accessible. Need to
revisit this. For not it is commented out.
francescomani