cellular-infrastructure
/
osmo-bsc
mirror of https://gerrit.osmocom.org/osmo-bsc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-bsc/doc/assignment-fsm.dot

50 lines
2.1 KiB
Plaintext
Raw Permalink Normal View History

doc: update/fix FSM charts These reflect the plan for refactoring, and will be implemented by I82e3f918295daa83274a4cf803f046979f284366 and Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb Change-Id: I29e31b753e23a4207662e0e385a337e7df836f45
2018-06-16 14:08:55 +00:00
digraph G {
rankdir=TB
labelloc=t; label="Assignment FSM"
WAIT_LCHAN_ACTIVE
WAIT_RR_ASS_COMPLETE
WAIT_LCHAN_ESTABLISHED
WAIT_MGW_ENDPOINT_TO_MSC
terminate [shape=octagon]
gscon [label="conn FSM",shape=box3d]
gscon2 [label="conn FSM",shape=box3d]
lchan [label="lchan FSM\n(new lchan)",shape=box3d]
old_lchan [label="old lchan",shape=box3d]
lchan and assignment FSMs: make Channel Mode Modify more sane The Channel Mode Modify procedure is currently implemented for changing a TCH lchan from signalling to voice mode. For that, however, it is re-using (abusing) the channel activation structs and state transitions, and thus always implies activating a voice stream when the mode modification is done. I will add a Channel Mode Modify to enable VAMOS mode soon, so I require separate structs and state transitions which also work on an lchan that already has a voice stream established: a struct lchan_modify_info and LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED. For the part where a Channel Mode Modify enables a voice stream after switching from signalling to speech mode, still use the channel activation code path, but only once the mode modification is done. General improvements: - To ask for a mode modification, emit an FSM event that ensures a mode modify only happens when the lchan state allows it. - The new lchan_modify_info struct reflects only those parts that have an effect during a mode modification (before the lchan_activate_info was fully populated, many values not having an effect). - More accurate logging, indicating "Mode Modify" instead of "Channel Activation" A TTCN3 test for the Channel Mode Modify procedure is added in Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both before and after this patch is applied. Related: SYS#4895 Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
2021-04-14 17:39:01 +00:00
lchan2 [label="lchan FSM",shape=box3d]
doc: update/fix FSM charts These reflect the plan for refactoring, and will be implemented by I82e3f918295daa83274a4cf803f046979f284366 and Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb Change-Id: I29e31b753e23a4207662e0e385a337e7df836f45
2018-06-16 14:08:55 +00:00
bssap [label="osmo_bsc_bssap.c",shape=box]
invisible [style="invisible"]
invisible -> bssap [label="BSSMAP Assignment Request",style=dotted]
invisible -> old_lchan [style=invisible,arrowhead=none]
bssap -> gscon [label="GSCON_EV_ASSIGNMENT_START\ndata=struct assignment_request",style=dotted]
gscon -> WAIT_LCHAN_ACTIVE [label="assignment_fsm_start()",style=dotted]
lchan and assignment FSMs: make Channel Mode Modify more sane The Channel Mode Modify procedure is currently implemented for changing a TCH lchan from signalling to voice mode. For that, however, it is re-using (abusing) the channel activation structs and state transitions, and thus always implies activating a voice stream when the mode modification is done. I will add a Channel Mode Modify to enable VAMOS mode soon, so I require separate structs and state transitions which also work on an lchan that already has a voice stream established: a struct lchan_modify_info and LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED. For the part where a Channel Mode Modify enables a voice stream after switching from signalling to speech mode, still use the channel activation code path, but only once the mode modification is done. General improvements: - To ask for a mode modification, emit an FSM event that ensures a mode modify only happens when the lchan state allows it. - The new lchan_modify_info struct reflects only those parts that have an effect during a mode modification (before the lchan_activate_info was fully populated, many values not having an effect). - More accurate logging, indicating "Mode Modify" instead of "Channel Activation" A TTCN3 test for the Channel Mode Modify procedure is added in Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both before and after this patch is applied. Related: SYS#4895 Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
2021-04-14 17:39:01 +00:00
WAIT_LCHAN_ACTIVE -> lchan [label="lchan_activate()\nFOR_ASSIGNMENT",style=dotted]
doc: update/fix FSM charts These reflect the plan for refactoring, and will be implemented by I82e3f918295daa83274a4cf803f046979f284366 and Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb Change-Id: I29e31b753e23a4207662e0e385a337e7df836f45
2018-06-16 14:08:55 +00:00
lchan -> WAIT_LCHAN_ACTIVE [label="ASSIGNMENT_EV_\nLCHAN_\nACTIVE,ERROR",style=dotted]
lchan -> WAIT_LCHAN_ESTABLISHED [label="ASSIGNMENT_EV_\nLCHAN_\nESTABLISHED,ERROR",style=dotted]
WAIT_LCHAN_ACTIVE -> WAIT_RR_ASS_COMPLETE
WAIT_RR_ASS_COMPLETE -> old_lchan [label="RR Assignment\nCommand",style=dotted,constraint=false]
lchan -> WAIT_RR_ASS_COMPLETE [label="RR Assignment\nComplete",style=dotted]
WAIT_RR_ASS_COMPLETE -> WAIT_LCHAN_ESTABLISHED
WAIT_LCHAN_ESTABLISHED -> WAIT_MGW_ENDPOINT_TO_MSC [label="TCH"]
WAIT_LCHAN_ESTABLISHED -> terminate [label="non-TCH"]
WAIT_MGW_ENDPOINT_TO_MSC -> terminate
WAIT_MGW_ENDPOINT_TO_MSC -> gscon2 [label="gscon_connect_\nmgw_to_msc()",style=dotted]
gscon2 -> WAIT_MGW_ENDPOINT_TO_MSC [label="ASSIGNMENT_EV_\nMSC_MGW_OK",style=dotted]
terminate -> gscon2 [label="GSCON_EV_\nASSIGNMENT_END",style=dotted]
lchan and assignment FSMs: make Channel Mode Modify more sane The Channel Mode Modify procedure is currently implemented for changing a TCH lchan from signalling to voice mode. For that, however, it is re-using (abusing) the channel activation structs and state transitions, and thus always implies activating a voice stream when the mode modification is done. I will add a Channel Mode Modify to enable VAMOS mode soon, so I require separate structs and state transitions which also work on an lchan that already has a voice stream established: a struct lchan_modify_info and LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED. For the part where a Channel Mode Modify enables a voice stream after switching from signalling to speech mode, still use the channel activation code path, but only once the mode modification is done. General improvements: - To ask for a mode modification, emit an FSM event that ensures a mode modify only happens when the lchan state allows it. - The new lchan_modify_info struct reflects only those parts that have an effect during a mode modification (before the lchan_activate_info was fully populated, many values not having an effect). - More accurate logging, indicating "Mode Modify" instead of "Channel Activation" A TTCN3 test for the Channel Mode Modify procedure is added in Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both before and after this patch is applied. Related: SYS#4895 Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
2021-04-14 17:39:01 +00:00
WAIT_LCHAN_ACTIVE -> WAIT_LCHAN_MODIFIED [label="assignment_fsm_start()\n(mode modify)"]
WAIT_LCHAN_MODIFIED -> lchan2 [label="lchan_mode_modify()\nMODIFY_FOR_ASSIGNMENT",style=dotted]
lchan2 -> WAIT_LCHAN_MODIFIED [label="ASSIGNMENT_EV_\nLCHAN_\nMODIFIED,ERROR",style=dotted]
WAIT_LCHAN_MODIFIED -> WAIT_MGW_ENDPOINT_TO_MSC [label="needs\nvoice\nstream"]
WAIT_LCHAN_MODIFIED -> terminate [label="no change\nin voice\nstream"]
doc: update/fix FSM charts These reflect the plan for refactoring, and will be implemented by I82e3f918295daa83274a4cf803f046979f284366 and Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb Change-Id: I29e31b753e23a4207662e0e385a337e7df836f45
2018-06-16 14:08:55 +00:00
}