aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/lchan_fsm.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-26lchan_fsm: silently ignore LCHAN_EV_RLL_ERR_INDHarald Welte1-0/+8
The RLL ERR IND is sent by the BTS in any number of casese that lead to a disconnect of a radio link layer, for example due to bad RF conditions. The lchan FSM currnently prints error messages about this event not being permitted, leading to confusion among users. Let's ignore this event, I don't think the lchan FSM should or could be doing anything as a result. We could also simply remove that event, but let's keep it in case we should need it in the future. Change-Id: I07aad62d25566d6068a95797915bb97fc3c66328
2020-07-18Move struct gsm_bts: gsm_data.* => bts.*Pau Espin Pedrol1-1/+1
Place all code related to the object into the related file. Having all the data model in one file made sense in early stage of development to make progress quickly, but nowadays it hurts more than helps, due to constantly growing size and more and more bits being added to the model, gaining in complexity. Currently, having lots of different objects mixed up in gsm_data.h is a hole of despair, where nobody can make any sense were to properly put new stuff in, ending up with functions related to same object in different files or with wrong prefixes, declarations of non-existing functions, etc. because people cannot make up their mind on strict relation to objects in the data model. Splitting them in files really helps finding code operating on a specific object and helping with logically splitting in the future. Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
2020-07-16propagate RSL error cause codes to RR Channel Release causeNeels Hofmeyr1-0/+5
In various places that receive an error cause from RSL and place it in lchan.release.rsl_error_cause, translate it to an RR cause and place that in the recently added lchan.release.rr_cause. Hence the RR Channel Release message now reflects more specific error causes when the reason for the error was received in an RSL message's cause value. Change-Id: I46eb12c91a8c08162b43dd22c7ba825ef3bbc6ac
2020-07-16RR Channel Release: pass Cause code from BSSMAP Clear to the BTSNeels Hofmeyr1-1/+3
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause value to lchan.release.cause_rr. In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause value, these are unrelated. Store in new lchan.release.cause_rr instead. The rsl_error_cause is apparently only used for logging, except for one place in lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so there should not be a functional difference by this fix. Propagate the BSSMAP Clear Command cause to the RR Channel Release: Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens in bssmap_handle_clear_cmd(). Adjust event handling in gscon_fsm_allstate(); there, pass the cause to gscon_release_lchans(). In gscon_release_lchans(), pass the cause to gscon_release_lchan(), and then lchan_release(), which sets the new lchan.release.cause_rr to the passed cause value. As soon as the lchan FSM enters the proper state, it calls gsm48_send_rr_release(). There, set the cause value in the encoded message to lchan.release.cause_rr. Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command cause code for normal release, it just passes 0 which amounts to GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC. This means in practice that we will now see an error cause in RR Channel Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc). A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b (osmo-ttcn3-hacks). Related: SYS#4872 Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
2020-07-15Fix trailing whitespace in several filesPau Espin Pedrol1-1/+1
Change-Id: Ide9921dfce3b6d7c580edaa612a3063c94319a02
2020-05-19stats: Add counters and gauges for BORKEN lchans/TSAlexander Chemeris1-0/+32
Now we can monitor the situation with the BORKEN lchans and TS in our BTS's over time. Change-Id: I427bbe1613a0e92bff432a7d76592fe50f620ebe
2020-05-09lchan: Allow transition from BORKEN state to WAIT_RF_RELEASE_ACKAlexander Chemeris1-0/+1
In the lchan_fsm_borken() we request to change the state to LCHAN_ST_WAIT_RF_RELEASE_ACK in response to a late LCHAN_EV_RSL_CHAN_ACTIV_ACK event but this transition is prohibited by the FSM definition, so the channels stay in the BORKEN state forever. :( Change-Id: I17a9b935a116eb842fd0239ef53d73bef35e6511
2020-05-04timers: T->X: 23002, 23004, 23005, 23006Oliver Smith1-1/+1
Make various internally used timers negative, to indicate that they are Osmocom specific. A follow-up patch will make them configurable. Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
2019-11-19bsc: Adapt maximum MS Power Ctrl level based on band and MS Power classPau Espin Pedrol1-2/+4
Related: OS#4244 Change-Id: I6bff440b7797e710bca5af94fae546e5d55e6972
2019-04-30move mgw endpoint FSM to osmo-mgw.gitNeels Hofmeyr1-4/+5
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example I92a9944acc96398acd6649f9c3c5badec5dd6dcc. Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
2019-04-23use libosmocore osmo_tdefNeels Hofmeyr1-5/+5
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API and use libosmocore's osmo_tdef* API instead. The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be able to use it in osmo-msc for inter-MSC handover. When adding osmo_tdef, the new concept of timer groups was added to the API. It would make sense to apply group names here as well, but do not modify the VTY configuration for timers. The future might bring separate groups (or not). Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore) Change-Id: I66674a5d8403d820038762888c846bae10ceac58
2019-04-08lchan activation: add explicit encryption info to activationNeels Hofmeyr1-10/+7
For intra-BSC handover, the previous encryption is copied from the old lchan, which of course is not available during inter-BSC handover. Hence the lchan activation info needs to include an explicit encryption information, and we must not rely on the presence of the previous lchan to copy encryption information from. Add struct lchan_activate_info.encr to allow passing encryption info through lchan_activate() without requiring a previous struct gsm_lchan to be present. Instead of copying from the old lchan, always copy encryption info to lchan_activate_info, and during activation, just before sending the Channel Activation, copy the lchan_activate_info.encr to the new lchan. This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which obtains the encryption information from an intra-BSC-incoming Handover Request message. Related: OS#3842 Related: I5b269f50bd2092516bfdf87746196983d3ac49d1 Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
2019-03-19lchan_fsm: add missing header file.Philipp Maier1-0/+1
The symbol GSM0808_SC_CFG_AMR_4_75_5_90_7_40_12_20 is used in lchan_fsm.c, but gsm_08_08.h, where the symbol is declared is not included. Change-Id: I46f910b3e0f2c7d8c78c1681acef30b9419e39f0
2019-03-19lchan_fsm: do not include 12.2k in active set on HR channelsPhilipp Maier1-0/+9
When "Config-NB-Code = 1" is set via the S-bits, then the resulting multirate configuration IE will contain 12.2K. Since the generator function is not aware if the lchan is activated for HR or FR it sets the flag for 12.2k always. We have to add a check here in order to set the 12.2k flag in the IE back to 0 so that the active set contains a set of useable rates. Change-Id: I40e7f568f4822040a2d1e78f22dbba0e49d0167e Related: SYS#4470
2019-03-19lchan_fsm: make sure multi rate configuration is validPhilipp Maier1-1/+6
When gsm48_mr_cfg_from_gsm0808_sc_cfg() is used to generate the AMR multirate configuration IE, make sure that lchan allocation fails in cases where the multirate configuration IE can not be generated. Change-Id: Icd3e5674b10b8ae223c0d13ae33fc9ae7e8a8a18 Depends: libosmocore I6fd7f4073b84093742c322752f2fd878d1071e15 Related: SYS#4470
2019-02-07bsc_vty: add features to disable specific lchans via vtyPhilipp Maier1-0/+1
In some test and debug situations it is useful to have the ability to lock certain lchans in a way that the BSC can not allocate them. One application might be to simulate an exhaustion of all TCH/H channels in order to force the BSC to take one of the available TCH/F. Lets add a command to the vty which alloes us sen lchans from LCHAN_ST_UNUSED to LCHAN_ST_BORKEN and vice versa. Change-Id: I397e68e26d6a1727890353fa34f4897b54795866 Related: OS#3503
2019-02-06handover_fsm: do not access conn->assignment.req, it may be outdatedNeels Hofmeyr1-0/+1
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current lchan's AMR configuration. However, conn->assignment.* values are only valid during an ongoing assignment. Those values may be overwritten by any failed Assignment attempt, at any time, and hence do not reflect the currently assigned conn->lchan. Those realms must be kept separate. The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most sense to store these values in struct gsm_lchan once the lchan activation succeeded. Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during lchan_activate(). In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*. Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
2018-12-21comments: describe some lchan detailsNeels Hofmeyr1-1/+1
(requested by pespin) Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr1-70/+72
Fix crash after AMR configuration fails. The crash is due to an assertion that finds a non-NULL conn in the lchan, when re-using an lchan that has failed in AMR configuration earlier on. That is because the AMR config still happens in state UNUSED. DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE ... DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED ... ... DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324) Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491 The FSM design idea is that when returning to the UNUSED state, all lchan state is cleared. However, when calling lchan_activate(), a failure may happen still in state UNUSED, so that we don't transition *back* to UNUSED properly. So, first transition out of UNUSED before failures can happen. (Other ways to solve this would be to invoke lchan clearing even if already in UNUSED, but semantically, transitioning first makes more sense.) Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to UNUSED and clear the lchan. Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter(). Also, there is a bit of duplication of members of the lchan->activate (lchan state) and the lchan_activate_info (passed to lchan_activate()) structs. The fix for this also removes the dup: Add struct lchan_activate_info as child struct at lchan->activate.info, drop the other lchan->activate members that would dup .info.*. Move struct lchan_activate_info declaration to gsm_data.h. Apply the new '.info' member struct throughout the code. Related: OS#3737 Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
2018-12-05bsc: lchan_fsm: Fix invalid duplicated transitionPau Espin Pedrol1-1/+4
When we enter WAIT_RLL_RTP_RELEASED (lchan_fsm_wait_rll_rtp_released_onenter), we call lchan_do_release() which in turn dispatches LCHAN_RTP_EV_RELEASE to lchan_rtp_fsm.c, which will dispatch back an LCHAN_EV_RTP_RELEASED event, which will be handled by lchan_fsm_wait_rll_rtp_released(), which will change state to WAIT_BEFORE_RF_RELEASE. When going back the stack (return), we are still in lchan_fsm_wait_rll_rtp_released_onenter() which again triggers a change state to WAIT_BEFORE_RF_RELEASE because it checks same conditions than first one. 20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1388 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: lchan detaches from conn SUBSCR_CONN(conn3)[0x612000002da0] 20181128203727051 DMSC osmo-bsc/lchan_fsm.c:1391 SUBSCR_CONN(conn3)[0x612000002da0]{CLEARING}: lchan lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] detaches from conn 20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1359 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: state_chg to WAIT_RLL_RTP_RELEASED 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:959 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) SAPI[0] = 1 20181128203727052 DRR osmo-bsc/gsm_04_08_rr.c:254 Sending Channel Release: Chan: Number: 0 Type: 2 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:945 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Received Event LCHAN_RTP_EV_RELEASE 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Terminating (cause = OSMO_FSM_TERM_REGULAR) 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Freeing instance 20181128203727052 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Deallocated 20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: Received Event LCHAN_EV_RTP_RELEASED 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:856 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) Still active SAPIs: 0 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:1011 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: state_chg to WAIT_BEFORE_RF_RELEASE 20181128203727052 DRSL osmo-bsc/abis_rsl.c:633 (bts=0,trx=0,ts=6,ss=0) DEACTivate SACCH CMD 20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:986 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_BEFORE_RF_RELEASE}: transition to state WAIT_BEFORE_RF_RELEASE not permitted! Change-Id: I5d95bbd8244cc8e9c1cfb6fe0f76148332386a3d
2018-12-05bsc: lchan_fsm: Add missing transition WAIT_TS_READY->WAIT_RLL_RTP_RELEASEDPau Espin Pedrol1-0/+1
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance 20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated 20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED 20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted! Change-Id: I43aab5ed8ac369869b191b3b7c938ce4985ab849
2018-11-30follow-up: logging tweak for Immediate AssignmentNeels Hofmeyr1-6/+4
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged before fixeria's code review could be incorporated. Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
2018-11-27send Immediate Assignment Reject only before Immediate AssignmentNeels Hofmeyr1-3/+12
Set flag lchan->activate.immediate_assignment_sent to true when sending, and omit a reject after that. lchan->activate gets completely zeroed in lchan_reset(), which sets that flag back to false whenever an lchan becomes inactive. Related: OS#3709 Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
2018-11-14lchan: set cause for 4 instances of release_in_error = trueNeels Hofmeyr1-0/+3
Make sure some RSL cause is set. Change-Id: I372ade9fc58919fbf858ce14caab8a0a22dbb083
2018-11-14cosmetic: lchan: introduce sub-struct lchan->release.*Neels Hofmeyr1-31/+32
Put all lchan release related flags and settings in a sub-struct named 'release' to better indicate what those fields are for. There is no functional change. Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
2018-11-14lchan release: always Deact SACCHNeels Hofmeyr1-11/+10
If an lchan is being released and had a SACCH active, there is no reason to omit the Deact SACCH message ever. All of the callers that passed do_deact_sacch = false did so for no good reason. Drop the do_deact_sacch flag everywhere and, when the lchan type matches and SAPI[0] is still active, simply always send a Deact SACCH message. The do_deact_sacch flag was carried over from legacy code, by me, mainly because I never really understood why it was there. I do hope I'm correct now, asserting that having this flag makes no sense. Change-Id: Id3301df059582da2377ef82feae554e94fa42035
2018-11-14lchan: release in error: fix missing messages / eventsNeels Hofmeyr1-12/+18
In the case where there is a release in error and we skip immediately to the RF Release state, send all of Deact SACCH, RR Release messages and also signal the lchan_rtp_fsm as appropriate. Move that code to static lchan_do_release() and call from both lchan_fsm_wait_rll_rtp_released_onenter() in the normal case, as well as lchan_release() when skipping that. When releasing in error, but we're already in LCHAN_ST_WAIT_RLL_RTP_RELEASED, those messages have already been sent and we can skip them. Change-Id: I648a9826ce56b611359f81462ca03e4ab4c736aa
2018-11-14fix: send RR Release (e.g. after BSSMAP Clear Cmd)Neels Hofmeyr1-10/+11
After commit [1], the code makes sure to disassociate lchan and conn before invoking the lchan release. However, we only send RR Release if a conn is present, which clearly is nonsense after [1]. [1] commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb "subscr conn: properly forget lchan before release" Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db Manage sending of RR Release via a flag, set during invoking lchan release. Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care whether a conn is still associated (because it won't ever be since [1]). That way we can intelligently decide what release process makes sense (whether the lchan terminates the subscriber connection or whether the connection goes on at another lchan), and still disassociate lchan and conn early. BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the f_expect_chan_rel() don't care whether an RR Release happens or not. This is being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845. So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear. Related: OS#3413 Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
2018-11-09dbug log: verbosely detach conn<->lchanNeels Hofmeyr1-0/+13
When reading the log of OS#3686, I wished for explicit logging of when exactly an lchan disassociates from a conn. Here is the debug logging I would have liked to see. I'm not sure whether we really need to merge this patch... Change-Id: I97558b899e7f2578ba98287e7352dc072d02ce44
2018-11-09lchan: rf release: make sure conn is NULLNeels Hofmeyr1-1/+3
lchan_fsm_wait_rf_release_ack_onenter() calls gscon_forget_lchan(). At the point where the conn has no lchan, the lchan must not have a conn. Make sure that conn is NULL after gscon_forget_lchan(). I hope this fixes OS#3686, it is the only situation I could find where the disassociation is potentially one-sided. I get the feeling that this should be hardcoded in gscon_forget_lchan(), but I dimly remember other situations that are less trivial, where it doesn't necessarily make sense to forget reciprocically. So only fixing this one now. Related: OS#3686 Change-Id: If0c6e495e419b9dbb44443c3fc3f54dd4b714aa5
2018-11-09lchan_fsm_cleanup: drop redundant 'forget_lchan' callNeels Hofmeyr1-2/+0
Right below this call, we invoke lchan_reset(), and the first thing it does is gscon_forget_lchan(). Drop this redundant invocation. Change-Id: I503efceb6d34c8df0cdfef3dfc83fa1e61271c47
2018-10-24lchan_fsm: generate proper multirate configuration IE on RSLPhilipp Maier1-58/+66
During the generation of the multirate configuration IE in the channel activation message that is sent over RSL, all AMR rates except the highest one are trimmed. This was to ensure that the multirate configuration IE only contains one codec rate per active set. Lets fix that and generate a proper IE with threshold and hysteresis values. - extend lchan_mr_config so that it can generate a full multirate configuration IE Change-Id: I7f9f8e8d9e2724cbe3ce2f3599bc0e5185fd8453 Related: OS#3529
2018-10-12lchan_fsm: notify conn of released lchan upon RF ReleaseNeels Hofmeyr1-0/+7
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154 Change-Id: I7621616c24588c2db15ad1ae7ca68cfa0fb76f66
2018-10-12lchan_fsm: fix failure handling: notify conn when releasedNeels Hofmeyr1-0/+3
Usually, conn->lchan is set to NULL before/upon releasing it. However, if the lchan is still associated with a conn upon/after release, make sure the conn realizes it has no lchan and sends a BSSMAP Clear Request to the MSC. lchan_reset() is the last step before an lchan is fully unused. In there, make sure to notify any conn that might still be associated, with gscon_forget_lchan(). lchan_cleanup() does the same, but in fact this is only called when an lchan is *deallocated*, but instead it usually merely goes to the UNUSED state. It may make sense to call gscon_forget_lchan() sooner, e.g. when entering a releasing state. This here nevertheless is a final safeguard. Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154 Change-Id: I88337a18246c44ba48da64bb611a3cbb647a750e
2018-10-05codec_pref: handle S0-S15 in ASSIGNMENT REQUESTPhilipp Maier1-2/+43
Opposed to all other codecs that are common in GSM, AMR requires a codec configuration that is expressed by a bitmask (S0 to S15) in the speech codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those configuration in the ASSIGNMENT COMPLETE message. At the moment osmo-bsc ignores all incoming configuration bits. The bits in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded. - Store the configuration bits while parsing the ASSIGNMENT COMPLETE - Create an intersection with the configuration that is actually supported by the BSS - Return the resulting (chosen) configuration bits with the assignment complete message. - Use the (highest of the) agreed codec rates in RSL channel activation. Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737 Related: OS#3529
2018-09-11ts,lchan_fsm: do not attempt to allocate CBCH subslotsNeels Hofmeyr1-0/+7
In case a given channel combination contains a CBCH, it replaces sub-slot 2 with a CBCH, i.e. we must not attempt to allocate the same for SDCCH. On timeslot initialization, immediately place such an lchan FSM into new state LCHAN_ST_CBCH, so that it never appears unused and never is picked during lchan_select(). Also set lchan->type = GSM_LCHAN_CBCH. Verified by configuring CBCH timeslots and watching 'show lchan summary'. Immediately after RSL and OML are up, these pchan types show lchan 2 in state CBCH: BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm With a 'phys_chan_config ccch+sdcch4+cbch' and three phones simultaneously requesting USSD, I see: BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 14 dBm RXL-FULL-dl: -53 dBm RXL-FULL-ul: -47 dBm BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 1, Type SDCCH, State ESTABLISHED - L1 MS Power: 30 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 3, Type SDCCH, State ESTABLISHED - L1 MS Power: 16 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm With 'phys_chan_config SDCCH8+CBCH' and three phones simultaneously attaching, I see: BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm i.e. in all cases the CBCH lchan remains occupied and is not allocated as SDCCH. Detaching and re-attaching the BTS reliably brings back the CBCH state. Also verified that changing the osmo-bsc config from telnet vty and dropping oml followed by the BTS re-attaching brings back the CBCH state. Change-Id: I2bafc5f696e818e38f8907ad0c8f38494df0623d
2018-09-10lchan_fsm: allow late RTP release events without erroringNeels Hofmeyr1-0/+9
Change-Id: Ia463f97402b957bd13a95d18d291d1c1f006f089
2018-08-29lchan: pick proper power and ta valuesNeels Hofmeyr1-6/+15
When activating an lchan, the power levels should be maximum and TA zero. Only if a new lchan is assigned within the same cell does it make sense to take over the previous power and TA levels. In LCHAN_EV_ACTIVATE: - Separate the code that copies previous encryption data. This should happen regardless of whether we're staying in the same cell or not. - For the power,TA levels, take over an old lchan's values only when it is assigning a new lchan in the same cell. Change-Id: I360b003398487fa6f934296ff03643c33ec61a35
2018-08-29cosmetic: lchan activ: drop todo commentsNeels Hofmeyr1-2/+0
Drop the todo comments about "for_conn->encr". I have intended that as an idea to store encryption info in the conn instead of the lchan, which might make sense, but there's no use in these comments. Change-Id: I47e90062c784dd7919fff3115e2bee3314b30cd5
2018-08-29cosmetic: lchan activ: no need to clear mr againNeels Hofmeyr1-2/+0
In lchan state UNUSED, on activating an lchan, we zero out the lchan->mr_ms_lv and mr_bts_lv. However, in UNUSED's onenter function, we already called lchan_reset(), clearing out the lchan completely. Drop two lines of unnecessary code. Change-Id: I8b38f222f1c8c822e8e5e776850dbc60e30e8b8d
2018-08-29lchan_fsm: safer 'concluded' flagNeels Hofmeyr1-7/+9
The flag lchan->activate.concluded prevents entering the lchan_on_fully_established()/lchan_on_activation_failure() more than once. So far it was checked by callers, instead place in the functions themselves. There is a potential functional change here, since during lchan_fail(), the concluded flag was set only after entering lchan_on_activation_failure(). Now it is already set at the start and prevents multiple re-entry beyond doubt. This patch is not a result of an actual observed faulty behavior, just from reading the code and seeing the slight loophole. Change-Id: I0c906438b05442d66255203eb816453b7193a6d8
2018-08-29cosmetic: lchan_fsm failure: log about state transitionsNeels Hofmeyr1-2/+9
Early on during failure, log which state transition is intended after failure handling. If such state is already reached after failure handling, do not log "state transition not permitted", but rather skip the state change and log "Already in state X". Change-Id: I81f53b38637823e62860cb773b7573bb5c21fdb0
2018-08-29lchan_fsm: lchan_fail_to(): store target state earlyNeels Hofmeyr1-1/+3
lchan_fail_to() is a macro to preserve useful source file:line information in logging. But a side effect is that its target state argument might evaluate differently at the end of the macro, if, say, the fi->state has changed. I hit such an instance on timeout of WAIT_RLL_RTP_ESTABLISH: lchan_fsm_timer_cb() calls macro lchan_fail(), which calls lchan_fail_to(lchan_fsm_on_error[fi->state]). Unlike for normal function invocation, this argument changes as fi->state changes. Since releasing the lchan_rtp_fsm already transitions the lchan fi into WAIT_RF_RELEASE_ACK, the final state change of lchan_fail_to() suddenly evaluates to the broken state instead of the intended WAIT_RF_RELEASE_ACK. Early in lchan_fail_to(), store the argument's value as of macro invocation. Change-Id: Id9bf4580a112ee5629f553a8bcb6b5b03b1c5f53
2018-07-28create separate logging categories for lchan,ts,as FSMsNeels Hofmeyr1-1/+1
Change-Id: Ie889b8860a4a63c7c22ef65025f690d64cd7330c
2018-07-28lchan_fsm: add in_release_handler flagNeels Hofmeyr1-7/+17
If a release event is being handled, ignore other ricocheting release events until that release handling has concluded. For example, if an lchan is regularly released, it signals the lchan RTP FSM to release, which then calls back to say "RTP is released" on termination -- this should not trigger other state changes than the initial release intends. Change-Id: Iec41e006b6ab9d0f618d36925341f9536353e5d8
2018-07-28lchan_fsm: split off lchan_rtp_fsm, establish RTP a bit earlierNeels Hofmeyr1-451/+169
Change-Id: Id7a4407d9b63be05ce63f5f2768b7d7e3d5c86fb
2018-07-28cosmetic: FSMs: allow ignorable eventsNeels Hofmeyr1-2/+38
In various FSMs, some events may appear later or earlier without need of action. Do not indicate these as 'ERROR' (event not permitted), but allow and ignore them. Debug-log about some of those. From the old code, we've taken over the habit to change into WAIT_BEFORE_RF_RELEASE even before SAPI[0] is released. Hence we may still receive a SAPI[0] REL_IND in WAIT_BEFORE_RF_RELEASE. Don't show this as error message, just silently accept it. Change-Id: Ie320c7c6a1436184aaf2ec5a1843e04f4b3414ab
2018-07-28large refactoring: use FSMs for lchans; add inter-BSC HONeels Hofmeyr1-0/+1522
Add FSMs: - timeslot_fsm: handle dynamic timeslots and OML+RSL availability. - lchan_fsm: handle an individual lchan activation, RTP stream and release, signal the appropriate calling FSMs on success, failure, release. - mgw_endpoint_fsm: handle one entire endpoint with several CI. - assignment_fsm: BSSMAP Assignment Request. - handover_fsm: all of intra, inter-MO and inter-MT handover. Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing the maximum amount events (32), and it is more logical to treat assignment, handover and MGW procedures in separate FSMs. - Add logging macros for each FSM type: - LOG_TS() - LOG_LCHAN() - LOG_MGWEP(), LOG_CI() - LOG_ASSIGNMENT() - LOG_HO() These log with the osmo_fsm_inst where present. New style decision: logging without a final newline char is awkward, especially for gsmtap logging and when other logs interleave LOGPC() calls; we have various cases where the final \n goes missing, and also this invokes the log category checking N times instead of once. So I decided to make these macros *always* append a newline, but only if there is no final newline yet. I hope that the compiler optimizes the strlen() of the constant format strings away. Thus I can log with or without typing "\n" and always get an \n termination anyway. General: - replace osmo_timers, state enums and program-wide osmo_signal_dispatch() with dedicated FSM timeouts, states and events. - introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def. These can be used (with some macro magic) to define a state's timeout once, and not make mistakes for each osmo_fsm_inst_state_chg(). Details: bsc_subscr_conn_fsm.c: - move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and mgw_endpoint_fsm. - There is exactly one state for an ongoing Assignment, with all details handled in conn->assignment.fi. The state relies on the assignment_fsm's timeout. - There is one state for an ongoing Handover; except for an incoming Handover from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn are both established. - move bssmap_add_lcls_status() to osmo_bsc_lcls.c abis_rsl.c: - move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in abis_rsl.c - reduce some rsl functions to merely send a message, rename to "_tx_". - rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function. - move all timers and error/release handling away into various FSMs. - tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an lchan passed, but just mode,type that they require. Rename to ipacc_speech_mode*() and ipacc_payload_type(). - add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR message received during BSSMAP Handover Command. - move various logging to LOG_LCHAN() in order to log with the lchan FSM instance. One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging from DRR to DRSL. It might actually make sense to combine those categories. - lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance. - handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's correct). - gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS. assignment_fsm.c: - the Chan Mode Modify in case of re-using the same lchan is not implemented yet, because this was also missing in the previous implementation (OS#3357). osmo_bsc_api.c: - simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv twice, once by member assignment and then again with a memcpy.) - During handover, we used to copy the MR config from the old lchan. Since we may handover between FR and HR, rather set the MR Config anew every time, so that FR rates are always available on FR lchans, and never on HR lchans. Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore), I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore) Change-Id: I82e3f918295daa83274a4cf803f046979f284366
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 13:18:53 +0000