A typical OS imposed limit is 1024 open FD, which is too low when there
are thousands of HNB.
In systemd service file, set a super high limit of 65536.
In osmo-hnbgw's user manual, add section 'Configure limits' describing
this in detail.
Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I5333765199cf9e3e5a570f85b85d2b7423d34a4d
According to 3GPP TS 25.413 8.26.2.2, "The RNC shall include the Global
RNC-ID IE in the RESET message." To be able to do that, osmo-hnbgw needs
to know the local PLMN.
Introduce explicit knowledge of the local PLMN by config, and use this
configured local PLMN in places where the local PLMN was so far derived
otherwise.
Subsequent patches will separately add the RNC-ID to the RANAP RESET
messages.
Since the PLMN is required to send correct RESET and RESET ACK, include
the new 'plmn' config item in all example configurations.
Related: SYS#6441
Change-Id: If404c3859acdfba274c719c7cb7d16f97d831a2a
After recent introduction of multiple 'msc' and 'sgsn' nodes in the
VTY config, switch cfg files to the new syntax:
- in doc/examples
- for 'make config-tests'
- have one test in old config syntax to test backwards compat:
'legacy', an exact copy of 'one_cs7_with_addrs'.
Related: SYS#6412
Change-Id: If999b71a8a8237699f6ccfcaa31d1885e66c0518
Allow configuring multiple MSCs and SGSNs. Show this in new transcript
test cnpool.vty and in sccp.dot chart.
Still use only the first CN link; actual CN link selection from the pool
follows in I66fba27cfbe6e2b27ee3443718846ecfbbd8a974.
Config examples and VTY tests cfg files will be adjusted to the new cfg
syntax in patch If999b71a8a8237699f6ccfcaa31d1885e66c0518. Only the VTY
write() changes are visible here, to pass all transcript tests.
Related: SYS#6412
Change-Id: I5479eded786ec26062d49403a8be12967f113cdb
Prepare for CN pooling; allow using separate SS7 instances for IuCS and
IuPS.
New struct hnbgw_sccp_user describes a RANAP SCCP user, one per cs7.
Limit struct hnbgw_cnlink to describing a CN peer, using whichever SCCP
instance that is indicated by hnbgw_sccp_user.
Chart sccp.dot shows the changes made.
Related: SYS#6412
Change-Id: Iea1824f1c586723d989c80a909bae16bd2866e08
Show current use of SCCP and SS7 by osmo-hnbgw, which is about to
change (along with this chart).
Related: SYS#6422
Change-Id: I109948758de998326a5e9f0dcdc84d5f11dfba02
We have not a single example yet showing point code and SCCP address
configuration. Add this example, which will also show how the config
file syntax changes while introducing CN pooling in upcoming patches.
Related: SYS#6412
Change-Id: I42c3b434a7339cc3efb27b43c893cfb734de9ca4
The RUA side may disconnect
a) gracefully (RUA Disconnect with RANAP IU Release Complete) or
b) by detecting that the HNB is gone / has restarted
For a), the SCCP side waits for a RLSD from the CN that follows the IU
Release Complete.
For b), we so far also wait for a RLSD from CN, which will never come,
and only after a timeout send an SCCP RLSD to the CN.
Instead, for b), immediately send an SCCP RLSD.
To distinguish between the graceful release (a) and the disruptive
release (b), add new state MAP_RUA_ST_DISRUPTED on the RUA side,
and add new event MAP_SCCP_EV_RAN_LINK_LOST for the SCCP side.
Any non-graceful disconnect of RUA enters ST_DISRUPTED.
disrupted_onenter() dispatches EV_RAN_LINK_LOST to SCCP,
and SCCP directly sends RLSD to the CN without timeout.
These changes are also shown in doc/charts/hnbgw_context_map.msc.
Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1
Prepend it to the cs7 config .adoc, so that it introduces some concepts
and specifies some limitations of current implementation, etc.
Change-Id: I9faef2dd15b62814e474299c675c2cb05b779c44
Planning new connection-oriented RUA and SCCP FSMs to
- conquer confusion about hnbgw_context_map release behavior, and
- eradicate SCCP connection leaks.
Related: SYS#6297
Change-Id: I661bf65d79972a732c52732934095e8bfcd99694
This way we document the recently gained support for MGW pooling.
Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: I3dc8a4b50f13ad50390ba82e64fe4ebe0b97d4e5
Large RAN installations may benefit from distributing the RTP voice
stream load over multiple media gateways.
libosmo-mgcp-client supports MGW pooling since version 1.8.0 (more than
one year ago). OsmoBSC has already been making use of it since then (see
osmo-bsc.git 8d22e6870637ed6d392a8a77aeaebc51b23a8a50); lets use this
feature in osmo-hngw too.
This commit is also part of a series of patches cleaning up
libosmo-mgcp-client and slowly getting rid of the old non-mgw-pooled VTY
configuration, in order to keep only 1 way to configure
libosmo-mgcp-client through VTY.
Related: SYS#5091
Related: SYS#5987
Change-Id: I371dc773b58788ee21037dc25d77f556c89c6b61
Change from ascii art to the dotty chart, taken from the osmocom.org
wiki. No need to keep a separate representation here.
Change-Id: Ifd8843aeb8ff28fec53323c8fb37b10d4d1f2f9b
There are several osmo processes that talk to osmo-mgw via
osmo-mgcp-client. The sample config for osmo-bsc suggest 2727 and the
sample config for osmo-msc suggests 2728 as local port default. To make
it less likely for users to get port collisions whlie setting up their
networks we should use a different port for osmo-hnbgw. Lets use 2729.
Change-Id: I55179c2bff3e6ef0e54fee6b1b90fc76f541e58e
OsmoHNBGW now requires a co-located OsmoMGW instance. Lets add add some
info on how to configure it.
Change-Id: Id47f4f365cee78ce28d1534c4e3e98a59bdb0621
Related: OS#5152
Neels Hofmeyr
Andreas Eversberg
Pau Espin
Philipp Maier