OAI is riddled with boolean_t, FALSE, TRUE, etc. This makes no sense, as
there is a standard bool type, and could lead to nasty bugs if a
definition of a bool is non-standard (0 == false, true == !false). This
commit removes all non-standard bools in the whole project.
To SIB2 and its passing to RRC. Parameter was read but not transfered
before. Basic LTE-M functionality should ok on develop branch with this
fix. Tested with uBlox SARA-R4 (QCOM chipset)
From the comment above the line with the warning:
> This asn1cCalloc leaks memory but also masks a bug.
> If we delete this asn1cCalloc statement, eNB will crash in NSA mode.
> Please don't delete the following line unless the bug has been found
Also, the allocation of the eNB measurement
report keeps getting commented out becasue
the compiler throws an error. I have un-commented
the allocation of memory (becasue it breaks NSA
mode) and added a memset to ensure we are using
the allocated memory. This gets rid of the
warning and ensures NSA mode still works.
However, when we free after we encode, fsanitize isnt happy.
Need to clean that up. Also, found an actual bug in LTE.
For the random value issue from fall 2020, we added a fix.
This fix uses ctxt and we were getting ctxt properly.
Lastly, we allocated some memory in processing of the
NR Meas report in the eNB.
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.
At the moment, the NSA mode worked once, but shows
unpredictable behavior. Other times it does not work.
In this commit I added several LOG_A messages for NSA
mode. Also removed old comments that were added during
development. Lastly, more comments for all the hacks
have been added.
The eNB may only check for RRC_Complete in EPC
mode. Need to look at this further. Updated how
we pass the RRC_Complete msg from NR UE to LTE UE.
Need to still handle transaction_id from dl_dcch_msg
in the LTE UE and trans_id from nr_dl_msg.
However, the NR UE is crashing because it is receiving
a second RRCReconfig message from the LTE UE and it is
having trouble decoding it. Need to understand this.
Now, we are able to fill the UE_Capability_Info that
the LTE UE and eNB are expecting. We then are able to
generate a RRC_DCCH_DATA_COPY_IND to trigger the
processing of the UE_Capability_Info (and sending the
info to the eNB). The info being received at eNB has not
been tested yet.
Also some code clean up.
c_SRS was 61, which does not fit for 106 PRBs as it seems. Value 0 works.
Maybe not the right thing to do though (see 38.211 6.4.1.4.3,
table 6.4.1.4.3-1).
Also it seems necessary to pass desired LTE/NR bands when requesting
LTE UE capabilities. Today this is hardcoded, to be done better at
some point. We should get the bands from the eNB configuration and
the eNB/gNB X2 exchanges.
Seems like the UEs in the CI don't like when asked to report NR UE
capabilities. So let's first ask for eutra capabilities and then
dig into them to check for en-dc support and only then ask for
NR capabilities. We chose to ask for NR capabilities after receiving
RRCConnectionReconfigurationComplete. That may not be the best thing
to do.
Today, we do nothing with those capabilities. We could completely skip
asking them to the UE, but since the code is there and since it may be
useful in the future, let's do it. Hopefully, it should not hurt too much.
Robert Schmidt