Questions regarding maintaining synchronization of a mobile station

historical

Hi Piotr,

On Fri, Sep 21, 2018 at 10:07:20AM +0200, Piotr Krysik wrote:
> Gr-gsm's receiver currently relies on having SCH channel to keep
> synchronization. 

are you referring to carrier clock (oscillator) synchronization, or TDMA
multiframe synchronization?

> To do this it would be great to know how normal mobile phones maintain
> synchronization, something I don't know currently. Especially:
> 1. How often mobile station (MS) checks if the synchronization is kept?
> 2. What is usually used to check if synchronization is kept, especially
> when a MS is on a traffic channel?
> 3. How MS regains synchronization? Does it always do full FCCH+SCH scan?

For tracking the clock of the currently serving BTS, you have the coarse
search window of +/- 1kHz clock difference until you've been to FACCH+SCH
sync.  From that point on, the clock drift between sender and receiver is
tracked by relying on the TCH only.  I think e.g. the calypso had something
like +/- 50Hz tracking capability while on a dedicated channel, meaning if
there's more clock difference, it would no longer lock onto the signal and
just receive junk, leading to L2 closing the channel.

In terms of synchronization to the TMDA frame of the other cells: This is
part of the neighbor cell measurement process, and I'm quite sure it's specified
quite tightly in the relevant specs.  IIRC, the MS must at least monitor up to
12 meighbors of which the 6 best are to be reported during the measurement report.

For tracking the neighbors during active use of TCH, the MS uses the
IDLE frames in the 26-multiframe.  It keeps "sync state" for each of the
neighbors, including
* carrier clock / oscillator recovered from FACCH on that neighbor
* BSIC + frame number on that neighbor

If the BSIC ever changes, the MS knows that the neighbor has changed
(different neighbor on same ARFCN) and all higher-layer state must be
invalidated.

I'm quite sure pretty much all of this should be in the jolly/handover branch
of osmocom-bb.git

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)