AgeCommit message (Collapse)AuthorFilesLines
2019-02-13Fix compilation on eclipse-titan 6.5.1daniel/titan-6_5-fixDaniel Willmann1-1/+1
Newer eclipse-titan makefilegen already sets CPPFLAGS like this: CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include$(TTCN3_SUBDIR) where TTCN3_SUBDIR expands to '/titan' and TTCN3_DIR to '/usr' If we add /titan after include we end up with -I/usr/include/titan/titan/ which will cause the compile to fail due to a missing TTCN3.hh include. Change-Id: If9fef29ce243be112d3735f0236335197f8f140f Related: OS#3179 Sponsored-by: On-Waves ehf.
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-05bsc: Test CSFB "Fast Return" in new TC_chan_rel_hard_clear_csfbHarald Welte3-2/+56
When a MSC releases a connection using the BSSMAP CLEAR CMD, it can specify that this call was part of CSFB. The BSC is then supposed to add a special IE to the RR RELEASE message which will help the phone to switch back to LTE as soon as possible. This commit adds a new test case testing for exactly that behavior. The test does *not* verify if the EARFCN information contained is actually correct, only that the IE is present in the RR RELEASE. Change-Id: I7501fb25578412c882ff92da5d388f3079bbce7f Requires: osmo-bsc Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755 Related: OS#3777
2019-02-05bsc: replace octet string with decmatch when matching RR RELEASEHarald Welte3-4/+34
The 'decmatch' keyword allows us to match the decoded version of some octetstring, which is very useful in the situations where we have the L3 message only as octetstring but want to check if it matches some L3 template. Change-Id: I0a91e067f7e8062bf991fef8b0d4d8da740bfafc
2019-02-05BSC_Tests: Don't make invalid assumptions about RR RELEASEHarald Welte2-6/+4
The RR RELEASE message does not always have to be '060D00'O, which constrains it to: * not having any optional IEs * not having a cause value != 00 Let's relax the matching to accept any RR RELEASE message, whatever the cause may be, and whether or not there are any optional IEs at the end. At the same time, also remove some copy+pasting but rather have one template that gets used everywhere. Change-Id: I4b9d078c9b66f040fe673b5d957cf8e2c6d5892c
2019-02-01MSC_Tests.ttcn: introduce TC_gsup_mo_mt_sms_rp_mrVadim Yanitskiy2-0/+106
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 Yanitskiy2-0/+114
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-29BSC_Tests: fix vty interface for channel allocator testspmaier/challocPhilipp Maier1-12/+12
The tests presented in Change I109d986dd7ece1a56422a669ca64353ed46f7ed6, are using a slightly outdated vty syntax and fail because of that. Lets update the VTY syntax. Change-Id: I302e8872dbdc8e65d51902a881f777863de22915 Related: OS#3503
2019-01-29BSC_Tests: Add tests to check channel allocatorPhilipp Maier2-0/+304
When a channel is assigned via the assignment request throught the A interface, the MSC may offer either FR, HR or both. When FR and HR are permitted, a preference is set on one of the two. At the moment we do not check how the bsc is reacting to those preferences and its also not checked how the behavior is when the preferred rate is not available because all lchan of that type are already in use. Lets add a set of tests to verify this. Change-Id: I109d986dd7ece1a56422a669ca64353ed46f7ed6 Depends: osmo-bsc I397e68e26d6a1727890353fa34f4897b54795866 Related: OS#3503
2019-01-23update expected resultsNeels Hofmeyr5-50/+116
Change-Id: Idacaf8343bed4a37878eacdf338c4d5eb46bf7a7
2019-01-22MSC_Tests: individual IMSI for TC_lu_and_mt_sms_paging_and_nothingPhilipp Maier1-1/+1
The testcase TC_lu_and_mt_sms_paging_and_nothing is currently using an IMSI that ends on 43. The same IMSI is used by TC_mo_cc_bssmap_clear as well. Since TC_lu_and_mt_sms_paging_and_nothing is running before TC_mo_cc_bssmap_clear, the re-use of the IMSI triggers the MSC to continue the paging procedure. The MSC then eventually tries to deliver the SMS from TC_lu_and_mt_sms_paging_and_nothing. This will disturb the execution of TC_mo_cc_bssmap_clear, which then fails. Lets make sure that TC_lu_and_mt_sms_paging_and_nothing uses an individual IMSI that is never used again throught the execution of the testsuite. Change-Id: I66f8310981078dd032c47fcc97810944cf0c856f Related: OS#3762
2019-01-14MSC_Test: Test what happens when Paging for SMS is unansweredPhilipp Maier2-0/+68
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-12BTS_Tests.ttcn: fix: use TRXC interface of the BTS side, not BBVadim Yanitskiy1-20/+20
It was observed that 'BTS_Tests.TC_rach_max_ta' started to fail with the following reason: "BTS_Tests.ttcn:1091 : RACH passed but was expected to be dropped: -2560". My initial assumption was that the test case basically sends FAKE_TOA command on a wrong TRXC interface, and it was confirmed using # TRXD of the BB side $ ./ -p 6700 [DEBUG] L1 -> TRX burst: fn=616 tn=0 pwr=0 [DEBUG] TRX -> L1 burst: fn=597 tn=0 rssi=-60 toa256=-2560 [DEBUG] TRX -> L1 burst: fn=598 tn=0 rssi=-60 toa256=-2560 ... # TRXD of the BTS side (Uplink bursts only) $ ./ -p 5700 --direction L1 [DEBUG] TRX -> L1 burst: fn=719 tn=0 rssi=-60 toa256=0 and additionally be enriching logging messages of [DEBUG] (trx@ Recv FAKE_TOA cmd Sending FAKE_* commands on TRXC interface of the BB side affects the bursts being forwarded to this side, so we should use the TRXC interface of the BTS side to simulate Uplink delay. The reason why the test case has been passing some time ago is that there was a bug in, that has been fixed recently. This patch makes 'BTS_Tests.TC_rach_max_ta' green again ;) Change-Id: I7736abd85407c186856be9f1a22613a1fa6e0c32
2019-01-12MSC_Tests.ttcn: introduce TC_gsup_mt_multi_part_smsVadim Yanitskiy2-0/+73
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 Yanitskiy2-0/+151
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-07MSC_Tests: make sgsap interface optionalPhilipp Maier2-6/+18
At the moment the sgsap always enabled in the testsuite. This means the testsuite will try to connect the SGs interface of osmo-msc on initalization. If the connection fails, the testcase will fail also. Unfortunately the related patches that add the SGs interface to osmo-msc are not yet merged to master. This causes almost all testcases to fail, so lets have the SGs interface as an option that we can switch on when the SGs interface patches are merged to master. Change-Id: I429c0c5250d4b61de8a4d6399f284ce2c87cca93 Related: OS#3645
2019-01-07WIP: MSC_Tests: Add SGs testcasesHarald Welte7-14/+1116
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 Yanitskiy3-0/+79
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 Yanitskiy2-0/+73
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-23BTS_Tests: Verify RSL MS POWER CONTROL and SACCH MS POWER LEVELPhilipp Maier3-1/+84
Usually the MS power is controlled by the BTS and there is no continous supervison by the BSC needed. However, a scheme where the BSC takes care of the power control loop exists. The power is then set via RSL using an RSL MS POWER CONTROL message. This tests establishes a dchan and then sends MS POWER CONTROL messages with differen power levels and then checks the presence of the power level set in the MS POWER LEVEL field of the SACCH L1 header. Change-Id: I82b04a3bf94d355175f7f6ff3fdc43672e8080a2 Related: OS#1622
2018-12-23mgw: Tear down all RTP flows to avoid race condition on tear downDaniel Willmann1-0/+2
When stopping the test TC_two_crcx_and_unsolicited_rtp the unsolicited RTP stream is not stopped. As a result it could happen that between tearing down the other flows and stopping the test an unsolicited RTP packet is sent to a closed socket. The resulting ICMP destination unreachable packet translates to a "Connection refused" error on the sending socket and fails the test. Avoid this by making sure the unsolicited RTP sender is stopped before stopping the test. Change-Id: Ied839596589609e75fa487046a85db48991e4c73
2018-12-21MSC_ConnectionHandler: Optionally check MM InfoPhilipp Maier3-2/+38
The MM Info message is an optional message that is set to the MS usually after the location update. It contains the full network name and time information. At the moment the presence of this message is not checked or expected since sending of MM-Info is explicitly disabled in the osmo-msc configu. This patch adds an optional check of MM Info that is disabled by default. Change-Id: I431f50c2ff3536f87f0c7c3caf23b7a38d501904 Related: OS#3615
2018-12-21wait for subscriber conn in TC_cipher_complete_with_invalid_cipherStefan Sperling1-0/+1
Ensure that tests running after TC_cipher_complete_with_invalid_cipher won't see a left-over subscriber connection at the MSC. Change-Id: If26ee688f77cdb80557e9695b8e3920fa2ce6706 Related: OS#2872
2018-12-19library/GSUP_Types.ttcn: actualize both GSUP_SM_RP_{DA|OA}Vadim Yanitskiy1-20/+2
Both GSUP_SM_RP_{DA|OA} IE definitions have been merged before the reference implementation in libosmocore. Recently it was decided to use the following structure: IEI | IE length | ID type | ID encoded data (optional) instead of: IEI | IE length | ID type | ID length | ID encoded data (optional) so, let's remove ID length from both definitions. Change-Id: I001cec53a80028ff153db3d8b0318b298f2bd8c2
2018-12-18BSC_ConnectionHandler: make VTY interface availablePhilipp Maier1-0/+8
The BSC_ConnectionHandler currently has no access to the VTY interface. Lets make it available so that upcoming tests can use the VTY interface to trigger actions (e.g. Paging, see also Change Id: 6a1a6bd6da1bf46d6d703be495795d3610ca431) Change-Id: I684f0a3a435924d81bc5a793cb7b43a3ab9ef842 Related: OS#3615
2018-12-18BSC_ConnectionHandler: introduce ctrl interfacePhilipp Maier2-3/+18
There are some upcomming tests which require to access the control interface of the MSC while the actual test is running. Future test cases (e.g. Paging, see also Change Id: a6a1a6bd6da1bf46d6d703be495795d3610ca431) will use this. Change-Id: Ie3caf7a449311e7687670cadfa27818635d25aa4 Related: OS#3615 Related: OS#3187
2018-12-18Osmocom_CTRL_Adapter: Let the OS decide over the local port numberPhilipp Maier1-1/+1
At the moment the function f_ipa_ctrl_start() is starting the IPA emulation client with parameter -1 for local port. This is internally translated to port number 9999, which is a fixed number. This makes it impossible to have two control interfaces at the same time. Lets use 0 as local port, so that the OS is selecting a free port number automatically. Change-Id: Ie6648f8f4c1e065c174868c35eb64ee034ace3ce Related: OS#3645
2018-12-18add MSC test for an invalid CIPHER MODE COMPLETE commandStefan Sperling3-0/+61
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-12-18Remove -Wall for autogenerated codeMax1-0/+3
There seems to be no option for ttcn3_makefilegen to disable generated code warnings so the only way to clear output from useless warnings about indentation and such is to manually strip -Wall using sed. Change-Id: I7ef141f7f3370a1bf909845ce8a4eb650b33fa81
2018-12-13MSC: match default expectation with configMax1-0/+1
In MSC_Tests.default we expect /tmp/mncc.sock as MNCC socket path - let's match this expectation with osmo-msc.cfg to make sure that tests work out of the box without the need to use specific command-line option. Change-Id: I540645ef4b1e08d05b89251f074af84a516e7a88
2018-12-11MGCP: remove commented variantsMax1-3/+0
It's unclear why those variants were commented - looks like artifact from initial development. Let's drop them to avoid confusion. Change-Id: I3f11a93634fc50243a7210edcd501bd4b90d6dcd add link to related Debian bug in commentMax1-0/+2
This makes it easier to track when this workaround can be disabled once Debian/upstream (hopefully) resolve the issue. Change-Id: I3c4ed0ae5c1145f162b2745f4a46705b51874b5b
2018-12-10bsc: TC_chan_exhaustion: Send correct RA to alloc all different channelsPau Espin Pedrol1-2/+4
Previous RA value (23, Establishment cause = 0010XXXX) meant MS was dual rate capable but was asking speciifically for only TCH/F channel. As a result, TCH/H was not being allocated and an immediate assignment reject was sent. Change-Id: I3e58592c661fc004e648dbe46b67a3b3f5a20bc8
2018-12-08MSC_Tests.ttcn: correct VTY command in TC_lu_and_ss_session_timeoutVadim Yanitskiy1-2/+2
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a few corrections of the VTY command format. Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
2018-12-08BSC_Tests: expect a HANDOVER PERFORMED message on internal handoverPhilipp Maier1-0/+4
When an internal handover is performed, the BSC is expected to inform the MSC about the event by sending a BSSMAP HANDOVER PERFORMED message. This feature was missing in the BSC and has now been added. The tests need to be upgraded in order to handle the additional message. - Upgrade f_tc_ho_int so that it expects a HANDOVER PERFORMED message Change-Id: I10f4e578c96a90317939ba49b61b14a3c7e488a7 Depends: osmo-bsc If26e5807280e0f75a423b3b04f8e3c698c82a351 Related: OS#3645
2018-12-07bsc: Fix TC_paging_resp_unsolPau Espin Pedrol1-1/+1
TC_paging_resp_unsol spent some time in gerrit before being merged. As a result, other commits were merged in between the test was submitted (tested) and merged. As a result, commit a5302c8151d1da2e43ed52efc0544d70bffab911 was merged while this test was still in gerrit and thus was not updated accordingly. Similar stuff happened with the osmo-bsc commit fixing the scenario this test was showcasing: The osmo-bsc patch (77cd1129931928d2a6e7667d0374feeeed71b0ce) had merge conflict with other osmo-bsc commits merged in-between, and was merged even later than the commit introducing this TTCN3 test, so failures were expected for this test for a while. Change-Id: I933cba41912640eb7e15be4a27bda5b4dd489962
2018-12-03BSC_ConnectionHandler.ttcn: introduce f_mt_sms_send_rp_error()Vadim Yanitskiy1-0/+22
Change-Id: I3d67a451335e1c1e1b18237fdda82260c0c969fb
2018-12-03BSC_ConnectionHandler.ttcn: split up f_mt_sms() into two functionsVadim Yanitskiy1-6/+23
This would allow to expect a MT SMS message using f_mt_sms_expect() and send an RP-ACK using f_mt_sms_send_rp_ack() separately in the follow-up changes for SMS over GSUP. Change-Id: I4730634a9f3352b6f8553ee2fd1d43044f41241e
2018-12-03BSC_ConnectionHandler.ttcn: split up f_mo_sms() into two functionsVadim Yanitskiy1-6/+29
This would allow to submit an SMS message using f_mo_sms_submit() and wait for RP-ACK using f_mo_sms_wait_rp_ack() separately in the follow-up changes for SMS over GSUP. Change-Id: I5b35206286ae8add8b5bd34b0ab41ba7862c28e4
2018-12-03library/GSUP_Types.ttcn: add READY-FOR-SM messageVadim Yanitskiy1-3/+104
According to 3GPP TS 29.002, section 12.4, MAP-READY-FOR-SM is used between the MSC and VLR as well as between the VLR and the HLR to indicate that a subscriber has memory available for SMS. This change replicates this service in GSUP as READY_FOR_SM_*. The only mandatory IE for this service (excluding Invoke ID) is 'Alert Reason' that is replicated by OSMO_GSUP_SM_ALERT_RSN_IE. Change-Id: If2256607527ecfcb10285583332fb8b0515d7c78 Related: OS#3587
2018-12-02library/GSUP_Types.ttcn: add MO-/MT-FORWARD-SM messagesVadim Yanitskiy1-3/+433
According to 3GPP TS 29.002, there are two services: - MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2), - MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9), which are used to forward MO/MT short messages. This change replicates both services as GSUP messages: - OSMO_GSUP_MSGT_MO_FORWARD_SM_*, - OSMO_GSUP_MSGT_MT_FORWARD_SM_*. Please note, that only the 'must-have' IEs are introduced by this change, in particular the following: - OSMO_GSUP_SM_RP_MR_IE (see note below), - OSMO_GSUP_SM_RP_DA_IE (see, - OSMO_GSUP_SM_RP_OA_IE (see, - OSMO_GSUP_SM_RP_UI_IE (see, - OSMO_GSUP_SM_RP_MMS_IE (see, - OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11,, where both SM_RP_DA and SM_RP_OA IEs basically contain a single nested TLV of the following format: - T: identity type (see 'GSUP_SM_RP_ODA_IdType'), - L: identity length, - V: encoded identity itself. According to GSM TS 04.11, every single message on the SM-RL has an unique message reference (see 8.2.3), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. In case of TCAP/MAP, this message reference is being mapped to the Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not required for other applications (other than SMS), this change introduces a special 'SM_RP_MR' IE that doesn't exist in MAP. Change-Id: Ibf49474a81235096c032ea21f217170f523bd94e Related: OS#3587
2018-11-29MSC_Tests.ttcn: introduce TC_lu_and_ss_session_timeoutVadim Yanitskiy2-0/+74
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-11-29library/GSUP_Types.ttcn: fix IE order in PROC_SS_ERROR templatesVadim Yanitskiy1-4/+4
In general, the order of IEs in a GSUP message doesn't matter. Despite libosmocore's GSUP API encodes IEs in a fixed order, it is capable to decode them in any arbitary order. Meanwhile, in the current TTCN-3 definitions (i.e. templates) the order makes a difference, because the 'GSUP_IEs' type is a record, that according to the TTCN-3 documentation represents an *ordered* sequence of elements. Let's reorder the IEs of both t{r|s}_GSUP_PROC_SS_ERR templates in a way that is used by the libosmocore's GSUP encoder. This correction doesn't affect successful test case executions, because we don't test possible problematic situations yet. But if something went wrong on the HLR side (i.e. SUT), the matching statements wouldn't match the PROC_SS_ERR message correctly and continue to wait until the guard timer is expired. Change-Id: I5eb2314f6a9ab0e9fc5e836390414cec6e1a12db
2018-11-29library/GSUP_Types.ttcn: fix missing session state IE in PROC_SS_ERRVadim Yanitskiy2-4/+8
Both session state and session ID IEs are always being encoded together by libosmocore's GSUP implementation. So, if a message contains a session ID IE, session state IE shall also be there. For some reason, the session state IE was missing in both ts_GSUP_PROC_SS_ERR and tr_GSUP_PROC_SS_ERR templates. This could led to incorrect matching in our test cases. This change fixes both templates by adding the missing IE. Since tr_GSUP_PROC_SS_ERR templete is used in HLR_Tests.ttcn, all the affected matching statements were also corrected. This correction doesn't affect successful test case executions, because we don't test possible problematic situations yet. But if something went wrong on the HLR side (i.e. SUT), the matching statements wouldn't match the PROC_SS_ERR message correctly and continue to wait until the guard timer is expired. Change-Id: I44070396ce7119eab4608d9f9fb090bb223dfaa2
2018-11-28HLR_Tests.ttcn: introduce TC_mo_sss_rejectVadim Yanitskiy2-0/+51
As at the moment, OsmoHLR doesn't support "structured" SS, such requests are being rejected. This test case aims to verify that. Change-Id: I147b919d0242b3b44e39a4587bf1b4660fa58bd2 Related: OS#3651
2018-11-28library/SS_Templates.ttcn: add SS_USSD_FACILITY_INVOKE templatesVadim Yanitskiy1-0/+41
Change-Id: Ic561b6b2eee7315d42fcd5ec5fef182ae097d3b7
2018-11-27bsc: Start the timer at the beginning of f_initDaniel Willmann1-2/+3
This avoids a possible indefinite timeout if osmo-bsc crashes during the test. Ticket: OS#3713 Change-Id: I88f6254d9d2d90ab49a3c3d8255af25ca6ffe624
2018-11-27BSC_Tests.ttcn: introduce TC_chan_deact_silenceVadim Yanitskiy2-0/+35
The idea of this test case is to verify channel deactivation procedure due to no response to Immediate Assignment. Change-Id: I00b0838c9f919303aef72280248b0d1317f42b3b Related: OS#3709
2018-11-22bsc: Introduce test TC_paging_resp_unsolPau Espin Pedrol2-1/+27
With this test we want to verify that channels are released if BSC fails to complete an L3 request, for instance because no pending Paging CMD is found for a received Paging Response. Related: OS#3680 Change-Id: Iabe8a51aa13d2fcfec4500cf7aab47d60cc138ce