| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In osmo-nitb, the way TCH lchans were assigned often resulted in mismatching
TCH kinds, causing problems in the lack of transcoding. Hence
dyn_ts_allow_tch_f was introduced as a workaround.
Now however, we always assign an SDCCH to a requesting MS first, and only later
assign a TCH channel, which then adheres to the codec list configured at 'msc'
in the vty config. Hence it is now considerably harder to obtain a mismatch.
Furthermore, forcing specific codecs is possible by simply omitting the
unwanted ones from the msc config's codec-list. The equivalent of
'dyn_ts_allow_tch_f 0' could be e.g. 'codec-list hr3 hr2 hr1'.
Change-Id: Ib2335d02ea545aff837aadd49f15b2fdb418c46e
|
|
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
The changes to abis_test and gsm0408_test show that this code now handles
3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded
PLMN.
Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the
presence of the third digit of the MNC. Always reply with all leading zeros.
Adjust the expected results in ctrl_test_runner.py, to show that it works.
In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use
of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters
and detect errno returned by strtol() (in contrast to atoi()).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore),
I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore)
Change-Id: I8e722103344186fde118b26d8353db95a4581daa
|
|
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ic16bc0bab3f2d4721e86a1a04f9d9f988d777df2
|
|
Change-Id: Ie597eae82722baf32546331e443dd9d94f1f25e6
|
|
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
The bit-mask of permitted ciphers from the MSC (sent in ASSIGNMENT
COMMAND) is intersected with the vty-configured mask a the BSC.
Finally, the best (highest) possible cipher is chosen.
Change-Id: I1d1c8131855bcab2392b4f27f6216bdb2fae10e0
Closes: OS#2461
|
|
Change-Id: I07d4a48af3154ee4d904686f230a51b8b8a94ff9
|
|
Change-Id: I7910ce8098d5431e41409bf09429ae4221efb360
|
|
Some part of the network init was common between libbsc and libmsc in the old
openbsc.git repository. Now osmo-bsc.git is independent with its own copy of
the gsm_network initialization. So move it over to libbsc.
Change-Id: I8968787a5f0b078619264f0cb42349a9bc7943af
|
|
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which
tells an MS requesting a channel to wait for a specified amount of
time before trying to request a channel again, i.e. the wait indicator
controls the T3122 timeout value in the MS.
Previously, the wait indicator was fixed to 10 seconds.
This is not sufficient if there are a lot of MS requesting channels
because the MS will retry too soon. Instead of using a fixed value,
maintain a dynamic wait indicator value based on average channel load.
The load (used vs. available channels on a BTS) is sampled once per
second, and once 8 samples have been collected we update a BTS-specific
T3122 wait indicator based on the measured load.
While the wait indicator could go up to 255 seconds, this initial
implementation keeps it in the range from 10 to 128 seconds.
Further experimentation and testing will show whether higher wait
indicator values are desirable, if the sampling rate needs to change,
or if the function mapping the load measurement to a wait indicator
value should change (currently we map the load average linearly into
the range [10, 128] inclusive).
Change-Id: I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
Related: OS#2592
|
|
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
|
|
The LU reject cause (like anything MM related) is under control of
OsmoMSC, not BSC.
Change-Id: I559ae31d67726845c9699c8b6127e21c6f63ace6
|
|
There still is a lot of dead code that we inherited from the NITB
days, let's remove more of it.
libtrau will be re-introduced as part of osmo-mgw later.
Change-Id: I8e0af56a158f25a4f1384d667c03eb20e72df5b8
|
|
Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
|
|
Change-Id: I64d84c52f6e38e98144eb9be8f0ab82e0e1f6cca
|
|
A number of the GSM timers (including T3109) had no reasonable
default values if not specified in the VTY / config file. Together
with unconditional writing to the config file, this created
config files with a persistent setting for important timers as '0'.
To make things worse, many of our example cofig files suffered from the
same problem.
Let's avoid this from happening by
* having reasonable defaults if nothing specified in the config file
* conditionally savingg timers only if they differ from default
* reject any timer values that state zero during start-up (see previous
commit)
Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8
Closes: OS#2380
|
|
In case the counter group allocation fails, we must handle this
gracefully and fail the allocation of the parent object, too.
RelateD: OS#2361
Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21
|
|
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
|
