manual/gbproxy: Update overview chapter
* Remove mention of features that are no longer supported * Update the data model Related: SYS#5115, SYS#5005 Change-Id: Icb9095f4002f2a0a4562fccecae109075cb93c7b
This commit is contained in:
parent
e30985ed92
commit
7061bed28d
|
|
@ -1,6 +1,10 @@
|
|||
[[chapter_overview]]
|
||||
== Overview
|
||||
|
||||
IMPORTANT: If you have used an earlier version of OsmoGbProxy please note
|
||||
that support for various features such as PLMN/APN patching, support for a
|
||||
secondary SGSN has been removed.
|
||||
|
||||
=== About OsmoGbProxy
|
||||
|
||||
OsmoGbProxy is the Osmocom proxy for the 3GPP Gb interface. The Gb
|
||||
|
|
@ -15,7 +19,7 @@ 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
|
||||
* maintaining separate 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
|
||||
|
|
@ -28,101 +32,64 @@ connection to the SGSN. This is achieved by
|
|||
|
||||
This contains the parsed configuration of the OsmoGbProxy.
|
||||
|
||||
==== gproxy_peer
|
||||
==== gbproxy_nse
|
||||
|
||||
A "peer" is any remote NS-entity that the proxy interacts with. A peer
|
||||
includes information about:
|
||||
The remote NS-entity that the proxy interacts with. Includes
|
||||
information about:
|
||||
|
||||
* the [unique] NSEI of the peer
|
||||
* the [unique] BVCI of the peer
|
||||
* the Routeing Area (RA) of the peer
|
||||
* which side this NSE is facing - SGSN or BSS
|
||||
* the list of BVCs in this NSE
|
||||
|
||||
==== gbproxy_tlli_state
|
||||
==== gbproxy_bvc
|
||||
|
||||
One of the (unique) TLLI of any of the subscribers/UEs attached to any of
|
||||
the BTSs/PCUs served by the proxy.
|
||||
A ptp-BVC on an NSE
|
||||
|
||||
==== gbproxy_link_info
|
||||
* the BVCI of this BVC
|
||||
* the routing area of this BVC
|
||||
* the BVC state machine
|
||||
|
||||
One of the [unique] subscribers/connections that are served through this
|
||||
proxy. The information includes
|
||||
==== gbproxy_cell
|
||||
|
||||
* 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)
|
||||
This contains a view of the cell and its associated BVCs
|
||||
|
||||
==== gbproxy_match
|
||||
* the unique BVCI of this cell
|
||||
* the routing area of this cell
|
||||
* one bss-side BVC
|
||||
* one BVC per SGSN in the pool
|
||||
|
||||
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
|
||||
==== gbproxy_sgsn
|
||||
|
||||
* routing between two different SGSNs, see below
|
||||
* patching of messages (e.g. APN, PLMN)
|
||||
Represents one SGSN in the pool. Contains:
|
||||
|
||||
* the NSE belonging to this SGSN
|
||||
* a (configurable) name of the SGSN
|
||||
* pool-related configuration of the SGSNs
|
||||
|
||||
=== Advanced Features
|
||||
==== IMSI cache
|
||||
|
||||
==== PLMN patching
|
||||
In order to route messages to the correct BSS or SGSN OsmoGbProxy
|
||||
sometimes needs to cache where messages came from.
|
||||
|
||||
This feature permits to modify the PLMN inside any BSSGP messages
|
||||
containing the Routing Area ID (RAID).
|
||||
In BSS->SGSN direction the IMSI-cache is needed for
|
||||
|
||||
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.
|
||||
* paging ps reject
|
||||
* dummy paging response
|
||||
|
||||
==== APN patching
|
||||
when SGSN-pooling is enabled and multiple SGSNs are configured. The IMSI
|
||||
contained in a paging ps or dummy paging message is cached together with
|
||||
the originating SGSN/NSE. The answer, which also contains the IMSI, is
|
||||
then routed back to the original SGSN.
|
||||
|
||||
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.
|
||||
==== TLLI cache
|
||||
|
||||
The configured core-apn will be used towards the SGSN, irrespective
|
||||
of which APN the MS is requesting in its Layer3 signaling.
|
||||
In SGSN->BSS direction OsmoGbProxy needs a TLLI cache to correctly route the
|
||||
following messages:
|
||||
|
||||
APN patching can only be performed if no GPRS encryption is enabled in
|
||||
the network!
|
||||
* suspend ack/nack
|
||||
* resume ack/nack
|
||||
|
||||
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.
|
||||
Suspend/resume are sent over the signalling BVC to the SGSN. OsmoGbProxy saves
|
||||
the TLLI->NSE association in the TLLI cache and routes the ack/nack back to
|
||||
the signalling BVC of the originating NSE.
|
||||
Loading…
Reference in New Issue