On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
[translated from german] is it certain that we switch a channel to PDCH only when gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message.
We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; }
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.)
Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that.
~Neels
Hi Neels,
On Tue, Jun 28, 2016 at 03:25:48PM +0200, Neels Hofmeyr wrote:
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
[translated from german] is it certain that we switch a channel to PDCH only when gprs mode != none?
I'm not sure if your response covers the question I raised.
What if you have a openbsc.cfg with a bts that has 'gprs mode none' but still has a timeslot in GSM_PCHAN_TCH_F_PDCH mode? The intended operation in that case is that it will be treated as a pure TCH/F, and no attempts to switch to PDCH are made.
On Wed, Jun 29, 2016 at 07:37:33PM +0200, Harald Welte wrote:
Hi Neels,
On Tue, Jun 28, 2016 at 03:25:48PM +0200, Neels Hofmeyr wrote:
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
[translated from german] is it certain that we switch a channel to PDCH only when gprs mode != none?
I'm not sure if your response covers the question I raised.
I see, I mistook the 'gprs mode' for the internal TS flag whether GPRS is currently active on a TCH_F_PDCH, but you mean the VTY config item.
What if you have a openbsc.cfg with a bts that has 'gprs mode none' but still has a timeslot in GSM_PCHAN_TCH_F_PDCH mode? The intended operation in that case is that it will be treated as a pure TCH/F, and no attempts to switch to PDCH are made.
Indeed, we would switch to PDCH anyway. Aside from it being meaningless to have GSM_PCHAN_TCH_F_PDCH time slots with 'gprs mode none', I agree that we shouldn't send PDCH ACT in that case.
It's easy to work around: just configure TS as GSM_PCHAN_TCH_F. So I'm not putting this high up on the todo list. http://osmocom.org/issues/1765
~Neels
Hi Neels,
On Tue, Jul 05, 2016 at 11:57:35AM +0200, Neels Hofmeyr wrote:
What if you have a openbsc.cfg with a bts that has 'gprs mode none' but still has a timeslot in GSM_PCHAN_TCH_F_PDCH mode? The intended operation in that case is that it will be treated as a pure TCH/F, and no attempts to switch to PDCH are made.
Indeed, we would switch to PDCH anyway. Aside from it being meaningless to have GSM_PCHAN_TCH_F_PDCH time slots with 'gprs mode none', I agree that we shouldn't send PDCH ACT in that case.
The point is that when you enable/disable GPRS services on a cell, you want to modify the one (intuitive) 'gprs mode' statment in your config, and not have to remember that you also need to change the configuration of every timeslot on that BTS.
I think particularly in testing scenarios (BTS used as tester for modems/m2m devices) or in research or education type applications this is a very frequent use case.
It's easy to work around: just configure TS as GSM_PCHAN_TCH_F. So I'm not putting this high up on the todo list. http://osmocom.org/issues/1765
Given that it should be super simple to fix (like a handful of if statements?), I'd rather do it soon than forget about the ticekt...
To know the origin of your website traffic, you must look through traffic channels for organic, paid, or referral activity. After reviewing these channels, you will be better prepared to arrange the collected information into your research strategy. Working with a professional in writing your dissertation proposal could make the process much easier.
Visit Our Website: https://thedissertationhelp.co.uk/dissertation-proposals/
-
Harald Welte -
Neels Hofmeyr -
norajellis56＠gmail.com