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://email@example.com/.Harald Welte laforge at gnumonks.org
Hi Sebastian, On Fri, Mar 03, 2017 at 05:56:09PM +0100, Sebastian Stumpf wrote: > > 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 reaseon for that is simple: We never forwarded actual traffic/user data in GSMTAP so far, only signalling messages. So for now, it is safe to assume that all TCH data is FACCH. GSMTAP will have to be extended with a new channel type if we want to carry voice frames later on. > 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. I think it is needed sooner or later, as the BTS will consider the radio channel dead if it doesn't receive anything. Also, it will probably think the radio quality is very poor? At the very least the SACCH must be present in uplink. But maybe not the most important bit right now. If you have to go for a full scheduler sooner or later, I think it's worth to "abstract out + recycle" either the scheduler tables from OsmocomBB layer1 (but I think they're very calypso specific?), or those from OsmoBTS, so one set of scheduling tables can be used in multiple places. > Thanks a lot for your support, I am glad you are taking the time to help me > out :). I'm happy if I can help your progress. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)