3 Mar
2017
3 Mar
'17
7:10 p.m.
Hi Sebastian,
On Fri, Mar 03, 2017 at 05:56:09PM +0100, Sebastian Stumpf wrote:
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.
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. 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)