aboutsummaryrefslogtreecommitdiffstats
path: root/include/osmocom/bsc
AgeCommit message (Collapse)AuthorFilesLines
2020-07-31Introduce support for ACC ramping during whole BTS life cyclePau Espin Pedrol1-6/+18
Prior to this patch, ACC ramping was only used to go 0->N in the number of allowed ACCs during BTS startup. It could optionally dynamically stretch or extend the ramping time based on channel load. With this patch, ACC ramping is kept alive during the entire time the BTS is active, and subset of allowed ACCs can now be incresed or decreased based on channel load. A new VTY command "access-control-class-ramping-chan-load" is added to configure a lower and an upper threshold. Channel load under the low threshold will potentially trigger an increment of the subset size of allowed ACCs, while a channel load over the upper threshold will potentially trigger the opposite (a decrease in size). The time between checks is kept fixed per VTY command (reusing old "access-control-class-ramping-step-size"), but the "dynamic" option is deprecated and ignored from now on since it provides nothing valuable in the new implementation, because the size always dynamically changes based on channel load (configured thresholds). Related: SYS#4912 Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
2020-07-29Introduce support for ACC subset rotationPau Espin Pedrol2-38/+35
See updated documentation section in manuals/chapters/bts.adoc regarding an explanation on how the system works. Related: SYS#4911 Change-Id: I952c9eeae02809c7184078c655574ec817902e06
2020-07-20rename files acc_ramp.* -> acc.c*Pau Espin Pedrol3-2/+2
With upcoming next commit, the file will contain far more code that simply ramping, so rename it to be more generic. Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
2020-07-18Move gsm_bts_{trx_}set_system_infos APIs to bts{_trx}.*Pau Espin Pedrol3-3/+4
Change-Id: I2aa83b499d6e5d06a0fa1001fee3111f7e639c94
2020-07-18Move struct gsm_bts_trx: gsm-data.* => bts_trx.*Pau Espin Pedrol4-74/+95
See rant fro similar recent commit moving stuff to bts.*. Change-Id: I11758ca3d255d849d77bd068f24bb68bde1f89a5
2020-07-18bts: Drop duplicated function to get trx by numberPau Espin Pedrol2-2/+1
In the big mess of gsm_data we reached a point where we have multiple functions doing the same thing, most probably because it's hard finding stuff in there. Let's drop one of them (the one which less callers) and move it to bts.*, where it belongs. Change-Id: I9071a0ab250844619280fbe2be63ed99f2c87eb1
2020-07-18Move struct gsm_bts: gsm_data.* => bts.*Pau Espin Pedrol3-626/+641
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/+1
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 Hofmeyr2-1/+11
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-2/+2
Change-Id: Ide9921dfce3b6d7c580edaa612a3063c94319a02
2020-07-15gsm_data.h: Drop duplicated include stdint.hPau Espin Pedrol1-1/+0
Change-Id: I7610cffc3a641975e05ba4ea9f469e12c99e407f
2020-07-08SI2quater: allow storing 48 EARFCNsNeels Hofmeyr1-1/+4
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical maximum is 48 (of course depending on how many bits are used by other SI2quater elements). Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
2020-07-03system_information: publicly declare generate_cell_chan_list()Vadim Yanitskiy1-0/+1
Change-Id: Idc7a9ed558ed6897e15a0f6d3c23418db7cee0d0
2020-06-23fix crashes due to OSMO_ASSERT(conn->lchan)Vadim Yanitskiy1-1/+2
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed that osmo-bsc crashes with the following message: Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376 The cause of this is a recently merged patch that calls conn_get_bts() during assignment_fsm rate counter dispatch: "Count assignment rates per BTS as well" commit b5ccf09fc4042c7fb1fdaaa6263961c40b32564e Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a The root cause being that the assignment_fsm attempts to count an Assignment event for a BTS after the lchan has already been released and disassociated from the conn. The assertion is found in conn_get_bts(), which is used in various places. In fact, each caller is a potential DoS risk -- though most are in code paths that are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the relatively volatile presence of an lchan is not a good idea for osmo-bsc's stability and error resilience. - Change conn_get_bts() to return NULL in the lack of an lchan. - Adjust all callers of conn_get_bts() to gracefully handle a NULL return val. - Same for cgi_for_msc() and callers, closely related. Here is a backtrace: Program received signal SIGABRT pwndbg> bt 0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376 0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758 0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325 0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257 0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260 0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291 0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953 0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6 0x0000555555b61bbe in _start () In the case of the assignment_fsm counter, we now miss a chance to increase a BTS counter for a failed Assignment, but this is a separate problem. The main point of this patch is that osmo-bsc must not crash. Related: OS#4620, OS#4619 Patch-by: fixeria Tweaked-by: neels Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
2020-06-21Count RSL DELETE INDICATION received from BTSHarald Welte1-0/+3
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends us an RSL DELETE INDICATION. So far, osmo-bsc logs this as <0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14 which is not very helpful. Instead, make the log message more descriptive and add a rate counter for monitoring. Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4 Closes: OS#3190
2020-06-17MSC pooling: add rate countersNeels Hofmeyr2-0/+17
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f (osmo-ttcn3-hacks). Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
2020-06-17MSC pooling: add 'no allow-attach' for MSC off-loadingNeels Hofmeyr1-0/+1
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid attaching new subscribers to it: 4.5a.1: "UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool." Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
2020-06-17MSC pooling: make NRI mappings VTY configurableNeels Hofmeyr2-0/+5
Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-06-16use osmo_mobile_identity API everywhereNeels Hofmeyr2-3/+3
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore) Change-Id: I71c3b4c65dbfdfa51409e09d4868aea83225338a
2020-06-16remove extract_sub(), add bsc_subscr_find_or_create_by_mi()Neels Hofmeyr3-4/+3
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-16Count assignment rates per BTS as wellDaniel Willmann1-0/+14
This adds the assignment counters for the BTS as well and changes the assignment_count() macro to increase both the counters for the BSC as well as the BTS. Related: SYS#4877 Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
2020-06-16abis_rsl: Count successful channel requestsDaniel Willmann1-0/+2
Ticket: SYS#4877 Change-Id: I5c51956569223e802f4789dc5ed1605d18f80aea
2020-06-16gsm_data.h: Remove period at end of counter descriptionDaniel Willmann1-19/+19
Change-Id: I045cef207603074bd018e40f984263d03db31405
2020-06-10refactor bsc_find_msc()'s round-robinNeels Hofmeyr1-0/+4
Prepare for MSC pooling by NRI. Before introducing actual NRI decoding and MSC matching, fix the bsc_find_msc() implementation. (Indicate the places relevant for NRI by "TODO" comments). bsc_find_msc() puts an MSC to the end of the internal list of MSCs when it was used. This has problems: - Modifying the list affects VTY output, e.g. 'show running-config' and 'show mscs' change their order in which MSCs are shown, depending on how often a round-robin selection has taken place. - Emergency calls and normal calls potentially pick quite different sets of eligible MSCs. When the round-robin choices between these sets affect each other, the choice is not balanced. For example, if only the first MSC is allow_emerg == true, every emergency call would reset the round-robin state to the first MSC in the list, also for normal calls. If there are regular emergency calls, normal calls will then tend to load more onto the first few MSCs after those picked for emergency calls. Fix: Never affect the ordering of MSCs in the internal list of MSCs. Instead, keep a "next_nr" MSC index and determine the next round-robin target like that. Keep a separate "next_emerg_nr" MSC index so that emergency call round-robin does no longer cause normal round-robin to skip MSCs. Further problems in current bsc_find_msc(): - The "blind:" label should also do round-robin. - The "paging:" part should not attempt to use disconnected MSCs. - Both should also heed NRI matches (when they are added). Fix: instead of code dup, determine Paging Response matching with an earlier Paging Request right at the start. If that yields no usable MSC, continue into the normal NRI and round-robin selection. The loop in this patch is inspired by the upcoming implementation of MSC pooling by NRI, as indicated by the two TODO comments. The point is that, in the presence of an NRI from a TMSI identity, we always need to iterate all of the MSCs to find possible NRI matches. The two round-robin sets (Emergency and non-Emergency) are determined in the same loop iteration for cases that have no or match no NRI, or where a matching MSC is currently disconnected. Change-Id: Idf71f07ba5a17d5b870dc1a5a2875b6fedb61291
2020-05-31handover_test: use 'unknown' BTS type instead of 'sysmobts'Vadim Yanitskiy1-0/+1
This unit test does not really need a BTS of such specific type. Change-Id: Id676042518d06e94a9fb20112334280e2b91074b
2020-05-31gsm_data: cosmetic: mark argument of is_*_bts() as constVadim Yanitskiy1-6/+6
Change-Id: Ifa084e34cbea006e09c83a530e1434a22895e9aa
2020-05-29flatten: move network->bsc_data->* to network->*Neels Hofmeyr2-22/+10
The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-29drop MSC types "local" vs "normal"Neels Hofmeyr1-6/+0
Another legacy feature. All that this setting effectively does is prevent MSCs from being contacted for non-emergency calls. To select which MSCs shall handle emergency calls, there is the allow_emerg flag. Change-Id: I7fc630d9c35be9a69a0d378d3de2b2312c69690d
2020-05-29drop all BSC originated USSD notification featuresNeels Hofmeyr6-38/+0
The BSC is the wrong network component to originate USSD messaging, as can be seen in the hacks in the USSD code: for example, the BSC would send a CM Service Accept message as if an MSC had accepted the connection, dispatch a USSD and directly send some RR release message (without proper tear down messaging like the lchan_fsm does these days). This made sense in the osmo-nitb world, but by now we are aiming for solid 3GPP compliance. The BSC shall not originate USSD messages. Deprecate all VTY and CTRL commands related to USSD: VTY [no] bsc-welcome-text [no] bsc-msc-lost-text [no] bsc-grace-text [no] missing-msc-text (the commands with 'no' are ignored, without 'no' lead to an error) CTRL ussd-notify-v1 Drop (already unused) ussd.h. Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code. Drop "RF grace" notification, where osmo-bsc was able to notify active subscribers that the RF was being turned off. Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
2020-05-29drop CC 'local-prefix' featureNeels Hofmeyr2-13/+0
It is not entirely clear to me what this used to do once, but I've stumbled upon this before. By now I am certain that this is a non-standard legacy feature. The BSC does *not* redirect connections during CC transactions. Along with this, a bunch of legacy utility functions can be dropped. All of this is unused code. (Preparing for MSC pooling.) Change-Id: Id54afe8ccf0e11b9121a733224054c9565eafb58
2020-05-28stats: Count paging requests flushed due to MSC Reset.Alexander Chemeris1-0/+2
Change-Id: Ie93fc54fecdfcf615483f7f41a36dbcea61a537b
2020-05-27drop IMSI filter and libfilter completelyNeels Hofmeyr6-115/+2
Filtering by IMSI in osmo-bsc is a legacy use case with questionable usefulness. Remove. Do not keep deprecated VTY commands: those could be dangerous, since (presumably non-existing) users might assume that the filtering would still be in place. Rather fail to start osmo-bsc for config with an IMSI ACL. The IMSI filtering did, if present, provide the logging with an IMSI to print for the bsc_subscriber. TMSIs should have ended up in logging likewise, which has never been implemented. The proper way to learn the IMSI would be by the Common Id message from the MSC. Furthermore, the upcoming MSC pooling feature will extract the mobile identity again, and will hence make sure that both IMSI and TMSI identities, as available, end up in the bsc_subscriber and will be logged again. So long, IMSI ACL, and thanks for all the fish. Change-Id: I89727af5387e8360362e995fdee959883c37d89a
2020-05-19deprecate 'msc' / 'ip.access rtp-base <port>'Neels Hofmeyr1-1/+0
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty command, remove the member. [1] "mgcp: use osmo-mgw to switch RTP streams" commit 39c609b7c924524172ad311bdf89f92b7ccf175a Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
2020-05-19bssap: Handle BSSMAP CONFUSION message.Alexander Chemeris1-0/+1
We decode the mesage and print it to the log files at ERROR log level. We also count it in the BSSMAP message counters. There is not much else we could do about it. Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore) Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
2020-05-19stats: Add a BTS/BSC counter PAGING_NO_ACTIVE_PAGING.Alexander Chemeris1-0/+4
This is a corner case but still we should count the events to know when is this happening. And for the number of paging requests to match the number of paging responses. Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
2020-05-19stats: Add counters and gauges for BORKEN lchans/TSAlexander Chemeris1-1/+47
Now we can monitor the situation with the BORKEN lchans and TS in our BTS's over time. Change-Id: I427bbe1613a0e92bff432a7d76592fe50f620ebe
2020-05-11stats: Rename BSSMAP Rx message counters to match Tx ones.Alexander Chemeris1-2/+2
Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
2020-05-11stats: Add counters for Tx BSSMAP messages.Alexander Chemeris1-0/+30
We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-09stats: Export connected OML/RSL links count per BTS.Alexander Chemeris1-0/+2
Change-Id: I88c8025940a0eecb034b1c70f76ea17937fa0325
2020-05-09stats: Add counters for received BSSMAP messages.Alexander Chemeris1-0/+17
Change-Id: I3f08d71b58b4e8d6f61376d85c2051e194aa8e43
2020-05-09stats: report a number of configured BTS to a stats gauge.Alexander Chemeris1-0/+7
It's useful to know how many BTS are actually configured to compare it to a number of connected BTS's. Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
2020-05-09stats: Add a stats gauge for the MSC links count.Alexander Chemeris1-0/+10
Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-09gsm_data: Update trx_is_usable for ericsson BTSSylvain Munaut1-0/+12
There is no bb_transc oject. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I34bb808cd21575ff25d36e6df028b140935a008f
2020-05-08stats: Report per channel type load to statsd counters.Alexander Chemeris1-0/+16
Change-Id: I2eac4c93061204aeb8f3d223f7e78158c61c7156
2020-05-08om2k: Add support for MCTR configurationSylvain Munaut1-0/+4
Currently only supports a single MCTR with fixed configuration Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
2020-05-08om2k: Add option to limit OML version during negotiationSylvain Munaut1-0/+4
Starting from G12R13 the MCTR swiches to BSC controlled mode. And although we think we know how to configure it (via MCTR Conf Req), something doesn't work right and the timeslot configuration is not accepted. (TS Conf Result shows "Data not according to request"). So as a workaround for now, we use this version of the protocol where we don't configure the MCTR (it's in "BTS controlled mode") and with this protocol, the BTS accepts our timeslot config and we can bring the system up. This commit add a generic option to limit either OML or RSL IWD version to any value. It also keeps track of the actual negotation version so we can react to it in other places of the code. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65 better version limit Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
2020-05-08bts_nokia_site: Fix LAPD segfault during reset procedureHarald Welte1-1/+1
The existing Nokia *Site code destroyed the LAPD SAP instance for OML while processing an OML message. Once the stack frame returned back to the LAPD code, the LAPD SAP was gone -> segfault. Let's work around this by moving deletion of the LAPD SAP out-of-line by starting a timer 0ms in the future. Not particularly nice, but effective. Change-Id: I6270c7210f600e53f845561898245d2fd30a368d Closes: OS#1761
2020-05-04gsm_data.h: Comment the 'nokia' BTS fieldsHarald Welte1-6/+6
Change-Id: I5e3eaf3dee97e2edcd80b20c3acf85bd89b40cdc
2020-04-28om2k: Add VTY command to allow TX of arbitrary message for testingSylvain Munaut1-0/+1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I5a385614fc670946f83ea79cc176c2d448675672
2020-04-28om2k: Allow the CON configuration request to be triggered via VTYSylvain Munaut1-0/+1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Id1171a151773182bb5cdc14c023c3637fb9ad0bc
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 15:47:12 +0000