Project

General

Profile

Actions

Feature #1545

open

continuous timing advance loop using PTCCH

Added by laforge about 8 years ago. Updated about 4 years ago.

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

60%

Spec Reference:
44.004 7.8 + 7.9 | 44.018 3.5.3.1 | 45.010 6.5.2 | 45.002 7 Mapping Table 6

Description

We currently only implement the "initial TA" where the TA of a MS is determined at time the TBF is established. If the MS moves more than 1 TA during a TBF being active, this leads to problems.

GPRS has the PTCCH for this, a special channel in the PDCH channel combination multiplex, using which we can instruct a sub-set of 16 MS (whether TBFs are active or not) to adjust their timing advance continuously. What needs to be done is
  • code to generate the PTCCH/D messages
  • code to parse the PTCCH/U messages
  • code to determine which 16 MS will be part of the current PTCCH subset
  • unit tests for the above

We also need to see how we can test this with actual hardware, in a way that TA exists (and changes) over time. Unfortuantely we don't have a MS-side GPRS implementation for OsmocomBB, because then we could simply artificially delay the transmit burst timing to make the network determine a higher TA.


Related issues

Related to OsmoPCU - Feature #1526: Acquire/update timing advance (TA)Stalledfixeria02/22/2016

Actions
Related to OsmoBTS - Bug #4102: osmo-bts-trx: incorrect PTCCH handlingResolvedfixeria07/12/2019

Actions
Related to OsmoBTS - Bug #4500: osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH timeslotsStalledfixeria04/18/2020

Actions
Blocked by OsmoBTS - Bug #1796: PTCCH activation breaks dyn TSClosed08/10/2016

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)