Order the features and add a comment that reminds of updating OsmoBTS
to actually report the new features that are assumed to be supported
here.
Related: SYS#5922, OS#5538
Change-Id: I6f041648990db4ae479538cf3970c826bc6703ed
pcu_sock.c: In function ‘pcu_tx_info_ind’:
pcu_sock.c:197:2: error: #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
197 | #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
pcu_sock.c:199:2: error: #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
199 | #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
they made it here from osmo-bts.git
(b4999b60d4 states that the PCUIF support
was copied from there). The gitlog shows that these warnings were added
in 744f745d7a508605254afa8f78412ad410d153b0 by jolly (in 2012!)
together with the PCUIF support, and before
c1368d4ebe49f8e01f1f5fff3bc3583cb5960c1d these warnings were in German:
"ist dl_tbf_ext nicht falsch?"
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: I9ef7e18f56aa86b48f0ffeec58406260736170f3
From Vadim in https://gerrit.osmocom.org/c/osmo-bsc/+/27818
By checking !(link_id & 0xc0) we actually make sure that this is not
SACCH. So the comment "but not if the link_id contains a TCH flag" is
wrong, there is simply no such thing like "a TCH flag".
Change-Id: I8f0f6d7bf952426fd2f27802f1499d6ee8981982
If the BTS tells us SAPI=0 is gone, there is no point in trying to keep
the lchan around for SAPI=3, as it is not possible to operate GSM with
SAPI=0 gone.
This occurred with RBS6000, which don't seem to send RLL REL IND for
SAPI3 after doing so for SAPI0. However, rather than an
ericsson-specific hack, let's make this the general rule: If SAPI=0
is gone, don't stop the lchan from being released.
Change-Id: Ia9caa5b0a5efdc459d94621367376927959a6e65
Related: OS#5530
If we receive something unexpected, log it (and free the msgb!)
Change-Id: I43fab6a3a1c5e7a6545d6ef848636f5ba1be1576
Related: OS#5530 (only tangentially related)
The penalty timer low_rxqual_as() is only supposed to apply on an
intra-cell re-assignment. However, a segfault has been reported that
apparently applies it to inter-BSC handover.
Make sure that this timer applies only to re-assignment. In effect this
makes sure that the target bts is non-NULL and avoids the segfault.
Related: OS#5525
Change-Id: Ifdb9891fbe7e3f3423a96371def4fcbf2fc0bc0d
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. Since we alrady have code to encode it, let's
just always add it - it certainly won't hurt.
Change-Id: I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
Closes: SYS#5906
This is cosmetic change making the default multi-rate configuration
easier to read/understand and modify.
Change-Id: I3d03c2188d007a60a86961a346744400bc81d4e6
Related: SYS#5917, OS#4984
* Always say 'codec mode', not just 'codec'.
* Suggest proper modes in AMR_{TH,HY}_HELP_STR.
* Use 3GPP's definition of threshold and hysteresis.
* Clarify that threshold and hysteresis values are in 0.5 dB steps.
Change-Id: I996eae8aafeb2850e5e1a6f5a7764d745e1289b5
Related: SYS#5917, OS#4984
Now that we have separate header/code files for the power control,
let's move the related definitions there. This change makes the
code consistent with osmo-bts, where it's already done this way.
Change-Id: I1cb3f6bfba0306e8f371dcd5162d1813beb3a088
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: Ie3d4b481cbfacf27004787616e22b6f8a863b47b
When the assignment succeeds, the assignment_request has taken effect
and whatever it requested should now be in effect.
Hence copy the new RTP information from the assignment_request to the
conn's storage indicating what is currently used, always, not only when
lchan_changed == true. The RTP information may have changed also from a
Mode Modify where the lchan stays the same but changes its mode of use,
e.g. from signalling to voice.
When there is no RTP involved, this data is zero or empty, so there is
no harm in copying it, always.
Related: SYS#5916
Change-Id: I0788d1f013b8f820f559b6ed58a5f9bb8a02e0b4
When the assignment fails, we roll back the MSC side RTP endpoint at the
MGW that may have been created before the failure occured. On success,
we clear the mgcp_ci pointer so it is not rolled back.
Always clear this, not only when lchan_changed == true. That is because
a channel Mode Modify may also have added a voice stream that should
retain the newly created RTP endpoint at the MGW.
If no voice stream is involved, the pointer should already be NULL.
There is no reason to have a condition for clearing this pointer.
Just always clear it.
This fixes all voice calls that modify a TCH lchan from signalling-only
to voice mode. Before this patch, their MSC side RTP endpoint was DLCX'd
right on assignment success.
In particular, this fixes Emergency Calls (which usually get a TCH lchan
assigned right from the start, and hence do a Mode Modify to add voice).
Related: SYS#5916
Change-Id: I5ab10ee7fd9c5d7608e8a06893881d990943feed
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. TRX1/C1 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Change-Id: Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
When bad RxQual causes handover to a cell with weaker RxLev, then
handover oscillation *will* happen, as shown in test_rxqual.ho_vty.
Introduce a penalty timer for a cell where we had bad RxQual.
This delays handover back to the cell with stronger RxLev by the penalty
timeout; hopefully the interference is gone after the timeout.
Usually, we set new configuration elements so that osmo-bsc behaves the
same as before the config item was added. In this instance, this makes
no sense, because no-one ever wants handover oscillation from bad
RxQual, which is guaranteed to happen without the new penalty timer. Set
it to 60 seconds by default, same as other penalty timers.
Related: SYS#5911
Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
This add support for handling inbound MESSAGE STATUS QUERY from the CBC,
and responding with MESSAGE STATUS QUERY COMPLETE or MESSAGE STATUS
QUERY FAILURE, as applicable.
Change-Id: I3b738dc29d0ead4f735abeeb6960d3675cb05ae2
Related: SYS#5909
I find it weird that we store the A5 algorithm ID in a format that
is used on the wire: N + 1 (valid for both A-bis and A interfaces).
What confused me even more is that in some functions we print it
as if it was in a normal, human-readable format. And this is
also why one can see weird constructions like:
if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... }
Let's ensure that our internal structures use the A5/N format:
alg_id=0: A5/0 (0x01 on the A-bis/A interface)
alg_id=1: A5/1 (0x02 on the A-bis/A interface)
alg_id=2: A5/2 (0x03 on the A-bis/A interface)
...
alg_id=7: A5/7 (0x08 on the A-bis/A interface)
so that we can print and compare the value of alg_id without using
additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n'
as it most clearly indicates which representation it is storing.
This is how the above code snippet would look like:
if (lchan->encr.alg_a5_n > 0) { ... }
Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
When copying the CBS page content from CBSP to RSL data structures, we
use the User Information Length as length argument in the memcpy. The
logic for that is that only this part of the message contains valid
data.
However, as the user information length is not passed on via RSL or
transmitted over the air, the receiving MS will get a page with
zero-initialized padding, rather than whatever the originator of the
message has specified. As zero bytes in the 8bit domain might get
translated into @-characters in the 7bit domain, this creates problems.
So instead, let's always copy the entire page (82 bytes) to ensure
transparency when passing on information from CBSP to RSL.
Change-Id: Iffcf1f6a7d41a08a2feffc6f2ac5634d940b63aa
Closes: SYS#5904
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the abovementioned IEs are present
in the original message, they must be delivered to the SMLC too.
Change-Id: Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Depends: libosmocore.git I8775a93cf4089b1752d040e43d2cba6b8997f955
Related: SYS#5891
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the LCS Client Type IE is present
in the original message, it must be delivered to the SMLC too.
Change-Id: Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
It's really confusing having a "default" struct whose inner values are
changing based on previous state. Furthermore, it's only used in
generate_si13() so there's no need to keep it outside the function.
Let's move it inside the function and rename it to avoid confusion.
Change-Id: I3ae4dd017dd4dad10c0365d21727666dd8e9fd41
It makes no sense to enable that field if the ext_info.egprs_supported
field marks EGPRS as disabled.
From TS 44.060 11.2.5a:
"""
This message may be sent by an EGPRS capable mobile station
*in a cell supporting EGPRS* and where the EGPRS_PACKET_CHANNEL_REQUEST
parameter indicates that this message shall be used.
"""
Related: SYS#5891
Change-Id: I5ac173116f8681d7340b75b2baff110158fab9fd
If "bts->gprs.mode" was changed dynamically at runtime (VTY or CTRL), it
could happen that the egprs_supported was kept as "1" if the dynamic
change was EGPRS->GPRS.
In summary, if EGPRS support was set, it couldn't be unset until BSC was
restarted.
Related: SYS#5894
Change-Id: Id2c2319044da474642c4cc710baa27cfee4fb592
Values in ext_info are modified in several places, so it's difficult
validating whether we deviate from default. Let's always send it so that
we always have a clear view on what the MS uses.
This fixes a bug where paging_coordination or ccn_active would not be
announced if GPRS was not enabled.
Related: SYS#5894
Change-Id: If96de3e0d77503cf6344dfbc611f9260ac3281aa
The value in bts->si_common.chan_desc may get out of sync with the
actual value in net->T_defs (e.g. after changing it via the VTY),
so we need to sync it in generate_si3().
Note that synchronizing the values in cfg_net_per_loc_upd_cmd is
a bad idea, because the value of T3212 may also be changed using
generic timer management commands.
Change-Id: Iee291623c2825505eeb5175adcedadfe35375b9e
Related: SYS#5888
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.
Change-Id: I807fd4a0e700e54c67ca3547d9c0c1b442dd1c54
Fixes: I4e5b1163a71443d706f14ce4bfd5c2294c320432
Related: SYS#5838
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.
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
When running a multi-trx setup, upon stopping osmo-bts one can see:
DCHAN ERROR lchan_fsm.c:80 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN ERROR lchan_fsm.c:144 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan activation failed
(lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR)
These messages show up when the following conditions are met:
* BTS model speaks A-bis over IP (ip.access, e.g. nanoBTS), and
* BTS has more than one transceiver configured.
The problem is that unlike traditional E1 based BTS models, ip.access
ones have a single global A-bis/OML link for all transceivers. Thus
when it goes down, in inp_sig_cb() we need to notify all timeslots
*of all TRXes*, not just TRX0.
Change-Id: I3dc657ac5a2c5334747bd4f4db1a658acb323942
Fixes: OS#5479
Historically, we first only had
BSS_MAP_MSG_ASSIGMENT_RQST
^
with missing N. libosmocore has this renamed a long time ago and
provides a shim #define that makes the typo version still work.
Having the typo is bad for grepping, so rather use the non-typo name.
Also rename the constant for the ass req counter which so far has a
similar typo, and fix the same typo in the counter description.
The counter name exposed on CTRL luckily doesn't have this typo in it.
Change-Id: Ieaa4f4e6e6f7e1563b1bd15a83f0c1a9112d2312
The ho_fail() macro includes a newline, so the callers should not add
one. Fix these cases where the extra '\n' fragments the logged message.
Related: SYS#5839
Change-Id: Ifdbce98be70c1aa127ae008d7a77b9795fd250d3
So far we completely ignore the codec list from the MSC in Handover
Request messages. This leads to error messages in subsequent handovers
because there is no Codec List stored on the conn:
DHODEC ERROR handover_decision_2.c:390 [...] No Speech Codec List present, accepting all codecs
Besides the error log, in hodec2 we may subsequently take bogus or
unexpected codec decisions, ignoring the MSC's choice of codecs, or in
the worst case picking an unsupported codec.
This also has implications on what type of lchan we choose for handover
target in hodec2: say, if no half rate codec is supported as per the
MSC's request, we normally avoid handover to a TCH/H, etc.
Intra-BSC HO after an Inter-BSC incoming HO is the only case where this
problem occurs, in every other scenario there is an Assignment Request
from the MSC, from which we properly store the MSC's codec list.
3GPP TS 48.008 does indicate that on AoIP this codec list shall be
included. So reject HO Request with missing Codec List, as we already do
for Assignment Request on AoIP.
This makes TTCN3 BSC_Tests for inter-BSC incoming HO fail, because our
tests so far omit the Codec List (MSC Preferred) on AoIP. The related
fix of the tests is If06de9c9b43d79f749447a4e2a340176eef75c79.
Related: SYS#5839
Depends: If06de9c9b43d79f749447a4e2a340176eef75c79 (osmo-ttcn3-hacks)
Change-Id: I117cc29d6d11db77d160de654f43f5993db6ee21
"inter-BSC MT" was the terminology of an early development stage of
inter-BSC handover, code review requested "incoming" instead. This one
was missed when applying code review.
Same in a code comment.
Related: SYS#5864
Change-Id: I1ca810542e89980ffda11876fd30626467e452d1
Teach osmo-bsc to handle empty N-Connect. So far we were always
expecting user data in an SCCP N-Connect from an MSC. However, it is
perfectly valid for an initial BSSMAP request to follow later.
This is relevant for:
- Handover Request (incoming inter-BSC handover)
- Perform Location Request (query physical location of the MS)
Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter
this state so that we don't have two separate code paths for handling
initial user data.
Related: SYS#5864
Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
Also increment message counter for the case that a Perform Location
Request came in the initial SCCP N-Connect message.
Related: SYS#5864
Change-Id: I3f78ce73eb16fdff1f19359963405b2235000fc4
During inter-BSC incoming handover, there is no previous lchan to be
switched, so this event always comes in the READY state of
lchan_rtp_fsm. No need to complain about that and confuse log readers.
Related: SYS#5864
Change-Id: I96fd53b8c8da621a40bd65f85070eabd030cc875
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
I find it cleaner to relay on the counter ('arfcns' in this case) to
check if the set is empty, rather than checking one of the resulting
values ('max'). There is just a cosmetic change.
Change-Id: I29ca51461beec053bcb8b8210f0ad24bb8c7765f
Related: SYS#5854
The callers of this function do pass different mask values, which
should be passed to gsm48_decode_freq_list(). Instead, 0xce was
passed regardless of the given mask value.
Change-Id: I47f2eab54ef8487b14992fd7a69d5c9ccbb3f5cf
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
Improve the function doc. Remove a comment at a caller, because that
information is what the function doc is for.
Rename the array to codec_by_strength, because it is not the codec
strength but the codec number listed in the array.
Related: SYS#5839
Change-Id: Iaed6b97c31e4ccb1f28ca7e64596d5e20563b392
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
The SAPI "n" REJECT messages were being sent with DLCI keeping the RSL
LINK ID format, which is not the same for CC bits.
With this patch, TTCN3 test BSC_Tests.TC_rll_sapi_n_reject_dlci_cc
passes again.
Related: OS#4728
Related: SYS#5047
Change-Id: Icc187f594743040a3d9b8beff7d9cfc21dd6eb08
Skip the BSSMAP Clear and SCCP RLSD parts and immediately deallocate the
gscon when there is no SCCP connection present. Before this patch, such
conn would stick around for a minute before a timeout deallocates it.
Related: OS#5337
Change-Id: I8c8537acf6b47b121903197608636c43ae601a57
Properly implement the separate conn release stages in separate FSM
states:
x) sent Clear Request, wait for a Clear Command from the MSC.
Timeout after a configurable 60s.
y) after a Clear Command and sending a Clear Complete, wait for the SCCP
RLSD. Timeout after a configurable 60s.
z) terminate after the RLSD is received / after timeout.
handover_test.c needs a little tweak to make the MGCP release work with
its fake MGCP client, because cleanup now ensures to invoke
gscon_forget_mgw_endpoint() in all cases.
Related: I680ec4ed866aa5f0b1ff29e7e98322615cfb288d (osmo-ttcn3-hacks)
Related: OS#5337
Change-Id: Ie975117d37f38ba853589dc7f8d3e94f8f9586b2
The way the ST_CLEARING is entered before this patch has various
symptoms of how I / we used osmo_fsm when we were still FSM amateurs in
Osmocom. Patch that up:
- In gscon_bssmap_clear(), ask for a state transition to ST_CLEARING
first. Go ahead only if it is allowed.
- move the Clear Request messaging to ST_CLEARING's onenter function.
- Fix the timeout behavior: by using conn_fsm_state_chg(), use the
actual proper X4 timer value for ST_CLEARING from VTY configuration
instead of hardcoded magic numbers.
Related: OS#5337
Change-Id: I234b2a754d0c98031056981823cdbc187e977741
Allow returning a context sensitive cause instead of a hardcoded one in
gscon pre_term().
Also, the conn->cause is needed to move message dispatch to an "onenter"
function in patch I234b2a754d0c98031056981823cdbc187e977741. I Split
this part off as a separate patch for better readability.
Related: OS#5337
Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
In lcs_ta_req_wait_ta_onenter(), fix use count leak of 'start-paging':
get() the use count only after the early exits.
osmo-ttcn3-hacks patch I69d4c5c6f8d499bb7f0b96a48af045361433c57b
introduces testing against this leak in various LCS tests (e.g.
BSC_Tests.TC_lcs_loc_req_for_active_ms_ta_req).
Related: OS#5355
Change-Id: Ibbfbfe766eafe42c78048ec5b3b503a11ef5535d
During specific release scenarios, it became clear that an lchan still
pointed at a conn even after it had been deallocated. That was due to
setting conn->lchan = NULL but not lchan->conn = NULL. Fix that.
Do lchan_forget_conn() first, because during gscon_forget_lchan() we may
enter the gscon clearing dance, which in case of no SCCP conn being
present will soon / should immediately deallocate the conn.
Related: OS#5337
Related: I8c8537acf6b47b121903197608636c43ae601a57 (osmo-bsc)
Change-Id: Idbfe4672233ba8105eff5ba77ee07fd871358255
Before:
state_chg to ACTIVE
state_chg to WAIT_RLL_RTP_RELEASED
state_chg to WAIT_SCCP_RLSD
After:
State change to ACTIVE (no timeout)
State change to WAIT_RLL_RTP_RELEASED (T3109, 5s)
State change to WAIT_SCCP_RLSD (X4, 60s)
Change-Id: I94b7dc4d9e5e45dc731bcb3a843ede9fb6cc0839
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
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
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
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
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
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
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
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
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
The function set_bts_loc does not check the string pointers resturned by
strtok_r. In this particular case this is not a problem because the
function set_bts_lock will only see verfied input. However, lets check
the results anyway to avoid creating false positives in coverity scan.
Change-Id: Ie21c392e0405fc45811c6d55bf5508e9eb6784de
Fixes: CID#240849
In order to be able to call check_bts() and bootstrap_bts() from
inp_sig_cb(), we must move it below bootstrap_bts.
Change-Id: I1a365bc2278368ec1f5c0db3f3e466b124b16e83
Related: SYS#5369
The function bootstrap_bts does a few checks before it does the actual
initialization. To make the code more modular, lets split the function
into two functions, check_bts and bootstrap_bts. Also be sure that we
print the BTS number when the check failes.
Change-Id: Id2b26f147d2f35e156e2da8ee58d2bbbb93de4ac
Related: SYS#5369
The function bootstrap_bts verifies that the ARFCN number is within the
valid range of the current band. In case of error it prints that the
ARFCN is out of range, but it does not print the BTS number, nor the
ARFCN number.
Change-Id: I432448b4bd5ea1a209838a6c5105cc1e9f7d80ee
Same as all_allocated:{sdcch,tch}, but already trigger when all
non-dynamic timeslots are allocated.
Related: SYS#4878
Related: Ib3997a827c9cc43d1361bb0cf3bfab9f6d91bf82 (osmo-ttcn3-hacks)
Change-Id: I2fa14531f16d3f07085620f1c50eb839c420da6a
This is a candidate for adding to libosmocore (as osmo_time_cc), but
let's first use this in osmo-bsc to make sure that it works as intended.
I started out expecting to be done with this in half an hour, but I
found out that accumulating elapsed time to an integer counter has a
staggering amount of complexity to it, and a million pitfalls.
The intended use is to report allAvailableSDCCHAllocated and
allAvailableTCHAllocated performance indicators in OsmoBSC. Hopefully
this will also be generally useful elsewhere, to be worth the effort.
Related: SYS#4878
Change-Id: Icdd36f27cb54b2e1b940c9e6404ba9dd3692a310
Add chan_counts_for_trx() and chan_counts_for_bts(). Drop
bts_count_free_ts() and trx_count_free_ts().
Rationale:
The bts_count_free_ts() and trx_count_free_ts() always returned the
number of free lchans, not timeslots. Hence, passing the pchan type as
argument never really matched the semantics.
Especially, when looking for free SDCCH, there is no clear match on a
gsm_phys_chan_config enum value: SDCCH8_SACCH8C, CCCH_SDCCH4,
CCCH_SDCCH4_CBCH, SDCCH8_SACCH8C_CBCH? -- GSM_LCHAN_SDCCH is clear.
==> Rather count free lchans by enum gsm_chan_t.
Counting lchans of distinct types required separate iterations for each
lchan type.
==> Rather compose an array of counts for all types, in one go.
I need to count the amount of free SDCCH lchans in an upcoming patch to
implement the performance indicator allAvailableAllocatedSDCCH (cumulate
time for which no SDCCH are available).
To implement allAvailableAllocated{SDCCH,TCH}, I need a count of both
the used as well as the total lchans for a type: it does not make sense
to flag "all available allocated" if none are ever available.
To properly count dynamic ts, I need the maximum total that can be
possible at any time. And to count currently free lchans, I need the
current total. This may seem counter intuitive, but consider, e.g.:
- Obviously, if a cell has only static TCH/F timeslots, it does not make
sense to flag that all available TCH/H are occupied, because no TCH/H
are available ever. Just stating this as contrast to dyn TS.
- If a cell has OSMO_DYN timeslots, I *do* want to flag that all TCH/H
are occupied when all dyn timeslots are fully occupied.
- If those OSMO_DYN however are all used as TCH/F, the current total of
TCH/H becomes zero, and it seems like TCH/H should not be considered.
- To count the nr of currently free lchans, I need the currently
possible total of lchans and the nr of occupied lchans.
So return both a maximum total and a current total of lchans. In above
example, the maximum total shows that there would be TCH/H possible.
BTW, it would be nice to keep a chan_counts array on trx, bts and bsc
level and update as channels are allocated and released, instead of
counting them all over periodically. But it's less error prone this way.
Related: SYS#4878
Change-Id: I2fb48c549186db812b1e9d6b735a92e80f27b8d3
It's more logical to have the boundaries sorted in ascending order:
* band 1 represents lowest interference levels,
* band 5 represents highest interference levels.
Change-Id: Ie9bf4bf0c89418685b8ea5096332d22cfba7c521
Related: SYS#5313
As stated in "GSM/EDGE Evolution and Performance", section 12.3,
both features *can* be enabled simultaneously.
Change-Id: I2189f01bd78625dab3d642597240338ee581fc98
Related: SYS#5319
We have lots of counters for intra-BSC handover *away from* a given BTS,
but still missing are counters indicating how many handovers *targeted*
a given BTS. Also count incoming HO.
Related: SYS#4878
Related: Iba229313d73fa20266f6d4eac5820579fb14c604 (osmo-ttcn3-hacks)
Change-Id: Id9f2c6e2865ebe680879018fff08d283ce24c983
I was a bit confused that grep did not find HO counters being used, so
let's add some comments to better explain and provide a grep hook.
Related: SYS#4878
Change-Id: I242de13e657286e09428a8ca6e583d8b5155faa2
nanoBTS would NACK a CHANnel ACTIVation message for an 'intra cell
channel change' if it does not contain the Timing Advance IE. And
this is right, because according to 3GPP TS 48.058, section 8.4.1,
point '4)', it *must* be included.
Indeed, the actual Timing Advance value is not known during the
manual channel activation triggered from the VTY interface. So
let's merely indicate 0 if it's not known.
Change-Id: Iee7ddb4cf1a9a7bb9b34e6c9f6f9899da480fbd0
It is possible to change the neighbor-list mode via the VTY from
automatic mode to manual neighbor-list configuration. In the manual
mode, the user can add ARFCN values manually. This command can be found
under the bts node. Lets add pendant of this command on the control
interface as well.
Change-Id: Id97bc0d31a358db6221c385761773fb48670c921
Related: SYS#5641
The VTY allows flexible control over the neighbor cell information via
the neighbor command, which can be found in the configure terminal under
the bts node. Lets add pendant of this command on the control interface
as well.
Change-Id: I343a40e18fa9b91e6c381912c0426a002841e079
Related: SYS#5641
The Neighbor Address Resolution Service is using the control interface
API as well. Lets add a comment to indicate that this service is not
related to the normal control interface.
Change-Id: Iec86f72548bfc54a2c86dadec69dd1c64813d852
When the gsm_subscr_conn_fsm (GSCO) terminates abormally it might not go
through the forget-mgw-endpoint mechanism. It might be terminated
forcefully, which means only the pre_term callback runs. The pre_term
callback clears the endpoint, but it does not put the mgcp_client
reference back into the pool. This results into a wrong ref-count in the
mgw-pool.
Change-Id: I5a7ce6a1880a1060df74d03dd4eb38b51fd85c69
Related: SYS#5675
The option -t --testmode is defined, but not evaluated. It seems that
the code of this option was removed long ago. Lets remove it now.
Change-Id: Ie11173f5a7aab568b9a25102ad7dcf37fd49f318
VAMOS secondary lchans are to be used specifically when the osmocom dyn
TS is set to pchan_is=TCH_{F,H}. Setting secondary subslots for
OSMO_DYN TS is not needed since it's only used to initialize the TS, and
OSMO DYN already initializes 8 subslots
(subslots_per_pchan[GSM_PCHAN_OSMO_DYN]=8). Otherwise, ts_setup_lchans()
will try to initialize 8+2 lchans on the TS, which is more than needed
and will access out of bounds in the array.
Related: OS#5278
Change-Id: I8727d5b446179c0ebcd8738507efe5a50afaf1e2
Since a while ago, osmocom types dynamic TS supports being configured as
SDCCH8, hence the maximum subslots is 8. This fixes issue where only up
to 2 subslots where being used on those TS.
Related: OS#5278
Related: SYS#5309
Fixes: 52b9912ef9
Change-Id: I50e6530284ef49cfd77d1944d4a183c5df345820
It is not possible to operate a cell that has secondary TRXs in
different bands. Especially considering that DCS1800 and PCS1900 have
overlapping ARFCN numbers it would be hard for the MS to tell to which
band it should switch. Also the ImmAss. message only contains the ARFCN
number. It is impractical to have TRXs in different bands and probably
this also violates the sepec.
Change-Id: Icc2af9e2a9bca3897dbbb34d7b2c0fe6f843bedd
The value ncc_permitted is preset in osmo_bsc_main.c from
bootstrap_bts(). It is a constant value that also cannot be changed via
the VTY. Therefore it should be set from bts_alloc(). This also fixes
the problem that when the BTS is added at runtime from the VTY. BTSs
added at runtime would have an all zero ncc_permitted until the next
restart of osmo_bsc.
Change-Id: I9f02277d7b4b4bcb383e749435416a0b22efd5e8
Related: SYS#5369
The index counter bts->chan_load_samples_idx is initialized to 0 in
bootstrap_bts. Since the bts object is allocated using talloc it is
already guaranteed that everything is set to zero. So we do not need to
initalize chan_load_samples_idx.
Change-Id: Ia75e59c44c3ccd653a2614c2cda7519faf999f09
The acs value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Idc4e08c471e15c36b4ea7eb3981254e179115765
The pwrc value is currently set from bootstrap_bts() in osmo_bsc_main.c.
The value is set to 0. Since the BTS object is allocated using
talloc it is guaranteed to be 0 from the beginning. Lets set it from
bts_alloc anyway so that we have a place holder that is easy to find.
Change-Id: Id76879a94cf8cf8c07e8fc7e8aa399cd50e04e9a
At the moment we set the R99 flag from bootstrap_bts() in
osmo_bsc_main.c. However this constant flag should be set together
with the many preinitalized chan_desc values in bts_alloc
Change-Id: I5b78c4e25616ab552c37ba8b7c9948cf7052bad4
The function gsm_set_bts_type() already takes care of setting the
model->started flag to true. There is no need to do this in
bootstrap_bts() again.
Change-Id: Ia70943d96d466ab506fe368ef178a2ccc7483adc
Controversy: this duplicates bts.N.rsl_connected. I would like to add
this duplication for consistency, since we now have these counters:
bsc.0.num_trx:rsl_connected
bsc.0.num_trx:total
bts.N.num_trx:total
and the old
bts.N.rsl_connected
which does not fit well with above naming scheme. Any user will be
justified to expect a stat named bts.N.num_trx:rsl_connected as well.
Determine bts.N.num_trx:rsl_connected in the new function
bsc_update_connection_stats(), where the other num_trx:* are set.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I55b55159fe13d937e441d8c2ed915734463e1154
This is similar to bsc.0.num_trx:total but per single BTS.
Related: SYS#5542
Related: I5be1cb470930354c4561cbed301bc50a32484ed9 (osmo-ttcn3-hacks)
Depends: I137992a5479fc39bbceb6c6c2af9c227bd33b39b (libosmocore)
Change-Id: I283d38e7a8c032e274a5bd2fa150ec2c9a7157b4
If an RF Resource Indication message includes interference band(s)
for 'pure' PDCH (i.e. not dynamic) timeslot(s), osmo-bsc logs:
DRSL DEBUG abis_rsl.c:1515 (bts=0,trx=0) Rx Resource Indication
DRSL ERROR bts_trx.c:236 (bts=0,trx=0) chan_nr 0xc7 cbits 0x18:
(bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED) is not GSM_PCHAN_OSMO_DYN
DRSL ERROR abis_rsl.c:141 (bts=0,trx=0,ts=7,pchan=PDCH,state=UNUSED)
Abis RSL Rx Resource Indication: mismatching chan_nr=0xc7
Let's better check if a timeslot is capable of GSM_PCHAN_PDCH,
rather than checking if it's GSM_PCHAN_OSMO_DYN.
Change-Id: I2cac4acd4c5145c5c525c9952fdc754477ce0942
Related: SYS#5313
Now that we solved all the interdependency symbol mess, we can finally
enable call to this function.
Change-Id: Id4c724ef17beae4bb0918ebd1a809665b59e4861
These are not needed anymore since we re-introduced libbsc, specially to
avoid all this churn.
Some specific methods are explicitly required to be overwritten by
tests, so we specificially mark those with __attribute__((weak)) in
order to be able to overwrite them.
This is the last step towards fixing interdependency mess of symbols and
stubs, and requires previous patches in order to have tests apssing
fine.
Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
This allows having it initialized automatically, as we usually do with
this type of code. As a result, tests or other apps importing libbsc
don't need to take care of calling it.
NOTE: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Since tests were not
using those FSMs before, there was no need to call ts_fsm_init().
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I0e4b95b5e73fbb3844d83ba33e66786831088e1f
This is used inside group of files forming libbsc (shared files used by
several apps). Let's instantie only once inside a file from libbsc
instead of doing so on each binary.
This is one further step towards fixing interdependency mess of symbols
and stubs.
Change-Id: I9b287aa492ca6aae5fc56133e1510aff3146fe25
osmo_fsm_inst_free() must be called explicitly, otherwise the instance
is kept in the llist of instances and produces heap-use-after-free.
Note: This fix is required by follow-up patches where some stubs are removed
and hence some tests start using FSMs internally. Due to this bug, tests
will crash due to reason explain in previous paragraph.
This patch itself may introduced failures to build due to some new
interdependencies being introduced in same follow-up patches mentioned
above, which are in turn fixed by this present patch.
So they are expected to be merged together.
Change-Id: Ib0e5560efe518833f76f846d7269e82d85c186a1
Increase the reaction time at the expense of more stable loop with less
temporary oscillations.
See updated user manual documentation in this commit for a larger
description.
Related: SYS#5371
Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
* Adds vty option dyn-bsc for ms-power-control -> mode
* Imports power_control.c from osmo-bts project
[at commit 2f3cd4b697972d8484f9a9d3b7ef634086f65fa5]
* Removes unused C/I code from osmo-bts's power_control.c
This patch then calls the power loop on receipt of measurement
reports and updates the MS Power Level accordingly.
Change-Id: Ibc307e758697eb5ca3fb86622f35709d6077db9e
From the nature of the lchan_activate_info.tsc_set and .tsc, it is easy
to forget to set tsc_set,tsc = -1 to use default TSC Set and TSC values.
Handover code is one such instance that forgets to set -1.
Change the semantics of tsc_set and tsc so that this kind of error can
not happen again as easily: use a separate bool to flag whether to use
the default config or explicit values.
Implicitly fix the lchan_activate_infos "launched" in handover_fsm.c as
well as abis_rsl_chan_rqd_queue_poll().
Related: OS#5244 SYS#4895
Related: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af (osmo-ttcn3-hacks)
Change-Id: Iae20df4387c3d75752301bd5daeeea7508966393
When the SDCCH gets released while the TCH still beeing activated, then
the ChanActivACK that is received after the TCH is activated will trigger
a segmentation fault in the assignment_fsm. The reason for this is that
conn->lchan, which holds the SDCCH at that point in time, is now NULL.
To prevent osmo-bsc from crashing, the FSM should check for the presence
of conn->lchan first. If it does not exist, the FSM should terminate.
(Assignment failed)
Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a
Related: SYS#5627
Improve the current VTY support to allow enabling/disabling C/I logic
independent from value setting. This way C/I support can be quickly
disabled & enabled.
Reminder: changing power parameters still require VTY Command "bts NR
resend-power-control-defaults" to be excuted prior to new parameters
being applied on the BTS.
Related: SYS#4917
Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
assignment_fsm_allstate_action is only used in module assignment_fsm.c,
so lets decalare it as static
Change-Id: I90d6c11bd485e3be80efc7f146e0129d93e18458
This fixes call setup issues when more than ~1km from the tower.
NOTE: We use the last reported TA from the UE in the CHANnel ACTIVation.
When the UE is more than 1km from the tower, (unshifted) TA in the
measurement report can be 8 or greater. Once we send TA of 8 in the
CHAN ACTIV message, the lchan is unrecoverable.
Change-Id: I1c9bd5bf2fd126e62bcbec419f3499d2e0465559
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite
cumbersome and end up in lengthy config files. Let's instead add a
placeholder command to apply it to all channel types of a BTS at once.
This is useful specially since a user disabling C/I capabilities
probably does so because it may require a fair amount of fine-tuning
parameters to have it working perfectly. Hence, a user not willing to
spend time configuring those parameters correctly (and for which default
ones doesn't work properly) will require quick way to get rid of C/I
based MS Power Control Loop. By disabling C/I comparison, osmo-bts will
rely on RxLev only when applying the MS Power Control Loop, which is
fine for non noisy environments.
Related: SYS#4917
Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
Completely describe the 'rf_states' string elements (in one place), and
fix the missing <rsl_status> item in bsc_ctrl_commands.c comments.
Related: SYS#5542
Change-Id: Ifc3610c344b3e270111e2f6c5155a6fb90d8f2ac
Add per-TRX command to lock/unlock single TRX.
(Besides the global root-node rf_locked command setting the global RF
policy.)
Corresponds to VTY command: 'bts N' / 'trx N' / 'rf_locked (0|1)'.
Related: SYS#5542
Related: I2bb5096732f75a7341c7e83951e63c5a2038b469 (osmo-ttcn3-hacks)
Depends: I4dac826aab00bc1780a5258b6b55d34ce7d50c60 (libosmocore)
Change-Id: Ie46fd730797b64fb185d705c3507e36f5f23ef4b
These commands return a listing of OML state, RF policy as well as RSL
connection status for each TRX in the form:
<bts_nr>,<trx_nr>,<opstate>,<adminstate>,<rf_policy>,<rsl_status>;<bts_nr>,<trx_nr>,...
For example, the root node 'rf_states' may return:
0,0,operational,unlocked,on,rsl-up;1,0,operational,unlocked,on,rsl-down;2,0,inoperational,locked,on,rsl-down;
A 'bts.N.rf_states' returns the same form of string, but lists only the
TRX for the given BTS nr.
Note, there is already a CTRL command 'bts.N.rf_state' (singular
'rf_state', not plural 'rf_states'), which only reflects the overall
status of all TRX combined. This new command has per-TRX resolution.
The rf-policy is so far always looked up in the global gsm_network flag,
as does the old 'rf_state' command; see osmo_bsc_rf_get_policy_by_bts()
which does not depend on the specific BTS at all. This may be worth
revisiting in the future, so I am already including the rf-policy in the
rf_state string for each TRX, even though it is globally identical.
Related: SYS#5542
Related: I01e6f391a5e71b0606c42be9b57f8a1687d59bcb (osmo-ttcn3-hacks)
Change-Id: I14fa2678fc8f2c11a879c5e9615ac552782c5b7e
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Related: SYS#5371
Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
While NACC was initially developed, it became clear there was need for
a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS
for later RIM usage.
Hence, this resolution was first (until today) implemented using an out
of bands RPC system using the CTRL interface, which required specific
config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port
of the CTRL interface to use).
However, this has several shortcomings:
* As explained above, specific configuration is required
* Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS
may switch to a BSC other than first one. If that happened, that'd mean
the CTRL interface would still point to the initially configured one,
which may not be the same currently serving the PCU.
During recent development of ANR related features, a similar need for
PCU<->BSC was required, but this time it was decided to extend the IPA
multiplex of the Abis OML connection to pass PCUIF messages,
transparently forwarded to each side by the BTS.
This has the advantage that connection PCU<->BTS is handled by BTS and
both sides send messages transparently.
Let's switch by default to using this new interface, while still
maintaing the old way for a while (announcing them as deprecated) to
avoid breaking existing deployments until they are upgraded to new
versions of osmo-pcu and osmo-bsc.
Change-Id: I9073a121564503f483c84263ac72476041e47c03
Related: SYS#4971
So far we were inherting the bs_power in used when activating an lchan
for an MS for which we already had previous lchan. For instance, when an
MS is first assigned an SDCCH, and later on, it is assigned a TCH to
place a voice call.
Doing so is, however, not correct because current and old lchans may be
placed on different TS or even on different TRX, which means they will
have different BS Power restrictions. In the scenario described above,
for instance, an SDCCH could have been assigned on C0 and hence have
a bs_power of 0, and later on, whenever the TCH lchan as created, it
would have inherited the C0 bs_power despite it may have been possible
to use a different (lower) max bs power.
Furthermore, the lchan->bs_power_db basically stores the *maximum* bs
power reduction. Hence it makes not sense at all to copy over the value,
since it is anyway not updated from MS measurement reports so far
anyway.
Fixes: 997a257f8d
Related: SYS#4919
Change-Id: I4a7736aa9a1395e0cc118b98b69896bd0f1e94e6
A previous commit (Feb 05 2021) moved copy of TA value to some other
place to fix some related issues, but forgot to update the comment.
Fixes: b03e73f27b
Change-Id: Ia10038919b6650dff45b7233f58fea94e9808712
Testing has shown that the Training Sequence Code in pre-chan-ack mode
is inaccurate (only worked with a BSIC that incidentally yielded the
same TSC value as the wrong TSC value sent in the IMM ASS msg).
Move the code setting the correct TSC and TSC-Set to the first stage of
channel activation (lchan_fsm_wait_ts_ready_onenter()) so that it is
available for both pre-chan-ack and pre-ts-ack Early-IA modes.
Have a separate function for setting the preliminary values requested in
Channel Activation (lchan->activate.*) into the accepted operative
places (lchan->*). Call this early for early-IA modes.
Hence the TSC and TSC-Set used in the early IMM ASS message is now the
correct one, and the same as sent during Channel Activation.
There shouldn't be any, but if there are other values besides TSC
suffering from the same problem, they are now also set to the right
values before sending IMM ASS early.
Related: SYS#5559
Related: I4479244b0c53648e62e84e1ebf986f51d659484f (osmo-ttcn3-hacks)
Change-Id: I9f26074154600d854a0b3baee2f38a6666f4cb56
bs_power_db, as its name suggests (also check vty code and
rsl_tx_chan_activ()) contains value in dB, not in 2dB steps.
Change-Id: I76bd6bb1b307ab75ba1292865747419228e0687a
This commit extends existing VTY and RSL infrastructure to configure and
manage MS Power Parameters used in MS Power Control loop, by adding
support to set up Carrier-to-Interference (CI) parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
So far we have stat items per BTS. Add stat items summing overall BTS
status.
Add stat items:
- num_bts:oml_connected
- num_bts:all_trx_rsl_connected
- num_bts:total
- num_trx:rsl_connected
- num_trx:total
Related: SYS#5542
Related: Ic1b35b7406547f92818afe399a2383d154576409 (osmo-ttcn3-hacks)
Change-Id: I2057a798e681a169cc03243a09b3d6449734c010
The MGCP proxy which is built into osmo-bsc is used to tunnel MGCP
messages through an SCCP-lite link. This is an SCCP-lite specific
implementation detail that is not present in SCCP/AoIP.
Change-Id: Id3a8c45ae38d6b9d9c106a9e83b3cbfff919650d
Related: SYS#5091
Since the libosmo-mgcp-client now supports MGW pooling, lets use this
feature in osmo-bsc. Large RAN installations may benefit from
distributing the RTP voice stream load on multiple media gateways.
Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0
Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d
Related: SYS#5091
To configure temporary overpower, new VTY commands are added. This patch
also addes the logic needed to attach the temporary overpower IE to the
RSL CHANNEL ACTIVATE message.
Change-Id: I488a91bb4ed86f630db56564a0cd293f39f0f690
Related: SYS#5319
TSC was initially set to -1 (to be picked by callee), but erased when
using designated initializers later on in the function, hence TSC being
set to 0. As a result, TSC 0 would be requested to the BTS, which may
have configured a different BSIC containing BCC!=0.
Related: OS#5219
Change-Id: I26813561ee9e7783a4004f32225f19296bd6319c
We already have MSC connection stat items, but for hysterical raisins
there are separate such stats for each MSC. Hence we have N connection
counters, each being either 0 or 1, for a single MSC.
Add a new stat counting the *overall* MSCs that are connected,
and one indicating the total number of configured MSCs.
Related: SYS#5542
Related: I178dcf4516606aa561d47b06061b8a416d3c40cf (osmo-ttcn3-hacks)
Change-Id: If76bbf9b3adb64c68d5c31c6b526fa71a99996ae
Instead of having static const structs in header files (which end up
duplicated in each and every compile unit!), have one .c file with the
rate_ctr and stat_item descriptions.
Related: SYS#5542
Change-Id: I8fd6380b5ae8ed2d3347e7cfbf674c30b6841ed9
Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn.
In the field, detecting that an MSC is lost is done by getting three
connection failures in a row. For the BSC_Tests, it is easier to just
provide a VTY command to reset an MSC's link status.
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks)
Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
Some UMTS capable phones (such as SE K800i) send this message
together with the 'normal' RR Classmark Change, what makes
osmo-bsc log the following warning:
DCHAN NOTICE gsm_04_08_rr.c:1037
lchan(0-0-1-SDCCH8-0)[0x562ea76d3ab0]{ESTABLISHED}:
(type=SDCCH) Unknown RR message: UTRAN Classmark Change
We don't handle it, so just ignore without logging anything.
Change-Id: Icb8e44c9a06519ead9c3dc9308788c23505d4bb1
Add explicit indexes like [BSC_STAT_NUM_BTS_TOTAL] = { ...
BSC_STAT_NUM_BTS_TOTAL == 0 and the first item of bsc_stat_desc of
course has index 0, but when grepping the code, it looks like
BSC_STAT_NUM_BTS_TOTAL is missing a name definition.
Same for MSC_STAT_MSC_LINKS_ACTIVE and MSC_STAT_MSC_LINKS_TOTAL.
Related: SYS#5542
Change-Id: Ie47e0857c41d517a9b37be96f6669d1825d24a6d
Add experimental 'pre-ts-ack' to the 'immediate-assignment' options:
send the IMM ASS even before a dynamic timeslot is switched. This
possibly saves an Abis roundtrip, but may be racy.
When pre-ts-ack is chosen, already do the IMM ASS before the dyn TS
pchan switch is ACKed.
In Immediate Assignment, in case the dyn TS is not ready yet, get the
pchan kind from lchan->type, which already reflects the target type, and
not from ts->pchan_is, which still reflects the previous pchan type.
Related test is in I2ae28cd92910d4bc341a88571599347a64a18fe5
Related: SYS#5559
Change-Id: I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74