There's some offset between Tx and Rx path, so we need to account for
differences counting and finding out USF blocks didn't arrive.
Change-Id: I868e7d24c8bdc9b85797f8fe4f9ee1bc5a3d1adb
Also change a bit expectations, since it can actually happen that DL
blocks for GPRS-only MS never signal USF for itself, which is
still fine.
Change-Id: Iedff87cedf55ab18b32bd0f159d1145901878203
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
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
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
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
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
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
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
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
Otherwise those test cases may sporadically fail due to DTE:
Sending data on the connection of port CLCK to 8:CLCK failed. (Broken pipe)
Change-Id: Ia8c934697a4e7bc39e762bf81587fea3bbe11b17
This change reproduces a segfault caused by the recent regression [1].
The IUT tries to bind on BSSGP host:port that it's already bound to.
[1] Ib389925cf5c9f18951af6242c31ea70476218e9a
Change-Id: I4c3bc883d795e5d1ee5ab175ac03684924692a7c
Related: SYS#5108
The existing BSSGP_Emulation is built around the assumption that every
instance of BSSGP_Emulation only servers one signaling-BVC and one
PTP-BVC. While this is true for osmo-pcu at this point (BTS-colocated
PCU), other BSS/PCU implementations differ.
In general, there can always be any number of PTP BVC (one per cell)
next to the signaling BVC (one per BSS). Let's represent this in
BSSGP_Emulation so we can create more comprehensive tests.
Change-Id: I7e30b4c4e188518a574e082962fba457b3a97ce3
NSConfiguration currently contains parameters relevant only for IP
based transport. Move IP/UDP parameters into a sub-structure in
anticipation of Frame Relay support.
Change-Id: I6904520d8c2f546327029777d68b1907611a8cf5
The dependency of PCUIF_Types creates also a dependency on
Replace the PCU_AddrType by an unix like address family defined
in the Osmocom_Types to reduce the dependency.
Change-Id: I0b4fda96accef401ffc009010f9f5621583fd6dd
My initial assumption was that we can skip redundant '0'B bits or
even '00'O octets in the Mobile Allocation IE, and thus reduce
the overall size of this element. Unfortunately, this is wrong.
3GPP TS 44.018, section 10.5.2.21 clearly states that the Mobile
Allocation IE contains a bit-string of size NF, where NF is the
number of frequencies in the cell allocation. If NF % 8 != 0,
then '0'B padding bits must be appended to make it octet-aligned.
In other words, if the cell allocation contains let's say 13
frequencies, but a hopping timeslot makes use of only a small
fraction of it (e.g. 4 first channels), we would still need to
transmit at least 13 bits (+padding), including all redundant
bits and octets.
In RLC/MAC frames though it's not required to make the bit-string
octet aligned, so we need to send exactly NF bits without padding.
In order to achieve that:
a) add MA length field to INFO.ind (record PCUIF_InfoTrxTs);
b) ajust the existing test cases to use this field.
It's safe to merge this change as the related patches have not
been merged to osmo-pcu and osmo-bts yet.
Change-Id: I2709673c90a0cd7d76de9db8b8ad82ac59ca84a0
Related: SYS#4868, OS#4547
osmo-pcu.git 0052051c07af63da98137c9f8e3b3119642eb587 introduced a bug
(fixed in 1d68cdff928f32941aff36c70e4543203c283d15) where no MS could
GMM attach to the network, but no test showed the issue.
This couple test verifies both correct behavior and also ensures wrong
IMSI is detected and reported.
Related: OS#4729
Change-Id: I5072d80b7ed9945a6083cdf3254efb8b8f119c54
This change introduces new version 10 specific extensions, in
particular: the frequency hopping parameters of each timeslot.
These parameters are used to compose Channel Description IE
in the packet resource assignment messages.
In order to maintain backwards compatibility with version 9 of
the PCUIF, and thus to still be able to run test cases against
the latest release of osmo-pcu, I kept the old parts of the
INFO.ind and gruoped them together with the new records
into union 'PCUIF_InfoTrxs'.
During decoding, the content of this union is resolved by the
TITAN's RAW codec itself, depending on value of the 'version'
field. During the encoding, it's the responsibility of the
API user to set a proper field of the union. I implemented
both f_PCUIF_ver_INFO_{Trxs,PDCHMask} helpers for that.
Version 9 is kept as default, so this change can be merged
independently of the actual implementation. We can bump
it and remove the compatibility glue once the new versions
of both osmo-bts and osmo-pcu are released.
Change-Id: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4547
Immediate Assignment is sent on AGCH/PCH, while on PACCH we have
Packet Uplink/Downlink Assignment instead (see 11.2.29, 11.2.7).
Change-Id: I56473ae5dfa565d2c9d26984b14685a4163bf69a
When changing the PCUIF, we have to maintain backwards compatibility
with the release versions of both osmo-pcu and osmo-bts, not only
with the recent master. In order to achieve that, let's introduce
'mp_pcuif_version', so the PCUIF version can be adjusted.
Change-Id: I3cf7f908e606b91dd2cbddc168827dd074aed052
Related: SYS#4868, OS#4547
Fix confusion: f_ms_establish_ul_tbf() vs f_establish_tbf(). The
new name precisely describes what the function does. Sending a
RACH.ind and receiving a DATA.req with RR Immediate Assignment
is just a part of the TBF establishment process.
Change-Id: I1e22b9936bf68ebcaf70cefbc57345995ebbbaed
I noticed that TC_egprs_pkt_chan_req_reject_exhaustion has started
to fail since the refactoring change [1]. As it turned out, this
test case does not init a GprsMs instance, which is needed by a
function it depends on - f_TC_egprs_pkt_chan_req().
I don't really see the point of using the GprsMs abstraction for
such small test cases sending just a few messages, which do not
require us to keep any state. Let's just revert those changes,
and keep using the low level API.
[1] Ib3fee37580f0ea0530a659dec83656799bf57288
Change-Id: I4f32c138e7587e68d2d35d13d13c044893fec4b2
Let's test the code path where UL TBF is requested through DL ACK/NACK
here, since we already test the usual UL TBF through CCCH approach in
most tests.
rlc_mode is changed to ACKED since that's the mode we are using so far
in tests.
Change-Id: I5a9a2e8107c87fdbf74cc2f09ae5eeafbb13ad55
Both f_ms_rx_imm_ass_ccch() and f_ms_establish_ul_tbf() functions
are actually twin brothers of good old f_pcuif_rx_imm_ass() and
f_establish_tbf() with some minor changes.
The former accepts a GprsMS parameter, that is never used. The
latter simply calls f_ultbf_new_from_rr_imm_ass() in the end.
Let's avoid code duplication:
- call f_establish_tbf() from f_ms_establish_ul_tbf(),
- remove f_ms_rx_imm_ass_ccch(), use f_pcuif_rx_imm_ass().
After the removal of f_ms_rx_imm_ass_ccch(), the implementation
of TC_ta_idle_dl_tbf_ass() does not need the GprsMS state, so
let's make it look like it was before.
Change-Id: If6c0b8796500e96525b7b1cadb61ab2fc84b4744
Before this patch, each test had to somehow keep state for all the
transactions needed. Now, most of the state is moved to generic GprsMS,
UlTbf and DlTbf structures, and APIs to maintain its state, as well as
function helpers to submit or receive messages from it. For now
specially the Tx side was improved, some of the Rx parts are left for
later and are still using the old APIs.
This will allow for more complex scenarios and more complex tests
running several MS.
All the tests were updated to use the new APIs, reworked when needed and
even totally rewritten in some cases since they were doing
inconsistent/wrong stuff from the point of view of what the scenarios
or code paths they were expected to test. There's no test regressions.
Change-Id: Ib3fee37580f0ea0530a659dec83656799bf57288
Pau Espin
Vadim Yanitskiy
Pau Espin Pedrol
Philipp Maier
Harald Welte
Daniel Willmann