aboutsummaryrefslogtreecommitdiffstats
path: root/msc/expected-results.xml
AgeCommit message (Collapse)AuthorFilesLines
2021-07-05update expected-results.xml filesNeels Hofmeyr1-3/+17
Change-Id: Idcf764cd2d251210bb123d2a5ea782cda0d670b7
2021-05-19msc: add first a5/4 testsEric Wild1-0/+3
All msc tests involving classmarks suffer from the same problem: if a existing subscriber is reused the old classmarks will stick, since the msc only overwrites updated parts of the cm when receiving a new cm, so "downgrading" the existing classmark information is not possible. This is circumvented here here by using different imsi suffixes, the last param passed to f_start_handler. Additionally the handler will now properly respond to cm requests by the msc, i.e. in case the early cm is not sufficient for a5/4 because it lacks cm3, so the msc attempts once to query the cm, hoping to get a cm3. Related: SYS#5324 Change-Id: Idc055a006b325f58a5eafa88bc4415181b3500a2
2020-10-01update expected resultsNeels Hofmeyr1-1/+14
Change-Id: Icb534a2b00fc48c3ead009a620e6061e595cb581
2020-05-19update expected resultsNeels Hofmeyr1-49/+26
Change-Id: I37014274ee97f09985c31966e7cc9122fe11a856
2020-01-20MSC: add a test case to check T3212 expiration during pagingVadim Yanitskiy1-0/+2
Long story short: some time ago I noticed that OsmoMSC crashes if T3212 expires during the Paging procedure. This is not the case anymore (as the test case shows) and apparently the bug has been fixed, hovewer I believe it makes sense to add this test case. Change-Id: If9147ae8b07d5120d2853b9acda2313910ac48be
2020-01-15MSC/SMPP: introduce TC_smpp_mo_sms_rp_error for OS#4351Vadim Yanitskiy1-0/+1
This test case reproduces the problem described in OS#4351: 1. MS/UE submits a MO SMS which it getting touted to an ESME; 2. MSC prematurely responds with RP-ACK to the MS/UE; 3. ESME responds with DELIVER-SM error; 4. SMS transaction is already terminated (by RP-ACK). Expected behaviour: 1. MS/UE submits a MO SMS which it getting touted to an ESME; 2. ESME responds with DELIVER-SM error; 3. MSC terminates the SMS transaction with RP-ERROR. Change-Id: I33c6ea0ffdf8b8a45f587d690bdceb38fc42c898 Related: OS#4351
2020-01-12msc: Introduce test TC_(iu_)chan_rel_sccp_tiar_timeoutPau Espin Pedrol1-0/+1
Verify SCCP T(iar) timeout triggers release of established channel. Related: OS#4343 Change-Id: Id6488a262e656f5c8fabb4e81f4797b305eb09e2
2020-01-10MSC: add test cases for concurrent MO/MT SS/USSD transactionsVadim Yanitskiy1-0/+4
Both test cases make use of the existing functions: - TC_multi_lu_and_mo_ussd: f_tc_lu_and_mo_ussd_single_request(), - TC_multi_lu_and_mt_ussd: f_tc_lu_and_mt_ussd_notification(), starting several (*) BSC_ConnHdlr components in parallel. (*) The maximum amount is limited by 16 - this is as much as both GSUP and SCTP emulation components can handle. Change-Id: I2fb1c5d285163d5245d92fa24c197a5027ecbe6f Related: OS#2931
2020-01-07MSC/Iu: add missing SS/USSD test cases from MSC_Tests.ttcnVadim Yanitskiy1-0/+5
Change-Id: I99e888708ed1efeab12a4c88c734a78619a39888
2020-01-01msc: Introduce test TC_lu_imsi_timeout_tmsi_reallocPau Espin Pedrol1-0/+10
Related: OS#4336, OS#4337 Change-Id: I603b2b2b1ae7edd6360ea38c6bbbfedc46e9fa5d
2019-07-23msc: use f_expect_clear() in check IMEI testsOliver Smith1-7/+3
Fix the broken pipe race condition caused by closing the RAN connection too early. Properly wait for clear command and send clear complete. TC_lu_imsi_auth_tmsi_check_imei_{nack,err} do not pass anymore, because OsmoMSC is sending the LU reject twice. Patch [1] fixes it. [1] I127b27937613ea0ff29d67991c0414fca6d441d9 (osmo-msc) Fixes: 1d118ff753d963cfe5feb2450a31bc3a51aa5eb6 ("msc: add check IMEI tests") Change-Id: I836f76242463789c4c003feec757714827f2a31b
2019-07-23msc/expected-results.xml: update from jenkinsOliver Smith1-12/+102
Change-Id: I9110f7bcda2919ff04c63a99d554b53a793f0037
2019-07-12msc: add check IMEI testsOliver Smith1-1/+17
Extend BSC_ConnHdlr with new check IMEI related parameters. Add tests for check IMEI and check IMEI early for multiple auth variations, as well as variants where the HLR would respond with NOK or ERR. Note that we can safely set "check-imei-rqd 0" in f_init(), because the latest OsmoMSC version already suppors this VTY command. Two tests do not always pass, sometimes the RAN connection breaks before the test finishes (TC_lu_imsi_auth_tmsi_check_imei_err and TC_lu_imsi_auth_tmsi_check_imei_nack). I have added them as expected errors in the expected-results.xml. Related: OS#2542 Change-Id: Ic34bb8dc8547cafb5a53df03884554dd4f72956d
2019-06-17msc/expected-results.xml: update SS and SMS related expectationsVadim Yanitskiy1-9/+7
Change-Id: I7c67fa71e2157063c13605267ec34779c5603ed9
2019-04-09MSC_Tests: Add testcase to simulate VLR/HLR failure (SGsAP)Philipp Maier1-0/+1
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-02MSC_Tests: add testcase TC_sgsap_impl_imsi_det_epsPhilipp Maier1-0/+1
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/+1
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-02-22msc: update expected resultsHarald Welte1-69/+23
Change-Id: I1151e9333da14bb2714712b57914e03e4d5b785b
2019-02-01MSC_Tests.ttcn: introduce TC_gsup_mo_mt_sms_rp_mrVadim Yanitskiy1-0/+1
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/+1
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
2019-01-23update expected resultsNeels Hofmeyr1-35/+78
Change-Id: Idacaf8343bed4a37878eacdf338c4d5eb46bf7a7
2019-01-14MSC_Test: Test what happens when Paging for SMS is unansweredPhilipp Maier1-0/+1
Trigger sending of an SM, but ignore any paging requests from the MSC, make sure that the MSC is not paging indefinitely Change-Id: Id645729551672026c6a96bb849ecd04f20cd0c56 Related: OS#3704
2019-01-12MSC_Tests.ttcn: introduce TC_gsup_mt_multi_part_smsVadim Yanitskiy1-0/+1
The idea of this test case is to verify the process of multi-part MT SMS transmission. The MSC should keep the RAN connection until the last message part is transmitted. Change-Id: I6308586a70c4fb3254c519330a61a9667372149f Related: OS#3587
2019-01-12MSC_Tests.ttcn: introduce TC_gsup_mt_sms_{ack|err}Vadim Yanitskiy1-0/+2
The idea of this test case is to verify MT SMS transmission initiated by ESME over GSUP. Basically, the algorythm is the following: 1.0 send 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 on BSSAP/DTAP, 2.1 send CP-DATA/RP-ACK on BSSAP/DTAP, 2.2.a expect MT-ForwardSM-Res, 2.2.b expect MT-ForwardSM-Err. Change-Id: I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-07WIP: MSC_Tests: Add SGs testcasesHarald Welte1-0/+19
This extens MSC_Tests.ttcn with an initial set of SGs interface test cases for RESET, LU, DETACH, PAGING, SMS and CSFB procedures In particular the following testcases are added: - TC_sgsap_reset: isolated reset procedure test - TC_sgsap_lu: isolated location update with TMSI realloc - TC_sgsap_lu_imsi_reject: location update, reject case - TC_sgsap_lu_and_nothing: location update with failed TMSI realloc - TC_sgsap_expl_imsi_det_eps: detach from EPS serveces - TC_sgsap_expl_imsi_det_noneps: detach from non-EPS services - TC_sgsap_paging_rej: isolated paging, reject case - TC_sgsap_paging_subscr_rej: isolated paging, subscr rejects call - TC_sgsap_paging_ue_unr: isolated paging, ue is unreachable - TC_sgsap_paging_and_nothing: page, but don't respond - TC_sgsap_paging_and_lu: check paging followed by an LU - TC_sgsap_mt_sms: mobile terminated SMS through SGs Interface - TC_sgsap_mo_sms: mobile originated SMS through SGs Interface - TC_sgsap_mt_sms_and_nothing: trigger SMS, but don't respond to paging - TC_sgsap_mt_sms_and_reject: trigger SMS, but reject paging - TC_sgsap_unexp_ud: Send unexpected unitdata (SGs Association: NULL) - TC_sgsap_unsol_ud: Send unsolicited unitdata (subscriber not in VLR) - TC_bssap_lu_sgsap_lu_and_mt_call: LU on 2G, LU on SGs and CSFB call - TC_sgsap_lu_and_mt_call: LU on SGs, and CSFB call Change-Id: I38543c35a9e74cea276e58d1d7ef01ef07ffe858 Depends: osmo-msc I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3645
2019-01-04MSC_Tests.ttcn: introduce TC_gsup_mo_smma for MO SMMA over GSUPVadim Yanitskiy1-0/+1
The idea of this test case is to verify MO SMMA transmission over GSUP towards HLR. The algorythm is equivalent to MO SMS. Change-Id: I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related: OS#3587
2019-01-04MSC_Tests.ttcn: introduce TC_gsup_mo_sms for MO SMS over GSUPVadim Yanitskiy1-0/+1
The idea of this test case is to verify MO SMS transmission over GSUP towards HLR. Basically, the algorythm is the following: 1.0 establish a RAN connection, 2.1 send CP-DATA/RP-DATA on BSSAP/DTAP, 2.2 expect MO-ForwardSM-Req on GSUP, 3.1 send MO-ForwardSM-Res on GSUP, 3.2 expect CP-DATA/RP-ACK on BSSAP/DTAP. Change-Id: Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-12-18add MSC test for an invalid CIPHER MODE COMPLETE commandStefan Sperling1-0/+1
Add new test TC_cipher_complete_with_invalid_cipher which verifies that the MSC will reject a CIPHER MODE COMPLETE command with a cipher which wasn't part of the preceding CIPHER MODE command. Change-Id: I4492eb7d77371aaa047abae81a2dcf26fe46eb6a Related: OS#2872
2018-11-29MSC_Tests.ttcn: introduce TC_lu_and_ss_session_timeoutVadim Yanitskiy1-0/+1
The idea of this test case is to verify SS session termination due to expiry of its guard timeout. The timeout value is intentionally set to a few seconds in order to speedup test case execution (we don't want to wait 2 minutes). We expect OsmoMSC to inform both session entities (MS and EUSE) about timeout expiry before releasing the transaction. The MS should receive GSM 04.80 RELEASE COMPLETE message with optional cause, while the EUSE should receive OSMO_GSUP_MSGT_PROC_SS_ERROR. At the moment, it's not clean which cause values should be used: - for GSM 04.80 RELEASE COMPLETE the cause IE is optional, and possible values are defined in GSM TS 04.08, annex G-H. The H.6.7 Cause No. 102 "recovery on timer expiry" seems to be suitable; - for OSMO_GSUP_MSGT_PROC_SS_ERROR the generic cause IE could be used, but actually this IE is not generic at all, and limited by 'gsm48_gmm_cause' enum; so we temporarily expect arbitrary cause values in both messages. Change-Id: I3e1791773d56617172ae27a46889a1ae4d400e2f Depends-on: (OsmoMSC) Icf4d87c45e90324764073e8230e0fb9cb96dd9cb Related: OS#3655
2018-09-06update expected resultsNeels Hofmeyr1-15/+9
Change-Id: I32c29e62ca317937db771f8fb1540bb1fe9da2ab
2018-07-30msc/USSD: introduce TC_lu_and_mo_ussd_mo_releaseVadim Yanitskiy1-0/+1
The idea of this test case is to check the reaction of OsmoMSC on MS-initiated release during an active transaction. In other words, when the network is waiting for some response from a MS, subscriber can press the 'red button' in order to terminate this conversation. It is expected that the MSC would terminate the transaction as on DTAP interface, as on GSUP interface. Change-Id: I7936ed5072ed2ae02f039dc90a1fece1e7f70a70
2018-07-30msc/USSD: add test cases with network-initiaded SS/USSDVadim Yanitskiy1-0/+2
This change introduces two new test cases for network-initiaded USSD notification and network-initiaded USSD request, which are based on the existing SS/USSD related test cases. The idea of TC_lu_and_mt_ussd_notification is to verify that a network-initiaded USSD notification can arrive subscriber in IDLE mode using Paging procedure. The idea of TC_lu_and_mt_ussd_during_mt_call is to verify that a network-initiaded USSD notification can arrive subscriber in DEDICATED mode (in this case during a call) on a separate transaction. Change-Id: I073893c6e11be27e9e36f98f11c1491d0c173985
2018-06-21msc/USSD: use more informative names for test casesVadim Yanitskiy1-2/+2
Let's explicitly indicate is a SS/USSD message MO or MT. Change-Id: I87f16f935f015dbd2ac2867d8ea5e155cc365e3f
2018-06-21msc/USSD: drop the TC_lu_and_ussd_wrong_code test caseVadim Yanitskiy1-1/+0
As we are about to finish the implementation of GSM TS 09.11, in our case it is 'SS/USSD over GSUP', OsmoMSC will not decide itself which USSD request-code is known, and which is wrong. Change-Id: Ic104a49bb2dce2127063bcef8443ee6b639c9f19
2018-06-10msc/USSD: test USSD-request during an active callVadim Yanitskiy1-0/+1
The idea of this testcase is to check if MSC can correctly handle a USSD-request during an active call. What we do here: 1) Perform Location Update 2) Establish a MT-call 3) Perform *#100# request 4) Release the call Change-Id: Ifa3cd1aeeb34ccf5864f78b76a88aaa6d5e51839
2018-06-10msc/USSD: add unknown request code testcaseVadim Yanitskiy1-0/+1
The idea of this testcase is to check reaction of the network on reception of USSD request with unknown/unhandled request code. It is not clearly defined by the GSM specs, how the network should react in such cases, but looking at GSM TS 04.80, section 4.3.2 "Error types description", the UnexpectedDataValue error looks suitable. Commercial networks also use this error when an unknown request code is sent. Change-Id: I6a3fcaafc37972a38c13722f0b511ea5e1e3fbd8
2018-06-02msc/USSD: add single *#100# request testcaseVadim Yanitskiy1-0/+1
In this testcase we perform LUR, then request our own number and then expect the response with matching MSISDN. Change-Id: I82450c6f48f6c17bc33e0ec6c91f2a73e44793ad
2018-06-01expect TC_establish_and_nothing to passStefan Sperling1-6/+1
The test case TC_establish_and_nothing is now passing. Update expected results list accordingly. Change-Id: I925fa4ad2e38e189cf5dd1ae76a24cdb9011fdc8 Related: OS#2879
2018-05-02update expected resultsNeels Hofmeyr1-49/+11
bsc: TC_assignment_sign fails with different message msc fixed: TC_lu_clear_request TC_emerg_call_imei_reject TC_cm_serv_req_vgcs_reject TC_cm_serv_req_vbs_reject TC_cm_serv_req_lcs_reject TC_cm_reest_req_reject TC_cl3_rnd_payload TC_lu_and_mt_sms new: TC_smpp_mo_sms TC_smpp_mt_sms sgsn fixed: TC_attach_umts_aka_gsm_sres Change-Id: Ie9ef25fb2081ebab7a2b08c06307fa391f8f747a
2018-04-11bsc, msc: update expected resultsNeels Hofmeyr1-1/+8
Mark TC_paging_imsi_a_reset fixed. Add various new tests. Change-Id: Ib3a36efeb086fd995d7dad4e040f5a46b1b1ca0a
2018-04-11mask timestamps and source file nrs in expected-results.xml filesNeels Hofmeyr1-70/+70
Prepare for upcoming updates with concise diffs. Change-Id: Ic9f006aa8db1b477598605e0525faeb229b03641
2018-04-11fix build: don't clean out expected-results.log: rename to *.xmlNeels Hofmeyr1-0/+110
'make clean' as generated by ttcn3_makefilegen removes all *.log files, which of course cleans out expected-results.log, which should not happen. Since this is a junit XML file, rename the suffix to .xml. Change-Id: Ic334f6b758eef865e3a497aa430691a3ae696d25
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-30 04:14:40 +0000