This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
daniel gerrit-no-reply at lists.osmocom.orgdaniel has submitted this change. ( https://gerrit.osmocom.org/c/osmo-sgsn/+/22491 ) Change subject: manual/gbproxy: Update overview chapter ...................................................................... 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 --- M doc/manuals/chapters/gbproxy-overview.adoc 1 file changed, 44 insertions(+), 77 deletions(-) Approvals: Jenkins Builder: Verified pespin: Looks good to me, but someone else must approve lynxis lazus: Looks good to me, approved diff --git a/doc/manuals/chapters/gbproxy-overview.adoc b/doc/manuals/chapters/gbproxy-overview.adoc index 1564157..3cd0d73 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 @@ 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 @@ 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. \ No newline at end of file -- To view, visit https://gerrit.osmocom.org/c/osmo-sgsn/+/22491 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-sgsn Gerrit-Branch: master Gerrit-Change-Id: Icb9095f4002f2a0a4562fccecae109075cb93c7b Gerrit-Change-Number: 22491 Gerrit-PatchSet: 3 Gerrit-Owner: daniel <dwillmann at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann at sysmocom.de> Gerrit-Reviewer: lynxis lazus <lynxis at fe80.eu> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-MessageType: merged -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210128/7aee1d0b/attachment.htm>