Cellular Network Infrastructure » Core Network (CN) » osmo-gbproxy

{{>toc}}

h1. The Gb proxy

The purpose of the Gb proxy is to aggregate the Gb links of multiple BSS's and present them in one Gb link to the SGSN.

More specifically, the Gb proxy terminates the NS-VCs of each BSS locally.  Furthermore, it establishes one NS-VC with the SGSN.

It also contains support for converting form a NS/UDP/IP (Gb over IP) stacking to a frame-relay based NS/FR/GRE/IP stacking.

Source code available as part of [[OpenBSC]] repository:

<pre>

git clone git://git.osmocom.org/openbsc.git

</pre>

The proxy then forwards NS-DUs (BSSGP PDUs) between the SGSN and the

respective BSS (and vice versa).

h2. Deployment scenarios

h3. Overview (also showing circuit switched side)

{{graphviz_link()

digraph G {

  rankdir=LR;

  nanobts1->OpenBSC  [ label="Abis/IP" ];

  nanobts2->OpenBSC  [ label="Abis/IP" ];

  nanobts1->gb_proxy [ label="Gb/IP" ];

  nanobts2->gb_proxy [ label="Gb/IP" ];

  gb_proxy->SGSN     [ label="Gb/IP or\nGb/FR/GRE/IP" ];

  nanobts2 [ label = "OsmoBTS\nOsmoPCU" ];

  nanobts1 [ label = "nanoBTS" ];

  OpenBSC [ label = "OpenBSC or OsmoBSC" ]

}

}}

h3. Mere aggregation of Gb/IP links towards a SGSN

This scenario is used where many Gb/IP links need to be aggregated to wards a SGSN.  It is primarily useful in GSM implementations where there is a BTS-colocated PCU (as often seen with small cells, or within Osmocom RAN where [[OsmoPCU:]] co-located next to [[OsmoBTS:]]).

Osmo-gbproxy will terminate the NS-VCs from all BSS and to the SGSN.  It will then pass through the BSSGP virtual connections from each BSS to the SGSN, while performing special treatment of BVCI=0 (signaling BVCI).

{{graphviz_link()

digraph G {

  rankdir=LR;

  pcu1->gb_proxy [ label="Gb/IP" ];

  pcu2->gb_proxy [ label="Gb/IP" ];

  pcu3->gb_proxy [ label="Gb/IP" ];

  gb_proxy->SGSN     [ label="Gb/IP" ];

  pcu1 [ label = "OsmoPCU" ];

  pcu2 [ label = "3rd party PCU" ];

  pcu3 [ label = "..."];

  SGSN [ label = "SGSN\n(Osmo or 3rd party)" ]

}

}}

h3. Conversion of Gb/IP to classic Gb over Frame Relay

This scenario is used if you have modern, IP based Gb interface from the RAN, but want to interface with traditional, TDM based SGSNs utilizing Gb over frame relay.  osmo-gbproxy doesn't itself directly interface with E1 interface cards, but it uses an external router with frame relay capability which performs Frame Relay encapsulation in GRE over IP.

{{graphviz_link()

digraph G {

  rankdir=LR;

  pcu1->gb_proxy [ label="Gb/IP" ];

  pcu2->gb_proxy [ label="Gb/IP" ];

  pcu3->gb_proxy [ label="Gb/IP" ];

  gb_proxy->router   [ label="Gb/FR/GRE/IP" ];

  router->SGSN     [ label="Gb/FR/E1" ];

  pcu1 [ label = "OsmoPCU" ];

  pcu2 [ label = "3rd party PCU" ];

  pcu3 [ label = "..."];

  router [ label = "FR capable Router\ne.g. Cisco 7200" ];

  SGSN [ label = "SGSN\n(3rd party)" ]

}

}}

h3. Connection with multiple SGSNs, routing traffic based on IMSI

This is a very special mode of operation far beyond 3GPP specifications.  Here, the purpose is to have two SGSNs, and to route the traffic from some select IMSIs to one SGSN, while using the other SGSN for all other IMSIs.  This can be used to create an architecture supported in 3.5G/4G/5G called 'local break-out', where (some) user IP traffic is directly passed to a local LAN a the base station.

{{graphviz_link()

digraph G {

  rankdir=LR;

  pcu1->gb_proxy [ label="Gb/IP" ];

  pcu2->gb_proxy [ label="Gb/IP" ];

  pcu3->gb_proxy [ label="Gb/IP" ];

  gb_proxy->SGSN   [ label="Gb/IP most IMSIs" ];

  gb_proxy->SGSN2  [ label="Gb/IP for some IMSIs" ];

  SGSN2->GGSN2 [ label="GTP" ];

  GGSN2->LAN [ label="IP" ];

  pcu1 [ label = "OsmoPCU" ];

  pcu2 [ label = "3rd party PCU" ];

  pcu3 [ label = "..."];

  SGSN [ label = "Normal SGSN" ];

  SGSN2 [ label = "BTS-local SGSN" ];

  GGSN2 [ label = "BTS-local GGSN" ];

  LAN [ label = "LAN" ];

}

}}

In order to achieve this functionality, osmo-gbproxy is building up internal state tracking tables to map IMSI with P-TMSI.

NOTE: This mode of operation can only be used if GEA0 is used, as otherwise osmo-gbproxy cannot keep track of the IMSI to P-TMSI (and hence TLLI) mappings.

h2. Documentation

* "User manual":https://ftp.osmocom.org/docs/latest/osmogbproxy-usermanual.pdf

* "VTY reference manual":https://ftp.osmocom.org/docs/latest/osmogbproxy-vty-reference.pdf

Documentation is somewhat minimalistic at this point, as this is not a general-purpose network element but something highly specialized for some niche use cases.  Feel free to contact sales@sysmocom.de in case you would want to hear more about its capabilities.

{{child_pages}}

h2. Configuring and using osmo-gbproxy

Like other programs in this project, osmo-gbproxy accepts a number of command line arguments

but is generally configured by a configuration file (which can be interactively created/edited

from the VTY).

The command line arguments are:

<pre>

  -h --help this text

  -d option --debug=DNS:DGPRS,0:0 enable debugging

  -c --config-file filename The config file to use.

  -s --disable-color

  -T --timestamp Prefix every log line with a timestamp

  -V --version. Print the version of [[OpenBSC]].

  -e --log-level number. Set a global loglevel.

</code></pre>

There is a wiki page [[osmo-gbproxy_VTY]] with a reference for all VTY commands

h2. Advanced use cases

h3. Cascading proxies

You can also cascade multiple Gb proxies behind each other, where a number

of BSS connect to one Gb proxy, which in turn connects to another Gb proxy,

which then finally connects to the SGSN.  

The reason for this type of use can be broken or limited Gb implementations

in proprietary BSS equipment, which fails to re-connect the Gb link after some

intermittent network outage.

h2. Design documentation

There's a more detailed [[osmo-gbproxy_design|design description]] outlining

details of the proxy.