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.
Harald Welte