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
The template restrictions are quite useful, becaue they give hints
to the TTCN-3 compiler, so it can spot more bugs. For example,
the lack of thereof would not prevent one from passing 'omit' to
a template, that assigns a value to a non-optional field, so that
might lead to a DTE at run-time in some cases.
Since adding 'template (restriction) ' to each template parameter
obviously makes templates look more cumbersome, let's move the
part with template name and arguments onto a separate line, just
like it's sometimes done for function definitions in C.
Change-Id: I7e6846381e0b3fb611059fcfbafb19bd6c15cfd8
Calypso PHY (unlike trxcon) needs to be explicitly configured to
enable forwarding of the TCH traffic. Otherwise it's handled
internally by the DSP and routed to/from the built-in speaker/mic.
Change-Id: I5b9ca5683627716868e85dc33f91d8ca4824cd61
Related: OS#4799
A TRAFFIC.ind with 'num_biterr' > 0 or 'fire_crc' != 0 is still
a valid TCH frame - Bad Frame Indication. Let's relax those
parameters for tr_L1CTL_TRAFFIC_IND().
Change-Id: Ia3357e06f986ae59dd0438f9ace3042cae8d3684
Related: OS#4799
In osmocom-bb 'struct l1ctl_dm_est_req' is defined as follows:
struct l1ctl_dm_est_req {
uint8_t tsc;
uint8_t h;
union {
struct l1ctl_h0 h0;
struct l1ctl_h1 h1;
},
uint8_t tch_mode;
uint8_t audio_mode;
} __attribute__((packed));
so the overall size of the union is size of the biggest member:
sizeof(struct l1ctl_h0) is 2
sizeof(struct l1ctl_h1) is 132
Therefore we need to fix our definitions:
- introduce 'record L1ctlH0' (with padding),
- introduce 'union L1ctlH0H1':
- move hopping indicator to L1ctl{H0,H1},
- use it as 'TAG' in 'union L1ctlH0H1'.
Change-Id: I53964f794260f0676cc2771a7acbb679befb06d5
Related: OS#4799
- Get rid of f_L1CTL_DM_EST_REQ, it's not really needed.
- Derive ts_L1CTL_DM_EST_REQ_H0 from ts_L1CTL_DM_EST_REQ.
- Turn all its params into (value) templates.
- Turn it into a (value) template itself.
- Pass GsmArfcn directly to ts_L1CTL_DM_EST_REQ_H0.
Change-Id: I4f275e22d4309a23b4ed301a0779c4ecb92023a8
Related: OS#4546
Get rid of template t_IMM_ASS, which is a part of L1CTL_Types.ttcn.
Prepare generic (for both CS and PS) template on top of tr_IMM_ASS,
and use it in f_L1CTL_WAIT_IMM_ASS().
Change-Id: I3a410ec3c41e3eefd23071bfb0d80feda82177a5
In BTS_Tests.ttcn we used to compose L1ctlDataReq manually. This
can be done by ts_L1CTL_DATA_REQ_SACCH() template itself, so
let's abstract BTS_Tests.ttcn from doing that.
Change-Id: I1ae948bd0314cdf15c21ce4b6346d5e32f1fcf95
In the existing TC_pcu_* test cases we use L1CTL_DATA_* messages
to send / receive (E)GPRS related MAC-blocks. The length of such
blocks can be greater than 23 octets (i.e. fixed MAC-block
length in GSM), up to 162 octets to be precise.
Change-Id: Iced78796882b757016d02a266d55bc2a98b62a3d
In OsmocomBB/trxcon Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
we introduced a new mode CCCH_MODE_COMBINED_CBCH to indicate that the
channel combination is a CCCH+SDCCH/4 with one SDCCH stolen for CBCH.
Let's make sure we actually use that mode in our CBCH related tests
Change-Id: I27ee2c81bec7175c1ea09d4f3f6037f2866fe242
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
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit)
Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS
capability. One of the alternative synch. sequences (see 3GPP TS
05.02, TS1 and TS2) shall be used.
Change-Id: If037cb2f2687697f168d10a033eeb20d20183328
Related: OS#1854
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
Vadim Yanitskiy
Vadim Yanitskiy
Harald Welte
Pau Espin