5 Sep
2016
5 Sep
'16
6:13 p.m.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom BTS-side code (Abis, scheduling, ...)".
The branch, neels/dyn_no_pcu has been updated
discards 7ea38df5378309a5eb831125dbebbec34aab107e (commit)
via 3e4ea873b75890765dfa241652be808d943d0aa5 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (7ea38df5378309a5eb831125dbebbec34aab107e)
\
N -- N -- N (3e4ea873b75890765dfa241652be808d943d0aa5)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-bts/commit/?id=3e4ea873b75890765dfa241652be808…
commit 3e4ea873b75890765dfa241652be808d943d0aa5
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Aug 22 23:07:09 2016 +0200
dyn TS: if PCU is not connected, allow operation as TCH
Before this patch, Osmocom style TCH/F_TCH/H_PDCH dyn TS were paralyzed if no
PCU was running. The state of the dyn TS would lock up in the PDCH activation
phase since the PCU never completed the process.
Make more robust, i.e. don't concern the BSC with PDCH activation failures.
This matches the way plain PDCH TS work: besides declaring the TS as PDCH, the
BSC is not involved and is not told about errors.
During PDCH deactivation, still wait for the PCU to tear down the PDTCH SAPIs,
but in case no PCU is connected, send a rel ack right away.
Thus, the BSC will happily switch Osmocom style dynamic timeslots to and from
PDCH mode, using the dyn TS as voice channels as needed, and not caring about
possible PDCH failures. GPRS starts working right away as soon as a PCU
connects, regardless of dyn TS having been used for voice any number of times,
and without another switchover needed.
In detail:
In rsl_rx_chan_activ(), upon receiving a PDCH activation, send an RSL chan act
ack right away, unconditionally (with an explaining comment). Do not concern
the Abis link with PDCH activation failures.
Since we're acking right away now, drop the chan act ack that would follow
after the PCU activation: as before dyn TS, only send acks and nacks for
rel_act_kind == LCHAN_REL_ACT_RSL (PDCH runs as LCHAN_REL_ACT_PCU).
In dyn_ts_pdch_release, indicate that the PCU is not connected by means of
returning 1. In rsl_rx_rf_chan_rel(), use this indicator to send a rel ack
right away if the PCU is not connected.
Change-Id: I2a0b9730197786b99ff3bc1f08c75f7d279cb1f7
-----------------------------------------------------------------------
Summary of changes:
src/common/rsl.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
hooks/post-receive
--
Osmocom BTS-side code (Abis, scheduling, ...)