== Running OsmoBSC The OsmoBSC executable (`osmo-bsc`) offers the following command-line arguments: === SYNOPSIS *osmo-bsc* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-T] [-e 'LOGLEVEL'] [-l 'IP'] [-r 'RFCTL'] === OPTIONS *-h, --help*:: Print a short help message about the supported options *-V, --version*:: Print the compile-time version number of the program *-d, --debug 'DBGMASK','DBGLEVELS'*:: Set the log subsystems and levels for logging to stderr. This has mostly been superseded by VTY-based logging configuration, see <> for further information. *-D, --daemonize*:: Fork the process as a daemon into background. *-c, --config-file 'CONFIGFILE'*:: Specify the file and path name of the configuration file to be used. If none is specified, use `osmo-bsc.cfg` in the current working directory. *-s, --disable-color*:: Disable colors for logging to stderr. This has mostly been deprecated by VTY based logging configuration, see <> for more information. *-T, --timestamp*:: Enable time-stamping of log messages to stderr. This has mostly been deprecated by VTY based logging configu- ration, see <> for more information. *-e, --log-level 'LOGLEVEL'*:: Set the global log level for logging to stderr. This has mostly been deprecated by VTY based logging configuration, see <> for more information. *-l, --local='IP'*:: Specify the local IP address of the OsmoBSC-MGCP *-r, --rf-ctl 'RFCTL'*:: Offer a Unix domain socket for RF control at the path/filename 'RFCTL' in the file system. === Multiple instances Running multiple instances of `osmo-bsc` on the same host is possible if all interfaces (VTY, CTRL) are separated using the appropriate configuration options. The IP based interfaces are binding to local host by default. In order to separate the processes, the user has to bind those services to specific but different IP addresses and/or ports. The VTY and the Control interface can be bound to IP addresses from the loopback address range, for example: ---- line vty bind 127.0.0.2 ctrl bind 127.0.0.2 ---- For the following links, OsmoBSC acts as a client and does not listen/bind to a specific interface, and will hence not encounter conflicts for multiple instances running on the same interface: - The SCCP/M3UA links are established by OsmoBSC contacting an STP. - The MGCP link is established by OsmoMSC contacting an MGW. To run multiple OsmoBSC instances on the same A-interface (SCCP/M3UA), each BSC has to configure a distinct point-code. See <>. === Configure primary links ==== Connect to an MSC's _A_ interface ===== Configure SCCP/M3UA (AoIP) OsmoBSC acts as client to contact an STP instance and establish an SCCP/M3UA link. An example configuration of OsmoBSC's AoIP SCCP link, assuming the BSC at point-code 1.23.3 and the MSC reachable at point-code 0.23.1 via an SG listening for M3UA at 127.0.0.1:2905: ---- cs7 instance 0 point-code 1.23.3 asp asp-clnt-msc-0 2905 0 m3ua remote-ip 127.0.0.1 sctp-role client sccp-address msc point-code 0.23.1 msc 0 msc-address msc ---- This configuration is explained in detail in <>. ===== Configure SCCPlite Traditionally, OsmoBSC implemented only an SCCPlite based A-interface, an ad-hoc standard encapsulating BSSAP in an IPA Multiplex. Since 2017, OsmoBSC supports primarily a proper 3GPP compliant SCCP/M3UA A-interface known as AoIP, by a new libosmo-sigtran implementation. In 2018, SCCPlite compatibility was added to libosmo-sigtran, re-enabling the option of using an SCCPlite based A-interface. For details, see the OsmoSTP manual, chapter "IPA / SCCPlite backwards compatibility". Here is an example configuration of OsmoBSC for SCCPlite, assuming the BSC at point-code 1.23.3 and an SCCPlite MSC listening on 127.0.0.1:5000 with own point-code 0.23.1: ---- cs7 instance 0 point-code 1.23.3 asp asp-clnt-msc-0 5000 0 ipa remote-ip 127.0.0.1 as as-clnt-msc-0 ipa asp asp-clnt-msc-0 routing-key 0 1.23.3 point-code override dpc 0.23.1 sccp-address remote_msc point-code 0.23.1 msc 0 msc-addr remote_msc ---- ==== Configure MGCP to connect to an MGW OsmoBSC uses a media gateway (typically OsmoMGW) to direct RTP streams. By default, an MGW is expected to receive MGCP requests on the IANA-registered default port for MGCP (2427) on local host (127.0.0.1). Here is an example configuration for a remote MGW: ---- msc 0 mgw remote-ip 10.9.8.7 mgw remote-port 2427 ----