MMEs connect over Gn interface using GTPCv1 towards the SGSN in order to
exchange RIM PDUs by using "RAN Information Relay" GTPCv1 message type.
For more info, see 3GPP TS 29.060 sec 220.127.116.11 "RAN Information Relay"
In order to support it, this commit does the following:
* Uses new libgtp APIs to rx and tx RAN Information Relay messages. The
same "gsn" object is reused, ie. the local GTPCv1 socket address used
for exchanging messages against GGSN is reused.
* Adds a new "sgsn_mme_ctx" struct holding information about MMEs
allowed by the SGSN, each one containing information about the GTP
address it uses, the in/out routing based on TAI requests, etc. The
set of MMEs and their config can be set up using new VTY node introduced
in this commit.
* The RIM related code in SGSN is refactored to allow forwarding from
and to several types of addresses/interfaces.
Depends: osmo-ggsn.git Change-Id Iea3eb032ccd4aed5187baca7f7719349d76039d4
Depends: libosmocore.git Change-Id I534db7d8bc5ceb19a2a6866f07d5f5c70e456c5c
Change the whole vty configuration for NS to be more flexible
and support more setups. Old configurations are invalid.
API change which must be synchronized with libosmocore
For further information see:
Depends-on: I8c3f2afecc74b78f7f914f7dce166cbcb63444eb (libosmocore)
For the common lookup-by-nsei, this should reduce the computational
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Add 'cs7' default configuration, link to the
osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain the 'cs7'
Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals)
Since osmo-ggsn.git c94837c6a401bf0f80791b619a9b4cfbe9160afd, those
APIs are a no-op since timers are tracked internally through osmocom
APIs (and at the same time, new implementation fixes some timing related
As a result, osmo-sgsn depends now on at least that libgtp commit. Since
it's not yet avaiable on latest libgtp release, let's track it down in
TODO-RELESE to not forget to update libgtp requirements during osmo-sgsn
It's going to be useful to track new dependency APIs being used which
require dependency version release and version bump during release of