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