Project

General

Profile

Feature #1526

Acquire/update timing advance (TA)

Added by zecke almost 2 years ago. Updated 5 days ago.

Status:
In Progress
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 PTCCH Stalled 02/23/2016
Related to OsmoPCU - Feature #1531: Use the burst timing information to compute the timing advance Closed 02/22/2016
Related to OsmoPCU - Bug #1524: PACCH on the wrong timeslot Stalled 02/22/2016

History

#2 Updated by laforge over 1 year ago

  • Priority changed from Low to High

#3 Updated by msuraev over 1 year ago

Reference to #1705 is probably wrong.

#4 Updated by msuraev over 1 year ago

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

#5 Updated by msuraev over 1 year ago

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

#6 Updated by laforge over 1 year ago

msuraev wrote:

Reference to #1705 is probably wrong.

It's probably #1531

#7 Updated by msuraev over 1 year 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.

#8 Updated by msuraev over 1 year ago

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

#9 Updated by msuraev over 1 year 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.

#10 Updated by msuraev over 1 year 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.

#11 Updated by msuraev over 1 year 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.

#12 Updated by msuraev over 1 year ago

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

#13 Updated by laforge over 1 year 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.

#14 Updated by msuraev over 1 year 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?

#15 Updated by laforge over 1 year 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)

#16 Updated by laforge over 1 year ago

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

#17 Updated by msuraev over 1 year ago

  • Status changed from Stalled to In Progress

Was working on other tickets in a meantime.

#18 Updated by msuraev over 1 year 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.

#19 Updated by msuraev over 1 year ago

  • Status changed from In Progress to Stalled

Gerrit #552 is still under review.

#20 Updated by laforge about 1 year ago

Gerrit 552 is now merged.

#21 Updated by msuraev about 1 year 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.

#22 Updated by laforge about 1 year ago

  • Priority changed from High to Normal

#23 Updated by msuraev 8 months ago

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

#24 Updated by msuraev 8 months 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.

#25 Updated by msuraev 4 months ago

Related fix is available in gerrit 3991.

#26 Updated by msuraev 3 months ago

  • Status changed from Stalled to In Progress

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

#27 Updated by msuraev 3 months ago

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

Gerrit 4292 should be rewritten, the rest is merged.

#28 Updated by msuraev 5 days 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.

Also available in: Atom PDF