Age | Commit message (Collapse) | Author | Files | Lines |
|
This was overlooked during the code review. GCC does not complain
because internally both 'enum handover_scope' and 'bool' are
interpreted as 'int'. Found this while running my WIP testcase
TC_srvcc_eutran_to_geran_a5_3. This change makes it pass.
Related: SYS#5838
Fixes: I4e5b1163a71443d706f14ce4bfd5c2294c320432
Change-Id: I807fd4a0e700e54c67ca3547d9c0c1b442dd1c54
(cherry picked from commit 7c14a12a786b4a297e79a6cf4a84d84393344b54)
|
|
Related: SYS#5838
Change-Id: I4e5b1163a71443d706f14ce4bfd5c2294c320432
(cherry picked from commit 53d05951a5ae0344101fccb58f89c4c1c4d2f8aa)
|
|
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
Related: SYS#5838
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
(cherry picked from commit 2902d91d69d2583bc7dd835fe6b389bc1a78dd27)
|
|
Related: SYS#5838
Change-Id: I731179bf7f5d711ca114e36af661faccf0caa19f
(cherry picked from commit 798a71eb300dfeb4c76e8c3d2973173ae81e1602)
|
|
Related: SYS#5838
Change-Id: I9771d7e1f2073ebf6d900c067885485e54790bca
(cherry picked from commit 0a01573bc1259c1b2dfefbe8eb16a507c8756902)
|
|
Change-Id: Iaa8377919a144e7f3799b76249f579c8f3874145
|
|
According to 3GPP TS 44.018, section 10.5.2.1b.2, only ARFCN values
in range 1..124 can be encoded using the 'bit map 0' format. Before
this patch, ARFCN values belonging to E-GSM band (0, 975..1023) were
ignored in bitvec2freq_list(), and thus not present in the resulting
Cell Channel Description IE.
Change-Id: I17739e6845cd84e2a81bc406dd532541f7c52cb6
Related: SYS#5854
|
|
This commit demonstrates what happens when a cell has channels in
both P-GSM and E-GSM bands (case 'c'). As can be seen from:
Case a) only the BCCH carrier: 10
Case b) more carriers from P-GSM band: 1 3 10 64 99 124
Case c) more carriers from E-GSM band: 1 3 10 64 99 124
in both cases 'b' and 'c' we have the same set of ARFCNs. Carriers
from the E-GSM band are not present at all. This is wrong and will
be fixed in the follow up change(s).
Change-Id: Ied0519c70501f105673a9b36657101063d275058
Related: SYS#5854
|
|
As the comment above the fix suggest, the encoding is in 10ms units.
osmo-bts is also doing the proper:
"""
uint8_t t3105 = *TLVP_VAL(&tp, NM_ATT_BTS_AIR_TIMER);
bts->t3105_ms = t3105 * 10;
"""
Related: SYS#5838
Change-Id: Ie190514ee35d1ca81b70e9180bf7393b973d3504
(cherry picked from commit 8f1597135dc6be84d3b368a2ae78b18383cfb578)
|
|
Change-Id: I1c96305839e6627a36655c2e64da64f0a6704896
(cherry picked from commit 10edefe68bd224cda7d988946e5d456f0b12a0d5)
|
|
Related: SYS#5839
Depends: Iab0a7b4d81592157fc111d1adb9e9f4cb53a94e9 (libosmocore)
Change-Id: I3c0576505a3ceb3cd5cc31dc69c5bc4a86a4ea08
|
|
Related: SYS#5839
Change-Id: I1d0b395c97145b5aa1af4ef67aec9338d2f8f43b
|
|
Related: SYS#5839
Change-Id: I830654f419e6f0a196dc6d3e58422e00b324af9e
|
|
In the field we saw Handover Requests without any Chosen Encryption
Algorithm IE, and osmo-bsc completely failed on those. This made me
understand my mistake from when I wrote this handover code.
So far, from a BSSMAP Handover Request, we (I) used only the Chosen
Encryption Algorithm IE to pick the encryption to use on the target
lchan. That is very wrong.
Instead, figure out the intersection of permitted algorithms MSC & BSC,
and pick the best of those. Which means, actually, completely ignore the
Chosen Encryption Algorithm IE.
In the message, the permitted algorithms are passed as a bitmask. The
current code using gsm0808_dec_encrypt_info() passes this on as an
array. In order to select_best_cipher(), I could convert that array back
to a bitmask. Instead pass the bitmask on from message decoding
alongside the struct gsm0808_encrypt_info in req->ei_as_bitmask.
In handover_end(), change the condition so that we can also pass
HO_RESULT_FAIL_RR_HO_FAIL to emit a Handover Failure.
Related: SYS#5839
Change-Id: Iffedc981b60d309ed2e5decd5efedee07a757b53
|
|
The naming confused me so that I wrote buggy code again. Hopefully this
clarifies which representations the code paths are using.
In the macro code, highlight the error case of n <= -1 explicitly.
Also add ALG_A5_NR_TO_PERM_ALG_BITS. I need the 1<<n case in an
upcoming patch.
Related: SYS#5839
Change-Id: I7557ae97764bba09c906748a18e9031dfb362611
|
|
This patch imposes no logical change in the code on itself, but makes
sure people compiling osmo-bsc uses an old enough libosmocore
implementing Cell Identifier SAI. This is important since adding the SAI
ID (CELL_IDENT_SAI) displaced CELL_IDENT_WHOLE_GLOBAL_PS to a new
number outside of the 3GPP range for cell IDS (4 bits, this way we
garantee we won't have the same problem again).
This means there was an ABI breakage (see Depends below).
As a result, using an osmo-bsc compiled against an older libosmocore
, and then using at runtime against a newer version of libosmocore, will
most probably provoke some RIM features to not work properly, since
libosmocore will handle CGI-PS cell ids sent by osmo-bsc as SAI ones,
and most probably do wrong comparisons when matching (they only match up
to LAI included).
ABI break analysis:
osmo-bsc uses CELL_IDENT_WHOLE_GLOBAL_PS in:
* gsm0808_dec_cell_id_list2() -> this is called on stuff received from the
network, so it's actually fine handling it
correctly as CELL_IDENT_UTRAN_SAI instead
of CGI_PS.
* gsm0808_cell_id_list_add
same_cell_id_list_entries
gsm0808_enc_cell_id_list2
cell_id_to_cgi-> On old osmo-bsc, When
CELL_IDENT_WHOLE_GLOBAL_PS is passed
to be encoded as CGI, RAC byte is
taken for encoding instead of 2nd CI byte.
* gsm0808_cell_ids_match
gsm0808_cell_id_u_match
cell_id_to_cgi -> If CELL_IDENT_WHOLE_GLOBAL_PS as 0x11
(CELL_IDENT_UTRAN_SAI), 1 byte offset when
comparing (1 byte of RAC is taken converting to
CGI instead of the 2nd byte of CI). That means
match would be wrong if 2nd byte of CI differs.
Related: SYS#5838
Depends: libosmocore.git Change-Id Id25e563febdb7640174540136225f399515a0089
Change-Id: I70972efffefd57fd36332fab539683696c32f4a5
|
|
The timer (T4) that controls the re-sending of the BSSMAP RESET can not
be changed via the VTY, althrough it is defined via a tdef struct. Lets
add a description along with default values to make it configurable via
the VTY.
Change-Id: I1fb5699220ab8a643a168567a89c6f381fe433a7
Related: SYS#5796
|
|
Change-Id: Ie4fad0426d1d089156481806a05982a24375b766
|
|
The checks that make sure that an ARFCN falls in the correct range do
not return with -EINVAL as they should, instead nothing happens. (Only
the check for GSM1800 is corrct)
Change-Id: Iddadafe3fbc47e2f980d8e4ab4f320998cb454ff
Related: SYS#5369
|
|
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ifbbafe185931c0f508ff8148ef244f25a9620fd8
|
|
At the moment the BTS configuration is checked, but the check does not
have much consequence other than that some initialization that is not
executed. The BTS will go into the OML bootstrap phase anyway and most
likely fail at some later point due to the invalid configuration. To
reduce noise and unexpected behaviour of the BTS lets make sure that the
OML boostrap phase can only proceed when the BSC conciders the
configuration as valid.
Change-Id: I42c1c26a9b800600787b1266a871f95f2114c26e
Related: SYS#5369
|
|
The manual lacks an example on how to set up an E1 connected BTS.
Especially the relation between trunk number and E1 line number is not
obvious.
Change-Id: I02f5d4fe059e5cc9c3ffc2e3636d812532c09239
Related: OS#5308
|
|
Counting the Assignment success after osmo_fsm_inst_term() meant that we
were counting a cleared out channel mode, which always yielded
signalling mode.
Count the Assignment success *before* terminating, so that we correctly
count the successful assignment as speech mode.
Related: SYS#4878
Related: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7 (osmo-ttcn3-hacks)
Change-Id: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8
|
|
Change-Id: I68b3e794ddf97c80f647c3536ec466217b338af9
|
|
Related: SYS#4878
Related: I17a7702b151ac03fd9f7ecd6927ef42133aad953 (osmo-ttcn3-hacks)
Change-Id: I1fde77d5d5920093ab037184eb3518876804353d
|
|
Change-Id: Ia2c1d59eac556b8f6a56c39abf12b35a3ba807eb
|
|
Similar to paging:attempted, count paging:expired not only per BTS, but
also for the whole BSC. Add active_paging_requests to struct bsc_subscr,
to increase the counter only once if paging expires, and not once per
BTS where paging expired.
Related: SYS#4878
Change-Id: I9c118e7e3d61ed8c9f1951111255b196905eba4d
|
|
Change-Id: Icc4947e68fa46aab180f2047231e51b997cca71b
|
|
Below is an example output:
"""
Received SIGNAL S_NM_GET_ATTR_REP
{
"primary_oml_ip": "192.168.100.100",
"primary_oml_port": "0",
"unit_id": "6969/0/0",
"nv_flags": {
"static-ip": "no",
"static-gw": "no",
"no-dhcp-vsi": "no",
"dhcp-enabled": "yes",
"led-enabled": "yes",
"secondary-oml-enabled": "yes",
"diag-enabled": "yes",
"cli-enabled": "yes",
"http-enabled": "no",
"post-enabled": "yes",
"snmp-enabled": "yes"
}
}
"""
Change-Id: Ic901910878529e6d8b152b3417463bae60644b82
|
|
Change-Id: If99ec89081af4ebd65152fc0a31ebdec491f3876
|
|
osmo-trx-uhd with a B200 has proven to provide bad (lower than usually
considered good) C/I values due to high noise (even with band filters in
place). Hence, default thresholds (gathered from literature on the topic)
are too high and end up in bad algorithm output decisions.
Furthermore, most users of Osmocom don't use it in densely populated
areas, hence RXLEV based algorithm used when C/I based one is disabled
is good enough.
Let's disable C/I based one by default, and let advanced users which
specific needs to enable and confiure thresholds specifically for their
needs (hardware, cell surrounding conditions, etc.).
Related: SYS#4917
Change-Id: If1a73c60695379bcfcd0f44c6ec6dd659563e279
|
|
Related: OS#5324 SYS#5259
Change-Id: I5a3345ab0005a73597f5c27207480912a2f5aae6
|
|
Do not crash in gscon_ensure_mgw_endpoint() if conn is NULL.
Related: SYS#5728
Change-Id: Id579243cc9ebbe8f315cd11754166970329dc9cf
|
|
abis_nm locally declares its own struct for the ipaccess firmware
header, even though libosmocore defines it as well. Lets use the
definition from libosmocore.
Change-Id: I69cb45fc40bd20ea2533cc8cd6a68363b59cc408
|
|
Change-Id: I2cb7b986db9d394db2c912247db861704d2c7c23
|
|
Change-Id: Ibd4f22f268aa5ec3c1b7839e334ffad69f2e50a9
|
|
Related: SYS#4878
Depends: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd (libosmocore)
Change-Id: Ica9f908a1a30f334a24c59471affa11225117e12
|
|
The function generate_ma_for_bts() is called when the OML TEI comes up.
In the same code path boostrap_bts() is called as well. It would be more
logical to call generate_ma_for_bts() from boostrap_bts() since it is
also part of the bootstrapping process.
Change-Id: Ib2ed5b1eac3701cfb3a3e8dd478488ba5404d1fd
Related: SYS#5369
|
|
At the moment check_bts and bootstrap_bts is called only once on startup.
When a new BTS is set up during runtime bootstrap_bts, nor check_bts is
called. This means that some parameters of the BTS stay uninitalized
until osmo-bsc is restarted. Lets rather call check_bts() and then
bootstrap_bts() when the OML TEI of the BTS comes up.
Change-Id: Ie599f809623efd6ea4ab3f39294195fc1ef84b85
Related: SYS#5369
|
|
Change-Id: I087025f9db59348f2f70d4a291f8d887644d6b17
Related: SYS#5319
|
|
Change-Id: I34d29d7d0f66c629367f3d6e8a660e199ecbe080
Related: SYS#5319
|
|
Change-Id: I663023adb4f2381d4b8debb01786801803b3d741
|
|
Change-Id: I3e71bb88db7b1eadff5a73fdb98fe7eee2fc2540
|
|
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: I39b98dcd14219402959646524315d5afea7c08cf
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
|
|
Let's have a short and consistent naming for both ACCH repetition
and temporary ACCH overpower structures, like it's done in osmo-bts.
Change-Id: Ia12c83ad1af4744ce28ba655ac806784f746e88a
Related: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07
|
|
Change-Id: I75b0e289c47841aea22b5966487535cbe855c84f
|
|
The linter (executed by Jenkins) complains:
src/osmo-bsc/bts_vty.c:653: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:654: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:656: ERROR:CODE_INDENT: code indent should use tabs where possible
src/osmo-bsc/bts_vty.c:657: ERROR:CODE_INDENT: code indent should use tabs where possible
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: If3c8c09ddff7cb945425e74344ceb4da989ddffc
|
|
The linter (executed by Jenkins) complains:
src/osmo-bsc/abis_rsl.c:543: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
and blocks changes, adding V-1 when I am changing the related code.
Change-Id: I0cf00ff898e69734850659e8ba0e2ff023f9b2dd
|
|
Change-Id: If933ce0fa0a162c4518ddab840f186ebaa1bcff9
|
|
In the case of ts->pchan_from_config=GSM_PCHAN_OSMO_DYN,
ts->max_primary_lchans will be 8 due to SDCCH8 support, and we don't
want to set lchan->vamos.is_secondary=true for lchans at the end of the
array.
Related: OS#5278
Change-Id: If86af5fafe059d5e830c1f6d37034f7325d9a96c
|