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