various comment tweaks

Change-Id: Ie40aa672948062282c566c90300f6e96963e05ec
This commit is contained in:
Neels Hofmeyr 2023-02-20 16:41:08 +01:00
parent f05d15e160
commit 43cc12bac3
4 changed files with 17 additions and 11 deletions

View File

@ -47,17 +47,22 @@ struct hnbgw_context_map {
enum hnbgw_context_map_state state;
/* FSM instance for the MGW */
/* FSM instance for the MGW, handles the async MGCP communication necessary to intercept CS RAB Assignment and
* redirect the RTP via the MGW. */
struct osmo_fsm_inst *mgw_fi;
/* FSMs handling RANAP RAB assignments for PS. list of struct ps_rab_ass. For PS RAB Assignment, each Request
* and gets one ps_rab_ass FSM and each Response gets one ps_rab_ass FSM. The reason is that theoretically, each
* such message can contain any number and any combination of RAB IDs, and Request and Response don't
* necessarily match the RAB IDs contained. In practice I only ever see a single RAB matching in Request and
* Response, but we cannot rely on that to always be true. The state of each RAB's PFCP negotiation is kept
* separately in the list hnbgw_context_map.ps_rabs, and as soon as all RABs appearing in a PS RAB Assignment
* message have completed their PFCP setup, we can replace the GTP info for the RAB IDs and forward the RAB
* Assignment Request to HNB / the RAB Assignment Response to CN. */
/* FSMs handling RANAP RAB assignments for PS, list of struct ps_rab_ass. They handle the async PFCP
* communication necessary to intercept PS RAB Assignment and redirect the GTP via the UPF.
*
* For PS RAB Assignment, each Request gets one ps_rab_ass FSM and each Response gets one ps_rab_ass FSM.
* The reason is that theoretically, each such message can contain any number and any combination of RAB IDs,
* and Request and Response don't necessarily match the RAB IDs contained. In practice I only ever see a single
* RAB matching in Request and Response, but we cannot rely on that to always be true.
*
* The state of each RAB's PFCP negotiation is kept separately in the list ps_rabs, and as soon as all RABs
* appearing in a PS RAB Assignment message have completed their PFCP setup, we can replace the GTP info for the
* RAB IDs and forward the RAB Assignment Request to HNB / the RAB Assignment Response to CN.
*/
struct llist_head ps_rab_ass;
/* All PS RABs and their GTP tunnel mappings. list of struct ps_rab. Each ps_rab FSM handles the PFCP

View File

@ -111,7 +111,7 @@ context_map_alloc_by_hnb(struct hnb_context *hnb, uint32_t rua_ctx_id,
LOGHNB(hnb, DMAIN, LOGL_INFO, "Creating new Mapping RUA CTX %p/%u <-> SCU Conn ID %p/%u\n",
hnb, rua_ctx_id, cn_if_new, new_scu_conn_id);
/* alloate a new map entry */
/* allocate a new map entry. */
map = talloc_zero(hnb, struct hnbgw_context_map);
map->state = MAP_S_NULL;
map->cn_link = cn_if_new;

View File

@ -780,7 +780,7 @@ int mgw_fsm_handle_rab_ass_resp(struct hnbgw_context_map *map, struct osmo_prim_
}
/*! Release the FSM and clear its associated RTP streams.
* \ptmap[in] map hanbgw context map that is responsible for this call.
* \ptmap[in] map hnbgw context map that is responsible for this call.
* \returns 0 on success; negative on error. */
int mgw_fsm_release(struct hnbgw_context_map *map)
{

View File

@ -620,6 +620,7 @@ static void ps_rab_ass_fsm_cleanup(struct osmo_fsm_inst *fi, enum osmo_fsm_term_
rab->resp_fi = NULL;
}
/* remove from map->ps_rab_ass */
llist_del(&rab_ass->entry);
}