499 lines
16 KiB
Plaintext
499 lines
16 KiB
Plaintext
== 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 constrast 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
|
|
----
|