Similarly to the commit "Use F1 UE context setup/modif Request in
stack", we do both UE context setup/modification response at once
because of some functions that are shared by the MAC message handler.
Use the new, tested F1 UE context setup request and modification
requests in the stack.
We have to do both at once, because there are some functions that are
used by handlers for both messages, notably
- handle_ue_context_drbs_setup()
- handle_ue_context_srbs_setup()
(+ and some functions called by those two). For instance, the first uses
the (new/old) type f1ap_drb_to_be_setup_t/f1ap_drb_to_setup_t which is
shared. The alternative would be to duplicate the functionality
temporarily, and I want to avoid unnecessary code churn.
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
- store the assoc ID of a UE at the RRC
- if F1 receives an SCTP shutdown, it removes the endpoint
- F1 will also send an "F1 Lost Connection" message to the RRC
- it is not yet possible to reconnect a DU after it had already been
connected at the CU, since the CU F1AP task will try to rebind GTP,
which fails
This branch series implements the usage of the F1 Setup Request
internally at the gNB, even if CU and DU run in the same process. Until
now, the F1 Setup Request contained struct fields to pass IP
configuration to the F1AP module; this information is not necessary in
monolithic, nor should it be relevant when passing the information in
F1 Setup Request.
Therefore, this commit moves all IP connection-related information out
of the F1 Setup Request and into a separate structure instead. In order
to give the F1AP module the necessary connection information, the
DU_REGISTER_REQ message is introduced that combines the F1 Setup Request
and IP configuration, such that the F1AP module can setup the SCTP
connection and then send the F1 Setup Request message.
In a later commit, there will be a callback for F1 Setup Request at MAC
to simply register the DU at the CU. The monolithic callback will simply
forward the F1 Setup Request The F1AP callback will look up the IP
configuration and create DU_REGISTER_REQ message containing IP
configuration and F1 Setup Request, which is then handled by the F1AP
module. To this end, a separate function in gnb_config.c allows to read
IP information from configuration.
-F1 message successfully encoded at the CU (including SRB2, DRB and F1-U tunnel configuration) and received from the DU.
-Next steps: handling of UE context modification request at the DU and triggering the UE context setup response towards the CU.
* MAC differentiates between DU/eNB
* sends ITTI message to DU task for F1AP_UE_CONTEXT_RELEASE_REQ
* message is dispatched to correctly in DU_TASK
* sender correctly fills IDs and cause and sends
- add message sender (CU) + handler (CU) and fill with data from ITTI message
- add PLMNID_TO_MCC_MNC and BIT_STRING_TO_TRANSPORT_LAYER_ADDRESS_IPv4 macros
- correct TRANSPORT_LAYER_ADDRESS_TO_BIT_STRING:
change name to TRANSPORT_LAYER_ADDRESS_IPv4_TO_BIT_STRING, make it send 4B, not 5
Robert Schmidt