Software Download for Configurable Processors

The ability to download new functions into software-defined radio (SDR) basestations or handsets is the differentiating advantage of commercial SDR. Over time, SDR will address the needs of all of the interest groups in the cellular marketplace. Users will get a global phone, which converts to local standards as invisibly as a credit card converts to local currency. Third-party software downloads will allow access to services not supplied by a user's "home" network operator. Equipment manufacturers will be able to get to market fast by shipping a product with a core set of functions, knowing it can be easily upgraded to support the full feature set at a later date. Network operators will be able to upgrade basestations without an engineer physically visiting each location.

Although there are compelling advantages to SDR, serious concerns arise with downloading low-level software such as Field-Programmable Gate Array (FPGA) configurations, Digital Signal Processor (DSP) code, and micro-controller code into software radio basestations and handsets. This code can make the radio operate in different frequency ranges, with different power levels, and different modulation standards. All of the interest groups have legitimate concerns about the possible misuse of software downloads. Users worry about threats to their safety or privacy, equipment manufacturers are concerned about product liability if third-party software makes the handset operate illegally, network operators worry about losing revenue, and governments fret about the ability of SDRs to evade regulations.

Several industry groups and companies are studying software download, most notably the SDR Forum. The Wireless Application Protocol (WAP) Forum and the European Telecommunications Standards Institute, with its Mobile Execution Environment (MExE) specification for GSM, are working on related standards for Web access from a cellphone handset, which include guidelines for downloading high-level applications.

A download protocol for field upgrading low-level features in embedded equipment must address at least three issues: initiation, transfer, and installation.

In the case of devices that are continuously connected to the network, such as basestations, a download can be initiated by broadcasting new software to all devices at some convenient time. However, when devices are only occasionally connected to the network, such as handsets, this is not possible. Different devices will pick up the download at different times. A mechanism may be provided by which the network informs the handset of mandatory downloads, for example bug fixes, when it connects and ensures that these are completed before allowing the user to access network services.

The download protocol must ensure proper transfer, which has several components. Enough resources, such as memory and battery power, must be available to complete the download. Unauthorised third parties must not be able to determine which software is being downloaded or obtain a copy of the software for their own use. The software "image" must not be altered during the download process, either maliciously or as a result of errors in transmission. The software must be verified as being supplied by a trusted and authorised source. Finally, the software must be suitable for running on the handset and must supersede the software currently installed.

The main approach that has been suggested to address these requirements is the use of the standard Internet e-commerce protocol Secure Sockets Layer (SSL), or a derivative such as TLS or the WAP forum's WTLS. SSL provides an encrypted channel between a client and a server. It also verifies the identities of client and server using certificates signed by trusted third parties, and it detects alteration of the transferred data. SSL does not address issues such as resource availability or software version checking. An important advantage is SSL's ability to leverage off the existing e-commerce infrastructure, including standard Web server software, such as Apache.

SSL verifies the identity of the server, rather than the authorship of the image, downloaded from the server. Arguably, a download protocol should secure the image itself rather than the channel that the image passes down. This is the approach taken by secure email standards such as S/MIME and PGP. An advantage of this approach is that each image is individually secured, allowing certification of the software by multiple institutions, each of which can digitally sign the image. For example, a handset might require downloads to be signed by their manufacturers, the operators of their home networks, and the regulatory authorities of their home countries.

After download, an installation phase must address decompression of the software image and installation of links to new functions into operating system registries. A self-test with rollback to the previous software version if problems are detected is necessary to ensure that a failed download cannot leave the terminal unable to communicate with the network.

While the transfer phase must take place with the device connected to the network, installation will normally occur off-line. It will usually be impossible for the device to maintain connectivity while low-level software and hardware are being reconfigured. Installation may involve a hardware reset.

Apparently, a baseband processor containing a 32-bit microcontroller is desirable to implement the demanding protocols required for secure download. In a SDR, signal processing and interface functions, which in a single-standard radio would be implemented as fixed function ASIC hardware, are implemented using programmable logic. Programmable logic can be reconfigured rapidly to implement the computations required by radically different cellphone standards, such as CDMA and TDMA, while maintaining ASIC level performance. In addition, using programmable logic for interface functions increases flexibility and product longevity by allowing peripherals such as displays and A/D converters to be updated as better alternatives become available without expensive changes to the baseband chip.

While it is clear that SDR and many other embedded applications demand a single chip solution containing a microcontroller, system memory, and programmable logic to meet cost, power, and size constraints, the only devices currently available that address these requirements are the Configurable System-on-Chip (CSoC) products from Triscend. The 8032 based E5 family is currently shipping and, later this year, the company will introduce a second family using the wireless industry's standard 32-bit ARM7 TDMI microcontroller. The ARM7 is easily capable of supporting the algorithms needed to secure downloads. Key to the Triscend CSoC architecture is the Configurable System Interconnect (CSI) bus and CSI Socket. These make it easy to develop and debug an application where some functions are implemented in microcontroller code and others are implemented as "soft peripherals" in the SRAM programmed Configurable System Logic (CSL).

Whatever hardware platform is used, designers must realize that software downloads for remote field upgrades of equipment requires a transfer of trust from physical security and testing to cryptographic security and quality assurance. There are two quality issues related to field upgrades. First, the upgrade itself must be designed correctly. This can be tested in the normal way by downloading to a single device and submitting it to type approval.

The second issue is less straightforward—every device that receives a download in the field must function correctly afterward. It is possible that the new software will make use of hardware components in a different way than did the software in the device when it was tested after manufacture. Faults might have occurred undetected in components of the device that were not stressed by the previous software while the device was in the field. If programmable hardware elements are being reconfigured by the download, it is possible that previously unused pins will now be required by the design. Analog circuitry may be operating at different frequencies, different signal voltage levels, and different waveforms as a result of software changes.

For these reasons, some units in the field may no longer function correctly after the field upgrade. Furthermore, no specialist's test equipment is available to diagnose problems after a software download as it would have if an engineer had carried out the upgrade.

Therefore, statistical quality assurance must replace testing. For example, a manufacturer or regulator might hold back a number of handsets and bake them to accelerate failure mechanisms. When a software upgrade becomes available, it can be tested on this group of devices. The expected number of failures and the symptoms of the most common failures caused by installing the software in the field can then be extrapolated from this sample and used to make a decision about approving the software update for release.

The highest-profile use of field upgrading to date has been updating the proprietary 56-kbit K56 flex and X2 modems to the V90 standard through software downloads from the Internet. In the future, as CSoC devices gain acceptance, secure download protocols become standardized, and the quality control requirements are better understood, product field upgrades via downloads of low-level software will become commonplace in communications equipment. Customers will start to expect mid-life upgrades of basic equipment functionality, and manufacturers will benefit from an upgrade revenue stream and reduced field-support expenditure. Early adopters of software downloads can obtain great benefits, but must carefully consider security and quality issues.

About the Author