Change in osmo-ttcn3-hacks[master]: PCU_Tests: new test case TC_ta_ul_ack_nack_first_block()

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

fixeria gerrit-no-reply at lists.osmocom.org
Wed May 26 13:24:56 UTC 2021


fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/24417 )


Change subject: PCU_Tests: new test case TC_ta_ul_ack_nack_first_block()
......................................................................

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
---
M pcu/PCU_Tests.ttcn
1 file changed, 54 insertions(+), 0 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/17/24417/1

diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 3d374d0..a8b809a 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -496,6 +496,59 @@
 	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 random TA in range 8..16 */
+	ms.ta := 8 + f_rnd_int(9);
+
+	/* 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 @@
 	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() );

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/24417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I30f82c51b3e9a167af4dbce3e74697dd79ff15bf
Gerrit-Change-Number: 24417
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210526/d838883c/attachment.htm>


More information about the gerrit-log mailing list