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
Pau Espin Pedrol
Harald Welte
Pau Espin
Vadim Yanitskiy
Daniel Willmann