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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)