- Table of contents
- The Gb proxy
- Deployment scenarios
- Configuring and using osmo-gbproxy
- Advanced use cases
- Design documentation
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
git clone git://git.osmocom.org/osmo-gbproxy.git
The proxy then forwards NS-DUs (BSSGP PDUs) between the SGSN and the
respective BSS (and vice versa).
Overview (also showing circuit switched side)¶
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).
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.
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.
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.
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 email@example.com in case you would want to hear more about its capabilities.
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:
-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.
There is a wiki page osmo-gbproxy_VTY with a reference for all VTY commands
Advanced use cases¶
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.
There's a more detailed design description outlining
details of the proxy.