In recent osmo-pcu commits, initial fn was changed to invalid value -1,
in order to be able to detect FN jumps. previously, the initial value
was set randomly to 0, which was wrong anyway because first FN received
from the BTS could be any other FN counted by the BTS at that time.
This makes some tests fail because they send RACH.ind + RTS.ind to
receive the Imm Assignment, and the Request reference in the Imm Assign
was calculated on the invalid unset FN "-1", hence it won't match test
expectancies.
In order to fix it, simply make sure the TDMA clock is initiated by
sending a DATA.ind to the PCU before tests start doing stuff
(f_init_raw() is blocked waiting for BTS_EV_SI13_NEGO).
Related: osmo-pcu.git Change-Id I29fb27981597edc69abb976049ba41aa840488cb
Related: OS#5020
Change-Id: I00c4dd9133ec9a236bf28fb8cb0afd0615791012
PCUIF will be updated to always send DATA.ind for each expected block FN
on any activated PDCH slot, irrespective of whether valid data was
received or not, similarly to what's done already for TRXDv1 NOPE.ind in
TRXD and TCH channels in OsmoBTS. The aim at this change is to be able to
track TDMA clock in an accurate way without hops, and hence be able to
detect on time whether expected UL blocks (SF, RRBP poll) didn't arrive.
Older osmo-pcu versions can cope well with this change, they will simply
print an error upon ach data_len=0 messages received and submit a GSMTAP
block, then discard it, so tests still pass.
Nevertheless, a new module parameter is added to disable this new
behavior in order to avoid logs and pcap files ending up clogged with
uneeded information until a new osmo-pcu release appears.
Related: OS#5020
Change-Id: Ib4f97a9bcfa68230945effeb6412218faa64ec78
All BSS-originated BVC-Reset for PTP BVC must contain a Cell Identifier.
This test is not respecting that rule
libosmogb correctly detects this and discards the RESET, which is not
what is intended here:
20210305120722368 DLBSSGP ERROR BSSGP BVCI=1235 Rx RESET missing mandatory IE (gprs_bssgp.c:392)
Change-Id: I57ebfc50befc47d0690021d73b52c504f0df4f9a
Related: OS#3879
Fixes: Iea5519b453dd544c5a78b3b16ddb5132d20cf67c
This test currently fails to pass in master osmo-pcu (and latest) due to
T3169 not being implemented exactly as per specs (due to limitations in
detecting lost UL blocks with assigned USF).
Related: OS#5033
Change-Id: I56177850f084cdaf4fcac63ebdcdff9cef4e7a5d
They are tested together since anyway in order to reach T3191 we need to
go through X2301 (IDLE TBF timeout).
Related: OS#3928
Change-Id: Ib6dfc5711b9c6f1fd404bce424bbf4b115fc930e
Sometimes the DL data may arrive too late to PCU and it may be requested
to tx before it arrives, hence the PCU will in that case schedule and
transmit a UL ACK/NACK instead of the expected DL data.
Change-Id: Iaee546e2021e86ca6da19ab73cc8d283a827a665
Since we have new releases in -latest, we don't need this param since
it's never set to true.
Related: OS~5042
Change-Id: Ic496407fd2139b3a5221c30f1798797320cdee24
It was previously disabled by default in order to avoid test breakage
with older versions of osmocom projects not supporting them. Since we
just did a new release, all -latest contian now master which should work
fine.
Don't remove the moduleparam yet in order to avoid breakage with some
cfg files in docker-playground.git still setting it to true.
Related: OS#5042
Change-Id: I4e2049c109986906d3c985ca2282174b1abff581
Triggers osmo-pcu assert in nacc_fsm.c due to scheduler not checking if
tbf has TFI assigned before deciding to transmit NACC related messages.
Related: osmo-pcu.git Change-Id I72b2dff28aacdb04909c098c94834ff79f55b31d
Related: SYS#4909
Change-Id: Id293e41e6b4380f2794007779ad430544bbe578a
These tests verify the NACC FSM adapts to MS restarting the NACC
procedure at any point when it selects for another tgt cell.
Related: SYS#4909
Change-Id: I42908a00f8d076e3559efde298a739d6b26d090e
These tests verify retransmission of duplicated Pkt Cell Change
Notification messages are ignored once the NACC procedure is already
ongoig.
Related: SYS#4909
Change-Id: Ib83eacfab7a73a2a51ab08801ff1c00c0058057c
Tests verify MS retransmitting a Pkt cell Chg Notif with different
target cell (hence a different NACC procedure) will be handled correctly
if PCU state was in the middle of handling a different NACC request.
Related: SYS#4909
Change-Id: I68c749aaabe9fe8272fc43045be09a46852359e5
Tests verify dup retrans triggered by MS timer are ignored if the target
cell is still the same (and hence no logic/behavior change is required,
current process can proceed onwards).
Related: SYS#4909
Change-Id: I00e8c1a63392bf8753f58f7d9d2d0e903ac5c529
Fixes:
warning: Inadequate restriction on the referenced template parameter
`chreq_desc', this may cause a dynamic test case error at runtime
Change-Id: I10b170c13aedc8abaaaf3b67d563ade8c3586c5b
There was a missing comma in the configuration as well the
indention was misaligned.
Related: OS#4953
Fixes: be7afce974 ("NS_Emulation: Respect data_weight==0 or signalling_weight==0")
Change-Id: I7f146ff71c107983e5787982970d0f6cd313cde9
We initialize those verbose structures over and over in different tests,
and we usually don't care about detials, only whether they enable EGPRS
or not.
So let's define them once and reuse them in tests whenever possible.
Some tests requiring specific values (eg to test allocation of 8 PDCH on
a single TBF) are left intact.
Change-Id: Id047929ad71dc7e330b09fd6cbfab2da43320fde
This is only a step towards a major set of changes.
This specific commit changes internal implementation of functions to stay
compatible with existing tests.
Later on, changes will be modified to use the new altsteps directly.
Related: OS#4927
Change-Id: Iecc33565fdc673e3499db12a0d4e0587290cfd45
This way tests can match directly on specific RLCMAC blocks, giving the
opportunity to handle different types using altsteps.
Before this, a user of the port could only receive a pcu_msg DATA_REQ
with a octetstring containing the rlcmac block, then decode it in a
second step when already in the alt step.
Related: OS#4927
Change-Id: Id8628e327d16c3a57e680e5a1ba0a2a8874f3a23
Perform a full RAN information request (single report) against the PCU
and check the results. Also test what happens when the request is issued
at a time where osmo-bts has no system information available.
Depends: osmo-pcu Id72118120c14984d2fb1b918b41fac4868150d41
Change-Id: I9054ab0e969c0fbfdc671c92d44cc61360959adc
Related: SYS#5103
Allow ignoring for received dumy packets while waiting for a Pkt Ass on
PACCH. This fixes some tests failing sometimes due to race condition
where rlcmac packet is requested too quicky, after the PCU has received
the BSSGP packet we sent to it.
The function is splitted into an internal altestep + a wrap function
which is compatible with tests already using it.
Related: OS#4779
Change-Id: I0a10d3a7383d8534e9263864b4130a96392e6198
* allow configuration of signalling + data weight for each NS-VC
* advertise per-NSVC signalling/data weight in SNS-CONFIG
* keep track of unblocked NS-VCS separately for data / signalling
* transmit BVCI=0 traffic only over signalling NS-VC
* transmit BVCI>0 traffic only over data NS-VC
* accept incoming BVCI=0 traffic only if signalling_weight > 0
* accept incoming BVCI>0 traffic only if data_weight > 0
Related: OS#4953
Change-Id: I9798e639b4bc8658482945970775b012b5840779
Previous RAW_NS only supported NS over UDP because
it handled the UDP connection on it's own.
Because of this there was no cleanup function for the tests
because no virtual component were started.
Using the new NS_Provider allows to use the same tests over
UDP and FR with no changes.
Change-Id: I8a3b6c72798a75f434f54229fdbfc802cd13967e
The BVC-RESETs are a little bit more complicated. The PCU will send
a BVC-RESET after the NSE become available.
Ensure the RESET is received and ignored so there is no race condition
if both sides send a BVC-RESET at the same time.
The test case TC_sns_1c1u_so_bvc_reset is still failing because the PCU can't
handle BVC-RESETs properly (both PTP and signalling).
Change-Id: Id681749d75073c1d50a4b0a2e86f0a2dd0955b45
Recent commit 7d0f9a0ec383fcfca934731bd6979b6be6629c90 in osmo-pcu.git
fixed situation where lots of unneeded LLC UI dummy frames where being
sent. As a result, osmo-pcu correctly counts less dl rlcmac payload
bytes being sent, so we must adjust our test expectancies.
Related: OS#4849
Change-Id: I01c34a0948094b17cc0d67e613cd9b756f78c372
For 12+ days, suspend/resume related SGSN + PCU TTCN3 tets have been failing.
It was the introduction of the BSSGP_CT:GLOBAL test port in
I40d973d80709f5d56f59247e8647b52754f09bc8 +
I805372f3024a0ec2491a24422e02c0bc6dc669d2 which caused the related PDUs
now to no longer show up where they used to.
Change-Id: I1977302fef4868dc1c330bc6f48f6a6608949393
Closes: OS#4902
When sending the SNS ADD in the test case the ip/port to add must be different
from the current NSVCs.
Fixes: 90f1974fb0 ("NS_Emulation: Support multiple NS-VC within one NSE (NS-VCG)")
Change-Id: I9bbbf1431468a452df324a7559518496e3eb48e3
LLC UI dummy frames are only to be sent alone in order to delay TBF
termination. Until recently (osmo-pcu.git
Ifae1a7b2b3dfad8df19585063088ba0df2749c8f), osmo-pcu was sending LLC UI
dummy frames instead of padding at RLCMAC layer, which made no sense.
Related: OS#4849
Change-Id: I7e0d9ed2475dbf989fbf932c8b83117ff5fb28fc
Since sending with the network-requested UL CS/MCS was implemented, CS-2
is being used in the test (since it's requested by the network during UL
Imm Ass). We used to send UL blocks with CS-1 prior to that, which means
we are sending a different amount of data, and hence the test
expectancies need to be updated.
Change-Id: Ie7112a96f5f2ca9c5bbd224b6270f55a338d101a
The existing BSSGP Code assumed that the TLLIs were always known "a
priori" by the test case. With the newly-introduced create_cb,
the user can provide a function to handle any incoming messages for an
unknown TLLL. The default handler behaves like before: fail +
terminate.
Change-Id: Ice0e145f5a6518ff79547dd851042b7965f38e00
This is something we need to simulate more complex scenarios,
particularly in the context of frame relay.
Change-Id: If1220852785853f8a5d8de183d5053ddd6ccb958
Previous commit implemented the CS/MCS verification, and hence now some
tests fail because they had too restrictive checks.
In theory the verifications could be done so restrictive by configuring
the PCU accordingly at the start of the test, but we are not
really interested in checking the exact CS/MCS in these tests, only
checking if GPRS/EGPRS is being used.
Change-Id: I79b81d473b7428b57a0ec501c5bd0d88e35c81e3
Once GPRS/EGPRS multiplexed support is ready, it will be controlled
through pcu info_ind.flags by enabling
MCS or not; the "egprs only" VTY comamnd will be dropped.
The usual setup would be to support both GPRS+EGPRS, so make that the default.
Most tests require to be passed the _noMCS variant to work in older
versions of PCU, since those versions use the "egprs only" concept which
will reject egprs_ms_class=0. Same tests enabling MCS in newer osmo-pcu
shouldn't be a problem.
Related: OS#4544
Change-Id: Ib95aae155b0712313a30f0c5404a8cb1f28b98f5
Similar to the DL TBF counterpart from last commit, this time verifying
UL multislot TBF is allocated.
Change-Id: I26a3cc0f2bd7bab176aa52df3e40aca7300de216
ARFCNs are allocated sequentially, so that conversion between
arfcn<->trx_nr is easily done.
Some helper functions are introduced to be able to submit and expect
messages on a given TRX+TS, which is required for setups with several
TRX and PDCH-enabled TS different than the default. These new APIs
will be used in PCU_Tests.ttcn in subsequent patches.
Change-Id: I28430e6d8c77d2b7dc630d186d425a5d82587b82
The change introduces three new test cases:
- TC_paging_cs_multi_ms_imsi,
- TC_paging_cs_multi_ms_tmsi,
- TC_paging_cs_multi_ms_imsi_tmsi.
Each of these establishes 56 Uplink TBFs, and then enqueues 56 CS
PAGING requests from the SGSN side. The main idea is to verify
encoding and compositing of the paging MIs in PACCH massages.
Change-Id: Ie8b4006f969598c9b0c452002d559f985d108a66
Related: OS#4838
In TTCN-3, array assumes a fixed number of elements. A 'record of'
type is more like a 'list' in Python, so let's call it this way.
Change-Id: Ib7df7efaa28a53a45d981d1c99f9eb1ac26fd91c
older versions of osmo-pcu were broken and were only allocating TBFs in
the first TRX available. This is now fixed and hence osmo-pcu tries
better to allocate TBFs across different TRX. That's why the test needs
to be fixed to set up only 1 TRX in order to run into the same scenario.
Change-Id: I3f6633950bb89dde3f87a237359497f5b23e0fee