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

1 files changed, 54 insertions, 0 deletions

diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 3d374d0b..8e8fba9b 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -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() );