OsmoBSCNAT » History » Version 7
laforge, 02/19/2016 10:48 PM
add graphviz
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 | OpenBSC1->bsc_nat [ label="A/IP" ]; |
||
22 | OpenBSC2->bsc_nat [ label="A/IP" ]; |
||
23 | bsc_nat->MSC [ label="A/IP" ]; |
||
24 | nanobts2 [ label = "BTS 1" ]; |
||
25 | nanobts1 [ label = "BTS 2" ]; |
||
26 | nanobts3 [ label = "BTS 3" ]; |
||
27 | nanobts4 [ label = "BTS 4" ]; |
||
28 | OpenBSC1 [ label = "OpenBSC 1" ]; |
||
29 | OpenBSC2 [ label = "OpenBSC 2" ]; |
||
30 | } |
||
31 | }}} |
||
32 | 4 | === Design === |
|
33 | ==== USSD Bypass ==== |
||
34 | We want to implement certain USSD messages ourselves, the MSC does not provide an extension |
||
35 | API so it must be done inside the NAT. On ther other hand we do not want to have complicated code |
||
36 | inside the NAT, the development of new features should not require a restart of the NAT. This means |
||
37 | we will have a simple bypass that detects USSD messages that we want to handle and then forwards |
||
38 | them to an external process. To begin with we will have a static decision making, which will be turned |
||
39 | into more dynamic pattern matching. |
||
40 | |||
41 | |||
42 | ===== Implementation in the NAT ===== |
||
43 | The difficulty is the management of the SCCP Connection. In case of a USSD operation as part of a |
||
44 | SMS or as a voice call, we should hope that sending the response arrives before the MSC is sending |
||
45 | the connection release. If the Connection is created with the intention of USSD we will have to take |
||
46 | over the connection and close it on the MSC side. It might show that this approach is tricky and we |
||
47 | might need better handling on the connection close. |
||
48 | |||
49 | 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) |
|
50 | * ~~Keep track of the Connection Type, identify SS requests in the CM Service Request.~~ (done) |
||
51 | 5 | * Listen on a port for incoming USSD Bypass connections. We will use the IPA protocol, with one extra stream identifier for control messages. |
|
52 | * 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. |