12 Aug
2011
12 Aug
'11
9:56 p.m.
Hello,
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
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de