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

1 files changed, 44 insertions, 77 deletions

diff --git a/doc/manuals/chapters/gbproxy-overview.adoc b/doc/manuals/chapters/gbproxy-overview.adoc
index 1564157ad..3cd0d73c8 100644
--- a/doc/manuals/chapters/gbproxy-overview.adoc
+++ b/doc/manuals/chapters/gbproxy-overview.adoc
@@ -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
-
-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
+==== gbproxy_bvc
 
-This feature permits to modify the PLMN inside any BSSGP messages
-containing the Routing Area ID (RAID).
+A ptp-BVC on an NSE
 
-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.
+* the BVCI of this BVC
+* the routing area of this BVC
+* the BVC state machine
 
-==== APN patching
+==== gbproxy_cell
 
-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.
+This contains a view of the cell and its associated BVCs
 
-The configured core-apn will be used towards the SGSN, irrespective
-of which APN the MS is requesting in its Layer3 signaling.
+* the unique BVCI of this cell
+* the routing area of this cell
+* one bss-side BVC
+* one BVC per SGSN in the pool
 
-APN patching can only be performed if no GPRS encryption is enabled in
-the network!
+==== gbproxy_sgsn
 
-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.
+Represents one SGSN in the pool. Contains:
 
-==== P-TMSI patching
+* the NSE belonging to this SGSN
+* a (configurable) name of the SGSN
+* pool-related configuration of the SGSNs
 
-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.
+==== IMSI cache
 
-P-TMSI patching is required by (and hence automatically enablede if
-secondary SGSN support is enabled.
+In order to route messages to the correct BSS or SGSN OsmoGbProxy
+sometimes needs to cache where messages came from.
 
-P-TMSI patching can only be performed if no GPRS encryption is enabled in
-the network!
+In BSS->SGSN direction the IMSI-cache is needed for
 
-==== IMSI Acquisition
+* paging ps reject
+* dummy paging response
 
-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
+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.
 
-IMSI acquisition is automatically enabled if secondary SGSN support is
-enabled.
+==== TLLI cache
 
-==== Secondary SGSN Support
+In SGSN->BSS direction OsmoGbProxy needs a TLLI cache to correctly route the
+following messages:
 
-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.
+* suspend ack/nack
+* resume ack/nack
 
-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.
\ No newline at end of file