The LAC value currently configured is now printed as hexadecimal value
too.
It can still be entered as a decimal value in order to keep backward
compatibility, though the hexadecimal one is now preferred.
Related: OS#5631
Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4
Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
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
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
Having different names for the same config setting is misleading, so
let's stick to the one used by osmo-bts.
Change-Id: Ide5ceb5db7403a70313405752579e30d7bb94eac
Some nanoBTS firmwares (if not all) are known to not work properly with
SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter
available will be forwarded by nanoBTS to MS, but will still only send
SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping
of BCCH data"). As a result, some MS won't allow registering to the
network.
To avoid this kind of scenario, enable force-combined-si by default on
nanoBTS while still allowing to overwrite the feature through VTY. Other
BTS models are kept with force-combined-si disabled by default as
usually, since they seems to be working fine when SI2ter is enabled.
Related: OS#3063
Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
In default example network, there's no cells with those arfcn.
Furthermore, having those seem to prevent some MS to register against
nanoBTS configured by a BSC using those lines.
Related: OS#3063
Change-Id: Iebe972da3a8442b6ded6d7f9e61a03b9144a843c
Handover decision 2 arguments are now configured by 'handover2 foo'. To match
that scheme, rename the previously 'handover foo' args for handover decision 1
to 'handover1 foo'.
For backwards compatibility, still provide aliases of the original VTY
commands. Writing back the config will result in 'handover1' though.
Change-Id: I7305ae7c04cc70082cd80d42b2ba32ffa399f51a
RRLP is handled in OsmoMSC after the split from NITB, so let's remove
any bogus VTY commands left over in the BSC.
Change-Id: Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38
authentication (optional|required) is no longer needed, the
related decisions are now made in the HLR.
Change-Id: Ib6c6331cc86004c4862067031e4fcb12a6975b63
Authentication is no longer done in the BSC, the variables that
set the authentication policy and the IMSI regex have no longer
any effect.
Remove auth policy and authorized-regexp
Change-Id: Ie31b921b5fd0af5501ec0c77c0f08089c10075e2
Now osmo-bsc.cfg's SCCP addresses work by internal defaults, while
osmo-bsc_custom-sccp.cfg shows how to use custom STP IP address and SCCP point
codes.
Change-Id: Icb41d5adc24b2ee5613be691a201df8f3566e5dd
Pau Espin
Vadim Yanitskiy
Harald Welte
Eric Wild
Vadim Yanitskiy
Philipp Maier