PDTCH and PTCCH activation

historical

On Thu, Jul 21, 2016 at 12:38:25PM +0200, Harald Welte wrote:
> Hi Neels,
> 
> [posting to the openbsc mailing list, as this discussion is not GPRS
> related]
> 
> On Thu, Jul 21, 2016 at 12:25:25PM +0200, Neels Hofmeyr wrote:
> > On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote:
> > > It's called from lchan_act_compl_cb() via sapi_queue_send() which is
> > > also in mph_send_activate_req() - I have hard time understanding how
> > > this works at all. Do we have this documented somewhere?
> > 
> > Both the TCH/F_TCH/H_PDCH timeslot feature and the TCH/F_PDCH on osmo-trx
> > are stuck on some post-lchan_act_compl SAPI stuff. 
> 
> can you be more specific about what "stuff"?  It's hard to be of
> assistance without details.

Well, I kind of feel that I should be able to find out myself, so I kept
my remark at a distance. But since you were so fast to reply and I am
indeed a bit stuck in a stupid way... I'll focus on TCH/F_TCH/H_PDCH:

GPRS works, but placing a TCH/H call doesn't. The pchan switchover dance is
complete, but then the new TCH/H channel is not working.

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: 

 DRSL <0004> abis_rsl.c:1462 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
 DRSL <0004> abis_rsl.c:1133 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE
 DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION
 ^ missing for dyn TS

 DRLL <0000> gsm_04_08.c:3667 Dispatching 04.08 message, pdisc=5
 DMM <0002> gsm_04_08.c:987 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=300151278
 DMM <0002> gsm_04_08_utils.c:681 -> CM SERVICE ACK 
 DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
 DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
 DRR <0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
 DRLL <0000> gsm_04_08.c:3667 Dispatching 04.08 message, pdisc=6
 DRR <0003> gsm_04_08.c:1281 MSC: Unimplemented GSM 04.08 RR msg type 0x60
 DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
 DRLL <0000> abis_rsl.c:1913 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION

The first one missing for a dyn TS is:

 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.

I feel a bit stupid not to be able to see it, and my knowledge is really
lacking... so I could use a noob nudge in the right direction there, or maybe a
really coarse picture of what I'm talking about in the first place.

My guess goes at sapi_queue_exeute() at the moment, but I'm not seeing the
connections yet.

BTW, the second TCH/H on a dynamic channel seems to be established
successfully, so I'm probably clearing some lchan state during pchan
switchover, but can't put my finger on it yet.

Thanks,
~Neels

> 
> > So, I would also benefit from better understanding the actions after
> > lchan_act.
> 
> I actually think the L1 SAPI activation/deactivation is rather simple.
> You have the tables that list the SAPI+Direction combinations needed for
> every lchan type (what I just quoted for PDCH in my recent mail), and
> then the code iterates over the list of SAPI+Direction at time of lchan
> activation or deactivation.
> 
> > Apparently related: libosmocore/gsm/lapd*.c
> 
> How are the SAPIs of the data link layer should be related to SAPIs of
> the physical layer?
> 
> LAPDm is establishing reliable channels over the already established
> physical layer, and LAPDm is not by iself activating/deactivating any
> channels, i.e. not talking to the MPH-SAP.
> 
> -- 
> - 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)

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160721/a07f0a13/attachment.bin>