Hi Harald,
This is likely a result of the MS somehow not
receiving/processing the
downlink signalling messages. [on TCH]
I found the reason for that. I thought I need to forward incoming messages
on TCH/H TCH/F as L1CTL_TRAFFIC_IND if the ACCH flag is not set in the
GSMTAP header channel type. But in case of a msg on FACCH this is wrong
and needs to be L1CTL_DATA_IND. As the CM Service Accept is sent on
FACCH it was not forwarded correctly to l23 and thus not processed.
Unfortunately I do not know, how to distinguish FACCH from TCH based on
the information available in the GSMTAP messages.
The stealing flag indicating a FACCH is set before and after the training
sequence in the burst I think, but this info is no longer available in the msg
as it is sent over the virtual um.
Or do I miss something here?
Do you have an idea how to check if the msg is TCH or FACCH?
Also, what's noteworthy (but likely unrelated) is
that the BTS is
sending empty idle/padding frames on the TS7 all the time (those
containing 0x2b2b2b2b) but the MS is not doing that in uplink.
That's because I just implemented some kind of one time scheduler.
If I do not get frames/data to schedule from the upper layer for a tdma slot,
I currently do not have any logic that fills these up with empty/idle frames.
Seems as if I need this, though.
Thanks a lot for your support, I am glad you are taking the time to help me
out :).
With kind regards,
Sebastian Stumpf