Change in osmo-bts[master]: TA loop: Take into account UL SACCH 'Actual Timing advance' field

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
Mon Sep 13 13:34:22 UTC 2021


pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/25386 )

Change subject: TA loop: Take into account UL SACCH 'Actual Timing advance' field
......................................................................

TA loop: Take into account UL SACCH 'Actual Timing advance' field

First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.

The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink  channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the  previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)

This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.

Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
---
M include/osmo-bts/ta_control.h
M src/common/l1sap.c
M src/common/measurement.c
M src/common/ta_control.c
M tests/ta_control/ta_control_test.c
5 files changed, 74 insertions(+), 28 deletions(-)

Approvals:
  Jenkins Builder: Verified
  osmith: Looks good to me, but someone else must approve
  pespin: Looks good to me, approved



diff --git a/include/osmo-bts/ta_control.h b/include/osmo-bts/ta_control.h
index 168f14a..bf99331 100644
--- a/include/osmo-bts/ta_control.h
+++ b/include/osmo-bts/ta_control.h
@@ -2,4 +2,4 @@
 
 #include <osmo-bts/gsm_data.h>
 
-void lchan_ms_ta_ctrl(struct gsm_lchan *lchan);
+void lchan_ms_ta_ctrl(struct gsm_lchan *lchan, uint8_t ms_tx_ta, int16_t toa256);
diff --git a/src/common/l1sap.c b/src/common/l1sap.c
index e9d58ce..92abbff 100644
--- a/src/common/l1sap.c
+++ b/src/common/l1sap.c
@@ -53,6 +53,7 @@
 #include <osmo-bts/bts_model.h>
 #include <osmo-bts/handover.h>
 #include <osmo-bts/power_control.h>
+#include <osmo-bts/ta_control.h>
 #include <osmo-bts/msg_utils.h>
 #include <osmo-bts/pcuif_proto.h>
 #include <osmo-bts/cbch.h>
@@ -1604,6 +1605,7 @@
 			rsl_tx_meas_res(lchan, NULL, 0, le);
 
 			radio_link_timeout(lchan, true);
+			lchan_ms_ta_ctrl(lchan, lchan->rqd_ta, lchan->meas.ms_toa256);
 			lchan_ms_pwr_ctrl(lchan, lchan->ms_power_ctrl.current, data_ind->rssi, data_ind->lqual_cb);
 		}
 		return -EINVAL;
@@ -1632,6 +1634,19 @@
 		lchan->meas.l1_info.ta = l1_hdr->ta;
 		lchan->meas.flags |= LC_UL_M_F_L1_VALID;
 
+		/* 3GPP TS 45.008 sec 4.2: UL L1 SACCH Header contains TA and
+		 * MS_PWR used "for the last burst of the previous SACCH
+		 * period". Since MS must use the values provided in DL SACCH
+		 * starting at next meas period, the value of the "last burst"
+		 * is actually the value used in the entire meas period. Since
+		 * it contains info about the previous meas period, we want to
+		 * feed the Control Loop with the measurements for the same
+		 * period (the previous one), which is stored in lchan->meas(.ul_res): */
+		lchan_ms_ta_ctrl(lchan, l1_hdr->ta, lchan->meas.ms_toa256);
+		/* FIXME: lchan_ms_pwr_ctrl() is currently being passed data_ind->lqual_cb, which is wrong because:
+		 * 1- It contains measurement data for 1 SACCH block only, not the average over the entire period
+		 * 2- It contains measurement data for *current* meas period, not *previous* one.
+		 */
 		lchan_ms_pwr_ctrl(lchan, l1_hdr->ms_pwr, data_ind->rssi, data_ind->lqual_cb);
 		lchan_bs_pwr_ctrl(lchan, (const struct gsm48_hdr *) &data[5]);
 	} else
diff --git a/src/common/measurement.c b/src/common/measurement.c
index 4c49dc9..a4cc668 100644
--- a/src/common/measurement.c
+++ b/src/common/measurement.c
@@ -10,7 +10,6 @@
 #include <osmo-bts/measurement.h>
 #include <osmo-bts/scheduler.h>
 #include <osmo-bts/rsl.h>
-#include <osmo-bts/ta_control.h>
 
 /* Tables as per TS 45.008 Section 8.3 */
 static const uint8_t ts45008_83_tch_f[] = { 52, 53, 54, 55, 56, 57, 58, 59 };
@@ -739,11 +738,6 @@
 
 	lchan_meas_compute_extended(lchan);
 
-	/* Compute new ta_req value. This has to be done here since the value
-	 * in lchan->meas.num_ul_meas together with lchan->meas.ms_toa256
-	 * is needed for the computation. */
-	lchan_ms_ta_ctrl(lchan);
-
 	lchan->meas.num_ul_meas = 0;
 
 	/* return 1 to indicate that the computation has been done and the next
diff --git a/src/common/ta_control.c b/src/common/ta_control.c
index ccb60e2..ac9f255 100644
--- a/src/common/ta_control.c
+++ b/src/common/ta_control.c
@@ -1,6 +1,7 @@
 /* Loop control for Timing Advance */
 
 /* (C) 2013 by Andreas Eversberg <jolly at eversberg.eu>
+ * (C) 2021 by sysmocom - s.m.f.c. GmbH <info at sysmocom.de>
  *
  * All Rights Reserved
  *
@@ -19,6 +20,8 @@
  *
  */
 
+/* Related specs: 3GPP TS 45.010 sections 5.5, 5.6 */
+
 #include <osmo-bts/gsm_data.h>
 #include <osmo-bts/logging.h>
 
@@ -29,22 +32,60 @@
 #define TA_MIN 0
 #define TA_MAX 63
 
-void lchan_ms_ta_ctrl(struct gsm_lchan *lchan)
-{
-	int16_t toa256 = lchan->meas.ms_toa256;
+/* TODO: make configurable over osmo-bts VTY? Pass it BSC->BTS? */
+#define TA_MAX_INC_STEP 1
+#define TA_MAX_DEC_STEP 1
 
-	if (toa256 < -TOA256_9OPERCENT && lchan->rqd_ta > TA_MIN) {
-		LOGPLCHAN(lchan, DLOOP, LOGL_INFO,
-			  "TOA is too early (%d), now lowering TA from %d to %d\n",
-			  toa256, lchan->rqd_ta, lchan->rqd_ta - 1);
-		lchan->rqd_ta--;
-	} else if (toa256 > TOA256_9OPERCENT && lchan->rqd_ta < TA_MAX) {
-		LOGPLCHAN(lchan, DLOOP, LOGL_INFO,
-			  "TOA is too late (%d), now raising TA from %d to %d\n",
-			  toa256, lchan->rqd_ta, lchan->rqd_ta + 1);
-		lchan->rqd_ta++;
-	} else
+
+/*! compute the new "Ordered Timing Advance" communicated to the MS and store it in lchan.
+ * \param lchan logical channel for which to compute (and in which to store) new power value.
+ * \param[in] ms_tx_ta The TA used by the MS and reported in L1SACCH, see struct gsm_sacch_l1_hdr field "ta".
+ * \param[in] toa256 Time of Arrival (in 1/256th bits) computed at Rx side
+ */
+void lchan_ms_ta_ctrl(struct gsm_lchan *lchan, uint8_t ms_tx_ta, int16_t toa256)
+{
+	int16_t new_ta;
+	/* Shall we skip current block based on configured interval? */
+
+	/*TODO: implement P_CON_INTERVAL for TA loop */
+
+	int16_t delta_ta = toa256/256;
+	if (toa256 >= 0) {
+		if ((toa256 - (256 * delta_ta)) > TOA256_9OPERCENT)
+			delta_ta++;
+		if (delta_ta > TA_MAX_INC_STEP)
+			delta_ta = TA_MAX_INC_STEP;
+	} else {
+		if ((toa256 - (256 * delta_ta)) < -TOA256_9OPERCENT)
+			delta_ta--;
+		if (delta_ta < -TA_MAX_DEC_STEP)
+			delta_ta = -TA_MAX_DEC_STEP;
+	}
+
+	new_ta = ms_tx_ta + delta_ta;
+
+	/* Make sure new_ta is never negative: */
+	if (new_ta < TA_MIN)
+		new_ta = TA_MIN;
+
+	/* Don't ask for out of range TA: */
+	if (new_ta > TA_MAX)
+		new_ta = TA_MAX;
+
+	if (lchan->rqd_ta == (uint8_t)new_ta) {
 		LOGPLCHAN(lchan, DLOOP, LOGL_DEBUG,
-			  "TOA is correct (%d), keeping current TA of %d\n",
-			  toa256, lchan->rqd_ta);
+			  "Keeping current TA at %u: TOA was %d\n",
+			  lchan->rqd_ta, toa256);
+		return;
+	}
+
+	LOGPLCHAN(lchan, DLOOP, LOGL_INFO,
+		  "%s TA %u => %u: TOA was too %s (%d)\n",
+		  (uint8_t)new_ta > lchan->rqd_ta ? "Raising" : "Lowering",
+		  lchan->rqd_ta, (uint8_t)new_ta,
+		  (uint8_t)new_ta > lchan->rqd_ta ? "late" : "early",
+		  toa256);
+
+	/* store the resulting new TA in the lchan */
+	lchan->rqd_ta = (uint8_t)new_ta;
 }
diff --git a/tests/ta_control/ta_control_test.c b/tests/ta_control/ta_control_test.c
index 2e981b3..12305cb 100644
--- a/tests/ta_control/ta_control_test.c
+++ b/tests/ta_control/ta_control_test.c
@@ -35,9 +35,6 @@
 	uint8_t rqd_ta_before;
 	int16_t toa256 = toa256_start;
 
-	/* Arbitrary value, high enough so that a computation can happen. */
-	lchan.meas.num_ul_meas = 10;
-
 	printf("toa256_start = %u / 256 = %u, steps = %u\n", toa256_start,
 	       toa256_start / 256, steps);
 
@@ -49,8 +46,7 @@
 
 		rqd_ta_before = lchan.rqd_ta;
 
-		lchan.meas.ms_toa256 = toa256;
-		lchan_ms_ta_ctrl(&lchan);
+		lchan_ms_ta_ctrl(&lchan, rqd_ta_before, toa256);
 
 		rqd_ta_after = lchan.rqd_ta;
 		toa256 -= (rqd_ta_after - rqd_ta_before) * 256;

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

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
Gerrit-Change-Number: 25386
Gerrit-PatchSet: 3
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: osmith <osmith at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210913/2f77dad8/attachment.htm>


More information about the gerrit-log mailing list