Change in osmo-ttcn3-hacks[master]: pcu: Introduce TC_ul_data_toolong_fills_padding

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/.

pespin gerrit-no-reply at lists.osmocom.org
Wed Jul 1 16:10:52 UTC 2020


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


Change subject: pcu: Introduce TC_ul_data_toolong_fills_padding
......................................................................

pcu: Introduce TC_ul_data_toolong_fills_padding

Change-Id: Ic37294efac005ed6c0ce48dea566fd20284b5868
---
M pcu/PCU_Tests.ttcn
1 file changed, 66 insertions(+), 0 deletions(-)



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

diff --git a/pcu/PCU_Tests.ttcn b/pcu/PCU_Tests.ttcn
index 3bad7d5..b6badc0 100644
--- a/pcu/PCU_Tests.ttcn
+++ b/pcu/PCU_Tests.ttcn
@@ -966,6 +966,71 @@
 	setverdict(pass);
 }
 
+function f_TC_ul_data_toolong_fills_padding_cs(inout GprsMS ms, CodingScheme cs, integer cv) runs on RAW_PCU_Test_CT {
+	var octetstring payload;
+	var template (value) RlcmacUlBlock ul_data;
+	var integer block_len, max_valid_data_len;
+	timer T;
+
+	block_len := f_rlcmac_cs_mcs2block_len(cs);
+	/* We need to send with TLLI since we are in One-Phase Access Contenion
+	 * resoultion), so that's -4 bytes of data, -3 for headers, -1 for LI
+	 * indicator, -1 for spare bits octet at the end */
+	max_valid_data_len := block_len - 4 - 3 - 1 - 1;
+	payload := f_rnd_octstring(max_valid_data_len + 1); /* +1 to write LLC data on last padding octet */
+	ul_data := t_RLCMAC_UL_DATA_TLLI(tfi := ms.ul_tbf.tfi,
+				    cv := cv,
+				    bsn := ms.ul_tbf.bsn,
+				    blocks := { t_RLCMAC_LLCBLOCK(payload,
+								  t_RLCMAC_LLCBLOCK_HDR(length_ind := lengthof(payload), more := false, e := true))
+					      },
+				    tlli := ms.tlli);
+	f_ultbf_inc_bsn(ms.ul_tbf);
+	f_ms_tx_data_ind(ms, enc_RlcmacUlBlock(valueof(ul_data)));
+
+	T.start(0.5);
+	alt {
+	[] BSSGP[0].receive(tr_BSSGP_UL_UD(ms.tlli, mp_gb_cfg.cell_id, ?)) {
+		setverdict(fail, "LLC PDU in Malformed RLC block was forwarded");
+		f_shutdown(__BFILE__, __LINE__);
+	}
+	[] T.timeout {
+		setverdict(pass);
+		}
+	}
+}
+/* Verify PCU finds out incorrectly formated RLC block and discards it. This
+   blocks intentionally contain last byte of data placed in last byte of RLC
+   containing padding/spare bits, which is incorrect. Spare bits exist and are
+   described for CS2..4 in 3GPP TS 44.060 Table 10.2.1: "RLC data block size,
+   discounting padding in octet" */
+testcase TC_ul_data_toolong_fills_padding() runs on RAW_PCU_Test_CT  {
+	var GprsMS ms;
+	var integer block_len, max_valid_data_len;
+
+	/* Initialize NS/BSSGP side */
+	f_init_bssgp();
+	/* Initialize GPRS MS side */
+	f_init_gprs_ms();
+	ms := g_ms[0]; /* We only use first MS in this test */
+
+	/* Initialize the PCU interface abstraction */
+	f_init_raw(testcasename());
+
+	/* Establish BSSGP connection to the PCU */
+	f_bssgp_establish();
+	f_bssgp_client_llgmm_assign('FFFFFFFF'O, ms.tlli);
+
+	/* Establish an Uplink TBF */
+	f_ms_establish_ul_tbf(ms);
+
+	f_TC_ul_data_toolong_fills_padding_cs(ms, CS_2, 2);
+	f_TC_ul_data_toolong_fills_padding_cs(ms, CS_3, 1);
+	f_TC_ul_data_toolong_fills_padding_cs(ms, CS_4, 0);
+
+	setverdict(pass);
+}
+
 /* Test scenario where MS wants to send some data on PDCH against SGSN and it is
  * answered, so TBFs for uplink and later for downlink are created.
  */
@@ -1953,6 +2018,7 @@
 	execute( TC_t3193() );
 	execute( TC_countdown_procedure() );
 	execute( TC_ul_all_sizes() );
+	execute( TC_ul_data_toolong_fills_padding() );
 	execute( TC_mo_ping_pong() );
 	execute( TC_mo_ping_pong_with_ul_racap() );
 	execute( TC_force_two_phase_access() );

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19097
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: Ic37294efac005ed6c0ce48dea566fd20284b5868
Gerrit-Change-Number: 19097
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200701/3ee2b4ae/attachment.htm>


More information about the gerrit-log mailing list