Having moved OpenBTS on to a new dedicated server I am pleased to report that all is well again!
I picked up a cheap (£25) HP Compaq DC7100 on eBay and installed Ubuntu 12.04. The build of OpenBTS and UHD went like a dream unlike on Centos 5 where it took ages to sort out the build dependencies.
Now I have no frame errors:
RSSI (Received Signal Strength Indication) figures all look good. I ran the “noise” command in the OpenBTS CLI several times to get the worst (=biggest) value of noise RSSI. It should be a negative value, like -44dB.
The MS RSSI Target should be higher than “noise” by a healthy number usually something like 4-6dB margin. Hence we need to add 4-6dB to the noise RSSI value to get the RSSI level we need to receive phone signal on the BTS without errors. This is called “target RSSI” in OpenBTS and is set with “GSM.Radio.RSSITarget” value in the config. If noise RSSI is -16dB, then you would set target RSSI to -10dB:
OpenBTS> config GSM.Radio.RSSITarget -10
I also ran the “chans” command in the OpenBTS and used the active channel between the mobile station (MS) and the base station (BS) to estimate link quality and tune Rx gain and Tx attenuation.
- TN – Timeslot number
- channel type – The dedicated channel type
- transaction id – The key for the corresponding entry in the transaction table that is currently making use of this channel
- UPFER pct – Uplink frame error rate, as a percentage.
- RSSI dB – Uplink RSSI at the BTS, in dB with respect to full scale
- TXPWR dBm – Current uplink transmitter power (from the MS) in dBm
- TXTA sym – Timing advance in symbol periods
- DNLEV dBm – Downlink RSSI in dBm as measured by the MS
- DNBER pct – Downlink bit error rate, as a percentage
The easiest way to estimate reception quality is to use the “UPFER” value. Zero “UPFER” means good reception, non-zero “UPFER” means errors on UL channel:
A Wireshark capture shows lots of interesting GSMTAP packets captured (analysis of which I will save for another blog post):
Finally an unexpected surprise – an iPhone 5 registered successfully!
Strangely even though I am running an unencrypted GSM network (since encryption is only supported in the commercial “C” release of OpenBTS and it is a pain to configure GSM A5/1 encryption, obtaining SIM cards with a known authentication key / Ki etc. etc.) I did not see the “Unsecured Call” warning introduced in IOS 5 which I had been expecting:
UPDATE: Fairwaves implemented encryption in the open-source version of OpenBTS and it is maintained in a special branch. It has issues with some phones and thus it has not been merged into Fairwaves master branch yet.
It turns out that even if the GSM handset supports indications of the ciphering status of a call, these indications can be disabled by the carrier through settings in the SIM. Most carriers choose to do disable this indication feature. Hence even though the indications sound good in principle, they are often useless in practice!
Happy days. I’ll put a full demo on YouTube soon.