Development of an Open-Source GSM Femtocell
and Integrated Core Infrastructure
Thomas Tsou, Thomas Cooper, Robert McGwier, T. Charles Clancy, Jeffrey Reed
Electrical and Computer Engineering
Virginia Tech
{ttsou, tacooper, rwmcgwi, tcc, reedjh}@vt.edu
Abstract—Open source development applied to cellular GSM
technology is a fairly recent, but growing, concept. Another trend
is the continually growing capability of low-power embedded
processors, which makes them increasingly suitable for open
source GSM applications. This paper applies two open source
software packages, OpenBTS and OpenBSC, to an readily
available embedded hardware platform, the Universal Hardware
Radio Peripheral (USRP) E100. The USRP E100 device is a
heterogeneous processor platform designed for software-defined
radio use. The result is an embedded base station that can
be deployed in standalone configuration or as part of a larger
GSM network. A software radio transceiver implementation is
presented that leverages optimized capabilities of all available
processors: a general purpose ARM processor, DSP, and FPGA.
Comparative performance measures are also provided.
I. I NTRODUCTION
The Global System for Mobile (GSM) cellular standard,
having been in existence for nearly two decades, is the most
widely deployed wireless technology in the world. As of July
2012, the number of overall cellular subscriptions worldwide
stands at 5.6 billion with roughly 75% of connections served
by standard GSM [1]. Undoubtedly, third generation networks
and beyond, such as Universal Mobile Telecommunications
System (UMTS) and Long Term Evolution (LTE), are under-
going extraordinary growth and will constitute a significant
market share moving forward. Currently, however, users of
these advanced networks still make up a minority share of
subscribers when examined at a global scale - this is especially
true in many developing regions and conflict zones where sub-
scribers may be restricted by economic or political concerns in
addition to limited availability of high speed networks. While
we can surely expect GSM market share to decline over time,
GSM networks will continue to maintain a large worldwide
presence serving billions of users for the near and indefinite
future.
Given the ubiquity of GSM based products, access to
developmental GSM technology has generally been prohibitive
for most researchers and individuals outside of commercial
wireless industries. The restrictive nature of the technology is
both complex and longstanding; various reasons include regu-
latory access, proprietary licensing, and patent encumbrances
among numerous other concerns. While the state of these and
other related issues continue to evolve within their respective
circles, alternative development paths have recently emerged
from the open source community.
978-1-4673-3/12/$31.00 ©2013 IEEE
In recent years, open source implementations of various
GSM components have been introduced as viable candidates
for cellular system testing, research, and deployment. In open
source development, source code or hardware designs - and
generally many reserved rights - are provided under an open
license that permits nonrestrictive use. Two such open source
GSM examples are OpenBTS [2] and OpenBSC [3] which
implement Base Transceiver Station (BTS) and Base Station
Controller (BSC) functionalities respectively. Together, the
BTS and BSC comprise the Base Station Subsystem (BSS),
which is the combined entity that handles air interface traffic
and signalling between mobile handsets and the GSM core
network.
While typically associated with software, the open source
model also applies to hardware where essential design infor-
mation, such as schematics, firmware, or driver source code,
is made openly available. For example, the Universal Software
Radio Peripheral (USRP) is a well known example of the open
source development model applied to a hardware product.
With products such as the USRP and the general availabil-
ity of low-cost, high performance processing capability, the
often complicated task of procuring dedicated – and gener-
ally restrictive – GSM baseband equipment is substantially
reduced. The combination of easily accessible open source
software and hardware has allowed GSM implementations to
be developed and operational systems constructed in relatively
short periods of time with significantly lower costs compared
to more traditional development paths. With a substantially
lower barrier to entry, open source implementations such as
OpenBTS, OpenBSC, and the USRP have influenced and
supported discussion around critical topics such as mobile
security [4]–[6], rural access [7], [8], privacy and public policy
[9], [10].
Progressing in parallel to the availability of open hardware
is the progressing capability of embedded processors and de-
vices. Low-power and increasingly fast embedded processors
have distinctly driven a new wave of consumer and military
applications in products such as smartphones and military ra-
dios. When combined with open source GSM software, similar
application processors that drive these now ubiquitous prod-
ucts are also capable of supporting unconventional applications
such as embedded base station and network functionality.
The potential effects of easily accessible open source GSM
technology existing in the reduced form factor of embedded

Fig. 1. GSM network architecture
devices is significant. Aforementioned security and privacy
implications are notable, and fundamentaly new applications
are possible. For example, the integration of wireless mesh
network backhaul [11], [12] through low-power embedded
devices is one novel possibility.
This paper describes the development of a deployable GSM
femtocell created using a combination of open source software
and hardware while leveraging the optimized capabilities of an
embedded platform. Specifically, an open source implementa-
tion of the GSM air interface Um [13], OpenBTS, is ported
to an E100 USRP, an embedded heterogeneous processor
platform designed for software-defined radio use. Further-
more, two different network configurations are introduced: a
standalone hybrid Voice over IP (VoIP) approach using only
OpenBTS and a more conventional approach that integrates
OpenBTS with OpenBSC.
The remainder of the paper is organized as follows. Sec-
tion II introduces open source software implementations in the
framework of basic GSM network architecture. The hardware
platform, application partitioning, and interprocessor commu-
nication structure are discussed in Section III. Section IV
describes the physical layer implementation and provides
comparative performance results of the software-defined radio
transceiver. Configuration of OpenBTS in an alternative BSC
configuration mode is discussed in Section V.
II. GSM N ETWORK A RCHITECTURE
A basic GSM network architecture consists of multiple
components as shown in Figure 1. Each cell contains a
Base Transceiver Station (BTS) that provides an Um radio
air interface to multiple Mobile Stations (MS). The regional
functionality and interconnectivity of each BTS is controlled
by a Base Station Controller (BSC) through the Abis interface.
The combination of one or more BTS units combined with a
BSC creates a Base Station Subsystem (BSS), which attaches
to the GSM core network. The core network centers around
the Mobile Switching Center (MSC) and handles routing and
switching between multiple BSC units. Finally, essential user
data is managed through various data storage elements: Au-
thentication Center (AuC), Visitor Location Register (VLR),
Home Location Register (HLR), and Equipment Identity Reg-
ister (EIR).
While the GSM standard specifies that all the aforemen-
tioned elements are present for an operational network, for
many small cell configurations, creating a network with dis-
crete implementations of BTS, BSC, MSC, and a multitude of
other entities is often undesirable due to to cost and practical-
ity. As a result, small scale network installations generally
utilize techniques to reduce the maintenance and overhead
of various network components. For example, functionality
of multiple elements can be integrated into a single package
or, alternatively, the traditional core network can be bypassed
entirely.
A. OpenBTS
The OpenBTS Project implements an independent BTS
that – rather than connecting to a typical BSC and MSC
– interfaces through Session Initiation Protocol (SIP) to a
software private branch exchange (PBX). With this approach,
open source PBX solutions can be used to route mobile and
external connections using a standardized VoIP protocol. For
the software radio air interface, multiple hardware options are
supported with variants from the USRP product line being
the most commonly used. By providing minimally integrated
BSC and MSC functionality and using a software PBX for
switching and calling functions, OpenBTS functions as a
GSM access point that can operate independently without
signalling and control from a core network. Without a standard
Abis connection, however, the hybrid GSM/VoIP solution
lacks certain functionalities of standard GSM networks such
as handover support and specification compliant multi-BTS
configurations.
B. OpenBSC
Compared to the general approach of OpenBTS, OpenBSC
takes a more traditional path toward GSM network imple-
mentation. Whereas OpenBTS realizes an alternative GSM
architecture, OpenBSC provides a network side implementa-
tion that closely follows the standard specifications. OpenBSC
interfaces with one or more of the supported commercial
BTS units and can create a stand-alone GSM network that
combines functionality from a BSC, MSC, HLR, VLR, EIR,
and AuC into one package. Additionally, the lower layers
of the OpenBTS stack may be configured to interface to
OpenBSC in a traditional network architecture rather than the
hybrid VoIP configuration. This approach is described in more
detail in Section V.
III. E100 USRP P LATFORM
The E100 platform includes three reconfigurable processors
suitable for different aspects of cellular use: Xilinx Spartan-
3A FPGA, ARM CortexA8, and Texas Instruments fixed point
C64x+ DSP. The general purpose ARM processor (GPP)
and C64x+, as components of the TI OMAP3530 application
processor, are collocated on a removable Gumstix computer-
on-module board [14]. The FPGA is mounted directly on the
main board and interfaces with the other processors through
a combination of General Purpose Input / Output (GPIO)

Fig. 2. E100 multi-processor platform
pins and the OMAP3530 General Purpose Memory Controller
(GPMC). The overall processor structure and connections are
shown in Figure 2.
The embedded BTS implementation partitions base station
functionality across multiple processors in order to support
different aspects of GSM operation in an efficient manner.
The precise timing necessary to meet the strict, real-time re-
quirement of GSM specific TDMA access is managed through
coordinated use of the ARM and FPGA cores. Computation-
ally intensive signal processing operations are handled through
two approaches; the receive side operations of the transceiver
are offloaded to the C64x+ DSP, while the simpler transmit
side remains on the ARM and is vector optimized using
single instruction, multiple data (SIMD) operations. Finally,
the ARM Cortex-A8 handles upper-layer GSM signaling, user
applications, and remaining operations that do not necessitate
specialized processing.
A. Interprocessor Communication
Distribution of base station functionality across the set
of multiple, heterogeneous cores greatly improves efficiency
and increases the capabilities of the device, but introduces
the added task of managing communication across each of
the different processing units. Because of disparate physical
locations, interconnects, and the unique characteristics of each
processor, there is no unified interprocessor communication
architecture available for the E100. Rather, interaction between
the specialized DSP and FPGA cores and the GPP occurs
through separate, independently implemented interfaces. Also,
no direct FPGA–DSP line of interaction is implemented as all
communications flows through the GPP. While less optimal
than a directly mapped FPGA–DSP interface, this approach
was found sufficient for OpenBTS use as shown in the
performance results section.
The FPGA communicates with the ARM processor through
a combination of GPIO and memory transfers controlled by
the General Purpose Memory Controller (GPMC) over the
OMAP L3 and L4 interconnects. The FPGA communication
structure of the E100 can bee seen in Figure 2. Mediation
of FPGA interaction occurs through a Linux kernel driver,
which controls the GPMC to initiate DMA transfers containing
sampled data across processor boundaries. With coordination
from the kernel driver, a user space library, the Universal
Hardware Driver (UHD), exposes data from kernel space and
presents a sampled signal stream interface to the OpenBTS
application. Within the OpenBTS receiver, the sampled data
stream is segmented into TDMA bursts using timing metadata
inserted by the FPGA firmware. These formed timeslot bursts
are subsequently transferred to the DSP for signal processing
and demodulation. The transmit case consists of the inverse
set of operations with the omission of DSP interaction.
ARM to C64x+ transfers are implemented using TI
DSP/BIOS Link (DSPLINK), which provides an interface and
abstraction layer for a shared memory and hardware interrupt
based transport. During initialization, asynchronous message
buffers are allocated from a shared memory pool. Through
DSPLINK, OpenBTS uses message queues for transferring
shared memory pointers to and from the DSP; these memory
pointers reference buffers containing the bursts received from
the FPGA. Either side of the connection can access the shared
buffer contents by translating the pointer address between the
ARM and DSP virtual address spaces. The data in memory
is then read or written by an explicit cache invalidation or
cache write respectively. The overall GPP–DSP message queue
transport is shown in Figure 3. This mechanism facilitates an
efficient and relatively simple method to communicate a high
volume of sampled GSM data bursts across the GPP–DSP
barrier for accelerated receiver handling.
Fig. 3. C64x shared memory transport
IV. P HYSICAL L AYER I MPLEMENTATION
The FPGA of the E100 provides a variety of functions that
include supporting external connectivity, device configuration,
and interfacing to mixed signal components. Serving as an
intermediate stage between GSM signal processing and the
digital converters, the FPGA provides flexible sample rate
selection and rate matching appropriate for the GSM specific
symbol rate of 270.833 ksps. Furthermore, by shifting the
high rate, and most intensive, filtering operations to the FPGA
reduces overall computational burden throughout the entire
system.

A. TDMA Interface
The GSM standard uses time division multiple access
(TDMA) for network access which places strict timing re-
quirements on the hardware in order to maintain precise times-
lot alignment. Real time performance limitations of general
purpose application processors, such as the ARM, prohibit
their direct use for cellular applications. Even when real
time operating systems (RTOS) are employed, the necessary
sample stability for cellular TDMA access [15] is a significant
magnitude greater than the performance available from a GPP.
Consequently, OpenBTS leverages the FPGA, which provides Fig. 4. OpenBTS L1/PHY receive chain
predictable, deterministic behavior based on programmable
logic for timeslot alignment.
For the OpenBTS transceiver, the FPGA maintains send
and receive side buffers that contain packets of sampled data
and additional timing metadata. The timing metadata indicates
when the samples arrived or when samples should be sent for
receive and transmit functionalities respectively. With these
hardware generated timestamp values, TDMA timeslots are
precisely aligned by the FPGA with respect to other timeslots
in both downlink and uplink directions.
The combination of FPGA and ARM packet handling with
added timing metadata relaxes real time requirements that
would otherwise be intractable on the host GPP processor.
Real time requirements still exist on the host in the need
for packets to arrive on the FPGA before a rolling deadline,
however, this limitation is significantly less restrictive than that Fig. 5. OpenBTS L1/PHY transmit chain
of maintaining accurate sample timing alignment.

B. Signal Processing filtering operations – make up the majority receiver operations.

A particularly unique aspect of OpenBTS is that the im-
plementation does not depend on any dedicated baseband
hardware and relies completely on a software-defined radio
transceiver. The GSM uses symbol rate of 270.833 kHz;
though modest by comparison to more recent cellular stan-
dards, the required signal bandwidth is substantial on an
embedded application processor without DSP acceleration
or any other forms of optimized operation. Consequently,
targeting DSP utilization along with maximizing efficiency
through specialized ARM instructions is a critical objective
of running OpenBTS on the E100 platform.
1) Receiver Structure: The OpenBTS receiver design is
shown in Figure 4 and encompasses all portions of the GSM
physical layer with the exception of channel coding, which is
implemented separately from the transceiver. Notably, tasks
consisting of high-volume complex multiply and multiply-
accumulate (MAC) instructions – such as convolution used in
The repetitive nature of MAC operations justifies offloading
such tasks to the DSP core. For example, the interpolation and
fractional delay processing are two operations implemented
using polyphase filterbanks, which can easily leverage opti-
mized libraries and specialized capabilities of the C64x+.
2) Transmitter Structure: As is typical in many commu-
nication systems, the transmitter is simpler than the receiver
since no synchronization or timing recovery stages are nec-
essary. In particular, the GMSK modulator implementation in
OpenBTS is implemented with a low complexity linearized
Laurent representation [16]. The transmitter path is shown in
Figure 5
Because of the comparatively simpler design, the transmit
chain does not justify full offload onto the DSP processor
given the addition transport overhead. Instead, the transmit
signal processing runs on the ARM processor with critical
processing sections optimized with ARM NEON assembly
 TABLE I
GSM BURST HANDLING RATE
Configuration Transfer Size Bursts / second
ARM baseline N/A 3.3e3
ARM w/ NEON N/A 40.3e3
ARM w/ DSP 8 kB 22.0e3
ARM w/ DSP 16 kB 44.1e3
ARM w/ DSP 32 kB 87.9e3
operations, which take advantage of SIMD vector extensions
[17]. These extensions allow for the use of 128-bit quadword
registers that perform four floating point multiplications with a
single instructions. In addition, memory can be managed more
accurately to minimize load and store operations.
C. Performance Results
In order to justify the architecture choices, independent test
cases were created to evaluate and compare different code and
processor combinations. The benchmark test case was based
on iterative convolution operations, which form the basis of the
OpenBTS transceiver signal processing. Repeated convolution
closely reflects the transmit side modulation operation as well
as interpolation filtering heavily used in the OpenBTS receiver.
The tests included 20,000 iterations of randomized GSM bursts
(sequences of 156 complex symbols sampled at 2 samples
per symbol) convolved with an 8 tap real valued FIR filter.
Mean burst processing rate was then derived from the overall
completion time. We compared NEON and DSP optimized
implementations against the ARM processor with the standard
GCC compiler output. Because use of the DSP involves inter-
processor communication, we also examine various message
transport sizes.
A large increase in achievable burst handling rate was ob-
served with SIMD and DSP optimization as shown in Table I.
With NEON we observed a 12x speedup much higher than
the expected 4x from vector operations alone. This disparity
is attributed selective memory operations, which constitute
a sizeable portion of processor time in addition to internal
register–register arithmetic operations. Much larger speedups
are found in the DSP case with the dedicated processor
and fixed point implementation. Note that DSP performance
was directly linked to transport message size, which clearly
illustrates the overhead of interprocessor communications. In
fact, we can conclude that for our GSM test case, the C64x
DSP is underutilized and primarily limited by memory and
transport overhead rather than actual signal processing.
In summary, the GCC compiler is not particularly effec-
tive in generating efficient ARM code for repetitive filtering
operations. Substantial increases can be found by optimizing
with NEON assembly instructions. Not surprisingly, addi-
tional, substantial gains can be found by using the dedicated
DSP coprocessor. With this approach, though, the accelerated
computing capability must be balanced with the overhead of
interprocessor communication. Additionally, in both NEON
and DSP cases, we encounter limitations of memory I/O speed
Fig. 6. OpenBSC / OpenBTS network architecture
in the form of small and large sized memory transactions
respectively.
V. BSC I NTERFACING
With an operational embedded transceiver, OpenBTS can be
configured for standalone operation or modified for more typ-
ical BSC interface use. Section II described typical OpenBTS
operation using a hybrid GSM–VoIP approach that operates
without a dedicated BSC. This section describes the alternative
approach of attaching a BSC to OpenBTS over IP.
A. Motivations
Integrating OpenBTS and OpenBSC connects two major
open source projects together, allowing for more control
and customization of GSM components and protocols. This
approach is accommodated by Osmo-USRP, a new interface
layer designed to provide an interface between the two open
source packages. There are a number of motivations for such
an approach, which include addressing certain limitations of
OpenBTS network configuration. Since OpenBTS has a hybrid
L3 with GSM and SIP features, the program cannot connect to
any GSM core infrastructure via the standard Abis interface.
While this is an advantage of a strictly OpenBTS configuration
in many ways, it can be prohibitive in other situations – namely
OpenBTS does not support standardized multi-cellular features
enabled by the BSC. By building an interface to connect
OpenBTS to OpenBSC and effectively remove hybrid SIP
functionality, there are additional possibilities for operating
a custom open source GSM network with multiple BTS
components. Configuration and operating status, as well as
custom goals such as monitoring target users, can then be
managed at a centralized instance of OpenBSC.
B. Design Implementation
The L1 and transceiver functionality of OpenBTS is inte-
grated with the GSM core network of OpenBSC and Osmo-
BTS. This integration is achieved through the Osmo-USRP
layer, which removes most of L2 and hybrid L3 from
OpenBTS and provides an interface to the L2 of Osmo-BTS.
In Figure 6, the architecture of interconnecting open source
programs is compared to that of the standard GSM network.

Fig. 7. Osmo-BTS inter-layer message handling
Osmo-USRP is highlighted to show its place in the GSM stack
of a standard BTS, between the L1 USRP transceiver and the
L2-L3 Osmo-BTS.
Osmo-USRP uses inter-layer primitives defined in Osmo-
BTS to process messages passed between the L1 and an event-
driven L2 via a pair of Unix domain sockets. In the downlink
direction, a thread multiplexer functions to route the message
to the appropriate OpenBTS L1 logical channel specified by
the L2 header. In the reverse direction, L2 header information
is attached to L1 messages, which are then written to the
uplink socket and processed in Osmo-BTS L2. This system
architecture, along with the connections to USRP and Osmo-
BTS, is shown in Figure 7.
VI. C ONCLUSION
While the long term impact of open source GSM software
and hardware on the cellular environment remains to be seen,
more immediate influences can be observed in the greater
availability and comparatively easy access of products suitable
for GSM development. This paper describes one such example
in the form of an embedded GSM femtocell built from open
source software packages, OpenBTS and OpenBSC, and a
popular off-the-shelf software radio product, USRP E100.
Required toolchains and supporting libraries were freely avail-
able to support multi-processor integration and optimization
for signal processing. Performance results demonstrate that
the open hardware and software combination is capable of
obtaining the desired result of supporting OpenBTS operation
on the target E100 embedded platform.
Finally, source code was also modified to support multiple
configurations of standalone OpenBTS operation or standard
GSM networked operation with OpenBSC.
R EFERENCES
[1] Global mobile Suppliers Association (GSA), “Global mobile market
update and output for GSM, WCDMA-HSPA/HSPA+ and LTE,” Sept
2011.
[2] D. Burgess, H. Samra, et al., “The OpenBTS Project,” [Online] Avail-
able: http://wush.net/trac/rangepublic, April 2012.
[3] H. Welte, H. Freyther, et al., “OpenBSC,” [Online] Available: http://
openbsc.osmocom.org, April 2012.
[4] I. Androulidakis, “Confidentiality, Integrity, and Availability Threats
in Mobile Phones,” in Mobile Phone Security and Forensics, ser.
SpringerBriefs in Electrical and Computer Engineering, 2012, pp. 1–
11.
[5] M. Becher, F. Freiling, J. Hoffmann, T. Holz, S. Uellenbeck, and
C. Wolf, “Mobile Security Catching Up? Revealing the Nuts and Bolts
of the Security of Mobile Devices,” in Security and Privacy, 2011 IEEE
Symposium on, May 2011, pp. 96 –111.
[6] M. Paik, “Stragglers of the herd get eaten: security concerns for GSM
mobile banking applications,” in Proceedings of the Eleventh Workshop
on Mobile Computing Systems & Applications, ser. HotMobile ’10. New
York, NY, USA: ACM, 2010, pp. 54–59.
[7] A. Anand, V. Pejovic, E. M. Belding, and D. L. Johnson, “Villagecell:
cost effective cellular connectivity in rural areas,” in Proceedings of
the Fifth International Conference on Information and Communication
Technologies and Development. New York, NY, USA: ACM, 2012, pp.
180–189.
[8] V. Gabale, R. Gopalakrishnan, and B. Raman, “The pilot deployment of
a low cost, low power gateway to extend cellular coverage in developing
regions,” in Proceedings of the 5th ACM workshop on Networked
systems for developing regions. New York, NY, USA: ACM, 2011,
pp. 21–26.
[9] S. D. Meinrath, J. W. Losey, and B. Lennett, “A Growing Digital Divide:
Internet Freedom and the Negative Impact of Command-and-Control
Networking,” IEEE Internet Computing, vol. 15, no. 4, pp. 75–79, 2011.
[10] K. Rechert, K. Meier, B. Greschbach, D. Wehrle, and D. von Su-
chodoletz, “Assessing Location Privacy in Mobile Communication Net-
works,” in Information Security, X. Lai, J. Zhou, and H. Li, Eds.
Springer, 2011, vol. 7001, pp. 309–324.
[11] A. Dhananjay, M. Tierney, J. Li, and L. Subramanian, “Wire: a new rural
connectivity paradigm,” SIGCOMM Comput. Commun. Rev., vol. 41,
no. 4, pp. 462–463, Aug. 2011.
[12] M. Kretschmer, C. Niephaus, T. Horstmann, and K. Jonas, “Providing
mobile phone access in rural areas via heterogeneous meshed wireless
back-haul networks,” in Communications Workshops (ICC), 2011 IEEE
International Conference on, June 2011, pp. 1–6.
[13] 3GPP, “Physical layer on the radio path; General description,” 3rd
Generation Partnership Project (3GPP), TS 05.01, Dec. 2004.
[14] Gumstix, “Overo COMS,” [Online] Available: http://www.gumstix.com,
April 2012.
[15] 3GPP, “Radio subsystem synchronization,” 3rd Generation Partnership
Project (3GPP), TS 05.10, Sep. 2003.
[16] P. Laurent, “Exact and approximate construction of digital phase
modulations by superposition of amplitude modulated pulses (amp),”
Communications, IEEE Transactions on, vol. 34, no. 2, pp. 150 – 160,
Feb 1986.
[17] ARM, “ARM Architecture Reference Manual: ARMv7-A and ARMv7-
R edition,” ARM DDI 0406C, 2011.