This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sebastian Stumpf sebastian.stumpf87 at googlemail.comHi 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