History

« Previous - Version 48/101 (diff) - Next » - Current version
Thomas Tsou, 06/01/2011 02:00 am

OpenBTS: USRP E100

General Information

Due to constrained resources of an embedded system, OpenBTS on the E100 requires 52 MHz clocking and the use of the 52 MHz transceiver implementation. 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 - 2 handsets or less - over extended durations (24 hours) on all four GSM frequency bands.

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

  • Root file system
    (to be posted)

Installing Images

The following instructions apply to installing images on the SD card in a Linux environment. 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.

$ 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-r0-usrp-e1xx.bin uImage

Erase the existing root filesystem. Be careful with this step for obvious reasons.

$ 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

$ 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 --with-uhd 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 band and frequency (default values shown). Please see OpenBTSMS_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).

# 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 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

Start the Asterisk server

$ asterisk

Start OpenBTS

$ ./OpenBTS

An echo server is setup by default 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

Dial the number on an associated handset to run the test. Please see OpenBTSMS_Camping for camping information.

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 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.

Additional Information