Facilitating Technology Insertion in Advanced Wireless Systems
Part 1: Architecture Requirements
By Lee Pucker
CTO and VP Corporate Development, Spectrum Signal Processing by Vecima
The baseband or modem processing engines in many advanced wireless systems often include a variety of
programmable “off-the-shelf” signal processing devices such as digital signal processors (DSPs) and field
programmable gate arrays (FPGAs). These devices tend to evolve following some variant of Moore’s law,
with new generations of devices incorporating new features and capabilities introduced every 2 to 3 years.
Original equipment manufacturers (OEMs) developing advanced wireless systems can take advantage of
this trend to offer their customers cost-effective feature enhancements and upgrades in existing systems
through technology insertion by replacing only the baseband processing engine while retaining other
subsystems, such as the RF or control subsystems as is. This article will explore the architectural
requirements necessary to facilitate this manner of technology insertion in an advanced wireless system.
Part 1 of the article will examine the requirements on the baseband processing engine hardware
architecture, and propose a software/firmware model for minimizing the cost to the OEM in moving from
one generation of technology to the next by maximizing the reuse of intellectual property (IP) across
roadmap products. Part 2 of the article will present a real world example illustrating the efficacy of the
proposed architectural models.
Architecting the Baseband Processing Engine for Technology Insertion
The baseband processing in an advanced wireless system typically provides a broad range of the radio’s
physical layer channel processing functions. These include channel estimation and equalization; carrier,
symbol and frame synchronization; spreading and despreading; modulation and demodulation; interleaving
and deinterleaving; and channel coding and decoding for forward error correction. As illustrated in Figure
1, OEMs typically utilize a variety of different types of signal processing technologies to provide this
functionality, including application specific integrated circuits (ASICs), field programmable gate arrays
(FPGAs), digital signal processors (DSPs), and general purpose processors (GPPs), These technologies
may be packaged as either discrete components or combined in system-on-chip (SoC) devices, and are
interconnected to provide the data flows necessary within the baseband processing subsystem to support the
target air interface standards.
Enabling future upgrades of this functionality through technology insertion requires that the baseband
processing subsystem be encapsulated in a “standardized” module. The term “standardized” in this context
means having a well defined mechanical structure or form factor that can facilitate the future replacement
of the baseband processing engine while the system is in-service and having well defined interfaces
between the baseband processing module and the other subsystems within the radio, including the
mechanical and electrical interfaces and associated intra-system communications protocols. With respect to
this latter requirement, three well-defined primary system interfaces are typically required in a baseband
processing module: the network interface, the control interface, and the RF subsystem interface. The
network interface provides support for the transport of payload data between the physical layer processing
supported in the baseband processing engine and the higher level functions supported within the rest of the
wireless platform. The control interface provides support via an external control subsystem for non-realtime control of the functions within the baseband processing engine, such as starting and stopping the
baseband processing and setting the mode of operation. The RF subsystem interface provides support for
the transport of digital intermediate frequency (Digital IF) signals and any associated context and control
data between the analog-to-digital and digital-to-analog converter assembly in the RF front end and the first
stage processing elements contained within the baseband processing module. The context data associated
with these signals may include items such as time of day and sample count that can be used to support
network synchronization in the transmit and receive channels, while the control data may include time
critical tuning instructions or power and bandwidth settings for the RF subsystem.
Copyright © 2007 Vecima Networks Inc.
DigitalIF Interface
Non-Blocking Crossbar
(Channel
Estimation ,
Equalization ,
Carrier Sync ,
Symbol Sync ,
Frame Sync ,
Spreading /
Despreading )
RF XCVR 1
RF XCVR 2
PCI
Bridge
2 MB
ZBT
SRAM
DSP
(Modulation /
Demodulation ,
Interleaving /
Deinterleaving ,
Channel Coding /
Decoding )
32 MB
SDRAM
Modem
Channel GPP
(Network Interface ,
Control Interface ,
Link/Network Layer
Network
Interface
Processing )
PCI
FPGA
PCI
Digital IF Interface
Control Interface
Baseband Processing Module
Figure 1: Architecture of a typical baseband processing engine utilized in an advanced wireless
platform
In establishing the “standards” that will be used in supporting these elements, OEMs typically evaluate the
business case for adopting either an open standard or a proprietary solution. The advantage of an open
standard is that it allows the OEM to leverage existing, proven technology thus reducing development cost
and schedule risk. The advantage of the proprietary standard is that it can be tailored to the system’s
specific requirements, often allowing the OEM to reduce per unit cost in production while at the same time
enabling features that may differentiate the system from competitive offerings. In performing this
evaluation, the communications systems engineer maps the specific technical requirements of the proposed
wireless system against available open standard that may address those requirements within the system’s
cost model. For example, in evaluating the bandwidth and quality of service requirements associated with
the baseband processing module’s network and control interfaces, the communications system engineer
will often find that these are fairly constrained, requiring at most tens of megabits per channel. This allows
the protocols supporting these interfaces to be implemented over open-standards based networking
technologies such as Gigabit Ethernet or PCI Express at a reduced cost to the OEM. The RF subsystem
interface, however, is generally more complex, requiring much higher bandwidths to transport the sampled
signal data and very tight controls on both latency and determinism. As such, the communications systems
engineer evaluating this interface may determine the requirements are best satisfied using a proprietary
interface architecture incorporating more specialized transport technologies.
Often this “make vs. buy” evaluation results in the use of a mix of open and proprietary standards within
the wireless system. That said, the need for proprietary “standards” has lessened over the past several years
due to industry efforts to define standard profiles for wireless platforms based on existing open standards,
and to develop new specifications targeting wireless products when open standards are not available.
Included among these "standardization" efforts are the following:
•
The Scope Alliance – The Scope Alliance was formed in January of 2006 by a group of network
equipment providers (NEP) that include Alcatel, Ericsson, Motorola, NEC, Nokia and Siemens,
with the intent of developing profiles for and identifying gaps in existing open specifications
supporting Carrier Grade Base Platforms (CGBP) [1]. The idea behind the Scope Alliance is to
Copyright © 2007 Vecima Networks Inc.
•
•
develop a “vibrant supply chain and ecosystem of commercial-off-the-shelf (COTS) and free/open
source software (FOSS) from which NEPs can source a majority of their CGBP hardware and
software” [2]. While the initial focus of the Scope Alliance does not include specialized
processing engines such as a baseband processing module, the Scope Alliance profiles do include
network and control interface specifications that are clearly relevant.
The Open Base Station Architecture Initiative (OBSAI) – OBSAI was started in 2002 by LG
Electronics, NEC Networks, Nokia, and Samsung Electronics to define an agreed upon common
base station architecture at a modular level [3]. As with the Scope Alliance, the purpose of OBSAI
is establish “standards” allowing commercial cellular base station manufacturers to purchase
COTS modules for inclusion in their system architecture. OBSAI defines multiple interfaces
within the base station architecture, referred to as reference points, including the interface between
the control processor and the baseband processing engine (RP1), between baseband processing
engine and the network (RP2), and between the RF front end and the baseband processing engine
(RP3) [4].
The VME Industry Trade Association (VITA) Radio Transport draft standard – VITA-49 was
formed in 2004 as a formal VITA Standards Organization Working Group to create a “new
interconnect standard for passing IF data between system elements in a digital format” [5]. This
standard defines a similar interface with OBSAI RP3 with a primary focus on addressing the
requirements of the signals intelligence (SIGINT) community and a secondary focus on the needs
of the communication systems and software defined radio markets.
Providing a “Standardized Operating Environment” to Maximize Code Reuse in the Upgraded
Module
In addition to “standardizing” the form factor and interfaces, support for baseband processing engine
upgrades through technology insertion also generally requires establishing a well defined operating
environment within the baseband processing engine to facilitate reuse of the functional code supporting the
physical layer processing (Figure 2). The reason for such an environment in supporting technology
insertion is simple: significant savings in both cost of development and time to market can be achieved by
the OEM if, for example, the DSP code in one generation of baseband processing engine can be largely
reused to support the same or similar functionality in the next. Support for this type code reuse between
generations of baseband processing requires that a number the elements be considered in establishing the
module’s software and firmware infrastructure:
•
•
•
•
A well-defined operating environment must be defined for each class of signal processing device
allowing code to move between generations of baseband processing modules from “like processor
to like processor” (e.g. FPGA to FPGA or DSP to DSP)
A standard application framework must be established that is used across generations of modules
to set up, tear down, connect and control the functional software and firmware components
supporting the wireless air interface standards that are operating on the various processing devices.
A standard set of Application Programming Interfaces (APIs) must be established allowing the
functional components operating on the various processing devices to access the common radio
services available within the wireless system, such as the timing and RF control services.
A well-defined "hardware abstraction layer" must be established to allow communications to
occur between functional components operating on different devices in a manner that is
independent of hardware architecture or data transport
Copyright © 2007 Vecima Networks Inc.
Air Interface Application N
Air Interface Application 2
Air Interface Application 1
Application resource
(FPGA)
Application resource
(FPGA)
Application resource
(PPC)
Application resource
(PPC)
Application resource
(PPC)
quicWave
Application resource
(PPC)
Application resource
(PPC)
Application resource
quicWave
IP cores
(Xilinx or other
3rd party)
VSI/Pro
VSI/Pro
VSI/Pro
(DSP)
quicWave
quicWave
VSI/Pro
VSI/Pro
Radio Service
quicWave
Application
quicWave
Programming
VSI/Pro
Interfaces
VSI/Pro
Application Framework
VSI/Pro
VSI/Pro
Hardware
Abstraction
Layer
MiddleWare Layer
Operating System(s) and TCP/IP Network stack
Baseband Processing Engine Hardware
Figure 2: "Standardized" Operating Environment for the Baseband Processing Module
As with the hardware architecture, companies involved in the wireless industry have developed, or are in
the processing of developing, a number of specifications and standards supporting these elements for use in
advanced wireless systems. Key examples of these specifications include the following:
•
•
•
The Service Availability Forum (SA Forum) Specifications – The SA Forum was formed in 2001
by multiple computer and communication companies to develop specifications for an application
framework supporting highly available systems [6]. Two key specifications from the SA Forum
supporting reuse of functional code across generations of baseband processing technology are the
Hardware Platform Interface (HPI) specification which standardizes the interface between the
hardware platform and the highly available middleware of a carrier grade platform, and the
application interface specification (AIS) which standardizes the interfaces between the higher
level applications and the highly available middleware [7, 8]. Scope Alliance activities for high
availability services in carrier grade communications platforms are based on these specifications.
The Joint Tactical Radio System (JTRS) Software Communications Architecture (SCA) – A key
element of the US JTRS program is the Software Communications Architecture (SCA) developed
by the Modular Software-programmable Radio Consortium (MSRC) under contract to the JTRS
Program Office [9]. This architecture “objectizes” the radio structure and defines a standard
application framework (referred to as the Core Framework) for instantiating and connecting the
software objects providing the entire set of radio and/or communications functions, referred to as
the waveform, associated with each radio channel [10]. Key elements of the SCA Core framework
are the Device Manager and Logical Device that abstract the application interfaces to the baseband
processing engine in a manner similar to the Service Availability Forum Specifications.
The eXpressDSP Algorithm Interoperability Standard (xDAIS) – xDAIS is an open specification
that facilitates the reuse of DSP code across baseband processing engines through “a set of coding
Copyright © 2007 Vecima Networks Inc.
•
•
conventions and application programming interfaces (APIs) that enables algorithms to be
integrated much more quickly” [11]. xDAIS was originally introduced by Texas Instruments in
1999, and since then TI’s third party partners have produced hundreds of xDAIS compliant
software components, including a number targeted at wireless applications such as GSM [12] .
The JTRS Modem Hardware Abstraction Layer (MHAL) Applications Programming Interface
(API) – Publicly released in May of 2007, the MHAL API was developed by the JTRS Program to
supplement the SCA by providing a common mechanism for functional components operating on
a GPP, and FPGA, or a DSP within the baseband processing engine to communicate [13].
The Software Defined Radio Forum’s Transceiver API - In November of 2006, the SDR Forum
formed a task group to define a common set of API’s supporting the interface between the RF and
the baseband processing in an advanced wireless system [14]. The goal of this effort is to produce
an API that supports a broad range of interface standards, including the VITA-49 draft standard,
the OBSAI RP3 specification, and the DigRF specification.
OEMs developing advanced wireless systems must evaluate the appropriateness of these types of
specifications in supporting the “standardized” operating environment of their baseband processing engine,
and reach a “make vs. buy” decision on each of these elements.
The Result – Reduced Cost of System Upgrades through Technology Insertion
By encapsulating the baseband processing engine in a “standardized” modular architecture in the proposed
manner with a well-defined operating environment supporting the reuse of signal processing code across
generations of modules, OEMs can offer their customers enhanced features and capabilities in existing
advanced wireless systems through technology insertion. The benefit to the OEM’s customer in this model
is the ability to spread out their capital expenditures over the product’s lifetime through incremental module
upgrades versus requiring a fork-lift upgrade of an entire system to support a new feature or service. In part
2 of this article, a real world example will be provided illustrating the efficacy of the proposed architectural
model in achieving these results, allowing the OEM to better take advantage of Moore’s law in servicing
their customer’s needs.
References
1) Nokia, ” Network Equipment Providers Team to Promote Open Specifications and Accelerate
Development of Carrier Grade Base Platforms”,
http://press.nokia.com/PR/200601/1030418_5.html
2) The Scope Alliance, “ Scoping the Scope – Closing the Gap on Open Carrier Grade Base
Platforms”, http://www.scope-alliance.org/scope-technical-position.pdf
3) Open Base Station Architecture Initiative, “Leading Telecommunications Companies Sign Up for
Open Base Station Initiative set to bring more innovative and cost-effective base stations to
mobile operators”,
http://www.obsai.org/obsai/media_relations/media_releases/021002_leading_telecommunications
_companies_sign_up_for_open_base_station
4) Joseph Cleveland, “Open Base Station Architecture Initiative”,
http://www.techonline.com/article/pdf/showPDFinIE.jhtml?id=1987003531
5) Stephen M. Pereira, ” Standardizing Digital IF Data Transfer with VITA 49”, RTC Magazine,
January 2006, http://www.rtcmagazine.com/home/article.php?id=100460
6) Service Availability Forum, “Service Availability Forum, “Premier Communications and
Computing Companies Mobilize to Eliminate Service Interruptions”,
http://www.saforum.org/press/releases/2001_12_04/
7) Service Availability Forum, “Service Availability Forum Tutorial – Hardware Platform Interface
(HPI)”, http://www.saforum.org/press/presentations/HPI_Tutorial_Nov.pdf
8) Service Availability Forum, “Service Availability Forum Tutorial – Application Interface
Specification (AIS)”, http://www.saforum.org/press/presentations/AIS_Tutorial_final_Nov.pdf
9) Lee Pucker and Geoff Holt, “Extending the SCA Core Framework Inside the Modem Architecture
of a Software Defined Radio”, IEEE Radio Communications, March 2004
http://www.spectrumsignal.com/publications/Extending_SCA_Inside_SDR_Modem_Architecture.
pdf
Copyright © 2007 Vecima Networks Inc.
10) Joint Tactical Radio System Joint Program Executive Office, “Software Communications
Architecture Specification, Version 2.2.2”,
http://jtrs.spawar.navy.mil/sca/downloads.asp?ID=2.2.2
11) Texas Instruments, “eXpressDSP Algorithm Standard – xDAIS Developer’s Kit and xDM”,
http://focus.ti.com/docs/toolsw/folders/print/tmdxdaisxdm.html
12) Texas Instruments, “ GSM – eXpressDSP-Compliant Third-Party Algorithms”,
http://focus.ti.com/lit/ml/sprm093c/sprm093c.pdf
13) Joint Tactical Radio System Joint Program Executive Office, “Joint Tactical Radio System (JTRS)
Standard Modem Hardware Abstraction Layer Application Programming Interface (API) Version
2.11.1”, http://jtrs.spawar.navy.mil/sca/downloads.asp?ID=mhal
14) SDR Forum, “Transceiver Sub-system Interfaces Task Force (TSI-TF) Call for Participation”,
http://sdrforum.org/pages/dublin_07_dropbox/TSI_TF_CFP_v0.2.doc
Copyright © 2007 Vecima Networks Inc.