summaryrefslogtreecommitdiffstats
path: root/msc/MSC_Tests.ttcn
AgeCommit message (Collapse)AuthorFilesLines
2019-07-10L3_Templates: add enum CmIdentityTypeOliver Smith1-1/+1
Change-Id: Ibe50669663e641cdfd6a88f22c5404e2d90323b7
2019-07-08MSC_Tests.ttcn: cosmetic: move TC_gsup_mt_multi_part_sms() backVadim Yanitskiy1-1/+1
The mentioned test case doesn't cause any problems anymore. Change-Id: Ic8d456f4becade9010d4eb27159e6c2806b11810
2019-06-24lib/mgcp: Add new port with support to handle multiple MGCP socketsPau Espin Pedrol1-1/+2
* Some scenarios like MGW BSC-attached in SCCPlite require handling of 2 MGCP-over-UDP sockets in MGCP Emulation: 1 for regular libosmomgcp-client from osmo-bsc and another one from the forward socket from osmo-bsc (of MGCP-over-IPA messages communicated with MSC). * Old port is kept for backward compatibility with other tests and enabled by default. It's also interesting to keep it because it makes tests without special needs (2 sockets) to use the old port/API which produces simpler code to read and mantain. * Users of the new port have to enable multi_conn_mode parameter and expect to interact with port MGCP_CLIENT_MULTI instead of MGCP_CLIENT, which will offer messages containing information about the UDP connection being used by that message. Change-Id: Ic0ba8c5cde068c07671512a83095d83e28b86746
2019-06-17MSC_Tests.ttcn: introduce TC_mo_ussd_for_unknown_transVadim Yanitskiy1-0/+60
The new test case is aimed to verify that OsmoMSC properly does reject (call independent) SS/USSD messages for non-existing transactions. Change-Id: I231142c88b0d3308039c797aa2bccadd79dce18b Related: OS#2931
2019-06-16MSC_Tests.ttcn: introduce TC_proc_ss_abortVadim Yanitskiy1-0/+86
This test case is aimed to verify HLR-/EUSE-initiated abort of an active SS/USSD session according to the following scenario: 1. (HLR/EUSE -> MSC) GSUP_PROC_SS_REQ with random facility; 2. Network-originated connection establishment: 2.a. (MSC -> BSC -> MS) Paging Request; 2.b. ... 2.c. (MS -> BSC -> MSC) Paging Response; 3. (MSC -> MS) GSM 04.80 REGISTER with random facility; 4. (HLR/EUSE -> MSC) GSUP_PROC_SS_ERR (abort); 5. (MSC -> MS) GSM 04.80 RELEASE COMPLETE; 6. Connection release. As can be seen, HLR/EUSE initiates the session abort right after the GSM 04.80 REGISTER message is delivered to the MS, and just before the MS sends anything back in response. Change-Id: I5586a88136c936441a842f49248824680603672e Related: OS#2931
2019-06-16MSC_Tests.ttcn: introduce TC_proc_ss_paging_failVadim Yanitskiy1-4/+64
The idea of this test case is to check that OsmoMSC does inform HLR/EUSE that a subscriber did not respond to Paging Request in case of network-originated SS/USSD. Both f_expect_gsup_msg() and f_expect_dtap_msg() were extended with optional timeout value, as we need to wait longer than 2.0 seconds (default). Let's stick to 10.0 seconds. Change-Id: I1f53c56d569c8ac4071835685bbe3bc9e0ebd7f0 Related: OS#2931
2019-06-15MSC_Tests.ttcn: introduce TC_proc_ss_for_unknown_sessionVadim Yanitskiy1-0/+43
The idea of this test case is to check that OsmoMSC properly rejects GSUP PROC_SS messages for unknown sessions. As it turned out, OsmoMSC doesn't send GSUP PROC_SS ERROR as expected. The fix has been submitted. Change-Id: Ie267ee174c5061cd3fc102a2824abe03d73f3aac Related: OS#2931
2019-06-15MSC_Tests.ttcn: use f_expect_gsup_msg() in f_tc_mt_ussd_for_unknown_subscr()Vadim Yanitskiy1-12/+1
Change-Id: Id067cee3b7d06613d8387e0fa9d8a5c1dbcc49cf
2019-06-14MSC_Tests.ttcn: add timers to SS/USSD test casesVadim Yanitskiy1-0/+16
Change-Id: I1883bae34a9fe0435a6138cb7594461dee3bb232
2019-06-14MSC_Tests.ttcn: introduce TC_mt_ussd_for_unknown_subscrVadim Yanitskiy1-0/+51
The idea of this test case is to check that OsmoMSC properly rejects SS/USSD requests for unknown subscribers. Running this test case against the current OsmoMSC helped to discover several problems: - OsmoMSC doesn't print anything in such cases; - IMSI in the response error message is empty; - both session state and ID IEs are omited; which are going to be fixed soon. Change-Id: Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-05-31msc: Add module param to disable osmux (fix msc-latest jenkins job)Pau Espin Pedrol1-6/+14
ttcn3-bsc-test-latest currently fails on most tests because it tries to use "osmux off" VTY param and only current osmo-msc master supports it. Change-Id: I53d58b2d905905ebf1df322d0389b3715a48212f
2019-05-31msc: Enable/disable osmux always based on testPau Espin Pedrol1-1/+5
Initially it was thought safe to only enable it since the osmux test was at the end, but actually IU tests run after it, and those don't expect osmux to be enabled. This way we also always match osmo-msc osmux state with whatever the test expects (and sets through f_init()). Change-Id: I8fb48af7d37f1a2391a39c19f5ec5064cd5869d2
2019-05-27cosmetic: Update copyright statement, license notice and SPDXHarald Welte1-0/+12
Some of our files didn't have a copyright notice at all, let's add it. Also, update the notices in other files and ensure a SPDX identifier is present in all but the most trivial files. Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
2019-05-27msc: Introduce Osmux infra and one test for osmo-mscPau Espin Pedrol1-6/+21
Change-Id: Ibcb82d1a2d570c6c0ad0c3b6504bffe2244eccd9
2019-05-23MSC_Tests: Remove duplicated structures from BSSMAP_TemplatesPau Espin Pedrol1-138/+0
Change-Id: Ia82b65fe7e53cc0ab73df94b844b9b85aba9468b
2019-05-11add three tests for CIPHER MODE COMPLETE without algoStefan Sperling1-0/+91
Add three tests which exercise MSC behaviour when a CIPHER MODE COMPLETE command lacks the optional chosenEncryptionAlgorithm IE. Check for behaviour with A5/1, A5/3, and A5/1 + A5/3 configured in the network, and expect the location update to succeed. These tests pass on master, but they should somehow verify the cipher the MSC ends up using. I am not quite sure how to do that. Would inspecting the MSC's VTY be a reasonable approach? How could his be done by code which runs on BSC_ConnectionHandler? Change-Id: I1a2a126795c544613a7a87e238e1fc8c4e943885 Related: OS#2872
2019-05-11msc: Add a test for LU with invalid MCC/MNC in BSSAP/RANAPHarald Welte1-0/+35
Verify that the MSC rejects a location update from a Cell/BSC that contains a PLMN which does not match the core network's PLMN. Related: OS#3162 Change-Id: I676894358259b9cc0f973769ce552ba58a2a58a1
2019-05-09msc: Permit optional authentication before reject/timeoutHarald Welte1-0/+3
Tests like TC_lu_imsi_reject, TC_lu_imsi_timeout_gsup and TC_cmserv_imsi_unknown all expected a reject straight in response to the LU REQ / CM SERV REQ. However, the MSC may very well decide to perform authentication beforehand. It's an implementation detail when a MSC/VLR performs authentication, so the tests should be tolerant to this. This primarily shows up in 3G/Iu/RANAP related tests, as authentication is mandatory there. Change-Id: Icdd3f34eca08092703ab2ba9a8e755e2d609a59b
2019-05-09msc: Don't require protocolExtensions in RANAP PagingHarald Welte1-3/+3
We were using '?' for the protocolExtensions in RANAP messages, which required that such extensions existed. In reality, we want to use '*' which accepts paging messages whether or not there are any protocolExtensions present. As this is the default in all our RANAP receive template, callers don't even need to specify it. This should fix all Iu paging related test failures in MSC_Tests*.ttcn Change-Id: If22e16ecb301c86b9073ffde0af9e03bc85fbcc7
2019-05-09msc: add inter-BSC and inter-MSC Handover testsNeels Hofmeyr1-29/+467
Change-Id: I7d76c982ad4e198534fa488609c41e8892b268ab
2019-05-07msc: mo and mt voice call tests: add lots of missing partsNeels Hofmeyr1-2/+10
Both f_mo_call_establish() and f_mt_call_establish() were testing barely half a voice call setup. For example, f_mo_call_establish() used to be satisfied with just two CRCX, but no actual RTP connections being made. Add numerous MNCC and MGCP messages more closely resembling an actual call. The main reason is to achieve a state that passes both current osmo-msc master as well as the upcoming inter-MSC Handover refactoring. Add log markers to f_*_call_*(): often when a test halts, it is not at all clear why. With these log markers it is saner to figure out what has happened and what hasn't. Change-Id: I162985045bb5e129977a3a797b656e30220990df
2019-04-30msc: Add Iu related tests for most existing 2G testsHarald Welte1-57/+148
This might look a bit like copy+paste programming for our testcases. However, we actually want the Iu related tests show up as separate 'testscase' in the TTCN-3 sense, so there's no way that's more elegant than this :/ Change-Id: I3b56e17487c9df839e67ed390a1ff89979683e8e
2019-04-30msc: Introduce f_cl3_or_initial_ue as replacement for f_bssap_compl_l3()Harald Welte1-22/+22
The new function will check the RAN type and dispath to f_bssap_compl_l3() in case of 2G/GERAN and to f_ranap_initial_ue() on case of 3G/UTRAN. Change-Id: Ia27afa265d441d1a0cbb40cc2d938aff46fa25f9
2019-04-30msc: Add RANAP to msc testsHarald Welte1-5/+8
Integrate RANAP to MSC_Tests.ttcn Related: OS#2856 Change-Id: Idfa54b7607ad6e7016ed9411b0cc5330c901ea34
2019-04-25RAN_Adapter: Rename functions from f_bssap_* to f_ran_adapter_*Harald Welte1-4/+4
Change-Id: I73818247f1dfc71c8ece11660e6c18f5f153d186
2019-04-25msc: Add testcase for UMTS AKA over GERAN TC_lu_imsi_auth3g_tmsi()Harald Welte1-0/+15
Change-Id: I10cc7ed214e83b4624587c60f332034d3f19b22d
2019-04-25msc: f_mm_auth(): Add support for UMTS AKAHarald Welte1-1/+2
Change-Id: Id57adcebd63a06cfa555824e493561fe08f13d6d
2019-04-21MSC_Tests: Allow test cases to specify RAN indexHarald Welte1-8/+10
This allows to start ConnHdlr on specific RAN connections, i.e. on different emulated BSCs (and soon RNCs). Change-Id: I3d7ec567a7b69d8c6f79d26971bf1c94e077d5f5
2019-04-21Add f_expect_paging() rather than using tr_BSSMAP_Paging directlyHarald Welte1-6/+8
this will ease the introduction of RANAP support Change-Id: I213303337373c349676be4f8ac4175acdc701e47
2019-04-21Rename BSSMAP_Emulation -> RAN_EmulationHarald Welte1-30/+30
So far, BSSMAP_Emulation supported only a transport over BSSMAP. However, we soon intend to merge support for RANAP in order to simulate RANAP/Iu connections as well as BSSMAP. Let's start by renaming some of the existing types/functions/ports/modules without introducing any functional changes just yet. Related: OS#2857, OS#2856 Change-Id: Iecbcb0c6c136baad9460eca40606bb4010d8882d
2019-04-12msc: expect only one Paging on failed MT SMSNeels Hofmeyr1-31/+4
An MSC might decide to repeatedly retry Paging if it failed the first time, but osmo-msc currently has no such mechanism. Instead, it so far had a bug that retriggered a failed Paging from a start in a situation where there are SMS pending for only one subscriber, and sending the SMS fails. osmo-msc patch I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49 changes this behavior to accept a Paging failure and not launch the same SMS again numerous times. Adjust the tests to this new behavior. Depends: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49 (osmo-msc) Change-Id: I7dce12942a65eaaf97f78ca69401c7f93faacb9e
2019-04-12msc: clear the failed SMS when a test is doneNeels Hofmeyr1-6/+13
If an MT SMS is triggered and not handled in the test, it is so far left behind when the test ends. That causes Paging to retrigger for that SMS at any later point during subsequent test runs, causing stray bogus test failures. Actually remove the SMS from the SMS database and the queue with a new VTY command: The vty command to clear failed SMS from the db is added in osmo-msc I637cbd7adc075a192f49752b38779391472ff06d Depends: I637cbd7adc075a192f49752b38779391472ff06d (osmo-msc) Change-Id: I4ff05187131e93f5bc58dc7ea44546f770e5b4c1
2019-04-09MSC_Tests: Add testcase to simulate VLR/HLR failure (SGsAP)Philipp Maier1-0/+38
Currently we do not simulate a situation where the HLR is unreachable to the MSC. Lets add a test wehere the HLR is disconnected and an LU via SGsAP is tried. The SGs interface should then carry out a reset procedure. Change-Id: I830d0b936cbe9d73d1e0b1f4792c2be3d0b08cb9 Related: OS#3859
2019-04-09MSC_Tests: allow disabeling GSUPPhilipp Maier1-7/+19
The GSUP link between testsuit and osmo-msc is currently on by default and can not be disabled. However, there may be situations where a missing GSUP connection must be simulated. Lets add add a parameter to disable GSUP if necessary. Change-Id: I7c86aa0a906a0d7e8be765f9109a65b4b4387bc6 Related: OS#3859
2019-04-02MSC_Tests: fix TC_sgsap_expl_imsi_det_nonepsPhilipp Maier1-2/+4
When a subscriber is detached from non eps services, it gets fully detached from 2G, which means that the VLR is supposed to remove the subscriber. Lets check if the subscriber is in deed no longer known by the VLR. Change-Id: I2ec3f548dfcf5a9b99f10214a8bfd0c6978e253b Related: OS#3614
2019-04-02MSC_Tests: add testcase TC_sgsap_impl_imsi_det_epsPhilipp Maier1-0/+25
We have a testcase that sends an explicit (UE-Initiated) imsi detach from EPS services. Lets also cover the case for an implicit (Network-initated) detach. Change-Id: I63ebc32ae457dd74214d4abee4f511cde28de4a7 Related: OS#3614
2019-04-02MSC_Tests: add testcase TC_sgsap_impl_imsi_det_nonepsPhilipp Maier1-0/+28
We have a testcase that sends an explicit (UE-Initiated) imsi detach from non EPS services. Lets also cover the case for an implicit (Network-initated) detach. Change-Id: I76049e6717680c54c18f97b7cd51944901a81ae7 Related: OS#3614
2019-04-02MSC_Tests: add function to check if a subscriber is in VLRPhilipp Maier1-0/+17
The control interface of osmo-msc is able to return a list with all active subscribers from the VLR. Lets add a function, so that we can check from TTCN3 if a specified subscriber is known by the VLR or not. Change-Id: I7661ae55afe34795c3701d59795331b32d64c988 Related: OS#3614
2019-03-19msc: f_tc_sgsap_mt_sms_and_nothing: also do f_sgsap_bssmap_screeningNeels Hofmeyr1-0/+2
The only reason to omit f_sgsap_bssmap_screening() in this was the still pending SMS in the database. Since SMS are now removed, f_sgsap_bssmap_screening() will succeed. Change-Id: Ibea1e1fb33e0dde7e8bf51ff226d5e57c5a5d763
2019-03-19msc: TC_lu_disconnect: add final delay to fix spurious failureNeels Hofmeyr1-0/+1
I hit a "Broken pipe" error, hoping that the bit of delay makes the teardown more stable. Change-Id: I765a75f91a748239f6cc82f4a61f02d59166f00b
2019-03-14msc: TC_gsup_cancel: end with f_expect_clear() to avoid broken pipeNeels Hofmeyr1-0/+2
Change-Id: I3b3ae0b9c3f02f523dfb60c9efb732db3ade2785
2019-03-07msc: f_tc_sgsap_reset: add final delay to fix spurious failureNeels Hofmeyr1-0/+1
Change-Id: I20fd583311ee69f2cdee6448e809214ab261f6bd
2019-03-07msc: move sms sending to BSC_ConnHdlr and send from within test flowNeels Hofmeyr1-6/+4
For the sole reason that f_vty_sms_send() was put on MTC_CT for no apparent reason, we start the test function and send an SMS with an arbitrary two seconds delay. Instead move it to BSC_ConnHdlr and place SMS sending in the actual test function flow where it belongs. Change-Id: I5f348b3d30342b7c4871a1fc8f94648923e82eea
2019-03-07msc: add as_optional_cc_rel to ignore CC REL during call abort testsNeels Hofmeyr1-9/+23
When aborting a call with a Clear Request, it is actually a good idea to release an ongoing call with a CC Release message from the MSC. Allow this. Change-Id: I8378f7602fecac8262b31b47ad9327a3782c1bcd
2019-02-22MSC: Verify CSFB INDICATOR is present in CLEAR COMMANDHarald Welte1-1/+1
When a CSFB voice call is cleared by the MSC, it must include the CSFB INDICATOR in order to trigger the BSC to perform actions required for Fast Return to LTE. This patch changes TC_sgsap_lu_and_mt_call() and TC_bssap_lu_sgsap_lu_and_mt_call() to ensure the CSFB INDICATOR IE is present as expected. Change-Id: I6ce3a34f85aca7143cf7925cb9319bc679e8d395
2019-02-14MSC_Tests: Make sure only sgsap related tests use the SGs interfacePhilipp Maier1-45/+81
At the moment the SGs interface is started and connected in all tests in the testsuite. This may be a problem because the IUT may lack the SGs support. In this case all tests would fail because of the missing SGs interface. Lets initalize and connect the SGs interface only for SGs related tests to prevent unrelated test failures. Change-Id: I8e012e3599ad00db2e132b6463499f8a4a2307f1 Related: OS#3614
2019-02-11MSC_Tests: run TC_gsup_mt_multi_part_sms latePhilipp Maier1-1/+1
The testcase TC_gsup_mt_multi_part_sms is known to fail osmo-msc in a way that meaninful sms delivery is not possible anymore. This is due to a bug in osmo-msc, but in the testsuit it makes running certain normally working testcases impossible. Lets move at at the end of the testsuite so that it rus late and other tests won't get blocked. Change-Id: I581cd80895ea992a15389c6f73816769864e6d4c Related: OS#3614
2019-02-11MSC_Tests: make sure SGs tests don't interferePhilipp Maier1-18/+18
The IMSIs used with the SGs tests are partially re-used in other SGs testcases and also in unrelated testcases. Lets give each SGs test a unique IMSI to prevent unrelated interference with other tests. Change-Id: I417d9c5f0fbab7483d1b31dc20a99f63ee1bbfe6 Related: OS#3614
2019-02-01MSC_Tests.ttcn: introduce TC_gsup_mo_mt_sms_rp_mrVadim Yanitskiy1-0/+105
The idea of this test case is to verify SM-RP-MR assignment for a few concurrent MO/MT SMS being sent over GSUP. Basically, the algorythm is the following: 1.0 establish a RAN connection, 1.1 send CM Service Request for MO SMMA indication, 1.2 submit MO SMMA indication on DTAP, 1.3 expect MO-ForwardSM-Req on GSUP, 2.0 send MT SMS using MT-ForwardSM-Req on GSUP, 2.1 expect CP-DATA/RP-DATA for MT SMS on DTAP, 3.0 compare both SM-RP-MR values (for MT, assigned by the MSC), 3.1 send MO-ForwardSM-Res for MO SMMA on GSUP, 3.1.1 expect CP-DATA/RP-ACK for MO SMMA on DTAP, 3.2 send CP-DATA/RP-ACK for MT SMS on DTAP, 3.2.1 expect MT-ForwardSM-Res for MT SMS on GSUP. Change-Id: I17cbbaa64d9bce770f985588e93cd3eecd732120
2019-02-01MSC_Tests.ttcn: introduce TC_gsup_mt_sms_rp_mrVadim Yanitskiy1-0/+113
The idea of this test case is to verify SM-RP-MR assignment for a few MT SMS being sent over GSUP. Basically, the algorythm is the following: 1.0 send the 1st SMS using MT-ForwardSM-Req on GSUP, 1.1 expect Paging Request on RAN, 1.2 establish a RAN connection, 1.3 expect CP-DATA/RP-DATA for the 1st SMS, 2.0 send the 2nd SMS using MT-ForwardSM-Req on GSUP, 2.1 expect CP-DATA/RP-DATA for the 2nd SMS, 3.0 compare both SM-RP-MR values assigned by the MSC, 3.1 send CP-DATA/RP-ACK for both 1st and 2nd SMS messages, 3.2 expect MT-ForwardSM-Res for both 1st and 2nd SMS messages. The SM-RP-MR values for both 1st and 2nd messages shall not match. Change-Id: I3a52d44f4abde9b6b471b9108c1cee905884c9bc