PDTCH and PTCCH activation
laforge at gnumonks.org
Thu Jul 21 14:43:40 UTC 2016
On Thu, Jul 21, 2016 at 01:19:55PM +0200, Neels Hofmeyr wrote:
> I notice that on a dyn TS just after switchover, log entries starting with
> "SAPI=0" are missing *on the BSC side*, when compared to a pure TCH/H:
when switching the PCHAN type, do you also make sure to "re-configure'
the data of the lchan array within that TS? I think some data in there
might need to change, just from my memory.
> DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION
> So I tried to find its root. The log on the BSC is from receiving an RLL
> message from the BTS, so I tried to find out where it's sent in the BTS:
> * BSC: abis_rsl_rx_rll(): case RSL_MT_EST_IND
> * libosmocore/src/gsm/lapdm.c:421: send_rslms_dlsap():
> case OSMO_PRIM(PRIM_DL_EST, PRIM_OP_INDICATION):
> rll_msg = RSL_MT_EST_IND;
> * libosmocore/src/gsm/lapd_core.c:788: prim = PRIM_DL_EST;
> And there I seem to be in a very general area with lots of callers.
an ESTABLISH INDICATION of LAPD(m) is triggered by a SABM frame on on
so you should try to trace the SABM frame from the MS over the radio
interface (maybe confirm it using GSMTAP frames generated by the BTS)
and trace it through the LAPD(m) code until on the upper side of the
LAPDm code (towards RLL, which is part of RSL) it generates the
> My guess goes at sapi_queue_exeute() at the moment, but I'm not seeing the
> connections yet.
I still don't see how this should at all relate to each other. As
indicated, a pysical-layer SAPI has nothing to do with a data
link-layer SAPI. It's like an IP address having nothing to do with an
e-mail address. They're both called addresses, that's it.
- 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)
More information about the OpenBSC