Project

General

Profile

Osmo-gbproxy design » History » Version 2

laforge, 02/19/2016 10:48 PM
gb proxy design spec

1 2 laforge
{{>toc}}
2 1 laforge
3 2 laforge
h1. osmo-gbproxy design spec
4 1 laforge
5 2 laforge
6
7
h2. NS protocol handling
8
9
10 1 laforge
The Gb gateway terminates all the NS-VC's from the BSS, as well as the
11
NS-VC to the SGSN.
12
13
Most NS PDU types are for NS link management only and thus will only
14
have relevance for the specific link.  No forwarding/routing is
15
required.
16
17
Only the NS-UNITDATA messages containing the BSSGP payload will need to
18
be forwarded between downlink and uplink NS-VCs and vice-versa.
19
20
21 2 laforge
h2. BSSGP
22
23
24 1 laforge
As most BSSGP messages indicate the PTP BVCI in the NS UNIT DATA header,
25
the PTP BVCI can be used to map those messages.
26
27
However, some of the BSSGP messages are destined for the so-called
28
signalling functional entity, which has the BVCI 0.
29
30
Since the Gb gateway masquerades the existance of many signalling
31
functional entities behind just one, it needs to somehow route the
32
BVCI 0 messages from the SGSN to the correct BSS.
33
34
35 2 laforge
h3. Handling of SIGNALLING PDUs
36
37
38 1 laforge
All of the PDU types below are sent on the SIGNALLING BVC, i.e. on
39
BVCI=0.  As such, if those messages are sent by the SGSN, the gateway
40
does not immediately know to which BSS to send the message to.
41
42
Thus, some message-specific special processing is needed in order to
43
route the PDU correctly.
44
45
The following complete list of SIGNALLING PDUs is taken from Table 5.4
46
of GSM TS 08.18.
47
48
49 2 laforge
h4. PAGING_PS / PAGING_CS
50
51
52 1 laforge
The message contains one (and only one) of the following IEs:
53 2 laforge
* BVCI (11.3.6)
54
* Location Area (11.3.17)
55
* Routeing Area (11.3.31)
56
* BSS Area Indication (11.3.3)
57 1 laforge
58
If the BVCI is given, we can simply look-up the BSS that uses this BVCI
59
for its PTP service, and then send the current message to BVCI 0 of that
60
BSS.
61
62
In all other cases, the gateway needs to iterate over a local list of
63
all BSS in order to determine which BSS is applicable.  THere may be
64
multiple BSS that each need a copy of the PAGING PS message.
65
66
67 2 laforge
h3. SUSPEND
68
69
70 1 laforge
Is sent from MS -> BSS -> SGSN, thus no processing needed.
71
72
If multiple BSS per routeing area are desired, the RA + TLLI tuple needs
73
to be stored for inverse mapping of RESUME ACK / NACK.
74
75
76 2 laforge
h3. SUSPEND ACK / NACK
77
78
79 1 laforge
The message contains the Routeing area of the BSS.  As long as there is
80
only one BSS in each routeing area, we can safely lookup the BSS and
81
forward the message there
82
83
LIMITATION: Only one BSS per routeing area
84
85
If multiple BSS per routeing area are desired, the RA + TLLI tuple
86
information gathered from snooping the SUSPEND messages needs to be used
87
for the reverse mapping. (This is not implemented so far)
88
89
90 2 laforge
h3. RESUME
91
92
93 1 laforge
Is sent from MS -> BSS -> SGSN, thus no processing needed.
94
95
If multiple BSS per routeing area are desired, the RA + TLLI tuple needs
96
to be stored for inverse mapping of RESUME ACK / NACK.
97
98
99 2 laforge
h3. RESUME ACK / NACK
100
101
102 1 laforge
The message contains the Routeing area of the BSS.  As long as there is
103
only one BSS in each routeing area, we can safely lookup the BSS and
104
forward the message there
105
106
LIMITATION: Only one BSS per routeing area
107
108
If multiple BSS per routeing area are desired, the RA + TLLI tuple
109
information gathered from snooping the RESUME messages needs to be used
110
for the reverse mapping. (This is not implemented so far)
111
112
113 2 laforge
h3. FLUSH LL
114
115
116
The message contains the _old BVCI_ as IE, so the mapping to the target
117 1 laforge
BSS can be made based on that BVCI
118
119
120 2 laforge
h3. FLUSH LL ACK
121
122
123 1 laforge
Is sent from BSS -> SGSN, thus no processing needed.
124
125
126 2 laforge
h3. BVC BLOCK
127
128
129 1 laforge
Is sent from BSS -> SGSN, thus no processing needed.
130
131
132 2 laforge
h3. BVC BLOCK ACK
133
134
135 1 laforge
Contains the BVCI as IE, so the mapping to the target BSS can be made on
136
that BVCI.
137
138
139 2 laforge
h3. BVC UNBLOCK
140
141
142 1 laforge
Is sent from BSS -> SGSN, thus no processing needed.
143
144
145 2 laforge
h3. BVC UNBLOCK ACK
146
147
148 1 laforge
Contains the BVCI as IE, so the mapping to the target BSS can be made on
149
that BVCI.
150
151
152 2 laforge
h3. BVC RESET
153
154
155 1 laforge
Contains the BVCI as IE, so the mapping to the target BSS can be made on
156
that BVCI.
157
158
159 2 laforge
h3. BVC RESET ACK
160
161
162 1 laforge
Contains the BVCI as IE, so the mapping to the target BSS can be made on
163
that BVCI.
164
165
166 2 laforge
h3. STATUS
167
168
169 1 laforge
If sent from BSS to SGSN, no need for modification.
170
171
If sent from SGSN to BSS and it includes the conditional BVCI IE, we can
172
use that to map to the target BSS.
173
174
If sent from SGSN to BSS, and it does not include the conditional BVCI
175
IE, we simply have to drop it.
176
177
178 2 laforge
h3. SGSN INVOKE TRACE
179
180
181 1 laforge
This message might only contain the PDU type (11.3.26), Trace Type
182
(11.3.38) and Trace Reference (11.3.37), without any additional information.
183
184
It is thus not possible to determine to which BSS the trace request
185
should be sent.  Even with the optional IEs present in the message,
186
it is still not possible to correctly map the message to the intended
187
BSS:
188 2 laforge
* Trigger ID (11.3.40)
189
* OMC Id (11.3.23)
190
* Transaction Id (11.3.39)
191 1 laforge
192
The only optional IE that could be of assistance is:
193 2 laforge
* Mobile Id (11.3.20)
194 1 laforge
If we were keeping a IMSI/IMEI/IMEISV map in the gateway, we could map.
195
But it is a lot of effort for a trace feature
196
197
Another option is to forward the SGSN INVOKE TRACE message to all of the
198
BSS connected to the gateway.  It is unclear what impact this might have
199
e.g. on BSS performance.
200
201
At the moment we simply drop all SGSN INVOKE TRACE events and create
202
a log file entry about each such incident.
Add picture from clipboard (Maximum size: 48.8 MB)