aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
2023-02-01bsc_ctrl_commands: Add GET for bts neighbor-list (local bts numbers)arehbein2-0/+75
Related: SYS#6287 Change-Id: I79aeffd93089086f57c66787fe20b439a4d8b6b4
2023-01-23vty: Add support for Ny1 configurationarehbein3-12/+34
Related: OS#5475 Change-Id: I6318cceb4ebdce50005e39e2e9323c1c8433250a
2023-01-03bts: ipa/osmo-bts/sysmobts: MO: add support for the second NSVCAlexander Couzens1-1/+1
The second NSVC MO has been explicit skipped and never been interacted with. osmo-bts is already supporting it for a long time as well the PCU is supporting it at least since the NS2 code migration. Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc. Closes: OS#5835 Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
2022-11-30paging: Replace reqs waiting for retransmission with new incoming inital req ↵Pau Espin Pedrol1-2/+2
if queue is full If queue size (in transmit delay of requests) is too long (above threshold) when a new initial incoming request arrives, instead of directly discarding it, see if we can drop a pending retransmission and insert the new one instead, in order to avoid losing initial requests. This is done under the assumption that it is more important to transmit intial requests than to retransmit already transmitted ones. The rationale is that there's lower chances that an MS which didn't answer lately will answer now (aka being reachable at the cell), so it's better to allocate resources for new requests (new MS) which may be available in the cell. Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d Related: OS#5552
2022-11-30paging: Split paging queue into 2 queues: initial and retransPau Espin Pedrol2-132/+303
Initial requests: paging requests which haven't been yet transmitted Retrans requests: paging requests which have already been transmitted at least once. Until now one queue was used (llist) to store both. The initial requests were stored at the start of the queue in FIFO order. After the last initial requests, the retrans requests followed also in FIFO. This ordering was used in order to prioritze scheduling of initial paging requests over retransmit paging requests. In the end, having both types in the same list only make code handling the list more complex. Hence, this patch splits the shared llist into 2 llists. Related: SYS#6200 Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
2022-11-28paging: Introduce VTY configurable X3113 (Maximum Paging Request Transmit ↵Pau Espin Pedrol1-0/+2
Delay Threshold) This allows configuring the maximum delay of paging requests to be queued according to other parameters, such as MSC paging request timeouts, etc. Related: OS#5552 Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
2022-11-23Cosmetic: fix spaces around timersOliver Smith1-3/+3
Use spaces around equals signs inside structs, as expected from the kernel coding style we mostly follow. Neels wrote: > IIUC "T=123" without spaces is my personal favorite that goes against > the accepted linter standard, i guess rather than everyone else > adapting to my weird style, i should start adding spaces in my > patches. Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
2022-11-15Add BTS setup ramping to prevent BSC overloadingAlexander Couzens1-0/+1
Prevent BSC overloading in the event of too many BTS try to connect. E.g. a network outage between the BSC and BTS. The BSC will accept incoming OML connection, but will delay sending any BSC originated messages. Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
2022-10-27gsm48_parse_meas_rep: fix parsing multi-band listOliver Smith1-7/+3
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't treat the BCCH channel list as one list sorted by ascending ARFCN. Instead, treat it as two sub lists, one for the same band, and one for channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20. This fixes getting the wrong ARFCN from measurement reports in multi-band BSS, which leads to failing handovers. Fixes: OS#5717 Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286 Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
2022-10-27tests: add test_meas_rep_multi_band.ho_vtyOliver Smith3-0/+108
Add a test that shows that the ARFCN of neighbors from the measurement report is not parsed correctly for multi-band BSS. A follow-up patch fixes it. Related: OS#5717 Change-Id: Ie18e341f236bab5cf60d3a342c15c96cc848a7c2
2022-10-19Use new mgcp-client VTY commands under mgw nodePau Espin Pedrol1-3/+3
New VTY commands have been added recently to the "mgw" node which drop the redundant "mgw" prefix on each fo them. Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484 Related: SYS#5987 Change-Id: I71e49cb4d6c2fe54a895aab0b0ba5acc4e57c253
2022-10-19Update examples to use mgw pooling VTY commandsPau Espin Pedrol1-4/+4
Let's avoid guiding users towards the old deprecated VTY interface. Line "mgw endpoint-range" is removed since it's nowadays deprected and implemented as a NOOP. Related: SYS#5987 Change-Id: Iff74a9efca2a0a2c38d5ac39df704b2b211fd906
2022-09-19vty: Allow setting LAC as hexadecimal valuePau Espin Pedrol5-11/+11
The LAC value currently configured is now printed as hexadecimal value too. It can still be entered as a decimal value in order to keep backward compatibility, though the hexadecimal one is now preferred. Related: OS#5631 Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4 Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
2022-08-09split lchan specific defines and code to its own filePau Espin Pedrol1-0/+1
It is really difficult right now to find out where all the different stuff relative to operation and lifecycle of an lchan is. Let's move everything to its own file to have all the related defines and logic together. Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
2022-07-27tests/ctrl: Avoid creating logfilePau Espin Pedrol1-9/+0
It's of no use for the test. Furthemore, it was being created outside the build direcory, being left there. Change-Id: Iaeee14a01badb8439bc8893ba8be06b13e4318f3
2022-07-22call osmo_timer_del() unconditionally, without osmo_timer_pending()Vadim Yanitskiy2-6/+3
osmo_timer_del() does check if a timer is active internally. Change-Id: I3e42a74d59b8e8d0d46cc4027676149689cc18a3
2022-06-30lchan_select: implement dynamic selection mode for assignmentVadim Yanitskiy2-1/+27
This change implements an additional channel allocation mode, which can be employed during a TCH channel allocation for assignment. Selection between ascending and descending order is performed depending on pre-configured parameters: * Uplink RxLev threshold and number of samples for averaging, * C0 (BCCH carrier) channel load threshold. This is useful in setups where Tx power of the RF carriers cannot be adjusted +dynamically at run-time and thus BS Power Control cannot be performed. In such setups the BCCH carrier is transmitting at relatively higher power than the other RF carriers. The key idea is to allocate channels in a smarter way, so that UEs with poor signal would get channels on carriers with high Tx power, while UEs with good signal could use carriers with lower Tx power. Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5 Related: SYS#5460
2022-06-30lchan_select: allow different alloc order for assignment and handoverVadim Yanitskiy5-7/+17
A follow-up patch implements a special channel allocation mode, which is only working for assignment (basically TCH selection for a voice call). This mode cannot be employed for initial CHANNEL REQUEST or handover due to the absence of an already established lchan. Adding this mode to the existing VTY command syntax would be confusing: channel allocator (ascending|desscending|dynamic) ^^^^^^^ so this patch extends the VTY syntax in a way that it becomes possible to configure different channel allocator modes for different cases: OsmoBSC(config-net-bts)# channel allocator mode ? set-all Set a single mode for all variants chan-req Channel allocation for CHANNEL REQUEST (RACH) assignment Channel allocation for assignment handover Channel allocation for handover The old command syntax, which is basically 'set-all', is kept for backwards compatibility, but marked as deprecated. Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f Related: SYS#5460
2022-06-22tests/handover_cfg.vty: use more precise regex for forbidden linesVadim Yanitskiy1-29/+29
Current regex 'handover' is way too restrictive because it completely forbids the use of word 'handover'. Adding new VTY commands with this word in the syntax makes this VTY test fail. Use regex '^\s+handover', which only matches lines starting with some whitespace and the word 'handover'. Lines simply containing the word 'handover' will be ignored. Change-Id: I8a1550c6c97437832e05b6b4bebbcc33c2fa3d46 Related: SYS#5460
2022-06-15Expand VTY option which controls use of TCH for signallingMichael Iedema1-12/+30
For statistical clarity and site tuning, it is sometimes desirable to completely disable the use of TCH for signaling. In the existing version of this VTY command, there is no way to accomplish this. We can only restrict TCH for signaling non-voice related actions. This patch deprecates 'allow-tch-for-signalling (0|1)' and adds 'tch-signalling-policy (never|emergency|voice|always)' to provide more options. Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
2022-06-10Cosmetic: bsc_vty: tweak msc pooling stringsOliver Smith1-1/+1
Drop "to this MSC" from the NRI_STR, as it is not only used for MSC specific configuration, but also in cfg_net_nri_* which affect all MSCs. Drop "for this MSC" from the description of cfg_net_nri_null_del, it affects all MSCs (unlike cfg_msc_nri_del). Change-Id: Ic8888775a965b6d607af51b9359bd8ffc2834e16
2022-06-02fix performance for chan_counts and all_allocated statsNeels Hofmeyr1-0/+3
The all_allocated_update_bsc() does inefficient iterating to count active/inactive lchans, which scales badly for high numbers of TRX managed by osmo-bsc. We need to update the all_allocated flags immediately (periodic counting alone would suffer from undersampling), so, until now, we are calling this inefficient function every time a channel state changes. Instead of iterating all channels for any chan state changes anywhere, keep global state of the current channel counts, and on channel state change only update those ts, trx, bts counts that actually change. A desirable side effect: for connection stats and handover decision 2, we can now also use the globally updated channel counts and save a bunch of inefficient iterations. To get accurate channel counts at all times, spread around some chan_counts_ts_update() calls in pivotal places. It re-counts the given timeslot and cascades counter changes, iff required. Just in case I missed some channel accounting, still run an inefficient iterating count regularly that detects errors, logs them and fixes them. No real harm done if such error appears. None show in ttcn3 BSC_Tests. It is fine to do the inefficient iteration once per second; channel state changes can realistically happen hundreds of times per second. Related: SYS#5976 Change-Id: I580bfae329aac8d4552723164741536af6512011
2022-05-13paging: start/stop credit_timer based on C0 runningPau Espin Pedrol2-839/+878
This way we avoid triggering timers and doing extra poll loops for each BTS which is configured but not up. It also has the effect of removing logging about estimating paging buffers for BTS which are down, which can be confusing. Furthermore, since work is delayed until the TRX and cell in general is configured, the first estimation is properly done now since the correct configuration is in place at that time. Related: SYS#5922 Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
2022-05-09paging: Implement upper bound of 60s for dynamic T3113Harald Welte1-1500/+1500
Change-Id: Ib8228f8485527d34794048a9927e62b6ec8d802a Closes: OS#5553
2022-05-09paging: Avoid queueing more than 60 second estimated requestsHarald Welte1-0/+1500
Reaching this point will only make system load (CPU, mem) grow, making it hard for the process to keep up with work to do, with no benefit since the requests will anyway be scheduled too late. Related: SYS#5922 Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
2022-05-06paging: Improve loggingPau Espin Pedrol1-129/+132
Change-Id: I3186f841623cad8ed3296ac4d541e5cf4701132d
2022-05-03tests: Introduce paging_testPau Espin Pedrol5-0/+8322
Add unit test env to easily test several paging scenarios. Change-Id: Iab61bf6a6eece5f439a19f7a5a0dc068a808ae8a
2022-05-03bts: Properly free ctr/stat when bts object is freedPau Espin Pedrol2-4/+0
This was so far workarounded in tests by manually freeing the fields. However, in follow-up patch the paging queue will also be properly freed, so free of the counters needs to be previously fixed too so that counters are freed at the right point of time. Otherwise, during paging queue flush, counters are used and would crash because they were freed before the BTS object in each test's bts_del(). Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
2022-05-03tests/acc: Remove unused varPau Espin Pedrol1-2/+0
Change-Id: I1b56b4f8d3c3901cdf9a971e9ed95a6ebbbc1cca
2022-05-03tests: Order tests alphabeticallyPau Espin Pedrol2-20/+20
Change-Id: Ic7507c90854a1c953f4c016b1b0e569bca570b37
2022-05-02Check VTY config against features reported by BTSOliver Smith2-0/+28
* Don't copy features for osmo-bts and nanobts initially, wait until BTS reported its features * Checks for BTS features in VTY cmds: pass if features are not known (not yet reported by the BTS), fail if the feature is missing * Once BTS reports its features, check relevant VTY config parts again Related: SYS#5922, OS#5538 Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
2022-04-27tests: acc_test: Get rid on unrelated logs in expect filePau Espin Pedrol2-928/+1
Change-Id: Id509fa1d27b18b5f9ba48f818671c432ff2719ac
2022-04-27tests: acc_test: fix typo in talloc ctx namePau Espin Pedrol1-1/+1
Change-Id: I80cd70ab0597a6d7d7b5445ddab504a38ac86c7b
2022-04-25Rename functions generating OML SetAttr messagesPau Espin Pedrol2-32/+32
Its name is totally misleading, since they seem to be related to GetAttributes messages rather than SetAttributes. Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
2022-04-25Move struct gsm_bts_paging_state to paging.hPau Espin Pedrol6-2/+13
Change-Id: I8c058d308fc816828b5e6a86e7c5a1f629a2d7c4
2022-04-21tests/bsc/Makefile.am: remove duplicate CFLAGSPau Espin Pedrol1-1/+0
Change-Id: I7af974a9920558af03495b6ca297b158caebc007
2022-04-14tests: use 'check_PROGRAMS' instead of 'noinst_PROGRAMS'Vadim Yanitskiy8-8/+8
When using 'check_PROGRAMS', autoconf/automake generates smarter Makefiles, so that the test programs are not being compiled during the normal 'make all', but only during 'make check'. Change-Id: I030c88545cdc71b3ad9e83f9c2ba7b27177c2ac8
2022-03-31hodec2: add penalty-time low-rxqual-hoNeels Hofmeyr2-1/+24
When bad RxQual causes handover to a cell with weaker RxLev, then handover oscillation *will* happen, as shown in test_rxqual.ho_vty. Introduce a penalty timer for a cell where we had bad RxQual. This delays handover back to the cell with stronger RxLev by the penalty timeout; hopefully the interference is gone after the timeout. Usually, we set new configuration elements so that osmo-bsc behaves the same as before the config item was added. In this instance, this makes no sense, because no-one ever wants handover oscillation from bad RxQual, which is guaranteed to happen without the new penalty timer. Set it to 60 seconds by default, same as other penalty timers. Related: SYS#5911 Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
2022-03-31hodec2: show reported ho oscillation from bad rxqualNeels Hofmeyr1-0/+8
First show the problem. Related: SYS#5911 Change-Id: I51f3101901492ae742d8e56d6eed2725408216cb
2022-03-29struct gsm_encr: store alg_id in human-readable formatVadim Yanitskiy1-1/+1
I find it weird that we store the A5 algorithm ID in a format that is used on the wire: N + 1 (valid for both A-bis and A interfaces). What confused me even more is that in some functions we print it as if it was in a normal, human-readable format. And this is also why one can see weird constructions like: if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... } Let's ensure that our internal structures use the A5/N format: alg_id=0: A5/0 (0x01 on the A-bis/A interface) alg_id=1: A5/1 (0x02 on the A-bis/A interface) alg_id=2: A5/2 (0x03 on the A-bis/A interface) ... alg_id=7: A5/7 (0x08 on the A-bis/A interface) so that we can print and compare the value of alg_id without using additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n' as it most clearly indicates which representation it is storing. This is how the above code snippet would look like: if (lchan->encr.alg_a5_n > 0) { ... } Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
2022-03-09support "empty" SCCP N-Connect from MSCNeels Hofmeyr1-0/+2
Teach osmo-bsc to handle empty N-Connect. So far we were always expecting user data in an SCCP N-Connect from an MSC. However, it is perfectly valid for an initial BSSMAP request to follow later. This is relevant for: - Handover Request (incoming inter-BSC handover) - Perform Location Request (query physical location of the MS) Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter this state so that we don't have two separate code paths for handling initial user data. Related: SYS#5864 Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
2022-03-03bitvec2freq_list(): fix handling of E-GSM ARFCNsVadim Yanitskiy1-1/+1
According to 3GPP TS 44.018, section 10.5.2.1b.2, only ARFCN values in range 1..124 can be encoded using the 'bit map 0' format. Before this patch, ARFCN values belonging to E-GSM band (0, 975..1023) were ignored in bitvec2freq_list(), and thus not present in the resulting Cell Channel Description IE. Change-Id: I17739e6845cd84e2a81bc406dd532541f7c52cb6 Related: SYS#5854
2022-03-03tests/gsm0408: add testing coverage for generate_cell_chan_list()Vadim Yanitskiy2-0/+74
This commit demonstrates what happens when a cell has channels in both P-GSM and E-GSM bands (case 'c'). As can be seen from: Case a) only the BCCH carrier: 10 Case b) more carriers from P-GSM band: 1 3 10 64 99 124 Case c) more carriers from E-GSM band: 1 3 10 64 99 124 in both cases 'b' and 'c' we have the same set of ARFCNs. Carriers from the E-GSM band are not present at all. This is wrong and will be fixed in the follow up change(s). Change-Id: Ied0519c70501f105673a9b36657101063d275058 Related: SYS#5854
2022-03-02ipa oml: Fix encoding of T3105Pau Espin Pedrol2-3/+3
As the comment above the fix suggest, the encoding is in 10ms units. osmo-bts is also doing the proper: """ uint8_t t3105 = *TLVP_VAL(&tp, NM_ATT_BTS_AIR_TIMER); bts->t3105_ms = t3105 * 10; """ Related: SYS#5838 Change-Id: Ie190514ee35d1ca81b70e9180bf7393b973d3504
2022-03-02tests: nanobts_omlattr_test: Use msgb_eq_data_print() helperPau Espin Pedrol1-5/+5
Change-Id: I1c96305839e6627a36655c2e64da64f0a6704896
2022-02-08bssmap_reset: make T4 user configurablePhilipp Maier1-0/+2
The timer (T4) that controls the re-sending of the BSSMAP RESET can not be changed via the VTY, althrough it is defined via a tdef struct. Lets add a description along with default values to make it configurable via the VTY. Change-Id: I1fb5699220ab8a643a168567a89c6f381fe433a7 Related: SYS#5796
2022-01-12fix gscon clear 3/n: separate state for SCCP RLSDNeels Hofmeyr1-0/+4
Properly implement the separate conn release stages in separate FSM states: x) sent Clear Request, wait for a Clear Command from the MSC. Timeout after a configurable 60s. y) after a Clear Command and sending a Clear Complete, wait for the SCCP RLSD. Timeout after a configurable 60s. z) terminate after the RLSD is received / after timeout. handover_test.c needs a little tweak to make the MGCP release work with its fake MGCP client, because cleanup now ensures to invoke gscon_forget_mgw_endpoint() in all cases. Related: I680ec4ed866aa5f0b1ff29e7e98322615cfb288d (osmo-ttcn3-hacks) Related: OS#5337 Change-Id: Ie975117d37f38ba853589dc7f8d3e94f8f9586b2
2021-11-25Disable C/I based MS Power Control Loop by defaultPau Espin Pedrol1-7/+32
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually considered good) C/I values due to high noise (even with band filters in place). Hence, default thresholds (gathered from literature on the topic) are too high and end up in bad algorithm output decisions. Furthermore, most users of Osmocom don't use it in densely populated areas, hence RXLEV based algorithm used when C/I based one is disabled is good enough. Let's disable C/I based one by default, and let advanced users which specific needs to enable and confiure thresholds specifically for their needs (hardware, cell surrounding conditions, etc.). Related: SYS#4917 Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
2021-11-16move time_cc to libosmocore osmo_time_ccNeels Hofmeyr5-1140/+0
Related: SYS#4878 Depends: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd (libosmocore) Change-Id: Ica9f908a1a30f334a24c59471affa11225117e12
2021-11-15[overpower] By default, permit only for speech channels using AMRVadim Yanitskiy1-9/+9
Change-Id: I087025f9db59348f2f70d4a291f8d887644d6b17 Related: SYS#5319
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 23:10:27 +0000