Feature #1526
openAcquire/update timing advance (TA)
Added by zecke about 8 years ago. Updated about 3 years ago.
30%
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
Updated by msuraev over 7 years ago
- Related to Feature #1545: continuous timing advance loop using PTCCH added
Updated by msuraev over 7 years ago
- Related to Feature #1531: Use the burst timing information to compute the timing advance added
Updated by msuraev over 7 years 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.
Updated by msuraev over 7 years ago
Currently TA is initialized with 0 by default which means we always begin with valid TA.
Updated by msuraev over 7 years 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.
Updated by msuraev over 7 years 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.
Updated by msuraev over 7 years 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.
Updated by msuraev over 7 years ago
Apparently TA might be unknown in 2 cases:
- packet queuing notification is used
- packet UL/DL assignment sent without prior paging
Updated by laforge over 7 years 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.
Updated by msuraev over 7 years 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?
Updated by laforge over 7 years 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 <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by msuraev over 7 years ago
- Status changed from Stalled to In Progress
Was working on other tickets in a meantime.
Updated by msuraev over 7 years 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.
Updated by msuraev over 7 years ago
- Status changed from In Progress to Stalled
Gerrit #552 is still under review.
Updated by msuraev about 7 years 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.
Updated by msuraev almost 7 years ago
- Related to Bug #1524: PACCH on the wrong timeslot added
Updated by msuraev almost 7 years 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.
Updated by msuraev over 6 years ago
- Status changed from Stalled to In Progress
Related gerrit 4336-4339, 4292 were sent for review.
Updated by msuraev over 6 years ago
- Status changed from In Progress to Stalled
- % Done changed from 10 to 20
Gerrit 4292 should be rewritten, the rest is merged.
Updated by msuraev about 6 years 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.
Updated by msuraev about 6 years ago
Fixes are merged, needs additional testing with "gprs control-ack-type-rach" and different BTS models.
Updated by msuraev about 6 years ago
- Status changed from In Progress to Stalled
Updated by keith over 5 years ago
I have found that when we create a new dl_tbf, we are not setting the TA to a valid TA at any time, this is resulting in:
DTBFDL <0009> tbf_dl.cpp:506 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=NULL) Send dowlink assignment on PCH, no TBF exist (IMSI=262423203000351)
DTBF <0008> tbf_dl.cpp:510 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=NULL) changes state from NULL to ASSIGN
DTBF <0008> bts.cpp:799 TBF(TFI=0 TLLI=0xf4b4d5ee DIR=DL STATE=ASSIGN) TX: START Immediate Assignment Downlink (PCH)
DRLCMAC <0002> bts.cpp:807 - TRX=0 (69) TS=6 TA=220 pollFN=-1
Note: TA=220
And we are telling the MS to use an invalid TA in the resulting IMM.ASS?
Maybe MS some ignore this and continue to work, but others set their max valid TA?
This would explain behavior I have observed a lot; that the MS is transmitting in response, but the BTS/PCU is not seeing the response, because the TA is wrong.
Updated by keith over 5 years ago
- Related to Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side. added
Updated by msuraev about 5 years ago
- Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added
Updated by keith almost 4 years ago
msuraev wrote:
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.
With gprs control-ack-type-rach:
On sysmo, osmo-pcu is currently logging
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH
Updated by laforge almost 4 years ago
On Mon, Mar 30, 2020 at 03:01:50AM +0000, keith [REDMINE] wrote:
With gprs control-ack-type-rach:
On sysmo, osmo-pcu is currently logging
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH
This is likely a regression in Change-ID I482d60a46b9d253dfe0b16140eac9fea6420b30c by fixeria,
where he introduced code that expected the ra_ind->sapi to be either Pdtch or Ptcch,
while apparently it's actually arriving with Prach SAPI.
Updated by fixeria almost 4 years ago
This is likely a regression in Change-ID I482d60a46b9d253dfe0b16140eac9fea6420b30c by fixeria,
I am sorry :/ Let's try to investigate more.
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH
I am currently trying to find this file, but it doesn't seem to be present in the recent master...
where he introduced code that expected the ra_ind->sapi to be either Pdtch or Ptcch,
while apparently it's actually arriving with Prach SAPI.
But how is it possible? I thought PRACH does not exist in network mode of operation II.
In any case, I'll propose a potential fix (as soon as I find the right file).
Updated by fixeria almost 4 years ago
I am currently trying to find this file, but it doesn't seem to be present in the recent master...
Never mind. For some reason I was looking in the source tree of osmo-bts-trx.
In any case, I'll propose a potential fix (as soon as I find the right file).
Please see https://gerrit.osmocom.org/c/osmo-pcu/+/17669. I hope it helps.
Updated by pespin about 3 years ago
Something which may be of interest here in case it's not yet done: TS 44.060 7.2.1.1 "Packet downlink assignment procedure" explains how to orchestrate the MS to send 4 access bursts to CTRL ACK the Pkt Downlink Assignment, and hence gain TA information.