PDTCH and PTCCH activation
laforge at gnumonks.org
Thu Jul 21 10:38:25 UTC 2016
[posting to the openbsc mailing list, as this discussion is not GPRS
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.
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".
> So, I would also benefit from better understanding the actions after
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)
More information about the OpenBSC