doc/manuals/chapters/gbproxy-sgsnpool.adoc

== SGSN Pooling

SGSN pooling is described in 3GPP TS 23.236 <<3gpp-ts-23-236>>, and is supported
by OsmoGbProxy since early 2021.

The aim of SGSN pooling is to distribute load from a BSS across multiple SGSNs,
which are equivalent and redundant infrastructure for the same core network.

The main mechanism for SGSN pooling is the TLLI/P-TMSI, which an SGSN hands out
to its attached subscribers. Typically 10 bits of the P-TMSI are designated as a
Network Resource Identifier (NRI) that identifies the originating SGSN, and
allows OsmoGbProxy to direct a subscriber back to the same SGSN instance that
previously negotiated the Attach procedure. Typically, the full NRI value
range available is divided into N even ranges, where each SGSN is assigned one
NRI range.

Subscribers attaching without a TLLI, or those with unknown NRI value,
are evenly distributed across SGSN instances. OsmoGbProxy uses a hash-based
approach to distribute load across all connected SGSNs.

A Paging Response from a subscriber is always returned back to whichever SGSN
initiated the Paging, regardless of the Mobile Identity used.

Finally, a NULL-NRI is a special NRI value that indicates that the SGSN wishes
to offload this subscriber to a different SGSN. A NULL-NRI is an arbitrary NRI
value that is chosen distinctly for each PLMN served by a BSS, so that a
subscriber can be reassigned within that PLMN. Upon (periodic) Location
Updating, an offloading SGSN hands out a NULL-NRI value in the assigned TLLI,
along with a non-broadcast LAI. The subscriber will notice the LAI mismatch,
and immediately re-attempt the attach using the TLLI containing the NULL-NRI.
OsmoGbProxy recognises the NULL-NRI and redirects the subscriber to one of the
other SGSNs. A prerequisite for this to work well is that the particular SGSN is
previously marked as not accepting new subscribers, in OsmoGbProxy's configuration.

The mechanisms described above make up the NAS node selection function
implemented in OsmoGbProxy.

3GPP TS 23.236 also defines that an offloading SGSN hands subscriber information
to the newly assigned SGSN, which takes place outside the scope of OsmoGbProxy.

=== Configuring SGSN Pooling

The NRI ranges assigned to each SGSN must match in the OsmoGbProxy and the SGSN
configuration. If inconsistent NRI value ranges are configured,
attached subscribers would be redirected to SGSN instances that did not perform the
attach, possibly rendering the core network unusable.

==== Connecting Multiple SGSNs

----
! Configure the Network Service
ns
 bind udp sgsn
  listen 10.0.0.1 23000
 nse 1
  ip-sns-bind sgsn
  ip-sns-remote 10.0.1.1 23000
  ip-sns-remote 10.0.1.1 23001
 nse 2
  ip-sns-bind sgsn
  ip-sns-remote 10.0.1.2 23000
 nse 3
  ip-sns-bind sgsn
  ip-sns-remote 10.0.1.3 23000
! configure NRI value ranges
gbproxy
 nri bitlen 10
 nri null add 0
sgsn nsei 1
 name SGSN01
 nri add 1 341
sgsn nsei 2
 name SGSN02
 nri add 342 682
sgsn nsei 3
 name SGSN03
 nri add 683 1023
----

==== NRI Value Bit Length

In OsmGbProxy, the NRI value's bit length is freely configurable from 0 to 15
bits. 3GPP TS 23.236 suggests a typical bit length of 10. Setting the length
to 0 disables SGSN pooling, this is also the default.
The NRI bit length must be identical across the entire SGSN pool.

Change the NRI value bit length in OsmoGbProxy's VTY configuration like this:

----
gbproxy
 nri bitlen 10
----

In the TMSI bits, regardless of the NRI bit length, the NRI value always starts
just after the most significant octet of a TMSI (most significant bit at TMSI's
bit 23).

==== NULL-NRI

Since OsmoGbProxy supports serving only one PLMN, NULL-NRI are configured globally.
Even though 3GPP TS 23.236 indicates that there is a single NULL-NRI per PLMN,
OsmoGbProxy allows configuring multiple NULL-NRI values.

----
network
 nri null add 0
 nri null add 423
----

==== Assigning NRI Ranges to SGSNs

Each SGSN configured in OsmoGbProxy must be assigned a distinct NRI value range.
Overlapping NRI value ranges will cause failure to serve subscribers.

NRI values are typically configured in ranges, here dividing a 10bit range
(0..1023) into three equal ranges, while leaving 0 available to be configured
as NULL-NRI:

----
sgsn nsei 1
 nri add 1 341
sgsn nsei 2
 nri add 342 684
sgsn nsei 3
 nri add 685 1023
----

NRI can also be assigned in single values:

----
sgsn nsei 1
 nri add 23
----

Ranges can be constructed arbitrarily by a sequence of `add` and `del`
configurations, here a contrived example:

----
sgsn nsei 1
 nri add 0 342
 nri del 23
 nri del 42 235
 nri add 1000 1023
----

On the VIEW and ENABLE VTY nodes, `show nri all` shows all SGSNs:

----
OsmoGbProxy> show nri all
sgsn nsei 1
 nri add 1 341
sgsn nsei 2
 nri add 342 684
sgsn nsei 3
 nri add 685 1023
----

When configuring overlapping NRI value ranges across SGSNs, the telnet VTY warns
about it, and starting OsmoGbProxy with such a configuration will fail:

----
sgsn nsei 1
 nri add 1 511
sgsn nsei 2
 nri add 512 1023
sgsn nsei 3
 nri add 500 555
----

This results in:

----
$ osmo-gbproxy
% Warning: NSE(00003/SGSN): NRI range [500..555] overlaps between NSE 00003 and NSE 00001. For overlaps, NSE 00001 has higher priority than NSE 00003
% Warning: NSE(00003/SGSN): NRI range [500..555] overlaps between NSE 00003 and NSE 00002. For overlaps, NSE 00002 has higher priority than NSE 00003
----

==== SGSN Offloading

To effectively offload a particular SGSN, it must be marked as no longer taking
new subscribers in OsmoGbProxy. This can be achieved in the telnet VTY by:

----
sgsn nsei 1
 no allow-attach
----

This SGSN will, as long as it is connected, continue to serve subscribers
already attached to it: those that yield an NRI matching this SGSN, and those
that are being paged by this SGSN. But OsmoGbProxy will no longer direct new
subscribers to this SGSN.

To re-enable an SGSN for attaching new subscribers:

----
sgsn nsei 1
 allow-attach
----

==== Traffic allocation

In a SGSN pool, osmo-gbproxy is facing the problem of dividing the downlink
capacity of a cell towards the SGSN.  The BSS advertises the per-BVC capacity
by means of the BSSGP FLOW-CONTROL-BVC messages, but as there are multiple
SGSN in a pool, they all have to share / divide that total capacity.

By default, osmo-gbproxy advertises the full capacity to _each_ of the SGSN
pool members, which results in significant over-provisioning and can lead to
overload situations.

The administrator can configure the _percentage_ of the overall BSS-advertised
capacity that shall be reported to each pool member SGSN using the
`pool bvc-flow-control-ratio <1-100>` configuration command.

A setting of 100 means that each pool member is informed of 100% of the
BSS side capacity.

A setting of 25 means that each pool member is informed of 25% of the
BSS side capacity.  This would make most sense in a set-up with four
SGSN of equal share.

More complex capacity division schemes are so far not supported by
osmo-gbproxy.