cellular-infrastructure
/
osmo-bsc
mirror of https://gerrit.osmocom.org/osmo-bsc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-bsc/src/osmo-bsc/osmo_bsc_msc.c

495 lines
17 KiB
C
Raw Permalink Normal View History

bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
/*
* Handle the connection to the MSC. This include ping/timeout/reconnect
Remove 'struct bsc_msc_connection' + fix IPA-encapsulated CTRL The bsc_msc_connection dates back to the old pre-libosmo-sigtran days, and 90% of the field members weren't used at all (even the new sigtran specific ones!). Let's merge what remains into struct bsc_msc_data. As a side effect, the already dysfunctional "dest A.B.C.D" VTY command has been removed from the MSC node. There's quite a bit of fall-out in the CTRL interface, which was the code with strongest ties to bsc_msc_connection. This was resolved by properly porting CTRL handling over to libosmo-sigtran, meaning that an IPA/SCCPlite connected MSC can now again send CTRL GET/SET commands, and can also receive those selective few TRAPs that old osmo-bsc-sccplite also sent to its MSC[s]. Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f Related: OS#2012
2018-05-26 20:42:29 +00:00
* (C) 2008-2018 by Harald Welte <laforge@gnumonks.org>
bsc: Allow to use different LAC/CI for the core-network We need to use different LAC/CI towards the core network. It is a bit problematic as LAC/CI is a per BTS attribute so this feature only works if a BSC manages everything in the same LAC. Related: SYS#1398
2015-04-01 16:15:48 +00:00
* (C) 2009-2015 by Holger Hans Peter Freyther <zecke@selfish.org>
* (C) 2009-2015 by On-Waves
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* GNU Affero General Public License for more details.
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
*
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
*
*/
move libctrl from openbsc to libosmoctrl (libosmocore.git)
2014-08-20 21:47:15 +00:00
#include <osmocom/ctrl/control_cmd.h>
#include <osmocom/ctrl/control_if.h>
bsc: Check for the rand and then generate a res Check if the NAT has sent 16 bytes of RAND and if a key has been configured in the system and then generate a result using milenage. The milenage res will be sent and noth the four byte GSM SRES derivation.
2015-06-08 16:02:10 +00:00
#include <osmocom/crypt/auth.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/debug.h>
#include <osmocom/bsc/gsm_data.h>
#include <osmocom/bsc/ipaccess.h>
#include <osmocom/bsc/bsc_msc_data.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/bsc/osmo_bsc_sigtran.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/signal.h>
Move struct gsm_bts: gsm_data.* => bts.* Place all code related to the object into the related file. Having all the data model in one file made sense in early stage of development to make progress quickly, but nowadays it hurts more than helps, due to constantly growing size and more and more bits being added to the model, gaining in complexity. Currently, having lots of different objects mixed up in gsm_data.h is a hole of despair, where nobody can make any sense were to properly put new stuff in, ending up with functions related to same object in different files or with wrong prefixes, declarations of non-existing functions, etc. because people cannot make up their mind on strict relation to objects in the data model. Splitting them in files really helps finding code operating on a specific object and helping with logically splitting in the future. Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
2020-07-15 18:53:16 +00:00
#include <osmocom/bsc/bts.h>
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
osmo_bsc: Use libctrl, handle ctrl cmds on port 4249 or from the nat This patch initializes libctrl to listen for connections on port 4249. Additionally, control messages arriving from the nat will also be processed.
2011-02-18 13:30:25 +00:00
#include <osmocom/core/talloc.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/core/socket.h>
osmo_bsc: Use libctrl, handle ctrl cmds on port 4249 or from the nat This patch initializes libctrl to listen for connections on port 4249. Additionally, control messages arriving from the nat will also be processed.
2011-02-18 13:30:25 +00:00
Fix build of bsc-nat and GPRS code after include path change The last patch changed the osmocore include paths, this fixes some build problems caused by it
2011-03-23 17:26:56 +00:00
#include <osmocom/gsm/gsm0808.h>
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
#include <osmocom/gsm/gsm23236.h>
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
src: port openBSC over libosmo-abis This is a big patch that ports openBSC over libosmo-abis. Sorry, the changes that are included here are all dependent of libosmo-abis, splitting them into smaller pieces would leave the repository in some intermediate state, which is not desired. The main changes are: - The directory libabis/ has been removed as it now lives in libosmo-abis. - new configuration file format for nanoBTS and HSL femto, we need to define the virtual e1_line and attach it to the OML link. - all the existing BTS drivers (nanoBTS, hsl femto, Nokia site, BS11 and rbs2000) now use the new libosmo-abis framework. - use r232 input driver available in libosmo-abis for bs11_config. - use ipa_msg_recv instead of old ipaccess_read_msg function. - delete definition of gsm_e1_subslot and input_signal_data. These structures now lives in libosmo-abis. Most of this patch are deletions of libabis/ which has been moved to libosmo-abis. This patch also modifies openBSC to use all the new definitions available in libosmocore and libosmo-abis. In order to do that, we have replaced the following: - DINP, DMI, DMIB and DMUX by their respective DL* correspondences. - SS_GLOBAL by SS_L_GLOBAL - SS_INPUT by SS_L_INPUT - S_GLOBAL_SHUTDOWN by S_L_GLOBAL_SHUTDOWN - SS_INPUT by SS_L_INPUT - S_INP_* by S_L_INP_* sub-signals - E1INP_NODE by L_E1INP_NODE vty node This patch has been tested with: - one nanoBTS - the HSL femto with the examples available under libosmo-abis - BS11 with both dahdi and misdn drivers.
2011-08-17 20:44:07 +00:00
#include <osmocom/abis/ipa.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/mgcp_client/mgcp_client.h>
sccplite: Use mgwpool config to set up socket forwarding IPA-MGCP from MSC to MGW 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
2022-10-26 09:18:23 +00:00
#include <osmocom/mgcp_client/mgcp_client_pool.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <unistd.h>
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
static const struct rate_ctr_desc msc_ctr_description[] = {
stats: Rename BSSMAP Rx message counters to match Tx ones. Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
2020-05-09 22:49:34 +00:00
/* Rx message counters (per specific message) */
Cleanup code style of rate counters in osmo_bsc_msc.c Change-Id: I7cfd4f20ebfee0c8df9305372977d6628d6337c5
2023-07-06 13:55:15 +00:00
[MSC_CTR_BSSMAP_RX_UDT_RESET_ACKNOWLEDGE] = {
"bssmap:rx:udt:reset:ack",
"Number of received BSSMAP UDT RESET ACKNOWLEDGE messages"
},
[MSC_CTR_BSSMAP_RX_UDT_RESET] = {
"bssmap:rx:udt:reset:request",
"Number of received BSSMAP UDT RESET messages"
},
[MSC_CTR_BSSMAP_RX_UDT_PAGING] = {
"bssmap:rx:udt:paging",
"Number of received BSSMAP UDT PAGING messages"
},
[MSC_CTR_BSSMAP_RX_UDT_UNKNOWN] = {
"bssmap:rx:udt:err_unknown",
"Number of received BSSMAP unknown UDT messages"
},
[MSC_CTR_BSSMAP_RX_DT1_CLEAR_CMD] = {
"bssmap:rx:dt1:clear:cmd",
"Number of received BSSMAP DT1 CLEAR CMD messages"
},
[MSC_CTR_BSSMAP_RX_DT1_CIPHER_MODE_CMD] = {
"bssmap:rx:dt1:cipher_mode:cmd",
"Number of received BSSMAP DT1 CIPHER MODE CMD messages"
},
[MSC_CTR_BSSMAP_RX_DT1_ASSIGNMENT_RQST] = {
"bssmap:rx:dt1:assignment:rqst",
"Number of received BSSMAP DT1 ASSIGNMENT RQST messages"
},
[MSC_CTR_BSSMAP_RX_DT1_LCLS_CONNECT_CTRL] = {
"bssmap:rx:dt1:lcls_connect_ctrl:cmd",
"Number of received BSSMAP DT1 LCLS CONNECT CTRL messages"
},
[MSC_CTR_BSSMAP_RX_DT1_HANDOVER_RQST] = {
"bssmap:rx:dt1:handover:rqst",
"Number of received BSSMAP DT1 HANDOVER RQST messages"
},
[MSC_CTR_BSSMAP_RX_DT1_HANDOVER_CMD] = {
"bssmap:rx:dt1:handover:cmd",
"Number of received BSSMAP DT1 HANDOVER CMD messages"
},
[MSC_CTR_BSSMAP_RX_DT1_CLASSMARK_RQST] = {
"bssmap:rx:dt1:classmark:rqst",
"Number of received BSSMAP DT1 CLASSMARK RQST messages"
},
[MSC_CTR_BSSMAP_RX_DT1_CONFUSION] = {
"bssmap:rx:dt1:confusion",
"Number of received BSSMAP DT1 CONFUSION messages"
},
[MSC_CTR_BSSMAP_RX_DT1_COMMON_ID] = {
"bssmap:rx:dt1:common_id",
"Number of received BSSMAP DT1 COMMON ID messages"
},
[MSC_CTR_BSSMAP_RX_DT1_UNKNOWN] = {
"bssmap:rx:dt1:err_unknown",
"Number of received BSSMAP unknown DT1 messages"
},
[MSC_CTR_BSSMAP_RX_DT1_DTAP] = {
"bssmap:rx:dt1:dtap:good",
"Number of received BSSMAP DTAP messages"
},
[MSC_CTR_BSSMAP_RX_DT1_DTAP_ERROR] = {
"bssmap:rx:dt1:dtap:error",
"Number of received BSSMAP DTAP messages with errors"
},
[MSC_CTR_BSSMAP_RX_DT1_PERFORM_LOCATION_REQUEST] = {
"bssmap:rx:dt1:location:request",
"Number of received BSSMAP Perform Location Request messages"
},
[MSC_CTR_BSSMAP_RX_DT1_PERFORM_LOCATION_ABORT] = {
"bssmap:tx:dt1:location:abort",
"Number of received BSSMAP Perform Location Abort messages"
},
ASCI: Add new rate counters to support VGCS/VBS messages Change-Id: I18e4ca3599e480de2d0f64cc1b6f4bb6ce8020d4 Related: OS#4852
2023-05-04 13:09:32 +00:00
[MSC_CTR_BSSMAP_RX_DT1_VGCS_VBS_SETUP] = {
"bssmap:rx:dt1:vgcs_vbs_setup",
"Number of received BSSMAP DT1 VGCS/VBS SETUP messages"
},
[MSC_CTR_BSSMAP_RX_DT1_VGCS_VBS_ASSIGN_RQST] = {
"bssmap:rx:dt1:vgcs_vbs_assignment:req",
"Number of received BSSMAP DT1 VGCS/VBS ASSIGNMENT messages"
},
[MSC_CTR_BSSMAP_RX_DT1_UPLINK_RQST_ACKNOWLEDGE] = {
"bssmap:rx:dt1:uplink_rqst:ack",
"Number of received BSSMAP DT1 UPLINK REQUEST ACKNOWLEDGE messages"
},
[MSC_CTR_BSSMAP_RX_DT1_UPLINK_REJECT_CMD] = {
"bssmap:rx:dt1:uplink_reject:cmd",
"Number of received BSSMAP DT1 UPLINK REJECT COMMAND messages"
},
[MSC_CTR_BSSMAP_RX_DT1_UPLINK_RELEASE_CMD] = {
"bssmap:rx:dt1:uplink_release:cmd",
"Number of received BSSMAP DT1 UPLINK RELEASE COMMAND messages"
},
[MSC_CTR_BSSMAP_RX_DT1_UPLINK_SEIZED_CMD] = {
"bssmap:rx:dt1:uplink_seized:cmd",
"Number of received BSSMAP DT1 UPLINK SEIZED COMMAND messages"
},
[MSC_CTR_BSSMAP_RX_DT1_VGCS_ADDL_INFO] = {
"bssmap:rx:dt1:vgcs_addl_info",
"Number of received BSSMAP DT1 VGCS/VBS ASSITIONAL INFORMATION messages"
},
[MSC_CTR_BSSMAP_RX_DT1_VGCS_SMS] = {
"bssmap:rx:dt1:vgcs_sms",
"Number of received BSSMAP DT1 VGCS SMS messages"
},
[MSC_CTR_BSSMAP_RX_DT1_NOTIFICATION_DATA] = {
"bssmap:rx:dt1:notification_data",
"Number of received BSSMAP DT1 NOTIFICATION DATA messages"
},
stats: Add counters for Tx BSSMAP messages. We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-09 18:27:40 +00:00
/* Tx message counters (per message type)
*
* The counters here follow the logic of the osmo_bsc_sigtran_send() function
* which receives DT1 messages from the upper layers and actually sends them to the MSC.
* These counters cover all messages passed to the function by the upper layers: */
Cleanup code style of rate counters in osmo_bsc_msc.c Change-Id: I7cfd4f20ebfee0c8df9305372977d6628d6337c5
2023-07-06 13:55:15 +00:00
[MSC_CTR_BSSMAP_TX_BSS_MANAGEMENT] = {
"bssmap:tx:type:bss_management",
"Number of transmitted BSS MANAGEMENT messages"
},
[MSC_CTR_BSSMAP_TX_DTAP] = {
"bssmap:tx:type:dtap",
"Number of transmitted DTAP messages"
},
[MSC_CTR_BSSMAP_TX_UNKNOWN] = {
"bssmap:tx:type:err_unknown",
"Number of transmitted messages with unknown type (an error in our code?)"
},
[MSC_CTR_BSSMAP_TX_SHORT] = {
"bssmap:tx:type:err_short",
"Number of transmitted messages which are too short (an error in our code?)"
},
stats: Add counters for Tx BSSMAP messages. We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-09 18:27:40 +00:00
/* The next counters are also counted in the osmo_bsc_sigtran_send() function and
* sum up to the exactly same number as the counters above but instead of message
* classes they split by the result of the sending attempt: */
Cleanup code style of rate counters in osmo_bsc_msc.c Change-Id: I7cfd4f20ebfee0c8df9305372977d6628d6337c5
2023-07-06 13:55:15 +00:00
[MSC_CTR_BSSMAP_TX_ERR_CONN_NOT_READY] = {
"bssmap:tx:result:err_conn_not_ready",
"Number of BSSMAP messages we tried to send when the connection was not ready yet"
},
[MSC_CTR_BSSMAP_TX_ERR_SEND] = {
"bssmap:tx:result:err_send",
"Number of socket errors while sending BSSMAP messages"
},
[MSC_CTR_BSSMAP_TX_SUCCESS] = {
"bssmap:tx:result:success",
"Number of successfully sent BSSMAP messages"
},
stats: Add counters for Tx BSSMAP messages. We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-09 18:27:40 +00:00
/* Tx message counters (per specific message)
*
* Theoretically, the DT1 counters should sum up to the same number as the Tx counters
* above but since these counters are coming from the upper layers, there might be
* some difference if we forget some code path. */
Cleanup code style of rate counters in osmo_bsc_msc.c Change-Id: I7cfd4f20ebfee0c8df9305372977d6628d6337c5
2023-07-06 13:55:15 +00:00
[MSC_CTR_BSSMAP_TX_UDT_RESET] = {
"bssmap:tx:udt:reset:request",
"Number of transmitted BSSMAP UDT RESET messages"
},
[MSC_CTR_BSSMAP_TX_UDT_RESET_ACK] = {
"bssmap:tx:udt:reset:ack",
"Number of transmitted BSSMAP UDT RESET ACK messages"
},
[MSC_CTR_BSSMAP_TX_DT1_CLEAR_RQST] = {
"bssmap:tx:dt1:clear:rqst",
"Number of transmitted BSSMAP DT1 CLEAR RQSTtx messages"
},
[MSC_CTR_BSSMAP_TX_DT1_CLEAR_COMPLETE] = {
"bssmap:tx:dt1:clear:complete",
"Number of transmitted BSSMAP DT1 CLEAR COMPLETE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_ASSIGNMENT_FAILURE] = {
"bssmap:tx:dt1:assignment:failure",
"Number of transmitted BSSMAP DT1 ASSIGNMENT FAILURE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_ASSIGNMENT_COMPLETE] = {
"bssmap:tx:dt1:assignment:complete",
"Number of transmitted BSSMAP DT1 ASSIGNMENT COMPLETE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_SAPI_N_REJECT] = {
"bssmap:tx:dt1:sapi_n:reject",
"Number of transmitted BSSMAP DT1 SAPI N REJECT messages"
},
[MSC_CTR_BSSMAP_TX_DT1_CIPHER_COMPLETE] = {
"bssmap:tx:dt1:cipher_mode:complete",
"Number of transmitted BSSMAP DT1 CIPHER COMPLETE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_CIPHER_REJECT] = {
"bssmap:tx:dt1:cipher_mode:reject",
"Number of transmitted BSSMAP DT1 CIPHER REJECT messages"
},
[MSC_CTR_BSSMAP_TX_DT1_CLASSMARK_UPDATE] = {
"bssmap:tx:dt1:classmark:update",
"Number of transmitted BSSMAP DT1 CLASSMARK UPDATE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_LCLS_CONNECT_CTRL_ACK] = {
"bssmap:tx:dt1:lcls_connect_ctrl:ack",
"Number of transmitted BSSMAP DT1 LCLS CONNECT CTRL ACK messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_REQUIRED] = {
"bssmap:tx:dt1:handover:required",
"Number of transmitted BSSMAP DT1 HANDOVER REQUIRED messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_PERFORMED] = {
"bssmap:tx:dt1:handover:performed",
"Number of transmitted BSSMAP DT1 HANDOVER PERFORMED messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_RQST_ACKNOWLEDGE] = {
"bssmap:tx:dt1:handover:rqst_acknowledge",
"Number of transmitted BSSMAP DT1 HANDOVER RQST ACKNOWLEDGE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_DETECT] = {
"bssmap:tx:dt1:handover:detect",
"Number of transmitted BSSMAP DT1 HANDOVER DETECT messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_COMPLETE] = {
"bssmap:tx:dt1:handover:complete",
"Number of transmitted BSSMAP DT1 HANDOVER COMPLETE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_FAILURE] = {
"bssmap:tx:dt1:handover:failure",
"Number of transmitted BSSMAP DT1 HANDOVER FAILURE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_DTAP] = {
"bssmap:tx:dt1:dtap",
"Number of transmitted BSSMAP DT1 DTAP messages"
},
[MSC_CTR_BSSMAP_TX_DT1_PERFORM_LOCATION_RESPONSE_SUCCESS] = {
"bssmap:tx:dt1:location:response_success",
"Number of transmitted BSSMAP Perform Location Response messages containing a location estimate"
},
[MSC_CTR_BSSMAP_TX_DT1_PERFORM_LOCATION_RESPONSE_FAILURE] = {
"bssmap:tx:dt1:location:response_failure",
"Number of transmitted BSSMAP Perform Location Response messages containing a failure cause"
},
ASCI: Add new rate counters to support VGCS/VBS messages Change-Id: I18e4ca3599e480de2d0f64cc1b6f4bb6ce8020d4 Related: OS#4852
2023-05-04 13:09:32 +00:00
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_SETUP_ACK] = {
"bssmap:tx:dt1:vgcs_vbs_setup:ack",
"Number of transmitted BSSMAP DT1 VGCS/VBS SETUP ACK messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_SETUP_REFUSE] = {
"bssmap:tx:dt1:vgcs_vbs_setup:refuse",
"Number of transmitted BSSMAP DT1 VGCS/VBS SETUP REFUSE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_ASSIGN_RESULT] = {
"bssmap:tx:dt1:vgcs_vbs_assignment:res",
"Number of transmitted BSSMAP DT1 VGCS/VBS ASSIGNMENT RESULT messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_ASSIGN_FAIL] = {
"bssmap:tx:dt1:vgcs_vbs_assignment:fail",
"Number of transmitted BSSMAP DT1 VGCS/VBS ASSIGNMENT FAILURE messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_QUEUING_INDICATION] = {
"bssmap:tx:dt1:vgcs_vbs_queuing:ind",
"Number of transmitted BSSMAP DT1 VGCS/VBS QUEUING INDICATION messages"
},
[MSC_CTR_BSSMAP_TX_DT1_UPLINK_RQST] = {
"bssmap:tx:dt1:uplink_rqst",
"Number of transmitted BSSMAP DT1 UPLINK REQUEST messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_ASSIGNMENT_STATUS] = {
"bssmap:tx:dt1:vgcs_vbs_assignment:status",
"Number of transmitted BSSMAP DT1 VGCS/VBS ASSIGNMENT STATUS messages"
},
[MSC_CTR_BSSMAP_TX_DT1_VGCS_VBS_AREA_CELL_INFO] = {
"bssmap:tx:dt1:vgcs_vbs_area_cell:info",
"Number of transmitted BSSMAP DT1 VGCS/VBS AREA CELL INFO messages"
},
[MSC_CTR_BSSMAP_TX_DT1_UPLINK_RQST_CONFIRMATION] = {
"bssmap:tx:dt1:uplink_rqst:cnf",
"Number of transmitted BSSMAP DT1 UPLINK REQUEST CONFIRMATION messages"
},
[MSC_CTR_BSSMAP_TX_DT1_UPLINK_RELEASE_INDICATION] = {
"bssmap:tx:dt1:uplink_release:ind",
"Number of transmitted BSSMAP DT1 UPLINK RELEASE INDICATION messages"
},
[MSC_CTR_BSSMAP_TX_DT1_UPLINK_APP_DATA] = {
"bssmap:tx:dt1:uplink_app_data",
"Number of transmitted BSSMAP DT1 UPLINK APPLICATION DATA messages"
},
MSC pooling: add rate counters Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f (osmo-ttcn3-hacks). Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
2020-06-16 10:08:39 +00:00
/* Indicators for MSC pool usage */
[MSC_CTR_MSCPOOL_SUBSCR_NEW] = {
"mscpool:subscr:new",
"Complete Layer 3 requests assigned to this MSC by round-robin (no NRI was assigned yet).",
},
[MSC_CTR_MSCPOOL_SUBSCR_REATTACH] = {
"mscpool:subscr:reattach",
"Complete Layer 3 requests assigned to this MSC by round-robin because the subscriber indicates a"
" NULL-NRI (previously assigned by another MSC).",
},
[MSC_CTR_MSCPOOL_SUBSCR_KNOWN] = {
"mscpool:subscr:known",
"Complete Layer 3 requests directed to this MSC because the subscriber indicates an NRI of this MSC.",
},
[MSC_CTR_MSCPOOL_SUBSCR_PAGED] = {
"mscpool:subscr:paged",
"Paging Response directed to this MSC because the subscriber was recently paged by this MSC.",
},
[MSC_CTR_MSCPOOL_SUBSCR_ATTACH_LOST] = {
"mscpool:subscr:attach_lost",
"A subscriber indicates an NRI value matching this MSC, but the MSC is not connected:"
" a re-attach to another MSC (if available) was forced, with possible service failure.",
},
[MSC_CTR_MSCPOOL_EMERG_FORWARDED] = {
"mscpool:emerg:forwarded",
"Emergency call requests forwarded to this MSC.",
},
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
};
static const struct rate_ctr_group_desc msc_ctrg_desc = {
"msc",
"mobile switching center",
OSMO_STATS_CLASS_GLOBAL,
ARRAY_SIZE(msc_ctr_description),
msc_ctr_description,
};
static const struct osmo_stat_item_desc msc_stat_desc[] = {
stat_item desc: add explicit indexes for clarity Add explicit indexes like [BSC_STAT_NUM_BTS_TOTAL] = { ... BSC_STAT_NUM_BTS_TOTAL == 0 and the first item of bsc_stat_desc of course has index 0, but when grepping the code, it looks like BSC_STAT_NUM_BTS_TOTAL is missing a name definition. Same for MSC_STAT_MSC_LINKS_ACTIVE and MSC_STAT_MSC_LINKS_TOTAL. Related: SYS#5542 Change-Id: Ie47e0857c41d517a9b37be96f6669d1825d24a6d
2021-08-19 17:25:47 +00:00
[MSC_STAT_MSC_LINKS_ACTIVE] = { "msc_links:active", "Number of active MSC links", "", 16, 0 },
[MSC_STAT_MSC_LINKS_TOTAL] = { "msc_links:total", "Number of configured MSC links", "", 16, 0 },
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
};
static const struct osmo_stat_item_group_desc msc_statg_desc = {
.group_name_prefix = "msc",
.group_description = "mobile switching center",
.class_id = OSMO_STATS_CLASS_GLOBAL,
.num_items = ARRAY_SIZE(msc_stat_desc),
.item_desc = msc_stat_desc,
};
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
int osmo_bsc_msc_init(struct bsc_msc_data *msc)
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
{
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
int rc;
osmo_bsc_msc: do not initalize MGCP proxy for AoIP MSCs The MGCP proxy which is built into osmo-bsc is used to tunnel MGCP messages through an SCCP-lite link. This is an SCCP-lite specific implementation detail that is not present in SCCP/AoIP. Change-Id: Id3a8c45ae38d6b9d9c106a9e83b3cbfff919650d Related: SYS#5091
2021-09-03 09:16:16 +00:00
/* Everything below refers to SCCP-Lite MSC connections only. */
if (msc_is_aoip(msc))
return 0;
Fix creating MGCP proxy socket if MGW listens on an IPv6 address If for instance "mgw remote-ip ::1" is configured, the MGCP IPA proxy socket towards the MGW will use ::1 as the destination address, but it was being created as AF_INET. Let's use AF_UNSPEC instead and let osmo_sock_init2 decide the best socket type to create. Moreover, change the default local address from "0.0.0.0" to NULL to also let osmo_sock_init2 pick an IPv6 address if necessary. Change-Id: Ide88c7358a38702ef11c84145518794e75870ef8
2020-08-31 18:09:26 +00:00
rc = osmo_sock_init2_ofd(&msc->mgcp_ipa.ofd, AF_UNSPEC, SOCK_DGRAM, IPPROTO_UDP,
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
msc->mgcp_ipa.local_addr, msc->mgcp_ipa.local_port,
sccplite: Support multiple MGW in MGW pool 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-22 16:20:12 +00:00
NULL, 0, OSMO_SOCK_F_BIND);
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
if (rc < 0) {
LOGP(DMSC, LOGL_ERROR, "msc %u: Could not create/connect/bind MGCP proxy socket: %d\n",
msc->nr, rc);
return rc;
}
sccplite: Use mgwpool config to set up socket forwarding IPA-MGCP from MSC to MGW 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
2022-10-26 09:18:23 +00:00
LOGP(DMSC, LOGL_INFO, "msc %u: Socket forwarding IPA-encapsulated MGCP messages towards MGW: %s\n",
msc->nr, osmo_sock_get_name2(msc->mgcp_ipa.ofd.fd));
Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring) This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-04-09 10:32:51 +00:00
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
return 0;
}
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *osmo_msc_data_find(struct gsm_network *net, int nr)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
{
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *msc_data;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
flatten: move network->bsc_data->* to network->* The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-26 10:41:18 +00:00
llist_for_each_entry(msc_data, &net->mscs, entry)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
if (msc_data->nr == nr)
return msc_data;
return NULL;
}
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *osmo_msc_data_alloc(struct gsm_network *net, int nr)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
{
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *msc_data;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
/* check if there is already one */
msc_data = osmo_msc_data_find(net, nr);
if (msc_data)
return msc_data;
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
msc_data = talloc_zero(net, struct bsc_msc_data);
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
if (!msc_data)
return NULL;
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
/* init statistics */
msc_data->msc_ctrs = rate_ctr_group_alloc(net, &msc_ctrg_desc, nr);
if (!msc_data->msc_ctrs) {
talloc_free(msc_data);
return NULL;
}
msc_data->msc_statg = osmo_stat_item_group_alloc(net, &msc_statg_desc, nr);
if (!msc_data->msc_statg) {
rate_ctr_group_free(msc_data->msc_ctrs);
talloc_free(msc_data);
return NULL;
}
flatten: move network->bsc_data->* to network->* The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-26 10:41:18 +00:00
llist_add_tail(&msc_data->entry, &net->mscs);
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
/* Init back pointer */
msc_data->network = net;
implement support for 3-digit MNC with leading zeros Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout the code base to be able to handle an MNC < 100 that has three digits (leading zeros). The changes to abis_test and gsm0408_test show that this code now handles 3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded PLMN. Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the presence of the third digit of the MNC. Always reply with all leading zeros. Adjust the expected results in ctrl_test_runner.py, to show that it works. In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters and detect errno returned by strtol() (in contrast to atoi()). Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore), Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore), I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore) Change-Id: I8e722103344186fde118b26d8353db95a4581daa
2018-03-05 01:09:40 +00:00
msc_data->core_plmn = (struct osmo_plmn_id){
.mcc = GSM_MCC_MNC_INVALID,
.mnc = GSM_MCC_MNC_INVALID,
};
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
msc_data->nr = nr;
bsc: Look for CM Service Requests with emergency cause Look for emergency calls and send them to a MSC that can handle them properly.
2011-06-08 17:25:38 +00:00
msc_data->allow_emerg = 1;
vty: Permit selection of other ASP protocol than M3UA We used to have hard-coded M3UA. Let's allow the user to configure this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command. For SUA this should just work 1:1 without any trouble. For IPA, this of course only changes the underlying transport without reflecting the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling, etc. Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13 Related: OS#2544
2018-05-25 13:51:05 +00:00
msc_data->a.asp_proto = OSMO_SS7_ASP_PROT_M3UA;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
audio: Make the BSC handle the new mr_config request of the BSC API Handle the mr_config request and set the AMR multirate config for the given MSC. Initialize the mr_config with the AMR5.9 default we have been using until now.
2011-08-06 05:00:52 +00:00
/* Defaults for the audio setup */
msc_data->amr_conf.m5_90 = 1;
Make sure to default to AMR octet-aligned mode In Change-Id If6d40b2407b87aad2227ea7f15533ef01a3771b3 we introduced the support for both octet-aligned and bandwidth-efficient mode, and added a related VTY option about it. However, we accidentially also changed the default behavior. Without any explicit configuration, we should behave just like we behaved all those years before: Continue with octet-aligned mode. Change-Id: I8b6fd8bec05b35d84ad16275d84f9d363e238d2b Closes: OS#4002
2019-05-15 12:57:32 +00:00
msc_data->amr_octet_aligned = true;
audio: Make the BSC handle the new mr_config request of the BSC API Handle the mr_config request and set the AMR multirate config for the given MSC. Initialize the mr_config with the AMR5.9 default we have been using until now.
2011-08-06 05:00:52 +00:00
osmo_bsc_msc: Set reasonable codec list defaults When the user sets no codec-list in the msc node, the configuration will end up with an empty codec list. This is a useless configuration. There should be a sane default setting. - Set all possible codecs as default for codec-list Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed Related: OS#3625
2018-10-05 08:29:53 +00:00
/* Allow the full set of possible codecs by default */
msc_data->audio_length = 5;
simplify storage of bsc_msc_data->audio_support Make it a plain array, no dynamic allocation needed. Change-Id: I625cedc4bb040d649fd6e1794ba468f4c6ad6adc
2023-02-28 23:43:06 +00:00
msc_data->audio_support[0].ver = 1;
msc_data->audio_support[0].hr = 0;
msc_data->audio_support[1].ver = 1;
msc_data->audio_support[1].hr = 1;
msc_data->audio_support[2].ver = 2;
msc_data->audio_support[2].hr = 0;
msc_data->audio_support[3].ver = 3;
msc_data->audio_support[3].hr = 0;
msc_data->audio_support[4].ver = 3;
msc_data->audio_support[4].hr = 1;
osmo_bsc_msc: Set reasonable codec list defaults When the user sets no codec-list in the msc node, the configuration will end up with an empty codec list. This is a useless configuration. There should be a sane default setting. - Set all possible codecs as default for codec-list Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed Related: OS#3625
2018-10-05 08:29:53 +00:00
Use OSMO_FD_* instead of deprecated BSC_FD_* New define is available since libosmocore 1.1.0, and we already require 1.3.0, so no need to update dependenices. Let's change it to avoid people re-using old BSC_FD_* symbols when copy-pasting somewhere else. Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
2020-05-09 17:17:12 +00:00
osmo_fd_setup(&msc_data->mgcp_ipa.ofd, -1, OSMO_FD_READ, &bsc_sccplite_mgcp_proxy_cb, msc_data, 0);
Fix creating MGCP proxy socket if MGW listens on an IPv6 address If for instance "mgw remote-ip ::1" is configured, the MGCP IPA proxy socket towards the MGW will use ::1 as the destination address, but it was being created as AF_INET. Let's use AF_UNSPEC instead and let osmo_sock_init2 decide the best socket type to create. Moreover, change the default local address from "0.0.0.0" to NULL to also let osmo_sock_init2 pick an IPv6 address if necessary. Change-Id: Ide88c7358a38702ef11c84145518794e75870ef8
2020-08-31 18:09:26 +00:00
msc_data->mgcp_ipa.local_addr = NULL; /* = INADDR(6)_ANY */
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
msc_data->mgcp_ipa.local_port = 0; /* dynamic */
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
msc_data->nri_ranges = osmo_nri_ranges_alloc(msc_data);
MSC pooling: add 'no allow-attach' for MSC off-loading As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid attaching new subscribers to it: 4.5a.1: "UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool." Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
2020-06-11 00:36:29 +00:00
msc_data->allow_attach = true;
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
return msc_data;
}
Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring) This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-04-09 10:32:51 +00:00
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
struct osmo_cell_global_id *cgi_for_msc(struct bsc_msc_data *msc, struct gsm_bts *bts)
{
static struct osmo_cell_global_id cgi;
fix crashes due to OSMO_ASSERT(conn->lchan) Starting from ttcn3-bsc-test-sccplite build #777, it was noticed that osmo-bsc crashes with the following message: Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376 The cause of this is a recently merged patch that calls conn_get_bts() during assignment_fsm rate counter dispatch: "Count assignment rates per BTS as well" commit b5ccf09fc4042c7fb1fdaaa6263961c40b32564e Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a The root cause being that the assignment_fsm attempts to count an Assignment event for a BTS after the lchan has already been released and disassociated from the conn. The assertion is found in conn_get_bts(), which is used in various places. In fact, each caller is a potential DoS risk -- though most are in code paths that are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the relatively volatile presence of an lchan is not a good idea for osmo-bsc's stability and error resilience. - Change conn_get_bts() to return NULL in the lack of an lchan. - Adjust all callers of conn_get_bts() to gracefully handle a NULL return val. - Same for cgi_for_msc() and callers, closely related. Here is a backtrace: Program received signal SIGABRT pwndbg> bt 0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376 0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758 0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325 0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257 0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260 0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291 0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953 0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6 0x0000555555b61bbe in _start () In the case of the assignment_fsm counter, we now miss a chance to increase a BTS counter for a failed Assignment, but this is a separate problem. The main point of this patch is that osmo-bsc must not crash. Related: OS#4620, OS#4619 Patch-by: fixeria Tweaked-by: neels Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
2020-06-18 15:29:56 +00:00
if (!bts)
return NULL;
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
cgi.lai.plmn = msc->network->plmn;
if (msc->core_plmn.mcc != GSM_MCC_MNC_INVALID)
cgi.lai.plmn.mcc = msc->core_plmn.mcc;
if (msc->core_plmn.mnc != GSM_MCC_MNC_INVALID) {
cgi.lai.plmn.mnc = msc->core_plmn.mnc;
cgi.lai.plmn.mnc_3_digits = msc->core_plmn.mnc_3_digits;
}
drop features 'core-location-area-code' and 'core-cell-identity' This feature apparently assigned a fixed LAC and CI to a specific MSC, but looking at the implementation was obviously not useful. Keep the vty commands for legacy compat, now without effect besides logging an error via vty_out(). Related: OS#4751 Change-Id: I6bee704e7e5d5b6b86473323bae1fa9fce9241ee
2020-10-15 17:17:10 +00:00
cgi.lai.lac = bts->location_area_code;
cgi.cell_identity = bts->cell_identity;
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
return &cgi;
}