Cellular Network Infrastructure » Core Network (CN) » osmo-gbproxy

[[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.