Project

General

Profile

Configuring the ipaccess nano3G » History » Revision 34

Revision 33 (neels, 12/14/2018 02:06 PM) → Revision 34/39 (neels, 08/07/2019 11:38 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. Ways to find out: 

 * Run @abisip-find@ (currently in the osmo-bsc.git repository), which should find the nano3G (despite no Abis interface being present). Find the @abisip-find@ output matching the MAC address printed on the sticker next to the power jack. 
 * Watch wireshark, filtering on 'BOOTP' while the nano3G starts up. 
 * Look it up in your DHCP server's list of leases. 

 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 (max. 256) 
 * the Cell ID composed by RNC (12 bits) and HNB C-ID (16 bits) 

 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="70" 

 # [uarfcnDownlink, 1900 MHz band], [scramblingCode], [dummyCellId] 
 set rfParamsCandidateList=({9800, 401, 1}) 

 # [lac], [rac] 
 set lacRacCandidateList=({10422, (99)}) 

 # cellid == RNCID<<16+HNBCID 
 set hnbCId=1 
 set rncIdentity=0 

 </pre> 

 These settings persist across nano3G power down. 

 *All of the above settings require a reboot of the nano3G to take effect.* 

 h2. After Every Boot: 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> 

 It is also possible to change the downlink power for the nano3G. This value is reset after the nano3G reboots and after changing the value the connection to the hnbgw needs to be reestablished before the change will become active. 

 The dmi attribute needed to set is maximumTotalWidebandTransmitPower 

 <pre> 
 dmi> set maximumTotalWidebandTransmitPower = 0 
 </pre> 

 The default value is 70 and a change of +/-10 seems to affect the output power by about 1dBm. 
 It is not possible to set the attribute to a negative value and setting it to something larger than the default should be done carefully 

 In our tests we were able to measure a tx power output of -6.5dBm for 1960MHz/UARFCN9800 with the attribute set to the lowest value (0) and 0dBm, with the default value of 70. 

 


 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. 
 Furthermore, the ciphers supported by the nano3G may be disabled by default. To enable both manually: 
 <pre> 
 ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc root@192.168.0.124 
 </pre> 

 or in ~/.ssh/config: 

 <pre> 
 Host nano3g 
 Hostname 192.168.0.124 
 User root 
 KexAlgorithms +diffie-hellman-group1-sha1 
 Ciphers aes128-cbc 
 </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. 

 A workaround is to edit the @/etc/hosts@ file on the nano3G (via SSH) and add an entry to resolve 0.ipaccess.pool.ntp.org to your local NTP server's IP address (which requires re-mounting the root file system in read-write mode...). 

 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) 

 h2. Neighbour Cells 

 If you have multiple cells running you can add the other to the neighbouring cell list over dmi. 

 <pre> 
 set neighbourListPopulation=STATIC_ONLY 
 # ({band:ENUM, dlUarfcn:INT, scramblingCode:INT, mcc:STRING, mnc:STRING, lac:INT, rac:INT, rncId:INT, cellId:INT, qQualMin:INT, qRxlevMin:INT, txDiversityIndicator:ENUM, primaryCpichTxPower:INT, hcsPriority:INT, qHcs:INT, deltaQhcs:INT}, ...) 
 set staticUmtsNeighbourList_001=({UMTS_BAND_2, 9800, 401, "262", "42", 10422, 99, 0, 1, -24, -119, TX_DIVERSITY_DISABLED, -10, 0, 0, -5},) 
 </pre> 

 h1. Peculiarities and Tips 

 h2. Exiting the dmi while keeping it alive 

 When you exit the dmi telnet by hitting Ctrl-C, it will not be available anymore until you reboot the nano3G. 
 Every connection attempt will then end in 

 <pre> 
 dmi> Connection closed by foreign host. 
 </pre> 

 However, if you end your session by the telnet escape character and quitting, the dmi remains open for further connections. Usually that means: hit Ctrl-] (Ctrl and closing square brace) and then enter 'quit': 

 <pre> 
 dmi> ^] 
 telnet> quit 
 </pre> 

 If the telnet interface for dmi is closed (after you quit it), you can still issue commands using the [[Configuring_the_ipaccess_nano3G#SSH-Access|console]] (here to close the connection to the HNB-GW) 
 <pre> 
 /opt/ipaccess/DMI/ipa-dmi -c 'action terminatePermanentHnbGwConnection' 
 </pre> 

 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 [[Configuring the ipaccess nano3G#Closed-Mode|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.) 

 A hack to make the nano3G work is currently on the "3G master" (the vlr_3G branch), 
 because it does not seem to harm other femto cells: the commit's summary is 
 "mgcp: hack RAB success from nano3G: patch first RTP payload", see "cgit":http://git.osmocom.org/openbsc/log/?h=vlr_3G. 

 See also #1712#note-21 and the following two comments. 

 h2. There is no DMI interface and the device restarts every 5 minutes 

 The ssh should still work. One of many daemons might not been started. This happens usually when a daemon is using a .cfg which is meant for another version. 
 Removing the configuration helps, because every daemon have a default configuration. 

 **cat /tmp/consoleLog** shows what happened! <pre>grep FAILURE /tmp/consoleLog</pre> 

 The configuration files are located under **/var/ipaccess/config_bank_2** 


 h2. Phone is registered, but is usually not receiving any SMS / voice calls 

 In open access mode, it seems the nano3G sometimes fails to page a phone -- it looks like it didn't store the subscriber's IMSI. Try to register the phone that should receive a call to a different network (being rejected suffices, just to get the TMSI out of the phone's state) and then re-register to the hNodeB. 

 It may also help to set the nano3G to closed access and indicate your IMSI as one of the allowed subscribers.
Add picture from clipboard (Maximum size: 48.8 MB)