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
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
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
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
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
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
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
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
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
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
This allows to start ConnHdlr on specific RAN connections, i.e.
on different emulated BSCs (and soon RNCs).
Change-Id: I3d7ec567a7b69d8c6f79d26971bf1c94e077d5f5
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
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
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
Pau Espin
Harald Welte
Stefan Sperling
Philipp Maier