Early on in the design of UmTRX it was decided that it would be a dual-channel platform, with this being identified as supporting many target use cases and operator requirements, including:
- dual-band operation, e.g. 1800MHz for local coverage and 900MHz for longer distance
- road coverage, with a dedicated BTS and narrow beam antenna facing in each direction
- two operators on a single system, e.g. one public and one private network
Not to mention that the capacity afforded by two carriers also happens to be the sweetspot for many villages and rural installations.
Given that making a single channel system which meets GSM specifications is sufficient a challenge in itself, the approach favoured was a dual-channel platform comprised of two completely independant transceivers — rather than two carriers with one transceiver and DSP tuning.
At the present time UmTRX is the only truly dual-channel transceiver that is fully compatible with the Osmocom GSM stack. There are some platforms which offer the ability to support two carriers with a single radio, but these are limited by the bandwidth of the transceiver and channels must be in the same band and cannot be spaced too far apart.
In this post we take a look at how it’s possible to run two separate GSM BTS instances with a single UmTRX. Which is to say, two independent base stations with only one UmTRX transceiver board, or commercial base station hardware that is based on this, such as the UmSITE product line.
Note that while a single BTS together with UmTRX can also be configured to use both channels — i.e. as a BTS equipped with dual-TRX — this is different as there is only a single BTS instance, with both TRX configured for the same band and connecting to a common BSC and network.
The hardware setup used in testing is quite simple, with a UmTRX connected to a HP Microserver running Ubuntu 14.04.2 and the Osmocom software. The TX ports for channels 1 and 2 were connected to an Agilent E4406A VSA Transmitter Tester and an ISO-TECH ISA 830 TG spectrum analyser.
Build tools and packaged dependencies were installed first via apt-get:
$ sudo apt-get install python-software-properties build-essential cmake libtool autoconf autotools-dev pkg-config git libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev sqlite3 libdbi-dev libdbd-sqlite3 libncurses5-dev libpcsclite-dev libusb-1.0-0-dev
The base UHD driver was installed next and packages with module support compiled-in are available via the Pothosware PPA, which can be added with:
$ sudo add-apt-repository ppa:guruofquality/pothos
Following which the Apt cache is updated and UHD can be installed, along with the Boost development files which are required in order to build the UmTRX module for UHD:
$ sudo apt-get update $ sudo apt-get install uhd libboost1.54-all-dev
The UHD-Fairwave sources were cloned and built next:
$ git clone https://github.com/fairwaves/UHD-Fairwaves.git $ cd UHD-Fairwaves/host $ mkdir build $ cd build $ cmake ../ $ make
The UmTRX driver module can then be installed simply via “sudo make install”, else packaged as a Debian package via cpack. For more details see the Driver page.
The Osmocom software is installed by cloning the sources, creating a build directory, entering this and running cmake, followed by configure and make etc. Rather than detail all these individual steps for each component in the software stack, just the required git branches along with any configuration options are noted here. See the linked wiki pages/sources for more details.
The following Osmocom libraries are required:
The master development branch should be used for each.
$ ./configure --enable-trx
At the time of writing multi-BTS functionality has not been integrated into the OsmoBTS main development branch, and so the software for the second OsmoBTS instance must be built from the achemeris/2sector branch. Once again, TRX hardware needs to be enabled, but this build of OsmoBTS should be installed to a different location from the first. For example, by using:
$ ./configure --prefix=/usr/local/special/2sector --enable-trx
Once the OsmoBTS and OsmoTRX code to support multi-BTS configurations has been tidied up, this functionality will be available via the fairwaves/master branches of each.
The configuration used was based on the multi-BTS with handover example, with one major difference: each BTS instance must be configured to have only a single TRX, both in the OsmoBTS configurations and the OpenBSC NITB configuration sections for these. In our example it was decided to put BTS 0 on 1800MHz and BTS 1 on 900MHz.
So for BTS 0 the first 5 lines of configuration were:
bts 0 band DCS1800 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp bind-ip 127.0.0.1
And with BTS 1 the first 5 lines were:
bts 0 band GSM900 ipa unit-id 1802 0 oml remote-ip 127.0.0.1 rtp bind-ip 127.0.0.1
Note the use of different values for ipa unit-id.
The OpenBSC NITB configuration (open-bsc.cfg) used was based on the multi-BTS one, with the main difference being to remove the trx 1 config sections from bts 0 and bts 1. The first BTS was put on ARFCN 540, which has a downlink at 1810.8MHz, with the second BTS on ARFCN 63, which has a downlink frequency of 947.6MHz.
The OpenBSC network-in-the-box software was started first with:
$ osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
Followed by the first BTS.
$ osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-0.cfg
And then the second BTS, which was installed to a non-standard location:
$ /usr/local/special/2sector/bin/osmobts-trx -t 1 osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-1.cfg
For obvious reasons each started with only one TRX.
Next the transceiver was started with two channels.
$ sudo osmo-trx -c 2
Note that the above screenshots were taken after everything had been started up.
With our two BTS network started we could then see that we had carriers on the expected ARFCNs.
So there we have it — you can now run two independent BTS instances with a single UmTRX board!