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
Since osmo-pcu.git 95ec50c9e4821ed1bdd15e9e30da1278ec1280c1, OsmoPCU
doesn't allow receiving a FINAL_ACK in FLOW state. This test was not
written properly and was taking advantage of that permissive logic in
osmo-pcu to trigger the target use case. Fix it to have the PCU send the
last DL data block (FBI=1) so that it can send a PKT DL ACK/NACK with
FinalAck=1 to terminate the DL TBF.
Change-Id: Ibd445bdd5cc1d1ffd810eea157829403b4b65f1f
N3105 is used for DL TBFs only (as tested by TC_n3105_max_t3195). The
test TC_ul_tbf_reestablish_with_pkt_resource_req_n3105_max is hence
wrongly written and should be based on T3168. Since recently, osmo-pcu
also moved to using T3168 in the scenario triggered by this test, hence
move to using it.
Related: osmo-pcu.git Change-Id I87dff68dedd06b60501e7586d20faf02bb1f0c93
Change-Id: Ibdfa9879cc56f5e2090cee0d3d70ee5df7c90454
The TC_nacc_outbound_pkt_cell_chg_notif_dup is currently failing
because in [1] we changed the default hard-coded MCC/MNC values in
ts_BssgpCellIdDstAddr_default, however these it's still using
hardcoded MCC=023/MNC=43. I overlooked this in [2].
Let's split up the f_handle_nacc_rac_ci_query() into four functions:
* f_ctrl_rx_nacc_rac_ci_req() / f_ctrl_tx_nacc_rac_ci_rsp(),
* f_pcuif_rx_nacc_rac_ci_req() / f_pcuif_tx_nacc_rac_ci_rsp(),
and use them in TC_nacc_outbound_pkt_cell_chg_notif_dup. Also
employ them in TC_nacc_outbound_pkt_cell_chg_notif_twice.
Change-Id: I3e84f55eedd278fb239600d6a0465bd34fd8cd0b
Related: [1] 03f74d4132
Fixes: [2] 7295661af5
Related: OS#5901
This patch fixes TC_nacc_outbound_si_resolve_timeout, which is still
using old hard-coded MCC/MNC values. The altstep does the same, but
relies on the updated values from ts_BssgpCellIdDstAddr_default.
Change-Id: I9f6dbe97e9a494a4e8fdb441a70999d3040f6cfd
Related: OS#5901
There is no such country/operator with MCC=023/MNC=43. Wireshark
complains about that when looking at the BSSGP messahes:
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
This may look confusing, let's better use some real country/operator:
Mobile Country Code (MCC): Central African Rep. (623)
Mobile Network Code (MNC): Celca (Socatel) (03)
Change-Id: Idc22128657d10893aa5c6d8ec80538a764de5c42
Related: OS#5901
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
It can happen that the RLCMAC req arrives at osmo-pcu before the
CS_PAGING we send to it over BSSGP, in which case osmo-pcu will schedule
an RLCMAC DL Dummy Block. Take into account this scenario to avoid
failing id it occurs.
Change-Id: I30da93835c7738aefcd84691d83f39759dd4b599
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: Icc94eb0544226facddcd65be65a8a41bcfc662cc
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: I67483bc423567d1fc98eb912ece1cf5cda746119
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state.
Change-Id: If7121473a3580b40d3a658dc38b9bb1421196127
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
This should prevent following race conditions at shutdown:
"""
131 - Terminating component type PCUIF_Components.RAW_PCU_BTS_CT.
...
PCUIF_Components.ttcn:642 Dynamic test case error: Sending data on the connection of port BTS to 131:PCUIF failed. (Broken pipe)
"""
Change-Id: I17b2cfed2edbea7427e608380059bb1b422ca600
The test was expecting to always receive at least 1 DL packet with
USF_UNUSED, but since we implemented idle blocks in PCUIF that may not
always be the case anymore. If the TBF is freed in between last
requested block and next one, there may be no TBF and hence no MS
listening on the TS, so PCU will optimize and send an idle block.
Change-Id: Ia301c01a3f5c3fd0b11d8f20e39061aa7abc6127
I cannot reproduce the issue in my local system with docker, probabluy
due to different performance from jenkins builder. It triggers almost
every time in jenkins nightly TTCN3 PCU_tests though.
A similar fix was already introduced recently for TC_n3105_max_t3195
since PCU started submitting empty (idle) blocks when there's no TBF
listening on that PDCH. We need to update the test to account for that,
since our TTCN3 timers are not necessarily exactly matching the one at
the PCU side.
Change-Id: Ia5344df15c612c70a6cdd7bb6f12dc7524a23bf4
Add two new tests to verify occupied and available PDCH stats if MS is
not known by the PCU.
Related: SYS#4878
Change-Id: Id21d4056a21b73ff612956700d2056d838eb54f8
Extend the test to verify that TTCN3.bts.0.pdch.occupied.gprs and
TTCN3.bts.0.pdch.occupied.egprs work as expected. These new stats are
needed for performance measurements in 3GPP TS 52.402 § B.2.1.54-55.
Related: SYS#4878
Depends: osmo-pcu I0c0a1121b4ae5f031782e7e63a0c28eb0b6c8b42
Change-Id: Ia98de17187810acb2e1b327c37beab79a0c211b8
Enable multiple TRX to verify that counters work as expected if the
allocator spreads TBFs over multiple TRX.
Related: SYS#4878
Change-Id: Ibde5be120e893fcecceb72a888483d5a6bb8ce50
New versions of osmo-pcu support Neighbor Address Resolution over this
interface, and deprecated the old CTRL interface.
Let's use it by default while still keeping support for the old one for
a while to avoid breakage of existing deployments.
Tests run to validate:
* Old osmo-pcu still passes tests using CTRL interface
* New osmo-pcu (with new iface support) still passes tests using CTRL
interface
* New osmo-pcu (with new iface support) passes tests using new iface
Related: SYS#4971
Change-Id: I05f1aabc64fc5bc4740b0d8afd8990b485eacd50
Test new stats bts.N.pdch.available/occupied, which count available
PDCHs (3GPP TS 52.402 § B.2.1.38) as well as occupied PDCHs
(§ B.2.1.42-44).
Related: SYS#4878
Related: osmo-pcu I74760a68ee055510a79e80854ec7bf1521669119
Change-Id: I607b4729740159c161af824317f9fc04878eb13d
Prepare to use this shared function in a new test with additional
commands between init, the function and shutdown.
Related: SYS#4878
Change-Id: I6fd523c7f5ab496b3356cf896a8ceaf9b6e874d2
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
Philipp Maier
Pau Espin
Vadim Yanitskiy
Oliver Smith