Tài liệu Phần mềm xác định radio P11 pdf

11
Software Download for Mobile
Terminals
Paul Bucknell and Steve Pitchers
Philips Research Laboratories
The subject of software radio emerged as a ‘hot topic’ in mobile communications in the early
1990s, when many people saw the technology as a solution to the problems of complex RF
and IF processing required in modern multimode/multiband mobile terminals. Today, soft-
ware radio is seen more as a technology to enable the reconfiguration of terminals by down-
load.
1
Such reconfiguration can be achieved at all stages from design, through production, to
post purchase use by the consumer.
This chapter begins by introducing the concepts of software reconfiguration by download
and then describes some of the important software technology issues. Standards, security, and
software architectures are then discussed. In the near term, the commercial benefits of soft-
ware download are initially being reaped at the higher layers of the protocol stack, rather than
through air interface reconfiguration. Such applications are not restricted to the field of
mobile communications – the chapter thus includes a brief description of the present status
and anticipated advances in software download for digital television – a global, high growth,
consumer market. The potential use of software download to reconfigure the air interface in a
mobile phone terminal ‘on the fly’ is examined. To exemplify the issues involved in such
reconfiguration, we describe the implementation of a practical demonstration of ‘on-the-fly’
reconfiguration of air interface parameters and algorithms, making use of a wireless web
browser. We present details of the procedures and protocols associated with such a reconfi-
guration and conclude with a brief discussion of the future of software downloading.
1
Early North American research focused on ‘pure’ software radio, the former approach, whereas in Europe
advocates argued that the latter, ‘pragmatic’ software radio, would prevail in terms of first commercial opportunities.
Such perspectives and evolution are described in the first section of Tuttlebee, W. (Ed.), Software Defined Radio:
Origins, Drivers & International Perspectives, John Wiley & Sons, Chichester, 2002.

Software Defined Radio
Edited by Walter Tuttlebee
Copyright q 2002 John Wiley & Sons, Ltd
ISBNs: 0-470-84318-7 (Hardback); 0-470-84600-3 (Electronic)
11.1 Why Software Download?
11.1.1 Software Reconfiguration
Software reconfiguration promises to facilitate roaming, lower terminal costs, dynamic spec-
trum management, bug fixing, new features, third party software creation, extra value to
network operators (their own customisations), personalization (customer’s own customiza-
tions), and more. Open software architectures will allow terminals to become programmable
transceivers for radio, television, home-networks, and offices, furthering fixed mobile broad-
cast integration. In the field, upgrading of software allows future proofing and can shield from
ever faster cycles of innovations and obsolescence.
The following four areas are key potential arguments for the manufacture of terminals and
integrated circuit platforms for terminals that can be reconfigured by downloading new
software:
† Reduction in the number of different models – reconfiguration of terminals should
allow fewer terminal variants to have to be manufactured to support different technical
standards. This allows the large scale manufacture of terminals, leading to lower unit
costs.
† Last minute or deferred customization – the use of downloading means that the final
configuration of the terminal can be made even after deployment, so increasing the
functionality of a product and reducing the likelihood of product recalls or returns. It is
also possible to market the late customization of a product to end users, who may see the
advantages of being able to download software to the terminal to customize the operation
of that terminal to match their personal requirements.
† Running applications – end user applications such as games, productivity applications,
etc., are the first of the downloaded applications already running on today’s terminals.
† Open platform – if an open platform is introduced, then third party software developers
can develop innovative applications for the terminal, which should increase the appeal of

the terminal to the end user, without the direct costs to the manufacturer of employing such
staff.
The disadvantages of software download include the difficult task of managing different
versions of software in the different terminals deployed in the field, as well as the problem of
ensuring robustness in all user environments.
11.1.2 Software Downloading Terminals
Commercial terminals using SDR technology will probably be available on the market by
the year 2002 which will allow a terminal to operate with all the 800 MHz, 900 MHz,
1800 MHz, and 1900 MHz network standards that exist today. Terminals that also support
third-generation capabilities may not be available until about 2003. The key benefit to the
terminal manufacturer is that the SDR technology will allow one hardware and software
architectural platform to be used to address all possible world markets. An estimate of
the size of the potential market for SDR terminals has been made by the SDR Forum as
about 9.5 million handheld devices in 2001 timeframe, rising to about 130 million in
2005.
Software Defined Radio: Origins, Drivers & International Perspectives312
Downloading software over the air interface is only one way to achieve terminal reconfi-
guration, so care must be taken that other methods, such as reconfiguration via Bluetooth [1],
IR, direct connection, smartcard, etc., are considered. Further, the range of functionalities
which software download can be used to modify is very broad. Figure 11.1 illustrates the
range of such possibilities, ranging from reconfiguration of simple user applications to chan-
ging the nature of the air interface during an active call.
The diagram shows how terminals could, in time, become fully programmable if the
hardware and software architectures used allowed this. The spectrum of downloadable func-
tions is shown as five distinct categories of reconfiguration:
† User applications – for example, games, email readers, new user interfaces, etc. This
software category has no connection with the operation of the protocol software.
† Protocol changes – this category includes bug fixing – correcting mistakes made in the
software loaded on the phone at manufacture. This level of upgrade also includes changes
made to a standard (e.g. the emerging UMTS 3GPP standard) as it develops and is

enhanced throughout its lifetime. This category could also include changes made to the
algorithms used in a terminal, such as power control, that an operator may wish to effect
after field deployment of the terminal.
† New codecs – this category includes the downloading of larger amounts of software that
affect functions in a terminal from physical layer to the user interface, e.g. a speech codec.
Generally this category of software will include substantial parts of software running both
as DSP firmware and microprocessor code, but which has well defined interfaces to the
rest of the software in the terminal.
† New air interface – this includes reconfiguration of the terminal to a completely different
air interface standard. This is different from conventional dual mode terminals in that the
software for the new radio interface is not held in the terminal but is downloaded in some
way.
† Fully flexible air interface – this is the extreme case of a reconfigurable terminal where the
air interface parameters such as modulation, coding, framing, bit rate, etc. are all defined
by the software downloaded at the start of each air interface connection.
Software Download for Mobile Terminals 313
Figure 11.1 The spectrum of downloading possibilities
11.1.3 Downloading New Air Interfaces
The ultimate software reconfiguration in terminals would be the download of a new air
interface. The increasing power and reducing cost of digital signal processing will allow the
use of reconfigurable baseband processing in mobile handsets which will in turn permit the
use of flexible air interfaces. Flexible air interfaces mean that parameters such as modula-
tion type, RF carrier frequency, and access scheme (TDMA, FDMA, OFDM, etc.) do not
have to be specified before communication can take place. Mobile terminals and the fixed
infrastructure entities can negotiate the exact physical layer parameters dependent on their
respective capabilities and the required services that the link has to support. For example,
voice services require different quality of service (QoS) parameters (delay, bandwidth, etc.)
than video services which can be provided by choosing the appropriate physical layer
attributes.
This idea can be further extended to using the allowed bandwidth in the most efficient way.

RF modulation can be chosen on the basis of the optimum use of the spectrum available. This
concept could significantly increase the spectral efficiency of a given part of the spectrum.
The concept could also allow the rapid deployment of newly developed algorithms and
processing techniques for mobile communications without the lengthy process of these
being approved as new standards.
A completely open architecture/interface for lower layers would allow new air interfaces to
be used, which would dramatically increase spectrum efficiency, by optimally matching the
use of the air interface to the demands of the application.
11.2 Downloading Technologies for SDR
The mobile terminal may contain one or more levels of programmability. Figure 11.2 shows
four programmable items – configurable hardware, a digital signal processor, a general
purpose processor, and a customer subscriber identity module (SIM). The left side represents
a layered stack of the processing that is carried out for the communication data flow. Note that
the mapping of functionality to these layers can vary for every terminal design. Also one
function could be composed of parts from multiple layers. For each of the blocks in the figure,
the content sent to the terminal can be divided into program code or data.
Software Defined Radio: Origins, Drivers & International Perspectives314
Figure 11.2 Programmable parts of a terminal
To minimize the number of bits to be downloaded (bandwidth is a scarce resource) it seems
reasonable to avoid replacing all of the layers at the same time. Hence, the interfaces between
the layers will probably have a longer lifetime than the individual layers.
2
Only in the case of
functions spanning multiple layers would some parts of adjacent layers need to evolve
simultaneously. This either requires a simultaneous update, or layers that can function
with two or more versions of an adjacent layer.
11.2.1 Granularity
For each of the layers, a choice can be made for the granularity of the downloaded code.
Options are:
† A full image download, e.g. replacing every byte of CPU program code with a new

program. This is typically an expensive operation in terms of bandwidth.
† A partial image download, e.g. replacing a part of the DSP’s layer 1 protocol stack. Such a
partial image can contain one or more components. Partial image downloading requires a
mechanism that allows existing components to communicate with further components that
may be downloaded in the future.
Parameters or settings, where the existing code is instructed to change the current mode of
operation, or is provided with new data that alters its behavior, e.g. a new user menu or a
command to use a different frequency band. Strictly speaking this is a partial download, but
the relationship between the transferred data and the memory image is not obvious.
For some layers, both a full image download as well as a partial image download may be
supported – the partial image download for evolution of the individual components, and the
full image download as a bootstrap for evolution of the system’s partial download architec-
ture. Using partial image downloads more sublevels can be created. Figure 11.3 shows an
additional Java applet level. The different shapes of component connections indicate that
components only ‘fit’ at certain places.
If partial downloading is supported, the number of downloadable components could still be
restricted, due, e.g. to a limited amount of memory to store downloaded components or to the
binding mechanisms chosen to connect the components. The latter can also restrict the
number of times a component is replaced by another.
Software Download for Mobile Terminals 315
Figure 11.3 Partial downloading levels
2
Although, in time, even this may evolve; cf. the concept of programmable protocol interfaces within the OPtIMA
framework described by Klaus Moessner in Chapter 12.
11.2.2 Component Communication and Binding
Communication occurs at two levels, first, between the layers shown in Figure 11.2 and
second, between the components inside a layer. Communication between two layers occurs
either through some form of asynchronous processor communication (e.g. between CPU and
DSP) or via a software gateway (e.g. Jini).
For asynchronous processor communication a number of options exist, e.g. shared

memory, interrupts, message queues, and I/O ports. Typically, a combination of these is
used. For communication between components running on the same processor, the above
mechanisms could also be used, which would allow a component’s function to migrate to
another processor. If this is not required, the components could use synchronous function
calls or method invocations to communicate.
Binding is required to make sure that components can find each other. In the case of a full
image download, all software can be linked together before download to resolve all external
references. In the case of a partial image download, the image either has to be altered after
downloading but before being used, or the image has to use an indirection. Examples of
indirections are function pointers and software interrupts. Whichever mechanism is chosen
will introduce a performance penalty. Applying a component object model (COM) for
embedded applications will not typically cause more than 5% performance degradation on
modern 32-bit processors.
The characteristics of the storage devices influence the binding. If a program is stored in
nonvolatile memory (e.g. a FLASH memory), the characteristics of this memory should be
considered. While a program stored in RAM memory can be altered freely, a program stored
in nonrewritable memory typically needs a form of indirection to pass control to an upgrad-
able component.
11.2.3 Content Function
The classification of the received or transmitted content in the terminal varies with the layer it
passes through. What is data, and what is not data, depends on the layer. A lower layer might
classify input as voice, video, and data; a higher layer might classify that data as an active
program like a Java applet.
To prevent ambiguity (data can be anything) we will classify the content in relation to the
final ‘function’ that the content has for the terminal. Some classifications are:
† application: the user application controlling the content (e.g. voice-telephony, WWW-
browser);
† active/passive: indication of whether the content is an active program (e.g. native code or
interpreted code) or a passive object (e.g. a parameter or an address book entry);
† performance: in cases where the content is an active program, an indication whether the

program’s execution requires response times that could conflict with requirements of other
programs;
† streaming/nonstreaming: where the content is passive, an indication whether it is part of a
continuous stream (voice or video) or part of a message with a limited size (still picture, e-
mail, SMS message).
Software Defined Radio: Origins, Drivers & International Perspectives316
11.2.4 Installation
When correctly received and authorized content has arrived, it can be installed. Depending on
the architecture and the kind of content, three installation scenarios may be envisaged:
† a special installation mode, where the entire terminal is taken off-line to install new
content, e.g. this could be a part of the terminal start-up, thus forcing a terminal reset
after installation;
† an off-line installation, where a part of the terminal that is (temporarily) not used can be
upgraded, while in the meantime the customer is offered a system with limited function-
ality;
† an on-line installation, where a part of the terminal that can still be used is upgraded.
Different kinds of content (a new entry for an address book, or a new voice codec) might
require a different content installation scenario.
11.2.5 Terminal Wide Aspects
Content sent to the terminal can conflict with the terminal’s resources. Data files can fill up
the system’s memory, or cause memory fragmentation problems due to the behaviour of data
driven memory. In addition, program code can cause lock-ups or heavy processor usage,
claim more bus throughput, and alter system latencies.
Allowing a terminal to download new content, upgrade its basic functionality, and recon-
figure its hardware, requires additional efforts to guarantee terminal wide integrity. For
example, terminal latency cannot be guaranteed in advance if any component can be
upgraded without restrictions. Hence, a mechanism to ensure good system level behavior
is necessary. The careful selection of which components can be upgraded on whose authority
seems a minimum precaution. Resource allocation for those components can be done at
activation time (worst case allocation) or by a run-time mechanism (e.g. a quality of service

mechanism).
11.2.6 Version Management
Although not discussed further here, we want to state that partial downloading and the
evolution of components increases the need for version management. This raises questions
like: which version can cooperate with which other version? And can a version from one
provider be replaced by a version from another provider?
11.3 Standards for Downloading
Standards are important in mobile telecommunications as they are designed to encourage
market growth, promoting competition while allowing interworking of equipment from
different manufacturers.
Software downloading at any level in a system, using conventional standardization proce-
dures, would lead to unacceptable complexity and delay. For true software downloading, new
approaches to standardization are required which will allow dynamic services, applications,
Software Download for Mobile Terminals 317
and air interface characteristics to be defined without the need for detailed protocol specifica-
tions.
Today, the most important two bodies for future generation cellular radio standards are the
third-generation partnership project (3GPP) [2] and the ITU’s international mobile telecom-
munications activity (IMT-2000) [3]. Currently, standards are being written for 3G that
should allow the downloading of software (at all protocol stack levels) in future products.
11.3.1 Mobile Standards – 2G/3G Cellular
Many bodies and standardization activities could potentially be important in influencing
standards for software downloading. The key standards for mobile cellular radio systems
where software download is being considered, or will need to be considered are as follows.
11.3.1.1 GSM
Within 3GPP GERAN, software download standards for GSM are being developed within the
context of:
† STK, SIM application tool kit
† mobile execution environment
3

(MExE)
11.3.1.2 3G Standards
The 3GPP and 3GPP2 (UWCC) organizations are developing:
† standards for UMTS UTRA FDD and TDD modes
† GSM/EIA-41 networks
Various groups and fora are important in influencing the direction and definition of future
telecommunications standards. The most important ones relating to software radio are the
SDR Forum, the Enhanced Soft Radio Forum, and various software industry middleware
open architecture initiatives, summarized below. The ways in which the SDR Forum is
interacting with and influencing standardization are described by Alan Margulies in Chapter
3ofSoftware Defined Radio: Origins, Drivers and International Perspectives (Tuttlebee, W.
(Ed.), John Wiley & Sons, Chichester, 2002).
11.3.2 Software Standards
Middleware is the term used in the computer industry to describe a set of functions that make
it easy to use communications services and distributed applications. The requirements for
middleware to support software downloading are not yet fully determined. A central question
is the extent to which middleware should support software download, or be an enabling
technology for downloading. Middleware components may reside in terminals or in
Software Defined Radio: Origins, Drivers & International Perspectives318
3
For details of MExE, see Pubudu, C., ‘First steps to software defined radio standards: MExE, the mobile
execution environment’ in Software Defined Radio: Origins, Drivers and International Perspectives, Tuttlebee,
W. (Ed.), John Wiley & Sons, Chichester, 2002, Chapter 9.
networks. Middleware interfaces, objects, and protocols are required for future software
downloading.
11.3.2.1 IEEE P1520
A standard is being proposed for application programming interfaces (APIs) for networks [4].
The objective of the IEEE P1520 group is to enable the development of open signaling,
control, and management applications as well as higher level multimedia services on
networks. The scope of the networks considered extends from ATM switches and circuit

switches to hybrid switches such as high speed IP switches and routers that provide for fast
switching of IP packets over an ATM backbone. A diagram of the software architecture for
P1520 is shown in Figure 11.4. Further detail on P1520 may be found in Chapter 12.
11.3.2.2 CORBA
The common object request broker architecture (CORBA) is an emerging open distributed
object computing infrastructure being standardized by the object management group (OMG)
[5]. CORBA automates many common network programming tasks such as object registra-
tion, location, and activation; request demultiplexing; framing and error handling; parameter
marshaling and demarshaling; and operation dispatching. Real time ORB endsystems are
designed to provide end to end quality of service guarantees to applications by vertically
integrating CORBA middleware with OS I/O subsystems, communication protocols, and
network interfaces.
One university implementation is TAO [6]. TAO is targeted at real time systems with
processing demands so great that distribution is necessary. Moreover, these types of real time
system can often benefit from using CORBA services such as the event, time, and persistence
services. Consider the CORBA event service, for example, which simplifies application
Software Download for Mobile Terminals 319
Figure 11.4 The P1520 reference model (July, 1998)
software by allowing decoupled suppliers and consumers, asynchronous event delivery, and
distributed group communication. The relevance of CORBA to software downloading is that
it represents a standard for the middleware, which can best be defined as a framework for the
deployment of software objects over networks. This deployment certainly includes the down-
loading of objects to remote devices.
11.3.2.3 OPC
The charter of the OLE for Process Control (OPC) Foundation [7] is, ‘‘ To develop an open
and interoperable interface standard, based upon the functional requirements of OLE/COM
and DCOM technology, that fosters greater interoperability between automation/control
applications, field systems/devices, and business/office applications.’’ This is relevant to
software downloading as a candidate middleware solution that allows ‘software objects’ to
be downloaded to remote devices, in a similar way to CORBA, but using Microsofte DCOM

technology.
Using the latest advances in distributed object and middleware technologies (P1520,
CORBA, OPC, etc.) can enable the development of autonomous applications capable of
making decisions about adapting the flow of information.
11.4 Seamless Upgrading ‘On the Fly’
The availability of seamless software upgrading in mobile phones can allow the performance
of software maintenance while the phone is in use. Software upgrading can thus be done
without any interruption of service to, or interaction with, the user of the phone. The user can
continue to make use of the phone even while the software upgrade takes place. The down-
load of the new software parts can be done via the air interface. Such download techniques are
already being used to provide rapid introduction of new services, flexible and interactive
personalized subscriber services, and operator customization of the handset interface [8].
A short classification of approaches to the problem of dynamic or seamless software
upgrade is given here. A more detailed classification can be found in [9]. A very good and
broad overview about ‘on-the-fly’ program modification systems is given in [10].
Three main categories can be distinguished:
† Hardware-based approaches – such approaches solve the problem by employing a redun-
dant CPU and redundant peripherals, which are updated with the new software while the
old one continues to run. After a phase of reconfiguration, a switchover from the old
software running on the redundant hardware takes place.
†X An advantage of this approach is that the software architecture remains almost unchanged
but the shortcomings are the following:
– additional cost, for the specialized and redundant hardware
– limited scalability of computing power
– problems of data consistency during the reconfiguration phase
†X Examples are known from the telecommunication industry where PABXs with a double-
processor architecture have been developed.
† Procedural (software-based) approaches – these offer the exchange of procedures in
Software Defined Radio: Origins, Drivers & International Perspectives320
running programs. The system is updated by exchanging old procedures with new proce-

dures. As this is only possible when the old procedure is not active, special checks have to
be performed for each upgrade. This approach further suffers from being not very flexible.
It seems to be very difficult to add new features and services to a system just by changing
some existing procedures in the running software. In addition, the approach depends on
special linker and/or special support from the operating or runtime system enabling for
replacing procedures.
† Service-oriented (software-based) approaches – these require a special software architec-
ture based on a client/server relationship between the replaceable software units. Commu-
nication between the units is only provided through well-defined interfaces. This approach
fits very well with modern object-oriented software design found already in embedded
systems. A software architecture for reconfigurable systems applying this approach is
suggested in [11].
The approach presented later in this chapter belongs to the service-oriented class. It does
not require any modification to compilers, linkers, or other development tools. It is based on
some widespread abstractions like multi-threading and message-based communication being
supported by the underlying runtime system.
11.5 Security of Download
This section presents the major architectural elements of two varieties of secure downloading
for a digital mobile phone. The first is for a system supporting the downloading of applica-
tions. The second is for a system that supports downloading of (new) native software and
other information to be stored directly by the platform.
The architectural elements of application downloading are presented, followed by the main
elements of the native software downloading system. The diagrams and text of this section
provide only a preliminary snapshot of the primary elements of a system necessary to
securely download content and/or software into a digital mobile phone.
11.5.1 Secure Downloading of Applications
Secure downloading to mobile terminals is just one of the components of a full communica-
tions system; Figure 11.5 shows the other main components. In this diagram, the digital
mobile phone is identified as the client. The client can request content and expect to receive
it, but it may also receive unsolicited content. Content originates at a service provider,

identified as the Origin Server in the figure. The third major component in the diagram is
a Gateway which, depending on the type of service being provided, may reformat or modify
the content coming from the server. It should be noted that end-to-end security between the
client and server must be possible.
For secure downloading there are two classes of requirement. The first is for secure,
possibly two-way, communication for World Wide Web-based applications, and for various
types of wireless telephony applications. The second requirement of secure downloading is
the provision of a mechanism to download new or modified software and data onto the
components of the phone’s (client’s) native platform. Figure 11.6 shows this being done
from the servers labeled ‘server/gateway’, with software from the manufacturer, or by using
wireless application protocol (WAP). The security aspect of this download should be based
Software Download for Mobile Terminals 321
(for efficiency reasons) on the security layer of WAP. The protocol for native software
downloads can be implemented with a separate download mechanism.
11.5.2 Secure Downloading of Native Software
A primary goal for implementing secure downloading of native software is to maximize soft-
ware reuse. Applications for this native software download capability include downloading
new services to a terminal, updating existing platform software with a newer version, and
installing bug fixes in the phone. An important benefit of this is that the terminal manufacturer
can control both ends of the download, and therefore much of the handshaking that must take
place at runtime, using a service like wireless application protocol (WAP). Figure 11.7 shows a
proposed architecture for secure native software downloading. Current thinking is that it is
possible to have unsolicited modifications of a client. Requesting, when required, can be done
via WAP applications or by an out-of-band mechanism (voice channel to a service center
representative).
Software Defined Radio: Origins, Drivers & International Perspectives322
Figure 11.5 Components of a secure downloading system
Figure 11.6 Two types of secure downloading
11.6 Software Architectures for Download
One possible software architecture for a terminal that can accept downloaded software for

any of the above reconfiguration types is shown in Figure 11.8. This architecture shows that
drivers could be used to provide an interface between the lower layers of the protocol stack
and the hardware used for the nonconfigurable physical layer functions. More programmable
functions, such as software user applications, sit at the top of the architecture supported by an
applicatiion program interface (API).The upper layers of this architecture could be imple-
mented on a virtual machine.
Software Download for Mobile Terminals 323
Figure 11.7 Architecture for downloading native software
Figure 11.8 A possible terminal software architecture
The mechanism for downloading of new software can be either ‘user pull’, where the
terminal user actively searches for new software to download, or ‘push’, where the terminal
manufacturer, service provider, or the network operator forces a terminal to have new soft-
ware. It is also possible that some scenarios for push and pull are possible where the end user
can decide whether or not to accept a new terminal configuration. Also possible is a scenario
where the user makes a request for new software (‘pull’) which is denied.
Figure 11.9 shows how downloaded software can be partitioned into four domains. One of
the major potential challenges for both terminal and network manufacturers is to define
interfaces which open up the terminals and networks to reconfiguration but still allow reliable
and consistent performance. Reconfigurabililty that is kept under the control of the manu-
facturers (closed) of the equipment concerned is the easiest to manage. It is more revolu-
tionary to consider reconfigurability where the terminals and networks become a platform for
the introduction of new services and applications from third party sources (open). Open
standards have been widely acknowledged as being a key factor in the rapid growth of the
GSM market, for example, and it may be expected that an open approach to reconfigurability
will yield the most rapid growth of new applications, services and user benefits.
The four software downloading domains are:
† native/closed – for terminals without a compiler or interpreter where the manufacturer has
complete control of software running on any particular terminal by downloading execu-
table code;
† interpreted/closed – where the terminal manufacturer has full control over the software,

but where the terminal uses an interpreter/compiler or virtual machine to convert down-
loaded software into executable code
† native/open – where the terminal can run executable code from any source
† interpreted/open – where the terminal downloads software from any source which is
interpreted into executable code using a compiler/linker or virtual machine.
The most challenging domain is the design of a native/open architecture which would
Software Defined Radio: Origins, Drivers & International Perspectives324
Figure 11.9 Software downloading domain
allow any third party executable to run on any terminal. The least technically challenging
scenario is the native/closed, where known and fully tested executable code is downloaded to
the terminal. If downloadable code comes from the terminal manufacturer it can be easily
downloaded from the Internet.
Another way of classifying software downloading is consider how much of the software is
to be replaced. Either:
† full, where all the executable code for a terminal is replaced; or
† partial, where only parts of the executable code are replaced, and some kind of binding is
required to combine new code with the remaining original code.
If a linker is required then it may be possible to run this on one processor in a terminal to
link the code for another processor. The only likely scenario where a full download is
performed is when trusted closed native code is downloaded.
The most challenging domain in Figure 11.9 with regard to terminal design is the inter-
preted download for all the software required for a terminal. The processing and memory
resources needed to define all the functions that are required using an interpreted language
would be very high.
Generally, the easiest form of downloading to implement is that of non-native partial code
in non-native code, e.g. in the MExE standard, where Java is used for platform independent
applications.
The bandwidth requirements for download increase as more code is required. For example,
if the GSM phone protocol software (typically 256 kBytes ROM) was to be replaced over the
air, using a GSM data channel at 14.4 kbits/s, the downloading time would be approximately

2.5 min. Of course, this could be significantly reduced if only compressed differences in
software were sent over the air interface. For 3G protocols the code space will be significantly
higher.
11.7 Software Download Today – Digital TV
In Europe, with the advent of the digital video broadcasting (DVB) standards, a revolution
has been occurring in the broadcast television marketplace over the last few years. In the UK,
for example, most households today have the option of receiving digital television via cable,
satellite, or terrestrial DVB channels. While integrated television sets, IDTVs, are becoming
increasingly available, initial products have been set top boxes for one of these three stan-
dards which allow existing analog televisions to receive and display the new multichannel
digital services.
Most of the digital TV set top boxes currently on the market contain FLASH memories that
can be reprogrammed in the field. The set top boxes contain a boot loader that can load a new
memory image into the video memory, and after the image has been received it reprograms
the FLASH with this image. If the customer wants to use the set top box during the download,
then the download is aborted. This, and the fact that a set top box can be powered down or
might be disconnected, means that the latest version of the memory image has to be broadcast
repetitively.
Although not yet commercially exploited, it is technically possible to send Java byte codes
instead of native code to the set top box. Experiments to use Java on a set top box are ongoing,
as well as a standardization effort within the DVB Project [12]. Some extensions to the
Software Download for Mobile Terminals 325
existing Java interfaces will be made as some of them assume Internet access, which is not
guaranteed, since the set top box may not always be online. For a Java applet to start running
on a set top box, only a few of its classes have to be loaded in the set top box. However, the
usual Java load on demand mechanism is handled differently at lower layers in the software;
classes are typically preloaded. If a class is not preloaded, the applet will have to wait until the
requested class is found in the broadcast (downloaded) transport stream.
Java has its own way of preventing version conflicts. If a new class is needed, it is loaded
from a specific site, or, in the case of a set top box, it is loaded from a specific broadcast

channel. This specific site is either local, for system classes, or it is the same site that provided
the class that initiated the download. All classes for an application are either standard classes
or they come from the same site, so there are no conflicts with (old or incompatible) versions
from other sites. Version conflicts can only exist if the provider makes a mistake, if other
system classes are expected, or if out of date classes are still stored in persistent memory. The
revenue potential of downloaded applications and services in the consumer broadcast market-
place is such that this area of activity is developing fast and lessons will be learned, many of
which may be transferable to the SDR mobile phone arena.
11.8 ‘Over the Air’, ‘On the Fly’ Reconfiguration: A Practical Example
The feasibility of reconfiguration of upgrading protocols ‘on the fly’ using ‘over the air’
download has been demonstrated by the authors through practical reconfiguration experi-
ments.
These reconfiguration experiments have been based on an existing demonstrator capable of
providing wireless web access via the digital enhanced cordless telecommunications
(DECT), short range wireless voice and data standard [13]. This feature is put to good use
in our reconfiguration demonstrator, since the user selects the items to be downloaded using a
web browser that runs over the actual DECT system to be reconfigured.
We selected two DECT subsystems to be the subject of our reconfiguration experiments.
These items were identified as being demonstrable within a short time, given the status of the
existing demonstrator, as well as being realistic – something operators might really want to be
able to do in the real world. Both of the reconfiguration examples have a genuine effect on the
quality of service as seen by the application using the DECT system.
The first and most straightforward of the reconfigurations that have been demonstrated is a
simple parameter value adjustment within the DECT prototols. The MAX_LIFE parameter is
a parameter within the DECT specification that adjusts the maximum number of retransmis-
sions allowed at the user plane multiple access level. The effect of changing this parameter
can clearly be seen in the metrics collected by the demonstrator platform. It is even possible
to see the effect of changing the parameter to certain values that are out of specification.
The second and more challenging scenario is replacement of a complete algorithm within
the protocol stack, for which the CRC algorithm was selected. The protocol stack can be

reconfigured to replace a deliberately defective CRC algorithm with a corrected version.
Both of these reconfigurations occur on the fly, and the new configuration takes effect
without any need to kill and restart the DECT system.
Software Defined Radio: Origins, Drivers & International Perspectives326
11.8.1 Architecture
The system architecture used for the reconfigurability experiments is shown in Figure 11.10.
The DECT system is shown at the bottom of the diagram, with the terminal, known as the
‘portable part’
4
(PP), on the left and the base station, ‘fixed part’ (FP), on the right. The web
browser communicates over DECT using the user plane (U-plane), in the normal manner of
our existing demonstrator. Access to the web is redirected via DECT by adding a module to
the top of the DECT stack that acts as a web proxy. The browser is simply configured to route
all traffic via port 80 on the local host instead of trying to access the outside world directly.
To each side of the link has been added a reconfiguration manager which is connected to
the DECT control plane (C-plane). Consequently, messages pertaining to reconfiguration are
kept entirely separate from the user data (e.g. protocol) carried by the U-plane.
A special protocol for reconfiguration related messages has been designed for use by the
reconfiguration manager peer entities. These messages are fed to DECT using a spare C-plane
message type. This makes the contents of these reconfiguration messages opaque to DECT,
Software Download for Mobile Terminals 327
Figure 11.10 Architecture of the DECT reconfiguration demonstrator
4
‘Fixed part’ and ‘portable part’ are the DECT terminology for ‘base station’ and ‘terminal’, respectively; the
terms are used here for consistency with the DECT specifications.
which conveys such messages verbatim to the peer. In consequence, there is a virtual channel
between the two reconfiguration managers for reconfiguration specific protocol data units
(PDUs).
When the user triggers a reconfiguration, a transient process is created on the web server
that sends a specification of the desired configuration to the fixed part reconfiguration

manager. The reconfiguration web page is hosted by one of our local servers. This is
programmed to make a separate IP connection to send a specification of the reconfiguration
operation to the reconfiguration manager in the fixed part.
The task of downloading a new configuration might include compilation and linking of
source code, expansion of a compressed image, or loading of a new DLL; whichever of these
operations are appropriate will vary according to circumstances. Reconfiguration usually
requires making a change to both the network side and to the mobile side, but there are
exceptions to this rule. For example, upgrading of old units may only require a reconfigura-
tion of the portable part.
11.8.2 Basic Operation
The basic sequence of operations necessary to perform a reconfiguration of our DECT
demonstrator is as follows:
† the user connects Netscape (or Internet Explorer) over DECT and surfs a little
† the user decides to upgrade
† the user connects to the reconfiguration web page and makes a selection
† the desired update is downloaded and verified
† the system switches over to the new configuration
† the user continues to use his web browser over the new configuration
Note that, in general, both sides of the DECT system must be reconfigured, so that both sides
have a compatible configuration. A more detailed description of the reconfiguration proce-
dure is given in Section 11.8.4.
11.8.3 Example Reconfigurations
The user may choose and activate alternative configurations using Netscape or Internet
Explorer running wirelessly over DECT. We now describe the two types of reconfiguration
we have implemented.
11.8.3.1 Protocol Parameter Upgrade
Figure 11.11 shows the control for the MAX_LIFE parameter, which affects the DECT error
correction services. It determines the maximum lifetime of packets (i.e. the number of
possible retransmissions) in the MAC Layer that have not yet been acknowledged by the
peer. This parameter can be adjusted from one to seven TDMA frames or may be set to zero,

to indicate that the packet should continue to be retransmitted until it has been received
without error [14].
When the DECT wireless channel is poor, due to adverse propagation conditions, adjust-
ment of the MAX_LIFE parameter has a measurable effect on link quality.
Software Defined Radio: Origins, Drivers & International Perspectives328
We showed that the user could affect the throughput of the link, as reported by monitoring
tools, by adjusting this parameter by way of an over the air reconfiguration. We have also
experimented with setting values that are outside the officially sanctioned range. Interest-
ingly, higher values were found to reduce the well-known problems associated with running
TCP/IP over a wireless link.
11.8.3.2 Algorithm Upgrade
Figure 11.12 shows the control for reconfiguring the CRC algorithm used by DECT to check
whether packets have been received correctly. This has a crucial role in the operation of the
link and affects the data throughput rate.
To prove the concept of actually replacing running software within an active protocol
stack, rather than the easier task of simply changing a parameter, we installed a deliberately
defective version of the CRC algorithm in our equipment. We then showed that we could
successfully replace the broken module with a correct version using an over the air reconfi-
guration.
Obviously, we had to ‘break’ the module in a way that still allowed a reasonable quality of
link between the fixed part and portable part. We chose to install a CRC algorithm that always
reports that the packet has been received correctly, even if it contains errors. This has an
obvious effect on the quality of the link, so we are fortunate that our use of the hypertext
transfer protocol (HTTP) is reasonably tolerant of any errors received. In most cases, it is only
necessary to reload any text or images containing errors.
Software Download for Mobile Terminals 329
Figure 11.11 Max life value selection
Figure 11.12 CRC algorithm selection
Using over the air reconfiguration, we were able to replace the broken CRC algorithm with
a correct version, leading to an obvious improvement in quality. It does this by unlinking a

data link layer (DLL) from the protocol stack and linking in a replacement. This is carried out
on an active system, without any need to kill and restart the program.
A new protocol has been designed for reconfiguration messages passed between the
reconfiguration managers, one of which is at the fixed side and the other at the portable
side. Each reconfiguration manager also needs to be able to communicate with its local part of
the DECT system, for which a set of command signals have been defined.
Signals are passed between the reconfiguration manager and the local part of the DECT
system via the C-plane (SAP) service access point.
5
Reconfiguration related communications
are tagged with a special identifier not used by DECT in order to distinguish them from
signals that would normally be passed between the DECT NWK Layer and a DECT LAP-C
entity. Two types of reconfiguration related signals must be distinguished; those to be
forwarded unchanged to the peer reconfiguration manager (RECFG) and those that are to
be acted upon by the DECT system itself INST):
† Signals of type RECFG are sent verbatim across the DECT system and DECT itself takes
no interest in their internal semantics. In fact, they are handled in exactly the same way
that the DLC would handle peer-to-peer messages from one of the DECT NWK layer
entities. Consequently, RECFG messages must contain a suitable DECT protocol descrip-
tor that distinguishes them from messages associated with one or other of the NWK
entities. In effect, the reconfiguration manager is treated as being an additional NWK
layer entity.
Also contained within the message passed across the DECT link is a type field to distinguish
between different types of message, e.g. test link, reply link. This will be followed by any
parameters that a particular message type needs to convey. For example, the NewConfig
message must convey a specification of the reconfiguration to be performed across the DECT
link to the other reconfiguration manager.
† Signals of type INST are instructions from the reconfiguration manager to the local part of
the DECT system. In contrast to the previous case, no part of these signals is transmitted
across the DECT link. The relevant instructions that may be given are as follows:

– MAX_LIFE – sets the U-plane maximum lifetime. An additional byte specifies the
desired value.
– RELINK – causes a new DLL to be loaded into DECT. For example, a new CRC
algorithm can be specified. The new DLL comes into use without any need to kill and
restart the DECT system.
– REVERT – the system reverts to the previous configuration. This is used for error
recovery should a new configuration be found nonviable.
11.8.4 Reconfiguration Manager
The reconfiguration manager has the following states:
Software Defined Radio: Origins, Drivers & International Perspectives330
5
Service access points (SAPs) are explained by Klaus Moessner in Chapter 12.
† idle state – the initial state
† negotiation state – to determine whether the new configuration is useable
† success state – indicating a successful reconfiguration
† failure state – indicating an unsuccessful reconfiguration
Note that the success state and the failure state are both functionally identical to the idle
state, so they are represented by the same specification and description language (SDL)
diagram. Following a successful or failed reconfiguration, a new reconfiguration can be
attempted immediately by virtue of the fact that the success and failure states will respond
in the same way as the idle state.
For convenience of implementation, the reconfiguration manager in the portable part is
defined identically to that in the fixed part. In our experiments, we chose to have each
reconfiguration initiated from the fixed side, but this does not necessarily have to be the
case. If it were found desirable for the portable side to be able to initiate a reconfigura-
tion, the same reconfiguration managers could be used unaltered. Whether the reconfi-
guration manager is in the portable side or the fixed side makes no difference to the state
machine.
11.8.4.1 Idle State
An SDL [15] diagram of the idle state is shown in Figure 11.13. Execution begins at the oval

symbol at the top of the diagram, initializing the ‘retry counter’ to zero and entering the idle
state to await a signal from another entity. The actions taken from this point will depend on
which of several signals are received.
When the user initiates a reconfiguration using the web browser, a CGI script on the web
server sends a ConfigSpecReq message containing a specification of the configuration to be
performed to the reconfiguration manager at the fixed side. The fixed side reconfiguration
manager passes this specification on to its peer reconfiguration manager in the portable side
and then sends an instruction to the local part of the DECT system to initiate the relevant
reconfiguration. A timer is started, to wait for the peer entity to send a similar instruction to its
side of the DECT system.
When the timer expires, the fixed side initiates a test sequence to see whether the new
configuration is working correctly. A test link signal is sent to the peer reconfiguration
manager and a new timer is started so another attempt can be made if no reply is received
to the first test signal. The reconfiguration manager moves into the negotiation state.
11.8.4.2 Negotiation State
The negotiation state of the reconfiguration manager is shown in Figures 11.14 and 11.15.
The objective for this state is for both sides of the link to come to a common understanding of
whether the two sides have been reconfigured correctly. This is done by verifying that
communication is possible over the new link, encompassing transmission and reception in
both directions.
When the portable side receives the test link message sent by the fixed side, a reply link
message is sent back to the fixed side reconfiguration manager. If this reply link message is
received, that side of the link knows that communication is possible in both directions.
Software Download for Mobile Terminals 331
Software Defined Radio: Origins, Drivers & International Perspectives332
Figure 11.13 Reconfiguration manager: idle state
However, the portable side can only be certain that the link works in one direction. Therefore,
a confirm link message is issued by the fixed side.
When the portable side receives the confirm link message, the reconfiguration manager
concludes that the reconfiguration has been successful and sends an acknowledge link

message to tell its peer that the test should be terminated.
Should the reply link message not be received within a certain time limit, another test link
message is sent (see Figure 11.15). Up to three attempts are made, in our implementation,
before concluding that the link is unusable. A similar timer is used to send repeated confirm
link messages. In the portable side, an abort timer is started upon reception of the first test link
message – if this timer expires, the reconfiguration is considered to have failed.
11.8.4.3 Success and Failure States
Once the negotiation phase has been completed, the two reconfiguration manager peers
should agree whether or not the reconfiguration was successful. Irrespective of success or
Software Download for Mobile Terminals 333
Figure 11.14 Reconfiguration manager: negotiation state (part 1)
failure, both these states are functionally equivalent to the idle state, allowing another recon-
figuration to be performed at the user’s convenience.
11.8.5 Reconfiguration Procedure
The procedure for conducting a reconfiguration, with the sequence of messages between the
various entities, is summarized in Figure 11.16. The procedure operates essentially as
follows:
† The user browses to the reconfiguration web page using a web browser connected via the
DECT U-plane and selects the desired configuration.
† The web server runs a program using CGI which sends (via TCP/IP) a specification of the
desired configuration to the fixed part reconfiguration manager (FP-RM). This extracts the
specification from the message and forwards the new configuration to its peer in the
portable part (PP-RM), via the DECT C-plane.
† The FP-RM reconfigures the DECT fixed part (DECT-FP) by sending a command via the
Software Defined Radio: Origins, Drivers & International Perspectives334
Figure 11.15 Reconfiguration manager: negotiation state (part 2)
C-plane interface. This command is not forwarded to the portable part, but is acted upon
locally to perform the reconfiguration. The RM-FP then delays for a suitable interval to
give enough time for RM-PP to be reconfigured in a similar manner.
† When the RM-PP receives the new configuration from its peer, it sends the configuration

back to the DECT-PP, but in the form of a command rather than a message to be
forwarded. This causes the reconfiguration to occur.
† Once enough time has passed for both sides to have been reconfigured, the RM-FP starts
an attempt to confirm that the new configuration is working. It first sends a test link
message (via the DECT C-plane, of course) and waits for a reply link message to be
received from the RM-PP. If it receives this reply, it knows that the new configuration
works for messages in both directions.
† However, at this point the RM-PP can only be certain that the new configuration works in
the FP to PP direction, so the RM-FP sends a confirm link message. When the RM-PP
receives this message it knows that the new configuration works in both directions and
Software Download for Mobile Terminals 335
Figure 11.16 Message sequence chart for a successful reconfiguration