[[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
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 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
  shared among all the PCUs connected to the proxy


=== Data Model

==== gbproxy_config

This contains the parsed configuration of the OsmoGbProxy.

==== gbproxy_nse

The remote NS-entity that the proxy interacts with. Includes
information about:

* the [unique] NSEI 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_bvc

A ptp-BVC on an NSE

* the BVCI of this BVC
* the routing area of this BVC
* the BVC state machine

==== gbproxy_cell

This contains a view of the cell and its associated BVCs

* the unique BVCI of this cell
* the routing area of this cell
* one bss-side BVC
* one BVC per SGSN in the pool

==== gbproxy_sgsn

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

==== IMSI cache

In order to route messages to the correct BSS or SGSN OsmoGbProxy
sometimes needs to cache where messages came from.

In BSS->SGSN direction the IMSI-cache is needed for

* paging ps reject
* dummy paging response

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.

==== TLLI cache

In SGSN->BSS direction OsmoGbProxy needs a TLLI cache to correctly route the
following messages:

* suspend ack/nack
* resume ack/nack

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.