129 lines
4.3 KiB
Plaintext
129 lines
4.3 KiB
Plaintext
[[chapter_overview]]
|
|
== Overview
|
|
|
|
=== About OsmoGbProxy
|
|
|
|
OsmoGbProxy is the Osmocom proxy for the 3GPP Gb interface. The Gb
|
|
interface is defined by 3GPP as the protocol between the BSS and the
|
|
SGSN inside the 2G/2.5G/2.75G packet switched network domain.
|
|
|
|
As Osmocom implements a BTS-colocated PCU, there are potentially many
|
|
Gb interface connections between all those many PCUs in the network
|
|
and the SGSN. This can be cumbersome to configure/maintain at the
|
|
SGSN side.
|
|
|
|
OsmoGbProxy aggregates many PCU-facing Gb connections into one Gb
|
|
connection to the SGSN. This is achieved by
|
|
|
|
* maintaining sepaate NS-VCs on the PCU side and on the SGSN side
|
|
* more or less transparently routing BSSGP peer-to-peer Virtual Circuits
|
|
(BVCs) through the proxy
|
|
* having some special handling for the signaling BVC (BVCI=0) which is
|
|
shared among all the PCUs connected to the proxy
|
|
|
|
|
|
=== Data Model
|
|
|
|
==== gbproxy_config
|
|
|
|
This contains the parsed configuration of the OsmoGbProxy.
|
|
|
|
==== gproxy_peer
|
|
|
|
A "peer" is any remote NS-entity that the proxy interacts with. A peer
|
|
includes information about:
|
|
|
|
* the [unique] NSEI of the peer
|
|
* the [unique] BVCI of the peer
|
|
* the Routeing Area (RA) of the peer
|
|
|
|
==== gbproxy_tlli_state
|
|
|
|
One of the (unique) TLLI of any of the subscribers/UEs attached to any of
|
|
the BTSs/PCUs served by the proxy.
|
|
|
|
==== gbproxy_link_info
|
|
|
|
One of the [unique] subscribers/connections that are served through this
|
|
proxy. The information includes
|
|
|
|
* the TLLI on BSS side
|
|
* the TLLI on SGSN side (may be different due to P-TMSI rewriting)
|
|
* the NSEI of the SGSN for this link
|
|
* a timestamp when we last conversed with this subscriber
|
|
* state related to IMSI acquisition
|
|
** a temporary queue of stored messages (until IMSI acquisition succeeds)
|
|
** N(U) rewriting state (inserting IDENTTIY REQ changes LLC sequence numbers)
|
|
|
|
==== gbproxy_match
|
|
|
|
A single matching rule against which IMSIs are matched. The matching rule
|
|
is expressed as regular expression. There can be one such matching rule for
|
|
each
|
|
|
|
* routing between two different SGSNs, see below
|
|
* patching of messages (e.g. APN, PLMN)
|
|
|
|
|
|
=== Advanced Features
|
|
|
|
==== PLMN patching
|
|
|
|
This feature permits to modify the PLMN inside any BSSGP messages
|
|
containing the Routing Area ID (RAID).
|
|
|
|
The configured core-mcc and core-mnc will be used towards the SGSN,
|
|
irrespective of which MCC/MNC the PCU is using/reporting on Gb.
|
|
|
|
==== APN patching
|
|
|
|
This will transparently re-write the APN name inside SM ACTIVATE PDP
|
|
REQUEST messages on the way from the MS to the SGSN. The patching is
|
|
performed based on matching on the IMSI of the subscriber.
|
|
|
|
The configured core-apn will be used towards the SGSN, irrespective
|
|
of which APN the MS is requesting in its Layer3 signaling.
|
|
|
|
APN patching can only be performed if no GPRS encryption is enabled in
|
|
the network!
|
|
|
|
APN patching is useful in case a valid APN cannot reliably be
|
|
provisioned via other means, such as via the SIM Card, OTA-DM or via
|
|
CAMEL rewriting in the SGSN.
|
|
|
|
==== P-TMSI patching
|
|
|
|
This feature transparently rewrite the P-TMSI between MS and SGSN. This
|
|
is required when using the Secondary SGSN support, as both SGSNs could
|
|
allocate overlapping TMSIs and we must make sure they're unique across
|
|
both SGSNs.
|
|
|
|
P-TMSI patching is required by (and hence automatically enablede if
|
|
secondary SGSN support is enabled.
|
|
|
|
P-TMSI patching can only be performed if no GPRS encryption is enabled in
|
|
the network!
|
|
|
|
==== IMSI Acquisition
|
|
|
|
This is a special feature where the proxy will by itself inject GMM IDENTITY
|
|
REQUEST messages for the IMSI into the downlink BSSGP traffic in order
|
|
to establish the IMSI of subscribers for which it is not otherwise known
|
|
|
|
IMSI acquisition is automatically enabled if secondary SGSN support is
|
|
enabled.
|
|
|
|
==== Secondary SGSN Support
|
|
|
|
This allows the proxy to connect not only to one SGSN, but to two
|
|
different SGSNs. IMSI matching rules are applied to determine which of
|
|
the SGSNs is to be used for traffic of this subscriber.
|
|
|
|
One possible use case of this feature is to have a "local break-out" for
|
|
subscribers who are native to this network (and hence save
|
|
latencies/overhead of back-hauling all related traffic via the
|
|
SGSN+GGSN) while at the same time maintaining the classic behavior for
|
|
inbound roaming subscribers, where the roaming agreements mandate that
|
|
data traffic is brought back to the GGSN in the HPLMN via the SGSN of
|
|
the VPLMN.
|