openbsc[master]: lchan: Release channel in case of late activation ack

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Sat Aug 20 01:23:51 UTC 2016


Patch Set 2:

(1 comment)

https://gerrit.osmocom.org/#/c/713/2/openbsc/src/libbsc/abis_rsl.c
File openbsc/src/libbsc/abis_rsl.c:

Line 1134: 				dyn_ts_switchover_complete(lchan);
so this first "accepts" the act ack, but then tells
the BTS to release the channel right away.

For dyn TS it might be safer to set
dyn.pchan_is = dyn.pchan_want = GSM_PCHAN_NONE,
because of the logic in rsl_rx_rf_chan_rel_ack():
switching on PDCH will only happen if pchan_is != GSM_PCHAN_PDCH
and if pchan_is == pchan_want.

If the broken state happened while trying to switch to PDCH,
lchan->type might be set to none, the call to
dyn_ts_switchover_complete() will thus set pchan_is = PDCH
and rsl_rx_rf_chan_rel_ack() will skip the PDCH activation.
But after the broken state we might need that to happen?

To clarify: "release" normally means "release voice",
and for dyn TS that is synonymous to "activate data", so
we always want to activate PDCH after this.

Complication: dyn TS also introduce a non-std chan act and
rf_chan_release message for PDCH, so we could also receive an
act ack here that was meant for the PDCH activation request.

I'm only trying to figure this out theoretically.
Do you have a scenario to test this and make sure?
Can a broken channel happen anytime, or only in specific cases?


-- 
To view, visit https://gerrit.osmocom.org/713
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I63dc0deaf15ba7c21e20b1e0c7b85f0437e183ed
Gerrit-PatchSet: 2
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger at freyther.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-HasComments: Yes



More information about the gerrit-log mailing list