A local tccn3 test run for VAMOS looks like:
while sleep 1; do osmo-bts-omldummy -f vamos 127.0.0.1 1234; done
osmo-stp
osmo-bsc -c osmo-bsc-vamos.cfg
make compile
make -j 5
../start-testsuite.sh BSC_Tests BSC_Tests_VAMOS.cfg
../log_merge.sh BSC_Tests --rm
Change-Id: Iabda4c864b02e6ddbf03386c75d67a37f92992f4
In BSC_Tests_VAMOS.ttcn, in f_est_and_reassign_to_secondary_lchan()
there is a missing channel release ack. By allowing ASP_RSL_UD, this rel
ack can be sent trivially.
Change-Id: Icd04184ed87c359349d86c5e0893c2ce9de2f7f1
BSC_Tests_VAMOS.ttcn is separate from BSC_Tests.ttcn in order to
instruct osmo-bts-omldummy to pass BTS_FEAT_VAMOS == true in the OML BTS
attributes.
Add tests:
TC_chan_act_to_vamos()
TC_mode_modify_to_vamos_fr()
TC_mode_modify_to_vamos_hr()
TC_assign_to_secondary_lchan_fr()
TC_assign_to_secondary_lchan_hr()
TC_vamos_multiplex_tch_f_tch_f()
TC_vamos_multiplex_tch_h_tch_h_tch_h_tch_h()
Change-Id: I2c504099163a30ea102cbd26d3615ca2e5ce1e64
In a recent osmo-bsc patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
c33eb8d56943b8981523754b081967e6ff5f245d
Ic665125255d7354f5499d10dda1dd866ab243d24
I accidentally changed the default behavior of the Training Sequence
Code sent to BTS and MS. So now, make sure that we verify the expected
Training Sequence Code in BSC_Tests, in:
RSL Channel Activate
RR Immediate Assignment
RR Assignment Command
RR Channel Mode Modify
RSL Mode Modify
Related: OS#5172 SYS#5315
Change-Id: Id67a949e0f61ec8123976eb8d336f04510c55c01
Without the SMLC routing in place, virtually all BSC_Tests fail with:
VirtSMLC-BSSAP_LE(8)@x42: setverdict(fail): none -> fail reason: "BSSMAP-LE: Timeout waiting for RESET-ACK after sending RESET"
Copy the SMLC part of osmo-stp.cfg from
docker-playground/ttcn3-bsc-test/osmo-stp.cfg and localhost-ize it.
Change-Id: I274515e7e9205c895cd250abed7361aef5a33f56
During f_create_chan_and_exp() (part of f_establish_fully()), announce
the BSSAP L3 expectation before activating the lchan.
In RSL_Emulation f_chan_est(), we go through Chan Request, Channel Act
and Immediate Assignment followed by EST IND. Right after that, osmo-bsc
sends a Complete Layer 3 on BSSAP. But in f_create_chan_and_exp(), we
only create the expectation of the BSSAP right after the call to
f_chan_est(), i.e. only after sending the EST IND. So far it was always
juuust in time to work, but when I added a little check to the end of
f_chan_est(), or alternatively an f_sleep(0.2), then BSC tests always
fail with:
Test case TC_reassignment_fr finished. Verdict: fail reason: Couldn't find Expect for incoming connection { [...] pdu := { bssmap := { completeLayer3Information... }
With the BSSAP expectation done first, this error is avoided.
Change-Id: I1d4af737dcc0f9c9fa6cdaff3a92813d532e730c
In a busy network, there can be a significant delay between resource
allocation (Packet Uplink Assignment above) and the actual time when
the MS is allowed to transmit the first Uplink data block.
Verify Timing Advance value indicated in Packet Uplink ACK/NACK message
sent in response to the first Uplink block after resource allocation.
Change-Id: I30f82c51b3e9a167af4dbce3e74697dd79ff15bf
The 'lqual_cb' represents the link quality in centiBels, which
can be negative. Use 'int16_t' instead of 'uint16_t'.
Change-Id: I038eec22928d831ddbc0a2704830d5e2eab2cb6b
The testcase TC_one_crcx_loopback_rtp_implicit triggers a bug in older
osmo-mgw version that eventually leads into a crash of osmo-mgw. This
also means that all tests after TC_one_crcx_loopback_rtp_implicit will
also fail. Lets move TC_one_crcx_loopback_rtp_implicit to the end of the
control section to postpone the crash to the very end of the testrun.
Change-Id: I25abf30f8c49e580c46e7a61e887bd0add9a4cd4
Related: OS#5123
Unfortunately, trxcon does not support handling more than one
connection in parallel. If there is already one connection
established, it would reject all other connection attempts.
This causes an error in f_handler_init(). As a quick hack,
let's allow running BTS_Tests.ConnHdlr components without
establishing L1CTL connections at all.
Change-Id: I72bcaed6c3803a0e18c9b787036a441e30c220cc
Related: SYS#4895, OS#4941
If an SGSN in a pool is down we expect the messages to instead be sent
to a different SGSN in the pool. That SGSN will not necessarily know
what to do with those messages, but it should )implicitly) detach that
UE so that it can reattach at the new SGSN. Otherwise UEs on a failed
SGSN would simply stop working as the messages would never be forwarded
anywhere.
This test also adjusts the NS timers so the failed NSVCs are detected
faster.
Change-Id: I46a6b8082441843f428a7681566228e5de375bcb
Related: OS#4952
osmo-bsc does now support intra-cell re-Assignment of lchans with active
voice. Test re-Assignment of TCH/F, triggered by VTY command.
Change-Id: I05fecefb9d6f9f23a0362f133170bca4da92e308
As announced in https://www.eclipse.org/forums/index.php/t/1107586/
TITAN is migrating both their github and git.eclipse.org repositories to
eclipse gitlab.
Let's adjust our Makefile accordingly
Change-Id: I6a501d50891c4fda78d33d3efd6030244a4aaf50
All msc tests involving classmarks suffer from the same problem: if a
existing subscriber is reused the old classmarks will stick, since the
msc only overwrites updated parts of the cm when receiving a new cm, so
"downgrading" the existing classmark information is not possible.
This is circumvented here here by using different imsi suffixes,
the last param passed to f_start_handler.
Additionally the handler will now properly respond to cm requests
by the msc, i.e. in case the early cm is not sufficient for a5/4
because it lacks cm3, so the msc attempts once to query the cm,
hoping to get a cm3.
Related: SYS#5324
Change-Id: Idc055a006b325f58a5eafa88bc4415181b3500a2
GTP_Templates.ttcn new templates use BssgpCellId, hence it depends on Osmocom_Gb_Types.ttcn.
Related: SYS#5314
Change-Id: I9dcf6ee2dc55bc6aba178eca30080233254f025e
The testcase TC_one_crcx_loopback_rtp_implicit uses
f_TC_one_crcx_loopback_rtp, which creates the RTP flow with IPv4
addresses but since we do not send a local RTP IP address with the CRCX
to the MGW, the MGW will prefer IPv6, which means that we get an IPv6
address back while the RTP strem is IPv4 on the TTCN3 side.
Related: OS#5123
Change-Id: I80498737d5b32f28b62e0c17cce1969b54af948c
This test verifies that libosmo-sccp will properly respond to SCCP
traffic that only has a SSN in the CallingPartyAddress. That situation
poses the unique challenge of how to route a response, as we lack
a GT and a PC to do the routing.
In order to support this, libosm-sccp now adds the PC into the
CallingPartyAddr when passing such messages from M3UA to SCCP. This
way the recipient can simply respond back to that address and it will
be routed on PC.
Change-Id: Ided599a922fb7f6dbbfe90f817c5419ab793f293
Related: OS#5146
Otherwise MS is not behaving correctly and newer versions of PCU (more
strict checking TLLI and behaving better) may not accept it and make the
test fail.
Related: OS#1940
Change-Id: I2efa5ce97bf2c82727efcbdebdc0a0b686664e12
Test what happens when the MGW gets a CRCX that creates a connection in
LOOPBACK mode but does not specify an RTP destination address. The MGW
is expected to deduct the destination address from the first incoming
RTP packet and loop it back to its originating address.
Change-Id: I7baf827fb0c3f33e13ccbaffd37ba0eb4e20c304
Related: OS#5123
Neels Hofmeyr
Vadim Yanitskiy
Philipp Maier
Daniel Willmann
Harald Welte
Eric Wild
Pau Espin