ttcn3
/
osmo-ttcn3-hacks
mirror of https://gerrit.osmocom.org/osmo-ttcn3-hacks
10
0
Fork 1
Code Issues Releases Wiki Activity

PCU_Tests: new test case TC_ta_ul_ack_nack_first_block() 

In a busy network, there can be a significant delay between resource
allocation (Packet Uplink Assignment above) and the actual time when
the MS is allowed to transmit the first Uplink data block.

Verify Timing Advance value indicated in Packet Uplink ACK/NACK message
sent in response to the first Uplink block after resource allocation.

Change-Id: I30f82c51b3e9a167af4dbce3e74697dd79ff15bf
This commit is contained in:
Vadim Yanitskiy 2021-05-26 14:50:27 +02:00 committed by fixeria
parent 0d4e3cb070
commit 866f870b7a
1 changed files with 54 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
pcu/PCU_Tests.ttcn
View File

@ -496,6 +496,59 @@ testcase TC_ta_rach_imm_ass() runs on RAW_PCU_Test_CT {
f_shutdown(__BFILE__, __LINE__, final := true);
}
/* Verify Timing Advance value indicated in Packet Uplink ACK/NACK message
* sent in response to the first Uplink block after resource allocation. */
testcase TC_ta_ul_ack_nack_first_block() runs on RAW_PCU_Test_CT {
var GprsMS ms := valueof(t_GprsMS_def);
var PacketUlAckNack ul_ack_nack;
var PacketTimingAdvance pkt_ta;
var RlcmacDlBlock dl_block;
var uint32_t sched_fn;
/* Initialize NS/BSSGP side */
f_init_bssgp();
/* Initialize the PCU interface abstraction */
f_init_raw(testcasename());
/* Establish BSSGP connection to the PCU */
f_bssgp_establish();
f_bssgp_client_llgmm_assign(TLLI_UNUSED, ms.tlli);
/* Establish an Uplink TBF */
f_ms_establish_ul_tbf(ms);
/* In a busy network, there can be a significant delay between resource
* allocation (Packet Uplink Assignment above) and the actual time when
* the MS is allowed to transmit the first Uplink data block. */
/* Simulate a delay > 0 */
ms.ta := 2;
/* We're in One-Phase Access contention resoultion, include TLLI */
f_ms_tx_ul_data_block_multi(ms, 1, with_tlli := true, fn := ms.ul_tbf.start_time_fn);
f_rx_rlcmac_dl_block_exp_ack_nack(dl_block, sched_fn);
ul_ack_nack := dl_block.ctrl.payload.u.ul_ack_nack;
if (ispresent(ul_ack_nack.gprs.pkt_ta)) {
pkt_ta := ul_ack_nack.gprs.pkt_ta;
} else if (ispresent(ul_ack_nack.egprs.pkt_ta)) {
pkt_ta := ul_ack_nack.egprs.pkt_ta;
} else {
setverdict(fail, "PacketTimingAdvance IE is not present");
f_shutdown(__BFILE__, __LINE__);
}
if (not ispresent(pkt_ta.val)) {
setverdict(fail, "Timing Advance value is not present");
f_shutdown(__BFILE__, __LINE__);
} else if (pkt_ta.val != ms.ta) {
setverdict(fail, "Timing Advance mismatch: expected ",
ms.ta, ", but received ", pkt_ta.val);
f_shutdown(__BFILE__, __LINE__);
}
}
/* Verify Timing Advance value(s) indicated during the packet Downlink assignment
* procedure as per 3GPP TS 44.018, section 3.5.3. There seems to be a bug in the
* IUT that causes it to send an unreasonable Timing Advance value > 0 despite
@ -5850,6 +5903,7 @@ control {
execute( TC_pcuif_suspend_active_tbf() );
execute( TC_ta_ptcch_idle() );
execute( TC_ta_rach_imm_ass() );
execute( TC_ta_ul_ack_nack_first_block() );
execute( TC_ta_idle_dl_tbf_ass() );
execute( TC_ta_ptcch_ul_multi_tbf() );
execute( TC_cs_lqual_ul_tbf() );