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