Project

General

Profile

Feature #1531

Use the burst timing information to compute the timing advance

Added by zecke over 2 years ago. Updated almost 2 years ago.

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

100%

Spec Reference:

Description

**Currently the timing advance is obtained from RACH request meta data and from which is passed from the BTS or from packet measurement reports (UL control block). The measParam.i16BurstTiming value contained in ph_data or ph_ra messages (obtained from the DSP) is more or less ignored. In handle_ph_ra_ind, an acc_delay is computed (burstTiming/4), but the result is ignored.

This might be an issue if the MS is moved during a longer data transfer, especially of DL TBFs are kept open to avoid RACH requests.


Related issues

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

History

#1 Updated by msuraev over 2 years ago

  • Related to Feature #1526: Acquire/update timing advance (TA) added

#2 Updated by msuraev over 2 years ago

#3 Updated by msuraev over 2 years ago

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

Fix submitted for review in gerrit #544.

#4 Updated by msuraev about 2 years ago

  • Status changed from In Progress to Stalled

#5 Updated by msuraev about 2 years ago

  • Status changed from Stalled to Resolved
  • Assignee changed from msuraev to laforge
  • % Done changed from 20 to 100

The fix has been merged to master. Note: ideally it should be tested using RF channel emulator to properly introduce delay for UL/DL communication with MS.

#6 Updated by laforge almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)