| Daniel Willmann | fcf0abb | 2021-01-26 18:19:48 +0100 | [diff] [blame] | 1 | == Configuring OsmoGbProxy |
| Harald Welte | a5ad7a4 | 2019-03-21 22:52:44 +0100 | [diff] [blame] | 2 | |
| Daniel Willmann | 1296972 | 2021-01-27 18:24:42 +0100 | [diff] [blame^] | 3 | OsmoGbProxy requires very little configuration, most of it being the |
| 4 | configuration of the NS links. |
| 5 | Most config options specific to OsmoGbProxy are related to SGSN pooling and |
| 6 | telling the proxy which NSE(s) it should use to talk to the SGSN(s). |
| Harald Welte | 209dc9f | 2020-12-12 19:02:16 +0100 | [diff] [blame] | 7 | |
| Daniel Willmann | 1296972 | 2021-01-27 18:24:42 +0100 | [diff] [blame^] | 8 | === Configure the Network Service (NS) |
| 9 | |
| 10 | A detailed description of the NS configuration can be found in <<libosmogb>>. |
| 11 | The following config snippets assume the SGSN(s) (NSEI 101 and 102) are using |
| 12 | IP-SNS and listen on 10.0.1.1:23000 and 10.0.1.2:23000 respectively. |
| 13 | |
| 14 | This would be the NS config for the SGSN(s): |
| 15 | |
| 16 | .Example: NS configuration example (SGSN) |
| 17 | ---- |
| 18 | ns |
| 19 | bind udp local |
| 20 | listen 10.0.0.1 23000 <1> |
| 21 | nse 101 <2> |
| 22 | ip-sns 10.0.1.1 23000 <3> |
| 23 | nse 102 |
| 24 | ip-sns 10.0.1.2 23000 |
| 25 | ---- |
| 26 | <1> Define the local IP/port from which to connect |
| 27 | <2> Define an NSE with NSEI |
| 28 | <3> Use IP-SNS to connect to the SGSN |
| 29 | |
| 30 | === Configure an SGSN |
| 31 | |
| 32 | Configuration of a single (non-pooling) SGSN is rather simple. |
| 33 | |
| 34 | .Example: SGSN configuration example |
| 35 | ---- |
| 36 | sgsn 101 <1> |
| 37 | name Main SGSN <2> |
| 38 | ---- |
| 39 | <1> Each SGSN is identified by its NSEI (same as in the NS configuration) |
| 40 | <2> An SGSN can optionally have a name. If none is set a default name will be used. |
| Harald Welte | 209dc9f | 2020-12-12 19:02:16 +0100 | [diff] [blame] | 41 | |
| 42 | === SGSN pool support |
| 43 | |
| 44 | In a SGSN pool, osmo-gbproxy is facing the problem of dividing the downlink |
| 45 | capacity of a cell towards the SGSN. The BSS advertises the per-BVC capacity |
| 46 | by means of the BSSGP FLOW-CONTROL-BVC messages, but as there are multiple |
| 47 | SGSN in a pool, they all have to share / divide that total capacity. |
| 48 | |
| 49 | By default, osmo-gbproxy advertises the full capacity to _each_ of the SGSN |
| 50 | pool members, which results in significant over-provisioning and can lead to |
| 51 | overload situations. |
| 52 | |
| 53 | The administrator can configure the _percentage_ of the overall BSS-advertised |
| 54 | capacity that shall be reported to each pool member SGSN using the |
| 55 | `pool bvc-flow-control-ratio <1-100>` configuration command. |
| 56 | |
| 57 | A setting of 100 means that each pool member is informed of 100% of the |
| 58 | BSS side capacity. |
| 59 | |
| 60 | A setting of 25 means that each pool member is informed of 25% of the |
| 61 | BSS side capacity. This would make most sense in a set-up with four |
| 62 | SGSN of equal share. |
| 63 | |
| 64 | More complex capacity division schemes are so far not supported by |
| 65 | osmo-gbproxy. |