aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2024-01-08fix spelling s/omso/osmo/ in bts_variant_namesHarald Welte1-1/+1
Change-Id: I37949c286498d99ecfdd3c36961226fefdc000ec
2024-01-06ctrl: Fix missing reply in set_bts_cell_reselection_offsetMatan Perelman1-0/+1
Change-Id: Iacdb192dc15ab7e10e06c0dfe0984fc8a5727ecc
2024-01-04vty: Ensure radio-link-timeout is a multiple of 4Matan Perelman1-1/+8
According to Table 10.5.2.3.1 in TS 144.018, radio-link-timeout values are between 4 to 64 in steps of 4. Change-Id: I733591d5f72f2e4f822761ca9eda85de7a4c6c81
2024-01-04ctrl: Add radio link timeoutMatan Perelman1-0/+51
Change-Id: Ic9532d4b051d34e71c91aaff545fb3dfa7d7c8b2
2024-01-02ctrl: Add rach expiry timeoutMatan Perelman1-0/+2
Change-Id: I74a402a3800d245e4bc3052ccb53d8d2660e9f52
2024-01-02abis_rsl: Add rach expiry timeoutMatan Perelman3-3/+18
This allows controlling the RACH DoS attack protection without increasing call drops rate. Change-Id: Iff7266672dd8bc9ce2b34b0478d98fb70691f425
2023-12-27VTY: fix config indentation for pcu-socket paramsKeith Whyte1-2/+2
osmo-bsc would not start with a config written from the vty due to incorrect identation on the pcu-socket parameters. Change-Id: I36a66794e654989b4b8bf54bb3727ccbfc2131fa
2023-12-27ctrl: Add rxlev access min controlMatan Perelman1-0/+36
Change-Id: I25bf4bb11bf8e34e80f740fb89a467fc6e491962
2023-12-12vgcs_fsm: fix NULL pointer dereference in vgcs_call_fsm_busy()Vadim Yanitskiy1-1/+3
Change-Id: I14ad41bfa1ab3455a6a175cfb05341ca12c8d73e Fixes: CID#322299
2023-12-11Only check for intersecting AMR codec support on matching TS rateAndreas Eversberg1-14/+20
Only check for intersecting full rate AMR codec, if the BTS has at least one full rate or dynamic time slot configured. Only check for intersecting half rate AMR codec, if the BTS has at least one half rate or dynamic time slot configured. Related: OS#5926 Change-Id: Ia4a8e7f22dc652655ee7c5458624df8ae136dd95
2023-12-09gsm_data: use ABIS_RSL_CHAN_NR_CBITS_* in gsm_pchan2chan_nr()Vadim Yanitskiy1-11/+7
Change-Id: Ic9370d8d7f13cce0f9c6e60a920d04161a7d6844
2023-12-09gsm_data: fix wrong variable set in gsm_pchan2chan_nr()Vadim Yanitskiy1-2/+2
I believe the actual intention was to reset the 'lchan_nr' variable, and not the 'chan_nr'. The 'lchan_nr' is used to compose the 'cbits': cbits = 0x04; cbits += lchan_nr; If the value is 4, then the result is: cbits = 0x04 + 4 = 0x08 which corresponds to SDCCH8 (not SDCCH4), and is clearly wrong. Change-Id: Ic9c7c2e46e24dab0b721221e9adcbbae2ca56d23 Fixes: ec1b5a0e9 "gsm_ts2chan_nr(): add assertions for lchan_nr" Fixes: CID#336586
2023-11-27recover BORKEN lchans for missing ACK scenariosOliver Smith2-0/+101
We already recover broken lchans where an ACTIV ACK or REL ACK arrives late. Now add a recovery path for lchans that are broken because no ACTIV ACK or REL ACK arrives at all. Add a timeout of X28 = 30s to the lchan BORKEN state. On timeout, attempt both a Channel Activation and a Channel Release. If any of them is ACKed, we have successfully synced BTS and BSC's state. After successful recovery, place the lchan back in the UNUSED state, available for servicing subscribers. If recovery is unsuccessful, just continue to attempt recovery every further X28 seconds. Patch-by: osmith, nhofmeyr Related: osmo-ttcn3-hacks I9b4ddfc4a337808d9d5ec538c25fd390b1b2530f Related: OS#5106 Related: SYS#6655 Change-Id: Ic4728b3efe843ea63e2a0b54b1ea8a925347484a
2023-11-27ASCI: Repeat notification after assigning MS to VGCS/VBS channelAndreas Eversberg1-0/+2
The assignment is repeated because the calling subscriber may not receive the notification on the DCCH, during handover process. After the assignment is complete, the calling subscriber will receive notification. This cannot be done automatically by the BTS, because the BTS has no relation between the notifications and the channels. The notification is required, so that the MS knows the channel to listen to when leaving the uplink the first time. If no notification is received, the MS will abort the call. Change-Id: Ife568b8c2756be332c0b8de21111f66f6e537c4d
2023-11-24bsc: Make socket queue max. length configurablearehbein3-4/+30
Title refers to the maximum length of the osmo_wqueue used for the PCU socket connection. Related: OS#5774 Change-Id: Ic5f19f4613bccaf582997a4d02b689adee083a0b
2023-11-22use X6 timer for REL ACK, not T3111Neels Hofmeyr1-1/+1
The lchan FSM timers were originally implemented to model earlier code as closely as possible. Now it has come up that T3111 is used in the wrong place: 3GPP TS 44.018 says: T3111: This timer is used to delay the channel deactivation after disconnection of the main signalling link. Its purpose is to let some time for possible repetition of the disconnection. Its value is equal to the value of T3110. Before this patch, we use it also to time the RF REL ACK message. That is pretty bad, because T3111 is only 2 seconds by default, making RF CHAN REL vulnerable for timeout. When a user increased T3111 to alleviate the problem, the result is that each lchan also delays its normal channel release procedure by the configured amount of time. Very inelegant. Instead, use the X6 timer for REL ACK, because X6 already times the CHAN ACTIV ACK, which is semantically identical. Compatibility / user impact: No negative impact expected. We can assume that every user out there has X6 configured to work for CHAN ACTIV ACK. From that logic, switching channel release ACK to the same timer is guaranteed to be what the user intends. We could instruct users in the release notes that they may now choose T3111 freely (as short as 2 seconds) without jeopardising channel release anymore. Related: SYS#6655 Change-Id: Ibd118fa23e5deb4381bc31b11a7b495f57901d6c
2023-11-21pcuif_proto: signal BTS model via PCUIFPhilipp Maier1-0/+8
At the moment the PCU has no way of knowing with which BTS model it is used with. However, some BTS models may require slightly different behaviour by the PCU, depending on which BTS model is used. So, lets add an additional bts_model field to struct gsm_pcu_if_info_ind in order to convey the exact BTS model to the PCU. Related: OS#6191 Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047 Change-Id: I4b58912ad7be3070829614853901aa19108ba2c0
2023-11-07ctrl: Add cell barredMatan Perelman1-0/+34
Change-Id: I6dc45fa1d76707be0d9f9d4391550be598ed0a6d
2023-11-06SI10: Fix uninitialized last_i indexAndreas Eversberg1-3/+2
Not only l_bts must be declared outside the for-loop, but also last_i. This is a fixup of I9dbbd066075f9ccb331616a2b59b46b1b44c8b4c. Related: CID#330311 Change-Id: Ia10c5e68cb2940d9360d78f606af25bb207ee55f
2023-11-01SI10: Fix uninitialized l_bts pointerAndreas Eversberg1-2/+3
l_bts must be declared outside the for-loop. If the loop is passed with n_bts set the first time, l_bts is set. If the loop is passed with n_bts set next time(s), l_bts is used to encode additional neighbor cell infos. Related: CID#330310 and CID#330311 Change-Id: I9dbbd066075f9ccb331616a2b59b46b1b44c8b4c
2023-10-24osmo-bsc: Have PCU socket connection use osmo_wqueuearehbein1-63/+36
Close PCU socket on write queue overflow. Related: OS#5774 Change-Id: Ifd9741045a87338e17eec3492590a5de9c308cb5
2023-10-24pcuif_proto: clean up last remains of old PCUIF v10Philipp Maier1-2/+0
There are still some remains that are related to the old PCUIF v10 protocol version. Let's clean those up. Related: OS#5927 Depends: osmo-pcu.git I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8 Change-Id: Iebb3a634fee680bdc3636a61f3ccaa1e97e54a64
2023-10-23ASCI: Add System Information 10 supportAndreas Eversberg2-2/+307
For each BTS, an SI 10 is generated with the informations about all neighbor BTS that have the same group/broadcast call. The SI 10 will only define neighbor cells within the same BSC, because it does not know about neighbor cells within other BSCs. When multiple channels are used for a group/broadcast call, the SI 10 is generated after all channels have been activated. Subsequent channel activations result in an update of SI 10 on all channels. Change-Id: Icd3101e6dd935a57f003253aaef400c2cf95a0c3
2023-10-09ASCI: Make neigh_list_get_arfcn() available to other usersAndreas Eversberg1-9/+32
The error logging message within this function is moved to the user neigh_list_get_arfcn(). In case of an error, which results in measurement report with cell index that does not exist in the list of neigbor cells, the measurement report is truncated to 0 neighbor cell measurements. Change-Id: Ia8a1dca4837536129d17e7784b892bcb75b9ca4b
2023-10-09Select correct neighbor list for measurement report decodingAndreas Eversberg1-1/+8
System Information 2 (bis/ter) uses BA_IND of 0. This refers to "neigh_list". System information 5 (bis/ter) uses BA_IND of 1. This may refer to "neigh_list" or optionally "si5_neigh_list", depending on the VTY settings. If BA_IND of 1 is received in measurement report and if the optional "si5_neigh_list" is used, this list is chosen to decode the measurement report. Change-Id: Ie9123928fb3ae6f10921ecf01d1b50330661da38
2023-10-09Do not generate 'bit map 0' neighbor lists with R-GSM ARFCNAndreas Eversberg1-2/+2
Before this patch, neighbor cells with ARFCN 955 to 974 were ignored in the GSM 900 band. This resulted an empty 'bit map 0' list in SI2/SI5 messages. This patch includes R-GSM ARFCN in range 955 to 974. A different encoding is chosen, if neigboring cells fall within this range. Change-Id: I40d024290fa4be2ba8d3149ec841b182d0cc8c1f
2023-10-04pcuif_proto: rename PCU_IF_FLAG_SYSMO to PCU_IF_FLAG_DIRECT_PHYPhilipp Maier1-1/+1
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo to signal to the PCU that the direct PHY access for the sysmo-bts DSP should be enabled. With time, support for other BTS models was added and the flag became a synonym for "direct PHY access", so it makes sense to rename it to "PCU_IF_FLAG_DIRECT_PHY" Related: OS#6191 Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b Change-Id: I23df067df99b76048667131905c4448d32d80640
2023-10-04meas_feed: Use osmo_io instead of write queuearehbein3-51/+41
Related: OS#6170 Change-Id: Ib0570a3242e2846062e24c93cbbbbd31137acdee
2023-10-03Drop unused local varPau Espin Pedrol1-2/+0
Change-Id: I6da89b8861c0bd17fc011b55d5f4979ad6787f80
2023-09-28vty: make NCC Permitted (SI2) configurableOliver Smith1-0/+77
Related: SYS#6579 Change-Id: I71bb855c35378f8f0598bc11a42bd274b7232a5e
2023-09-27sccplite: Support multiple MGW in MGW poolPau Espin Pedrol2-18/+118
Before this patch, the MGW was selected at startup, and the MGCP data was always forwarded to that same MGW. If several MGW were configured in the MGW pool, then osmo-bsc would select any of those from the pool, and start configured the BTS-side connection on an endpoint in that MGW. However, when the MSC submitted the MGCP encapsulated in IPA to the BSC, the BSC would always forward the MGCP message to that same MGW selected at startup. As a result, multiple MGWs configured with osmo-bsc using SCCPlite was broken. This commit fixes support for multiple MGWs by looking up the already selected MGW (to setup the BTS-side conn on the endpoint), based on the CIC (MGCP Endpoint) which was provided by the MSC upon AssignReq. Related: OS#6189 Depends: libosmocore.git Change-Id Iee361d740845257fa62c9093e30e8079fa933827 Depends: osmo-mgw.git Change-Id I18d7bdf650c0ec87ae16ed4944aed9f495400137 Change-Id: Ia106a21b7692eb5b2ac3b5ac2b358bedbc3b9da6
2023-09-24si2quater: Invalidate thresh_lo, prio and qrxlm when neededMatan Perelman3-9/+25
Change-Id: I5910ce8db2d085295b327b12096ba129369eb532
2023-09-23abis_nm: send Get Attributes to GPRS Cell MO(s)Vadim Yanitskiy1-0/+31
Change-Id: Ib6d87da49217f1c8d76445ce623a511a07daedbf Related: OS#4505
2023-09-23abis_nm: send Get Attributes to Rado Carrier MO(s)Vadim Yanitskiy1-0/+31
Change-Id: If7b75689c12a253377f2747babd4d7ebd1db5f87 Related: OS#4505
2023-09-23oml: ipacc: fix sending hard-coded GPRS Cell attributesVadim Yanitskiy1-23/+27
Change-Id: I7d90ca3d6a660af8e953e890c7919194f5d297d2 Related: OS#4505
2023-09-23oml: ipacc: send GPRS Cell attributes based on IPA Object VersionVadim Yanitskiy1-26/+56
Change-Id: Ie0fb3eaf76e1f70e5a19bb088e1674b7e553d32a Related: OS#4505
2023-09-23oml: ipacc: print all supported versions of MOsHarald Welte1-3/+10
The first byte is the default version, the other bytes describe the optional other versions supported by the MO. Print them all. Change-Id: I01da4883cf59101ddaef575979519ac48fcf54b0
2023-09-23abis_nm: delay configure_loop() until NM_MT_SW_ACTIVATED_REPVadim Yanitskiy7-1/+82
Even though the Abis/OML message flow looks the way it should look on the wire, it does not actually reflect the sequence/flow of events and actions in the NM FSMs. For example (extracted from a PCAP): GPRS Cell(00,00,ff) State Changed Event Report GPRS Cell(00,00,ff) Software Activate Request GPRS Cell(00,00,ff) Software Activate Request ACK GPRS Cell(00,00,ff) Activate Software GPRS Cell(00,00,ff) Activate Software ACK [a] GPRS Cell(00,00,ff) State Changed Event Report [b] GPRS Cell(00,00,ff) Software Activated Report [c] GPRS Cell(00,00,ff) Get Attributes GPRS Cell(00,00,ff) Get Attributes Response [d] GPRS Cell(00,00,ff) IPA Set Attributes GPRS Cell(00,00,ff) IPA Set Attributes ACK GPRS Cell(00,00,ff) Change Administrative State GPRS Cell(00,00,ff) Change Administrative State ACK GPRS Cell(00,00,ff) State Changed Event Report GPRS Cell(00,00,ff) Opstart GPRS Cell(00,00,ff) Opstart ACK A follow-up patch [1] changes the logic generating message [d], so that the IPA Object Version of the GPRS Cell MO is taken into account when adding the attributes. The problem is that both messages [c] and [d] are generated and queued for transmission on the receipt of message [a], but *before* message [b] has been processed. So the IPA Object Version is not known and assumed to be 0 at that point in time. This patch delays configure_loop() until message [b] is received. So far only for nanoBTS and only for those MOs, for which Figure 2 in 3GPP TS 52.021 explicitly mentions that the SW downloading and activation procedures may be required, plus for the ip.access specific MOs which all seem to support the SW activation. osmo-bts does send SW Activated Report only for a subset of MOs, which does not include Baseband Transceiver, Radio Carrier, and Radio Channel. 3GPP TS 52.021 is not clear on whether this message shall be sent by all MOs either, so we consider it optional and delay configure_loop() only for nanoBTS. Change-Id: I3953a5e41eb27165f9ff203cac7447ee9d311abf Related: [1] Ie0fb3eaf76e1f70e5a19bb088e1674b7e553d32a
2023-09-21abis_nm: handle NM_EV_SW_ACT_REP in ST_OP_DISABLED_{DEPENDENCY,OFFLINE}Vadim Yanitskiy8-0/+58
3GPP TS 52.021 does not strictly mandate that the SW Activated Report can only be received in state DISABLED/OFFLINE. The only requirement is that the software load procedure (if needed) and activation is to be performed in this state. The successful outcome of software activation procedure is indicated by the BTS using the above-mentioned SW Activated Report message, which may be received in ST_OP_DISABLED_{DEPENDENCY,OFFLINE} too. The MO state changes are triggered by the State Changed Event Report messages, and happen asynchronously with the software activation. This patch fixes the following warnings seen with a nanoBTS: NM_BTS_OP(bts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_GPRS_NSE_OP(nse2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_GPRS_CELL_OP(gprs-cell2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_GPRS_NSVC_OP(nsvc0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_GPRS_NSVC_OP(nsvc1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_BB_TRANSC_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts3){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts4){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts5){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts6){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_CHAN_OP(bts2-trx0-ts7){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted NM_RCARRIER_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted The following warning is still expected to show up though: NM_BTS_SM_OP(bts_sm){ENABLED}: Event SW_ACT_REP not permitted but is caused by a different problem, which is to be fixed later. Change-Id: I00a423adcde5c34977f4c4dad920874687fa493c
2023-09-19oml: ipacc: add missing is_ipa_abisip_bts() checksVadim Yanitskiy1-2/+24
These functions are called from a signal handler (SS_NM), and the signal itself is sent from the generic OML logic whenever the Software Activated Report is received from some BTS, which is not necessarily a nanoBTS or osmo-bts. It would be nice if we could check the BTS type once in the signal handler, but the signal data is not always the same and depends on the signal type, so unfortunately it's not possible. Change-Id: I088ff75f2048e54e4bfd926a79c1dcf27b4fb3a4
2023-09-16abis_nm: fix bts->nr vs bts->bts_nrVadim Yanitskiy1-2/+2
Using bts->nr on the wire is wrong because: * bts->nr is a BTS number in the BSC's config file, * bts->bts_nr is a BTS number within the SITE-MANAGER MO. The problem does not show up if there exists only one BTS node in osmo-bsc.cfg. Otherwise, the Software Load and BTS Restart procedures are broken for nanoBTS. Change-Id: I99d9c72752e55c4553e2e9c60df5caa8343b7be0
2023-09-15oml: ipacc: fix copy-pasted talloc chunk namesVadim Yanitskiy1-5/+10
Change-Id: Ib0858c0d84b9bd2d3a4d732cfedb045862d2efed Related: OS#4505
2023-09-15oml: ipacc: log supported features using LOGL_INFOVadim Yanitskiy1-1/+1
Change-Id: Ie0b05bc9e3739b5a38b32a676641e64f2cf698ac Related: OS#4505
2023-09-15oml: ipacc: parse Object Version from SW Activated ReportVadim Yanitskiy1-0/+15
Change-Id: I39105096a6b29bd7e4fb15287653074527c3e024 Related: OS#4505
2023-09-15bts_ipaccess_nanobts: clean up, use gsm_objclass2mo()Vadim Yanitskiy1-141/+28
Change-Id: Ic6c0dfe950459d07a8f506b5007a65fea1950c18
2023-09-14gsm_data: refactor/simplify and expose gsm_objclass2mo()Vadim Yanitskiy1-47/+18
Change-Id: Ic03fdfabf84a1b5cd8046101c1575296914c6332
2023-09-13abis_nm: get rid of MAX_BTS_ATTRVadim Yanitskiy3-4/+7
This is a partial revert of commit [1], which defined a limit on the number of attributes and SW Description IEs as a constant and added a spec. reference. The problem is that there is no such limit in the referenced 3GPP TS 52.021. The attributes and SW Description IEs are using TL16V encoding, so there can be as many as the Length part can represent. It's actually the limitation of our side, since we allocate a buffer of fixed size on the stack for parsing. * Remove the MAX_BTS_ATTR and confusing spec. reference. * For the SW Description IEs, define SW_DESCR_MAX locally. * For the attributes, define the buffer size in place. Change-Id: Idd8b971d32cf0f7a910a664d921e644b7c32d831 Related: [1] 1ebf23b7fe "Prepare for BTS attribute reporting via OML" Related: OS#4505
2023-09-13nm_{bb_transc,bts}_fsm: rework sending of Get AttributesVadim Yanitskiy2-12/+22
* Make it easier to append the attributes conditionally. * Remove irrelevant comments about the order of attributes. * Request NM_ATT_IPACC_SUPP_FEATURES from Abis/IP models only. Change-Id: Ice5bddd51481a3ef9fcffd77a4c292ea211bf179 Related: OS#4505
2023-09-13abis_nm: parse feature flags in NM_ATT_IPACC_SUPP_FEATURESVadim Yanitskiy2-1/+74
Since change [1], among with the other attributes we started requesting NM_ATT_IPACC_SUPP_FEATURES from the BTS. This patch adds the logic for parsing the response (so far only printing supported features). Change-Id: I64cffa0bdead3617cc169c83b0f6ddf74f0866a7 Related: [1] 43440e1fc5758c52e80a0d182afa7c9d16b21426 Depends: libosmocore.git Ia4208e10d61843dd6ae77398f6624c918dc81ea4 Related: OS#4505
2023-09-13abis_nm: separate parsing of osmo-bts features into a functionVadim Yanitskiy1-33/+48
This commit prepares for adding handling of additional attributes. The parse_attr_resp_info_attr() is already quite complex, so take a chance to simplify it a bit. Change-Id: Ia5919a8311cd6a7fc16d02d2196276881e96f4c5 Related: OS#4505
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-21 04:50:04 +0000