osmo-hnbgw/doc/manuals/chapters/running.adoc

177 lines
5.4 KiB
Plaintext

== Running OsmoHNBGW
The OsmoHNBGW executable (`osmo-hnbgw`) offers the following command-line
arguments:
=== SYNOPSIS
*osmo-hnbgw* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-T] [-e 'LOGLEVEL']
=== OPTIONS
*-h, --help*::
Print a short help message about the supported options
*-V, --version*::
Print the compile-time version number of the OsmoHNBGW 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 <<logging>> 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-msc.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 <<logging>>
for more information.
*-T, --timestamp*::
Enable time-stamping of log messages to stderr. This has mostly
been deprecated by VTY based logging configuration, see
<<logging>> 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
<<logging>> for more information.
=== Multiple instances
Running multiple instances of `osmo-hnbgw` on the same computer is possible if
all interfaces (VTY, CTRL, Iuh) 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
----
The Iuh interface can be bound to an individual port:
----
hnbgw
iuh
local-ip 0.0.0.0
local-port 29169
----
For the following links, OsmoHNBGW 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 OsmoHNBGW contacting an STP.
- The MGCP link is established by OsmoHNBGW contacting an MGW.
- The PFCP link is established by OsmoHNBGW contacting a UPF.
To run multiple OsmoHNBGW instances on the same SCCP routing, each HNBGW has to
configure a distinct point-code, see <<configure_iucs_iups>>.
=== Configuring Primary Links
[[configure_iucs_iups]]
==== Configure SCCP/M3UA to connect to an MSC's _IuCS_ and an SGSN's _IuPS_ interface
OsmoHNBGW acts as client to contact an STP instance and establish an SCCP/M3UA
link.
An example configuration of OsmoHNBGW's SCCP link:
----
cs7 instance 0
point-code 0.23.5
asp asp-clnt-OsmoHNBGW 2905 0 m3ua
remote-ip 127.0.0.1
sctp-role client
sccp-address msc
routing-indicator PC
point-code 0.23.1
sccp-address sgsn
routing-indicator PC
point-code 0.23.2
hnbgw
iucs
remote-addr msc
iups
remote-addr sgsn
----
This configuration is explained in detail in <<cs7_config>>.
==== Configure RUA to accept Iuh connections from hNodeB
OsmoHNBGW acts as server to accept Iuh connections from hNodeB devices.
An example configuration for OsmoHNBGW's RUA server:
----
hnbgw
iuh
local-ip 10.9.8.7
local-port 29169
----
==== Configure co-located media gateway
OsmoHNBGW requires a co-located OsmoMGW instance. The purpose of the co-located
media gateway is to relay the RTP traffic between hNodeB and the core network.
For security reasons the RAN network is kept separate and isolated from the
core network. Both networks will usually have no transparent routing in between
them. The co-located media gateway provides an interface between hNodeB and core
network across this boundary.
The configuration is done under the hnbgw node along with `iucs` and `iups`.
An example configuration for OsmoHNBGW's MGCP client:
----
hnbgw
mgw 0
remote-ip 127.0.0.1
remote-port 2427
reset-endpoint rtpbridge/*
----
==== Configure co-located User Plane Function
OsmoHNBGW optionally supports relaying the GTP user plane via a co-located UPF,
which is controlled by the PFCP protocol.
PFCP support is optional at compile time, as well as run time. To use a co-located UPF,
* osmo-hnbgw needs to be compiled with 'configure --enable-pfcp',
* and osmo-hnbgw.cfg needs to configure a 'pfcp' / 'remote-addr' and
'local-addr'.
The following example configures OsmoHNBGW to associate via PFCP with a UPF
listening on UDP 127.0.0.2:8805, ready to setup GTP tunnel relays.
----
hnbgw
pfcp
remote-addr 127.0.0.2
local-addr 127.0.0.1
----
3GPP TS 29.244 4.2.2 specifies that PFCP Request messages shall be sent to UDP
port 8805, i.e. the PFCP port is fixed as 8805 and currently not configurable in
osmo-hnbgw.
Setting a 'local-addr' is required: the PFCP protocol features a Node ID, which
uniquely identifies PFCP peers across different interfaces. According to the
PFCP specification, the Node ID can be a fully-qualified domain name (FQDN) or
an IP address. Currently, osmo-hnbgw has no support for using an FQDN as Node
ID, and so far uses the 'local-addr' as local Node ID -- hence the 'local-addr'
must not be "0.0.0.0", which is an unfortunate consequence. This is likely to
improve in the future, see https://osmocom.org/issues/5647 .