OsmoBSCNAT » History » Version 12
laforge, 02/20/2016 08:56 PM
1 | 12 | laforge | {{>toc}} |
---|---|---|---|
2 | 11 | h2. BSC NAT/MUX |
|
3 | |||
4 | h3. Introduction |
||
5 | |||
6 | The [[OpenBSC]] NAT is masquerading multiple BSCs behind one. It listens for incoming BSCs on |
||
7 | 3 | port 5000 and connects to a specified MSC. It will forward Paging Requests and MGCP messgaes |
|
8 | 2 | laforge | to the right BSC (if it is connected). Each incoming SCCP connection gets patched with a different |
9 | 3 | Source Reference to avoid any collision between the different BSCs. |
|
10 | 1 | ||
11 | To the network the NAT looks like a real BSC, to the BSC the NAT looks like almost a real MSC. One |
||
12 | 3 | difference is that MGCP messages are not send via UDP but inside the IPA protocol to avoid |
|
13 | any issues with firewalls and such. |
||
14 | 4 | ||
15 | 11 | <pre> |
|
16 | <code class="graphviz"> |
||
17 | 1 | digraph G { |
|
18 | rankdir=LR; |
||
19 | 7 | laforge | nanobts1->OpenBSC1 [ label="Abis/IP" ]; |
20 | nanobts2->OpenBSC1 [ label="Abis/IP" ]; |
||
21 | nanobts3->OpenBSC2 [ label="Abis/IP" ]; |
||
22 | nanobts4->OpenBSC2 [ label="Abis/IP" ]; |
||
23 | BSC1->cellmgr_ng1 [label="A/MTP" ]; |
||
24 | 11 | [[OpenBSC]]1->bsc_nat [ label="A/IP" ]; |
|
25 | [[OpenBSC]]2->bsc_nat [ label="A/IP" ]; |
||
26 | 7 | laforge | cellmgr_ng1->bsc_nat [ label = "A/IP" ]; |
27 | 1 | bsc_nat->MSC [ label="A/IP" ]; |
|
28 | nanobts2 [ label = "BTS 1" ]; |
||
29 | nanobts1 [ label = "BTS 2" ]; |
||
30 | nanobts3 [ label = "BTS 3" ]; |
||
31 | 7 | laforge | nanobts4 [ label = "BTS 4" ]; |
32 | 8 | BSC1 [ label = "Traditional BTS/BSC" ]; |
|
33 | 11 | [[OpenBSC]]1 [ label = "OpenBSC 1" ]; |
|
34 | [[OpenBSC]]2 [ label = "OpenBSC 2" ]; |
||
35 | 7 | laforge | cellmgr_ng1 [ label = "Cellmgr 1" ]; |
36 | 1 | } |
|
37 | </code></pre> |
||
38 | 11 | ||
39 | 12 | laforge | {{child_pages}} |
40 | 11 | ||
41 | h3. Concept |
||
42 | |||
43 | 9 | The bsc_nat is useful when the BSCs of a GSM network are not in the same IP network. The BSC |
|
44 | might be behind a firewall, or the IP is changing, also the ports might be masqueraded. The bsc_nat |
||
45 | 1 | is tunneling the MGCP protocol through the A/IP link to penetrate firewalls and UDP port discovery |
|
46 | for RTP based audio. Being the central part to the GSM network it provides detailed statistics and |
||
47 | other features. |
||
48 | 9 | ||
49 | 1 | ||
50 | 11 | h3. Features |
|
51 | |||
52 | |||
53 | |||
54 | h4. IMSI based access control |
||
55 | |||
56 | 1 | The bsc_nat provides a per MSC and per BSC IMSI filter. The filter works during the Location Updating |
|
57 | 9 | Procedure, the CM Service Request and other places. It allows to exclude IMSIs from certain locations. |
|
58 | |||
59 | 11 | ||
60 | h4. Number rewriting |
||
61 | |||
62 | 9 | The bsc_nat provides a way to rewrite destination numbers based on MNC and MCC of the subscriber. |
|
63 | 1 | ||
64 | 11 | ||
65 | h4. USSD bypass |
||
66 | |||
67 | 9 | The bsc_nat provides a way to forward USSD requests for certain number ranges for subscribers based |
|
68 | on the MNC and MCC to an external process. |
||
69 | |||
70 | 11 | ||
71 | h4. Detailed statistics |
||
72 | |||
73 | 1 | The bsc_nat provides detailed statistics about the traffic of each BSC, the reason for opening the |
|
74 | connection, the number of active connections. |
||
75 | |||
76 | 11 | ||
77 | h4. NAT traversal |
||
78 | |||
79 | 1 | The bsc_nat tunnels MGCP through the A/IP link, the BSC will send a beacon from the source RTP port |
|
80 | to make the external port visible to the NAT. |
||
81 | |||
82 | 11 | ||
83 | h3. Design === |
||
84 | USSD Bypass ==== |
||
85 | 4 | We want to implement certain USSD messages ourselves, the MSC does not provide an extension |
|
86 | API so it must be done inside the NAT. On ther other hand we do not want to have complicated code |
||
87 | inside the NAT, the development of new features should not require a restart of the NAT. This means |
||
88 | we will have a simple bypass that detects USSD messages that we want to handle and then forwards |
||
89 | them to an external process. To begin with we will have a static decision making, which will be turned |
||
90 | into more dynamic pattern matching. |
||
91 | |||
92 | |||
93 | 11 | ||
94 | h5. Implementation in the NAT |
||
95 | |||
96 | 4 | The difficulty is the management of the SCCP Connection. In case of a USSD operation as part of a |
|
97 | SMS or as a voice call, we should hope that sending the response arrives before the MSC is sending |
||
98 | the connection release. If the Connection is created with the intention of USSD we will have to take |
||
99 | over the connection and close it on the MSC side. It might show that this approach is tricky and we |
||
100 | might need better handling on the connection close. |
||
101 | |||
102 | 11 | * -Keep track of the IMSI of every SCCP Connection. The increase in storage size is acceptable right now. We have not started to tune anything in the NAT anyway.- (done) |
|
103 | * -Keep track of the Connection Type, identify SS requests in the CM Service Request.- (done) |
||
104 | * Listen on a port for incoming USSD Bypass connections. We will use the IPA protocol, with one extra stream identifier for control messages. |
||
105 | * Identify USSD request to be forwarded to the MSC, send the IMSI and SCCP references to the bridge so it can start doing its job. |