osmo-bts[master]: dyn TS: if PCU is not connected, allow operation as TCH

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
Thu Sep 1 15:13:11 UTC 2016


Patch Set 2:

(1 comment)

https://gerrit.osmocom.org/#/c/748/2/src/common/rsl.c
File src/common/rsl.c:

PS2, Line 930: o for the BSC, it is not
             : 		 * helpful in any way to know that a PDCH channel fails to
             : 		 * work
> this is not entirely true.  For OML/OSS it is important to understand that 
The wording might be a bit too drastic, but:

My point is that normal PDCH operation has no such OML alerts.
Also, this is about RSL Chan Activ messages, and not OML.

I see your point and it would probably be good to add reporting,
but I'd first like to get dyn TS working like normal PDCH,
i.e. as if they did not appear on the RSL channel activation.

There's also the case of activating PDCH when the PCU is not
running yet, which basically happens at every BTS startup.
The BTS starts, the PCU must not yet be running. Then the
channels are setup (and for dyn TS the non-standard RSL
Chan Act for PDCH mode is sent); the PCU will only start
in a few seconds' time. In that case we'd have to send some
RSL failure back to the BSC, where in the default case the
PCU will come up shortly and the PDCH channels will simply
start working. So it makes no sense to nack at startup.

Determining whether the PCU is considered ok is not trivial.
We'd need to define some timeout (half a minute?) and check
whether a PDCH has not become active in that period.

But the RSL logic expects an ack fairly quickly, or it will
put the channel in a broken state.

At this point, I prefer to cut out the complexity by just
not telling the RSL wire anything about PDCH except
"ack, all is fine, don't worry now"; like standard PDCH.

Let's have reporting of PDCH failure as an OS# feature request?


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I2a0b9730197786b99ff3bc1f08c75f7d279cb1f7
Gerrit-PatchSet: 2
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-HasComments: Yes



More information about the gerrit-log mailing list