Failing channel assignment

Dieter Spaar spaar at
Fri Aug 12 19:56:47 UTC 2011


I noticed some issues in the following situation, I used the "testing"
branch (I think it affects both current "testing" branches):

  - the signalling channel is an SDCCH/8 on a timeslot different from
    TS0, for example on TS4

  - an ASSIGNMENT COMMAND switches to another channel on a different TS
    than the SDCCH/8, e.g. to TS2

Now the following two problems can happen:

  1.) The ASSIGNMENT COMMAND releases the SDCCH/8 with an L1CTL_DM_REL_REQ.
  Depending on when the L1CTL_DM_REL_REQ is received, it could be that
  there are still burst scheduled for transmit (e.g. for the SACCH). Due
  to the L1CTL_DM_REL_REQ, rfch_get_params() will return wrong data
  (l1s.dedicated.type is now set to GSM_DCHAN_NONE) and the transmit
  of the bursts happens on the wrong ARFCN and/or TS.

  My temporary workaround is to clear every item in the scheduler including
  the current bucket when a L1CTL_DM_REL_REQ is received, this action
  requires to disable the FIQ, otherwise problems might happen.

  2.) There is some code to check for a switch to a lower timeslot in
  check_lost_frame(). However it can happen that this code gets not
  triggered although it should: The ASSIGNMENT COMMAND causes a
  L1CTL_DM_REL_REQ, l1s.dedicated.type is now GSM_DCHAN_NONE ("0").
  The next call to check_lost_frame() resets "last_ts" to 0. Now the
  new channel is assigned (in the example from above its a switch
  from TS4 to TS 2) and a "LOST" occures, however the required
  increment of the GSM time does not happen because "last_ts" is 0
  although it should be 4.

  My current workaround is to not reset "last_ts" to 0 in check_lost_frame()
  but during "L1CTL_RESET_REQ: FULL!".

I don't post any patches because my changes are really just ugly workaround
which seem to work in (most) situations where it I otherwise observe failures.

To really solve this issues something else should be done, maybe put
the whole switch of a channel into an atomic operation instead of
doing several operations (this is just an idea, maybe there are
better solutions).

Best regards,
Dieter Spaar, Germany                           spaar at

More information about the baseband-devel mailing list