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 [...]... 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 322 Software Defined Radio: Origins, Drivers & International Perspectives Figure 11.5 Components of a secure downloading system Figure 11.6 Two types of secure downloading (for efficiency reasons) on the security layer of WAP... supported by an applicatiion program interface (API).The upper layers of this architecture could be implemented on a virtual machine Figure 11.8 A possible terminal software architecture 324 Software Defined Radio: Origins, Drivers & International Perspectives The mechanism for downloading of new software can be either ‘user pull’, where the terminal user actively searches for new software to download, or... 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 326 Software Defined Radio: Origins, Drivers & International Perspectives 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... DECT, 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 Software Defined Radio: Origins, Drivers & International Perspectives 328 which conveys such messages verbatim to the peer In consequence, there is a virtual channel between the two reconfiguration managers for reconfiguration... 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 330 Software Defined Radio: Origins, Drivers & International Perspectives 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... 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 332 Software Defined Radio: Origins, Drivers & International Perspectives Figure 11.13 Reconfiguration manager: idle state Software Download for Mobile Terminals Figure 11.14 333 Reconfiguration manager: negotiation state (part... 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 Defined Radio: Origins, Drivers & International Perspectives 334 Figure 11.15 Reconfiguration manager: negotiation state (part 2) failure, both these states are functionally equivalent to the idle state, allowing... 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 336 Software Defined Radio: Origins, Drivers & International Perspectives concludes that the reconfiguration has been successful The RM-PP sends an acknowledge link message to its peer carrying the meaning that the DECT-PP... offering the user many service possibilities with higher bandwidths The evolution of GSM occurs by the use of extensions to the GSM standard, high speed circuit switched data (HSCSD) and general packet radio service (GPRS), which both provide higher dates rates and, in the case of GPRS, a packet data capability A possible evolution path for the downloading of software is also shown in Figure 11.17 Simple . focused on ‘pure’ software radio, the former approach, whereas in Europe advocates argued that the latter, ‘pragmatic’ software radio, would prevail in terms. (Ed.), Software Defined Radio: Origins, Drivers & International Perspectives, John Wiley & Sons, Chichester, 2002. Software Defined Radio Edited by Walter