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
The testcase TC_pcu_data_req_agch uses SAPI PCU_IF_SAPI_AGCH. Since we
now have a function f_PCUIF_tx_mac_block_agch() to send MAC blocks over
the AGCH using the recently introduced SAPI PCU_IF_SAPI_AGCH_2, lets use
this function instead.
Related: OS#5927
Change-Id: I341bbd01e8132fab913d307bfb4b2fb873cdde3c
In PCUIF v.11 it will be possible to get confirmations for IMMEDIATE
ASSIGNMENT messages sent through the AGCH.
Related: OS#5927
Change-Id: I40e05a2e68cca77d3c2f41df9af8d35762488abf
In the recent PCUIF change of osmo-pcu (see Depends) a confirm flag
is added to struct gsm_pcu_if_pch. This flag tells the receiving end
(OsmoBSC or OsmoBTS) that the sending of the received MAC block has
to be confirmed towards the PCU. OsmoBTS and OsmoPCU now rely on the
conformation flag.
Let's update the BTS_and PCU testsuites accordingly.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I7017ca20ca7e0b77d0f363121e4f17280e39e8ac
After fixing GCC and BCC transaction ID, the new head is:
b6602eb357673f097ea1a1d22edd568ecd239da1
Related: OS#4854
Change-Id: I2833750a8cf1def74f92a5a50f0d271891cee05f
This is useful in the scenarios where the client component submits a
IMSI-based transaction such as AIR, but its answer (AIA) contains no
IMSI (as per what's specified in TS 29.272 5.2.3.1). As a result, the
received AIA message would be enqueued in the DIAMETER_UNIT.
With this new feature, the test can create an expect using the
End-to-End Identifier of the message it is going to transmit, and
receive the answer in the same DIAMETER_CLIENT port the request was
transmitted, even if it contains no IMSI.
Related: OS#5757
Change-Id: I25e44146d2c49e308c1fb490b499e70ac6045f2f
The decoder function that decodes the RIM ROUTING ADDRESS should be
called dec_RIM_Routing_Address_GTPC and not dec_PCUIF_pch_dt
Change-Id: I4235bc727bf8e71d1ef4a43c830706b6e1c826c9
Pau Espin
Philipp Maier
Neels Hofmeyr
Alexander Couzens
Vadim Yanitskiy
Harald Welte
Oliver Smith