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, but not for PCU_IF_SAPI_PCH_DT.
Let's add compatibility for PCU_IF_SAPI_PCH_DT.
Related: OS#5927
Change-Id: Ibaa6d170ef0f1f61b708a872a3c2364585063503
The function that assigns the downlink TBF f_ms_exp_dl_tbf_ass_ccch()
uses SAPI PCU_IF_SAPI_AGCH as default but actually downlink TBFs are
assigned via the PCH. This means we have to put PCU_IF_SAPI_PCH into the
parameter list on every function call, so it makes sense to change the
default to PCU_IF_SAPI_PCH and omit the SAPI when calling the function
Related: OS#5927
Change-Id: I49c59bad0162cb303669f6108201f154918b1db3
This allows selectively disabling ASN.1 memory checks, which still fail
in current osmo-hnbgw-latest.
Change-Id: I5c18cf2d6797bcf0bef13d71ab0b69f1403b474f
Add the missing rx of MNCC_REL_cnf to f_call_hangup for the MO case
(called with release_by_ms = false, see f_mo_call()).
This is in preparation for running f_mo_call several times in a row to
test multiple bearer services in a CSD test (follow up patch). Without
this patch, calling f_mo_call_establish() for the second time fails to
rx the MNCC_RTP_CREATE because the REL cnf is still in the port. This
leads to a timeout of X2 and OsmoMSC sending a CC RELEASE.
Adjust the log numbers next to f_call_hangup to re-use numbers 2 and 3
from above, as only one of the two code paths gets executed (similar to
numbers 5 and 6 below).
Related: OS#4394
Change-Id: Ia2ed7ce092e73e17c4243e83bfd239ead8266b49
The test uses two connections: "confecho" and "sendonly". It is expected
that "confecho" connection receives as many RTP packets as it sends,
because it echoes back its packets. It is also expected that "sendonly"
connection receives the same amount of RTP packets.
Change-Id: I7df4a58ad9287a564b2daf7548b882c03787f7f2
To test the planned Gn connectivity support in open5gs MME the testsuite
also requires support for such an interface. This patch adds the
connection handler, provided by GTP_Emulation.ttcn to the connection
handler in MME_Tests.ttcn, along with a simple GTP ECHO REQUEST
testcase.
Related: OS#5760
Change-Id: I38b668df15b3dd10542b4aa8790b9ea33c1f9635
When using the GTP_Emulation connection handler one has to configure a
GTPC and a GTPU link. However in some situations (e.g. when testing the
Gn interface of an 5g MME) only GTPC may be required. So lets make the
GTPU link optional.
Related: OS#5760
Change-Id: I509a229fcaf02ea5149df42816af27bba46d3bff
We need to call f_shutdown() to properly terminate all components.
All (at least speech related) testcases do this function call.
Change-Id: Ib706fe3d9901f9cd1a0efa7d9ffd3b5b8a4472d7
Otherwise we're getting a DTE when trying to run this function more
than once in a single testcase (e.g. when testing different channel
modes). This is already done properly in f_TC_speech_rtp().
Change-Id: I290789153bea4b128af29dcf7c52da16b64c4108
Related: SYS#5919, OS#4823
This testcase is currently passing for both -master and -latest
versions of osmo-bts, despite their behavior is different:
* the -latest is sending FACCH frames with dummy LAPDm func=UI,
* the -master is sending invalid speech frames with inverted CRC3.
There is a bug in the 'tr_bad_frame' template definition: we expect
the payload to be present, while in real BFIs it's omitted. So these
two testcases would always pass, even if the IUT would be sending dummy
bursts or sending nothing at all, because they were designed to fail on
receipt of a never-matching TRAFFIC.ind template.
Let's fix this and align our expectations with the current behavior
of the -master version of osmo-bts. Note that sending invalid speech
frames with inverted CRC3 is not osmo-bts-trx specific behavior;
it's actually a replicated behavior of DSP based osmo-bts-sysmo.
Change-Id: Ic680002f60e598cfeeb448c517581b3506355e5b
Related: osmo-bts.git I78106802a0aa4af39859c75d29fe0e77037899fe
Related: SYS#5919, OS#4823
The MSC will block (seize) or unblock (release) the uplink on one BSC,
if a talker requests or releases uplink on a different BSC. An UPLINK
BUSY or UPLINK FREE message es expected to be sent to the BTS.
Change-Id: I7ebf03662e81f59d76ca8d8fa29f581043053564
There is no UPLINK BUSY message sent by BSC, if the talker
requests/establishes the uplink. Due to timing reason, the message is
sent by the BTS itself towards the MS.
Change-Id: I2e3b866eca174ae212ea986980d508e48e31fa57
I forgot to update this function in [1]. Let's make it consistent with
the f_TC_speech_rtp(). More details can be found in the linked patch.
Change-Id: I8c2f8bb4cc4b44378af5536893bc73fde368b3fe
Related: [1] Ifb69669b75df5b390d7056cefaf0ef1df69d9bd4
Without this change I cannot run BTS_Tests manually anymore:
Local verdict of MTC: fail reason:
"BTS_Tests.ttcn:480 : Invalid PCU Version/BTS Number received"
Change-Id: If0046b44adb93fba7dced1ce06d5ddb9d7c75269
Fixes: 3b4abb86 "BTS_Tests: Add support for PCUIF protocol version 11"
The S1_SETUP_REQUEST may have an optional IE eNB_Name in between Global
eNB ID and Supported TAs
Related: OS#5760
Change-Id: Id4b52921053884e79349301598b75c264b7f058c
This testcase has been fixed in [1] and is currently passing.
Change-Id: I9bc81629a9baaf922a87ac95c8f69af343aacdf1
Related: [1] I2c328219b1a37d0f4623c5728143cd91976000a0
Related: OS#5972
It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
expectancies.
Change-Id: If48ca06f2cc3c0986daa5f6264d80138d468332a
At the moment we do not have a default implementation for the create_cb.
The create_cb is called to resolve the vc_conn to which a subscriber
communication belongs in case it is not found in the S1apAssociationTable,
then it is resolved from an S1apExpectTable instead.
The current implementation uses the IMSI as key to resolve the vc_conn
from the S1apExpectTable, this might not work since in S1AP the UE
context is identfied by an MME_UE_S1AP_ID / ENB_UE_S1AP_ID pair.
Related: OS#5760
Change-Id: I758e7c8d8cc445cf18acdd7a25dcde8846fd84e5
When a S1AP_UeContextReleaseCmd is received, the UE association should
be deleted.
Related: OS#5760
Change-Id: I8c6f7a780945ce34dabdc794aabab5d16a3a73aa
When we search for the entry that we want to delete, we use the
ENB_UE_S1AP_ID as a search key, but we compare it against
mme_ue_s1ap_id. This is not correct, it should be compared against
enb_ue_s1ap_id
Change-Id: I8528af4e3fda0bc97f8b14785097434a6163bcc4
Related: OS#5760
The INITIAL CONTEXT SETUP RESPONSE message may have optional elements at
the end.
Related: OS#5760
Change-Id: Ic28c94093e55db0dc1fa18d36e22d328788cb3fc
This allowed me to find massive memory leaks in osmo-hnbgw: at the end
of each test, run f_shutdown_helper(), and in it query 'show talloc' for
an empty asn1_context.
Hence verify that all the scenarios run in these ttcn3 tests have no
asn1 de/encoding memory leaks.
Change-Id: I2948ee6f167369a2252f85b493e9653b93c7e4e9
I want to use it in a new function f_verify_talloc_bytes() added to
Osmocom_VTY_Functions.ttcn in I2948ee6f167369a2252f85b493e9653b93c7e4e9.
Change-Id: I9ddd9977734efd7599481261f04df82620845cef
To get 001-01, we need to encode the placeholder 0xf nibble.
Since recently, osmo-hnbgw cares about the PLMN in messages, in specific
cases: in upcoming CN pool tests, the PLMN is part of the algorithm that
picks the CN link. So let's encode 001-01 correctly.
Change-Id: I5299c521479dc25ea0f82d7d294d53942960d2cf
If the talloc count matching failed, immediately stop the failed test.
It is currently used by BSC_Tests.ttcn, and will soon also be used by
HNBGW_Tests.ttcn. These tests were used to uncover memory leaks, and
can now remain to guard against new leaks being introduced.
Change-Id: Id2b29beecf1c0652fb8d75e031e5c0dc9aa27975
This RANAP RESET code...
a) is not used:
osmo-hnbgw has only recently started sending RANAP UnitData by its own initiative.
Until very recently, osmo-hnbgw has only responded to receiving a RESET, with an ACK.
It has never sent a RESET message to the peer, here titan.
b) makes no sense implementation wise:
RANAP RESET handling is actually implemented in RAN_EMulation.ttcnpp.
c) makes no sense protocol wise:
The UnitDataCallback happens when osmo-hnbgw sends a RANAP UnitData to
titan: if at all, the only logical response would be a RESET ACK
message, not a RESET message.
Change-Id: Ie7b9022e991b63b945c7ec6e5c9f7c4eb5da4d7e
Fix the missing call to f_ran_unregister_imsi when running f_mt_call.
This is in preparation for calling f_mt_call multiple times during one
test, to test various CSD bearer services. Without this patch, it will
result in a "No space left in ImsiTable" error.
I've also considered adding it to f_call_hangup instead, but this gets
called by f_mo_call (mo instead of mt) as well, which does not run
f_ran_register_imsi.
Related: OS#4394
Change-Id: Ie9b180b95348d7e84650c14a331c5091a1e67d1f
The PCUIF protocol version 11 uses a more distinct (direct TLLI) way
to signal PAGING COMMAND and IMMEDIATE ASSIGNMENT messages towards the PCU.
Since OsmoBTS will soon fully support v.11 of the PCUIF protocol we need
to add compatibility in the OsmoBTS TTCN3 testsuite early. We also have
to stay compatible with older versions of OsmoBTS. The BTS_Tests.default
config still sets up mp_pcuif_version to version 10, so this will be the
default until we have full version 11 support in current master and
latest.
Related: OS#5927
Change-Id: I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
When the PacketCellChangeNotification proposes an UTRAN or E-UTRAN cell,
then the PCU will not provide system information. Instead it will directly
conclude the NACC procedure with a PacketCellChangeContinue message.
Related: OS#6044
Change-Id: Idae86a458fd44ac81bab183ed1865b1c1bdbfd66
The testcase TC_nacc_outbound_success tests the NACC procedure. The cell
that is proposed in the PacketCellChangeNotification is a GERAN cell.
This means that the PCU should conclude the procedure with a
PacketCellChangeNotification that contains the ARFCN and BSIC of the
proposed cell. Let's make sure that this actually is the case.
Related: OS#6044
Change-Id: I4b8f3312088e3d2bc4b90702485e7c6a8d39f954
The record PCUIF_pch_dt uses ALIGN(left) variants for imsi data. This is
not correct, since it would left-pad the data with zeros if it does not
fit the specified length. This is a problem with IMSIs shorter than 17
characters, because the left padded zeros would appear like a
null-string to the receiving end.
When the ALIGN(left) modifier is removed, the encoder will apply the
padding from the right. This will fill the unused space after the string
with zeros.
Related: OS#5927
Change-Id: I011eb2496b1422c49736b227dfa1e2a2d6096d67
When we respond to the MGCP requests from OsmoHNBGW, we use codec name
"FOO" and payload type 23 in the SDP part of the response. This is
obviously an invalid codec and osmo-mgcp-client will not tolerate this
anymore. Let's use a more realistic payload type and codec name, like
112 and "VND.3GPP.IUFP"
Change-Id: Ib53ff7a878087b497e6ff27f786c9ab1297f3d5f
This patch fixes multiple compilation warnings like this one:
Inadequate restriction on the referenced template variable
`attach_req', this may cause a dynamic test case error at runtime
Change-Id: Iee7760d3dcf2a35d7fe612ed80dc13c1d11e0897
Philipp Maier
Pau Espin
Oliver Smith
Andreas Eversberg
Vadim Yanitskiy
Neels Hofmeyr