Creates function that have nr_pdcp_ prepended to their name, and change
the signature of some functions for the 5G PDCP:
- nr_pdcp_layer_init()
- nr_pdcp_data_req()
- nr_pdcp_remove_UE()
- nr_pdcp_config_set_security()
- nr_pdcp_remove_UE()
- Make separate functions for nr_pdcp_data_req_srb/drb()
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.
This commit includes about 1/3 of the code clean up
in preparation for the merge to the OAI develop
branch. Several of the changes are white space changes,
removing of logs, comment removals, and updating any
changed code for our use-case to be clear for NSA mode.
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.
More accurately, we changed the do/while infinite
loop to be an infinite for loop for the read command of
the socket. The socket file descriptor choice is more clear now.
ACKNOWLEDGEMENT:
1. This commit was developed at Vicomtech (https://www.vicomtech.org) under UE project CDN-X-ALL: "CDN edge-cloud computing for efficient cache and reliable streaming aCROSS Aggregated unicast-multicast LinkS"
2. Project funded by Fed4FIRE+ OC5 (https://www.fed4fire.eu)
Signed-off-by: Javier Morgade <javier.morgade@ieee.org>
-MBMS scheduler developed (oneFrame allocations implemented at this time)
-UE DSLCH schedulers updated: if an eMBMS session running UE DTCH, DCCH will be only scheduled at non MBSFN sufbframes
-eMBMS L2 procedures implemented
-Dedicated MBMS PDCP pipes src/sink enabled (only for TUN)
-BUGFIX eMBMS MAC procedures (wrong indexing at few loops)
-ENB FAPI updated to enable dynamic MBSFN configurations through M2AP (RRC<->MCE)
ACKNOWLEDGEMENT:
1. This commit was developed at Vicomtech (https://www.vicomtech.org) under UE project CDN-X-ALL: "CDN edge-cloud computing for efficient cache and reliable streaming aCROSS Aggregated unicast-multicast LinkS"
2. Project funded by Fed4FIRE+ OC5 (https://www.fed4fire.eu)
Signed-off-by: Javier Morgade <javier.morgade@ieee.org>
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.
mir