Project

General

Profile

Actions

Feature #1526

open

Acquire/update timing advance (TA)

Added by zecke about 8 years ago. Updated almost 3 years ago.

Status:
Stalled
Priority:
Normal
Assignee:
Target version:
-
Start date:
02/22/2016
Due date:
% Done:

30%

Spec Reference:

Description

Currently the TA is derived from the initial RACH request and never updated during the lifetime of a TBF.

Is this handled correctly for network initiated DL TBF establishment?

TS 44.018, 3.5.3.1.2 asks for TA determination on DL TBF establshment if the MS is idle and the TA is not known (see "If the network does not have a valid timing advance ...").

Other related issues:

  • The burst timing info (qta) should be applied (see #1705)
  • Support access bursts on PDCH which can be requested by the PCU if the current TA is unknown (44.060)

Related issues

Related to OsmoPCU - Feature #1545: continuous timing advance loop using PTCCHStalledfixeria02/23/2016

Actions
Related to OsmoPCU - Feature #1531: Use the burst timing information to compute the timing advanceClosedlaforge02/22/2016

Actions
Related to OsmoPCU - Bug #1524: PACCH on the wrong timeslotFeedbackroh02/22/2016

Actions
Related to OsmoPCU - Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side.Closedkeith08/18/2018

Actions
Related to OsmoBTS - Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with dataStalleddexter02/21/2018

Actions
Actions #2

Updated by laforge over 7 years ago

  • Priority changed from Low to High
Actions #3

Updated by msuraev over 7 years ago

Reference to #1705 is probably wrong.

Actions #4

Updated by msuraev over 7 years ago

  • Related to Feature #1545: continuous timing advance loop using PTCCH added
Actions #5

Updated by msuraev over 7 years ago

  • Related to Feature #1531: Use the burst timing information to compute the timing advance added
Actions #6

Updated by laforge over 7 years ago

msuraev wrote:

Reference to #1705 is probably wrong.

It's probably #1531

Actions #7

Updated by msuraev over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

TS 44.060 is referred to by 44.018 in "If the network does not have a valid timing advance ..." passage: "the network shall use the procedures defined in 3GPP TS 44.060". For both 1-phase (7.1.2.5) and 2-phase (7.1.3.5) in 44.060 the only procedure defined in continuous TA update described in #1545.

Alternatively 44.018 suggests to use "polling mechanism" to derive TA "if the PACKET CONTROL ACKNOWLEDGEMENT format is set to four access bursts".

The PACKET CONTROL ACKNOWLEDGEMENT format is described in TS 44.060 § 11.2.2 including 11-bit and 8-bit RACH.

The ACK format is specified in SI parameter CONTROL_ACK_TYPE and in Packet Polling Request message in § 11.2.12.

Actions #8

Updated by msuraev over 7 years ago

Currently TA is initialized with 0 by default which means we always begin with valid TA.

Actions #9

Updated by msuraev over 7 years ago

The SI message referred to above is Packet System Information Type 1 (§11.2.18) which has CONTROL_ACK_TYPE bit in GPRS Cell Options (§12.24) both in 3GPP TS 44.060.

Actions #10

Updated by msuraev over 7 years ago

Alternatively (our case as we do not support yet PBCCH) SI type 13 from 3GPP TS 44.018 §9.1.43a can be used as §10.5.2.37b refers to same IE specified for PSI1.

Actions #11

Updated by msuraev over 7 years ago

  • Status changed from In Progress to Stalled

With gerrit #543, 544, 547 TA handling seems to be fine. So far I have not managed to reproduce situation in which PCU do not know TA - it's always derived from initial RACH qTA. The question is - is it worth adding support for access bursts on PDCH if there's no need for PCU to use polling which will trigger them? Note: it might also require changes to DSP firmware.

Actions #12

Updated by msuraev over 7 years ago

Apparently TA might be unknown in 2 cases:
- packet queuing notification is used
- packet UL/DL assignment sent without prior paging

Actions #13

Updated by laforge over 7 years ago

msuraev wrote:

The question is - is it worth adding support for access bursts on PDCH if there's no need for PCU to use polling which will trigger them? Note: it might also require changes to DSP firmware.

Is there something specified in GPRS that permits access bursts on a PDTCH outside of the TCCH/PACCH?

Also, in terms of the DSP firmware, I would assume you just need to activate the "right" SAPI on the logical channel, and it should do the correlation/decoding of access bursts.

Actions #14

Updated by msuraev over 7 years ago

laforge wrote:

Is there something specified in GPRS that permits access bursts on a PDTCH outside of the TCCH/PACCH?

It's possible to configure the use of access bursts (x4) instead of ctrl ack packets - see gerrit #546.

Also, in terms of the DSP firmware, I would assume you just need to activate the "right" SAPI on the logical channel, and it should do the correlation/decoding of access bursts.

You mean pysical-layer SAPI or link-layer SAPI?

Actions #15

Updated by laforge over 7 years ago

On Wed, Jul 27, 2016 at 11:27:32AM +0000, msuraev [REDMINE] wrote:

Also, in terms of the DSP firmware, I would assume you just need to
activate the "right" SAPI on the logical channel, and it should do
the correlation/decoding of access bursts.

You mean pysical-layer SAPI or link-layer SAPI?

physical-layer SAPI (such as RACH).

--
- Harald Welte <> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

Actions #16

Updated by laforge over 7 years ago

why is this stalled at 10%? Please update ticket status

Actions #17

Updated by msuraev over 7 years ago

  • Status changed from Stalled to In Progress

Was working on other tickets in a meantime.

Actions #18

Updated by msuraev over 7 years ago

Fixes for TA handling submitted for review in gerrit #547, 552. With the code from gerrit #546 we can test decoding of 4xRACH in place of CTRL_ACK (once the decoding is available). See also OS#1545.

Actions #19

Updated by msuraev over 7 years ago

  • Status changed from In Progress to Stalled

Gerrit #552 is still under review.

Actions #20

Updated by laforge over 7 years ago

Gerrit 552 is now merged.

Actions #21

Updated by msuraev about 7 years ago

Turning on "gprs control-ack-type-rach" option in OpenBSC breaks GPRS (expectedly), 4xRACH response is not visible in the logs (unexpectedly) although GsmL1_Sapi_Prach is activated for RxUplink - see pdtch_sapis in oml.c Investigation is ongoing.

Actions #22

Updated by laforge about 7 years ago

  • Priority changed from High to Normal
Actions #23

Updated by msuraev almost 7 years ago

  • Related to Bug #1524: PACCH on the wrong timeslot added
Actions #24

Updated by msuraev almost 7 years ago

The Packet Control Acknowledgement in RACH format described in 3GPP TS 44.060 Table 11.2.2.1, when trying to detect corresponding message type in PCU's pcu_rx_rach_ind() I've got nothing so far. I suspect that the reason is low-level encoding difference: I've got several consequitive RACH decoding errors from BTS' rx_rach_fn() (the tests were done using osmo-bts-trx as it exposes more information than DSP). It means that osmo_crc8gen_check_bits() fails in gsm0503_rach_decode() in libosmocoding - I'm not sure yet if different polynomial should be used compared to regular RACH. Note: at the time of tests 11-bit RACH is not supported by osmo-bts-trx.

Actions #25

Updated by msuraev over 6 years ago

Related fix is available in gerrit 3991.

Actions #26

Updated by msuraev over 6 years ago

  • Status changed from Stalled to In Progress

Related gerrit 4336-4339, 4292 were sent for review.

Actions #27

Updated by msuraev over 6 years ago

  • Status changed from In Progress to Stalled
  • % Done changed from 10 to 20

Gerrit 4292 should be rewritten, the rest is merged.

Actions #28

Updated by msuraev about 6 years ago

  • Status changed from Stalled to In Progress
  • % Done changed from 20 to 30

The fixes for IA rest octets which seem to prevent 4xRACH reply from MS were posted for review in gerrit 5726 - 5729.

Actions #29

Updated by msuraev about 6 years ago

Fixes are merged, needs additional testing with "gprs control-ack-type-rach" and different BTS models.

Actions #30

Updated by msuraev about 6 years ago

  • Status changed from In Progress to Stalled
Actions #31

Updated by laforge about 6 years ago

  • Assignee changed from msuraev to 4368
Actions #32

Updated by keith over 5 years ago

I have found that when we create a new dl_tbf, we are not setting the TA to a valid TA at any time, this is resulting in:

DTBFDL <0009> tbf_dl.cpp:506 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=NULL) Send dowlink assignment on PCH, no TBF exist (IMSI=262423203000351)
DTBF <0008> tbf_dl.cpp:510 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=NULL) changes state from NULL to ASSIGN
DTBF <0008> bts.cpp:799 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=ASSIGN) TX: START Immediate Assignment Downlink (PCH)
DRLCMAC <0002> bts.cpp:807  - TRX=0 (69) TS=6 TA=220 pollFN=-1

Note: TA=220

And we are telling the MS to use an invalid TA in the resulting IMM.ASS?

Maybe MS some ignore this and continue to work, but others set their max valid TA?

This would explain behavior I have observed a lot; that the MS is transmitting in response, but the BTS/PCU is not seeing the response, because the TA is wrong.

Actions #33

Updated by keith over 5 years ago

  • Related to Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side. added
Actions #34

Updated by laforge over 5 years ago

Actions #35

Updated by laforge over 5 years ago

  • Assignee changed from 4368 to msuraev
Actions #36

Updated by msuraev about 5 years ago

  • Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added
Actions #37

Updated by laforge almost 5 years ago

  • Assignee changed from msuraev to lynxis
Actions #38

Updated by laforge over 4 years ago

  • Assignee changed from lynxis to fixeria
Actions #39

Updated by keith almost 4 years ago

msuraev wrote:

Turning on "gprs control-ack-type-rach" option in OpenBSC breaks GPRS (expectedly), 4xRACH response is not visible in the logs (unexpectedly) although GsmL1_Sapi_Prach is activated for RxUplink - see pdtch_sapis in oml.c Investigation is ongoing.

With gprs control-ack-type-rach:
On sysmo, osmo-pcu is currently logging
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH

Actions #40

Updated by laforge almost 4 years ago

On Mon, Mar 30, 2020 at 03:01:50AM +0000, keith [REDMINE] wrote:

With gprs control-ack-type-rach:
On sysmo, osmo-pcu is currently logging
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH

This is likely a regression in Change-ID I482d60a46b9d253dfe0b16140eac9fea6420b30c by fixeria,
where he introduced code that expected the ra_ind->sapi to be either Pdtch or Ptcch,
while apparently it's actually arriving with Prach SAPI.

Actions #41

Updated by fixeria almost 4 years ago

This is likely a regression in Change-ID I482d60a46b9d253dfe0b16140eac9fea6420b30c by fixeria,

I am sorry :/ Let's try to investigate more.

DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH

I am currently trying to find this file, but it doesn't seem to be present in the recent master...

where he introduced code that expected the ra_ind->sapi to be either Pdtch or Ptcch,
while apparently it's actually arriving with Prach SAPI.

But how is it possible? I thought PRACH does not exist in network mode of operation II.
In any case, I'll propose a potential fix (as soon as I find the right file).

Actions #42

Updated by fixeria almost 4 years ago

I am currently trying to find this file, but it doesn't seem to be present in the recent master...

Never mind. For some reason I was looking in the source tree of osmo-bts-trx.

In any case, I'll propose a potential fix (as soon as I find the right file).

Please see https://gerrit.osmocom.org/c/osmo-pcu/+/17669. I hope it helps.

Actions #43

Updated by pespin almost 3 years ago

Something which may be of interest here in case it's not yet done: TS 44.060 7.2.1.1 "Packet downlink assignment procedure" explains how to orchestrate the MS to send 4 access bursts to CTRL ACK the Pkt Downlink Assignment, and hence gain TA information.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)