History

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; though not GSM compliant, generally no external clocking is necessary for basic testing and non-carrier grade applications.

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 and the performance page for more information. Work on ARM SIMD optimization and C64x DSP acceleration is in progress, though no release date is available at this time.

There are multiple ways to setup an OpenBTS environment on the E100. OpenBTS has a small number of dependent packages, which are already included in the file system image shipped with the E100. Alternatively, a cross-compile environment can be setup using OpenEmbedded,.

Compiling on the E100 device using the official file system image from Ettus Research is recommended for the majority of users and developers not interested in setting up a cross-compile environment.

Dependencies

Required packages for OpenBTS that are not included on the Ettus file system image are subversion and libosip2. Both packages can be installed using opkg.

opkg update
opkg install libosip2-dev subversion

Download

Obtain the source code from the official OpenBTS P2.8 project site

svn co http://wush.net/svn/range/software/public

Build

Follow standard build instructions, however, note that special compiler options specific to ARM processor optimizations are required.

$ autoreconf -i
$ ./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

After running 'autoreconf', the following version dependent error may be displayed, which can be safely ignored.

Can't locate Autom4te/ChannelDefs.pm in @INC
...
autoreconf: gnu-configize failed with exit status: 2

Configure

Follow standard configuration instructions.

Be sure to create the Subscriber Registry.

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. The Asterisk server is started automatically at startup.

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

On the E100, the transceiver may take longer to start than expected by OpenBTS. It is recommended that the transceiver load delay be increased. Otherwise, OpenBTS may respond with the message "assuming TRX is dead" and exit. If this occurs, the existing transceiver instance will still be running and prevent subsequent UHD device access.

To exit an existing transceiver process.

pkill transceiver

Patch to increase the transceiver load wait time.

diff --git a/apps/OpenBTS.cpp b/apps/OpenBTS.cpp
index ff215bf..790668d 100644
--- a/apps/OpenBTS.cpp
+++ b/apps/OpenBTS.cpp
@@ -170,7 +170,7 @@ int main(int argc, char *argv[])

      // Start the transceiver interface.
      // Sleep long enough for the USRP to bootload.
-       sleep(5);
+       sleep(8);
      gTRX.start();

      // Set up the interface to the radio.

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.

Additional Information