Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Related: OS#5927
Change-Id: I15e754ce3ceed92a517586a073d3e3ed008b5eef
Add tr_RUA_Disconnect_opt_ranap that matches RUA Disconnect with and
without RANAP payload.
Use this in RUA_Emulation as_main_rua(), to trigger a RUA_Disc_Ind to
the CLIENT also for Disconnect without RANAP data.
Rationale:
This patch exists for the line
RUA.receive(RUA_Disc_Ind:?);
in the TC_apply_sccp patch Ia1ff0cb56893edf045ea3cb3233882ca93445d21
In upcoming HNBGW_Tests.TC_apply_sccp, I want to test for an ungraceful
RUA Disconnect, which is sent without a RANAP payload. But
tr_RUA_Disconnect only matches when a RANAP Message IE is present. In
consequence, RUA_Emulation ignores "empty" RUA Disconnect, and my test
case cannot verify that the RUA Disconnect occurred. Fix that.
Change-Id: Ia0b89e9198794d196a88040ee89bdf24f3b08ae0
Only dispatch RUA_Disc_Ind to CLIENT when CLIENT is connected.
Reason:
If a test does not care much about conn cleanup, it may cause a
situation where the CLIENT has already disconnected when osmo-hnbgw
sends a RUA Disconnect. A disconnected CLIENT port will cause the final
verdict to become 'error'. Instead, if the CLIENT is already
disconnected, just don't bother, and allow tests to still pass.
This will become necessary, because:
So far a RUA Disconnect without any RANAP payload is not detected by the
RUA emulation. But patch Ia0b89e9198794d196a88040ee89bdf24f3b08ae0 will
fix it, so that *every* RUA Disconnect causes a RUA_Disc_Ind sent to the
CLIENT. From then on, we will see a bunch more RUA_Disc_Ind at the end
of tests. Some of those happen *after* the client already disconnected,
causing tests to error that have been passing for a long time.
Change-Id: Ia1403f39cfdc75139922292a3eace7a69a64a576
The record PCUIF_data_cnf_dt was added when the first experiments
with Ericsson RBS base stations were made. It is essentially a copy of
record PCUIF_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Related: OS#5927
Change-Id: Ie17d73d4c4bf2921800f87f6d6be7c05ce3a291d
The function f_PCUIF_tx_imm_ass_pch() retuns the frame number, that is
sent back from osmo-bts via PCUIF / gsm_pcu_if_data_cnf_dt. Since we are
about to remove this field from gsm_pcu_if_data_cnf_dt, lets no longer
access it here as well. Also the return code is never used anywhere in
the tests. (In osmo-pcu the fn parameter was used for logging only, in
osmo-bts it was set to constant 0)
Related: OS#5927
Change-Id: I0e5bad7a0d74e5032f2818f6fdf5b9b2ecb531cc
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related record member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: I1db29d5b1920e351c452b798c3260654c2cbe0cb
The IE types RIM_RoutingAddress and RIM_RoutingAddress_Discriminator
have not coresponding templates yet.
Related: OS#6095
Change-Id: If79f94ac3b7ec9a76763141ee2d8cac50c69d60b
The GTP Templates lack the template restriction qualifiers (present,
value, omit) in many places.
Related: OS#6095
Change-Id: Ic439b4ae85b417fde0ddfb8fa00758d6486b57c8
docker-playground.git needs a config file change to be committed at the
same time as this patch, see 'Related'.
Depends: osmo-ttcn3-hacks I94aa0b2adfc48b98cb4b1efe595c2432fc603d6c
Change-Id: I027a059faed3f140f8801f84338956cd004043b5
Allow starting with a specific 'msc' / 'sgsn' instance without having to
read all the lower numbers along. For HNBGW_Tests.ttcn.
Change-Id: I9b74a1df9e115883b4b0ac0f606a370c6aca7f40
When forwarding RAN TRANSPARENT CONTAINERs containers on GTP-C, the
sender adds a RIM ROUTING ADDRESS and a RIM ROUTING ADDRESS
DISCRIMINATOR. The RIM ROUTING ADDRESS is represented as an
octet-string, so we need encoder/decoder functions for it.
Related: OS#6095
Change-Id: I45d1f5b019f3847fd611c38dc19d78d6fe027c5a
The expectation table is used to deliver new connections with Handover
Request as well as with VGCS/VBS Setup and VGCS/VBS Assignment Request.
"handoverRequest" is renamed to "n_connect".
Related: OS#4854
Change-Id: I941c5db5235785841f3368ef908a409bbb12150e
Similar to Handover Requests the RAN Emulation can accept new SCCP
connections with VGCS/VBS Setup message and VGCS/VBS Assignment Request
message. The point code for the incoming connection can be registered
in the same way as for the Handover Request.
In order to allow multiple connections with the same point code, the
table entry in the ExpectTable must be released after receiving the
message. VGCS/VBS calls have multiple connections to the same BSC.
This patch does not break existing MSC handover tests.
Related: OS#4854
Change-Id: I3fc0c5efe7d9f270804e7295aeb65cfe7898bd7e
We have a ts_RANTransparentContainer_RAN_INFO_REQ but no coresponding
tr_RANTransparentContainer_RAN_INFO_REQ template yet.
Related: OS#5760
Change-Id: I83b0134c9406526c2fe5b6e97e160b8b28295d20
When S1AP unit-data is passed around, there is always the problem that
it is routed to the MTC_CT. The reason for this is that S1AP_Emulation
cannot determine a specific receiver component because unit-data does
not contain any addressing fields that would identifiy a specific eNB or
UE.
Unfortunately it can be a huge problem when developing test fixtures
that use unit-data from inside a ConnHdlr component. It is no problem to
send unit-data using S1AP.send(), but it is impossible to receive
unit-data through the same path.
The solution that is proposed in this patch uses a mechanism that allows
to create an expectation for a specific procedureCode. When the
S1AP_Emulation sees a messages with the expected procedureCode, it will
forward it to the ConnHdlr component.
Related: OS#5760
Change-Id: I041b45b247e365b0d4ee8645c07dc5f26007af82
The test cases used UPLINK RELEASE message as test for an unspported
message. This message is supported and does not trigger the expected RR
STATUS message. The fix uses the unsupported DTM ASSIGNMENT FAILURE
message.
To have the DTM ASSIGNMENT FAILE, it is added to
library/L3_Templates.ttcn.
Change-Id: I35877574cf4459332229e3b941918bc0a23b939f
The comp_ref member in S1apAssociationTable is not initialized. When an
item is delted from the S1apAssociationTable, comp_ref is set to null.
Let's maintain a consistent state and also set comp_ref to null when the
table is initialized.
Related: OS#5760
Change-Id: If86a18a4a953665c1e2bf7f757880ba3ac6c0f83
We have a template ts_GTPC_RAN_Information_Request not no
tr_GTPC_RAN_Information_Request yet.
Related: OS#5760
Change-Id: Ibf737ddc7a9867f0a73646bc0d86550fea6f6dbd
The RIM_RoutingAddress tells a relaying RIM node (SGSN, MME) where to
route a RIM RANTransparentContainer. The RANTransparentContainer also
contains source and detination, but is not meant to be interpreted by a
relaying node. That is why a RIM_RoutingAddress exists.
Related: OS#5760
Change-Id: I4d497389226b12368cc0ed4e3d469cde8e812ba6
The new type LapdmFrameBter and its send and receive template is used to
send and receive Bter frames, which has a short L2 header and uses all
23 octets for payload.
Bter frames are DCCH UI frames with SAPI 0 and 23 octets sent on
downlink only.
Change-Id: I07a4fd9879dfd9de441c0348a84b7dd5c9864eb4
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
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
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
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
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 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
osmo-hnbgw since recently sends own RANAP RESET out to the CN links. So
HNBGW_Tests.ttcn now receives a lot more UnitData messages.
Turns out that tests crash when no UnitData callback is provided.
Currently only osmo-hnbgw and RANAP, i.e. ranap_unitdata_cb, needs this
fix, but also apply the same safeguard to the BSSAP unitdata_cb.
Change-Id: I699a42de88b15f6f47b8feece7639e0dfaf31955
There is a typo in the CSN.1 definition for CCN Measurement Report.
While fixing this we can also shorten the record name to
"CCNMeasReport" to make it coherent to the Utran/Eutran related
definitions.
Change-Id: I1e44afdbede7420299435ddb7333dd151b5da4b3
The PacketCellChangeNotification type currently lacks the release 6 and
the release 8 additions. Those basically add 3G and 4g/5g compatibility to the
PacketCellChangeNotification message type.
Spec reference: 3gpp TS 44.060 11.2.3a
Related: OS#6044
Co-authored-by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Change-Id: I4e1c63c06fb89111765df187a93db563e77c3fc4
AoIP, call ID and codec list must be included, if user plane is IP
based. If not, the fields must not be included.
Change-Id: Id3ce78ad795c418650ca924a953294c3380b8198
As we want to test VBS/VGCS related aspects of BSC and/or MSC soon, we
will need related templates to construct and match related messages and
IEs.
This requires titan.ProtocolModules.BSSMAP updated for modern-day
VGCS/VBS related message definitions as I submitted in
https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolModules.BSSMAP_v11.2.0/-/merge_requests/3
Change-Id: I949f731de794b22292b01d0ddf9a75a9e7e7e71d
This adds support for the VBS/VGCS related L3 RR messages to
GsmRrL3Union/GsmRrL3Message. Only those with proper L3 header
and classic "tabular" syntax are supported so far, no CSN.1 messages
with short L2 header for SACCH.
Change-Id: I79ca7ee2b94bb370cd7162cfd9db436049998041
The record PCUIF_pch_dt, coresponds to struct gsm_pcu_if_pch_dt in
pcuif_proto.h. It will be needed when we introduce support for the TLLI
based confirmation of IMMEDIATE ASSIGNMENT messages that are sent via
the PCH.
Related: OS#5927
Change-Id: Ia705d3a6fe7adb863acd29e968f8dc6b2066a497
A record for the message type PCU_IF_MSG_DATA_CNF_DT exists with
PCUIF_data_cnf_dt, but there are no tr_ or ts_ templates yet.
Related: OS#5927
Change-Id: Iccde71e1dd6fbd421652c5892bc2c1f32a8535ff
"according to a comment in f_gmm_attach() there's an encoder problem if it's omit. This sounds like the ts_GMM_ATTACH_REQ()
should be changed to define solSACapability as '0' insteads of omit. At that point none of the users of ts_GMM_ATTACH_REQ
will need to manually modify it anymore."
(quote: hwelte on Gerrit (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/31199/comments/17ed155d_cc58810a))
Related: OS#4221
Change-Id: I9eaa39274456e5cc0a1cf025bf956970efc4a51f
Even though we do not need it right now, let's add the message type
PCU_IF_MSG_E1_CCU_IND. This message type has been added to the PCUIF
protocol recently.
Related: OS#5927
Change-Id: Ib6482d88e924f285658b933f32be42a4f63bee71
The SAPI PCU_IF_SAPI_AGCH_DT has been renamed to PCU_IF_SAP_PCH_DT in
the recent pcuif_proto.h version since the IMMEDIATE ASSIGNMENT what it
is used for is sent on the PCH not on the AGCH.
The SAPI constant is currently not used in the TTCN3 testsuite, but it
will soon be used when we introduce support for the recent PCUIF which
will then use the direct TLLI (DT) method.
Related: OS#5927
Change-Id: Ifc09067bcb0f9f422ca429313fa09fea081dc316
At the moment The RTP emulation and MGCP_Test only allow to specify one
codec and one set of RX/TX fixed payload octet strings to verify against.
This is quite limiting since it might be necessary to test against
different types and formats of payloads simultaneously in order to see
if osmo-mgw converts or forwards them correctly.
Let's extend this to support multiple codecs on MGCP/SDP level plus
support for multiple RTP payloads on RTP emulation level.
Related: OS#5461
Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
Verify that CSD ipaccess CRCX/MDCX has the CSD RTP payload type, and
that the RSL_IE_IPAC_RTP_CSD_FMT IE is set with
RSL_IPA_RTP_CSD_TRAU_BTS.
Related: OS#4393
Change-Id: Id0e0c5631d7a36635e1ef49cf5bf554f0336556b
The 3rd-party M3UA_Emulation supports operation both with and without
a routing context. Let's make sure the layers we build on top don't
lose that capability by forcing routing context usage.
Change-Id: Iff849953d923770c93029a6a5c5b86daa8c38f1e
The old test was not really correct, since it is fine for the BTS to ACK
the RSL CONNECT despite later on failing to connect the RSL link.
RSL_CONNECT is really just setting the attributes (it could even be
replaced by SETATTR in the future), and connect happens later on.
This can still be found out by the BSC because the BBTRANSC will never
transition to a Enabled state until the RSL link becomes up.
This patch repurposes the existent test to do some more meaningful check
in a case the RSL CONNECT can be answered with a NACK. This scenario was
actually failing to be properly checked in osmo-bts until recently, so
it is expected that it will fail (and even crash) older versions of
osmo-bts.
Depends: osmo-bts.git Change-Id If27639ae1727fc5232e1a964a1b29f50c8805d80
Related: OS#5964
Change-Id: I10df611f0086d34a5482f7c8a79703938313ab3d
Add Message types for Radio Resource management messages using
the RR short protocol discriminator from Table 10.4.2 3GPP TS 44.018
Related: OS#5783
Change-Id: Id3b59638a3cf75c7105b1992094a4cc20855161d
The old GPRS related messages are no longer valid. Use the new message
definitions supported by both trxcon and virtphy since recently.
Comment out lines referencing the old definitions in LAPDm_RAW_PT.ttcn.
This module contains an implementation of the RLC/MAC abstraction
layer, which is currently not used anywhere.
Change-Id: Ib8f4459480bbe12584a6fa71882f745f03c5055d
Related: osmocom-bb.git I9567d64f9d00262e36147e8d7e541e5e246bda5f
Related: OS#5500
Currently we have two variants of the L1CTL PDU:
* L1ctlUlMessage: L23 -> L1 requests (*_REQ),
* L1ctlDlMessage: L1 -> L23 responses (*_IND, *_CONF).
The L1CTL_PT port is defined in a way that one can:
* Tx L1ctl{Ul,Dl}Message PDUs,
* Rx L1ctlDlMessage PDUs.
This means that the testsuite can act as the L23 talking to the L1
(e.g. trxcon or virtphy), but not vice-versa. Adding an additional
Rx `UD_send_data -> L1ctlUlMessage` mapping is not an option,
because such a mapping would be ambiguous and would cause errors.
By merging the two L1CTL PDU variants into the one, we can achieve
the testsuite acting as the L1. This will be useful for testing
the L23 applications in osmocom-bb.git, like the modem app.
Take a chance to reorder fields to match the order in L1ctlMsgType.
Change-Id: I1313068c5f02b65d3dbb05a1341a9d7286225f0c
Related: OS#5500
Prepare to test CSD in BSC_Tests.ttcn. After sending a BSSAP assignment
request to the BSC with channel type data, the BSC will send a channel
activation via RSL to the BTS (which is emulated by the testsuite).
Without CSD support in the RSL template, the testsuite is unable to
decode the message, prints "Data remained at the end of the stream
after successful decoding" and the test fails.
Related: OS#4393
Change-Id: Ief2d95c7e9d71afb26fa74da755294226c8e158d
Currently an unexpected PDU will trigger a DTE (no matching alt).
Let's add an additional wildcard alt and terminate grecefully.
Change-Id: I6dbc646d5f036f454f197137373796f40c4c9e74
Related: SYS#5602, SYS#6333
The enc_* functions usually return an octetstring. However, both
f_enc_BcdMccMnc[_int]() return a sub-type of hexstring (BcdMccMnc),
so let's rename them to avoid confusion.
A follow-up patch adds the actual encoding function for BcdMccMnc.
Change-Id: I0332fe7396310da49910e89571f7181fb1604182
This is a partial revert of e9858efb90.
I was confused by weird MCC/MNC values in the Destination RAI generated
by the NACC testcases from the PCU_Tests.ttcn. As I figured out, these
values are not from the INFO.ind, but some hard-coded literals:
* SRC RAI: MCC=262/MNC=42/LAC=13135/RAC=0 (from ts_PCUIF_INFO_default);
* DST RAI: MCC=023/MNC=43/LAC=00423/RAC=2 (resolved by test itself);
so actually they're not incorrect: they're sent by the testsuite itself
in response to the Neighbor Address Resolution Request, and then
expected to be received in the Destination RAI from the PCU.
Another important point is that TITAN produces different results when:
a) converting BcdMccMnc to bytes using the hex2oct() function,
b) converting BcdMccMnc to bytes using the RAW encoder.
The key difference is that TITAN does swap nibbles in each byte when
using the RAW encoder, but does not when using the hex2oct() function.
Use the proper hexorder (low-to-high) in f_enc_BcdMccMnc().
Add a selftest to make sure we're encoding the input properly.
This change makes the NACC testcases pass again.
Change-Id: I6f497b97c4f1e270803e01530be8355beea740bb
Related: SYS#5602
Fixes: OS#5901
In [1] I copied the hexstring concatenation statement for the 3-digit
MNC from the original function f_enc_BcdMccMnc(), which was renamed
to f_enc_BcdMccMnc_int(). Unfortunately, this statement (originally
introduced in commit [2]) is incorrect.
In our implementation a pair of MCC and MNC is encoded as follows:
| MCC digit 1 | MCC digit 2 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 1 | MNC digit 2 | octet 3
Additionally, in the case of a 2-digit MNC, the original variant
of f_enc_BcdMccMnc() (before [1]) would swap MCC and MCC in the
2nd octet, generating even more unpredictable results.
According to 3GPP TS 24.008, Figure 10.5.13, the correct coding is:
| MCC digit 2 | MCC digit 1 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 2 | MNC digit 1 | octet 3
So far the only user of this API is the PCU_Tests module. Looking
at the PCAPs of testcases invoking this function, Wireshark indeed
shows weird MCC/MNC values (expected 262/42):
Routing area identification: 23-43-423-2
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
Location Area Code (LAC): 0x01a7 (423)
Routing Area Code (RAC): 0x02 (2)
Change-Id: Ifa3083fdd6307b56baa1ef3ac85a3e7a2efab728
Related: [1] 7a92d5fbc0
Fixes: [2] 0637ba0728
PFCP_Templates.ttcn is not the place to do the conversion between string
and OCT4.
When I wanted to use an OCT4 address in some ts_PFCP_* template, it
dawned on me that it is stupid to convert the OCT4 to a string, just so
that the ts_PFCP_* template converts it back to OCT4.
Related: SYS#6192 SYS#5599
Change-Id: Ib068831787f4256f70a2189a5f36ca1ea1f40c9e
We need to be able to send L1ctlDlMessage to the l1gprs_test [1],
a special program for testing the MS side GRR implementation.
Change-Id: I18e7585a8e93e3fafeda63b7325cfcc73e792abd
Related: [1] I36ceec4035b2ea593d47998f3f14f1415c606765
Related: OS#5500
We need to be able to send L1ctlDlMessage to the l1gprs_test [1],
a special program for testing the MS side GRR implementation.
Change-Id: Id163cb53afcbf803caf60a5b1a5768c67a9a2bf0
Related: [1] I36ceec4035b2ea593d47998f3f14f1415c606765
Related: OS#5500
Some AMR format's payload size doesn't necessarily fit octet boundaries.
When AMR octet-aligned is used, padding bits are appended at the end to
fill the octet.
Until this patch, the padding bits where set with whatever payload fill
pattern was provided. Instead of doing so, better set the padding bits
to 0 to avoid conflicts when checking the received paytload later on,
since those bits are potentially be going to be set to 0 (eg when
converting to bandwidth-efficient).
Related: SYS#6161
Change-Id: I5bc68eb05c2f5500a259f4c73d14b51794f7f078
There also exists UL equivalent of this message, for which I am
planning to add a template. Let's clarify direction in the name.
Change-Id: I3b19c6679eb432b062e28aee9dd1220dbf33ee31
In TTCN-3 it's not possible to store templates in records, so in
f_assignment_codec() we match received RSL_IE_MR_CONFIG against the
value (not template!) stored in g_pars.expect_mr_conf_ie.
Because of that, the length field is not being calculated by TITAN
for us, so we need to calculate it in ts_RSL_MultirateCfg ourselves.
Automatic length calculation only works during encoding/decoding
and when matching against a receive template.
Change-Id: I595be86d69913ba25e965a5a5c6977e00c342e60
The RSL MultiRate configuration IE is all about AMR (Adaptive Multi
Rate) codec, so there is no need for 'amr_' prefix in field names.
Change-Id: If63ee50e8681ad4e0a202f142f2fca2268d55079
New TC_assignment_osmux_bts is added which tests Osmux used only
BTS<->BSC.
Existing TC_assignment_osmux is renamed to TC_assignment_osmux_cn,
and a new TC_assignment_osmux is added which tests using Osmux on both
sides (towards BTS and CN).
Related: SYS#5987
Change-Id: I6e82eb9d995de988b812001e1c4cf6923509de66
Similar to what's already present in RTPEM_Emulation, this allows tests
to retrieve the Osmux messages received.
Related: OS#5987
Change-Id: Id9aa3a0a02ef5a5e39b4df8a1c165f35255829ab
Will soon be used by new subdir 'upf' (test osmo-upf),
and by 'hnbgw' (test GTP mapping via UPF).
Related: SYS#5599
Change-Id: I0723b931b3f755ea291bffa2f27c34ba446c2f2f
BSC_Tests_CBSP was sending an ETWS message but using non-ETWS templates
to match the response, which may differ from an ETWS one (for instance,
ETWS related messages have no channel_ind).
Change-Id: I42941655081af6d5b04b1e061e6259d8dee94665
This test case verifies the new channel allocation mode, which
is expected to switch between ascending and descending modes
dynamically based on the following two configurable parameters:
* Uplink RxLev threshold (and min number of samples),
* C0 (BCCH carrier) channel load threshold.
The test case scenario includes:
Case a) Unknown Uplink RxLev => fall-back to ascending.
Case b) Not enough RxLev samples => use ascending.
Case c) Uplink RxLev below the threshold => use ascending.
Case d) Uplink RxLev above the threshold => use descending.
Case e) Uplink RxLev above the threshold, but C0 load is not.
Change-Id: Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
So far only non-emergency CBS messages were tested, which require a
slighlty idfferent encoding on the protocol side.
Related: OS#4945
Change-Id: I506322fc8a664716db8cd79217c2091b0b926836
So far only non-emergency CBS messages were tested, which require a
slighlty idfferent encoding on the protocol side.
Related: OS#4945
Change-Id: Ie22a00120218a205db11a5622274dcc67435f5de
3GPP TS 23.041 9.3.32 states that the IE is always present for non-ETWS
messages and never present in ETWS messages.
The present template is used for CBS messages (non-ETWS) only so far.
Once we add support to test ETWS message this will be updated
accordingly if needed.
Related: osmo-cbc.git I4a5ac56b7e6eeb85aee07ae2ddf10fa2afbbf4ef
Related: OS#4945
Change-Id: I8f2067069ecf0c46f86279413a10e5970ec4456c
Move parameter 'fpc' at the end and assign false by default, so that
there is not need to pass false. We never set it to true anyway.
Change-Id: I8a0ef562c2426a637fbb9fe3d50711ee7738d04f
Since osmo-cbc.git I563e7d1c999f14b8197bb41e85b7bcf6262fe2a0, Write
Replace Warning Indication is sent, so expect it.
Change-Id: I84e3ae7a532a8a76ac1c26d357da7eaa73f39374
This requires a recent libfftranscode (>=0.5) with SBC-AP support.
The asn files are obtained from 3GPP TS 29.168.
Related: osmo-cbc.git Ib278bc1d1a74459814016fef7a8fe21cc29d46c9
Related: docker-playground.git 5f3c78105836d1f2c229655df3f537a73ab6e12a
Change-Id: Ia6743e0a3e7974a5f2dd3ecf74ec331f646f6bc2
Related: OS#4945
New versions of osmo-bsc send CGI instead of LAC+CI, which provides more
information (PLMN).
Related: SYS#5910
Change-Id: I48e86150f499f0f458f75f132087319d80f86448
Let's have all SABP related stuff together in one subdir, not some under
the subdir and some directly under library/.
Change-Id: Ibfd0287194c87dcc240590e0835d6205ead194f9
Audio SAPI version 1 has been added recently in osmo-hnodeb.git
I860d18b80c1041bf63a1570d435e0568c0f6b01b.
Let's update our HNBLLIF emulation to support and use it.
Related: SYS#5516
Change-Id: I9af56f5e6a70b350f2fffa2e04be384d101b52ed
Various tweaks are required to allow RAN_Emulation to handle, and also
to expect, an SCCP CR that has no payload data.
Related: SYS#5968
Related: If0c5c0a76e5230bf22871f527dcb2dbdf34d7328 (osmo-hnbgw)
Change-Id: I827e081eaacfb8e76684ed1560603e6c8f896c38
This way we trigger more code paths in the GGSN_Tests IUT, like parsing
the QoS IE. This is interesting because the QoS IE has quite a complex
encoding, specially the MBR/GBR part. Those fields in turn are also
modified during the answer based on AVPs received during Gx set up of
that session.
Related: SYS#5984
Change-Id: Id195eedf530e2eff753d057ce2302dfb5275bfcd
All the AVP ecosystem in DIAMETER is quite a mess. There's AVPs defined
in several different specs, sometimes even with the same name and
different AVP code and vendor.
Hence, as we add more templates it becomes important to start using the
prefix in order to differentiate where they come from.
Change-Id: Iec7c51dae136629d6b754de4dd798e988ac51f6b
The Reporting-Reason can be in different places depending on its values.
In the case of TERMINATION, we expect it to be FINAL so we know its
location.
Change-Id: Id33b9bb2f7b469e03a0761dc8807770cfdf77fcc
We have a function to register an IMSI but we're missing a function
to unregister it from RAN_Emulation. This will cause resource leaks
and eventually an overflow of the ImsiTable. We don't notice this yet
as we don't have long enough running tests in the test suite yet.
Change-Id: I1f5d86c999d4495d661166f98183dfbc48f05f47
TS 29.060 states that it shall be included for primary PDP context
activation if the information is available, so let's add it by default.
Change-Id: I8c7e491a07cadfe09403504a82d34e412673a531
This IE is conditionally added if the HLR provides it to the SGSN.
Let's add it by default so that we test code paths where GGSN parses it.
Related: SYS#5925
Change-Id: Ia0f74041d2107afeaa36b94e33474370b7b07c0e
This adds new tests:
* TC_cbsp_emerg_write_bts_cgi_noreplace
* TC_cbsp_emerg_write_bts_cgi_replace
* TC_cbsp_emerg_write_bts_cgi_kill
All of the above relate to improved / fixed handling of emergency
broadcasts in some corner cases.
Related: SYS#5906
Related: OS#5539, OS#5540
Change-Id: Ic0f0b3d620f3ca73bab3d45997d0c1b9433ac1f7
The list might be empty because either there were no broadcasts
completed in case of a CBS message, or because it was an emergency
message where this IE is never used.
Change-Id: I2b24ac7e5857bdd50a821399b3c383cea9d408ad
I used the construct like f_rnd_octstring(f_rnd_int(100)) in a number
of places to generate random-length packets with randomized length.
The problem I didn't realize is that f_rnd_int() of course can also
return '0', which would generate zero-length packets. This may be
permitted in some protocols, but it leads to problems e.g. when trying
to send a UDP packet of zero length (which the kernel will not do).
So let's introduce
* f_rnd_int_nonzero() for returning non-zero randomized integers
* f_rnd_octstring_rnd_len() for returning a random-length random payload
octet string
* replace all f_rnd_octstring(f_rnd_int()) call sites with the new
function.
Change-Id: I818a113ff8d2a2f7cab2ec7d9c8661607c6331d6
Closes: OS#5528
Release of 256 tuns + threads takes quite a reasonable amount of time.
Let's increase the timeout since reset_all_state can take around 10
seconds sometimes.
Related: OS#5523
Change-Id: Ie01e07bd698cb5c386f757f4ec315f4892ad61cb
An emergency call often comes with a Location Request. Make sure
osmo-bsc handles it well.
Related: SYS#5916
Change-Id: I95037374c45943cb14401bc48f16a39c2fcbe1f5
We don't really act as rely agents in the emulation, so let's not
announce it.
Furthermore, this aids libfreediameter selecting proper routes, since it
seems to only underscore peers not matching the AppId if they are not
rely agents (see dont_send_if_no_common_app() in freeDiameter.git)
Change-Id: I0a9daf094f4c27c0b4de5581ddd56feced8e5732
bsc-nat introduces a delay that will lead to failed tests, since the
reset attempt happens too early and times out, and the tests do not
retry.
Change-Id: I9f6db2a24e984eef31e76f9d42a80eb6a1bb6928
Philipp Maier
Neels Hofmeyr
Andreas Eversberg
Pau Espin
Oliver Smith
Harald Welte
Vadim Yanitskiy
Daniel Willmann
Eric Wild