A preceding patch has added mncc_with_sdp, defaulting to false.
So far just two new tests use mncc_with_sdp := true, but operation
without SDP is now merely the legacy compatibility mode, and I would
rather nudge new tests towards mncc_with_sdp := true.
So switch the default to mncc_with_sdp := true.
Change-Id: Ic9871917c57a9ab81b2fff0af7f569b09015910c
Add CallPars.mncc_with_sdp: when true, the call establishing functions
f_establish_{mo,mt} now send valid SDP via MNCC, and validate that the
SDP received on MNCC and SIP are as expected.
Keep all current tests unchanged with mncc_with_sdp := false: they will
continue to test the case without SDP (for legacy compatibility). These
tests will still pass on the 'latest' builds.
Add two new tests for mncc_with_sdp := true: TC_mt_with_sdp and
TC_mo_with_sdp. These new tests will fail on our 'latest' builds until
the SDP forwarding feature in osmo-sip-connector is released.
Related: osmo-sip-connector I3df5d06f38ee2d122706a9ebffde7db4f2bd6bae
Change-Id: Ib2ae8449e673f5027f01d428d3718c006f76d93e
Whenever we send a ts_BSSGP_DL_UD via BSSGP and we expect the downlink
assignment on the paging channel by calling
f_ms_exp_dl_tbf_ass_ccch(ms), then we should make sure that
ts_BSSGP_IMSI actually contains an IMSI (paging group)
Related: OS#5927
Change-Id: I356d93edd03c7e7564bde88d34effcf1b1967621
When we send BSSGP DL UD, we should include an IMSI, since we are
expecting the paging request to appear on the PCH
Related: OS#5927
Change-Id: If62c2c7db9717cd08116374ee6ca939211bdf01e
In many of our tests we trigger a paging by the PCU by sending some data
through BSSGP. However, we often do this without putting an IMSI into
the ts_BSSGP_DL_UD template. The PCU then send the paging through the
AGCH because without IMSI no paging group can be calculated. The tests
still expect the paging to appear on the PCH and fail.
Let's fix this by adding an IMSI to the BSSGP request so that the PCU
knows the and the paging is sent through the PCU.
Change-Id: I7a70cc2a8af9d088071841861a8120afb9af86f9
We currently send a confirmation back when the SAPI was PCH. This is no
longer correct. We now have to check if the receiving end has actually
requested a confirmation.
Related: OS#5927
Change-Id: I339dfd0c057d957d2ace24fd6821e54c25fe8eb2
The msg_id in record record PCUIF_data_cnf lacks the variant
BYTEORDER(last), (which we use in record PCUIF_agch and record
PCUIF_pch). This causes the msg_id to be sent back in the wrong
endieness format.
Related: OS#5927
Change-Id: I69c1ccc37dac1e06ebe29484c767014954ff55e2
When receiving an IMSI from PCUIF (see type record PCUIF_pch), it is
represented as a null terminated string. The field is set to be 17
characters wide with a pdding of zeros at the end (as it ought to be
for a null terminated string). Unfortunately TTCN3 will not chop off
the trailing zeros, and also include them when the string length is
determined using lengthof(). This means we must take care of this
ourselves.
Let's use a regular expression to make sure any non numerical digits
are trimmed off before passing the IMSI string on to higher layers.
Related: OS#5927
Change-Id: I7bfea59a306e75211856e4e80985ebf000c42224
The function f_pcuif_rx_pch_pag_req1 tries to read the IMSI suffix from
the raw data that was exchanged on the PCUIF interface. This is no
longer the appropriate way in PCUIF v.11. There is now a dedicated imsi
member in type record BTS_CCCH_Block, which is used for that purpose.
Related: OS#5927
Change-Id: I0c7c6a31cbf7ed533e665728c157de0ac9e0fe8d
The osmocom git fork containing an extra patch has been rebase to
current upstream master, which now contains a fix for LUDT(S) messages
which will be required in a follow-up patch.
Related: OS#6185
Related: SYS#6566
Change-Id: Id8b7ab652b656841a9b73d40d79077a47f45e735
OsmoPCU has support for PCUIF v.11 for quite some time now. Let's
upgrade the testsuite as well.
Related: OS#5927
Change-Id: I6c4042f2224cd48aecc1b1499226f7d23caddd4f
Move composition of CallPars out of all f_* functions into their TC_*
functions, so that future tests can reuse the f_* functions with
different CallPars.
An upcoming patch wants to call f_TC_mo_success_rel_sip() with different
CallPars.
Change-Id: Icdcaa7a8a0fadcd6f5715ad052e286b904ded570
Since osmo-bts 1.7.0 & osmo-pcu 1.3.0, which were just released
PCUIF v11 is supported, so use it by default.
Change-Id: I8e5f44fc1d613c12eaf984dff860ee6f05c2c171
The testcase TC_s1ap_attach is not complete yet. Since the testsuite
lacked the S11 interface, it was not possible to develop the testcase
beond the S1AP/NAS-EPS Security Mode Command. However, the S11 interface
is now available to the testsuite, so let's show that it works by
catching the Create Session Request. Let's also put a TODO that the
testcase needs to be completed still.
Related: OS#5760
Change-Id: I6350a3d5cab33fa4f43e4cdcbd7bf3241821d233
With a new HLR version there are multiple APN possible in the
Subscriber Data (PDP Info).
Related: SYS#6391
Change-Id: I8d0c08272bc239370e800d6014ab9c68087b8989
APN are encoded by splitting each domain part by the dot and prefix
each element by a 8bit length.
E.g. internet -> \x08internet and internet.foo -> \x08internet\x03foo
Change-Id: I607969cd58110d4d5ff1b828e64cf2b5031868ac
This function is going to be used by the upcoming testcases for CSD
specific channel modes. Generating the Rx/Tx payload(s) now becomes
the duty of the calling function. So far the only user of this API
is f_TC_speech_rtp(), so move the speech payload generation there.
Change-Id: I9e823c33b1dbbadd57bc63df25b8ddf368d76232
Related: OS#1572
When GTPv2 unit-data is passed around, there is always the problem that
it is routed to the MTC_CT (TEID0). The reason for this is that GTPv2_Emulation
cannot determine a specific receiver component because unit-data does
not contain any addressing fields that would identifiy a specific vc_conn.
In GTPv2_Emulation there is already a mechanism implemented that detects
responses by their sequence number. Untfortunately this does only work
when the vc_conn has send a unit-data message before so that the
sequence number of the response can be guessed.
In case the first messages comes from the IUT, there is no way to
determine the receiving vc_conn, so this message is then routed to the
MCT_CT (TEID0). This can be a problem for testcases that run from inside
a ConnHdlr componet.
The solution that is proposed in this patch uses a mechanism that allows
to create an expectation for a specific messageType. When the GTPv2_Emulation
sees a unit-data message with the expected messageType, it will forward
it to all ConnHdlr (vc_conn) components that have registered for this
messageType previously.
Related: OS#5760
Change-Id: I02bb74d7bd547347168b5c64ee6512c71e8fd960
A tracking area update that contains an OldGUTI (TMSI) that is unknown
to the MME should be rejected.
Related: OS#5760
Change-Id: I9306fea69ac930b9642528e2fd32a7091147081e
We do have ts_NAS_MobileId_IMSI/IMEI/GUTI, those can not be used when
crafting EPS messages. However, we can use them to craft
ts_EPS_MobileId_IMSI/IMEI/GUTI templates.
Related: OS#5760
Change-Id: I1adf8c652530904a8e9bd988e78c995c75bb49ab
The template ts_NAS_GUTI permutates the MCC/MNC digits in a weird way,
which seems to map to a format that is not used anywhere else. Also the
template is not used anywhere yet.
Let's not permutate the MCC/MNC digit, instead let's put a comment that
makes clear which format has to be used.
Change-Id: I9546993987b873e8ae921664238b234608e37bba
Related: OS#5760
The S11 interface is used by the MME to talk to the SGW-C. At the moment
we do not simulate the S11 interface in our testcases. This is in particular
a problem for TC_s1ap_attach, which needs to answer the Create Session
Request, comming from the MME in order to continue.
As a first step, lets add evrything that is required to run an S11
interface in the testsuite.
Change-Id: I545dd6cef3cef7283f2e04c2406a2703c2fdd01a
Related: OS#5760
In function f_init, we activate altstep as_uecups_ind at the end of the
function. In as_uecups we use the template generator function
tr_UECUPS_RecvFrom_R(). In this function we use g_uecups_conn_id, which
is only populated when use_gtpu_daemon is set to true. When
use_gtpu_daemon is false g_uecups_conn_id will be <unbound>, which leads
into an error.
Related: OS#5760
Change-Id: Ifc2e8d9de13d5d183d6f052b2092c356ab4973d1
We are about to introduce a feature for SLS "randomization" in osmo-stp,
so let's modifiy our STP tests to permit any SLS in the M3UA messages
after IPA -> M3UA conversion.
Change-Id: Ib70322b80a72e3e7dc3155bca9e67b03efb413e0
Related: SYS#6543
This fixes following error while running test
GGSN_Tests.TC_pdp46_act_deact_apn4:
"GTP_Templates.ttcn:315 Dynamic test case error: Restriction `omit' on
template of type octetstring violated."
Change-Id: I3846d2a077e4bc53a772e354fcc3c38ca952b38f
Do some refactoring to the core infrastructure of the tests before
adding new testsi. Among others:
- Move Tguard to main component
- Avoid having to call f_init_handler in each handler (do it
automatically during f_start_handler()).
Change-Id: I4a1bf6ca03549688704815e3fec4e5152d0181a6
The record BTS_CCCH_Block has an optional field "confirm". However, this
field is not marked as optional. Also f_BTS_CT_handler should make sure
that this field is populated with "omit" when it is not present.
Related: OS#5927
Change-Id: Ifcbb72c22b93855bed89f4970cf63bd2d6fcd128
This patch fixes BTS_Tests.TC_pcu_data_ind_lqual_cb, which is currently
failing due to incorrect decoding of the 'lqual_cb' field:
"Link quality -32512 does not match expected value -256"
The COMP attribute is documented in TITAN's reference guide,
see 4-ttcn3_language_extensions.adoc#attributes for more info.
Change-Id: I79b8cd41010f212898fbf39c4c600ace69603e79
Related: OS#5954
When we receive a PCUIF_DATA_REQ, f_BTS_CT_handler will mangle the
incoming message for us. The resulting BTS_CCCH_Block that is sent up to
the component not only contains the PCUIF message, but will also have
the already parsed MAC block attached. This currently only works for
PCU_IF_SAPI_PCH and PCU_IF_SAPI_PCH_2 but not for PCU_IF_SAPI_AGCH_2.
Let's add compatibility for PCU_IF_SAPI_AGCH_2.
Related: OS#5927
Change-Id: Ife67bde444d957822a953391b80d01d49fff064b
In PCUIF v.11 we support getting confirmations for IMMEDIATE ASSIGNMENT
messages that are sent through the AGCH.
Related: OS#5927
Change-Id: Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458
Pau Espin
Neels Hofmeyr
Philipp Maier
Vadim Yanitskiy
Alexander Couzens
Harald Welte