In some cases GsmArfcn itself is not enough. It case of L1CTL
and GSMTAP, it needs to be equipped with a band discriminator:
- DCS / PCS (as the numbers may overlap),
- Downlink / Uplink (not yet there).
Let's rename this record and move it to GSM_Types. Also, add
send / receive tamplates, so we can add new fields later.
Change-Id: I7a63f03bbd15a06caafb786122dc12991d115771
This in turn means Osmocom_Gb_Types doesn't need to depend on
GSM_RR_Types anymore, which is particularly ugly as the latter
now depends on RLCMAC_*, creating a long chain of dependencies.
Change-Id: I8c8da7709695ff0023f71b3999291e2515b22e46
This test case is aimed to verify handling of both PTCCH/U and
PTCCH/D logical channels, recently implemented in [1]. This is
done by sending 16 Access Bursts on PTCCH/U, and then by
sending a random data block on PTCCH/D.
The existing TC_pcu_data_req_ptcch does not cover PTCCH/U, and
moreover involves TBF handling which has nothing to do with
PTCCH. Let's keep it anyway.
[1] I232e5f514fbad2c51daaa59ff516004aba97c8a3
Change-Id: I011ffdfa63b698ce6085968d15ffb4ff4bd23ee5
Related: OS#4102
Bring our TTCN-3 view of how RSL channel numbers are defined in sync
with that of our other implementations (BTS, libosmocore, trxcon, ...)
Change-Id: I48908058ac2501a3b5ae7c74e4e8527cbaee1b01
Related: OS#4027
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
This will prevent subsequent failures from overwriting the verdict so we
can easily see the root cause of the test failure.
Using testcase.stop instead for errors internal to our test
infrastructure to mark them as test errors instead of failed.
Change-Id: Idc6819aaf0b01e70c38fad828dd44dcec6bdd778
This test case checks on each logical channel if the DEACT SACCH RSL
message actually deactivates downlink SACCH as expected.
Change-Id: Id8219ffce0635071cb50669b89368de51fe82843
We're testing at 80% and 200% of PCH capacity, both for either IMSI-only
or TMSI-only paging requests. The way how we test ensures:
* the expected number of paged mobile identities end up on the Um interface
* we implicitly check the queuing limit of 200 paging records by
overflowing it in the 20-seconds-of-200%-load cases
* we implicitly check the batching of mobile identities into different
paging types
* we test the PCH load reporting over RSL
As a side note, in case you were ever wondering what's the expected
paging throughput / capacity, there are now helper functions to compute
it. For our combined CCCH/SDCCH4, it's about 16 IMSIs per second or
about 32 TMSIs per second.
Change-Id: I0b80b72bdab3d80d915296d70e1174623fbd8610
It's a quite frequent requirement in encoding IMSI/BCD numbers, so
let's move it to the more generic GSM_Types module.
Change-Id: I6fb8d9a6f37c990f6901fb48b15312a157954fda
For Downlink and Uplink RLC/MAC Control blocks this is already working
quite nicely. Data blocks is not working, as their encoding cannot be
expressed in TTCN-3 RAW syntax, and a mixture of C++/native and
RAW-generated coder will be required.
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy
Harald Welte
Daniel Willmann