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