2 Nov
2016
2 Nov
'16
7:04 p.m.
Hi Max,
On Wed, Nov 02, 2016 at 01:19:00PM +0100, Max wrote:
Pardon the cross-posting, I'm not sure where this
question really belongs.
I would say here, as OsmoBTS is discussed on the openbsc list. PCU on
the net-gprs list.
I've been trying to wrap my head around how
PDTCH/PACCH/PTCCH activation
works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what
got to be activated both in DL and UL directions. Right now it's PDTCH
(UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are
commented out.
Yet I see code dealing with PACCH in osmo-pcu and corresponding log
messages.
So the question is - how does this works? The PACCH seems to be used so
it's somehow activated but apparently not the same way as PDTCH.
I think the PACCH SAPI is simply not activated in L1 at this point.
Maybe either L1 activates it automatically, or you can still send PACCH
blocks to the L1 despite not having activated it.
the L1 SAPI activation is probably really only "important" for dedicated
channels that get their own sub-multiplex in the TDMA scheme. Then the
L1 can generate associated PH-RTS.ind to the L2. Also, it matters for
channels that have different burst types, like the RACH SAPI on an
uplink TCH in case of hand-over, so the L1 will actually enable+perform
RACH burst correlation (which it normally doesn't).
For packet data channels, they're all shared and allocated dynamically
on the PDCH, and therere is no hierarchical TDMA architecture.
Therefore, a PACCH downlink message is simply a CS-1 radio block with
different payload than a PDTCH block. It's completely virtual.
So yes, we should be a good citizen and activate the PACCH SAPI. It's
probably a bug that simply doesn't show up due to the above reasoning.
Regards,
Harald
--
- 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)