Commit 92dc38d1c2 converted
bts->depends_on from bitmask to a list, but introduced an error while
doing so, iterating the wrong list and hence derreferring wrong entries
from it.
This caused for instance sporadic malfunction where osmo-bsc refused a
BTS from connecting with "Dependency not full-filled".
Related: SYS#7062
Related: SYS#7624
Fixes: 92dc38d1c2
Change-Id: I50c8111d71ee4493076cd2cf3d4d850fee3c0414
Add functions to set LAC/CI on a BTS and update hashtables
Use these function from both the vty and the control interface.
This commit fixes the issue where an update to LAC or CI
via the control interface was not resulting in updated
hashtables and therefore the BTS was not found during paging.
Related: OS#6840
Fixes: 15284337ec
Change-Id: If9509534bd4a75f8ed8fb3e0a6bec701c7596861
In Debian 13 armv7l, time_t and suseconds_t are "long long int" instead
of "long unsigned int" as seen on x86_64 and aarch64. Fix it by casting
to "long unsigned int".
Related: OS#6828
Change-Id: I416b31dd11a82ad52f6a662d7e099123a5c77fff
ITU Q.714 2.8:
"""
When an end node is informed of a routing failure, this information
is forwarded towards the SCCP user by using the N-DISCONNECT primitive
(refer to reason for release in 2.1.1.2.4/Q.711) or the N-NOTICE primitive
(refer to reason for return in 2.2.2.2.4/Q.711)
"""
We are already handling N-DISCONNECT.ind for CO messages, but
N-NOTICE.ind for CL messages was not being handled.
If CL messages are not arriving to the peer (MSC), then reset the link
and mark the peer as disconnected, until a new RESET can successfully fo
through.
Related: OS#5917
Change-Id: I3f6c120183a53a80255de71366935b6c07fcfbc8
Use osmo_sccp_addr_dump() instead of osmo_sccp_addr_name(), since msc
may be uninitialized and hence ss7 may not be available.
Change-Id: I682567e88f61c9ec3cfa25c50f2c12fc9d1f6e4f
This way they can used by libosmo-sigtran to figure out interesting
remote PCs it should track availability for.
Related: OS#5917
Related: SYS#7501
Depends: libosmo-sigtran.git Change-Id I9d2452d9cc8e443050927a047b7ebacd2b2f37e1
Change-Id: I57dca92eb5f482e9017d9b19cd7f8feebd9e2721
Depending on the BSC size we potentially have a very large number of
measurement reports. They occur every 480ms on each active logical
channel, so with a 4-TRX BTS of 12 SDCCH + 60 TCH/H we have up to 144
measurement reports per second per BTS. Therefore, a BSC-global
meas_feed transmit queue limit of 100 msgb might be a bit low.
This also follows the default osmo_io txqueue len which was increased
recently to 1024.
Related: SYS#7508
Change-Id: Ib4382adc05cf6776952801ad7edad230db1ec454
As of 2025-03-10 (I0d58e6d84418f50670c8ab7cf8490af3bc2f5c26 merge)
OsmoMGW supports an SDP extension that enables the use of TW-TS-001
and TW-TS-002 enhanced RTP formats for FR/EFR and HRv1, respectively;
libosmo-mgcp-client likewise supports a mechanism to request these
extensions. At the present time OsmoMGW rtpbridge endpoints don't
do anything different when these extensions are enabled (they
originate from OsmoBTS in this case), but for E1 Abis endpoints
the new MGCP extension controls whether or not these MGW endpoints
emit the enhanced RTP formats in question.
Changes to OsmoBSC:
1) Allow TW-TS-001 and TW-TS-002 to be enabled on all E1 BTS -
previously not allowed.
2) Whether E1-based or IP-based BTS are used, when RTP extensions
have been enabled by CN request (BSSMAP IE of TW-TS-003),
pass them to the MGW endpoint controlled by this BSC.
The second change makes RTP extensions work on E1 BTS, and also
paves the way for future OsmoMGW rtpbridge improvements where
the MGW might do additional processing that needs to be disabled
when TW-TS-* extensions are in use.
Depends: osmo-mgw.git I0d58e6d84418f50670c8ab7cf8490af3bc2f5c26
Change-Id: Iaa6e4c56313f06b79852c06dcec686f21950e638
If the design of an E1 BTS allocates a 16 kbit/s subslot on Abis
for each GSM timeslot, then if that GSM ts is configured to operate
as two TCH/H lchans instead of a single TCH/F lchan, that BTS has
to use the 8 kbit/s TRAU frame format of GSM 08.61 and not the
16 kbit/s format for each TCH/H lchan. Nokia E1 BTS and their
associated BSC and TCSM (TRAU) equipment are known to use this
arrangement; the present author does not know of any GSM BSS vendor
who used the 16 kbit/s format of GSM 08.61 - it might be a paper-only
spec.
Prior to the present change OsmoBSC always selected a 16k subslot
endpoint at the MGW, thus precluding possibility of working TCH/H
on otherwise supported E1 BTS. Change it to select 8k subslot
endpoints when operating on TCH/H lchans.
It may seem that this change breaks support for those E1 BTS that
do use 16 kbit/s TRAU frame format for TCH/H, whatever they may be -
but in reality, said support was already broken. Prior to the
present change OsmoBSC would smoosh both TCH/H lchans of a given
GSM ts onto the same MGW endpoint - which cannot work because they
are two different lchans carrying unrelated traffic.
Change-Id: If6141a55434ce08f8fdd1c69b6fc9a97d6c726a7
/osmo-bsc/src/osmo-bsc/bts_nokia_site.c:1903:36: error: 'bcch_trx_nr' may be used uninitialized [-Werror=maybe-uninitialized]
1903 | if (trx->nr != bcch_trx_nr) {
|
Change-Id: I6bfdefb44235291a5a1f1c72e5a5149d15e19b8f
This callback was drepecated and is not ever called since
libosmocore.git 70ce871532ab21955e0955d7e230eae65438f047 (release 1.3.0).
See also libosmocore.git d31de237582f6fe3315d61bb9a488d4cda92654e.
Change-Id: I391a6fc9f7325c1770ce410d31ed2d820726225a
We have a long outstanding issue with TRX RSL bootstrap,
espcially with BTSes with more than one TRX. The more TRX
a BTS has, the more time it takes for it get to a ready state.
This commit changes the TRX bootstrap logic as the following:
1. During OML initial config, all TRXes are configured locked.
This gives a better controled state of TRXes, and the BTS
enough time to do internal checks, SW load etc.
2. BTS_CONF_COMPL usde as entry point for the RSL bootstrap.
3. Unlock all TRXes, and give the BCCH TRX a reset.
4. Start RSL bootstrap.
Runtime tested with InSite and a MetroSite with 4 TRXes.
Co-authored by: Tomcsányi Domonkos <domi@tomcsanyi.net>
Change-Id: I9042a1e24f0932a23a26185181481db2ceddbb7c
Note: these are cosmetic changes so far, the plan is to use them
in the future to finetune the Nokia OML and RSL bootstrap logic.
Thanks Domi for helping with the code!
Change-Id: Id9f819b0649ba3c247db72d7d738e49c72388dc3
Wait for BTS_CONF_COMPL and start RSL bootstrap after.
This way the TRX SW load has enough time to complete and the RSL LAPD becomes available.
Important for MetroSite, UltraSite BTS types.
Change-Id: I7319a64f069d239a582547bc422058ff5848d2e2
Signed-off-by: csaba.sipos <metro4@freemail.hu>
Commit which introduced the gsm_bts_nr_t type forgot to use it in these
functions.
As a result, bts 256 ended up trying to allocate rate counters for id=0.
Change-Id: I5128becaf453f5cfbc722a55c756432e525fc884
Fixes: 6fe0e28a23
Related: SYS#7063
We receive a TXT indication that contains the PCU_VERSION from the PCU when the
connection to the PCU is established. This message contains a BTS number, which
is always 0. This is a hard coded value that does not refer to a specific BTS
object. Also it is not logical to inform a specific BTS object about the PCU
version. This information should be directed to the connecting process as a
whole. However, we use this TXT indication to trigger certain initialization
processes on the BTS object we manage inside the BSC process. Unfortunately the
BSC is currently using the BTS Number in the TXT indication to resolve the BTS
object. This is not correct, instead the BSC should iterate of over all BTS
objects and trigger the initializations for each BTS object that has a BSC
co-located PCU.
This change does not have any dependencies, it just corrects the behavior of
the BSC on initialization.
Related: OS#6507
Change-Id: I3fbf5430db8b8ea29efb147bd162706990453fc5
This function actually slippted in unintentionally when copying the
ipaccess driver from libosmo-abis.git as a base for the ipaccess-config
driver.
That function is actually not used either by libosmo-abis driver, but
was left there as a backward compatible API.
Fixes: 76b863eb47
Change-Id: I126014eed2196e9fe03c65dff7bb384ac81f39f8
Since osmo-bsc.git creation from openbsc.git around 10 years ago, a
reference was kept in osmo-bsc/ipaccess/ipaccess-config.c to ipa
specific code in the ipaccess e1_input stack of libosmo-abis.git
(ipaccess_fd_cb()).
Back at that time that was already considered to be an ugly hack, as
mentioned in include/osmocom/abis/ipaccess.h exporting that function.
This was done because ipaccess-config is quite different in several
aspects wrt to usual ipaccess based bts/osmo-bsc ipaccess lines:
* nanoBTS acts as TCP server and ipaccess-client as TCP client.
* TCP port 3006 is used instead of usual OML 3002.
* IPA handshake is actually also different, since despite nanoBTS being
the server it doesn't really trigger an IPA ID GET which need to
answer. Instead, upon ipaccess-config connecting, it will send an IPA
ID ACK and wait to receive an IP ID ACK itself before start
transmitting OML to ipaccess-config.
Due to all those differences, it really makes no sense to keep support
for this setup in the more usual bts<->bsc Abis e1line ipaccess driver
present in libosmo-abis.git.
Instead, this patch adds a new ipaccess-config-e1-driver.c which
implements a libosmo-abis e1_input line driver which works for this
specific service. libosmo-abis.git src/input/ipaccess.c from Change-Id
Idf241c8f2fdb86d090d4132a9b316b7236402232 is used as a base, further
simplifying it by removing stuff not really needed like BTS/BSC role,
tcp keepalive, tcp socket stats, etc.
Related: SYS#7063
Related: OS#5755
Related: OS#5756
Change-Id: I4d26876ce7d75a78f03c4fa66233550baf4fa7d5
That header is only really used to provide an old hack for
ipaccess-proxy tool in openbsc.h/osmo-bsc.h, and will be deprecated
soon.
src/ipaccess/ipaccess-config.c already has an explicit extern
declaration for ipacces_fd_cb() anyway, so drop the header in advance.
Take the chance to organize a bit better the includes based on dependency
chain.
Change-Id: I5f9daaf7789a56a08d2ec24b5e25e2e3b65b8b5b
It makes no sense that ipaccess-proxy is using the ipaccess_fd_cb()
function from libosmo-abis, since that function expects an e1_input
ipaccess driver to be set up by the app, which ipaccess-proxy never sets
up. Furthermore, even the data pointer being passed doesn't match the
one expected by the callback.
This seems to be a bug introduced 10 years ago in osmo-bsc.git
eb62301938, where the name of the private
function callback used by ipaccess-proxy was changed to
proxy_ipaccess_fd_cb() to avoid colliding with the ipaccess_fd_cb() from
libosmo-abis, but only 1 of the 2 references was changed at the time,
leaving the other one pointing to the wrong function.
Fixes: eb62301938
Change-Id: I1702d9913a462a36e4b78b503a8338ae2ad140b1
Call to e1inp_sign_link_destroy() may trigger a sign_down() callback,
which if happening synchronously, could end up reentring the same code
path we are in before bts->*_link was set to NULL.
Avoid it by marking the pointer as NULL immediatelly before calling
e1inp_sign_link_destroy().
Change-Id: Ice71b3143f167482e4a23759012b58e9ee13bfc0
We know the id because we just found/created it base don that id, so
simply use it instead of accessing the library object field.
Change-Id: Ib6d1f4898eb0a804ebda527fdd876d2ca4ec1e67
Use this new API instead of accessing the route struct directly.
Depends: libosmo-sigtran.git Change-Id Ife63bd384d247a761e0b89505ea71c41a4a16d9b
Change-Id: I198351fba4cfeba310b397c964e5306cd73189ba
This is useful to quickly lookup pagings aiming at a LAC+CI.
Until now, we first looked up in the LAC hashtable and then iterated
over it. However, that means a potential configuration where all BTS
share the same LAC will end up in iterating over 256 bts, which is not
nice.
Change-Id: I47db6c7543e5c6c3b8f0de3ae5ee1b53c2b5f16f
Related: SYS#7062
