21 Jul
2016
21 Jul
'16
10:38 a.m.
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:
can you be more specific about what "stuff"? It's hard to be of
assistance without details.
Also, SAPIs exist completely separately on every SAP, such as the (M)PH-SAP
of the physical layer and the (M)DL-SAP of LAPDm, wich is implemented
via RSL. So it is useful to explicitly state which SAP we are talking
about when mentioning "SAPI stuff".
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. 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
21 Jul
21 Jul
11:19 a.m.
New subject: PDTCH and PTCCH activation
On Thu, Jul 21, 2016 at 12:38:25PM +0200, Harald Welte wrote:
--
- Neels Hofmeyr <nhofmeyr(a)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
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:
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
On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max
wrote:
can you be more specific about what "stuff"? It's hard to be of
assistance without details. 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. 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
12:18 p.m.
New subject: PDTCH and PTCCH activation
On Thu, Jul 21, 2016 at 01:19:55PM +0200, Neels Hofmeyr wrote:
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:
DRSL <0000> rsl.c:2265 (bts=0,trx=0,ts=2,ss=1) Fwd RLL msg EST_IND from LAPDm to
A-bis
lapdm_rll_tx_cb() is sending, i.e. forwarding, the EST_IND.
So it seems I'm not getting the EST_IND I need because of earlier
misconfiguration of sorts.
I hope to find it soon, especially because TCH/H slot 1 of a TS seems to
work and only TCH/H slot 0 is failing, just after switchover.
~Neels
1:21 p.m.
New subject: PDTCH and PTCCH activation
On Thu, Jul 21, 2016 at 02:18:43PM +0200, Neels Hofmeyr wrote:
I hope to find it soon, especially because TCH/H slot
1 of a TS seems to
work and only TCH/H slot 0 is failing, just after switchover.
As so often with these things, the solution is pretty simple... during
channel switchover, I inadvertently throw away the lchan->rqd_ref, and
thus no immediate assignment is sent.
I was just looking in the wrong places...
~Neels
2:47 p.m.
New subject: PDTCH and PTCCH activation
Hi Neels,
On Thu, Jul 21, 2016 at 02:18:43PM +0200, Neels Hofmeyr wrote:
I hope to find it soon, especially because TCH/H slot
1 of a TS seems to
work and only TCH/H slot 0 is failing, just after switchover.
lchan[0] is what is also used as TCH/F or PDCH, while lchan[0] and
lchan[1] are used in the TCH/H case. See my comment regarding
re-initialization of the lchan array every time you switch the pchan
type.
--
- 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)
2:43 p.m.
New subject: PDTCH and PTCCH activation
Hi Neels,
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
LAPD(m).
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
ESTABLISH INDICATION
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3261
days inactive
3261
days old
5 comments
2 participants
participants (2)
-
Harald Welte -
Neels Hofmeyr