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
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
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
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
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
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
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
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
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
Upcoming osmo-msc changes move away from the current ordering of MGCP and
Assignment messages. Allow these async dialogs to appear in any order.
Change-Id: Ia06af1e347601949f4ddb19f963daa400766d9e7
So far we omit a Speech Codec (Chosen) from Assignment Complete messages, which
is actually a mandatory parameter. osmo-msc seems to carry on nevertheless, but
it actually shouldn't be able to.
Always send a Speech Codec (Chosen).
Change-Id: Ib35f019383db8ace05a9dc349648e2da7ba58bfa
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before
the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a
few corrections of the VTY command format.
Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
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
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
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
MSC tests were unable to match odd-length digit strings in
a CallingPartyBCD_Number template created by tr_Calling().
This happens because the raw encoder for CallingPartyBCD_Number
pads odd-length digits with 1-bits ('F'H). Do the same when
constructing such a template in our own code to ensure that
we'll match the actual data received.
Change-Id: I34439c8750f588802a5403375e2a3d6e74dae70c
Related: OS#2930
This function can now be called from anywhere to try and safely shutdown
a testcase. It is not optimal as we can't call "all component.stop" from
outside the mtc, but without any proper and orderly shutdown handling of
all our emulation components I believe this is the best we can do.
To use it:
import from Misc_Helpers all;
in your module and then call
Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
You can also pass the function a verdict and a message and it will take care
of calling setverdict, but beware of the following:
While setverdict would accept any number of arguments as log message
and convert them to a log string f_shutdown expects one charstring.
It's possible to use the log2str function to use the log arguments in
setverdict for f_shutdown, for example
setverdict(fail, "Template didn't match: ", tmpl_foo);
would become
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo));
Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
The mncc guard timer in osmo-msc expires after 180 sec. This tests
terminates early and fails. Lets expand the timeout in order to give the
test a chance to pass.
Change-Id: I9f954a8807c0f0513422693ac24c647da0bfafd1
Related: OS#3599
Add f_gen_handover_req() like f_gen_ass_req(), to match AoIP or SCCPlite
requirements.
For incoming HO, MSC_ConnHdlr needs to know the SCCP addresses to expect the
incoming SCCP Connection from MSC to BSC. Add 'handover' section to
TestHdlrParams, and pass in the addresses from test_CT via that.
In osmo-bsc.cfg, add a remote neighbor config, so that the VTY command
'handover any to arfcn 123 bsic any' can trigger an outgoing inter-BSC HO.
Add various BSSMAP handover templates to BSSMAP_Templates.ttcn.
Add RR Ho Command template to L3_Templates.ttcn.
Move ts_BSSAP_Conn_Req() from msc/BSC_ConnectionHandler.ttcn to
library/BSSMAP_Emulation.ttcn, so we can also model an SCCP Connection Request
in BSC_Tests.ttcn (this time from MSC to BSC).
Add the two new tests to bsc/expected-results.xml.
Related: OS#2283
Change-Id: Id22852d4be7f127d827e7a8beeec55db27c07f03
Harald Welte
Neels Hofmeyr
Philipp Maier
Daniel Willmann