Commit Graph

16 Commits

Author SHA1 Message Date
Neels Hofmeyr 2c61245935 remove extract_sub(), add bsc_subscr_find_or_create_by_mi()
Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.

(More refactoring to use osmo_mobile_identity follows in subsequent patch.)

Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
2020-06-16 14:56:57 +02:00
Alexander Chemeris 962cb637fc Return 0 from gsm0408_rcvmsg() if SCCP link is already closed.
Whether to forward the message or not to an SCCP connection is
an internal question for the GSM 04.08 code. Unlike errors with
the message decoding, memory allocation and other critical errors,
this not an error which should be reported to the caller.
abis_rsl_rx_rll() (the caller) shouldn't know about the message
routing decisions and should only care about actual errors.

This code path is hit in production very often because we frequently
receive a Classmark Change message from a phone right after the MSC
has shut the SCCP connection but before we close the lchan on the BTS.

Change-Id: I2d430ebc894a2345bebaa1841a75e94a3b45eae2
2020-05-29 20:03:26 +00:00
Martin Hauke a29affda98 Fix some typos
Fix typos and common misspellings in code comments and in the manual.

Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-11-13 22:10:41 +01:00
Harald Welte bbd0bfff17 SMSCB: Send ETWS primary warning message via all dedicated channels
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
dedicated channels.

Change-Id: I913d0237cffdcb95037da8489acef5f32a7fc02e
2019-09-06 23:09:54 +02:00
Daniel Willmann 1d5eda4b4c gsm_data.h: Remove unused variable from OpenBSC times
This variable does not seem to be used anywere in OsmoBSC, seems to be a
remnant from OpenBSC times.

Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
2019-04-17 16:01:11 +00:00
Harald Welte 963763dfec Implement CSFB "Fast Return" Handling at RR RELEASE
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.

We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE.  This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.

That in turn will make sure the MS/UE can return very quickly to
the LTE cell.

Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
2019-02-05 16:04:35 +01:00
Daniel Willmann 162626637f gsm_04_08: Free GSM subscr conn if paging response can't be matched
The current idea of calling gscon_release_lchans is not enough because
the conn is still present.
Insetad pretend we got a disconnect indication from the MSC which will
call gscon_release_lchans as well as terminate the conn state machine
which will clean up conn state as well.

Related: OS#3680
Change-Id: Iccf5f6864ffe238189907c4bb3ea333948621b4c
2018-12-06 19:51:21 +00:00
Pau Espin 77cd112993 gsm0408_rcvmsg: Release lchan if L3 fails to complete
gscon_release_lchans stub is added to gsm0408_test.c to make linker
happy.

Change-Id: I1743f9d5cd0fdbc0fb9afe7bcc0271c897915210
2018-11-21 17:59:06 +01:00
Neels Hofmeyr 5b1a7d1e9b lchan release: always Deact SACCH
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-14 16:16:30 +00:00
Neels Hofmeyr 478e991a78 fix: send RR Release (e.g. after BSSMAP Clear Cmd)
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 8b818a01b0
    "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-14 16:16:30 +00:00
Philipp Maier 3b9dcb3fc1 gsm_04_08: improve gsm48_multirate_config()
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.

- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL

Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
2018-10-24 09:22:41 +02:00
Neels Hofmeyr e2209c20c5 Implement RR Classmark Enquiry
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to
the MS.

(The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC,
is already implemented.)

Related: OS#3043 (A5/3 encryption)
Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb
Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
2018-09-18 14:34:32 +02:00
Neels Hofmeyr 81a496340c cosmetic: rename bsc_api.h to gsm_08_08.h
See also I91922f557072d0fb8cfe213a8a7b50f3bb23dea0, which renames
osmo_bsc_api.c to gsm_08_08.c.

Change-Id: I7179eb27183ee213f8fc8d548895b67aa43dc6a2
2018-07-28 12:18:23 +02:00
Neels Hofmeyr 31f525e756 large refactoring: use FSMs for lchans; add inter-BSC HO
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
2018-07-28 12:18:23 +02:00
Neels Hofmeyr 68455f30a0 cosmetic: move RR functions from bsc_api.c to gsm_04_08_rr.c
Rationale: bsc_api.c used to be a kind of kitchen sink for various
implementations, we want to dissolve it. Also, combining 0808 and 0408 in the
same c file causes "weird" linking dependencies for utility and test programs.

bsc_api.c will be completely dissolved in upcoming
Ib7ce026b52d4ba3e53a8b2824e74ea92432c48c5.

Change-Id: Ie8ee334145bf7bc3a601d395ea7ab9b2009b61c7
2018-07-28 12:18:23 +02:00
Neels Hofmeyr 6242742d20 rename gsm_04_08_utils.[hc] to gsm_04_08_rr
"utils" suggests thin helpers to aid using a proper API, while this .c file
actually *is* the proper RR API. Rename from "utils" to "rr".

Change-Id: I0ffff63d57f03cb324df8e40e41caea5b55a2c85
2018-07-28 12:18:23 +02:00