aboutsummaryrefslogtreecommitdiffstats
path: root/doc/manuals/chapters/running.adoc
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manuals/chapters/running.adoc')
-rw-r--r--doc/manuals/chapters/running.adoc88
1 files changed, 83 insertions, 5 deletions
diff --git a/doc/manuals/chapters/running.adoc b/doc/manuals/chapters/running.adoc
index ae45afcee..70f9d283f 100644
--- a/doc/manuals/chapters/running.adoc
+++ b/doc/manuals/chapters/running.adoc
@@ -35,8 +35,6 @@ arguments:
Set the global log level for logging to stderr. This has mostly
been deprecated by VTY based logging configuration, see
<<logging>> 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.
@@ -136,7 +134,87 @@ 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
+network
+ mgw 0
+ remote-ip 10.9.8.7
+ remote-port 2427
+ reset-endpoint rtpbridge/* <1>
+----
+<1> The 'reset-endpoint' setting instructs the OsmoBSC to send a wildcarded
+DLCX to the media gateway. This helps to clear lingering calls from the
+media gateway when the OsmoBSC is restarted.
+
+OsmoBSC is also able to handle a pool of media gateways for load
+distribution since mid 2021. See also <<mgw_pooling>>.
+
+[NOTE]
+====
+Previous versions of OsmoBSC didn't have the 'mgw' VTY node and
+hence didn't support the MGW pooling feature. Therefore, historically the MGW
+related commands where placed under the `msc` VTY node. The MGW related commands
+under the `msc` VTY are still parsed and used but its use is deprecated and
+hence discouraged in favour of the new `mgw` node. Writing the config to a file
+from within OsmoBSC will automatically convert the config to use the new `mgw`
+node.
+====
+
+===== Pinning a BTS to a specific MGW
+
+It is sometimes desirable to assign a specific MGW to a given BTS, so that all
+calls where the BTS is involved use the assigned MGW with a higher precedence if
+possible.
+
+This is specially important if the BTS is configured to serve calls using Osmux
+instead of RTP. Osmux features trunking optimizations, which allow transmission
+of audio payload from different concurrent calls inside the same underlaying UDP
+packet, hence reducing the total required throughput and saving costs on the
+required link.
+
+In order for Osmux trunking optimization to work, the source and destination IP
+address of uderlaying UDP packet must be of course the same for all the calls
+involved. That essentially boils down to having all the concurrent calls of the
+BTS be connected to the same MGW so that they can be trunked over the same UDP
+connection.
+
+The pinning to a specific MGW can be configured per BTS, and hence it is
+configured under the `bts` VTY node:
+
+----
+OsmoBSC> enable
+OsmoBSC# configure terminal
+OsmoBSC(config)# network
+OsmoBSC(config-net)# bts 1
+OsmoBSC(config-bts)# mgw pool-target 1 <1>
+OsmoBSC(config-bts)# exit
+OsmoBSC(config-net)# bts 2
+OsmoBSC(config-mgw)# mgw pool-target 7 strict <2>
+OsmoBSC(config-net)# bts 3
+OsmoBSC(config-mgw)# no mgw pool-target <3>
----
+
+<1> Pin BTS1 to prefer MGW1 (node `mgw 1`). If MGW1 is not configured,
+administrateivly blocked or not connected at the time a new call is to be
+established, then another MGW from the pool is selected following the usual
+procedures. This allows applying pinning in the usual scenario while still
+keeping call service ongoing against another MGW if the preferred MGW is not
+available at a given time.
+
+<2> Pin BTS2 to prefer MGW7 (node `mgw 7`). If MGW7 is not configured,
+administrateivly blocked or not connected at the time a new call is to be
+established, then the MGW assignment will fail and ultimately the call will be
+terminated during establishment.
+
+<3> Apply no pinning at all (default). The MGW with the lowest load is the one
+being selected for each new call.
+
+==== Configure Lb to connect to an SMLC
+
+Enable the Lb interface. OsmoBSC will then use the default point-codes to
+establish a connection to the SMLC.
+
+----
+smlc
+ enable
+----
+
+More detailed configuration is described in <<smlc-config>>.