History

« Previous - Version 80/101 (diff) - Next » - Current version
Thomas Tsou, 06/02/2011 10:59 pm

OpenBTS: USRP E100

General Information

OpenBTS on the E100 requires 52 MHz clocking and the use of the 52 MHz transceiver implementation due to constrained resources of an embedded system. The E100 master clock rate is configurable through the UHD driver interface and requires no hardware modifications for use with OpenBTS. The E100 includes a TCXO that keeps the master clock and RF signals within a couple of parts per million, and no external clocking is necessary.

OpenBTS on the E100 is project undergoing continuing development, but has been repeatedly tested in lightly loaded scenarios - up to two simultaneous voice calls - over extended durations (multiple days) on all four GSM frequency bands. Please see the limitations section for more information.

There are multiple ways to setup an OpenBTS environment on the E100. OpenBTS has a small number of dependent packages, which can be built from source on the device, cross-compiled with OpenEmbedded, or supplied on a pre-built filesystem image.

Using the pre-built images with all dependencies installed and compiling only OpenBTS on the device is strongly recommended for the majority of users and developers not interested in setting up a cross-compile environment.

Prebuilt Images

Installing Images

The following instructions apply to installing images on the SD card in a Linux environment. Please read all instructions and follow them carefully as significant data loss is possible. It is recommended that you backup your SD card contents before proceeding.

Insert the SD card into a card reader. On most Linux distributions, two partitions should mount automatically as "FAT" and "rootfs". If not, the partitions need to be mounted manually. The FAT partition contains required boot contents, which includes the Linux kernel. The rootfs partition contains everything else - kernel modules, installed packages, user information, etc.

$ ls /media/
FAT  rootfs

Install the MLO. Always copy a new MLO over the old one. If not performed properly, the partition will need to be reformatted.

$ cd /media/FAT
$ cp <download location>/MLO MLO

Install the U-Boot image and Linux kernel

$ cp <download location>/u-boot.bin-for-2.6.38 u-boot.bin
$ cp <download location>/uImage-2.6.38-r0a-usrp-e1xx.bin uImage

Erase the existing root filesystem. Be careful with this step and make sure that you are in the correct directory as significant data loss may occur if performed improperly.

$ cd /media/rootfs
$ sudo rm -rf *

Install the new root filesystem

$ sudo tar xvfz <download location>/console-openbts-devel-image-usrp-e1xx.tar.gz .

Unmount the partitions. Note that the umount may take a few minutes to sync before the SD card can be safely removed.

$ umount /media/FAT
$ umount /media/rootfs

At this point, the SD card can be removed and booted on the E100. For general information on starting and communicating with the E100, please refer to the following FAQ entry.

http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-talk-to-the-E100

Download Source

The source code for all UHD devices is identical and no code changes are necessary for the E100.

git clone git://github.com/ttsou/openbts-uhd.git
or
git clone http://github.com/ttsou/openbts-uhd.git

A generated tarball is also available for download.

Build OpenBTS

Compiler options specific to the ARM processor are required.

$ cd openbts-uhd/public-trunk
$ ./bootstrap
$ ./configure CFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3" CXXFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3" 
$ make

Configure

Create a new configuration file from the supplied example.

$ cd apps
$ cp OpenBTS.config.example OpenBTS.config

It is recommended that only error messages be logged due to limited I/O resources.

# The initial global logging level: ERROR, WARN, NOTICE, INFO, DEBUG, DEEPDEBUG
Log.Level ERROR
# Logging levels can also be defined for individual source files.
# This example set shows normal operations in the control layer (L3).
Log.Level.MobilityManagement.cpp ERROR
$optional Log.Level.MobilityManagement.cpp
Log.Level.CallControl.cpp ERROR
$optional Log.Level.CallControl.cpp
Log.Level.RadioResource.cpp ERROR
$optional Log.Level.RadioResource.cpp

Limit the transceiver log to error messages as well.

# TRX logging.
# Logging level.
# IF TRX.Path IS DEFINED, THIS MUST ALSO BE DEFINED.
TRX.LogLevel ERROR

Set the desired GSM band and frequency (default values shown). Please see OpenBTS/MS_Camping for information on frequency selection and related issues.

# Valid band values are 850, 900, 1800, 1900.
GSM.Band 900

# Valid ARFCN range depends on the band.
GSM.ARFCN 51

Select the 52 MHz transceiver.

# Path to transceiver binary
#TRX.Path ../Transceiver/transceiver
TRX.Path ../Transceiver52M/transceiver

Set the desired transmit power attenuation (default values shown). Transmit power in OpenBTS adjusts automatically within the range specified by the minimum and maximum attenuation factors.

# Maximum attenuation (sets MINIMUM power level).
GSM.PowerManager.MaxAttenDB 30
# Minimum attenuation (sets MAXIMUM power level).
GSM.PowerManager.MinAttenDB  7

Antennas

The use of antennas and/or dummy loads is highly recommended. For desktop test setups, a 50 Ω terminator on the transmit side with a receive antenna is sufficient, though most handsets should still be able to connect at limited range when no receive antenna is present. Generally speaking, operating a radio transmitter with no load is not recommended.

Dummy loads can be purchased from a RF parts supplier, or you can make your own.

Testing

By default Asterisk includes an echo server that can be used to test basic operation of OpenBTS. No modifications to Asterisk configuration files are necessary for the test.

Start the Asterisk server

$ asterisk

Start OpenBTS

$ ./OpenBTS

The echo server is setup in Asterisk on extension "600". See the file /etc/asterisk/extensions.conf for details.

;
; Create an extension, 600, for evaluating echo latency.
;
exten => 600,1,Playback(demo-echotest)  ; Let them know what's going on
exten => 600,n,Echo                     ; Do the echo test
exten => 600,n,Playback(demo-echodone)  ; Let them know it's over
exten => 600,n,Goto(s,6)                ; Start over

For the test to work, a handset will need to be associated with the BTS. When this occurs, the handset will receive a text message from OpenBTS.

Often times this is the most unpredictable aspect of OpenBTS testing as the decision to connect to the BTS is made, ultimately, by the handset. The BTS cannot force the handset to switch over, but can provide an accommodative environment. If there are difficulties in associating, make sure that the handset supports the GSM band of operation and see OpenBTS/MS_Camping for additional information.

Dial the extension on an associated handset to run the echo test.

Known Issues

  • Occasionally, the following message may display on the terminal. These messages can be disregarded.
[  285.306701] omap_device: omap_i2c.1: new worst case activate latency 0: 793457
  • Adding a second call may introduce additional voice delay. This is a reaction to increased processor load.
  • The current distributed image does not include time zone information and the E100 will default to UTC.

Limitations

Currently, OpenBTS on the E100 will support up to two simultaneous calls. Basic testing with OProfile reveals that, with two connected handsets, the transceiver consumes roughly three times that of OpenBTS. Asterisk is negligible in comparison.

Most of the operations in the transceiver are using floating point operations, so this behaviour is not too surprising. The developers are currently looking at ARM NEON optimizations of various operations along with using the available DSP in the longer term. Contributions from any developers with experience in this area are certainly welcome.

Also, with limited resources, a high level of I/O may be disruptive to OpenBTS operation causing underruns - reported by 'U' - or other errors. Thus, it is recommended that logging (both global and transceiver) be limited to lower verbosities - ERROR or NOTICE - unless explicitly needed.

Additional Information