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
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 trx_sniff.py:
# TRXD of the BB side
$ ./trx_sniff.py -p 6700
[DEBUG] trx_sniff.py:110 L1 -> TRX burst: fn=616 tn=0 pwr=0
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=597 tn=0 rssi=-60 toa256=-2560
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=598 tn=0 rssi=-60 toa256=-2560
...
# TRXD of the BTS side (Uplink bursts only)
$ ./trx_sniff.py -p 5700 --direction L1
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=719 tn=0 rssi=-60 toa256=0
and additionally be enriching logging messages of fake_trx.py:
[DEBUG] fake_trx.py:186 (trx@0.0.0.0:6700) 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 fake_trx.py, that has been fixed recently.
This patch makes 'BTS_Tests.TC_rach_max_ta' green again ;)
Change-Id: I7736abd85407c186856be9f1a22613a1fa6e0c32
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
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
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
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
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
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
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
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
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
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
It's unclear why those variants were commented - looks like artifact
from initial development. Let's drop them to avoid confusion.
Change-Id: I3f11a93634fc50243a7210edcd501bd4b90d6dcd
This makes it easier to track when this workaround can be disabled once
Debian/upstream (hopefully) resolve the issue.
Change-Id: I3c4ed0ae5c1145f162b2745f4a46705b51874b5b
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
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before
the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a
few corrections of the VTY command format.
Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
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
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 a5302c8151
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
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
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
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 7.6.8.1),
- OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2),
- OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4),
- OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7),
- OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4),
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
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
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
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
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
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
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
With some real HW setups, there's no PCU (osmo-pcu) available locally,
for instance when using a sysmobts, or when using a nanoBTS. There's no
need to waste time and generate extra output by running this tests in
this case.
Furthermore, some tests seem to crash sometimes in that setup, probably
due to using invalid fd (-1):
MTC@801a0da9866a: Setting RSL_SYSTEM_INFO_4 (4): '31061C62F224002A4740E50400'O
/osmo-ttcn3-hacks/bts/BTS_Tests: Segmentation fault occurred
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7f0c33b48073]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7f0c321aa060]
/osmo-ttcn3-hacks/bts/UD_PT.so(_ZN12UD__PortType15UD__PT_PROVIDER13outgoing_sendERKN9UD__Types14UD__send__dataE+0xf0)[0x7f0c349e42f8]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_17PCUIF__send__dataERK9COMPONENT+0x19e)[0x7f0c37e1731a]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_26PCUIF__send__data_templateE+0x5f)[0x7f0c37e174f7]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests20f__TC__pcu__act__reqERK7INTEGERS2_S2_RK7BOOLEAN+0x411)[0x7f0c3eec3210]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests28testcase_TC__pcu__deact__reqEbd+0x15d)[0x7f0c3eec4f27]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(+0xfb65d)[0x7f0c3eeef65d]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN11Module_List15execute_controlEPKc+0x1c)[0x7f0c33af3fbc]
Change-Id: I773c7ec52dd8532bf160e92ffefc8d936ca55de2
tr_BSSMAP_HandoverPerformed matches all optional fields on "omit". This
does not make much sense as a safe default. Lets match on "*" instead.
(See also other tr_ templates)
Related OS#3645
Change-Id: Icd55afdaebdda8ba98431f358148035f7d220b8a
Implement a basic paging test for the PCU, which is passing for paging
via TMSI (but only if osmo-pcu is started after the test is started).
Previously, this test code amounted to a debugging loop which
never terminated.
Change-Id: Id0384e0742ab91983615e4f1c883bb044c1c8b18
Related: OS#2404
It's useful to see which BTS exactly has failed the test in
configuration with multiple BTS on single BSC.
Change-Id: Ib813635862c04d51a30e7bbcca4ec05ce664f7e9
tr_BSSMAP_HandoverPerformed lacks the field speechVersion, lets add it
to make the template complete.
Change-Id: Id73c0aef5caa0936aa44308faf2aae1c20c7446c
Related OS#3645
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
Previously the expectations for number of CRCX and MDCX messages from
MGW was adjusted unconditionally for LCLS tests. However this is only
necessary for MGW-loop type of LCLS. Use explicit variable (with default
value preserving current behavior) to decide whether to apply this
adjustment or not. This simplifies support for other kinds of LCLS
loops.
Change-Id: I07b2c56991977b5e80c372a5b8338f348f14c076
Related: OS#3659
Move duplicated code into separate functions to simplify adding test
cases which do not use MGW MDCX methods for closing the loop.
Change-Id: Idf9fc8e639b0ece662ab26c481899ef39fb7edfe
Related: OS#3659
Philipp Maier
Vadim Yanitskiy
Harald Welte
Daniel Willmann
Pau Espin