The manual currently does not mention ACCH repetition yet. Lets
add some info on how to set up ACCH repetition correctly.
Change-Id: I1e27ac955882497bbeefac0c830708dd18ad46b3
Related: SYS#5114
So far osmo-bsc would enable Uplink DPC (Dynamic Power Control) only
for osmo-bts, and the 'static' mode for all other BTS models. This
decision dates back to the time when ip.access specific encoding for
dynamic power control parameters was not implemented, and the MS
Power Parameters IE was sent empty in the RSL messages.
Let's make a step forward by enabling Uplink DPC by default for
all BTS models which declare the API for vendor-specific encoding
of the power control parameters. Currently this includes osmo-bts
and nanoBTS, both supporting ip.access specific format.
Change-Id: If86d27d4332af3d82f862737340d061e42e34eba
Related: SYS#4918
For balancing load across congested cells and across congested TCH/*
kinds, instead of comparing the number of lchans above the configured
congestion threshold, compare the percent of lchans of overload.
In short, using a percentage prevents cells with less min-free-slots to
fill up 100% while neighbor cells still may have several free lchans
available.
An obvious example of why this is desirable is illustrated by
test_balance_congestion_by_percentage.ho_vty:
Cell A has min-free-slots 2, and has all slots occupied.
Cell B has min-free-slots 4, and has 2 slots remaining free.
If we count congested lchans as in current master: cell A has a
congestion count of 2: two more lchans in use than "allowed". If we move
one lchan over to cell B, it ends up with a congestion count of 3, which
is worse than 2. So when counting lchans, we decide that cell A should
remain full.
Instead, when comparing percentage of remaining lchans, we would see
that cell A is loaded 100% above congestion (2 of 2 remaining lchans in
use), but when moving one lchan to cell B, that would only be 75% loaded
above its treshold (3 of 4 remaining lchans in use). So a percentage
comparison would cause a handover to cell B.
Related: SYS#5259
Change-Id: I55234c6c99eb02ceee52be0d7388bea14304930f
This new CTRL interface allows users of this BSC (such as attached PCU)
to gather neighbor information.
This interface is needed for PCU to translate ARFCN+BSIC keys provided
by MS in the Um side into CGI + RAC keys used to identify target cells
in RIM procedures against SGSNs on the Gb interface.
This patch extends the already existing neighbor information storage in
the VTY by allowing storage of CGI + RAC (RAC couldn't be stored
beforehand).
Related: SYS#4909
Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
This was started in 2017 before the NITB split. Let's align it with
reality, mostly in terms of naming and making explicit what was
implemented.
Change-Id: Ib4e66b565a1edfc5ea8c1446f911011bfd4b1642
Backwards compatibly, introduce timer groups in OsmoBSC, and move some
non-specified T timers to new X timers:
T993111 -> X3111
T993210 -> X3210
T999 -> X4
Why X4? because there already is an X3 used elsewhere in Osmocom, and I find
it less confusing if X-numbers don't repeat across programs. See
https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers
Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc.
This makes the MGCP timeout configurable for the first time.
Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T
timers to X timers on-the-fly. All previous VTY commands still work, and new
'timer [(net|mgw)] ...' commands are added. timer.vty shows this.
Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so
that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands.
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
This is needed to be able to force MGW to provide an IPv4 address during
MDCX, since IPACC protocol on the BTS side only supports IPv4, but one
may need IPv6 side at the same time on the core side.
By moving the IPACC MDCX request to a later step, the BSC gains
knowledge of the local address on each side (BTS, MGW), and if they
don't match (ie. BTS uses IPv4 and MGW uses IPv6), it can then get MGW
to offer an IPv4 address during MGCP MDCX containing the BTS IPv4
address. At that point, the MGW can see the mismatch and provide an IPv4
address in the MGCP MDCX ACK, which can then finally be communicated to
the BTS during IPACC MDCX phase.
Previous order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGW local IP addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IP addr)
BSC -> BTS: IPACC MDCX (set MGW IP addr)
BSC <- BTS: IPACC MDCX ACK
BSC -> MGW: MDCX (set BTS IP addr)
BSC <- MGW: MDCX ACK
New order:
BSC -> MGW: CRCX
BSC <- MGW: CRCX ACK (get MGCP local IPv6 addr)
BSC -> BTS: IPACC CRCX
BSC <- BTS: IPACC CRCX ACK (get BTS local IPv4 addr)
BSC -> MGW: MDCX (set BTS IPv4 addr)
BSC <- MGW: MDCX ACK (here MGW changes its local addr to IPv4)
BSC -> BTS: IPACC MDCX (set MGW IPv4 addr)
BSC <- BTS: IPACC MDCX ACK
Change-Id: I4de5ea5c94c1482c9cb0b6386997a942edc60e32
osmo-nitb supports the modification of an lchan if the lchan is
compatible but in the wrong mode. This feature was dropped in the
transition to AoIP/bsc-split. However, osmo-bsc still has code to
generate and parse the messeages, but the FSMs do not support a mode
modify yetm
Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in
order to support mode modify again
Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb
Related: OS#4549
The files have been used successfully in the past weeks to bring up a
variety of different combinations of Ericsson DUG20 + RUS.
Change-Id: I046f786d68f7cd3fd21693142bd1315bf40696f5
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.
Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
Those adoc files are only used by osmo-bsc.git and openbsc.git
(osmo-nitb), and the later is deprecated and no longer maintained, which
means new features are only added to BSC. Hence it makes no sense to
keep the doc shared between both.
Change-Id: I20aa60d2f4111d66e922f3e2a73a20352ec1f7e4
This adds osmo-bsc config files for Ericsson RBS2308, Siemens BS-11 and
Nokia InSite which were working in July 2020 to get the BTS initialized,
recognized by MS and up to signalling.
Voice/TRAU support is still missing in OsmoBSC, but should be added
relatively soon.
Change-Id: I1fe15cc3654025e52fc1110ac3052fb1f7a009a0
Depends: osmo-python-tests I896b99032d94ba0cdd340a8eed7c7b625661ad69
Closes: OS4651
This option has been deprecated back in 2018 [1], but for some
reason we still have it in the configuration examples, so it
prevents osmo-bsc to allocate TCH/F on dynamic timeslots.
[1] Ib2335d02ea545aff837aadd49f15b2fdb418c46e
Change-Id: Icc82f6178d18dccc7207485b25dc3bdad91a0052
Related: SYS#5014
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built
before the docs.
Remove bsc_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-bsc --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I5dc872149154e1a949bb6a2b9bbc1461e0fc51f6
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal
MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty
command, remove the member.
[1] "mgcp: use osmo-mgw to switch RTP streams"
commit 39c609b7c9
Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a
Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
I notice that some merges seem to have missed updating the
bsc_vty_reference.xml file. Re-generating it from current master yields these
changes.
Change-Id: I75269cbed8dd62be23293fd2c1470af6f61e6ad2
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE
contains two parameters related to 11 bit Access Burst support:
- ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be
used in the PACKET CHANNEL REQUEST message, the PTCCH/U block,
PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS
messages on the PRACH (if present).
- EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall
use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF
establishment on the RACH or on the PRACH (if present).
The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls
the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may
be hard to understand this from its name and description.
This patch is actually a group of tightly related changes:
- deprecate 'gprs 11bit_rach_support_for_egprs (0|1)':
- update its description to avoid any possible confusion,
- print a warning if it's used in non-EGPRS mode,
- print a warning if it's still used;
- introduce '[no] gprs egprs-packet-channel-request':
- ensure that it can only set / printed in the EGPRS mode;
- take a chance to clean-up / rename the related struct members:
- 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request',
- remove 'supports_egprs_11bit_rach' from 'gprs_cell_options'
because we already have 'ext_info.use_egprs_p_ch_req' there.
Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
Link to the osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain
the 'cs7' client configuration.
Related: OS#2767
Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals)
Change-Id: I5b4973901f02046322b852fd9862517982d21bd9
All timeslots are configured for full rate, so the codec list must also
have a full rate codec. Fix this error on startup:
"Configuration contains mutually exclusive codec settings -- check configuration!"
All other example configs don't have mutually exclusive codec settings.
Related: OS#3739
Change-Id: Iddac13c7d644ed57b6d9e6a57d23d88c01bd8b8e
Replace python 2 code using pychart to draw a graph in
osmux-reference.adoc with the generated svg file. The upstream of
pychart is dead, there is no python 3 version, and python 2 is EOL at
the end of 2019.
This is the only time we ever made use of pychart in osmo-gsm-manuals,
so with this change, we can just drop the dependency.
I've generated the chart by saving the python code in chart.py, then:
$ ./chart.py --format=svg --font-size=3 > chart.svg
Related: OS#2819, OS#4193
Depends: osmo-ci I754b133d77743582bd84c33c74ecc9eb9ca4c0ef
Change-Id: I36b721f895caee9766528e14d854b6aa2a2fac85
SCCPlite is long supported (again) by osmo-bsc, let's remove the
outdated pointers to osmo-bsc-sccplite.
Change-Id: Ia3d831aca7c3c7ef9f257e974faf6e8e360c59f5
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7