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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)