PageOutline = osmo-gbproxy design spec =

NS protocol handling

The Gb gateway terminates all the NS-VC's from the BSS, as well as the
NS-VC to the SGSN.

Most NS PDU types are for NS link management only and thus will only
have relevance for the specific link. No forwarding/routing is
required.

Only the NS-UNITDATA messages containing the BSSGP payload will need to
be forwarded between downlink and uplink NS-VCs and vice-versa.

BSSGP

As most BSSGP messages indicate the PTP BVCI in the NS UNIT DATA header,
the PTP BVCI can be used to map those messages.

However, some of the BSSGP messages are destined for the so-called
signalling functional entity, which has the BVCI 0.

Since the Gb gateway masquerades the existance of many signalling
functional entities behind just one, it needs to somehow route the
BVCI 0 messages from the SGSN to the correct BSS.

=== Handling of SIGNALLING PDUs ===

All of the PDU types below are sent on the SIGNALLING BVC, i.e. on
BVCI=0. As such, if those messages are sent by the SGSN, the gateway
does not immediately know to which BSS to send the message to.

Thus, some message-specific special processing is needed in order to
route the PDU correctly.

The following complete list of SIGNALLING PDUs is taken from Table 5.4
of GSM TS 08.18.

==== PAGING_PS / PAGING_CS ====

The message contains one (and only one) of the following IEs: * BVCI (11.3.6) * Location Area (11.3.17) * Routeing Area (11.3.31) * BSS Area Indication (11.3.3)

If the BVCI is given, we can simply look-up the BSS that uses this BVCI
for its PTP service, and then send the current message to BVCI 0 of that
BSS.

In all other cases, the gateway needs to iterate over a local list of
all BSS in order to determine which BSS is applicable. THere may be
multiple BSS that each need a copy of the PAGING PS message.

=== SUSPEND ===

Is sent from MS -> BSS -> SGSN, thus no processing needed.

If multiple BSS per routeing area are desired, the RA + TLLI tuple needs
to be stored for inverse mapping of RESUME ACK / NACK.

=== SUSPEND ACK / NACK ===

The message contains the Routeing area of the BSS. As long as there is
only one BSS in each routeing area, we can safely lookup the BSS and
forward the message there

LIMITATION: Only one BSS per routeing area

If multiple BSS per routeing area are desired, the RA + TLLI tuple
information gathered from snooping the SUSPEND messages needs to be used
for the reverse mapping. (This is not implemented so far)

=== RESUME ===

Is sent from MS -> BSS -> SGSN, thus no processing needed.

If multiple BSS per routeing area are desired, the RA + TLLI tuple needs
to be stored for inverse mapping of RESUME ACK / NACK.

=== RESUME ACK / NACK ===

The message contains the Routeing area of the BSS. As long as there is
only one BSS in each routeing area, we can safely lookup the BSS and
forward the message there

LIMITATION: Only one BSS per routeing area

If multiple BSS per routeing area are desired, the RA + TLLI tuple
information gathered from snooping the RESUME messages needs to be used
for the reverse mapping. (This is not implemented so far)

=== FLUSH LL ===

The message contains the ''old BVCI'' as IE, so the mapping to the target
BSS can be made based on that BVCI

=== FLUSH LL ACK ===

Is sent from BSS -> SGSN, thus no processing needed.

=== BVC BLOCK ===

Is sent from BSS -> SGSN, thus no processing needed.

=== BVC BLOCK ACK ===

Contains the BVCI as IE, so the mapping to the target BSS can be made on
that BVCI.

=== BVC UNBLOCK ===

Is sent from BSS -> SGSN, thus no processing needed.

=== BVC UNBLOCK ACK ===

Contains the BVCI as IE, so the mapping to the target BSS can be made on
that BVCI.

=== BVC RESET ===

Contains the BVCI as IE, so the mapping to the target BSS can be made on
that BVCI.

=== BVC RESET ACK ===

Contains the BVCI as IE, so the mapping to the target BSS can be made on
that BVCI.

=== STATUS ===

If sent from BSS to SGSN, no need for modification.

If sent from SGSN to BSS and it includes the conditional BVCI IE, we can
use that to map to the target BSS.

If sent from SGSN to BSS, and it does not include the conditional BVCI
IE, we simply have to drop it.

=== SGSN INVOKE TRACE ===

This message might only contain the PDU type (11.3.26), Trace Type
(11.3.38) and Trace Reference (11.3.37), without any additional information.

It is thus not possible to determine to which BSS the trace request
should be sent. Even with the optional IEs present in the message,
it is still not possible to correctly map the message to the intended
BSS: * Trigger ID (11.3.40) * OMC Id (11.3.23) * Transaction Id (11.3.39)

The only optional IE that could be of assistance is: * Mobile Id (11.3.20)
If we were keeping a IMSI/IMEI/IMEISV map in the gateway, we could map.
But it is a lot of effort for a trace feature

Another option is to forward the SGSN INVOKE TRACE message to all of the
BSS connected to the gateway. It is unclear what impact this might have
e.g. on BSS performance.

At the moment we simply drop all SGSN INVOKE TRACE events and create
a log file entry about each such incident.