Use the burst timing information to compute the timing advance
**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.
#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.