osmo-ttcn3-hacks/pcu/PCUIF_Components.ttcn

519 lines
16 KiB
Plaintext
Raw Normal View History

module PCUIF_Components {
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/*
* Components for (RAW) PCU test cases.
*
* (C) 2019 Vadim Yanitskiy <axilirator@gmail.com>
*
* All rights reserved.
*
* Released under the terms of GNU General Public License, Version 2 or
* (at your option) any later version.
*
* SPDX-License-Identifier: GPL-2.0-or-later
*/
import from IPL4asp_Types all;
import from UD_Types all;
import from PCUIF_Types all;
import from PCUIF_CodecPort all;
/* Component communication diagram:
*
* +-----+ +----------+ +---------+
* | MTC +---------------+ PCUIF_CT +------+ OsmoPCU |
* +--+--+ +----+-----+ +---------+
* | |
* | |
* | |
* | +-----------+ | +---------------+
* +----+ BTS_CT #1 +------+ | ClckGen_CT #1 |
* | +-----+-----+ | +-------+-------+
* | | | |
* | +---------------------------+
* | |
* | +-----------+ | +---------------+
* +----+ BTS_CT #2 +------+ | ClckGen_CT #2 |
* | +-----+-----+ | +-------+-------+
* | | | |
* | +---------------------------+
* | |
* | +-----------+ | +---------------+
* +----+ BTS_CT #N +------+ | ClckGen_CT #N |
* +-----+-----+ +-------+-------+
* | |
* +---------------------------+
*/
/* Events are used by the components to indicate that something
* has happened, e.g. we have got a connection from the PCU. */
type enumerated RAW_PCU_EventType {
/* Events related to RAW_PCUIF_CT */
PCU_EV_DISCONNECT, /*!< OsmoPCU has disconnected */
PCU_EV_CONNECT, /*!< OsmoPCU is now connected */
/* Events related to RAW_PCU_BTS_CT */
BTS_EV_SI13_NEGO, /*!< SI13 negotiation complete */
/* TDMA clock related events (TDMA frame-number in parameters) */
TDMA_EV_PDTCH_BLOCK_BEG, /*!< 1/4 bursts of a PDTCH block on both Uplink and Downlink */
TDMA_EV_PDTCH_BLOCK_END, /*!< 4/4 bursts of a PDTCH block on both Uplink and Downlink */
TDMA_EV_PTCCH_DL_BLOCK, /*!< 4/4 bursts of a PTCCH block on Downlink */
TDMA_EV_PTCCH_UL_BURST, /*!< One Access Burst on PTCCH/U */
TDMA_EV_PDTCH_BLOCK_SENT /*!< A PDTCH block has been sent to the PCU */
};
/* Union of all possible parameters of the events */
type union RAW_PCU_EventParam {
integer tdma_fn
};
type record RAW_PCU_Event {
RAW_PCU_EventType event,
/* TODO: can we use 'anytype' here? */
RAW_PCU_EventParam data optional
};
template (value) RAW_PCU_Event ts_RAW_PCU_EV(RAW_PCU_EventType event) := {
event := event,
data := omit
}
template RAW_PCU_Event tr_RAW_PCU_EV(template RAW_PCU_EventType event := ?,
template RAW_PCU_EventParam data := *) := {
event := event,
data := data
}
template (value) RAW_PCU_Event ts_RAW_PCU_CLCK_EV(RAW_PCU_EventType event, integer fn) := {
event := event,
data := { tdma_fn := fn }
}
template RAW_PCU_Event tr_RAW_PCU_CLCK_EV := {
event := (TDMA_EV_PDTCH_BLOCK_BEG, TDMA_EV_PDTCH_BLOCK_END,
TDMA_EV_PTCCH_DL_BLOCK, TDMA_EV_PTCCH_UL_BURST,
TDMA_EV_PDTCH_BLOCK_SENT),
data := { tdma_fn := ? }
}
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
/* Commands are mostly used by the MTC to configure the components
* at run-time, e.g. to enable or disable some optional features. */
type enumerated RAW_PCU_CommandType {
GENERAL_CMD_SHUTDOWN, /*!< Shut down component and all its child components */
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
TDMA_CMD_ENABLE_PTCCH_UL_FWD /*!< Enable forwarding of TDMA_EV_PTCCH_UL_BURST to the MTC */
};
type record RAW_PCU_Command {
RAW_PCU_CommandType cmd,
anytype data optional
};
template (value) RAW_PCU_Command ts_RAW_PCU_CMD(RAW_PCU_CommandType cmd) := {
cmd := cmd,
data := omit
}
template RAW_PCU_Command tr_RAW_PCU_CMD(template RAW_PCU_CommandType cmd := ?,
template anytype data := *) := {
cmd := cmd,
data := data
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* Generic port for messages and events */
type port RAW_PCU_MSG_PT message {
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
inout RAW_PCU_Command;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
inout RAW_PCU_Event;
inout PCUIF_Message;
} with { extension "internal" };
/* TDMA frame clock generator */
type component RAW_PCU_ClckGen_CT {
/* One TDMA frame is 4.615 ms long */
timer T_TDMAClock := 4.615 / 1000.0;
port RAW_PCU_MSG_PT CLCK;
var integer fn := 0;
}
/* Derive PTCCH/U sub-slot from a given TDMA frame-number */
function f_tdma_ptcch_fn2ss(integer fn) return integer
{
var integer ss := -1;
/* See 3GPP TS 45.002, table 6 */
select (fn mod 416) {
case (12) { ss := 0; }
case (38) { ss := 1; }
case (64) { ss := 2; }
case (90) { ss := 3; }
case (116) { ss := 4; }
case (142) { ss := 5; }
case (168) { ss := 6; }
case (194) { ss := 7; }
case (220) { ss := 8; }
case (246) { ss := 9; }
case (272) { ss := 10; }
case (298) { ss := 11; }
case (324) { ss := 12; }
case (350) { ss := 13; }
case (376) { ss := 14; }
case (402) { ss := 15; }
}
return ss;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
function f_ClckGen_CT_handler()
runs on RAW_PCU_ClckGen_CT {
var integer fn104, fn52, fn13;
while (true) {
fn104 := fn mod 104;
fn52 := fn mod 52;
fn13 := fn mod 13;
if (fn13 == 0 or fn13 == 4 or fn13 == 8) {
/* 1/4 bursts of a PDTCH block on both Uplink and Downlink */
CLCK.send(ts_RAW_PCU_CLCK_EV(TDMA_EV_PDTCH_BLOCK_BEG, fn));
} else if (fn13 == 3 or fn13 == 7 or fn13 == 11) {
/* 4/4 bursts of a PDTCH block on both Uplink and Downlink */
CLCK.send(ts_RAW_PCU_CLCK_EV(TDMA_EV_PDTCH_BLOCK_END, fn));
} else if (fn52 == 12 or fn52 == 38) {
/* 4/4 bursts of a PTCCH (Timing Advance Control) block on Downlink */
if (fn104 == 90) {
CLCK.send(ts_RAW_PCU_CLCK_EV(TDMA_EV_PTCCH_DL_BLOCK, fn));
}
/* One Access Burst on PTCCH/U (goes 3 time-slots after PTCCH/D) */
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
CLCK.send(ts_RAW_PCU_CLCK_EV(TDMA_EV_PTCCH_UL_BURST, fn));
}
/* TDMA hyperframe period is (2048 * 51 * 26) frames */
fn := (fn + 1) mod (2048 * 51 * 26);
/* (Re)start TDMA clock timer and wait */
T_TDMAClock.start;
T_TDMAClock.timeout;
}
}
type record of PCUIF_Message PCUIF_MsgQueue;
/* Enqueue a given message to the end of a given queue */
private function f_PCUIF_MsgQueue_enqueue(inout PCUIF_MsgQueue queue,
in PCUIF_Message msg)
{
queue := queue & { msg };
}
/* Dequeue the first message of a given queue */
private function f_PCUIF_MsgQueue_dequeue(inout PCUIF_MsgQueue queue,
out PCUIF_Message msg)
{
var integer len := lengthof(queue);
if (len == 0) {
setverdict(fail, "Failed to dequeue a message: the queue is empty!");
mtc.stop;
}
/* Store the first message */
msg := queue[0];
/* Remove the first message from queue */
if (len > 1) {
queue := substr(queue, 1, len - 1);
} else {
queue := { };
}
}
/* Get first message from queue. true if non-empty, false otherwise */
private function f_PCUIF_MsgQueue_first(inout PCUIF_MsgQueue queue,
out PCUIF_Message msg) return boolean
{
if (lengthof(queue) == 0) {
return false;
}
msg := queue[0];
return true;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* Multiple base stations can be connected to the PCU. This component
* represents one BTS with an associated TDMA clock generator. */
type component RAW_PCU_BTS_CT {
/* TDMA clock generator */
var RAW_PCU_ClckGen_CT vc_CLCK_GEN;
port RAW_PCU_MSG_PT CLCK;
/* Queues of PCUIF messages to be sent
* TODO: we may have multiple PDCH time-slots */
var PCUIF_MsgQueue pdtch_data_queue := { };
var PCUIF_MsgQueue pdtch_rts_queue := { };
var PCUIF_MsgQueue ptcch_rts_queue := { };
/* Connection towards the PCU interface */
port RAW_PCU_MSG_PT PCUIF;
/* Connection towards the test case */
port RAW_PCU_MSG_PT TC;
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
/* Whether to forward PTCCH/U burst events to the TC */
var boolean cfg_ptcch_burst_fwd := false;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
}
/* Queue received messages from Test Case, they will eventually be scheduled and
* sent according to their FN. FN value of 0 has the special meaning of "schedule
* as soon as possible". */
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
private altstep as_BTS_CT_MsgQueue(integer bts_nr)
runs on RAW_PCU_BTS_CT {
var PCUIF_Message pcu_msg;
/* Enqueue DATA.ind and RTS.req messages */
[] TC.receive(tr_PCUIF_MSG(PCU_IF_MSG_DATA_IND, bts_nr)) -> value pcu_msg {
f_PCUIF_MsgQueue_enqueue(pdtch_data_queue, pcu_msg);
repeat;
}
[] TC.receive(tr_PCUIF_RTS_REQ(bts_nr, sapi := PCU_IF_SAPI_PDTCH)) -> value pcu_msg {
f_PCUIF_MsgQueue_enqueue(pdtch_rts_queue, pcu_msg);
repeat;
}
[] TC.receive(tr_PCUIF_RTS_REQ(bts_nr, sapi := PCU_IF_SAPI_PTCCH)) -> value pcu_msg {
f_PCUIF_MsgQueue_enqueue(ptcch_rts_queue, pcu_msg);
repeat;
}
/* Forward other messages directly to the PCU */
[] TC.receive(tr_PCUIF_MSG(?, bts_nr)) -> value pcu_msg {
PCUIF.send(pcu_msg);
repeat;
}
}
/* Handle schedule events and manage actions: Send msgs over PCUIF to PCU,
* advertise Test Case about sent messages, etc. */
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
private altstep as_BTS_CT_TDMASched(integer bts_nr)
runs on RAW_PCU_BTS_CT {
var PCUIF_Message pcu_msg;
var RAW_PCU_Event event;
var integer ev_begin_fn;
var integer next_fn;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
[] CLCK.receive(tr_RAW_PCU_EV(TDMA_EV_PDTCH_BLOCK_BEG)) -> value event {
/* If the RTS queue for PDTCH is not empty, send a message */
if (lengthof(pdtch_rts_queue) > 0) {
f_PCUIF_MsgQueue_dequeue(pdtch_rts_queue, pcu_msg);
/* Patch TDMA frame / block number and send */
pcu_msg.u.rts_req.fn := event.data.tdma_fn;
pcu_msg.u.rts_req.block_nr := 0; /* FIXME! */
PCUIF.send(pcu_msg);
}
/* We don't really need to send every frame to OsmoPCU, because
* it omits frame numbers not starting at a MAC block. */
PCUIF.send(ts_PCUIF_TIME_IND(bts_nr, event.data.tdma_fn));
repeat;
}
[lengthof(pdtch_data_queue) > 0] CLCK.receive(tr_RAW_PCU_EV(TDMA_EV_PDTCH_BLOCK_END)) -> value event {
/* FN matching the beginning of current block: */
ev_begin_fn := event.data.tdma_fn - 3;
/* Check if we reached time to serve the first DATA.ind message in the queue: */
f_PCUIF_MsgQueue_first(pdtch_data_queue, pcu_msg);
next_fn := pcu_msg.u.data_ind.fn;
if (next_fn != 0 and next_fn != ev_begin_fn) {
if (next_fn < ev_begin_fn) {
setverdict(fail, "We are late scheduling the block! ", next_fn, " < ", ev_begin_fn);
mtc.stop;
}
repeat;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* Dequeue a DATA.ind message */
f_PCUIF_MsgQueue_dequeue(pdtch_data_queue, pcu_msg);
/* Patch TDMA frame / block number */
pcu_msg.u.data_ind.fn := ev_begin_fn;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
pcu_msg.u.data_ind.block_nr := 0; /* FIXME! */
PCUIF.send(pcu_msg); /* Send to the PCU and notify the TC */
TC.send(ts_RAW_PCU_CLCK_EV(TDMA_EV_PDTCH_BLOCK_SENT, ev_begin_fn));
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
repeat;
}
[lengthof(ptcch_rts_queue) > 0] CLCK.receive(tr_RAW_PCU_EV(TDMA_EV_PTCCH_DL_BLOCK)) -> value event {
/* FN matching the beginning of current block (PTCCH is interleaved over 4 non-consecutive bursts): */
ev_begin_fn := event.data.tdma_fn - 78;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* Dequeue an RTS.req message for PTCCH */
f_PCUIF_MsgQueue_dequeue(ptcch_rts_queue, pcu_msg);
/* Patch TDMA frame / block number and send */
pcu_msg.u.rts_req.fn := ev_begin_fn;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
pcu_msg.u.rts_req.block_nr := 0; /* FIXME! */
PCUIF.send(pcu_msg);
repeat;
}
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
/* Optional forwarding of PTCCH/U burst indications to the test case */
[cfg_ptcch_burst_fwd] CLCK.receive(tr_RAW_PCU_EV(TDMA_EV_PTCCH_UL_BURST)) -> value event {
TC.send(event);
repeat;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* Ignore other clock events (and guard against an empty queue) */
[] CLCK.receive(tr_RAW_PCU_CLCK_EV) { repeat; }
}
function f_BTS_CT_handler(integer bts_nr, PCUIF_info_ind info_ind)
runs on RAW_PCU_BTS_CT {
var PCUIF_Message pcu_msg;
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
var RAW_PCU_Command cmd;
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
var RAW_PCU_Event event;
/* Init TDMA clock generator (so we can stop and start it) */
vc_CLCK_GEN := RAW_PCU_ClckGen_CT.create("ClckGen-" & int2str(bts_nr)) alive;
connect(vc_CLCK_GEN:CLCK, self:CLCK);
/* Wait until the PCU is connected */
PCUIF.receive(tr_RAW_PCU_EV(PCU_EV_CONNECT));
alt {
/* Wait for TXT.ind (PCU_VERSION) and respond with INFO.ind (SI13) */
[] PCUIF.receive(tr_PCUIF_TXT_IND(bts_nr, PCU_VERSION, ?)) -> value pcu_msg {
log("Rx TXT.ind from the PCU, version is ", pcu_msg.u.txt_ind.text);
/* Send System Information 13 to the PCU */
PCUIF.send(PCUIF_Message:{
msg_type := PCU_IF_MSG_INFO_IND,
bts_nr := bts_nr,
spare := '0000'O,
u := { info_ind := info_ind }
});
/* Notify the test case that we're done with SI13 */
TC.send(ts_RAW_PCU_EV(BTS_EV_SI13_NEGO));
/* Start feeding clock to the PCU */
vc_CLCK_GEN.start(f_ClckGen_CT_handler());
repeat;
}
/* PCU -> TS becomes active */
[] PCUIF.receive(tr_PCUIF_ACT_REQ(bts_nr, ?, ?)) -> value pcu_msg {
log("Rx ACT.req from the PCU: TRX" & int2str(pcu_msg.u.act_req.trx_nr) &
"/TS" & int2str(pcu_msg.u.act_req.ts_nr));
repeat;
}
/* PCU -> TS becomes inactive */
[] PCUIF.receive(tr_PCUIF_DEACT_REQ(bts_nr, ?, ?)) -> value pcu_msg {
log("Rx DEACT.req from the PCU: TRX" & int2str(pcu_msg.u.act_req.trx_nr) &
"/TS" & int2str(pcu_msg.u.act_req.ts_nr));
repeat;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* PCU -> test case forwarding (filter by the BTS number) */
[] PCUIF.receive(tr_PCUIF_MSG(?, bts_nr)) -> value pcu_msg {
TC.send(pcu_msg);
repeat;
}
/* TC -> [Queue] -> PCU forwarding */
[] as_BTS_CT_MsgQueue(bts_nr);
/* TDMA scheduler (clock and queue handling) */
[] as_BTS_CT_TDMASched(bts_nr);
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
/* Command handling */
[] TC.receive(tr_RAW_PCU_CMD(GENERAL_CMD_SHUTDOWN)) {
log("Shutting down virtual BTS #", bts_nr, "...");
vc_CLCK_GEN.stop;
break;
}
PCU_Tests_RAW.ttcn: add a test case for continuous Timing Advance control 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
2019-10-04 10:12:35 +00:00
[] TC.receive(tr_RAW_PCU_CMD(TDMA_CMD_ENABLE_PTCCH_UL_FWD)) {
log("Enabling forwarding of PTCCH/U TDMA events to the TC");
cfg_ptcch_burst_fwd := true;
repeat;
}
[] TC.receive(tr_RAW_PCU_CMD) -> value cmd {
log("Ignore unhandled command: ", cmd);
repeat;
}
Introduce PCUIF, BTS and ClckGen components for RAW PCU test cases 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
2019-09-05 22:08:17 +00:00
/* TODO: handle events (e.g. disconnection) from the PCU interface */
[] PCUIF.receive(tr_RAW_PCU_EV) -> value event {
log("Ignore unhandled event: ", event);
repeat;
}
}
}
/* PCU interface (UNIX domain socket) handler */
type component RAW_PCUIF_CT {
var ConnectionId g_pcu_conn_id := -1;
var boolean g_pcu_connected := false;
port PCUIF_CODEC_PT PCU;
/* Connection towards BTS component(s) */
port RAW_PCU_MSG_PT BTS;
/* Connection to the MTC (test case) */
port RAW_PCU_MSG_PT MTC;
};
/* All received messages and events from OsmoPCU can be additionally sent
* directly to the MTC component. Pass direct := true to enable this mode. */
function f_PCUIF_CT_handler(charstring pcu_sock_path, boolean direct := false)
runs on RAW_PCUIF_CT {
var PCUIF_send_data pcu_sd_msg;
var PCUIF_Message pcu_msg;
timer T_Conn := 10.0;
log("Init PCU interface on '" & pcu_sock_path & "', waiting for connection...");
g_pcu_conn_id := f_pcuif_listen(PCU, pcu_sock_path);
/* Wait for connection */
T_Conn.start;
alt {
[not g_pcu_connected] PCU.receive(UD_connected:?) {
log("OsmoPCU is now connected");
/* Duplicate this event to the MTC if requested */
if (direct) { MTC.send(ts_RAW_PCU_EV(PCU_EV_CONNECT)); }
BTS.send(ts_RAW_PCU_EV(PCU_EV_CONNECT));
g_pcu_connected := true;
setverdict(pass);
T_Conn.stop;
repeat;
}
/* PCU -> BTS / MTC message forwarding */
[g_pcu_connected] PCU.receive(PCUIF_send_data:?) -> value pcu_sd_msg {
/* Send to the BTSes if at least one is connected */
if (BTS.checkstate("Connected")) { BTS.send(pcu_sd_msg.data); }
/* Duplicate this message to the MTC if requested */
if (direct) { MTC.send(pcu_sd_msg.data); }
repeat;
}
/* MTC -> PCU message forwarding */
[g_pcu_connected] MTC.receive(PCUIF_Message:?) -> value pcu_msg {
PCU.send(t_SD_PCUIF(g_pcu_conn_id, pcu_msg));
repeat;
}
/* BTS -> PCU message forwarding */
[g_pcu_connected] BTS.receive(PCUIF_Message:?) -> value pcu_msg {
PCU.send(t_SD_PCUIF(g_pcu_conn_id, pcu_msg));
repeat;
}
[not g_pcu_connected] MTC.receive(PCUIF_Message:?) -> value pcu_msg {
log("PCU is not connected, dropping ", pcu_msg);
repeat;
}
[not g_pcu_connected] BTS.receive(PCUIF_Message:?) -> value pcu_msg {
log("PCU is not connected, dropping ", pcu_msg);
repeat;
}
/* TODO: handle disconnect and reconnect of the PCU */
[] PCU.receive {
log("Unhandled message on PCU interface");
repeat;
}
[not g_pcu_connected] T_Conn.timeout {
setverdict(fail, "Timeout waiting for PCU connection");
mtc.stop;
}
}
}
}