This change implements an additional channel allocation mode, which
can be employed during a TCH channel allocation for assignment.
Selection between ascending and descending order is performed
depending on pre-configured parameters:
* Uplink RxLev threshold and number of samples for averaging,
* C0 (BCCH carrier) channel load threshold.
This is useful in setups where Tx power of the RF carriers cannot be
adjusted +dynamically at run-time and thus BS Power Control cannot
be performed. In such setups the BCCH carrier is transmitting at
relatively higher power than the other RF carriers. The key idea
is to allocate channels in a smarter way, so that UEs with poor signal
would get channels on carriers with high Tx power, while UEs with good
signal could use carriers with lower Tx power.
Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d
Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
A follow-up patch implements a special channel allocation mode, which is
only working for assignment (basically TCH selection for a voice call).
This mode cannot be employed for initial CHANNEL REQUEST or handover due
to the absence of an already established lchan.
Adding this mode to the existing VTY command syntax would be confusing:
channel allocator (ascending|desscending|dynamic)
^^^^^^^
so this patch extends the VTY syntax in a way that it becomes possible
to configure different channel allocator modes for different cases:
OsmoBSC(config-net-bts)# channel allocator mode ?
set-all Set a single mode for all variants
chan-req Channel allocation for CHANNEL REQUEST (RACH)
assignment Channel allocation for assignment
handover Channel allocation for handover
The old command syntax, which is basically 'set-all', is kept for
backwards compatibility, but marked as deprecated.
Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f
Related: SYS#5460
For statistical clarity and site tuning, it is sometimes
desirable to completely disable the use of TCH for signaling.
In the existing version of this VTY command, there is no way to
accomplish this. We can only restrict TCH for signaling non-voice
related actions.
This patch deprecates 'allow-tch-for-signalling (0|1)' and
adds 'tch-signalling-policy (never|emergency|voice|always)' to
provide more options.
Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
Add experimental 'pre-ts-ack' to the 'immediate-assignment' options:
send the IMM ASS even before a dynamic timeslot is switched. This
possibly saves an Abis roundtrip, but may be racy.
When pre-ts-ack is chosen, already do the IMM ASS before the dyn TS
pchan switch is ACKed.
In Immediate Assignment, in case the dyn TS is not ready yet, get the
pchan kind from lchan->type, which already reflects the target type, and
not from ts->pchan_is, which still reflects the previous pchan type.
Related test is in I2ae28cd92910d4bc341a88571599347a64a18fe5
Related: SYS#5559
Change-Id: I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
This patch adds only the VTY config option without any effect, to ease
patch review.
The implementation follows in I56c25cde152040fb66bdba44399bd37671ae3df2
The new config option is written so that further variants of Immediate
Assignment sequencing may be added easily.
See also I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74.
Related: SYS#5559
Change-Id: I710343d1728153faf3db9758ff5a1ef26bb8d3d4
In the command
bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> deactivate fr
the final argument indicating the channel type does not make sense and
is not actually used. Define a separate vty command for 'deactivate', so
that it doesn't require arguments only used for 'activate'.
Change-Id: Ibdeca3b1d75b9f6092f566544e9d5f4da67fffce
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
Store the config option whether the channel allocator should try to
avoid lchans with higher interference levels reported in RES IND.
The actual implementation of avoiding interference follows in
I844494092193811dfd9fa4d52983cbaed0fc9248
Related: SYS#5313
Change-Id: I8b62d0b41ad9e908b27713db9219e3dbc1ebaab7
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
Add VTY command to trigger an intra-cell re-assignment, also allowing to
re-assign to a secondary VAMOS lchan.
Related: SYS#5315 OS#4940
Change-Id: If006f5caaf83b07675f57e5665cfa79328da55e6
A subsequent patch will add to this VTY command, so let's first test the
current status as a baseline.
Change-Id: I6379e306fb8fa6ec227125c6cf14893d674e7596
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
Vadim Yanitskiy
Michael Iedema
Keith Whyte
Pau Espin