e3d3dc6ea2
Refactor: 1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm. 2. Add separate AUTH_CIPH state to the FSM. 3. Use conn->use_count to trigger conn release. 4. Add separate RELEASING state to the FSM. 5. Add rate counters for each of the three Complete Layer 3 types. Details: 1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm. Historically, a gsm_subscriber_connection was allocated in libbsc land, and only upon Complete Layer 3 did libmsc add the fsm instance. After splitting openbsc.git into a separate osmo-msc, this is no longer necessary, hence: Closely tie gsm_subscriber_connection allocation to the subscr_conn_fsm instance: talloc the conn as a child of the FSM instance, and discard the conn as soon as the FSM terminates. 2. Add separate AUTH_CIPH state to the FSM. Decoding the Complete Layer 3 message is distinctly separate from waiting for the VLR FSMs to conclude. Use the NEW state as "we don't know if this is a valid message yet", and the AUTH_CIPH state as "evaluating, don't release". A profound effect of this: should we for any odd reason fail to leave the FSM's NEW state, the conn will be released right at the end of msc_compl_l3(), without needing to trigger release in each code path. 3. Use conn->use_count to trigger conn release. Before, the FSM itself would hold a use count on the conn, and hence we would need to ask it whether it is ready to release the conn yet by dispatching events, to achieve a use_count decrement. Instead, unite the FSM instance and conn, and do not hold a use count by the FSM. Hence, trigger an FSM "UNUSED" event only when the use_count reaches zero. As long as use counts are done correctly, the FSM will terminate correctly. These exceptions: - The new AUTH_CIPH state explicitly ignores UNUSED events, since we expect the use count to reach zero while evaluating Authentication and Ciphering. (I experimented with holding a use count by AUTH_CIPH onenter() and releasing by onleave(), but the use count and thus the conn are released before the next state can initiate transactions that would increment the use count again. Same thing for the VLR FSMs holding a use count, they should be done before we advance to the next state. The easiest is to simply expect zero use count during the AUTH_CIPH state.) - A CM Service Request means that even though the MSC would be through with all it wants to do, we shall still wait for a request to follow from the MS. Hence the FSM holds a use count on itself while a CM Service is pending. - While waiting for a Release/Clear Complete, the FSM holds a use count on itself. 4. Add separate RELEASING state to the FSM. If we decide to release for other reasons than a use count reaching zero, we still need to be able to wait for the msc_dtap() use count on the conn to release. (An upcoming patch will further use the RELEASING state to properly wait for Clear Complete / Release Complete messages.) 5. Add rate counters for each of the three Complete Layer 3 types. Besides LU, also count CM Service Request and Paging Response acceptance/rejections. Without these counters, only very few of the auth+ciph outcomes actually show in the counters. Related: OS#3122 Change-Id: I55feb379e176a96a831e105b86202b17a0ffe889 |
||
|---|---|---|
| contrib | ||
| debian | ||
| doc | ||
| include | ||
| m4 | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| AUTHORS | ||
| COPYING | ||
| Makefile.am | ||
| README | ||
| README.vty-tests | ||
| configure.ac | ||
| git-version-gen | ||
| osmoappdesc.py | ||
README
About OsmoMSC ============= OsmoMSC originated from the OpenBSC project, which started as a minimalistic all-in-one implementation of the GSM Network. In 2017, OpenBSC had reached maturity and diversity (including M3UA SIGTRAN and 3G support in the form of IuCS and IuPS interfaces) that naturally lead to a separation of the all-in-one approach to fully independent separate programs as in typical GSM networks. OsmoMSC was one of the parts split off from the old openbsc.git. Before, it was the libmsc part of the old OsmoNITB. Since a true A interface and IuCS for 3G support is available, OsmoMSC exists only as a separate standalone entity. OsmoMSC exposes - GSUP towards OsmoHLR (or a MAP proxy); - A over IP towards a BSC (e.g. OsmoBSC); - IuCS towards an RNC or HNB-GW (e.g. OsmoHNBGW) for 3G voice; - MNCC (Mobile Network Call Control derived from GSM TS 04.07); - SMPP 3.4 (Short Message Peer-to-Peer); - The Osmocom typical telnet VTY and CTRL interfaces. Find OsmoMSC issue tracker and wiki online at https://osmocom.org/projects/osmomsc https://osmocom.org/projects/osmomsc/wiki