From 26cd244a9f355244029b1888d48290b11c971c88 Mon Sep 17 00:00:00 2001 From: Vadim Yanitskiy Date: Fri, 8 Nov 2019 05:39:06 +0700 Subject: [PATCH] PCU_Tests_RAW.ttcn: fix the expectations of TC_cs_lqual_ul_tbf As it turned out, OsmoPCU is not supposed to change the Coding Scheme immediately when the recent link quality value leaves the current window. Instead, in order to avoid rapid changes of the Coding Scheme, it also takes the previous value into account. Thus the current Coding Scheme is only changed if both current and old values fit into a new window. This change makes the test case pass. Change-Id: I5d503d5a9c46cb9de84fbabd2d591afbe4216fdb --- pcu/PCU_Tests_RAW.ttcn | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/pcu/PCU_Tests_RAW.ttcn b/pcu/PCU_Tests_RAW.ttcn index af1ef99d5..6a5f5d005 100644 --- a/pcu/PCU_Tests_RAW.ttcn +++ b/pcu/PCU_Tests_RAW.ttcn @@ -912,8 +912,11 @@ testcase TC_ta_ptcch_ul_multi_tbf() runs on RAW_PCU_Test_CT { tai6_ta := ?)); } -/* Default link quality adaptation (Coding Scheme) ranges: -/* CS1: ... 6 dB, CS2: 5 .. 8 dB, CS3: 7 .. 13 db, CS4: 12 ... dB */ +/* Default link quality adaptation (Coding Scheme) ranges (inclusive). + * OsmoPCU (VTY): cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 + * + * NOTE: the ranges are intentionally overlapping because OsmoPCU + * does not change CS/MCS on the range borders (5-6, 7-8, 12-13). */ private template integer CS1_lqual_dB_range := (-infinity .. 6); private template integer CS2_lqual_dB_range := (5 .. 8); private template integer CS3_lqual_dB_range := (7 .. 13); @@ -952,14 +955,22 @@ testcase TC_cs_lqual_ul_tbf() runs on RAW_PCU_Test_CT { /* HACK: patch missing TLLI; otherwise OsmoPCU rejects DATA.req */ ul_data.data.tlli := '00000001'O; - /* 16 UL blocks (0 .. 32 dB, step = 2 dB) */ + /* The actual / old link quality values. We need to keep track of the old + * (basically previous) link quality value, because OsmoPCU actually + * changes the coding scheme if not only the actual, but also the old + * value leaves the current link quality range (window). */ + var integer lqual := 0; + var integer lqual_old; + + /* 16 UL blocks (0 .. 15 dB, step = 1 dB) */ for (var integer i := 0; i < 16; i := i + 1) { /* Prepare a new UL block (CV, random payload) */ ul_data.data.mac_hdr.countdown := (15 - i); ul_data.data.blocks := { valueof(t_RLCMAC_LLCBLOCK(f_rnd_octstring(10))) }; - /* Link quality in dB and our CS1-4 expectations */ - var integer lqual := i * 2; + /* Update the old / actual link quality */ + lqual_old := lqual; + lqual := i; /* Enqueue DATA.ind (both TDMA frame and block numbers to be patched) */ log("Sending DATA.ind with link quality (dB): ", lqual); @@ -971,9 +982,11 @@ testcase TC_cs_lqual_ul_tbf() runs on RAW_PCU_Test_CT { log("Rx Packet Uplink ACK / NACK with Channel Coding Command: ", dl_block.ctrl.payload.u.ul_ack_nack.gprs.ch_coding_cmd); - /* Match the received Channel Coding Command */ + /* Match the received Channel Coding Command. Since we are increasing + * the link quality value on each iteration and not decreasing, there + * is no need to check the both old and current link quality values. */ var template ChCodingCommand ch_coding; - select (lqual) { + select (lqual_old) { case (CS1_lqual_dB_range) { ch_coding := CH_CODING_CS1; } case (CS2_lqual_dB_range) { ch_coding := CH_CODING_CS2; } case (CS3_lqual_dB_range) { ch_coding := CH_CODING_CS3; }