Project

General

Profile

Actions

Feature #1531

closed

Use the burst timing information to compute the timing advance

Added by zecke about 8 years ago. Updated over 7 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)Stalledfixeria02/22/2016

Actions
Actions #1

Updated by msuraev over 7 years ago

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

Updated by msuraev over 7 years ago

Actions #3

Updated by msuraev over 7 years ago

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

Fix submitted for review in gerrit #544.

Actions #4

Updated by msuraev over 7 years ago

  • Status changed from In Progress to Stalled
Actions #5

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

Actions #6

Updated by laforge over 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)