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
This config is out of sync with the one in docker-playground.git.
The 'neighbor resolution' param makes osmo-pcu use the CTRL interface.
Change-Id: I8d59096644afd5a5278bc7bb1335670edad72576
Related: OS#5901
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
Internal BVC components in BSSGP are now created as alive. We have to
create also BSSGP one as alive in order to avoid having the BVC
component sending stuff to the BSSGP when it has already been killed:
BSSGP_Emulation.ttcnpp:1133 Dynamic test case error: Sending data on the connection of port BVC to 486:BVC failed. (Broken pipe)
Change-Id: I369a5e2246204416c2f29a114bde6bc21f7eaf4f
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
Set the executable name in each regen_makefile.sh explicitly with -e,
instead of having it set indirectly from the first .ttcn file. Make it
consistent by placing the name on top of each of these files.
Fix for warning:
ttcn3_makefilegen: warning: File `BSC_Tests.ttcn' was given more than once for the Makefile.
Related: OS#5252
Change-Id: I5ed03f8f3ed905483620dc7bae33b617bbb8507f
Make all regen_makefile.sh more readable and diff friendly by moving
each entry in FILES and CPPFLAGS_TTCN3 into separate lines. Order
entries alphabetically.
Related: OS#5252
Change-Id: I6b6866eb9f6ec6232e4ae434517457a4c8c1c050
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
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Oliver Smith