aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2023-08-31pcu_sock: use PCU_IF_SAPI_AGCH_2 instead PCU_IF_SAPI_AGCHPhilipp Maier2-2/+15
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. One new feature of PCU_IF_SAPI_AGCH_2 is that the PCU may ask to send a confirmation when the MAC block is sent. CAUTION: This patch breaks compatibility to current master osmo-pcu (See also "Depends") Related: OS#5927 Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292 Change-Id: I709c27adaf09a6766cfde4d76d878626d30ebb3c
2023-08-31pcuif_proto: check confirm flag in struct gsm_pcu_if_pchPhilipp Maier2-1/+4
Since osmo-bsc uses RSL (with a propritary Ericsson RBS specific extension) to send a confirmed IMMEDIATE ASSIGNMENT messages via PCH, we can not just forward the MAC blocks into the paging queue without determining whether the MAC block is a PAGING message or an IMMEDIATE ASSIGNMENT message. the reason for this is that RSL uses two different message types (IMMEDIATE ASSIGNMENT COMMAND and PAGING COMMAND) to process IMMEDIATE ASSIGNMENT and PAGING messages. This means we have to look into the MAC block to make sure whether the message is a PAGING message or an IMMEDIATE ASSIGNMENT message. We also need to make sure that the confirm flag is properly executed. In the case of the IMMEDIATE ASSIGNMENT this means we have to include (confirm=true) or not include (confirm=false) the RSL_IE_ERIC_MOBILE_ID into the IMMEDIATE ASSIGNMENT COMMAND message. In the case of PAGING we directly echo a confirmation after sending the PAGING COMMAND via RSL when a confirmation is requested. Related: OS#5927 Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04 Change-Id: I3d2842626b7e8325860ea3160c7d900d39e953a0
2023-08-30meas_feed: Increase wqueue max_len to 100 and make it vty-configurablePau Espin Pedrol1-0/+3
The previous amount of 10 messages may be small if the BSC is processing lots of measurements from lots of BTS connected to it. Increase it to 100 by default, and allow changing the write_queue length through the VTY. Related: SYS#6550 Change-Id: Ib2e3591498c038b8e59f3ad447ac1f65928d6da8
2023-08-10pcuif_proto: get rid of _DT, _dt (Direct TLLI)Philipp Maier1-6/+6
Since we now no longer refer to TLLI when we mean "message ID" (msg_id), we should also remove the "_DT" / "_dt" suffix from structs and define constants and replace it with "_2" if required. Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0 Change-Id: I628aaf19999a0004d0760d25ecd323cdbc0076f5 Related: OS#5927
2023-08-10pcuif_proto: remove unnecessary members from gsm_pcu_if_data_cnf_dtPhilipp Maier1-9/+0
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments mit Ericsson RBS base stations were made. It is essentially a copy of gsm_pcu_if_data, where the mamber "data" was replaced with a member "msg_id" (which was originally called "tlli"). Since we didn't know back then which parameters we would still need at some later point we kept all the other parameters. However, to this day we never used the parameters below fn. Even fn was only used for logging purposes, but is now also unused. Let's remove all those unused members. (Since all removed members are at the tail of the struct, compatibility with other programs that use the PCUIF should not break.) Change-Id: I37845408edd96017b50559964c82b2cdc5e143a7 Related: OS#5927
2023-08-08pcuif_proto: rename tlli to msg_idPhilipp Maier3-7/+7
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an identifier and the related struct member is also called "tlli". Unfortunately this is misleading since the message identifier does not necessarly have to be a TLLI. It is just an implementation detail that osmo-pcu uses the TLLI as a message identifier. To make that clear, lets rename the tlli member (and variable and parameter names where it is passed on) to "msg_id". (Since this change only renames variables and struct members it will not break compatibility with other programs that use the PCUIF) Related: OS#5927 Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6 Change-Id: Ifb3f257099b52c50e525768484f9e93282089d0f
2023-07-21Select channel type by enum instead of three booleanAndreas Eversberg1-5/+9
struct lchan_activate_info and struct lchan_modify_info use an enum to define, if the channel type is for a normal channel, a VAMOS channel or a VGCS/VBS channel. Change-Id: I21167eb4192c02cd7b5e1574cddb382a3feaebe0
2023-07-21ASCI: Add assignment to a VGCS/VBS channelAndreas Eversberg1-0/+1
The assignment is triggered by the MSC by sending an ASSIGNMENT REQUEST with a group call reference. The reference is used to find the VGCS/VBS channel that belogs to the referenced call. The existing VGCS/VBS channel is reactivated. This will put the channel into a state where the MS can establish the link on it, to complete the assignment. The old connection is released by the MSC and assignment completion is handled by the VGCS FSM. Change-Id: Idaa864cd5ce4df6c3193494ce12d91523c104d89 Related: OS#4852
2023-07-21ASCI: Send release on VGCS/VBS channel via unit dataAndreas Eversberg1-1/+1
Channel release is sent to MS that is in dedicated mode on the main DCCH. Additionally it is sent as unit data on a VGCS/VBS to notify all listeners that the channel has been released. All listeners return to IDLE mode. Change-Id: Ib777fe98c8ce2342082d88d227b796167d92cfe1 Related: OS#4852
2023-07-21ASCI: Add processing and FSMs for VGCS/VBSAndreas Eversberg3-0/+176
Change-Id: Id9e94fb4f27bb438b7093c031344a3400bfa34f1 Related: OS#4852
2023-07-21ASCI: Add TX support for UPLINK FREE/BUSY messagesAndreas Eversberg1-0/+2
Change-Id: Ia27e0ebb5bf7edb1b9f84999cafc028231b9489f Related: OS#4852
2023-07-21ASCI: Add support for sending RSL UNIT-DATA towards BTSAndreas Eversberg1-0/+1
This is required to send UPLINK FREE and UPLINK BUSY messages to the BTS. Change-Id: I25e80f079989a4c7dede58c327c22b958784f3ff Related: OS#4852
2023-07-21ASCI: Do not release channel, if SAPI 0 is releasedAndreas Eversberg1-0/+2
A VGCS channel must not release, if all SAPIs (including 0) are released. lchan FSM will ignore this. Change-Id: Ief1e1894362c4917f6e0092268690f68c8193750 Related: OS#4852
2023-07-21ASCI: Add new debug category "ASCI" for VGCS/VBS state machinesAndreas Eversberg1-0/+1
Change-Id: I4714fa4ff2b1327183a365223a3e3d89ae0357f7 Related: OS#4852
2023-07-21ASCI: Make function to add OSMUX IE publicAndreas Eversberg1-0/+2
Rename _gsm0808_ass_compl_extend_osmux() to gsm0808_extend_osmux(). This IE is also used for VGCS/VBS assignment command that is located in a different file. Change-Id: I1452cabb142f9e7a169f4ddfeac85908abaf8dfc Related: OS#4852
2023-07-21ASCI: Add TX support for UPLINK RELEASE messageAndreas Eversberg1-0/+1
Change-Id: Ie3d8ad1ea8325c13759838d8083c6e47a0f54497 Related: OS#4852
2023-07-21ASCI: Add selection reason for VGCS/VBS channelsAndreas Eversberg2-0/+2
"enum lchan_select_reason" gets a new selection reason: "SELECT_FOR_VGCS" The selection "direction" can also be changed via VTY. Change-Id: I6b96d0a1df68efa5858b98297ebe0944b1473aaf Related: OS#4852
2023-07-21ASCI: Add support for Group/Broadcast channel activationAndreas Eversberg1-0/+4
"struct lchan_activate_info" is expanded to support flags for VGCS and VBS. These are used to send the correct Channel Mode to the BTS. "enum lchan_activate_for" is expanded to indicate and activation of VGCS/VBS calls. Change-Id: Ic0c0597d149d0758d6766937d99660fa02e0e139 Related: OS#4852
2023-07-21ASCI: Add support for NOTIFICATION COMMAND (RSL) messageAndreas Eversberg1-0/+1
This message will be sent to each BTS with a VGCS/VBS channel to notify the served MSs about ongoing group/broadcast calls. It is also used to remove the notification, if the call is terminated. Change-Id: I96ec0ee5d1a772a45f1ebfd64210718c8bf5aa58 Related: OS#4852
2023-07-21Fix typo in rate counters ASSIGMENT->ASSIGNMENTAndreas Eversberg1-2/+2
Change-Id: I73079948afbdde35594660959b5335118a810d7b
2023-07-21ASCI: Add new rate counters to support VGCS/VBS messagesAndreas Eversberg1-0/+20
Change-Id: I18e4ca3599e480de2d0f64cc1b6f4bb6ce8020d4 Related: OS#4852
2023-05-31Support (optional) indication of NCH position in SI1 rest octetsHarald Welte1-0/+5
This adds the vty commands and respective logic to allow the user to specify the NCH (notification channel) position in the SI1 rests octets. Change-Id: Iefde0af44a663f22462a54d68a58caa560eceb2f Related: OS#5781 Requires: libosmocore.git I24a0095ac6eee0197f9d9ef9895c7795df6cdc49
2023-05-24pcu_sock: fix PCUIF interface (PCH)Philipp Maier1-5/+1
The PCUIF interface implementation in osmo-bsc provides two ways to access the paging channel (PCH). 1) Under the SAPI PCU_IF_SAPI_PCH PAGING COMMAND messages are accepted as whole MAC block but the format is in the style that we are going to deprecate with PCUIF v.11. Also at the moment those PAGING COMMANDs are not confirmed towards the PCU. This is also not necessary since osmo-pcu would silently drop such confirmations. (see pcu_rx_data_cnf in pcu_l1_if.cpp) 2) Under the SAPI PCU_IF_SAPI_PCH_DT messages are also accepded as MAC blocks but the SAPI will only accept IMMEDIATE ASSIGNMENT messages. The messages are encapsulated in a struct that holds IMSI (paging group) and TLLI (used for confirmation) as separate struct members. The messages are also confirmed towards the PCU as it should be. Since we want to depreacete the older V.10 version of PCUIF and there is not much benefit in maintaining two interfaces we should use SAPI PCU_IF_SAPI_PCH_DT for both message types. This also requires small adjustments to osmo-pcu (see Depends). Depends: osmo-pcu.git I99cfe373fa157cfb32b74c113ad9935347653a71 Related: OS#5927 Change-Id: I82443f2b402aa2416469c8c50b1c050323ef3b8f
2023-05-18copyright: fix typo: sysmocom s/s.m.f.c./s.f.m.c./ GmbHVadim Yanitskiy2-2/+2
Change-Id: I849a18a3bfd15aad00de3e103339540a7548e097
2023-05-11pcu_connected(): constify parameterMax1-1/+1
Change-Id: I6d18ec0ad2bd6f71e0187ed70b03c3a2d0447f21
2023-05-08cosmetic: Rename is_ipaccess_bts() to is_ipa_abisip_bts()Harald Welte1-1/+1
This function is used to check if the BTS is using the IPA Abis-IP transport, and not whether its manufacturer/vendor is ip.access. Let's use a less confusing name. Change-Id: I202c58341c1536489064d2671c0842c6f70b5429
2023-05-01fix mscpool for large msc NRsNeels Hofmeyr1-2/+2
Use the proper type that can handle the entire range of MSC numbers we allow on the VTY, we have: #define MSC_NR_RANGE "<0-1000>" Before this patch, MSC pool round robin would glitch around for any 'msc' numbers 'msc 256' thru 'msc 1000'. Change-Id: I98bee022c1a78508554d2ff4a10fbce3c53f1128
2023-04-28bts: st_op_enabled_on_enter(): resume C0 power reductionVadim Yanitskiy1-0/+1
If power saving is enabled for a BTS, it should remain enabled even if the BTS is restarted for whatever reason. This persistence can be achieved by re-sending the configured power reduction value whenever the BTS NM FSM enters the ENABLED state again (i.e. reconnects). Separate gsm_bts_send_c0_power_red() from gsm_bts_set_c0_power_red() and call the former from st_op_enabled_on_enter(). All we need to do is to send the value that was configured before, per-timeslot power reduction limits remain and need not to be updated. Take a chance to move logging from BTS specific to the generic code. Change-Id: Ic3f8a2ab0ffd049a8ed84361a3a588c1e1b23ac6 Related: SYS#6435
2023-04-28struct gsm_bts_model: rename power_ctrl_{set->send}_c0_power_redVadim Yanitskiy1-1/+1
Change-Id: I13d9e6ea2a2b7b11f92532d377e71f0e83974622 Related: SYS#6435
2023-04-15fix comment typoNeels Hofmeyr1-1/+1
Change-Id: I5c38f47cdf21d4e787341bf68e1e63c713003bbd
2023-04-14SCCP N-PCSTATE: trigger MSC status on PC availabilityNeels Hofmeyr1-0/+1
Related: SYS#6319 Related: Ia1aea4e33230d6a685b72ea5ba20dd9c7d265d44 osmo-ttcn3-hacks Related: Ib4a5330df30a73e744c316898817b2fa3271d75e osmo-ttcn3-hacks Change-Id: I3a0869598b8395601a16d78dbc46eec400c0ea84
2023-03-31Move paging queue specific handling to signal callback outside RSL codePau Espin Pedrol1-3/+0
The signal is already there but not being used. Let's further split generic paging code from RSL specificites. Change-Id: Iabc1c29908a5136501d6dc6e60f8777dab511b86
2023-03-20pcuif_proto: increment version numberPhilipp Maier1-1/+1
The co-located PCU support for Ericsson RBS E1 CCU made it necessary to add new features to the PCU socket interface, so let's increase the version number. Change-Id: I8315bd67c7f3eb0d7ee71b64cd4dff889a84fcf1 Depends: osmo-pcu.git I2a78651593323e8b9627c39918d949a33497b70f Related: OS#5198
2023-03-20pcu_sock: handle multiple BTSs with one BSC co-located PCU (in theory)Philipp Maier3-8/+8
The current PCU implementation has never been tested with multiple BTS attached to it. This is due to the fact that it has been used exclusively in an BTS co-located setup where naturally only one BTS is present. The PCU sock protocol supports multiple BTSs in theory and we should handle this correctly. Related: OS#5198 Change-Id: I0b42c2c130106f6ffca2dd08d079e1a7bda41f0b
2023-03-20pcu_sock: drop usage of PCUIF flag PCU_IF_FLAG_DTPhilipp Maier1-1/+0
The flag PCU_IF_FLAG_DT is no longer needed. The PCU implementation will distinguish by the version number instead. Change-Id: I0dc20e351deb14906b2edffc39499bad9659cc35 Related: OS#5198
2023-03-20bts: add function to check if a BTS has a BSC co located PCUPhilipp Maier1-0/+12
At the momemnt we use is_ericsson_bts() to check if the BTS uses a BSC co-located PCU, this is a bit ambiguous, lets have a function that explicitly checks for a BSC co-located PCU and nothing else. Change-Id: I23ed4219e5ebd188867c17f387ca877efa9bc3b0 Related: OS#5198
2023-03-20bts: is_xyz_bts check functions should return boolPhilipp Maier1-18/+18
The check functions that we use to distinguish between the various types of BTSs return an integer that can be 0 or 1. Let's change the return type to bool Change-Id: I3de957f228452c9d3aa4fed342f73bfb17363b40
2023-03-17Fix Lb/A SCCP conn lookup after recent regression in optimization patchPau Espin Pedrol1-14/+19
In osmo-bsc, there's currently 0..1 Lb links and 0..N A links, where N is the number of MSC, but links can be shared in the underlaying stack (struct osmo_sccp_instance), hence range 0..N of different osmo_sccp_instance (identified by PC). Even more, the Lb and A link can share the same underlaying stack, so osmo-bsc can end up with only 1 struct osmo_sccp_instance shared by all the above mentioned links in case all are configured under the same PC. Total range A+Lb is 0..(1+N). A struct gsm_subscriber_conn stores 2 struct sccp_instance*, one for Lb (conn->lcs.lb.*)and one for A (conn->sccp.*). They can actually point to the same sccp_instance or to different ones, as explained above, depending on the configured setup. In any case, a gsm_subscriber_conn needs 2 rb_nodes since it can hold any of the 2 conn_ids independently (A or Lb). The previous patch forgot to add that 2nd rb_node as well as some initialization and release code for the Lb conn. This patch addresses that. When the 2nd rb_node, a problem when iterating the rbtree appears: how to find out the "conn" pointer from the rb_node pointer, since the rb_node pointer can be any of the 2 rb_nodes inside the struct at a different offsets. In order to solve that problem, a new struct bscp_sccp_conn_node is added, which holds all the relevant information used by the rbtree lookup code in a generic way (rb_node and conn_id), plus a backpointer to the struct bsc_gsm_subcriber it relates too. Fixes: 85062ccad31e9fb73e0256a5ee556c6ae0a16449 Change-Id: If42d93adee71d646766929a09bc01ae92b734ef3
2023-03-15bsc_subscriber: Optimize lookup of bsub by TMSIPau Espin Pedrol1-0/+6
It was found that on a busy osmo-bsc process (>1000 concurrent calls spead over different BTSs), a good amount of time is spent iterating the subscribers list trying to find a subscriber based on a TMSI (1.60% of total CPU time used by osmo-bsc). This patch introduces a new rbtree under struct bsc_subscr_store which allows storing all the busbs ordered by TMSI. This way, lookup time changes O(N) -> O(log(N)), at the expense of increased insert/deletion time O(1) -> O(log(N)). Related: SYS#6200 Change-Id: If27429e715ef4b327177e427249e68321a6e83cc
2023-03-15bsc_subscriber: Introduce bsc_subscriber_store objectPau Espin Pedrol2-12/+15
This allows keeping the bsc_subscriber storage internals outside of main gsm_network code, while easily allowing making the internal implementation more complex (in order to optimize it in a follow-up commit). It is also nice since we get rid of uncommon procedures being used in this code, like allocating an llist directly as a talloc context, etc. Change-Id: I616e8872af4ac63a6985f8900909e324ba889192
2023-03-15bsc_subscriber: Mark functions used only internally as staticPau Espin Pedrol1-9/+0
Change-Id: I846af993905aee0be75aa3021460b130362c6d3d
2023-03-15bsc_subscriber: Drop unused function bsc_subscr_find_by_mi()Pau Espin Pedrol1-2/+0
Change-Id: I15a51fa8a5c30fd92b34ebb366d0a805f8902cd0
2023-03-15Move bsc_conn_by_bsub() and make it staticPau Espin Pedrol1-1/+0
The function was currently in osmo_bsc_sigtran.c but was never used there, and it really doesn't have any relation to that file. Let's move it to the only place where it's used so far, and mark it as static. Change-Id: I8a8cef45aa378421e0ac328d3b29b9d194698a55
2023-03-15Optimize subscr_conns lookupPau Espin Pedrol1-2/+18
It was found that, on a busy osmo-bsc (>1000 concurrent calls spread over several BTS), the CPU consumption looking up for gsm_subscriber_conn based on SCCP conn_id can take a considerable amount of time (>5% of osmo-bsc already taking 70% of the CPU time on the core it is running on). The huge CPU consumption happens because a linear search is done (llist) over the entire list of SCCP connections every time an SCCP message is handled. In order to optimize this lookup, this patch introduces a new struct bsc_sccp_inst which becomes associated to the libosmo-sccp osmo_sccp_instance. Each of this strucs maintains an rbtree of gsm_subscriber_conn ordered by conn_id. As a result algorithmic complexity adds O(log(N)) during insert, lookup and delete of SCCP conns, but gets rid of O(N) previous lookup. As a plus, finding a new conn_id now takes generally O(log(N)), while before it used to take O(N). Related: SYS#6200 Change-Id: I667d3ec1dad0ab7bc0fa4799d9611f3a914d07e5
2023-03-13bscc_sccp: Avoid allocating conn_id 0x00FFFFFFPau Espin Pedrol1-1/+1
The 0x00FFFFFF source local reference is reserved in M3UA/SCCP, hence avoid allocating a conn_id with that value since later on when reused as a source local reference it would fail to be encoded. Change-Id: I5c62bbfa89140d754edccb4404503cb70d5fde89
2023-03-13Clarify type and values of sccp.conn_idPau Espin Pedrol1-4/+12
Currently, the conn_id is allocated in a range 0..0xffffff by bsc_sccp_inst_next_conn_id(), and -1 means it is unset. This means allocation expects "int" to be at least 32 bits integer, in order to fit 24 bits for 0..0xffffff plus the -1. Hence, let's define the variable as uint32_t, as already done in libosmo-sccp. Use last value 0xFFFFFFFF ((uint32_t)-1) and avoid playing with the value being unsigned sometimes and signed only for "unset" value. The value is actually already handled as unsigned (printed with %u) in most places. Change-Id: If019bcbc1e28929fe8d981fef9103835fc6ead2e
2023-03-10constify bsc_conn_by_bsub() ptr paramPau Espin Pedrol1-1/+1
Change-Id: I44b1397e7771c803efdca6bf59750ca5568df365
2023-03-10cosmetic: gsm_data.h: Fix typo in commentPau Espin Pedrol1-1/+1
Change-Id: Id59eb176551b2546ee6ff9c7f0eee4d8dd6ed199
2023-03-08abis_rsl: CSD: add RTP_CSD_FMT IE to CRCX/MDCXOliver Smith2-0/+6
Related: OS#4393 Change-Id: I4964b268124d29354e252c2ee509866ae75fab6d
2023-03-07pcu_sock: use struct to transfer IMMEDIATE ASSIGNMENT for PCHPhilipp Maier1-0/+13
When the IMMEDIATE ASSIGNMENT is sent from the PCU to the BSC using the "direct TLLI" method, the TLLI (and the last three digits of the IMSI) is prepended to the MAC block. Currently we are taking the fields apart manually using offsets. The code for this is difficult to read and the method is error prone. Let's define a struct that we can just overlay to access the fields directly. Let's also transfer the full IMSI. Change-Id: Id6acbd243adf26169e5e8319dd66bb68dd6a3c22 Related: OS#5198