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
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
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
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
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: 1d118ff753 ("msc: add check IMEI tests")
Change-Id: I836f76242463789c4c003feec757714827f2a31b
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
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
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 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
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
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
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
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
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
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
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
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
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
In this testcase we perform LUR, then request our own number and
then expect the response with matching MSISDN.
Change-Id: I82450c6f48f6c17bc33e0ec6c91f2a73e44793ad
The test case TC_establish_and_nothing is now passing.
Update expected results list accordingly.
Change-Id: I925fa4ad2e38e189cf5dd1ae76a24cdb9011fdc8
Related: OS#2879
'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
Neels Hofmeyr
Neels Hofmeyr
Eric Wild
Pau Espin
Oliver Smith
Philipp Maier
Harald Welte