Configuring the ipaccess nano3G » History » Revision 10
Revision 9 (roox, 03/04/2017 08:01 PM) → Revision 10/39 (roox, 03/06/2017 12:52 PM)
{{>toc}}
h1. Configuring the ip.access nano3G
h2. IP address
The ip.access nano3G will obtain an IP address from the DHCP server in your network.
You can look it up there or watch wireshark, filtering on 'BOOTP' while the nano3G starts up.
For this text, let's assume the IP address it obtained is 192.168.0.124.
h2. Initial Config
Once off, configure:
* the MCC + MNC,
* the UARFCN (i.e. the frequencies to transceive on) and
* the LAC and RAC.
You can do this on the _dmi_ console reachable by telnet:
<pre>
telnet 192.168.0.124 8090
dmi>
</pre>
On the dmi, enter commands like these:
<pre>
# PLMN Id == MCC + MNC
set mcc="901"
set mnc="98"
# [uarfcnDownlink, 1900 MHz band], [scramblingCode], [dummyCellId]
set rfParamsCandidateList=({9800, 401, 1})
# [lac], [rac]
set lacRacCandidateList=({10422, (99)})
</pre>
These settings persist across nano3G power down.
h2. Starting Operation
Every time you boot the nano3G, you need to
* set the IP address the nano3G will find the HNB-GW at.
* 2061 = set cell parameters
* 1216 = unlock ap
* activate HNB-GW connection
* set csg to open access so that any IMSI can register
Enter the _dmi_...
<pre>
telnet 192.168.0.124 8090
dmi>
</pre>
...and issue commands like:
<pre>
set hnbGwAddress="192.168.0.132"
action 2061
action 1216
action establishPermanentHnbGwConnection
set csgAccessMode=CSG_ACCESS_MODE_OPEN_ACCESS
</pre>
h2. SSH Access
The nano3G come with a root password of 'newsys':
<pre>
ssh root@192.168.0.124
password: newsys
</pre>
In case you are using a recent version of the OpenSSH-client you'll get the following error message while trying to connect:
_Unable to negotiate with 192.168.0.124 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1_
Starting with OpenSSH version 7.0 support for the 1024-bit diffie-hellman-group1-sha1 key exchange was disabled by default at run-time.
Use the following to connect to your nano3G in this case.
<pre>
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@192.168.0.124
</pre>
h2. NTP
Be sure that the nano3G is able to resolve the DNS record _0.ipaccess.pool.ntp.org_ and can connect the the corresponding NTP servers.
Without syncronized NTP the nano3G does not bring up the TRX and it even do not try to connect to the hnbGw.
h2. Logging
When logged in via SSH, you can view the live logging here:
<pre>
ls /tmp/iapclogs/trace_*.log
</pre>
h2. Closed Mode
You can also set csgAccessMode to closed and allow only specific IMSIs:
<pre>
set csgAccessMode=CSG_ACCESS_MODE_CLOSED_ACCESS
# IMSI, 1:allowed/2:not allowed, phone number (only for "Closed Access")
set accessControlList = ({"001010123456015", 1, "81084"},{"001010123456025", 2, "81025"})
</pre>
(The phone number is actually not relevant)
h1. Peculiarities and Tips
h2. UE Register
The nano3G apparently passes the same identity received from the UE through to
the HNBAP UE Register Request message. This means that when the UE sends a
TMSI, the UE Register Request received by osmo-hnbgw contains no IMSI.
In this scenario, the problem is that Paging apparently does not (always) work.
So even though we have working code that allows HNBAP registration with
a TMSI, that means that you can't (always) reach the UE from the CN.
This is not always the case, sometimes the nano3G can well page UEs that have
registered by TMSI. Vague idea: it may be that it needs to have seen the IMSI
once after power-cycling, e.g. after a closed-mode registration, and then
TMSI registration will not harm Paging. (TODO: clarify this)
The VTY configuration option to allow TMSI-only attaching to HNBGW, which
possibly helps to shorten your dev cycle but may harm paging, is:
<pre>
hnbgw
iuh
hnbap-allow-tmsi 1
</pre>
Legacy workaround: connect the phone to a different network between retries (being
rejected suffices). That causes the UE to discard its TMSI and then use the IMSI
for the next registration.
A closed csgAccess with explicit IMSIs could help here to enforce that a UE
indeed sends its IMSI to the nano3G and hence Paging should work.
See also #1924.
h2. id-Reset
The nano3G seems to *not* send an id-Reset message upon connecting to the HNB-GW.
h2. Location Update failure due to timeout
If a UE seems to connect successfully at first but fails by timeout because the final
"TMSI Reallocation Complete" message is missing, this might be due to misconfiguration:
the CN is sending the wrong LAC or the PLMN-ID (NCC/MNC) is configured wrongly.
This might be confusing in the sense that a complete LU worked once but not after that;
GMM Attach may be successful; Security Mode Commands succeed; and so forth.
Still the solution might be simply to fix the mobile network code in the osmo-msc.cfg.
h2. RAB Assignment needs IuUP ACK Initialization
IuCS uses UP encapsulated in RTP. The UP starts off by sending an Initialization, replied
upon by an ACK Initialization.
The nano3G seems to not reply with an ACK when it receives an IuUP Initialization frame.
Thus it is not possible to merely echo its own RTP packets back to itself; instead, the
first RTP frame received from the nano3G (that is an IuUP Initialization) can be changed
to an ACK Initialization by writing 0xe4 to the first payload byte. Sending this back to
the nano3G then results in successful RAB Assignment.
(With the SysmoCell5000, echoing its own Initialization back to itself results in an ACK
being sent, which we can also echo back to itself, so mere echoing works there.)
