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

Open software architectures will allow terminals to become programmabletransceivers for radio, television, home-networks, and offices, furthering fixed mobile broad-cast integration.. 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 early1990s, when many people saw the technology as a solution to the problems of complex RFand 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.1Such reconfiguration can be achieved at all stages from design, through production, topost purchase use by the consumer

This chapter begins by introducing the concepts of software reconfiguration by downloadand then describes some of the important software technology issues Standards, security, andsoftware 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 thanthrough air interface reconfiguration Such applications are not restricted to the field ofmobile communications – the chapter thus includes a brief description of the present statusand 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 amobile phone terminal ‘on the fly’ is examined To exemplify the issues involved in suchreconfiguration, we describe the implementation of a practical demonstration of ‘on-the-fly’reconfiguration of air interface parameters and algorithms, making use of a wireless webbrowser 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.

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 trum management, bug fixing, new features, third party software creation, extra value tonetwork operators (their own customisations), personalization (customer’s own customiza-tions), and more Open software architectures will allow terminals to become programmabletransceivers 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 fromever faster cycles of innovations and obsolescence

spec-The following four areas are key potential arguments for the manufacture of terminals andintegrated circuit platforms for terminals that can be reconfigured by downloading newsoftware:

† Reduction in the number of different models – reconfiguration of terminals shouldallow fewer terminal variants to have to be manufactured to support different technicalstandards This allows the large scale manufacture of terminals, leading to lower unitcosts

† Last minute or deferred customization – the use of downloading means that the finalconfiguration of the terminal can be made even after deployment, so increasing thefunctionality of a product and reducing the likelihood of product recalls or returns It isalso possible to market the late customization of a product to end users, who may see theadvantages 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 developerscan develop innovative applications for the terminal, which should increase the appeal ofthe terminal to the end user, without the direct costs to the manufacturer of employing suchstaff

The disadvantages of software download include the difficult task of managing differentversions of software in the different terminals deployed in the field, as well as the problem ofensuring robustness in all user environments

11.1.2 Software Downloading Terminals

Commercial terminals using SDR technology will probably be available on the market bythe 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 supportthird-generation capabilities may not be available until about 2003 The key benefit to theterminal manufacturer is that the SDR technology will allow one hardware and softwarearchitectural platform to be used to address all possible world markets An estimate ofthe size of the potential market for SDR terminals has been made by the SDR Forum asabout 9.5 million handheld devices in 2001 timeframe, rising to about 130 million in2005

Downloading software over the air interface is only one way to achieve terminal guration, so care must be taken that other methods, such as reconfiguration via Bluetooth [1],

reconfi-IR, direct connection, smartcard, etc., are considered Further, the range of functionalitieswhich software download can be used to modify is very broad Figure 11.1 illustrates therange 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 thehardware 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 Thissoftware category has no connection with the operation of the protocol software

† Protocol changes – this category includes bug fixing – correcting mistakes made in thesoftware loaded on the phone at manufacture This level of upgrade also includes changesmade to a standard (e.g the emerging UMTS 3GPP standard) as it develops and isenhanced throughout its lifetime This category could also include changes made to thealgorithms used in a terminal, such as power control, that an operator may wish to effectafter field deployment of the terminal

† New codecs – this category includes the downloading of larger amounts of software thataffect 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 therest of the software in the terminal

† New air interface – this includes reconfiguration of the terminal to a completely differentair interface standard This is different from conventional dual mode terminals in that thesoftware for the new radio interface is not held in the terminal but is downloaded in someway

† Fully flexible air interface – this is the extreme case of a reconfigurable terminal where theair 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

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 airinterface The increasing power and reducing cost of digital signal processing will allow theuse of reconfigurable baseband processing in mobile handsets which will in turn permit theuse 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 nothave to be specified before communication can take place Mobile terminals and the fixedinfrastructure entities can negotiate the exact physical layer parameters dependent on theirrespective 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 layerattributes

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 Thisconcept 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 andprocessing techniques for mobile communications without the lengthy process of thesebeing 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 theuse 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 showsfour programmable items – configurable hardware, a digital signal processor, a generalpurpose 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 thatthe mapping of functionality to these layers can vary for every terminal design Also onefunction 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

Figure 11.2 Programmable parts of a terminal

To minimize the number of bits to be downloaded (bandwidth is a scarce resource) it seemsreasonable to avoid replacing all of the layers at the same time Hence, the interfaces betweenthe layers will probably have a longer lifetime than the individual layers.2Only in the case offunctions spanning multiple layers would some parts of adjacent layers need to evolvesimultaneously This either requires a simultaneous update, or layers that can functionwith two or more versions of an adjacent layer.

Parameters or settings, where the existing code is instructed to change the current mode ofoperation, or is provided with new data that alters its behavior, e.g a new user menu or acommand to use a different frequency band Strictly speaking this is a partial download, butthe 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 besupported – the partial image download for evolution of the individual components, and thefull 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 anadditional Java applet level The different shapes of component connections indicate thatcomponents only ‘fit’ at certain places

If partial downloading is supported, the number of downloadable components could still berestricted, due, e.g to a limited amount of memory to store downloaded components or to thebinding mechanisms chosen to connect the components The latter can also restrict thenumber of times a component is replaced by another

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 andsecond, between the components inside a layer Communication between two layers occurseither through some form of asynchronous processor communication (e.g between CPU andDSP) or via a software gateway (e.g Jini)

For asynchronous processor communication a number of options exist, e.g sharedmemory, interrupts, message queues, and I/O ports Typically, a combination of these isused For communication between components running on the same processor, the abovemechanisms could also be used, which would allow a component’s function to migrate toanother processor If this is not required, the components could use synchronous functioncalls or method invocations to communicate

Binding is required to make sure that components can find each other In the case of a fullimage download, all software can be linked together before download to resolve all externalreferences In the case of a partial image download, the image either has to be altered afterdownloading but before being used, or the image has to use an indirection Examples ofindirections are function pointers and software interrupts Whichever mechanism is chosenwill introduce a performance penalty Applying a component object model (COM) forembedded applications will not typically cause more than 5% performance degradation onmodern 32-bit processors

The characteristics of the storage devices influence the binding If a program is stored innonvolatile memory (e.g a FLASH memory), the characteristics of this memory should beconsidered 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 able component

upgrad-11.2.3 Content Function

The classification of the received or transmitted content in the terminal varies with the layer itpasses through What is data, and what is not data, depends on the layer A lower layer mightclassify input as voice, video, and data; a higher layer might classify that data as an activeprogram like a Java applet

To prevent ambiguity (data can be anything) we will classify the content in relation to thefinal ‘function’ that the content has for the terminal Some classifications are:

† application: the user application controlling the content (e.g voice-telephony, browser);

WWW-† active/passive: indication of whether the content is an active program (e.g native code orinterpreted 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 theprogram’s execution requires response times that could conflict with requirements of otherprograms;

† streaming/nonstreaming: where the content is passive, an indication whether it is part of acontinuous stream (voice or video) or part of a message with a limited size (still picture, e-mail, SMS message)

† an off-line installation, where a part of the terminal that is (temporarily) not used can beupgraded, 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) mightrequire 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 upthe system’s memory, or cause memory fragmentation problems due to the behaviour of datadriven 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 figure its hardware, requires additional efforts to guarantee terminal wide integrity Forexample, terminal latency cannot be guaranteed in advance if any component can beupgraded without restrictions Hence, a mechanism to ensure good system level behavior

recon-is necessary The careful selection of which components can be upgraded on whose authorityseems a minimum precaution Resource allocation for those components can be done atactivation time (worst case allocation) or by a run-time mechanism (e.g a quality of servicemechanism)

11.2.6 Version Management

Although not discussed further here, we want to state that partial downloading and theevolution of components increases the need for version management This raises questionslike: which version can cooperate with which other version? And can a version from oneprovider be replaced by a version from another provider?

11.3 Standards for Downloading

Standards are important in mobile telecommunications as they are designed to encouragemarket growth, promoting competition while allowing interworking of equipment fromdifferent manufacturers

Software downloading at any level in a system, using conventional standardization dures, would lead to unacceptable complexity and delay For true software downloading, newapproaches to standardization are required which will allow dynamic services, applications,

proce-and air interface characteristics to be defined without the need for detailed protocol tions.

specifica-Today, the most important two bodies for future generation cellular radio standards are thethird-generation partnership project (3GPP) [2] and the ITU’s international mobile telecom-munications activity (IMT-2000) [3] Currently, standards are being written for 3G thatshould 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 influencingstandards for software downloading The key standards for mobile cellular radio systemswhere 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 thecontext of:

† STK, SIM application tool kit

† mobile execution environment3

(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 futuretelecommunications standards The most important ones relating to software radio are theSDR Forum, the Enhanced Soft Radio Forum, and various software industry middlewareopen architecture initiatives, summarized below The ways in which the SDR Forum isinteracting with and influencing standardization are described by Alan Margulies in Chapter

3 of Software 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 formiddleware 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 enablingtechnology for downloading Middleware components may reside in terminals or in

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 softwaredownloading.

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 onnetworks The scope of the networks considered extends from ATM switches and circuitswitches to hybrid switches such as high speed IP switches and routers that provide for fastswitching of IP packets over an ATM backbone A diagram of the software architecture forP1520 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 distributedobject 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; parametermarshaling and demarshaling; and operation dispatching Real time ORB endsystems aredesigned to provide end to end quality of service guarantees to applications by verticallyintegrating CORBA middleware with OS I/O subsystems, communication protocols, andnetwork interfaces

One university implementation is TAO [6] TAO is targeted at real time systems withprocessing demands so great that distribution is necessary Moreover, these types of real timesystem can often benefit from using CORBA services such as the event, time, and persistenceservices Consider the CORBA event service, for example, which simplifies application

Figure 11.4 The P1520 reference model (July, 1998)

software by allowing decoupled suppliers and consumers, asynchronous event delivery, anddistributed 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 thedeployment 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 openand interoperable interface standard, based upon the functional requirements of OLE/COMand DCOM technology, that fosters greater interoperability between automation/controlapplications, field systems/devices, and business/office applications.’’ This is relevant tosoftware 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 DCOMtechnology

Using the latest advances in distributed object and middleware technologies (P1520,CORBA, OPC, etc.) can enable the development of autonomous applications capable ofmaking 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 donewithout any interruption of service to, or interaction with, the user of the phone The user cancontinue 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 arealready being used to provide rapid introduction of new services, flexible and interactivepersonalized subscriber services, and operator customization of the handset interface [8]

A short classification of approaches to the problem of dynamic or seamless softwareupgrade is given here A more detailed classification can be found in [9] A very good andbroad 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 dant CPU and redundant peripherals, which are updated with the new software while theold one continues to run After a phase of reconfiguration, a switchover from the oldsoftware running on the redundant hardware takes place

redun-†

X An advantage of this approach is that the software architecture remains almost unchangedbut 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

running programs The system is updated by exchanging old procedures with new dures As this is only possible when the old procedure is not active, special checks have to

proce-be performed for each upgrade This approach further suffers from proce-being not very flexible

It seems to be very difficult to add new features and services to a system just by changingsome existing procedures in the running software In addition, the approach depends onspecial linker and/or special support from the operating or runtime system enabling forreplacing procedures

† Service-oriented (software-based) approaches – these require a special software 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 approachfits very well with modern object-oriented software design found already in embeddedsystems A software architecture for reconfigurable systems applying this approach issuggested in [11]

architec-The approach presented later in this chapter belongs to the service-oriented class It doesnot require any modification to compilers, linkers, or other development tools It is based onsome widespread abstractions like multi-threading and message-based communication beingsupported by the underlying runtime system

11.5 Security of Download

This section presents the major architectural elements of two varieties of secure downloadingfor 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 andother information to be stored directly by the platform

The architectural elements of application downloading are presented, followed by the mainelements of the native software downloading system The diagrams and text of this sectionprovide only a preliminary snapshot of the primary elements of a system necessary tosecurely 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 tions system; Figure 11.5 shows the other main components In this diagram, the digitalmobile phone is identified as the client The client can request content and expect to receive

communica-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 modifythe content coming from the server It should be noted that end-to-end security between theclient 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 varioustypes of wireless telephony applications The second requirement of secure downloading isthe provision of a mechanism to download new or modified software and data onto thecomponents of the phone’s (client’s) native platform Figure 11.6 shows this being donefrom the servers labeled ‘server/gateway’, with software from the manufacturer, or by usingwireless application protocol (WAP) The security aspect of this download should be based

(for efficiency reasons) on the security layer of WAP The protocol for native softwaredownloads 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 ware reuse Applications for this native software download capability include downloadingnew services to a terminal, updating existing platform software with a newer version, andinstalling bug fixes in the phone An important benefit of this is that the terminal manufacturercan control both ends of the download, and therefore much of the handshaking that must takeplace at runtime, using a service like wireless application protocol (WAP) Figure 11.7 shows aproposed architecture for secure native software downloading Current thinking is that it ispossible to have unsolicited modifications of a client Requesting, when required, can be donevia WAP applications or by an out-of-band mechanism (voice channel to a service centerrepresentative)

soft-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 forany of the above reconfiguration types is shown in Figure 11.8 This architecture shows thatdrivers could be used to provide an interface between the lower layers of the protocol stackand the hardware used for the nonconfigurable physical layer functions More programmablefunctions, such as software user applications, sit at the top of the architecture supported by anapplicatiion program interface (API).The upper layers of this architecture could be imple-mented on a virtual machine

Figure 11.7 Architecture for downloading native software

Figure 11.8 A possible terminal software architecture