Add a couple tests to validate some MGW pool features, like load
balancing and skip selection blocked MGWs from the pool.
Related: SYS#5987
Change-Id: I6a8c30309be406e37190dc67b6ee5af13e1b9e68
OsmoBSC has supported this VTY interface since more than a year ago.
Let's update the config files to use the new "mgw" node.
The recently submitted VTY commands without the redundant "mgw" prefix
are still not used here in order to have the config file work with
latest release which still doesn't support those.
Related: SYS#5987
Change-Id: I9b869e6bf4a3910f38014d570dce27e67af6e0d6
Previously the test was starting to count Osmux packets too early.
Now that osmux conn state has been improved in osmo-mgw [1], Osmux
Rx packets are not forwarded until the conn is completely configured
through MGCP, hence first osmux packets snet by our async emulation
are dropped.
So we must start counting the transmitted valid osmux packets according
to what the test says, when the full conn is set up.
[1] osmo-mgw.git Change-Id I7654ddf51d197a4107e55f4e406053b2e4a02f83.
Related: SYS#5987
Change-Id: I7efd87bbbda2ffa8fd0c5a64658d42edd0f30857
Since osmo-mgw.git 2177919edb3bc0dd308be388272486ffd97f4761, osmo-mgw can handle
properly conns containing a different remote and local CID.
Hence this hack can be dropped.
Related: SYS#5987
Change-Id: I531631d716581f68c11d3c0b07fc6755a822a0d3
Some tests require to match what's configured in osmo-mgw.
Let's make it possible to change it through a module parameter.
This will be needed for a follow-up patch to test >256 concurrent osmux
conns, which will require increasing the number of configured endpoints
above that value.
Change-Id: Ia1e5a0b59ba7c49e97c2cf7ee7a009f3827cf36d
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
Until now we forgot to properly configure the osmux socket local ip, but
that was fine because 0.0.0.0 was taken as a default.
With addition of IPv6, this changed, and the socket is not bound unless
an IP address is set (to allow conditional use of IPv4, IPv6 or both).
Depends: osmo-mgw.git Change-Id I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Change-Id: I4e0ea11ae7e55da600aec56bebf694f3ba0f7b72
in Diameter, the CC-Input/Output direction is defined as follows in
RFC4006:
"""
8.24. CC-Input-Octets AVP
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been received from the end user.
8.25. CC-Output-Octets AVP
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been sent to the end user.
"""
So:
* 3GPP uplink is from end user to PGW, and hence 'CC-Input-Octets'
* 3GPP downlink is to end user to PGW, and hence 'CC-Output-Octets'
This test started failing a few days ago since a bug was recently
fixed in open5gs which was swapping the counters in open5gs-upfd:
https://github.com/open5gs/open5gs/pull/1793f72a1edc6e
Change-Id: I2f64649ce70d85634f14b84eff98731f7711cbad
The RSL_IE_MultirateCfg was implemented and added to union RSL_IE_Body
in [1]. Before this change, this IE was decoded as RSL_LV (basically
an octetstring). Now this IE is decoded as RSL_IE_MultirateCfg, while
some AMR tests still expect RSL_LV. Let them use RSL_IE_MultirateCfg.
Change-Id: I40dab41d5dc5d14e358ba5a070ce174e7d8d4a4b
Fixes: [1] I0a5ddce570c0fd70f096d897b0b609d20b552ff7
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
Currently this testcase fails:
RSL MR CONFIG IE does not match expectation.
Expected: { other := { len := 2, payload := '2804'O } }
Change-Id: Icc5381eccb924803b1117b46d2b4c47cee6dabd7
This way it's easier to see that the only difference from other
tests using c_mr_conf_5_90 is the ICMI field set to false.
Change-Id: If7b491fa55a9366520c2d665a700c5badb187fae
* This is a global constant, so prefix with 'c_' for consistency.
* The RSL_IE_MultirateCfg is all about AMR, remove redundant 'amr'.
Change-Id: I72405b7139fcfd0dbe90afc469ed4db71b43a87c
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
There is no real need to pass the multi-rate parameters explicitly
in each invocation of ts_RSL_MultirateCfg. The exact multi-rate
configuration does not matter in scope of BTS specific tests.
Change-Id: I24117af8c5b7b11fe4b8f24fca5279ad97b46fab
The per-BTS VTY command 'osmux (on|off|only)' was added to osmo-bsc.git
recently, and is not available in -latest yet. Use it conditionally.
Change-Id: Id501d3f4b5eb18b096d8baffcb5f38e583f7a3d8
Fixes: I6e82eb9d995de988b812001e1c4cf6923509de66
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