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
Vadim Yanitskiy
Pau Espin
Daniel Willmann
Neels Hofmeyr