== Gb/NS Network Service

'libosmogb' is part of the libosmocore.git repository and implements the
Gb interface protocol stack consisting of the NS and BSSGP layers. It
is used in a variety of Osmocom projects, including OsmoSGSN, OsmoPCU
and OsmoGbProxy.

NOTE: <<3gpp-ts-48-016>> specifies Network Service

[[gb_variants]]
=== Gb interface variants

There are multiple variants of the Gb interface. This
section tries to provide an overview into what those variants are, how
they differ from each other.

The two peers involved in any Gb interface must always be in agreement
about the specific Gb interface variant before they are able to
connect.

The following variants are supported by Osmocom:

* Gb-over-Frame-Relay over E1/T1
* Gb-over-IP "ip.access style"
* Gb-over IP 3GPP static configuration
* Gb-over-IP 3GPP auto-configuration

[[gb-fr]]
==== Gb over Frame Relay over E1/T1

Historically, this is the first Gb interface that was specified as part
of GSM Release 97 when GPRS was first introduced.

Like all other terrestrial GSM interfaces, it uses circuit-switched
technology from the PDH/ISDN family of systems: E1 or T1 lines as per
ITU-T G.703 / G.704.

GSM TS 08.16 and later <<3gpp-ts-48-016>> specify that Frame Relay (FR)
shall be used as transport layer between the E1/T1 bit-stream and the
NS-level Gb messages.

Two peer entities such as a GPRS BSS and a SGSN are interconnected by a
NS-VCG (Virtual Connection Group) consisting of any number of NS-VCs
(Virtual Connections).

Each NS-VC in turn operates over a Frame Relay Permanent Virtual Circuit
(PVC), identified by its DLCI (Data Link Connection Identifier).

The protocol stacking is BSSGP/NS/FR/E1.


===== FR Driver Support

The Osmocom NS/FR implementation currently requires the individual Frame Relay
Links to be exposed as Linux kernel HDLC net-devices. The Osmocom NS
implementation has to be instructed which `hdlcX` network devices it
shall use for each NS-VC, and which DLCIs to use on them.

The Linux kernel Frame Relay LMI support (which only implements the user
role anyway) is not used. Instead, the ITU-T Q.933 LMI is implemented
as part of the Osmocom NS code in libosmogb. Osmocom NS code configures
the `hdlcX` device to match the correct mode (fr) and lmi (none).
This is equivalent to the user-space command `sethdlc hdlcX fr lmi none`.
 The net-devices will be also brought _up_ by the Osmocom NS code equivalent to
 `ip link set hdlcX up` command.

As the Osmocom Gb implementation uses AF_PACKET sockets on those
`hdlcX` network interfaces, the respective program must be running with
`CAP_NET_RAW` capability.

[[gb-gre-fr]]
==== Gb over Frame Relay encapsulated in GRE/IP

This is a variant of the Gb-over-FR specified above. However, an
external router (e.g. certain ancient Cisco routers) is used to take the
Frame Relay frames from the physical E1/T1 TDM circuit and wrap them
into the GRE encapsulation as per IETF RFC 2784.

NOTE: GRE/IP has been removed from Osmocom NS code.

[[gb-ip-access]]
==== Gb over IP "ip.access style"

This is a non-standard variant of Gb which is not found in the GSM/3GPP
specifications.

It uses an UDP/IP based transport layer, while not yet implementing the
IP-SNS that is normally required by a true 3GPP Gb over IP interface
described further below. Hence, this variant resembles an intermediate
state where a Gb interface originally designed for Frame Relay is used
over IP without any of the IP-specific procedures specified by 3GPP.

The major difference to 3GPP Gb over IP specified below are:

* No support for the IP-SNS and its SNS-SIZE, SNS-ADD, SNS-DELETE,
  SNS-WEIGHT procedures.
* Use of the NS-RESET, NS-BLOCK and NS-UNBLOCK procedures which are
  normally forbidden over an IP network.

The protocol stacking is BSSGP/NS/UDP/IP.

[[gb-ip-sns]]
==== Gb over IP 3GPP static and auto-configuration

This is the only official, 3GPP-standardized way of speaking a Gb
interface over IP based transport.

It features the IP Sub-Network Service (IP-SNS) which allows either
static configuration or dynamic configuration.
The static configuration requires to specify the NSE and related NS-VC
configuration via VTY similiar to Gb-over-FR.

===== Gb over IP 3GPP auto-configuration

The auto-configuration allow to dynamically exchange information about
IP endpoints (IP+port tuples) between the Gb interface peers.
This means that normally only one initial IP endpoint needs to be configured.
All additional IP endpoints and their relative weight for load distribution are then negotiated via the
IP-SNS auto-configuration procedure.

The major differences of this true IP based Gb compared to any of the
above are:

* No use of the NS-RESET, NS-BLOCK or NS-UNBLOCK procedures.
* Ability to use some NS-VCs only for signaling (data_weight=0) or only
  for user plane traffic (signaling_weight=0). This helps with SGSNs
  that have an internal control/user plane separation architecture.

Once the IP endpoints of the peers are known to each other, A full mesh
of NS-VCs between all BSS endpoints and all SGSN endpoints is
established.

<<fig-gb-sns-nsvcs>> below illustrates a deployment with two IP
endpoints on both the BSS (PCU) and the SGSN, as well as the resulting
four NS-VCs established between them.

[[fig-gb-sns-nsvcs]]
.IP sub-network relationship between NS-VCs and NS-VLs (from 3GPP TS 48.016)
image::./common/images/gb-ip-nsvc.pdf[]

The sequence of messages in an IP-SNS enabled Gb interface bring-up can
be seen in <<fig-ip-sns-sequence>>. Here we have a PCU/BSS with a
single IP endpoint and a SGSN with two IP endpoints, which results in
only two NS-VC being established.

Furthermore, for each of the cells in the BSS/PCU, we can see the
BVC-RESET procedure for its corresponding PTP BVC.

[[fig-ip-sns-sequence]]
.Initialization of Gb interface using IP-SNS procedures
[mscgen]
----
include::gb-ip-sns.msc[]
----

=== General structure

The general structure of the configuration is split into 3 parts

* binds (NS-VL)
* nse (NS-E)
* timeouts

==== bind (NS-VL)

A bind represent a NS-VL. A bind has a specific type (IP/UDP or FR)
and a unique name.

==== NS-E

A NSE node represents a NS Entity. A NSE is either persistent or dynamic.
A persistent NSE is configured by VTY. A dynamic NSE is created on-demand
without any VTY node. The SGSN/GbProxy creates dynamic NSE when a BSS connects
to the SGSN (see accept-ipaccess).
The PCU creates a dynamic NSE when it receives the configuration from BTS/BSC.

==== NS-VC

A NS-VC is always bound to a NSE and the bind (NS-VL). The NSVC can be either
persistent or dynamic.


=== Gb/NS configuration

This section describes the configuration that libosmogb exposes via the
VTY and is valid for OsmoSGSN and OsmoGbProxy.

==== Gb over Frame Relay over E1/T1

The Gb over Frame Relay over E1/T1 requires:

* a hdlc interface
* a frame relay role (fr or frnet)
* the DLCI

.Example: Gb over Frame Relay configuration #1
----
ns
 bind fr sitea1 <1>
  fr hdlc1 frnet <2>
 nse 2001 <3>
  nsvci fr sitea1 dlci 16 nsvci 11
----
<1> a Gb-over-FR bind with the name sitea1
<2> connect the hdlc1 device with the role frnet to sitea1
<3> one NSE (2001) with a single NS-VCI 11 on sitea1 with DLCI 16

.Example: Gb over Frame Relay configuration #2
----
ns
 bind fr sitea1 <1>
  fr hdlc1 frnet <2>
 bind fr sitea2
  fr hdlc2 frnet
 bind fr sitea3
  fr hdlc3 frnet
 bind fr sitea4
  fr hdlc4 frnet
 bind fr siteb1
  fr hdlc5 frnet
 bind fr siteb2
  fr hdlc6 frnet
 bind fr sitec1
  fr hdlc7 frnet
 bind fr sitec2
  fr hdlc8 frnet
 nse 2001 <3>
  nsvci fr sitea1 dlci 16 nsvci 11
  nsvci fr sitea2 dlci 17 nsvci 12
  nsvci fr sitea3 dlci 18 nsvci 13
  nsvci fr sitea4 dlci 19 nsvci 14
 nse 2002 <4>
  nsvci fr siteb5 dlci 20 nsvci 15
  nsvci fr siteb6 dlci 21 nsvci 16
 nse 2003 <5>
  nsvc fr sitec7 dlci 22 nsvci 17
  nsvc fr sitec8 dlci 23 nsvci 18
----
<1> a Gb-over-FR bind with the name sitea1
<2> connect the hdlc1 device with the role frnet to sitea1
<3> one NSE (2001) with four NS-VCI (11..14) on sitea1..4 with their respective DLCI
<4> another NSE (2002) with two NS-VCI (15..16) on siteb1..2 with their respective DLCI
<5> another NSE (2003) with two NS-VCI (17..18) on sitec1..2 with their respective DLCI


==== Gb over IP "ip.access style"

The Gb over IP "ip.access style" can be used with a dynamic configuration or with a
static configuration

The static configuration requires to configure all endpoints on the BSS and SGSN.
In contrast the dynamic configuration allows the SGSN to have only a reduced configuration.

===== Gb over IP "ip.access style" dynamic configuration

.Example: Gb over IP/UDP ip.access style dynamic configuration (SGSN)
----
ns
 bind udp ran1 <1>
  listen 10.100.1.1 23000 <2>
  accept-ipaccess <3>
----
<1> create a IP/UDP bind with name ran1
<2> bind to 10.100.1.1:23000
<3> accept unknown BSS of ip.access style

.Example: Gb over IP/UDP "ip.access style" dynamic configuration (GbProxy as BSS)
----
ns
 bind udp ran1 <1>
  listen 10.100.0.1 23000 <2>
 nse 1001 <3>
  nsvc ipa ran1 10.100.1.1 23000 nsvci 1001
----
<1> create a IP/UDP bind with name ran1
<2> bind to 10.100.1.1:23000
<3> accept unknown BSS of ip.access style

NOTE: The OsmoPCU supports ip.access style Gb/NS but doesn't support this vty configuration because
it's receiving the configuration from the BTS/BSC.

===== Gb over IP "ip.access style" static configuration

.Example: Gb over IP/UDP "ip.access style" static configuration (BSS & SGSN)
----
ns
 bind udp ran1 <1>
  listen 10.100.0.1 23000 <2>
 nse 1001 <3>
  nsvc ipa ran1 10.100.1.1 23000 nsvci 1001
----
<1> create a IP/UDP bind with name ran1
<2> bind to 10.100.0.1:23000
<3> NSE 1001 with nsvc 1001 as ip.access style

NOTE: The OsmoPCU supports "ip.access style" Gb/NS but doesn't support this vty configuration because
it's receiving the configuration from the BTS/BSC.


==== Gb over IP 3GPP static configuration

A static IP/UDP configuration without SNS as specified by 3GPP 48.016.

.Example: Gb over IP/UDP static configuration BSS/SGSN
----
ns
 bind udp ran1 <1>
  listen 10.100.0.1 23000 <2>
 nse 1001 <3>
  nsvc udp ran1 10.100.1.1 23000 signalling-weight 2 data-weight 2
  nsvc udp ran1 10.100.1.2 23000 <4>
----
<1> create a IP/UDP bind with name ran1
<2> bind to 10.100.0.1:23000
<3> add NSE 1001 with 2 NSVC
<4> short configuration with default signalling and data weight of 1

==== Gb over IP 3GPP auto configuration as BSS

IP/UDP auto-configuration with initial endpoints to an SGSN.
The auto-configuration will use the first bind to connect to the
first endpoint. If this fails Osmocom will iterate over all endpoints and binds to find
a working combination.

.Example: Gb over IP/UDP auto-configuration as BSS
----
ns
 bind udp ran1 <1>
  listen 10.100.0.1 23000 <2>
 bind udp ran2
  listen 10.100.0.2 23000
 bind udp ran3
  listen 10.100.0.3 23000
 nse 1001 <3>
  ip-sns-bind ran1 <4>
  ip-sns-bind ran2
  ip-sns-remote 10.100.1.1 23000 <5>
  ip-sns-remote 10.100.1.2 23000
----
<1> create a IP/UDP bind with name ran1
<2> bind to 10.100.0.1:23000
<3> add NSE 1001 with 2 initial SNS endpoints
<4> add ran1 to the list of available endpoints
<5> add 10.100.1.1 as initial endpoint


==== Gb/NS Timer configuration

The NS protocol features a number of configurable timers.

.List of configurable NS timers
|===
|tns-block|(un)blocking timer timeout (secs)
|tns-block-retries|(un)blocking timer; number of retries
|tns-reset|reset timer timeout (secs)
|tns-reset-retries|reset timer; number of retries
|tns-test|test timer timeout (secs)
|tns-alive|alive timer timeout (secs)
|tns-alive-retries|alive timer; number of retries
|tsns-prov|SNS provision timeout (secs) used by all SNS auto configuration procedures.
|tsns-size-retries|SNS Size procedure; number of retries
|tsns-config-retries|SNS Config procedure; number of retries
|===

All timer can be configured by vty configuration

.Example of timeouts
----
ns
 timer tns-block 3
 timer tns-block-retries 3
 timer tns-reset 3
 timer tns-reset-retries 3
 timer tns-test 30
 timer tns-alive 3
 timer tns-alive-retries 10
 timer tsns-prov 10
 timer tsns-size-retries 3
 timer tsns-config-retries 3
----

// FIXME: ladder diagrams for every timer

=== Gb/NS maintenance

This section describes common maintenance procedures.

[[ns2-nse-states]]
==== NSE states

A NSE can have the following states:

.NSE states
* ALIVE
* DEAD

For FR, IPA: The NSE is ALIVE if there is at least one NSVC in state UNBLOCKED.
For IP-SNS/UDP: The NSE is ALIVE if there is at least one NSVC ALIVE and the sum of all ALIVE NSVCs signalling weights > 0 and data weights > 0.

The state of the NSE is shown by vty.

.show ns
----
GbProxy# show ns nsei 1234
NSEI 01234: UDP, DEAD <1>
 FSM Instance Name: 'GPRS-NS2-SNS-BSS(NSE01234-SNS)[0x6120000012a0]', ID: 'NSE01234-SNS'
  Log-Level: 'DEBUG', State: 'BSS_SIZE'
  Timer: 1
 Maximum number of remote  NS-VCs: 8192, IPv4 Endpoints: 8192, IPv6 Endpoints: 8192
  1 NS-VC:
   NSVCI none: DISABLED DYNAMIC data_weight=1 sig_weight=1 udp)[127.0.0.1]:23000<>[127.0.0.1]:22000
----
<1> NSE state

==== NSVC states

A NSVC can have the following states:

.nsvc states
[options="header"]
|=========================================================
| State | transport UNITDATA | Description

| DISABLED	   | No   | Either the transport layer is unavailable (FR) or this NSVC is currently used by IP-SNS dynamic configuration.
| RESET	           | No   | Sending out RESET PDU and awaiting data.
| BLOCKED          | No*  | The NSVC has been BLOCKED. * see 3GPP TS 48.016 § 7.2 exception
| UNBLOCKED/ALIVE  | Yes  | The NSVC transport UNITDATA.
| RECOVERING       | No   | The NSVC test procedure timed out. NSVC type is a IP-SNS which don't use RESET/BLOCK/UNBLOCK.

|=========================================================

[[fig-nsvc-states-reset-block]]
.Simplified state diagram for RESET BLOCK UNBLOCK NSVCs
[graphviz]
----
include::gb-ns2-nsvc-states-reset-block.dot[]
----

[[fig-nsvc-states-alive]]
.Simplified state diagram for IP-SNS/UDP
[graphviz]
----
include::gb-ns2-nsvc-states-alive.dot[]
----

==== Show information of a specific NSE

The NSE 1234 has been configured for as BSS with IP-SNS configuration.

.show ns on a dynamic configured IP-SNS NSE
----
GbProxy# show ns nsei 1234
NSEI 01234: UDP, DEAD <1>
 FSM Instance Name: 'GPRS-NS2-SNS-BSS(NSE01234-SNS)[0x6120000012a0]', ID: 'NSE01234-SNS'
  Log-Level: 'DEBUG', State: 'BSS_SIZE' <2>
  Timer: 1
 Maximum number of remote  NS-VCs: 8192, IPv4 Endpoints: 8192, IPv6 Endpoints: 8192
  1 NS-VC:
   NSVCI none: DISABLED DYNAMIC data_weight=1 sig_weight=1 udp)[127.0.0.1]:23000<>[127.0.0.1]:22000
----
<1> A UDP NSE. A NSE can be ALIVE or DEAD
<2> The SNS state. CONFIGURED and LOCAL_PROCEDURE are ALIVE states

For description of NSE states see <<ns2-nse-states>>.

.show ns on a frame relay NSE
----
OsmoNSdummy# show ns nsei 02001
NSEI 02001: FR, ALIVE <1>
  4 NS-VC:
   NSVCI 00001: DISABLED PERSIST data_weight=1 sig_weight=1 fr)netif: hdlcnet1 dlci: 16 <2>
   NSVCI 00002: DISABLED PERSIST data_weight=1 sig_weight=1 fr)netif: hdlcnet2 dlci: 17 <3>
   NSVCI 00003: DISABLED PERSIST <4> data_weight=1 sig_weight=1 fr)netif: hdlcnet3 dlci: 18
   NSVCI 00004: DISABLED PERSIST data_weight=1 sig_weight=1 fr)netif: hdlcnet4 dlci: 19
----
<1> A FR NSE. A NSE can be ALIVE or DEAD
<2> An unblocked NS-VC will be used for data and signalling. data and signalling weight are only relevant for UDP NSVC.
<3> NSVC is still blocked.
<4> A PERSIST NSVC is a configured via VTY.

==== Blocking a NSVC

.how to block a single NSVC
----
OsmoNSdummy# show ns nsei 01234
NSEI 01234: UDP, ALIVE since 0d 0h 41m 6s
  2 NS-VC:
   NSVCI 01234: UNBLOCKED PERSIST udp)[127.0.0.1]:23000\<1234>[127.0.0.1]:22000 ALIVE since 0d 0h 2m 36s
   NSVCI 01235: UNBLOCKED PERSIST udp)[127.0.0.1]:23001\<1235>[127.0.0.1]:22001 ALIVE since 0d 0h 41m 6s

OsmoNSdummy# nsvc 1234 block
The NS-VC 01234 will be blocked.
OsmoNSdummy# show ns nsei 01234
NSEI 01234: UDP, ALIVE since 0d 0h 42m 7s
  2 NS-VC:
   NSVCI 01234: BLOCKED PERSIST udp)[127.0.0.1]:23000\<1234>[127.0.0.1]:22000 DEAD since 0d 0h 3m 37s
   NSVCI 01235: UNBLOCKED PERSIST udp)[127.0.0.1]:23001\<1235>[127.0.0.1]:22001 ALIVE since 0d 0h 42m 7s
----
