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 42edba5fe67ac96d4dde6ebb5f5d84fea9124f4f (commit)
discards 370a91c4eac99948376c2175ef9e352c70be2b53 (commit)
via 7ea38df5378309a5eb831125dbebbec34aab107e (commit)
via bf6bae2b2363a182bb1b95574c2922bf4257c4d9 (commit)
via 8a148613b4c93f5a25dd2a2d9929de75882adbc5 (commit)
via 4dfc3da96bbad9e6a8641233c87a05a46af7d906 (commit)
via 9faaf4ecf01322189808901398e06d7e4f14560d (commit)
via 3b2e5de3aea8652969e7bbd1e3c04206dce51330 (commit)
via 988f634c97d070840f4ffc952f6bac32d967859b (commit)
via e77bcaecb6e45b55b8e31fea7cf10c2652431c1c (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 (42edba5fe67ac96d4dde6ebb5f5d84fea9124f4f)
\
N -- N -- N (7ea38df5378309a5eb831125dbebbec34aab107e)
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=7ea38df5378309a5eb831125dbebbec…
commit 7ea38df5378309a5eb831125dbebbec34aab107e
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:
include/osmo-bts/gsm_data.h | 1 +
include/osmo-bts/pcu_if.h | 3 ++-
include/osmo-bts/pcuif_proto.h | 6 ++++--
src/common/l1sap.c | 30 +++++++++++-------------------
src/common/lchan.c | 16 ++++++++++++++++
src/common/measurement.c | 16 +---------------
src/common/pcu_sock.c | 5 ++++-
src/osmo-bts-litecell15/l1_if.c | 2 +-
src/osmo-bts-litecell15/oml.c | 27 +++++++++++++++++++--------
src/osmo-bts-sysmo/l1_if.c | 8 +++++++-
src/osmo-bts-sysmo/oml.c | 27 +++++++++++++++++++--------
11 files changed, 85 insertions(+), 56 deletions(-)
hooks/post-receive
--
Osmocom BTS-side code (Abis, scheduling, ...)