The event FN contains the current FN, but the message should contain the
FN of the first burst of the block.
Change-Id: Iba0b1d1a3d7d875c5443a7bcaff399f9681624ad
As it turns out, it was a bad idea to use a counter in altstep
as_ta_ptcch(), because its value is getting lost. Let's instead
introduce a new type PTCCH_TAI_ToA_MAP, which is basically a
list of ToA values for each PTCCH/U sub-slot (TA Index), and
pass it to the altstep.
Change-Id: I74252dfb929fcb32d07e8728d692674931fae727
Both TDMA_EV_PTCCH_DL_BLOCK and TDMA_EV_PTCCH_UL_BURST events may
happen together during the same TDMA frame (fn % 104 == 90). We
shall not skip TDMA_EV_PTCCH_UL_BURST. Let's fix this.
Change-Id: Ifc66d5d1c5f9eaa7bed6882105298c45257ebef0
Unlike the circuit-switched domain, Uplink transmissions on PDCH time-slots
are not continuous and there can be long time gaps between them. This happens
due to a bursty nature of packet data. The actual Timing Advance of a MS may
significantly change between such rare Uplink transmissions, so GPRS introduces
additional mechanisms to control Timing Advance, and thus reduce interference
between neighboring TDMA time-slots.
At the moment of Uplink TBF establishment, initial Timing Advance is measured
from ToA (Timing of Arrival) of an Access Burst. This is covered by another
test case - TC_ta_rach_imm_ass. In response to that Access Burst the network
sends Immediate Assignment on AGCH, which _may_ contain Timing Advance Index
among with the initial Timing Advance value. And here PTCCH comes to play.
PTCCH is a unidirectional channel on which the network can instruct a sub-set
of 16 MS (whether TBFs are active or not) to adjust their Timing Advance
continuously. To ensure continuous measurements of the signal propagation
delay, the MSs shall transmit Access Bursts on Uplink (PTCCH/U) on sub-slots
defined by an assigned Timing Advance Index (see 3GPP TS 45.002).
The purpose of this test case is to verify the assignment of Timing Advance
Index, and the process of Timing Advance notification on PTCCH/D. The MTC
first establishes several Uplink TBFs, but does not transmit any Uplink
blocks on them. During 4 TDMA multi-frame periods the MTC is sending RACH
indications to the PCU, checking the correctness of two received PTCCH/D
messages (period of PTCCH/D is two multi-frames).
At the moment of writing, PTCCH handling is not implemented in OsmoPCU
(neither PTCCH/D messages are correct, nor PTCCH/U bursts are handled).
Additionally, this change introduces a new message type, which is used
for sending commands to the RAW components - RAW_PCU_Command. Commands
can be used to (re)configure components at run-time.
Change-Id: I868f78e3e95a95f8f2e55e237eea700d7d4726a3
Related: SYS#4606
The problem of existing test cases is that they mix IUT (i.e. OsmoPCU)
with OsmoBTS (osmo-bts-virtual) and OsmocomBB (virt_phy). This approach
allows to avoid dealing with TDMA clock indications and RTS requests on
the PCU interface - this is done by OsmoBTS. On the other hand, our test
scenarios may be potentially affected by undiscovered bugs in OsmoBTS
and the virt_phy.
In order to solve that problem, this change introduces a set of new
components and the corresponding handler functions:
- RAW_PCUIF_CT / f_PCUIF_CT_handler() - PCU interface (UNIX domain socket)
handler. Creates a server listening for incoming connections on a given
'pcu_sock_path', handles connection establishment and message forwarding
between connected BTS components (see below) and OsmoPCU.
- RAW_PCU_BTS_CT / f_BTS_CT_handler() - represents a single BTS entity,
connected to OsmoPCU through the RAW_PCUIF_CT. Takes care about sending
System Information 13 to OsmoPCU, forwarding TDMA clock indications from
a dedicated ClckGen component (see below), and filtering the received
messages by the BTS number. Implements minimalistic scheduler for both
DATA.ind and RTS.req messages, so they are send in accordance with the
current TDMA frame number.
- RAW_PCU_ClckGen_CT / f_ClckGen_CT_handler() - TDMA frame clock counter
built on top of a timer. Sends clock indications to the BTS component.
All components communicate using TTCN-3 ports and explicitly defined sets
of messages (see RAW_PCU_MSG_PT). One noticeable kind of such messages is
events (see RAW_PCU_Event and RAW_PCU_EventType). That's how e.g. the PCUIF
component can notify the BTS component that OsmoPCU has just connected, or
the BTS component can notify the MTC that SI13 negotiation is completed.
Events may optionally have parameters (e.g. frame-number for TDMA_EV_*).
Furthermore, the proposed set of components allows to have more than one
BTS entity, so we can also test multi-BTS operation in the future.
+-----+ +----------+ +---------+
| MTC +---------------+ PCUIF_CT +------+ OsmoPCU |
+--+--+ +----+-----+ +---------+
| |
| |
| |
| +-----------+ | +---------------+
+----+ BTS_CT #1 +------+ | ClckGen_CT #1 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #2 +------+ | ClckGen_CT #2 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #N +------+ | ClckGen_CT #N |
+-----+-----+ +-------+-------+
| |
+---------------------------+
Change-Id: I63a23abebab88fd5318eb4d907d6028e7c38e9a3
Pau Espin
Vadim Yanitskiy