Configuring the ipaccess nano3G » History » Version 6
neels, 02/23/2017 07:19 PM
1 | 2 | neels | {{>toc}} |
---|---|---|---|
2 | 1 | neels | |
3 | 2 | neels | h1. Configuring the ip.access nano3G |
4 | |||
5 | h2. IP address |
||
6 | |||
7 | The ip.access nano3G will obtain an IP address from the DHCP server in your network. |
||
8 | 5 | neels | You can look it up there or watch wireshark, filtering on 'BOOTP' while the nano3G starts up. |
9 | 2 | neels | For this text, let's assume the IP address it obtained is 192.168.0.124. |
10 | |||
11 | h2. Initial Config |
||
12 | |||
13 | Once off, configure: |
||
14 | |||
15 | * the MCC + MNC, |
||
16 | * the UARFCN (i.e. the frequencies to transceive on) and |
||
17 | * the LAC and RAC. |
||
18 | |||
19 | You can do this on the _dmi_ console reachable by telnet: |
||
20 | |||
21 | <pre> |
||
22 | telnet 192.168.0.124 8090 |
||
23 | dmi> |
||
24 | </pre> |
||
25 | |||
26 | On the dmi, enter commands like these: |
||
27 | |||
28 | <pre> |
||
29 | # PLMN Id == MCC + MNC |
||
30 | set mcc="901" |
||
31 | set mnc="98" |
||
32 | |||
33 | # [uarfcnDownlink, 1900 MHz band], [scramblingCode], [dummyCellId] |
||
34 | set rfParamsCandidateList=({9800, 401, 1}) |
||
35 | |||
36 | # [lac], [rac] |
||
37 | set lacRacCandidateList=({10422, (99)}) |
||
38 | </pre> |
||
39 | |||
40 | These settings persist across nano3G power down. |
||
41 | |||
42 | h2. Starting Operation |
||
43 | |||
44 | Every time you boot the nano3G, you need to |
||
45 | |||
46 | * set the IP address the nano3G will find the HNB-GW at. |
||
47 | * 2061 = set cell parameters |
||
48 | * 1216 = unlock ap |
||
49 | * activate HNB-GW connection |
||
50 | * set csg to open access so that any IMSI can register |
||
51 | |||
52 | Enter the _dmi_... |
||
53 | <pre> |
||
54 | telnet 192.168.0.124 8090 |
||
55 | dmi> |
||
56 | </pre> |
||
57 | |||
58 | ...and issue commands like: |
||
59 | |||
60 | <pre> |
||
61 | set hnbGwAddress="192.168.0.132" |
||
62 | action 2061 |
||
63 | action 1216 |
||
64 | action establishPermanentHnbGwConnection |
||
65 | set csgAccessMode=CSG_ACCESS_MODE_OPEN_ACCESS |
||
66 | </pre> |
||
67 | |||
68 | h2. SSH Access |
||
69 | |||
70 | The nano3G come with a root password of 'newsys': |
||
71 | <pre> |
||
72 | ssh root@192.168.0.124 |
||
73 | password: newsys |
||
74 | </pre> |
||
75 | |||
76 | h2. Logging |
||
77 | |||
78 | When logged in via SSH, you can view the live logging here: |
||
79 | <pre> |
||
80 | ls /tmp/iapclogs/trace_*.log |
||
81 | </pre> |
||
82 | |||
83 | h2. Closed Mode |
||
84 | |||
85 | You can also set csgAccessMode to closed and allow only specific IMSIs: |
||
86 | |||
87 | <pre> |
||
88 | 6 | neels | set csgAccessMode=CSG_ACCESS_MODE_CLOSED_ACCESS |
89 | 2 | neels | # IMSI, 1:allowed/2:not allowed, phone number (only for "Closed Access") |
90 | set accessControlList = ({"001010123456015", 1, "81084"},{"001010123456025", 2, "81025"}) |
||
91 | </pre> |
||
92 | |||
93 | (The phone number is actually not relevant) |
||
94 | |||
95 | h1. Peculiarities and Tips |
||
96 | |||
97 | h2. UE Register |
||
98 | |||
99 | The nano3G apparently passes the same identity received from the UE through to |
||
100 | the HNBAP UE Register Request message. This means that when the UE sends a |
||
101 | TMSI, the UE Register Request received by osmo-hnbgw contains no IMSI. |
||
102 | |||
103 | In this scenario, the problem is that Paging apparently does not work. |
||
104 | So even though we have working code that allows HNBAP registration with |
||
105 | a TMSI, that means that you can't reach the UE from the CN. |
||
106 | |||
107 | For completeness sake, the VTY configuration option for this _which you |
||
108 | actually don't really want to enable_ is: |
||
109 | |||
110 | <pre> |
||
111 | hnbgw |
||
112 | iuh |
||
113 | hnbap-allow-tmsi 0 |
||
114 | </pre> |
||
115 | |||
116 | Legacy workaround: connect the phone to a different network between retries (being |
||
117 | rejected suffices). That causes the UE to discard its TMSI and then use the IMSI |
||
118 | for the next registration. |
||
119 | |||
120 | A closed csgAccess with explicit IMSIs could help here to enforce that a UE |
||
121 | indeed sends its IMSI to the nano3G and hence Paging should work (to be verified). |
||
122 | See also #1924. |
||
123 | 3 | neels | |
124 | h2. id-Reset |
||
125 | |||
126 | The nano3G seems to *not* send an id-Reset message upon connecting to the HNB-GW. |
||
127 | |||
128 | h2. Location Update failure due to timeout |
||
129 | |||
130 | If a UE seems to connect successfully at first but fails by timeout because the final |
||
131 | "TMSI Reallocation Complete" message is missing, this might be due to misconfiguration: |
||
132 | the CN is sending the wrong LAC or the PLMN-ID (NCC/MNC) is configured wrongly. |
||
133 | |||
134 | This might be confusing in the sense that a complete LU worked once but not after that; |
||
135 | GMM Attach may be successful; Security Mode Commands succeed; and so forth. |
||
136 | Still the solution might be simply to fix the mobile network code in the osmo-cscn.cfg. |
||
137 | 4 | neels | |
138 | h2. RAB Assignment needs IuUP ACK Initialization |
||
139 | |||
140 | IuCS uses UP encapsulated in RTP. The UP starts off by sending an Initialization, replied |
||
141 | upon by an ACK Initialization. |
||
142 | |||
143 | The nano3G seems to not reply with an ACK when it receives an IuUP Initialization frame. |
||
144 | Thus it is not possible to merely echo its own RTP packets back to itself; instead, the |
||
145 | first RTP frame received from the nano3G (that is an IuUP Initialization) can be changed |
||
146 | to an ACK Initialization by writing 0xe4 to the first payload byte. Sending this back to |
||
147 | the nano3G then results in successful RAB Assignment. |
||
148 | |||
149 | (With the SysmoCell5000, echoing its own Initialization back to itself results in an ACK |
||
150 | being sent, which we can also echo back to itself, so mere echoing works there.) |