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
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
RAW_NS used previous a single TTCN3 port for a single UDP port
(source/listen side).
This has the limitation that only a single NSVC could be tested for a
local UDP port. However SNS tests require multiple NSVCs over a single UDP port.
NS_Provider_IPL4 already supports multiple NSVCs for the NS_Emulation.
Extend the support in NS_Provider_IPL4 to also allow RAW_NS to use
multiple NSVCs.
Related: OS#5036
Change-Id: Iafd9310e04066958914201da0cbdcd563bd5c976
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
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Oliver Smith
Neels Hofmeyr