In send_assignment_complete(), obviously return the current channel
configuration from lchan->current_ch_mode_rate, which is the proper
place to get the channel mode after RSL Chan Activ Ack.
It is interesting to look at the history of this line of code.
lchan->current_ch_mode_rate was added later, so now the mistake is very
obvious.
Related: SYS#6229
Change-Id: I3bf8f5ea9ae2a3c12fc5b483818d550a069fe66e
This patch caches the counts of initial paging requests for each paging
group. This count is needed to estimate T3113 when a new incoming paging
request is received and it has to be inserted into the queue.
With this there's no need to traverse the whole initial_req_list every
time a new incoming paging request is receiving, potentially saving lots
of iteration and hence lots of CPU when the queue is long.
Related: SYS#6200
Change-Id: I6994127827d120a0b4dd3de51e1ddde39f2fe531
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
When adding a new incoming request (aka "initial_req"), if the queue is
full only of retransmis (no not-yet-ever-transmitted initial requests
queued), then the new incoming request is inserted at the start of the
queue, in order to take scheduling priority over retransmits.
This was already fine before this patch, but the counting of requests
before it (used to calculate its T3113) was wrong, because it counted all
the retransmissions. This patch fixes it to end up with
reqs_before(_same_group)=0.
Change-Id: Ib2e810b0bcc51eac117713584310272462c58867
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
The default is to have a dynamic T3113. However, if the user wished to
set it statically, it would show up when writing the current VTY config.
Change-Id: If121a97bbb4a0234a0c162ef37c3692d6408404d
The BTS can be obtained easily from the backpointer in req->bts. Having
the extra param can only lead to confusion and introduction of bugs, as
happened in bug fixed by Change-Id
I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679.
Related: SYS#6200
Change-Id: I545fd853fdffce7f23f0d99203c66c3b39144e4b
When rewriting the loop, the pointer passed all the time to
paging_remove_request() was the one of the BTS which answered the
request, not the one actually handling the related unanwared still
active paging request.
Fixes: 70a1d60a83
Related: SYS#6200
Change-Id: I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679
This allows tracking each BTS active paging request queue length over
time, and evaluate CPU load based on the number of active paging
requests queued.
Related: SYS#6200
Change-Id: I6d296cdeba1392ef95fc31f6c04210c73f1b23e5
This way all paging related stats can be grouped (more will be added in
follow-up commits).
Related: SYS#6200
Change-Id: Iede1b6f68df468c7a3b3bf5fce7f68bb08b78832
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Neels wrote:
> i guess we can drop this comment now, it is a remnant from separating
> osmo-nitb -> osmo-bsc + osmo-ms
Change-Id: I2ce4d691715c1ea5c7c7896693a03b0aefbdb5b9
Prior to this patch the whole paging queue of each BTS was iterated.
After the patch only the active paging_req for a given subscriber are
iterated.
Related: SYS#6200
Change-Id: I225d5e08427c6bb9d92ce6a1dccb6ce36053eab5
This is triggered by BSC_Tests.TC_lcs_loc_req_no_subscriber.
Before, the NULL ptr was not a problem because paging_request_cancel()
only used the pointer to compare it against other pointers, but never
accessing it. A follow-up patch is, however, changing the implementation
to optimize the lookup by using the subscriber pointer, which generates
a crash.
Related: SYS#6200
Change-Id: Id0de43ac5bde0f52f258de6c9bf58b173301c8db
Before this patch, the entire queue of paging_request had to be iterated
in order to find if the subscriber already had an active paging request
(discarding duplicates).
Now that bsc_subscriber holds a list of its active paging requests, it's
easier to look at its list to find out if it is already active on that
BTS.
As a result, there's no need to unconditionally iterate the whole list
and we can optimize the loop finding the spot to insert the new queue:
- First the potentially way smaller loop over
bsub->active_paging_requests is done
- Second, only if the first loop allowed, the bts->pending_requests is
iterated and potentially early terminated.
Related: SYS#6200
Change-Id: I7912275026c4d4983269c8870aa5565c93277c5a
This allows havily decreasing the algorithmic cost of removing all
pending active paging requests for a given subscriber once it answers
on a given BTS.
Beforehand, the whole paging queue of all BTS were iterated. Now, only
the active requests for that subscriber are iterated.
Related: SYS#6200
Change-Id: I831d0fe01d7812c34500362b90f47cd65645b666
This saves the BSC from iterating twice the whole paging list of the BTS
which received the paging response.
Related: SYS#6200
Change-Id: I5f9215f31428ce0249cd9ece6d2d4e93155f429f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
The function rsl_ericsson_imm_assign_cmd has a comment "Chapter 8.5.6"
above it. However, thats only half true. The function implements
ericsson vendor specific RSL IEs, so lets be more clear about this in
the spec reference.
Change-Id: Id27662e208ca8ac0a48851583c11fbacf85f988c
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
This feature allows pinning each BTS to a specific MGW from the
configured pool. The pinning can be soft or hard (strict). If strict
pinning is not set, the configured MGW is selected with priority, but
other MGWs can still be selected during each call setup if the
preferred MGW is found not available at that time, hence avoiding denial
of service for the entire BTS if that MGW goes down.
If strict mode is selected, the call will be refused if the configured
preferred MGW is not available at the time the call is set up.
It is useful to use this feature when Osmux is configured between
the BTS and the BSC and an MGW pool is in use. This way the BSC is
capable of grouping all the calls of a BTS towards one MGW, hence taking
advantage of the Osmux trunking optimizations to reduce link data usage
(AMR payload of several concurrent calls ending up sharing the same
underlaying UPD packet).
Furthermore, this allows the operator to intelligently spread load over
the MGW pool in order to avoid ending up with more than 256 concurrent
Osmux circuits on any of the co-located MGWs in the pool (maximum supported
at the moment).
Related: SYS#5987
Depends: osmo-mgw.git 5d8b5b093595e1203e288c3175c163c0994b1102
Change-Id: I9a7a5af72795faed0d12d9d73b59951b6a0e9c7d
The CHAN REQ entry is not deleted after its information was passed on to
the PCU. This causes the same entry to be used over and over again while
blocking other incoming CHAN RQD.
Change-Id: Ia4abc55fc6fcb1c00991cc84d09529131d014910
Related: OS#5198
There's no need to fail, simply make it a noop in that case,
everything's fine and everybody is happy (specially when using CTRL
command "apply-config-file" to load a .cfg file containing
modifications.
Related: SYS#6138
Change-Id: Ia4e70d20d48a28c46a21dd10358577e5c798744c
Current organization is totally mess, there's actually no organization
at all for lots of commands.
Let's organize most commands based on CTRL node where they are applied:
global, bts, trx, etc.
Specific set of commands such as neighbor-related, rf-related, etc.
are left in separate files as subsections inside the same node, so the
hierarchy is still clear.
Change-Id: I51a9b31780a4a8026aafb2d732369cdc10c8bb70
There exists a VTY command for sending default power control params,
but so far there was no CTRL counterpart for it. This patch adds a
SET command 'send-power-control-defaults':
$ osmo_ctrl.py \
--host 127.0.0.1 -p 4249 \
--set "bts.0.send-power-control-defaults" 1
Similar to 'send-new-system-informations', this command takes an
arbitrary dummy value (required for SET), which is simply ignored.
Change-Id: Ib370bd97ee2d9f72f8bec553550b1792d1345387
Related: SYS#6138
in osmo-pcu, the message buffer in pcu_sock_read is allocated with 1000
bytes in addition to the true size of the pcu_prim struct. Presumably
this is to avoid compatibility problems in case the primitives slightly
grow due to appending new struct members. Lets do the same in osmo-bts.
Change-Id: I99f5204b0563f72f9da427bb7aa5451552d8c5b5
Related: OS#5198
The pcu_sock interface in osmo-bts does check the size of the primitives
it receives. Lets do the same in osmo-bsc as well.
Change-Id: I247c6f4b5a7a22d17a060a558c4ceb9221ca7351
Related: OS#5198
We expect osmo-bts to provide us with a remote CID in order to be able
to set up MGW to send Osmux frames to it.
Related: SYS#5987
Change-Id: Ia90e8e0d18193d64c0fa0788dbd0eb242a359b61
the shared code in libbsc checks for sane config being set, but this
doesn't really apply to ipaccess-config, wihich doesn't set such config
fields internally.
Change-Id: I22ff0d22d6dcf9b0f715bfa4e0daeb52c4028308
Until now Osmux was selected unconditionally in bss-side CRCX, without
checking if the codec was AMR or not. If Osmux use policy is "on", we
only want to request Osmux use if AMR codec is selected.
Change-Id: I3f53555dd9608f1337365e4f82b492bdf1da05bb
ipaccess-config sets up the entire line in a fake way.
That requires also setting the fd of each TS used to -1 in order to
avoid library code interacting with it during tear down if an error
occurs.
Change-Id: I19eb23a46f89b96dd8d63742ca2078ecd5c9ab6b
Since this is created by osmo-bsc, it is also expected to be there by
ipaccess_drop_oml() in the shared libbsc code. But ipaccess-config was
not creating it, so let's do so.
Let's explicitly assert this condition in the code path expecting the
pointer to be instantiated in shared code, to easily track related
issues in the future.
Change-Id: I3f63f6827f7c5d7a21ac125b7ca6b35244efbb65
nanoBTS waits until receiving OPSTART in order to establish the RSL
connection socket against BSC, hence we cannot wait until the socket is
established at the BSC in order to send the OPSTART.
Still this way we make sure the RSL CONNECT is acked before attempting
an OPSTART at the BSC.
Change-Id: Ief46bad5075b656c13d1f09a0724e33283148236
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
It makes no sense to have duplicate signals. Let's simply clean up
S_NM_IPACC_ACK and pass the required info for higher layers to do
whatever is needed based on the information.
This allows reusing same signal infrastructure for different types of
messages instead of having to implement new signals for each message
(which can be done at a higher point in the stack).
Change-Id: I18ae3d320d00077fc13bb9903903de2a17767302
pcu_sock_read() may not free the message buffer in case the recv
returned errno EAGAIN. This is already fixed in osmo-bts, lets fix it in
osmo-bsc as well.
Related: OS#5198
Change-Id: I49eda447fc1912c1f7f25ba07331cb84decf4548
There seems to be no way for this function to be called with NULL parameter despite unreproducible crash observed in the
past. Let's add assert to show this explicitly.
Fixes: OS#5551
Change-Id: I235bdd42ea82e7b5a1a40f437ca34c49ad239c48
This way it is a lot easier to find out how and when is an lchan
initialized, simply by looking at the lchan.h header, then seeing the
init function and grepping for it.
Change-Id: I043d1c2ee75d4d2a8b323b7960ee490e567f3865
It is really difficult right now to find out where all the different
stuff relative to operation and lifecycle of an lchan is. Let's move
everything to its own file to have all the related defines and logic
together.
Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
This API has been available since 1.0.0, and we actually require
libosmocore >= 1.7.0 nowadays, so it's totally fine using the
libosmocore API and drops the local duplicate.
Change-Id: I95c59b31cf1b08e1d513b589ef386d2dd55f09a2
The OM2000 model does not have a separate bb_transc MO, however for
compatibilty reasons we have a virtual MO that just mirrors the state of
the TRX mo. We should mark it as [Virtual] in show trx to reflect this
to the user.
Change-Id: I0f5501f6fbc7ce6d5457676b16c7f93f70db5763
Related: OS#5101
In OM2000 a separate bb_trxc MO does not exist to archive better
compatibilty towards classic ABIS and its MOs. Let's mirror the nmstate of
the BB_TRANSC MO to the RCARRIER MO in order to make it look like if it
were present.
Change-Id: I4611d8af16a30725308bd527098b12a356bfde9f
Related: OS#5634
the function om2k_trx_s_done_onenter() updates the administrative state
of the TRX oml MO but it does not notify the update to other entities
using S_NM_STATECHG
Change-Id: Iabf9f3a1a345c5d53d9a4d02fa2d6d13ddfd86ae
Related: OS#5634
Thanks to manawyrm for pointing out that the comments of the file
actually contained the numeric codes for the CBCH variants, but the
cases in the switch statements were missing.
Change-Id: Id5b4da6838f9a34db39fff5c23ad18822cd3347b
The function update_op_state() updates the OML MO, but it does not
notify the update to other entities using S_NM_STATECHG
Change-Id: Id19c6beb2bc79c4db0ec07ef593aacb57fff8b75
Related: OS#5634
The switch-case in update_op_state() and update_mo_state() can be split
off into functions. This makes to code better readable.
Change-Id: I41f0d9d0d498f6f698c2c959baac50424f5ac317
Related: OS#5634
The normal abis nm FSMs are sending S_NM_RUNNING_CHG signals that
include an object class to notify other entities about state changes.
This also includes paging.c, which only starts paging services when it
sees NM_OC_RADIO_CARRIER becoming enabled.
Change-Id: I305df5b2f962473e33e32484c42a79ff96e53e1a
Fixes: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
Related: OS#5634
In cases where the MGCP client endpoint FSM is terminating early the bsc
sbscr conn FSM receives the signal GSCON_EV_FORGET_MGW_ENDPOINT, which
then calls gscon_forget_mgw_endpoint(). However, this only nulls the
conn->user_plane->mgw_endpoint_ci_msc struct pointer, not the others.
This causes the assignment FSM to access
conn->assignment.created_ci_for_msc whle trying to initiate a DLCX. We
must make sure that when the MGCP client endpoint FSM dies, that all
other CI pointers that reference the same CI are also set to NULL.
Change-Id: Ia857e3af6c17282b7e8178b6d249eb0f99ed98e3
Related: OS#5572
As described in 3GPP TS 48.049:
7.8.2: "The RESTART message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
7.9.2: "The FAILURE message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
Related: SYS#5910
Change-Id: I6668b55868cf534a3b59da5e11542abb8131d604
Let's use CGI instead of LAC+CI, which contains only a subset of the
information.
Furthermore, It was noted that some third party (non-osmocom, non
open source) CBCs don't support/like receiving LAC+CI,
and expect to receive CGI instead.
Related: SYS#5910
Change-Id: I33a6216f89496484cbb3921609fcd3ab90761c69
When trying to build osmo-bsc using clang 14, I am getting this error:
make[3]: Entering directory 'src/osmo-bsc'
CCLD osmo-bsc
/usr/bin/ld: ./.libs/libbsc.a(handover_decision_2.o): undefined reference to symbol 'pow@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:656: osmo-bsc] Error 1
We need to link with the math library to resolve this.
Change-Id: I4137cad07a3343882ca77d5ebd5137083941dc11
GCC 12.1.0 emits -Wmaybe-uninitialized when building with '-O2'.
In function 'populate_ts_list',
inlined from 'lchan_avail_by_type' at src/osmo-bsc/lchan_select.c:356:2:
src/osmo-bsc/lchan_select.c:248:12: warning: 'chan_alloc_reverse' may be used
uninitialized [-Wmaybe-uninitialized]
248 | if (chan_alloc_reverse) {
| ^
src/osmo-bsc/lchan_select.c: In function 'lchan_avail_by_type':
src/osmo-bsc/lchan_select.c:326:14: note: 'chan_alloc_reverse' was declared here
326 | bool chan_alloc_reverse;
| ^~~~~~~~~~~~~~~~~~
This could only happen if in 'enum lchan_select_reason' we had items
that are not handled in lchan_avail_by_type(), but this is not the
case. Make GCC happy by initializing chan_alloc_reverse to false.
Change-Id: I3956621a6ec14ca5ff0ba0b11d2c956e2538efd8
This change implements an additional channel allocation mode, which
can be employed during a TCH channel allocation for assignment.
Selection between ascending and descending order is performed
depending on pre-configured parameters:
* Uplink RxLev threshold and number of samples for averaging,
* C0 (BCCH carrier) channel load threshold.
This is useful in setups where Tx power of the RF carriers cannot be
adjusted +dynamically at run-time and thus BS Power Control cannot
be performed. In such setups the BCCH carrier is transmitting at
relatively higher power than the other RF carriers. The key idea
is to allocate channels in a smarter way, so that UEs with poor signal
would get channels on carriers with high Tx power, while UEs with good
signal could use carriers with lower Tx power.
Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d
Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
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
The lchan_avail_by_type() attempts to find an unused lchan for the
given GSM_LCHAN_* value: TCH/F, TCH/H, or SDCCH. This is achieved
by looking up timeslots with compatible GSM_PCHAN_* values.
For instance, finding an unused SDCCH lchan may involve:
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4,
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (switched),
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (not switched).
Each attempt involves iterating over all timeslots of each TRX,
either in ascending or in descending order (see _lc_dyn_find_bts()
and _lc_find_trx()).
This patch simplifies the lookup logic by preparing a monolithic
array of timeslot pointers once, and then using that array for
each GSM_PCHAN_* lookup attempt. This change is required for the
upcoming dynamic channel allocation mode, which is fa more complex
than the existing ascending/descending ones.
A side effect of this change is that the interference aware mode
of allocation is not limited by the scope of a single TRX anymore.
Interference levels are now compared within the scope of the whole
BTS, so that lchans on the other TRXes may be picked if they are
better according to the interference reports from the BTS.
Change-Id: I7ccc56856bfd40fd7c63b7437736de60c2b516ff
Related: SYS#5460
Let's decrease the logging since it's fine simply discarding the message
if the link is down. This way all code sending messages doesn't need to
care about the link state.
Change-Id: I64356ec6a7b3a4e11a0e66b17efab2788b1ca5cc
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Idb0e6565e362ce383c833d6bfec4fb39d2985a6b
Fixes: CID#272982, CID#272944
Found by clang:
warning: implicit conversion from enumeration type
'enum lchan_activate_for' to different enumeration type
'enum assign_for' [-Wenum-conversion]
This is indeed a bug, because both enum items have different values:
* ACTIVATE_FOR_VTY (from enum lchan_activate_for) is 4,
* ASSIGN_FOR_VTY (from enum assign_for) is 3.
Change-Id: I44544d4577833e0aed62b07d0c7c1c2821b05dd4
Fault Reports are commonly oberved with a TLV id 0xd2
as are reports with up to 20 TLVs.
Let's not have these cause logging at level ERROR.
Closes: OS#5593
Change-Id: Ibe0b38835362c59d1576a206b2f64cea4427295f
This way the CBSP peers knows the state of specific cells and can avoid
sending messages to unoperative ones, etc.
Related: SYS#5910
Change-Id: I94f0a1ac3c59cffe5af57f972d5d96fc92281d34
When calculating average lchan duration based on the new stats for
BTS_CTR_CHAN_{TCH,SDCCH}_ACTIVE_MILLISECONDS_TOTAL there are
discrepancies which emerge. Specificially in bandwidth-constrained
environments, there are still-unknown failure states which can
occur that cause the TCH or SDCCH activity count to increment but
zero milliseconds of activity on the lchan to accumulate. This
portrays a failure as a success.
These new fully-established stats are intended to provide a more
accurate denominator when calculating average lchan duration as
they are incremented in proximity to the duration timestamp
initialization.
Change-Id: I417940ad9479719f5324fb12d45883cd3cb2c578
This allows running CBCH/ETWS related procedures only when the CBCH
towards MS under that cell is operative.
This also allows providing awarness of per-cell status to the CBSP peer
as required per specs.
Related: SYS#5910
Change-Id: Ia93919be94132fc010acb5bbfef0a6fd51c42981
For statistical clarity and site tuning, it is sometimes
desirable to completely disable the use of TCH for signaling.
In the existing version of this VTY command, there is no way to
accomplish this. We can only restrict TCH for signaling non-voice
related actions.
This patch deprecates 'allow-tch-for-signalling (0|1)' and
adds 'tch-signalling-policy (never|emergency|voice|always)' to
provide more options.
Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
This way we separate all the VTY boilerplate from the actual logic, as
we usually do in all other subsystems.
Change-Id: Ifc7d1693d745dd2a3c31e3ee9610d8c634b50812
Drop "to this MSC" from the NRI_STR, as it is not only used for MSC
specific configuration, but also in cfg_net_nri_* which affect all MSCs.
Drop "for this MSC" from the description of cfg_net_nri_null_del, it
affects all MSCs (unlike cfg_msc_nri_del).
Change-Id: Ic8888775a965b6d607af51b9359bd8ffc2834e16
The all_allocated_update_bsc() does inefficient iterating to count
active/inactive lchans, which scales badly for high numbers of TRX
managed by osmo-bsc.
We need to update the all_allocated flags immediately (periodic counting
alone would suffer from undersampling), so, until now, we are calling
this inefficient function every time a channel state changes.
Instead of iterating all channels for any chan state changes anywhere,
keep global state of the current channel counts, and on channel state
change only update those ts, trx, bts counts that actually change.
A desirable side effect: for connection stats and handover decision 2,
we can now also use the globally updated channel counts and save a bunch
of inefficient iterations.
To get accurate channel counts at all times, spread around some
chan_counts_ts_update() calls in pivotal places. It re-counts the given
timeslot and cascades counter changes, iff required.
Just in case I missed some channel accounting, still run an inefficient
iterating count regularly that detects errors, logs them and fixes them.
No real harm done if such error appears. None show in ttcn3 BSC_Tests.
It is fine to do the inefficient iteration once per second; channel
state changes can realistically happen hundreds of times per second.
Related: SYS#5976
Change-Id: I580bfae329aac8d4552723164741536af6512011
Reduce some code dup in all_allocated accounting and cosmetically
prepare for upcoming performance fix.
Have a struct all_allocated, allow easy re-use of function
all_allocated_update().
Rename function to all_allocated_update_bsc(). Upcoming patch will also
add all_allocated_update_bts().
Related: SYS#5976
Change-Id: Id7a82c65d56a87818fc35bbeedf67e2af2f89f11
ts_is_usable() returns the current state; logging is the job of calling
functions. An upcoming patch adds some calls to ts_is_usable(), this
avoids the log flaring up with useless messages.
Related: SYS#5976
Change-Id: I0635c47609fd7c7d0195b6658b7da231d6527b4b
It was described in [1] that the NM FSM failed to trigger the
S_NM_RUNNNG_CHG signal when locking/unlocking the TRX.
That's because current osmo-bts doesn't fully conform to TS 52.021 and
it doesn't go back to Op=Disabled Avail=Dependency when becoming
Admin=Locked. It's true though that TS 52.021 sec 5.3.1 is not really
helpful since it doesn't explicitly state that specific object should go
into Disabled Dependency, despite saying it for most of the other ones.
Hence, let's account for both possibilities at the BSC side.
[1] https://gerrit.osmocom.org/c/osmo-bsc/+/28205
Related: OS#5576
Change-Id: Ifbdc066fd88bdbf826800d14524e74416815b625
Since b7ef6884f9, the state is updated
before triggering the signal S_NM_STATECHG, so the warning does no
longer hold true.
Change-Id: I7b7dd30b4fcdc92febca42e3e6a75e6f98e184ff
Add missing conn->assignment.created_ci_for_msc to
gscon_forget_mgw_endpoint_ci().
Before this patch, when assignment.created_ci_for_msc lingers after a
DLCX, it can cause a use-after-free on assignment_reset(). Possible
scenario is rx BSSMAP Clear Cmd during ongoing Assignment.
In assignment_reset(), locally cache the ci pointer, because
gscon_forget_mgw_endpoint_ci() now NULLs created_ci_for_msc.
Related: OS#5572
Change-Id: If89610020f47fd6517081dd11b83911b043bd0f1
VAMOS lchans are behind the primary ones in the ts->lchan[] array.
For example, for TCH/F, there is a primary ts->lchan[0] and a VAMOS
ts->lchan[1]. We should print 'ss 0' for both of them.
Change-Id: I8e7a5a2ecc9b9a33e3ddb76cb1bc04d7802fd320
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
As per TS 48.049 Table 8.1.3.1.1 the WRITE-REPLACE message always
has a Warning Security Information IE if it relates to ETWS. This
is also implemented in the libosmocore CBSP parser.
As the previous Change Id369bb3676ba279bafc234378fbe21dbc7b0614b has
pointed out, the CBSP parser structure doesn't even permit any way
of handing a decoded message to us without the warning_sec_info
static struct member.
So as a result, there's also no need to dynamically allocate
bts_etws_state.input.sec_info via talloc. We can have it in-line
as a static struct member and reduce code complexity and runtime
memory allocations.
Change-Id: Ib1b8e4af37b1f9f9398b81dad29942e82218c70b
The proper way to fix this is having a use count on the SCCP conn, one
each for a busy lchan and a busy Location Request. That would require a
bunch more work and testing.
This patch is the least-effort way to avoid the following scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
Perfectly fine Location Request gets canceled by Clear Request;
The information was there, but we did not forward the location;
No help at emergency because of my code.
Allow Location Request to complete for these cases:
- rx RLL REL IND (or any other reason for gscon_lchan_releasing())
- rx RSL CONN FAIL
Related: SYS#5912
Related: Idea690a4aa4aecbe4642a16e96d086cc0538564a (osmo-ttcn3-hacks)
Change-Id: Ib44dd05b0adee84234f671313b156ff6625357cc
ACC used to be stared/stopped based on operational/administrative state
changes. The new S_NM_RUNNING_CHG triggers a single boolean based on the
same logic, so we can now simplify the mechanism.
Change-Id: I2e09bcb18a6c3bb2e88bba98579fb4854a6b0699
This way we avoid triggering timers and doing extra poll loops for each
BTS which is configured but not up. It also has the effect of removing
logging about estimating paging buffers for BTS which are down, which
can be confusing.
Furthermore, since work is delayed until the TRX and cell in general is
configured, the first estimation is properly done now since the correct
configuration is in place at that time.
Related: SYS#5922
Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
This allows different parts of the code to hook to some signals which
allow start/stopping processes based, for instance, on whether C0 is
available or not.
This can be later used by paging or CBSP code. Also ACC code can be
ported to this new system (acc_ramp_nm_sig_cb()).
Same signal can be used for other NM objects, but is left unimplemented
until there's use for them.
Change-Id: I206d4c7863a77fbab6a600126742a6a6b8fc3614
This way code triggered through signal has an updated view of the object
tree when running generic code which queries the current state of
objects.
This way for instance one can use APIs like trx_is_usable() or alike.
Change-Id: Ib46234e3f3e446e866d27b0dfee65edf4af4d2ba
Found by GCC 12.1.0:
smscb.c: In function 'etws_primary_to_bts':
smscb.c:537:13: warning: the comparison will always evaluate as 'true'
for the address of 'warning_sec_info'
will never be NULL [-Waddress]
537 | if (wrepl->u.emergency.warning_sec_info) {
| ^~~~~
In file included from smscb.c:31:
/usr/local/include/osmocom/gsm/cbsp.h:99:33: note: 'warning_sec_info' declared here
99 | uint8_t warning_sec_info[50];
| ^~~~~~~~~~~~~~~~
Indeed, address of &warning_sec_info[0] is always not NULL.
Change-Id: Id369bb3676ba279bafc234378fbe21dbc7b0614b
Don't wait until RSL link goes up to check the reported features against
the config. Do it in the OML bring up right after the features are
reported.
Related: SYS#5922, OS#5538
Change-Id: I6b1b4ef3e163528ed186050d848ec089a4315a7c
Especially during emergencies / natural disasters, it is particularly
likely that networks become unreliable and BTSs disconnect and
reconnect. If upon reconnect there still is an active ETWS/PWS
emergency message active for this BTS, send it to the BTS to ensure
it re-starts broadcasting that message until disabled.
Change-Id: I175c33297c08e65bdbf38447e697e37f8a64d527
This reverts commit 5e2ac29703.
This patch was found to be a troublemaker regarding osmo-bsc
performance, since it's scheduling one timer every 100ms for each
channel. On a BSC with dozens of BTS, each with several TRX, this ends
up in a huge amount of timers scheduled in a tight timeframe, which ends
up in osmo-bsc spending CPU time getting in and out of the poll() main
loop.
Related: SYS#5922
Change-Id: Ibd5123e7f04ae8f4eb8f08b63525527f526f0b2c
This allows external monitoring to see where the T3113 timer has been
adjusted to, in case it is set dynamically.
Change-Id: I533f2ca3c8e66c143154cbf03b827c9cbbacccdf
Reaching this point will only make system load (CPU, mem) grow, making
it hard for the process to keep up with work to do, with no benefit
since the requests will anyway be scheduled too late.
Related: SYS#5922
Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
In lchan_fsm_cleanup(), ensure that the time_cc timer is actually inactive
before deallocating. Do so via lchan_reset(), to also make sure the
timer is stopped in all other situations where the lchan is deactivated.
This fixes an infinite-loop deadlock as described in OS#5554:
- run BSC_Tests.TC_chan_act_ack_est_ind_noreply
- restart the BTS process after the test is done
- osmo-bsc enters infinite loop in osmo_timer_del()
The reason is that lchan_fsm_cleanup() fails to stop a running active_cc
timer upon lchan deallocation. TC_chan_act_ack_est_ind_noreply
incidentally terminates OML while the timer is still active.
Related: OS#5554
Change-Id: I901bb86a78d7d021c8efe751fd9d93e5956ac0e0
We have seen an increased CPU load in osmo-bsc recently since the paging
improvements where merged, centered round poll() calls.
It is expected most of them will be fixed with previous patch. In any
case, let's avoid unnecessary poll() calls being called for no reason.
Related: OS#5922
Change-Id: Ie767bdc8d4353aafe375a424e02d698ef7fd3dea
We want to recalculate the timer based on last time the work_timer was
triggered (that is, the time when the worker re-armed the pag req to
retransmit). We don't want to recalculate based on the last time the pag
ret tro retransmit was scheduled.
In loaded paging queue, there's lots of retrans (let's say 200) and it
may take more than 500ms to actually retransmit them. That means in most
cases we could end up in a situation where only pag req to retrans where
in the queue, hitting this recalculate path. Since the 500ms were for
sure elapsed, that would most probably schedule the work_timer at {0,0}
for each new paging request that arrived. As a result, the worker would
be scheduled lots of times per second (once for each new req arriving)
and only submitting 1 pag req (the new one) plus potentially 1 or
serveral pag req to retransmit.
In summary, there was not throthling applied in the scenario where only
pag req to retransmit where in the queue and new pag reqs kept arriving.
This incurrs into augmented paging throughput and also augmented
frequency of polls().
Related: OS#5922
Fixes: 4821c9f4df
Change-Id: I7ce6f436286b50dc31331d218ff256cf7be3f619
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
One callback function was being registered for each BTS.
That means, when a C0 RCARRIER of one specific BTS changed NM state,
the outcome on whether to trigger/abort ramping would end up being
applied to all BTS.
Change-Id: I56c4dd1809fdcf8441a69bf77ad173e1ccc8eea7
This makes sure code accessing those fields is not changing its values,
since it would make no sense to change those. Follow up commit will make
convert those pointers to be full structs instead, as there's no need to
have pointers there.
Change-Id: I9979e62eac861e25bbe2161ab187ddb2b40fd097
Having 2 signals makes all code handling them more complex, specially
because S_NM_STATE_CHG_OPER could actually provide any change in
admin/oper/availability.
Both signals already provided the same kind of data (the whole
admin/oper/avail state change), so let's simply merge the signals
themselves. Current code really doesn't act differently for those 2
signals anyway.
Change-Id: Ia86d20a42b859063d0327b940ba528ec1438b04a
This code is not used currently. Furthemore, it makes little sense to
transmit an OPSTART if the BTS already told us it is enabled (because
OPSTART is what moves the BTS into operational enabled state).
Change-Id: I2c65e0803fbde7de9497089b562275baad58936a
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347
So far we only calculated the expiration time based on the amount of
requests of the same paging group in the BSC queue.
However, also extra time has to be taken into account regarding requests
of other paging groups. This is important because requests of all paging
groups are mixed in the BSC queue, meaning having a lot of requests from
other groups before a certain req will anyway delay transmit of that
req to some extend.
Related: OS#5537
Change-Id: Ib55f947c5d3490b27e1d08d39392992919512f9a
This was so far workarounded in tests by manually freeing the fields.
However, in follow-up patch the paging queue will also be properly
freed, so free of the counters needs to be previously fixed too so that
counters are freed at the right point of time.
Otherwise, during paging queue flush, counters are used and would crash
because they were freed before the BTS object in each test's bts_del().
Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
Use the same one as used to decode the message in osmo-bts.
This patch doesn't cause a change in logic since both headers are binary
identical.
Change-Id: Ideb863fdaedf77caac1a320de6696ba4f507a398
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
If the queue is only holding requests in retransmition state, when we
add a new one, we have to re-calculate the work timer to a lower value
instead of letting it wait for the first retransmit to be ready.
Change-Id: Ibd4f8921c92f7481f0b9943041c141640ab812c8
There's no need to keep the timer running, since anyway upon next
trigger it will simply early exit in paging_handle_pending_requests()
becuase there's no more work to do.
Change-Id: I096ab7231f52c741c5fded37acd5b309e1de06e3
Before this patch, on each BTS a 500ms timer was used to schedule some
work, sending up to 20 paging requests verytime.
This means, however, for an initial paging request it may take up to
500ms delay to be scheduled to the BTS, which is huge.
While we still want to maintain this 500ms interval for retransmits, it
doesn't make sense to wait that much for other cases. It's far better
sending less requests (10 instead of 20) every half time (250ms instead
of 500ms), since it will spread the load and paging more over time,
allowing for other work to be done in the middle.
Change-Id: I7a1297452cc4734b6ee8c38fb94cf32f38d57c3d
PAging happens over C0 RSL link, not over OML, so let's actually
validate that the C0 RSL link is up before paging instead of the OML
one.
Change-Id: I11e5bb6f952534763935aa01470e514d4af247ed
Decouple credit_timer from event "available_slots became 0".
Let's actually relate credit_timer to the fact of not receiving CCCH
Load Indication: If no CCCH Load Indication is received (cch_load_ind_period * 2),
then assume we are below CCH Load Indication threshold (10% load) and
start estimating the available_slots in a cch_load_ind_period*2 time
frame.
Moreover, in paging_schedule_if_needed(), there's no use in delaying
start of processing work if the work_timer is not already doing work.
Related: OS#5537
Change-Id: I6a0da03c408270044079e81d431f6641527c00cd
From 3GPP TS 48.018:
If only the New Serial Number IE, and not the Old Serial Number IE, is
included in the WRITE-REPLACE message,then the BSC shall interpret the
message as a write request, i.e. a broadcast request of a new emergency
message without replacing an ongoing emergency message broadcast.
Only one emergency message at the time can be broadcasted in a cell. If
a write request is received for a cell where an emergency message
broadcast is currently ongoing, the write request is considered as
failed.
Change-Id: I376c9e796f3a2d26b22d0451f15ef1debbd7f656
Closes: OS#5539
Related: SYS#5906
So far, we only implemented KILL for CBS, but not for Emergency
broadcasts. This patch adds KILL support for Emergency, by which
a CBC can terminate broadcast of a previously-started Emergency
message before its scheduled period ends.
Change-Id: Ie91939b93de6847eeb5d00c97a137c43721c2711
Closes: OS#5540
Related: SYS#5906
ETWS is sent over both dedicated channels and broadcast channels.
Some BTS models may not support the latter, but it is still useful
to start the related timer to ensure bts->etws.active gets set to
false after the emergency period has concluded.
Change-Id: I448be9fd75b87c1f7333a5bfa4f6ba238569fdc3
Only if we store data like the CBSP message_id and serial_number
we are able to later (in a subsequent patch) match a CBSP KILL
for ETWS/PWS and stop emergency broadcast.
Change-Id: Ide74638880d7e3c6a7c774bf6320d3dce4b11c74
Related: OS#5540
TS 48.049 states the following rules for the KILL COMPLETE / FAILURE
messages:
The Number of Broadcasts Completed List IE, if present, contains for
each cell the total number of broadcasts of the killed CBS message.
The Cell List IE, if present, contains the cells in which the emergency
message is successfully terminated.
As any message can only be either emergency or CBS, this means that
we can (at maximum) have only one of those two IEs in the message.
As there is no explicit indication in the KILL whether it relates
to CBS or Emergency, we use the "Channel Indicator" IE, which is
specified as "only included if the message refers to a CBS message".
Related: SYS#5906
Closes: OS#5541
Change-Id: I9a43d386da01f085663d231a555b8b5acc99faca
With previous patch Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, the
features get copied from the BTS model to the BTS. For rbs2000, bs11 and
nokia_site, an empty feature set was copied because the features weren't
set at this point. Fix this by moving the set_feature calls to _init().
Notably the set_feature calls had been moved for osmo-bts and nanobts
from _start to _init already in 2013 in the patch e84dd98d
("sysmobts: Avoid a crash when trying to look-up a BTS").
Fixes: 2d818b9f ("Always use reported features if available")
Related: SYS#5922, OS#5538
Change-Id: I43389ae48d5e0f01381602751f6bad902011b158
When building with CFLAGS="-flto -Wall", I get the following:
meas_pcap2db.c: In function ‘pcap_cb’:
meas_pcap2db.c:64:27: warning: pointer targets in initialization of
‘const char *’ from ‘const u_char *’
{aka ‘const unsigned char *’} differ
in signedness [-Wpointer-sign]
64 | const char *cur = bytes;
Change-Id: I84d8e6f290bda0f03476f182f292ecc7a9e520f2
When building with CFLAGS="-flto -Wall", I get the following:
meas_db.c: In function ‘_insert_ud’:
meas_db.c:62:23: warning: unused variable ‘rowid’ [-Wunused-variable]
62 | unsigned long rowid;
meas_db.c: In function ‘meas_db_insert’:
meas_db.c:89:13: warning: unused variable ‘rc’ [-Wunused-variable]
89 | int rc;
meas_db.c: In function ‘check_create_tbl’:
meas_db.c:260:16: warning: unused variable ‘rc’ [-Wunused-variable]
260 | int i, rc;
Change-Id: Id12958f67a47b6b3ebece7252e4f7c0835d4bb96
Instead of sometimes checking against hardcoded BTS model features, and
sometimes against features reported at runtime (which only some BTS
models do):
* copy the hardcoded BTS model features to BTS features initially
* do all checks against BTS features
Related: SYS#5922, OS#5538
Change-Id: Idf2d933aa8b03b1f708e56a08707fe6c620a97aa
Let all changes of the bts model go through this function, so we can in
a future patch copy over the bts model's features to the bts.
Related: SYS#5922, OS#5538
Change-Id: I8475c8c20eb72411e8ca820181d1c8603c22a56d
Just log all reported features, instead of comparing them against an
expected set of features and logging mismatches. The point of reporting
features from the BTS at runtime is that the BSC can support various BTS
versions with various feature sets.
Related: SYS#5922, OS#5538
Change-Id: Ibd79bc7ef802d8e95e05d746df182ff974b78e29
After the lchan release, the gscon would go into the Clear dance with an
arbitrary cause value. Instead, explicitly ask for a Clear upon
pre-emption, with the proper cause value.
Related: OS#5535
Change-Id: I20108f7b4769400b89b7b0d65c8dab883bf87c46
So far the we indicated pre-emption in the release cause of denying an
emergency setup, instead indicate protocol error.
When emergency calls are disallowed, it is not pre-emption (making room
for an emergency call) but a protocol error (MS asks for emergency call
when the network does not allow it).
Related: OS#5534
Change-Id: Ia195621165cb7bbe33e6c2e915abc42ab16a2a4f
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Currently, the Tx paging_req queue at the BSC always has new paging
requests adding at the end (as long as the subscriber is not already in
the queue).
That means, if the queue is full of retransmitions, it will take a long
time until the first paging_req is sent towards that subscriber.
The rationale here is that it makes sense to attempt the first paging
ASAP, and give lower prio to paging_req retransmitions, since it may
well be that those other subsribers are not available/reachable and
won't answer.
Related: SYS#5922
Change-Id: I1ae6d97152c458247bc538233b97c2d245196359
Having one paging request being sent every PAGING_TIMER (500msec) is too
slow in case BSC is serving lots of subscribers on a BTS. Hence, we want
to send many paging requests at once while still trying not to fill the
BTS buffer.
Morever, we don't want to send tons of paging requests at once, hence we
limit the amount of paging requests sent in one timer iteration
(MAX_PAGE_REQ_PER_ITER) in order to avoid the BSC doing lots of work
there at once, keeping it busy from processing other tasks.
Related: SYS#5922
Change-Id: I609fa67834b426456f48f6fb2acb601c5905f178
The variables are unsigned, so -1 gets actually translated to UNIT16_MAX
when the value is casted to uint16_t. Let's do that explicitly so that
readers don't think those are signed variables.
Change-Id: I02ad80e5d10f1a47cdf712f7f7c576a2e20fe607
If an lchan needs to be released to make room for an emergency call,
send the proper release cause ("pre-emption").
Related: OS#5534
Change-Id: I0423621d15ace11a53ae1653e5e7f5cb93605edb
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
arehbein
Neels Hofmeyr
Pau Espin
Oliver Smith
Harald Welte
Vadim Yanitskiy
Philipp Maier
Keith Whyte