| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
gsm_bts_alloc() ought to do all static initialization, so that e.g. unit tests
can use an initialized bts struct that is fully usable, just not registered at
the gsm_network.
For example, two INIT_LLIST_HEAD() and various system information data pointers
(pointing to proper places within the same bts struct) should definitely never
be omitted.
This fixes the remaining errors of gsm0408_test's SI tests, as revealed by a
sanitizer build using gcc (Debian 7.3.0-12) 7.3.0.
Fixes:
../../../../src/osmo-bsc/src/libbsc/system_information.c:613:3: runtime error: null pointer passed as argument 1, which is declared to never be null
Initializing the bts->si_common.rach_control results in different expected
bytes for SI2. The initialized values are
bts->si_common.rach_control.re = 1; /* no re-establishment */
bts->si_common.rach_control.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */
bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */
bts->si_common.rach_control.t2 = 4; /* no emergency calls */
Causing a change to e5 04. 04 is t2 = 4, and the remaining values are verified by:
uint8_t re :1,
cell_bar :1,
tx_integer :4,
max_trans :2;
>>> hex(1 + (9 << 2) + (3 << 6))
'0xe5'
Change-Id: I13ef24bbe0f1fbe49465e67a0b67d6fd69fff3b1
|
|
In order to avoid code duplication the feature list (bit masks) and
the desciptive value strings as well as the function to set and get
the feature bits have been moved to libosmocore.
- use feature list functionality provided by libosmocore
Depends: libosmocore Change-Id Id0c35aef11aa49aa40abe7deef1f9dbd12210776
Change-Id: I3e80517539cc5d0e5d8189d434a5e3cc0fdea1a0
|
|
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
|
|
Move from using deprecated gsm48_construct_ra(), which uses a buf, to
gsm48_encode_ra(), which uses a gsm48_ra_id argument. Pass struct gsm48_ra_id
around instead of a buf.
struct gsm48_ra_id is the "encoded" representation of the bytes in a typical
MCC-MNC-LAC-RAC (04.08 Routing Area Id IE, 3GPP TS 24.008 ยง 10.5.5.15). Using
the struct spares using magic numbers for byte offsets.
In the process, fix a sanitizer warning for unaligned access by using memcpy()
instead of pointer assignment:
osmo-bsc/src/libbsc/abis_nm.c:2857:27: runtime error: store to misaligned address 0x7ffe8e0d6695 for type 'uint16_t', which requires 2 byte alignment
Note that (besides removing a now unnecessary cast) the gsm0408_test and
abis_test tests of RAI / CGI encoding remain stable, which indicates that the
new code is still correct.
Change-Id: I0d3908fb8ca1e2e669d257b5d59b40675fa85d06
|
|
After recent libosmocore commit "implement support for 3-digit MNC with leading
zeros" c4fce1425e19d604c199c895e227dc2519110456
Id2240f7f518494c9df6c8bda52c0d5092f90f221, struct gprs_ra_id has a new member,
namely mnc_3_digits. In gprs_ra_id_by_bts(), this new member is now not
initialized and may end up having an arbitrary value, which then may amount to
mnc_3_digits == true. Hence the resulting BCD representation of the MCC-MNC may
inadvertently and randomly indicate a leading zero on the MNC.
Use a struct assignment so that all members are guaranteed to be set, and so
that mnc_3_digits will be zero in all cases.
Since above libosmocore commit, nanobts_omlattr_test fails "randomly", fixed by
this patch.
Change-Id: I872ae3b2b0a0cd8f932f3a5fbc77c0dbfcb28bbf
|
|
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Change-Id: I0a5ac3a08f992f326435944f17e0a9171911afb0
Related: OS#2591
|
|
Move gsm_data.c and handover_cfg.c to libbsc, where they belong.
This leaves libcommon utterly empty, drop it.
Change-Id: I6178061fa30c7e1a4c22c29d3c8f508b1033569f
|
