Reconfigurable SDR Equipment and Supporting Networks

WWiirreelleessss WWoorrlldd RReesseeaarrcchh FFoorruumm WWoorrkkiinngg GGrroouupp 33 --WWhhiittee PPaappeerr--

© 2002, WWRF 1

Reconfigurable SDR Equipment and Supporting Networks Reference Models and Architectures

Authors Information (alphabetically) – Editor: Didier Bourse

Nancy Alonistioti, University of Athens, [email protected] , tel.: +30 10 727 5653 Didier Bourse, Motorola CRM-Paris, [email protected], tel: +33.1.6935.2558

Soodesh Buljore, Motorola CRM-Paris, [email protected], tel: +33.1.6935.2566 Antoine Delautre, Thales Communications, [email protected] , tel: +33.1.46.13.27.40

Markus Dillinger, Siemens AG, [email protected], tel.: +49 89 636 44826 Rainer Falk, Siemens AG, [email protected], +49 89 636 51653

Dieter Greifendorf, IMS Fraunhofer Gesellschaft, [email protected], tel: +49 203 3783 152 Mirsad Halimic, Panasonic PMDO, [email protected], tel:+44 (0)118 902 9322 Tim Hentschel, Technische Universität Dresden, [email protected], tel: +49 351 463 32365

Quiting Huang, ETH ISL, [email protected], tel: +411 632 5240 Apostolos Kountouris, Mitsubishi Electric ITE-TCL, [email protected], tel: +33 299842632

John MacLeod, University of Bristol, [email protected], tel: +44 (0)117 9545189 Ashok Marath, ICR, [email protected], tel: +65 68709138 Linus Maurer, DICE, [email protected], tel: +43 699 12182643

Stefano Micocci, Siemens MC, [email protected], tel +39 02 27337116 Klaus Moessner, CCSR, The University of Surrey, [email protected], tel: +44 (0)1483 683468 Nikolas Olaziregi, CTR, King’s College London, [email protected], tel: +44 (0)20 7848 2889

Parbhu D. Patel, Panasonic PMDO, [email protected], tel:+44 (0)118 902 9323 Santhosh Kumar Pilakkat, [email protected]

Christian Prehofer, DoCoMo Communications Labs Europe, [email protected], +49 89 56824223 Tapio Rautio, VTT, [email protected], tel: +358 8 551 2326

Joachim Sachs, Ericsson, [email protected], tel: +49 2407 575 113 Andreas Schieder, Ericsson, [email protected], tel: +49 2407 575 237

Wolfgang Schott, IBM, [email protected], tel: +41 1 724 8476 Matthias Siebert,Comnets, [email protected]

Joerg Stammen, IMS Fraunhofer Gesellschaft, [email protected], tel: +49 203 3783 152 Shiao-Li Tsao, CCL/ITRI, [email protected], tel: +886 3 591 4651

Paul Warr, University of Bristol, [email protected], tel: +44 (0)117 9545166 Thomas Wiebke, Panasonic European Laboratories, [email protected], tel: +49 6103 766 161

Manfred Zimmermann, Infineon, [email protected], tel: +49 89 234 81636

Abstract – Reconfigurability of SDR equipment is widely seen as one of the enabling technologies for the communication systems beyond 3G. This White Paper aims to outline the issues and technological problems of reconfigurable systems and endeavours the definition of a “Reference Model for Reconfigurable SDR Equipment and Supporting Networks’. To put things into perspective a roadmap in a 2010 timeframe, in accordance to the WWRF vision, is used. A reference model identifying all facets of reconfigurability must include the whole range of different access schemes available. It stretches through the heterogeneous environment of satellite, haps, broadcast, cellular and low range communication networks (WLAN, Bluetooth) and has to provide the means for interconnection of this variety of systems. The multitude of different radio transmission and access technologies has to be included in the reference model, and means for (re)configuration management in the network elements and end equipments have to be installed to control the configurations of nodes between the communication end points. The reference model targeted will encompass System and Network (including core and access network/base stations), the hardware issues in both RF & BB side and the data & control/management interfaces between the various building blocks of the reconfigurable environment. Specific technical appendixes complement the core of this White Paper. All research thematics identified in this document ate summarized within the second White Paper “Reconfigurable SDR Equipment and Supporting Networks – SDR Research Thematics”.

mailto:[email protected]





























WWiirreelleessss WWoorrlldd RReesseeaarrcchh FFoorruumm WWoorrkkiinngg GGrroouupp 33 -- WWhhiittee PPaappeerr

RReeccoonnffiigguurraabbllee SSDDRR EEqquuiippmmeenntt aanndd SSuuppppoorrttiinngg NNeettwwoorrkkss

© 2002, WWRF 2

Executive Summary

This White Paper “Reconfigurable SDR Equipment and Supporting Networks – Reference Models and Architectures” has been produced within the WWRF WG3 SDR Group [1] [2]. It aims at defining the WWRF SDR Reference Models, analysing the overall problematic of the SDR Architectures and identifying the main SDR research thematics to be investigated in the next decade. The document follows a top-down approach and the reference model targeted encompasses system and network (including core and access network/base stations), the hardware issues in both RF and BB sides and the data and control/management interfaces between the various building blocks of the reconfigurable environment. This documents outlines the issues and technological problems of reconfigurable systems and endeavours the definition of a “Reference Model for Reconfigurable SDR Equipment and Supporting Networks”. The SDR reference model includes the whole range of different access schemes available, stretches through the heterogeneous Beyond 3G environment and provides the means for interconnection of the associated variety of systems. The multitude of different radio transmission and access technologies is included in the reference model, and means for (re)configuration management in the network elements and end equipments have to be installed to control the configurations of nodes between the communication end points. Following introduction of the multi-dimensional aspects of SDR and the needs and constraints for terminal and network reconfigurability in chapter 1, the SDR system and supporting networks reference models and architectures are presented and analysed in details within chapter 2. A “High-level Reconfiguration System Model” is proposed in this chapter and existing SDR system architectures are reviewed as potential candidates for future research on reconfigurable SDR equipment and supporting networks. Network and terminal reconfigurability and adaptability are deeply covered, security being also addressed at the end of the chapter as key area for SDR. To support the development of software defined and re-configurable radio and networks, the research on SDR System and Software Architectures will have to address the following main areas: system, network and protocol architectures supporting re-configurable equipment, network-centric re-configuration support and finally terminal-centric re-configuration support. All identified research thematics are summarized as conclusion of the chapter. The different SDR RF architectures choices are investigated in chapter 3. This chapter reviews issues that have arisen out of architectural considerations. Current state of the art solutions to these issues is examined. Necessary research to extend the usefulness of these solutions to a practical SDR design is identified. Chapter 3 discusses possible research topics, which, it is hoped, will aid the evolution of SDR hardware design. MEMS technology is specifically examined, as it provides the possibility of innovative breakthroughs that established technologies are incapable of providing. These research thematics include: agile linear frequency translation, flexible linearity profile (FLP) amplifiers, diplexerless frequency-agile radio front-end, interference cancellation or filtering, adaptive preselect filters, frequency agile zero IF receiver, novel up-conversion techniques, digital IF processing and finally data converters. Chapter 3 also proposes a RF road-map to make the SDR transceiver become a reality.



© 2002, WWRF 3

Chapter 4 focuses on the SDR Baseband Architectures and critical components. Primary goal of the research in the field of SDR-BB concept is a generic hardware architecture which is able to cover as many current and upcoming wireless standards as possible. Baseband processing of the future multi-standard terminal or basestation will set very demanding requirements in computational performance and flexibility. It is very probable, that the future baseband processing architectures will consist of different kind of processing, storage and interconnection resources. Different kind of reconfigurable technologies will be used as processing elements. The reconfigurable technologies include configurable processing cores, FPGA-based approaches, embedded FPGA-based approaches and approaches based on arrays of processing elements. Still the special purpose hardware blocks will be needed also for the most demanding algorithms due to their superior silicon area and energy efficiency. Research is needed to define what is an optimum hardware architecture for a given wireless standard set. A crucial issue of the resulting architecture is the resulting implementation complexity, i.e. power consumption, chip area of single modules and the overall resulting architecture. This may also include research on efficient HW-Structures of re-configurable logic modules. Design flow for implementation of SW-modules for constituent standards on the hardware architecture has also to be considered. Chapter 4 ends with the summary of identified critical components, future directions and research goals. Chapter 5 investigates SDR equipment interfaces, protocol issues and genericity of the link layer. A powerful processing platform and a structured software architecture capable to implement the system requirements of the various RATs are core basis for the development of future reconfigurable SDR equipment. An architectural framework is developed which considers the inclusion of open programming interfaces for both the application layer but also for the lower system levels (i.e. an open programming interface for RAT implementation software). To develop this complete framework of interfaces between the building blocks of a reconfigurable equipment (terminal/base station, etc.) a number of research need to be solved, including clear separation of tasks between the different reconfigurable modules, generalisation and specification of individual generic interfaces between RF and BB as well as between BB and the GP modules, identification of all reconfiguration control/management related functions, definition of a generic control/management interface between the individual radio modules and the reconfiguration manager. The research topics associated to the definition of generic and adaptable protocols and protocol stacks have also been identified. The SRA configurability is addressed at the end of the chapter 5. A specific research challenges section concludes this chapter. Finally, chapter 6 attempts to define some plausible roadmaps for the deployment of reconfiguration applications. These roadmaps treat basic scenarios frequently mentioned in the literature: reconfiguration for remote equipment upgrades and reconfiguration for enhancing network management. Specific technical Appendixes complement the overall White Paper: Appendixes 1 to 5 (section 9.1 to 9.5) provide additional information to Chapter 2 on coupling methods, profile location, mobility management, mass up-grade and signalling. Appendix 6 (section 9.6) complements chapter 3 on amplifier linearisation schemes.



© 2002, WWRF 4

Table of Content 1 Introduction ......................................................................................................................................... 14

1.1 The Need for Network and Terminal Reconfigurability and Adaptability.................................. 14 1.2 Reconfigurability, Adaptability and Flexible Service Provision................................................. 16 1.3 Open APIs for Reconfigurability Support ................................................................................... 18 1.4 Reconfigurability in IP Networks................................................................................................ 19 1.5 A Reconfigurable RF Architecture.............................................................................................. 21 1.6 A Reconfigurable Base-Band Architecture ................................................................................. 22 1.7 Data and Control Interfaces......................................................................................................... 23 1.8 Reconfigurability Applications ................................................................................................... 25

2 SDR System and Supporting Networks Reference Models and Architectures ................................... 26 2.1 Reconfigurability in Future Mobile Communication Systems.................................................... 26

2.1.1 An Abstract Model for Open Platforms and Reconfigurability........................................... 26 2.1.2 Adaptable Network Element Model .................................................................................... 27 2.1.3 Terminal Reconfiguration Control ...................................................................................... 28 2.1.4 Network Adaptability / Active Services.............................................................................. 29

2.2 Software Defined Radio Architecture Model.............................................................................. 29 2.3 High-level Reconfiguration System Model................................................................................. 30 2.4 Heterogeneous Network Architectures and SDR Network Functions ........................................ 33

2.4.1 Management and Location of Profile Data for Mode Switching ........................................ 34 2.5 SDR System Architectures .......................................................................................................... 35

2.5.1 Proxy Reconfiguration Manager ......................................................................................... 40 2.5.1.1 Proxies in IP-based Networks ......................................................................................... 41 2.5.1.2 Function Split in Control and User Plane for PRM......................................................... 43 2.5.1.3 Inter-PRM-Interface ........................................................................................................ 44 2.5.1.4 Mass Upgrade.................................................................................................................. 44

2.5.2 SRM and HRM Role and Location ..................................................................................... 45 2.5.3 Reconfigurable Modules and Protocol Stacks..................................................................... 46

2.6 Reconfiguration Security............................................................................................................. 50 2.6.1 Secure Software Download and Execution ......................................................................... 52 2.6.2 Reconfiguration Control...................................................................................................... 53

2.7 SDR System and Network Research Challenges ........................................................................ 54 3 SDR RF/IF Reference Models and Architectures ............................................................................... 57

3.1 Receiver Architectures ................................................................................................................ 57 3.1.1 Homodyne Receiver Architecture ....................................................................................... 58 3.1.2 Heterodyne Receiver ........................................................................................................... 60 3.1.3 Digital IF Receiver Architectures........................................................................................ 62 3.1.4 Low IF Architecture ............................................................................................................ 63 3.1.5 Six-Port Technology for Terminal Receivers...................................................................... 64

3.2 Transmitter Architectures............................................................................................................ 64 3.2.1 Direct Conversion Architecture........................................................................................... 64 3.2.2 Heterodyne Architecture ..................................................................................................... 65

3.3 The Analog/Digital Interface....................................................................................................... 66 3.4 Critical Components.................................................................................................................... 67

3.4.1 Filter Functions within a Conventional Receiver ................................................................ 67 3.4.2 Device Linearity .................................................................................................................. 67



© 2002, WWRF 5

3.4.3 Mixer Linearisation ............................................................................................................. 68 3.4.4 Image Signals and Variable Preselect Filters ...................................................................... 68 3.4.5 ADC/DAC Issues ................................................................................................................ 69 3.4.6 Broadband Synthesiser and its Impact on Phase Noise Characteristics / System Performance ........................................................................................................................................ 71 3.4.7 Digital IF-Processing........................................................................................................... 71 3.4.8 Commonality between TX and RX Schemes ...................................................................... 72

3.5 SDR Design Choices ................................................................................................................... 73 3.5.1 Active and Shadow Receiver Chains .................................................................................. 73

3.5.1.1 Single Transmit – Receive Chain .................................................................................... 73 3.5.1.2 Active and Shadow Transmit and Receive Chains.......................................................... 74 3.5.1.3 Hybrid Architecture......................................................................................................... 74 3.5.1.4 Conclusion....................................................................................................................... 75

3.5.2 Separate Antennas for Individual System ........................................................................... 77 3.6 Future Directions......................................................................................................................... 78

3.6.1 MEMS Technology and its Impact on Software Radio Front-end ...................................... 78 3.6.2 Future Research Directions ................................................................................................. 80

3.6.2.1 Agile Linear Frequency Translation................................................................................ 80 3.6.2.2 Flexible Linearity Profile (FLP) Amplifiers.................................................................... 80 3.6.2.3 Diplexerless Frequency-agile Radio Front-end............................................................... 80 3.6.2.4 Interference Cancellation or Filtering.............................................................................. 80 3.6.2.5 Adaptive Preselect Filters................................................................................................ 80 3.6.2.6 Frequency Agile Zero IF Receiver .................................................................................. 81 3.6.2.7 Novel Up-Conversion Techniques .................................................................................. 81 3.6.2.8 Digital IF-Processing....................................................................................................... 81

3.6.3 Technological Roadmaps Receiver Architectures............................................................... 81 4 SDR Baseband Reference Models and Architecture........................................................................... 84

4.1 Algorithms................................................................................................................................... 84 4.1.1 Harmonization and Classification of Transceiver Algorithms ............................................ 84 4.1.2 Interworking between RF/IF Part and Baseband Part ......................................................... 85

4.2 Software Architecture of Reconfigurable Baseband ................................................................... 85 4.3 Hardware Architecture of Reconfigurable Baseband.................................................................. 87

4.3.1 Generic Baseband Receiver Chain ...................................................................................... 90 4.3.2 Transmitter Baseband Receiver Chain ................................................................................ 91 4.3.3 Other Baseband Transceivers ............................................................................................ 101

4.3.3.1 Personal Area Network “Bluetooth” ............................................................................. 101 4.3.3.2 Digital Audio Broadcast Systems.................................................................................. 102 4.3.3.3 Digital Video Broadcasting (DVB) ............................................................................... 104

4.4 Critical Components.................................................................................................................. 104 4.4.1 Application Specific DSPs ................................................................................................ 104 4.4.2 DSP Operating Environment............................................................................................. 105

4.5 Future Directions / Research Goals ........................................................................................... 106 5 The Missing Link – Management, Control and Data Interfaces to connect SDR Platform and SDR Software Architecture................................................................................................................................ 109

5.1 Information Exchange between Network and Terminal: Data and Reconfiguration Related Traffic 109 5.2 SDR Platform Module Interfaces .............................................................................................. 110 5.3 Control and Management Interfaces ......................................................................................... 110 5.4 A Software Architecture for SDR Equipment........................................................................... 111

5.4.1 Service Support in Reconfigurable Equipment ................................................................. 112



© 2002, WWRF 6

5.4.1.1 Configurable Service and Middleware Platform ........................................................... 113 5.4.1.2 Configurable Network Platform .................................................................................... 114 5.4.1.3 Services in Reconfigurable Systems ............................................................................. 117

5.4.2 Installing a Radio Configuration ....................................................................................... 117 5.4.3 Generic and Adaptive Protocols ........................................................................................ 118

5.4.3.1 Development of a Generic Protocol Stack .................................................................... 119 5.4.3.2 Definition of a Generic and Reconfigurable Link Layer............................................... 120

5.4.4 Software Radio Architecture (SRA) Configurability ........................................................ 122 5.5 Research Challenges.................................................................................................................. 125

6 Deployment Roadmaps for Reconfigurability Applications ............................................................. 127 7 Conclusions ....................................................................................................................................... 130 8 References ......................................................................................................................................... 132 9 Appendixes........................................................................................................................................ 138

9.1 Appendix 1: Coupling Methods ................................................................................................ 138 9.2 Appendix 2: Profile Location in Different Coupling Scenarios ................................................ 141 9.3 Appendix 3: Mobility Management .......................................................................................... 142 9.4 Appendix 4: Mass Up-grade Multicast Flow ............................................................................ 145 9.5 Appendix 5: Signalling between Network Entities for Terminal Reconfiguration ................... 146 9.6 Appendix 6: Amplifier Linearisation Schemes ......................................................................... 153



© 2002, WWRF 7

List of Figures

Figure 1: The need for Reconfigurability and Adaptability in Service Provision for 3G and Beyond ...................................................................................................................................15

Figure 2: Service Provision Dependent Reconfiguration Management.........................................16 Figure 3: Generic Architecture for Flexible Service Provision and Reconfigurability

Management. ..........................................................................................................................18 Figure 4: Convergence in Telecommunications.............................................................................19 Figure 5: Multi-Dimensional Aspects of Software Defined Radio................................................20 Figure 6: Interface Architecture for Reconfigurable Systems and Supporting Network Elements

................................................................................................................................................24Figure 7: Open Platform with its Base and Components ...............................................................26 Figure 8: Abstract Model or Reconfigurable Network Element ....................................................27 Figure 9: High-level Reconfiguration System Model ....................................................................31 Figure 10: Tight /Loose Coupling between WLAN and UMTS....................................................34 Figure 11: Network-Centric Architecture ......................................................................................35 Figure 12: Functional Architecture for SDR Equipment ...............................................................36 Figure 13: Example of Entities and Interfaces of a Terminal Reconfiguration Serving Area

(TRSA) with different Radio Access Technologies...............................................................38 Figure 14: IP-based Network and Proxies Supporting Reconfigurable Terminals ........................42 Figure 15: PRM Function Split ......................................................................................................43 Figure 16 Example of Proxy Control Functions in the Core Network (left) and in the RAN (right)

................................................................................................................................................44Figure 17: Military SDR Platform Architecture (SDR Forum) .....................................................46 Figure 18: Decorrelation of SW and HW in SDR Context ............................................................46 Figure 19: Open Platforms Architecture Comparison (SDR Forum) ............................................47 Figure 20 : SRA Architecture Layers.............................................................................................48 Figure 21: Non-CORBA based SDR SW/HW Integration ............................................................49 Figure 22: Reconfigurable SDR Terminal Architectures and Interfaces .......................................49 Figure 23: Reconfiguration Security System Model......................................................................51 Figure 24: Re-configuration Support in Re-configurable Access Networks and Terminals ........56 Figure 25: Ideal SDR based Receiver ............................................................................................57 Figure 26: Direct Conversion Receiver Architecture.....................................................................59 Figure 27: Heterodyne Receiver Structure with two Hardware Conversions...............................60 Figure 28: Relation between Filter Bandwidths and IF in Heterodyne Receivers.........................61 Figure 29: Superheterodyne Architecture with Digital Second Downconversion.........................62 Figure 30: Direct Conversion Transmitter Architecture ................................................................65 Figure 31: Heterodyne Architecture...............................................................................................66 Figure 32: Possible Block Diagram of an Active Shadow Chain Transceiver ..............................76 Figure 33: Structure of a MEMS switch ........................................................................................79 Figure 34: Generic Software Architecture of Reconfigurable Baseband.......................................86 Figure 35: Generic Hardware Architecture of Reconfigurable Baseband .....................................87 Figure 36: Baseband Receiver Module ..........................................................................................92 Figure 37: Baseband Transmitter Module......................................................................................97 Figure 38: Baseband Transmitter and Receive Chain of Bluetooth.............................................101



© 2002, WWRF 8

Figure 39: Modem Architecture...................................................................................................105 Figure 40 SDR Architecture – Data and Control Interfaces ........................................................110 Figure 41: 4G System Abstraction Layer Groups........................................................................112 Figure 42: Middleware Platform and Applications......................................................................114 Figure 43: Network Side Networking Platform ...........................................................................115 Figure 44: Mobile Terminal Architecture ....................................................................................116 Figure 45: SDR Hierarchical Architecture...................................................................................117 Figure 46: Interaction of Components for an SDR Protocol Stack..............................................119 Figure 47: Multiple Link Layer Scenario compared to Generic Link Layer Scenario (GLL –

generic link layer, LL – link layer, L1 – layer 1, RAN – radio access network, CN – core network) ...............................................................................................................................121

Figure 48: Generic Link Layer Functions and Interfaces ............................................................122 Figure 49 : Waveform Component Model ...................................................................................123 Figure 50: SRA Core Framework Model .....................................................................................124 Figure 51: Deployment Roadmaps for Incremental Introduction of Reconfigurability Applications

..............................................................................................................................................127Figure 52: Open coupling Scenario between WLAN and UMTS ...............................................138 Figure 53: Loose Coupling Scenario between WLAN and UMTS .............................................139 Figure 54: Tight Coupling Scenario between WLAN and UMTS...............................................140 Figure 55, Tighter Coupling Scenario between WLAN and UMTS............................................140 Figure 56: Interworking of different RAT’s, Hybrid Coupling ...................................................141 Figure 57: Example of a Mass Reconfiguration Process Initiated by an External Server with the

Use of IP Multicast...............................................................................................................145 Figure 58: Signalling between the Terminal, the current PRM (PRM 1) and the new PRM (PRM

2) in the Mode Switching Case ............................................................................................147 Figure 59: Signalling between Reconfiguration Network Entities during Application Update

Process..................................................................................................................................148 Figure 60: Signalling in Case of a Mass Upgrade, Initiated by a Manufacturers Server.............150 Figure 61: Signalling between Terminal, current and new PRM and Server in order to enhance

Software Download Process.................................................................................................151 Figure 62: Cartesian Feedback Used to Linearise a PA...............................................................153 Figure 63: Feedforward Distortion Cancellation .........................................................................154 Figure 64: Linearisation using Predistortion................................................................................155 Figure 65: Envelope Elimination and Restoration .......................................................................156 Figure 66: LINC Linear Transmitter Architecture .......................................................................157 Figure 67: CALLUM Linear Transmitter Architecture ...............................................................158 Figure 68 The Block Diagram of the Proposed Technique Applied as a Receiver .....................159 Figure 69: Modified Hairpin Filter Structure...............................................................................161



© 2002, WWRF 9

List of Tables

Table 1: Typical MEMS switch Specification ...............................................................................79 Table 2: Comparison of Technologies Required to Realise a SDR Receiver using Various

Architectures ..........................................................................................................................81 Table 3: Estimated Time Frame to Develop Technologies Required for a fully Functioning SDR

Receiver..................................................................................................................................83 Table 4: Parameter Table for Receiver Module .............................................................................93 Table 5: Parameter Table for Transmitter Module.........................................................................98 Table 6: DAB Characteristics ......................................................................................................103



© 2002, WWRF 10

Abbreviations List

AAA Authentication, Authorisation and Accounting ACL Access Control List ACL Asynchronous ConnectionLess ADC Analog to Digital Conversion AEP Application Environment Profile AP Access Point. API Application Programming Interface AS Access Stratum ATM Asynchronous Transfer Mode BB Baseband BIOS Basic Input Output System BMM Bandwidth Management Module BS Base Station BS Bearer Services BT_AP Bluetooth Access Point BTS Base Transceiver Station CALLUM Combined Analogue Locked Loop Universal Modulator CAST Configurable radio with Advanced SW Technology CDMA Code Division Multiple Access CF Core Framework CM Configuration Management CMM Configuration Management Module CN Core Network CODEC CODer/DECoder COM Component Object Model CORBA Common Object Request Broker Architecture CPU Cental Processing Unit CSW Computer Software Components DAB Digital Audio Broadcast DAC Digital to Analog Conversion DL Downlink DNS Domain Name Service DVB Digital Video Broadcast DSP Digital Signal Processor EIR Equipment Identity Register ETSI European Telecommunications Standards Institute EVM Error Vector Magnitude FDD Frequency Division Duplex FEC Forward Error Correction FLP Flexible Linearity Profile FPGA Field Programmable Gate Array FTP File Transfer Protocol GGSN Gateway GPRS Support Node



© 2002, WWRF 11

GIOP General Inter-ORB Protocol GLL Generic Link Layer GP Generic Protocol GPP General Purpose Processor GPRS General Packet Radio Service GSM Global System for Mobile Communications HiperLAN/2 High Performance LAN type 2 HLR Home Location Register HO Handover HRM Home Reconfiguration Manager HTTP HyperText Transport (or Transfer) Protocol HW Hardware IDL Interface Definition Language IETF Internet Engineering Task Force IF Intermediate Frequency IGMP Internet Group Management Protocol IIOP Internet Inter-ORB Protocol IMD Intermodulation Distorsion IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IMT-2000 International Mobile Telecommunications 2000 IP Internet Protocol ISA Instruction Set Architecture ISDN Integrated Services Digital Network ISV Independent Software Vendor LAN Local Area Network LINC Linear Amplification with Non-linear Components LLC Logical Link Control LNA Low Noise Amplifier LO Local Oscillator LR Location Register MAC Medium Access Control MDA Model Driven Architecture ME Mobile Equipment MExE Mobile Execution Environment MEMS Micro ElectroMechanical Systems MIB Management Information Base MIMM Mode Identification & Monitoring Module MIP Mobile IP MIPS Million Instructions Per Second MMS Multimedia Message Service MN Mobile Node. MNSM Mode Negotiation and Switching Module MOBIVAS downloadable MOBIle Value Added Services MS Mobile Station



© 2002, WWRF 12

MSC Mobile Switching Centre MT Mobile Terminal MVCE Mobile Virtual Centre of Excellence NBS Network Bearer Services NE Network Element NO Network Operator OEM Original Equipment Manufacturer OMG Object Management Group ORB Object Request Broker OS Operating System OTA Over the Air PA Power Amplifier PAN Personal Area Network PBA Parametrizable Basic Architecture PHY Physical Layer PIM Platform Independent Model PLMN Public Land Mobile Network PRM Proxy Reconfiguration Manager PSM Platform Specific Model QoS Quality of Service RAN Radio Access Network RAT Radio Access Technology RCS Radio Control Server RF Radio Frequency RM Reconfiguration Manager RMA Reconfiguration Management Architecture RMM Reconfiguration Management Module RNC Radio Network Controller ROM Read-Only Memory RPC Remote Procedure Call RRC Radio Resource Control RSMM Resource System Management Module RSSI Receive Signal Strength Indicator RX Receive SAP Service Access Point SAW Surface Acoustic Waves SCOUT Smart user-Centric cOmmUnication environmenT SDL System Description Language SDM Software Download Module SDP Service Discovery Protocol. SDR Software Defined Radio SDRF SDR Forum SDRC Software Download and Reconfiguration Controller SDU Service Data Unit SEG Security Gateway



© 2002, WWRF 13

SIM Subscriber Identity Module SIR Signal to Interference Ratio SOAP Simple Object Access Protocol SPRE Software Download and Profile Repository SRA Software Radio Architecture SRM Serving Reconfiguration Manager S-RNC Serving RNC SW Software TCP Transport Control Protocol TDD Time Division Duplex TOI Third Order Intercept TRUST Transparently Reconfigurable UbiquitouS Terrminal TRSA Terminal Reconfiguration Serving Area TX Transmit. UE User Equipment UL Uplink UML Unified Modeling Language UMTS Universal Mobile Telecommunication System UP User Profile UPS User Plane Server USIM UMTS Subscriber Identity Module UTRAN UMTS Terrestrial Radio Access Network VCO Voltage Controlled Oscillator VHE Virtual Home Environment VLR Visitor Location Register VM Virtual Machine WAN Wide Area Network WAP Wireless Application Protocol W-CDMA Wideband Code Division Multiple Access W-LAN Wireless LAN XML eXtensible Markup Langage



© 2002, WWRF 14

11 IInnttrroodduuccttiioonn This White Paper “Reconfigurable SDR Equipment and Supporting Networks” has been produced within the WWRF WG3 SDR Group [1] [2]. It aims at defining the WWRF SDR Reference Models, analysing the overall problematic of the SDR Architectures and identifying the main SDR research thematics to be investigated in the next decade. The document follows a top-down approach and the reference model targeted encompasses system and network (including core and access network/base stations), the hardware issues in both RF and BB sides and the data and control/management interfaces between the various building blocks of the reconfigurable environment. In order to support and complement SDR terminal and network reconfigurability, it is apparent that additional intelligence for network reconfigurability functionality is necessary. To this end, since the reconfigurability aspects in all OSI layers should be adequately addressed, the provision of holistic solutions towards the support of reconfigurable mobile environments, imply the introduction of advanced reconfigurability management and control. Furthermore, terminal and network reconfiguration is closely coupled with optimal service and RRM provision. The multitude of available services, with highly diverse requirements from the network and terminal, creates the need for a dynamic and intelligent way of adapting the network and terminal to enable optimal service provision by using adequate RAT’s. This adaptation encompasses the abstraction of the complexity related to the terminal capabilities.

1.1 The Need for Network and Terminal Reconfigurability and Adaptability

In 2G networks, services provided to mobile users are either rigidly integrated in network equipment or developed with proprietary tools by mobile operators or equipment manufacturers. However, in 3G and beyond, an open marketplace is expected to emerge, where a huge number of diverse services will be developed by Independent Software Vendors (ISVs) including radio software and application and service software which typically will not be targeted solely to mobile networks. This situation creates the need for more flexible networks that can be adapted dynamically to the requirements of the multitude of services and RAT’s software that are provided to them. Thus, network and terminal reconfigurability becomes an issue critical to the successful development of the 3G and beyond market according to the expectations of the market players that have invested in this technology as well as the end-users. Requirements and architectures for the support of reconfigurability management on the network side are addressed in. [3] and in [4], [5].



© 2002, WWRF 15

Network

RAT SP

SP

Various user profiles

Reconfigurable terminal profiles

Various network capabilities

Various serviceprofiles

Various service and RAT providers

FFlleexxiibbllee SSeerrvviiccee pprroovviissiioonn aanndd rreeccoonnffiigguurraabbiilliittyy//aaddaappttaabbiilliittyy

Complexity for profile interpretation and

policy enforcement

Service

Figure 1: The need for Reconfigurability and Adaptability in Service Provision for 3G and Beyond

Network and Terminal reconfiguration to best accommodate a service profile, adequate terminal and user profiles may occur either during service and RAT deployment to a network or during service and RAT activation and execution. Network reconfigurability is thus required in order to:

• Complement and support terminal reconfiguration, • Support protocol and RAT adaptivity, • Support flexible service discovery and provision, • Support protocol/software download, • Support policy provision based on terminal, service, user and network profile, • Support to provide self-planning networks.

Some examples of the types of reconfiguration actions that would be useful in a mobile network are the following:

• Quality of Service (QoS) provisioning, • Charging and billing, • Dynamic software downloading.

Although the capability of a network to be dynamically reconfigured could by itself be a very powerful tool for terminal reconfiguration support and service adaptation and delivery, its full potential cannot be realized if such features are not accessible by all involved parties. Employing reconfiguration for a restricted number of operator or equipment vendor provided services limits its impact, while opening up reconfigurability capabilities to service provision platforms and applications could create a dynamic environment where flexible, personalized, revenue-generating services will be within the reach of the user at any time and within any environment. To this end, we clearly identify the need for network reconfiguration functionality to be part of open, standardized interfaces that provide access to mobile networks.



© 2002, WWRF 16

• • • •

• • • • •

1.2 Reconfigurability, Adaptability and Flexible Service Provision Reconfigurability management and control is essential for the support of network–wide reconfiguration actions (including also support for terminal reconfigurability). Some basic requirements for reconfigurability management for 3G and beyond are:

Support for flexible business models with novel dynamic services, Dynamic reconfiguration based on profile, service provision requirements, Dynamic reconfiguration based on MT/access capabilities, Dynamic reconfiguration based on policy provision (QoS, charging, etc.).,

The reconfigurability management and control depends on various aspects. Some basic aspects that affect the reconfiguration management span across low level as well as high level functionalities and features. Based on some of these features, reconfigurability management can be identified in:

Service provision dependent reconfiguration management, MT capabilities dependent reconfiguration management, Profile dependent reconfiguration management, Policy dependent reconfiguration management, Location dependent reconfiguration management.

An example for service provision dependent reconfiguration management is shown in Figure 2.

MS

4G Core Network

IP Network

UTRAN

GERAN

RAT n

Network infrastructure

Laptop

SP SP

SP SP

Technology independent interfaces

API extensions for reconfigurability (Policy e.g., Charging, QoS)

OSA, Parlay, JAIN APIs

Service, RAT Profile Management

Service Discovery Mobile system profile management

Reconfiguration Manager

Services, RAT

Service, RAT Deployment User Profile Management

Rec

onfig

urab

ility

Man

agem

ent P

lane

Reconfiguration Control/ Service and RAT Provision Manager Open

APIs

Service provision dependent

reconfiguration management

MT and BS capabilities dependent


Profile dependent


Figure 2: Service Provision Dependent Reconfiguration Management



© 2002, WWRF 17

•

Reconfigurability management encompasses the triggering and control of reconfiguration actions in various layers on mobile systems and networks. It incorporates management of protocol and software downloading, as well as policy provision in order to enhance or change mobile terminal and network component characteristics and capabilities ([7], [8], [9], [10]). The main processes for reconfigurability realisation that are directly related to reconfigurability management and control include the identification of reconfiguration context by spatially scoping the technological surrounding of the requesting entity by identifying affected elements in the communication and computing infrastructure, the identification of feasible alternative solutions by capability exchange and negotiation procedures under specific policies (e.g., maximise system features), the decision on solution and respective implementation by taking into account generic (e.g. user) preferences alongside with strictly technical considerations (type-checking). Finally, the physical deployment of the identified solution will follow by reserving necessary resources, then downloading, installing and activating the identified solution. This solution may be protocol stack related components, service related tasks etc. Service and protocol adaptability is an important feature for the implementation of reconfigurable and adaptable environments. Management of adaptability coincides with reconfigurability management. It encompasses protocol, service and system adaptation based on identified information handling related to change of status in various functional elements (resources, mobile environment etc.). Based on the context change and identified policy, specific protocol elements and service tasks may be triggered in order to activate or accomplish the overall desired behaviour. These actions may be supported by wider reconfiguration actions and protocol and software downloading on the network and mobile system. It entails protocol adaptivity in various layers. This can be achieved by the support of new generic approaches in protocol design and implementation. A basic protocol part can be supplemented by downloadable parts that will be able to specialize the protocol functionality and behavior.

Protocol downloading is important in order to achieve and manage reconfigurability. It requires mechanisms for the identification of protocol elements to be downloaded, the management of protocol libraries, the versioning and conformance. Finally caching mechanisms of protocol elements for performance purposes should also be investigated. An important aspect related to the reconfigurability and adaptability support and management, is the introduction of intelligent service and RAT management platforms (its generic architecture is depicted in Figure 4) that act as mediators between SPs, end-users and mobile network operators, thus simplifying the extremely complex task of service management and provisioning, as well as reconfiguration actions in various layers in the protocol stack, terminal and network, employing various policies ([11],[12]). The platform functionality would include:

A service and RAT provision and reconfigurability management middleware enabling reconfigurability and adaptability actions in various layers in mobile networks, systems and terminals. These actions could include service-level operations like service deployment and modification of service tariffing policies as well as lower layer actions like monitoring of traffic flows,



© 2002, WWRF 18

•

•

Generic, re-usable mechanisms for adapting applications as well as service provision procedures to the current context (identified, among others, by terminal capabilities, network characteristics, user locations and status), A one-stop shop offering mobile users highly personalized, location and context-aware service discovery and access through a unified, customisable interface.

The generic framework introduced, incorporates aspects related to the combination of flexible service provision and best access and terminal connection selection, terminal and network reconfiguration in various layers in order to support better overall service provision and terminal connectivity (taking into consideration the various user/terminal/network and service profiles). Important features are the introduction of open APIs in order to support service registration, discovery and profile provision and additionally to trigger reconfiguration actions towards the network and terminal in various layers.

RAN RAT1

RAT2

APIs

Service and RAT Provision and Reconfiguration management middleware

SP SP SP

APIs

Adaptable services

Adaptable services

Adaptable RATs

Figure 3: Generic Architecture for Flexible Service Provision and Reconfigurability Management.

1.3 Open APIs for Reconfigurability Support Value added services (not necessarily voice centric) comprising multimedia, location based services, emergency services, MMS etc. will be an emerging service area for 3G operators and Service Providers. There are various potentials for the provision of adaptable services and Value added Services. Services based on the mobile subscriber's presence and availability include applications such as instant messaging and mobile chat. This is also an emerging industry segment, which will likely see convergence with various location based services and mobile commerce applications. The "look and feel" of all these kinds of services will satisfy the user's expectations through the extensive implementation of service adaptability and network reconfigurability mechanisms.



© 2002, WWRF 19

Architectures for the development and deployment of services by Service Providers over 3G networks have been introduced by 3GPP (OSA)[14], OSGi [15], Parlay [16], Jain [17], LIF [18] , UMTS Forum discussions [19] etc. The aforementioned schemes do not provide open APIs for reconfiguration purposes. Reconfiguration APIs should be introduced in order to enhance the OSA/Parlay etc. functionality and enable reconfiguration triggering network-wide, under specific conditions and policies. Reconfiguration actions concern various attributes. For example two types of attributes can initially be identified, namely state and configuration. Configuration attributes describe the desired state of a network device, and include attributes and classes for representing desired or proposed thresholds, bandwidth allocations, and traffic classification criteria. State attributes describe the actual state of a device at a particular operating instance. A generic service provision and reconfigurability management architecture in order to be able to fulfil its role, it is essential to accommodate open APIs for reconfiguration triggering and control. Context awareness features can also be accommodated on a generic service provision and reconfigurability management architecture and enabled through the support of open APIs related to context (e.g., location) aware policy provision, as described in [20], [21].

1.4 Reconfigurability in IP Networks The evolution of telecommunications in the next decade will be characterized by the convergence toward an IP-based core network and ubiquitous seamless access (2G, 3G, broadband, broadcast, etc.) in a context of hierarchical and hybrid self-organizing networks [4] [23] (Figure 4). Mobile users will only benefit from this global telecommunication environment if they are equipped with a single re-configurable SDR terminal.

xDSL

Mobility &radio access server

Network & service management

Application & content server

Reconfigurable equipment(Mobile routers, terminals, basestations,etc.)

Signalling gateway & call feature server

ApplicationsTransport

IP Network

Legacy PLMN

POTS/ISDN

APIAPI

Equipmentreconfigurationmanager and softwarerepository

Ad-hoc networks

Figure 4: Convergence in Telecommunications



© 2002, WWRF 20

This future generation of reconfigurable SDR terminals will be capable to operate in several or all of the different access environments, to support the whole range of applications available on the specific devices in the heterogeneous networks, to guarantee efficient use of the existing network resources, to provide to the user adaptive and customisable QoS provision by using the right network for the required service... All these capabilities will be offered to the users in a seamless and transparent way in the form of permanent global access, roaming and service availability. As explained by the SDR Forum [24], the SDR concepts impacts many layers of a wireless network and associated benefits will be realized from the physical layer to the user applications plane.

User Applications

Plane

Service Providers

Plane

Network Operator

Plane

Radio Implementers’

Plane

User orApplication

Request for NewService orCapability

SoftwareDownload

System Control

SDR provides flexibility inservice specification to the enduser.

SDR provides flexibility in thedeployment of newtechnologies to the networkoperator.

SDR provides market andservice differentiation toservice providers/operators.

SDR provides flexibility toradio designers as animplementation technique.

NetworkRequest forNew Service

orCapability

Figure 5: Multi-Dimensional Aspects of Software Defined Radio

All SDR research groups (European IST Reconfigurability Cluster Projects [23], SDR Forum [24], Mobile VCE initiative [25]…) stress the fact that re-configuration of mobile SDR terminals will require complex interactions between the terminal and the network entities, including the download of new software modules to be installed on the terminal and the discovery of services. The successful development of this future SDR telecommunications environment will be directly dependant on the early and appropriate definition of the reconfigurable system and network architectures, including the analysis of intelligence split between reconfigurable terminals and network and the definition and design of reconfigurable equipment required on the network side to support reconfigurability.



© 2002, WWRF 21

• • •

• • •

1.5 A Reconfigurable RF Architecture If a radio is to be able to be reconfigured, then issues associated with transceiver linearity, and transceiver image signals must be properly dealt with. These issues are easily accommodated in a conventional fixed centre frequency, fixed bandwidth transceiver, via the use of appropriate filters. Reconfigurable radios, because their centre frequency, bandwidth, and modulation technique are unknown at the time of their design, must deal with these problems differently. An ideal SDR must cover an infinite range of centre frequencies, possess a flexible bandwidth, be able to transmit signals at a wide range of RF output power, and be able to receive signals which exhibit a wide range of power levels. To make the problem more tractable, this White Paper proposes to restrict the concept of a SDR to what is the most fruitful and interesting area of radio technology. The SDR discussed in this white paper should be able to accommodate the following air interface standards:

Wireless telephone (GSM, DECT, UMTS), Wireless PAN (Bluetooth), Wireless LAN (HIPERLAN/2, IEEE802.11a/b).

If this assumption is made, then it is obvious that there are three distinct frequency bands that our hypothetical SDR should operate in. These are:

Around 900MHz, Around 2GHz, Around 5GHz.

The question that should now be asked is whether we could transmit and receive at these frequencies, using the same piece of RF hardware. It is possibly difficult to avoid a split between 2GHz and 5GHz. There are two reasons for this. The first is that devices (mixers and amplifiers) are not available which are capable of performing, to a satisfactory level, both in the 5GHz band and the 2GHz band. The second reason has to do with the size of the down conversion required. It is difficult to pick an IF frequency, which is simultaneously useful for signals in the 2GHz band, and signals in the 5GHz band. Consider, for example, if a 150MHz IF frequency is chosen. This is a suitable IF for 2GHz signals because the image signal is separated from the wanted signal by 300MHz or 15% of the centre frequency. A 150MHz IF is very low for a 5GHz signal, on the other hand. In this case, whilst the image signal is still separated from the wanted signal by 300MHz, this now represents 6% of the centre frequency. This may make the provision of a preselect filter in the 5GHz band, more problematic. It is possible, therefore, that an extra conversion may be necessary to achieve satisfactory operation in this part of the spectrum. The direct conversion (alternatively also know as “zero-IF”) architecture does not suffer from that problem. In principle, a direct conversion based front-end could accommodate different air-interface standards with a single, reconfigurable analogue baseband section, which is responsible for most of the amplification and filtering necessary. As each “special case” develops, departures from the SDR ideal takes place, and the “SDR” tends to look more like a multi-band, multi-mode radio. This is unavoidable, but as technology evolves, it would be expected that radios could approach the SDR ideal more closely.



© 2002, WWRF 22

1.6 A Reconfigurable Base-Band Architecture The baseband architecture of radio transceivers for user terminals and basestations for a mobile communication system beyond 3G has to be designed so that it is well-suited for the execution of a variety of wireless access and air interface schemes, and can be efficiently integrated into a system and network architecture that can support and exploit software-defined radio (SDR) equipment [2] [26]. The conventional approach to the design of a baseband architecture supporting multiple radio access and air interface schemes is the provision of multiple radio transceivers, each dedicated to an individual standard and optimised for the standard’s requirements. This approach is becoming increasingly infeasible and economically unacceptable because the complexity of the baseband grows and the number of standards expands. A more efficient approach towards this design is to architect a software reconfigurable baseband. User terminals can thus easily be adapted to the best-suited radio access scheme according to software requests issued by a configuration manager, while dynamically reconfigurable basestations can share its capacity between different standards based on the temporarily changing number and types of users in a certain area. Even though it is still impossible to implement such an advanced, software-reconfigurable baseband with today’s available hardware technologies, it is necessary for future product development work to investigate how the key baseband functions of today’s most important and potential future wireless access schemes can be efficiently mapped onto a generic reconfigurable hardware platform. Today’s wireless access systems include cellular mobile communication systems such as GSM and UMTS (W-CDMA), wireless local area networks (WLANs) such as 802.11b, 802.11a, and Hiperlan-2, and the personal-area network (PAN) Bluetooth. Future systems will further diversify this list. The implementation of these access schemes on a single, common hardware platform is different because the physical layer specifications of these standards strongly vary in terms of required channel access scheme, data rate, modulation, source and channel coding, etc. The availability of digital microelectronic hardware components is prerequisite for the successful implementation of reconfigurable SDR baseband equipment. Baseband processing power and memory requirements will finally determine the feasibility to store and execute the baseband functions of a given wireless access scheme on a configurable hardware platform. Reconfigurabilty must also be justified against battery power consumption, cost, and weight. However, the rapidly evolving semiconductor technology will allow the implementation of a more complex programmable, reconfigurable hardware platform with a justifiable hardware effort in the near future.



© 2002, WWRF 23

One of the objectives of this White Paper is to define a generic hardware architecture for an SDR baseband. Such an architecture has to cover three different aspects:

• Digital microelectronics is making much more profit from the fast evolution than its analog counterpart. Digital circuits fully benefit from the very fast increasing speed and integration density and also from the fast decreasing power consumption, due to lower supply voltages. By this, more and more complex digital circuits can be implemented on the same chip area. This will result in a continuous shift of digital circuits towards the direction of the antenna. Thus, the evolution of microelectronics forces a generic hardware architecture to be adaptable to the current state of the art of digital circuitry.

• Due to the aforementioned evolution, also the power of (embedded) processors is increasing permanently. This results in a shift from hardware to software: Functionality, which is realized by hardwired digital circuits today, will be substituted by software running on embedded digital signal processors in the future. A generic hardware architecture must be flexible enough to support this trend.

• An SDR concept must not be limited to today’s wireless standards but has to be open for upcoming standards as well. This is a crucial constraint for a future proof SDR architecture.

1.7 Data and Control Interfaces Reconfiguration of terminals requires a somewhat complex logistic, terminal and network information has to be gathered, the software necessary to perform a reconfiguration has to be obtained and it has to be ensured that this software becomes securely downloaded and properly installed in exactly that partition of the software definable radio hardware platform for which this particular software module has been foreseen. A very course structure taking all this into account had been defined and propagated during the early days of software radio, when the SDR Forum (at that time called MMITS) advocated a subset derived from the SPEAKeasy architecture. This initial architecture identifies not only the various functional blocks and the software structure of a SDR radio but it also recognises sets of interfaces between the various modules of a terminal, (i.e. information (I) and control (C)) interfaces between SW and HW platform, and also between HW platform and control infrastructure (see also [24]). Meanwhile there are a number of projects and communities approaching the definition of software radio architecture(s). Common to all these example architectures/structures (as listed and shown in [27] is the separation between information and control paths within the radios, as well as the gathering of parameters and general system information, as precondition to pursue controlled and trustworthy standard compliant reconfiguration processes. A reconfigurable communication platform must encompass all system levels [1] [2], ranging from (reconfiguration) supporting networks, reconfigurable base stations to reconfigurability of the terminals RF and BB modules whereby also the other aspects like the support for higher layers may require reconfiguration. It is widely understood that, at least currently, there is no single platform, architectural framework and implementation technology capable to provide a homogeneous structure for SDR equipment.



© 2002, WWRF 24

Additionally, the anticipated flexibility of such equipment requires an able modularisation of the various system elements [28] and mechanisms to manage complete reconfiguration processes (examples are Mobile VCE’s Reconfiguration Management Architecture RMA [25] and TRUST’s Configuration Management Module CMM [4] [23]). Taking all this into account, and at the same time aiming for open programmability to enable a ‘PC-like’ growth and variety of software provided, requires an interface architecture for both control and data domains.

Management and Control InterfaceData Interface (and RAN signalling)Management and Control InterfaceData Interface (and RAN signalling)

RNC, BSC,etc.AcA,

S-RM,etc.

SGSN,MSCetc.

G-AcA,HRM,etc.

backbone corenetwork

accessnetwork

Ant. RF BB GeneralProcessing

UserI/OAnt. RF BB General

ProcessingUserI/O

RMA, CMM, etc.

Ant. RF BB GeneralProcessing

UserI/OAnt. RF BB General

ProcessingUserI/O

terminal

air

inte

rfac

e

Figure 6: Interface Architecture for Reconfigurable Systems and Supporting Network Elements

Figure 6 abstracts the various interfaces between the different elements within a reconfigurable system. On the terminal side, a management unit (RMA, CMM, etc.) controls and steers the reconfiguration process whereby TRUST’s ‘Mode Switching’ feature [29] may be applied to monitor, using a switched shadow chain, the radio environment and to support seamless HOs. MVCE’s reconfiguration management controllers [30] are a solution to enable the intended reconfiguration of single modules within the transceiver chains. Based on a logical systems and software architecture for reconfigurable equipment, a clear defined and specified set of interfaces for both data and control of reconfigurable equipment needs to be developed, this section aimed to outline and proposed an initial approach applying different available technologies. A focused and detailed breakdown of the management control and data interfaces will follow in a later section (see Chapter 5).



© 2002, WWRF 25

1.8 Reconfigurability Applications From the previous discussion it is clear that the SDR approach principally revolves around two complementary axes:

1. Increasingly software implementations of radio applications on generic hardware platforms,

2. Device reconfiguration. Furthermore, in the context of cellular mobile networks a third axis has appeared:

3. Network reconfiguration management. Currently SDR functionality is found in existing products mainly BTS equipment. The use of programmable DSPs permits to change (reconfigure) the equipment functionality implemented in software. However in the future the focus is how to design the equipment to facilitate this change, make it part of the system operation (dynamic) and finally allow the core network to exploit it in meaningful ways.

In this spirit, all previously described items in the preceding sections identify the technical issues that need to be addressed in order to:

• Make radio equipment (terminals, basestations) reconfigurable, • Enable networks to exploit these reconfiguration capabilities and to optimise the networks

performance. SDR literature survey and market studies reveal that there are two popular use-case scenarios. First comes the scenario for over-the-air software upgrades and second the scenario for mode and standard switching [31]. These two scenarios are closely related in terms of both technical requirements and deployment times. Over-the-air software upgrades may occur either when the device is not in use (offline) or when it is (online). Depending on the case different R/T constraints need to be satisfied. A specific case of software upgrades is the device adaptation to changing environments or requirements by means of algorithm diversity [32]; different algorithms for the same functions may be better adapted to different operational situations. The second scenario of multimode/multistandard operation has also different manifestations. Switching may be offline or online and may or may not necessitate prior downloading. It can be user, terminal or network initiated. This depends on the reasons (e.g. coverage, QoS, spectrum availability, etc.) for a mode/standard switching. Finally instead of switching from one mode to another it may also be needed to make the device to operate in two different modes at the same time one for the downlink and one for the uplink.

Plausible deployment roadmaps are described into more detail in Chapter 6.



© 2002, WWRF 26

22 SSDDRR SSyysstteemm aanndd SSuuppppoorrttiinngg NNeettwwoorrkkss RReeffeerreennccee MMooddeellss

aanndd AArrcchhiitteeccttuurreess

2.1 Reconfigurability in Future Mobile Communication Systems In this section, the importance of reconfigurability or adaptability for mobile communication systems is highlighted. A very high-level system architecture focusing on reconfiguration is presented. Reconfiguration in middleware is also discussed and other technologies which support flexibility and reconfiguration are mentioned, e.g. active networks. This section ends with some requirements derived from this overall view.

2.1.1 An Abstract Model for Open Platforms and Reconfigurability In the following, we present a system architecture, which shows that reconfigurability or adaptability is prominent on all layers. While the main focus is on lower layer reconfigurabilty, we give here a brief overview of adaptability concepts on all layers. The abstract architecture model ranges from radio transmission mechanisms to applications visible to the end-user. It is structured in abstraction layers, which encompass transmission, networking, middleware (including service support), as well as applications and services. An abstraction layer may consist of several open platforms providing the actual computational behaviour. Each such platform consists of a stable and minimal platform base, plus several platform components, which can be added or removed to address different requirements at different times (Figure 7).

PlatformComponent

1

Platform Base

PlatformComponent

2

PlatformComponent

n

Figure 7: Open Platform with its Base and Components

We argue that adaptability achieved by this approach is a central concept in future mobile networks, because flexibility is a key requirement for future mobile systems. Our notion of adaptability is broad in order to cover all system aspects from reconfigurable radio parameters to applications. Due to this broad scope, different forms of adaptability are considered. The concept of open platform is only an abstract idealization of reconfigurable entities, either hardware or software.



© 2002, WWRF 27

2.1.2 Adaptable Network Element Model In this section, the overall architecture of network elements is described with the focus on the networking and transmission layers. More detailed descriptions, including the middleware layers, can be found in [33]. A generic architecture for the network elements of a mobile network is shown in Figure 8.

Firmware Drivers Param

eters

NW Interface(s)

Firmware Drivers Param

eters

NW Interface(s)

Filtering

Security

QoSEnf.

Forwarding Engine

Filtering

Security

QoSEnf.

Forwarding Engine

RoutingProt.

QoSProt.

PolicyMngr

Computing Platform

RoutingProt.

QoSProt.

PolicyMngr

Computing Platform

Middleware

Networking

Transmission

ActiveNet

Service

MW Platform(s)

ActiveNet

Service

MW Platform(s)

Virtual Execution Env.e.g, Active Networking,Service Components

Protocol Engine, e.g.Support for ActiveNetworks

ProgrammablePacket ForwardingEngine

ProgrammableSDR HW

Figure 8: Abstract Model or Reconfigurable Network Element

In this architecture, four platforms are considered, each programmable with configurable components. For terminals, typically a more compact subset is selected due to resource constraints. • The middleware platform can be structured in the local, virtual execution platform, the

distributed processing platform, and the service support platform, • The computing platform serves as a general-purpose platform for processing stateful

protocols, e.g. routing, QoS signaling or connection management, • The forwarding engine is in the data path of a network node and it connects network

interface platforms, e.g., by a switch matrix. This engine can be implemented as dedicated hardware or as a kernel module of common operating systems. The forwarding engine is programmable for performance-critical tasks, which are performed on a per-packet basis,

• The network interface platforms are medium specific for different wireless or wired standards. They can be configured or programmed to adapt to new physical layer protocols or for triggering events in higher layers.



© 2002, WWRF 28

The key technologies are the following:

• Software defined radio technologies as discussed in the remainder of this chapter, • Programmable, active network nodes [33] will enable the fast deployment of new services

by using open interfaces to the network resources. Active network technology typically provides an execution environment, which is tailored for networking protocols. Depending on the requirements, this can be on the middleware layer or on the networking layer. In both cases, the forwarding engine platform typically provides filtering of packets to be handled in the active network environment. With this technology, new protocols can be installed on the network elements, which use the lower layer resources for creating new services,

• Adaptable and open middleware platforms. From the operation point of view, the main requirements for the platforms are:

• Reliability for uninterrupted services, in particular when updating services, • Remote management is important for the central configuration in large networks, • Security with respect to attacks from outside. Since we assume that the network is owned

by operator, the main security risks arise from external interfaces.

2.1.3 Terminal Reconfiguration Control Since reconfiguration ubiquitous in network elements, controlling is a major challenge for the operator. This holds in particular for the terminal, where smooth reconfiguration is essential for a positive user experience. Over-the-air download of software will enable the dynamic provisioning of mobile application services to re-configurable terminals. Depending on the characteristics of the software download which includes radio parameters, protocols and software bug fix, time constraints, traffic management and security considerations have to be addressed. The motivation of network operators for SDR is to provide the best services to the user, but also to ensure positive user experience. For this, the software update has to be controlled from the network side in order to optimize application requirements and network resources. The key requirements from a network operator point of view are:

• Secure and reliable distribution of software, • Integration with user profiles, applications and billing, • Scalability will require a distributed execution of software updates, • Support for heterogeneous network infrastructure and terminal diversity.

In order to fulfil the above requirements, a flexible and reliable architecture for SDR control is needed.



© 2002, WWRF 29

2.1.4 Network Adaptability / Active Services Since network are composed of numerous and various elements, supervision and management is complex. Active Networking technology offers a transverse approach to adapt the Network from the server to the terminal and dialog occurs directly through the active nodes. Active network is a complementary approach which is added to existing network. Active network provide smartness to nodes, which means that providers and users can be differentiate by establishing policy on request at each node: this constitute a way to insure service delivery. Some advantages provided by this technology: reliable Multicast protocol (redundancy avoidance), dynamic routing, QoS booking for each node. Advantage for provider is network adaptability and advantage for user is content-aware service. For example configurability can be delegate to the last node to adapt the service depending link quality and terminal characteristic and to unload the network and the server.

2.2 Software Defined Radio Architecture Model Defining and designing SDR is a challenge and needs knowledge of various skills that cannot be covered by a single person or entity. To maximise the efficiency of the design work, a common background and understanding has to be defined using a non ambiguous language like UML. In Chapter 3, some design patterns are described, using a formal language well known and used by electricians. At the system level the same has to be done : defining concepts, architectural patterns using a formal language to avoid misunderstandings nor ambiguity. Even if not written, SDR is based on oriented object concepts: RADIO is an object that can be instantiated in various ways from FM receiver to multi-channel, multi-band transmitter-receiver. The various "models" proposed by SDR Forum, TRUST, … have commonalities and discrepancies but they all refer to the same concept or object but have been instantiated on different ways. The OMG (Object Management Group, www.omg.org), creator of UML, has developed a method to support the design of system named Model Driven Architecture MDA (OMG is also the creator and promoter of CORBA, but there is no direct relationship between CORBA and MDA). The MDA initiative allows to define and design a system at a high level without explaining the partitioning between hardware and software, nor the detailed design (PIM - Platform Independent Model). Such a PIM, can be shared by various companies, each company possessing one or multiple platform dependent models, corresponding to the instantiation of the PIM for a dedicated platform. The OMG leads an initiative to define PIM and PSM for SDR Components

http://www.omg.org/



© 2002, WWRF 30

2.3 High-level Reconfiguration System Model Being an enabling technology for the communication systems beyond 3G, reconfigurability benefits both Network Operators and Users. Whereas the former can maximize Radio Network Planning, as well as rapidly incorporate new enhancements and improvements such as personalised and customised services; the latter’s flexibility to select services ‘on demand’, with equitable QoS and perceived value for money, is also enhanced, alongside the provision of world wide roaming capabilities. End-to-End reconfigurability allows for a plethora of heterogeneous environments integration, consequently coping with the diverse availability of access schemes, converging in an all IP backbone. Subsequently, provision of means for interworking on a common platform leading to horizontal and vertical handovers, service negotiations and global roaming constitutes a pivotal factor, should the Reference Model capture the aforementioned requirements. Accordingly, the definition of a ‘Reference Model for End-to-End reconfigurable mobile communication systems’ should base on both legacy and future proof infrastructure; modelling radio access, transport and service technologies, as they relate to reconfiguration, and separating them from each other. Hereafter, the presented proposal aims at compiling various existing architectural approaches so as to design the basic structure required to support End-to-End reconfigurable systems. The focus is centred on identifying necessary (re)configuration controlling management instances in both terminal and infrastructure (network) from structural and logical points of view. Firstly, we call 3G cellular systems as a reference model for the complexity they involve in contrast to other plainer environments such as satellite and broadcast systems (i.e. DVB, DAB), Wireless LAN (i.e. HiperLAN2, IEEE 802.11) and Wireless Personal Area Networks (i.e. Bluetooth); even though the latter must also be considered to develop a seamless mobile network like the Internet, the necessary evolution and enhancements to bring reconfigurability to cellular systems, constitute the grounds applicable to the rest. This chapter shows, at a basic level, physical and functional separations to allow a network supporting reconfiguration capabilities to fit within the context of the IMT-2000 family of networks. It does not attempt to develop aspects of 3G networks that are highly specific to that implementation.



© 2002, WWRF 31

Conceptualisation of the system regards on dividing the network architecture into subsystems based on the nature of traffic (i.e. packet and circuit switch domains), protocols (i.e. access and non-access stratums, control and data) and physical elements (i.e. access and core network structure). Accordingly, Figure 9 builds on those bases to present a perspective of (Re)-Configuration Management (CM) instances, essential protocols and structural elements.

Figure 9: High-level Reconfiguration System Model

On the bottom side of the figure the structural approach illustrates a relation of 3G network elements of diverse domains, involved in an End-to-End Reconfiguration process. The functionalities implemented on those elements present a framework which capabilities would certainly be enhanced by Reconfiguration services. Should this constitute into a different network element (i.e. server, proxy) or, on the other hand be embedded into the same elements, is beyond the scope of this White Paper. Hence, instead of identifying the physical elements that incorporate CM instances, those are only depicted at the system level they operate. One way or another, functionalities and protocols should be likewise standardised, leaving open choice of implementation.



© 2002, WWRF 32

The top side of the figure presents the logical architecture by separating the protocol structure into three layered subsystems, namely Transport, Radio Network and System Network layers. The protocols within each of the layers operate across multiple interfaces and belong together in the sense of interworking. This refers to protocols of the same layer which extend across multiple network elements. Thereby, they comprise a set of protocols, which contribute to distributed execution of a common system-wide function, as discussed in more detail in [31]. CM functionality extends across the three layers, as shown by the SDR Multi-Dimensional Aspects figure in the Introduction section (Figure 5). The range of CM varies depending on the protocols and functionalities implemented in each element. Furthermore, CM instances are located in various domains for the functionalities required during the Reconfiguration process, expand across several network elements. The Terminal and the Base Station, or NodeB, comprise the elements performing the most dramatic processes such as hardware and physical layer reconfiguration. Accordingly, these two elements need CM instances at those levels. Note that CM reaches partially to the Radio Network layer, for a minimal set of radio resource management processes are located over there; and therefore, subject to reconfiguration too. It is also worth to stress the importance of having a CM element at the Radio Network domain. The reason is twofold. First for the advantages it brings [35] shows that using inter-Radio Network signalling, easily achievable in an All-IP environment, offers implementation and capacity benefits compared to conventional Dynamic Channel Assignment (DCA) algorithms. Thus, a CM entity supporting the system at this level can considerably improve the overall performance by triggering Terminal and Base Station reconfigurations, as well as performing a crucial role during radio access bearer establishment during Vertical Handovers. The bottom line is a better switching process for the user, with enhanced throughput and minimized delay, which in turn means optimization of the Reconfiguration QoS. Second, CM in the Radio Network domain proves valuable for network operators by making feasible to better administrate the extremely expensive and scarce spectrum resource, leading to Radio Network Planning optimization. The proposals for dynamic spectrum allocation between differing systems is facilitated by flexible system selection schemes as proved in [36]. Concisely, CM instances in the Access Network Domain could interact with elements that perform dynamic spectrum allocation, reporting current and target load conditions depending on the implemented reconfiguration capabilities. Finally, CM has to interwork with System Network entities, such as Communication (Connection, Session) and Mobility Management. High layer interactions are envisaged during procedures for authentication, global roaming and software download. The latter constitutes one of the key research areas; for specific cases (i.e mass terminal upgrades), it tends to rely on multicasting technologies managed in the top subsystem and thereby within the scope of the presented framework.



© 2002, WWRF 33

Reconfigurable networks will use object oriented software technologies for distributed systems. The scalability and modularity advantages, which enables efficient methods for software provisioning, as well as fast deployment and high flexibility have been highly disseminated by TINA [37]. Middleware is an open, broadly applicable and platform-neutral technology that uses object-oriented techniques to hide most of the underlying complexity introduced by differing systems. The benefits of incorporating a glue-layer are straight forward, considering the vast amount of different environments and access schemes and the subsequent proprietary protocols. Provided that adequate APIs are available, middleware copes with migration of objects from one platform to a remote platform, conforming a whole set of Interworking functions. In the following, some architectural approaches will be presented highlighting the correlation to the High-level Reconfiguration System model.

2.4 Heterogeneous Network Architectures and SDR Network Functions

SDR Terminals must be supported by new network entities or functions and a fast download and reconfiguration management must be provided by networks. Before we introduce these new functions, we will define the interworking between different networks and the relationship to reconfigurable terminals. In the future systems, a certain deployment is required to support the interworking between different radio sub-networks in particular between 2G, 3G and 4G systems. Generally we consider sub-networks capable of running different radio access technologies (RATs). Currently different scenarios towards the interworking between different radio sub-networks are existing/under investigations (see Appendix 1 in Section 9.1). If the interworking between different access technologies is nowadays controlled by the core network (loose and tight coupling case), information is spread over several network elements, i.e. increased delay for inter-system handoff due to high number of involved network elements. Therefore a need of evolution solutions for interworking should be thought of, in order to maximize the benefit of the co-existing of different radio access network.



© 2002, WWRF 34

IWU RNCIWU

GGSN

SGSN SGSNSGSN

SDRmobile

AP AP APAP NODE B

NODE B

Iu Iuhl2 Iurhl2/utr Iurhl2

Iub Iubhl2Iubhl2

Uu Uuhl2

Tight Coupling

Loose Coupling

Figure 10: Tight /Loose Coupling between WLAN and UMTS

2.4.1 Management and Location of Profile Data for Mode Switching In order to support fast reconfiguration or intersystem handover and the related mode negotiation procedure among heterogeneous networks, the co-operation between terminal and network should be highlighted. One important key of the co-operation between the network and the terminal is the information (user/terminal/service/network profile) needed by the mode negotiation and radio resource management for Intersystem handover or any other adaptations. These information or Profile data describe the capability of terminals, service, network and user preferences and present an important decisive element in adaptation (Intersystem handover) decisions. Two key features should be considered for mode switching (Intersystem handover):

• Database for system deployment supporting Intersystem handover between coupled RAT sub-networks. The database can be organized as table for storing network topology,

• Management and storing of terminal (user/service) profile data in RAN and CN depending on network interworking (e.g. tight vs. very tight coupling).

Different scenarios and solutions for handling the profile data and the terminal measurement report depending on the interworking method can be identified and are presented in Appendix 2 (Section 9.2).



© 2002, WWRF 35

2.5 SDR System Architectures The suitable network architecture based on IP paradigms needs to be further developed, which supports reconfigurable terminals and access networks, manages software download traffic, provides reconfiguration support and facilitates joint radio resource management. The possible architecture, could take as a basis the TRUST Network-centric architecture [4] [23], presented in Figure 11. The network provided supporting entity serves as a proxy instance for negotiations with other network entities, in particular the Serving Re-configuration Manager (S-RM) in the Access Network and the Home Re-configuration Manager (H-RM) in the Core Network.

SoftwareRepository

Core Network

AccessNetwork 2

AccessNetwork 1

TerminalDatab aseHRM

S-RM

S-RM

P-RM

P-RM

P-RM

P-RM

P-RM

P-RM

So ftwareReposit ory

Sof twareRepository

SoftwareProvider

ManufacturerServer

Soft wareRep ository

Figure 11: Network-Centric Architecture

The S-RM is used in each Access Network and is dimensioned according to the number of users that an Access Network can support and what the expected services for the Access network are. The P-RM is used to minimize delays, use information on location and status of terminal, and negotiate between terminal and S-RM a strategy for reconfiguration. Both S-RM and H-RM are key elements for upgrade of a large number of terminals and they relieve currently deployed network entities from several management and security issues that have a critical impact on network performance. The SDR functional architecture developed in TRUST [4] is presented in Figure 12. It reflects elements needed in the terminal architecture and in the network. The terminal architecture consists of re-configurable components and terminal resource system related parts (depicted in green colour) and on the other hand re-configuration process control and configuration parts (shown in red colour), which are the core of this architecture. Additionally, network implication during the re-configuration process are also addressed (entities in purple colour). Arrows drawn between entities represent interactions and indicate either some kind of negotiation, a store/retrieve type of interaction if one of the entities represents a collection of data, a kind of trigger, or a query operation.



© 2002, WWRF 36

Mode Negotiation andSwitching Module (MNSM)

SoftwareDownload

Module (SDM)Bandwidth

ManagementModule(BMM)

ModeIdentification &

MonitoringModule (MIMM)

Access StratumModule

Network BearerService Profile

ProxyReconfiguration

Manager(PRM)

QoS Manager

Location UpdateModule

ApplicationApplication

ApplicationUser Interface

User

NetworkOperator

ServiceProvider

ProfileDatabase

TerminalReconfiguration

ProfileLookupTables

TerminalCapability Lookup

Table

AuthenticationManager

ConfigurationManagement Module

(CMM)Reconfiguration

ManagementModule(RMM)

Resource System Management Module (RSMM)

CPUManagement

MemoryManagement

PowerManagement

Figure 12: Functional Architecture for SDR Equipment

This functional architecture may be mapped on terminal and base stations physical architectures. The objectives of the reconfiguration architecture are to support a fast and reliable reconfiguration and to use the available resources in an efficient manner. Furthermore a common functionality is required to avoid a continuous adaptation of the backbone infrastructure in case of the possible heterogeneity of future radio access networks. Therefore the main responsible components and functions are located in the particular radio access network and additional on the terminal. The core entities in the reconfiguration process are the proxy reconfiguration managers (PRMs) located in every radio access network. The PRMs are the contact points for every terminal attached to the radio access network concerning reconfiguration. In case of a terminal initiated software download, the terminal signalises the need of reconfiguration to the current PRM in the radio access network and the PRM is afterwards responsible for the delivery of the appropriate software module. For the mode switching support, the PRM performs additionally different measurements and informs the terminal and the neighbouring PRMs as well.



© 2002, WWRF 37

With reference to the software download, the PRM stores necessary software modules in its local repository. However, the overall capacity of the storage space in the PRM is not so high. The intention is to have a fast access on the most frequently used modules. For less frequent requests of required software there exists an interface between the PRM and an intermediate server database, the serving reconfiguration manager (SRM). Thus, the request is forwarded and processed by this SRM. Another possible reconfiguration supporting functionality is the Inter-PRM-Interface. Therefore, neighbouring PRMs are connected to each other and enabled to exchange some information about the current status of the accompanying radio access or about an ongoing mode change of a terminal. The reconfiguration of a terminal must not only be initiated by the terminal, but can also be triggered by an external entity. In the case of a new hardware driver version, it is inefficient to inform each terminal separately. The use of multicast would help to optimise the content delivery. We call terminal reconfiguration serving area (TRSA), the area of the served PRMs by a SRM. The TRSA encloses all PRMs connected to one SRM. The TRSA is not restricted to one single radio access network or technology and can therefore be larger and cover several radio access networks (e.g. if the total cover of an area is achieved by different WLANs) or smaller than a single radio access network and cover only a part of the access network (e.g. if a single radio access network covers the whole of a continent). All the reconfiguration signalling from and to the TRSA leads either across the external connection of the SRM or across the Inter-PRM-Interface, if neighbouring PRMs with overlapping cells exchange information. The Figure 13 shows an example of a terminal reconfiguration serving area. In this area different radio access technologies are located. 3 hotspot areas with 2 access points (e.g. IEEE 802.11 or Hiplerlan2) in each area with lower range but high maximum available bandwidth and one cellular access point belonging to the same TRSA. The neighbouring PRMs with overlapping cell coverage are coupled with each other by the Inter-PRM-Interface and every PRM has a connection to the local SRM.



© 2002, WWRF 38

PRM

PRM

SRM

HOTSPOT

CELLULAR

SRM: Serving Reconfiguration ManagerPRM: Proxy Reconfiguration ManagerTRSA: Terminal Reconfiguration Serving AreaS-P-If: SRM - PRM InterfaceI-P-If: Inter-PRM Interface

TRSA

AP AP

PRM

HOTSPOT

AP AP

PRM

HOTSPOT

AP AP

NodeB NodeB

Figure 13: Example of Entities and Interfaces of a Terminal Reconfiguration Serving Area (TRSA) with

different Radio Access Technologies.

A SDR terminal could perform many different types of reconfiguration. Among others, the firmware associated to different hardware parts might be updated, as, for example, new DSP algorithms that might improve connection to existing or new access networks. New application might be downloaded, e.g. update to new version of WAP. Also new codecs for existing applications might appear, as new voice or image coding allowing a better compression. Malfunctioning terminals might be repaired by means of new software if the problem was provoked by some bug in the old one without the need of expensive and inconvenient shipments. Even new transport protocols or improvement in existing ones could also be adapted by a SDR terminal after downloading the required files. A software terminal allows the reconfiguration of every layer.



© 2002, WWRF 39

A special mention is to be made for massive software downloads. This could be the case, for instance, of fixing an existing bug by means of a software update. Apart from an appropriate planning (scheduling it for low traffic times within the network, using hot-spots offering capacity for a high number of users), there is the need of minimising the impact in the radio link. Multicast or broadcast can solve or at least minimise this problem but they also introduce extra requirements in network functionalities. Support for multicast/broadcast or adding reliability are crucial aspects for software downloads, specially for the case of mass-upgrades, also mobility is an important aspect in case the user performs a handover while receiving a download from a multicast/broadcast session. There are also some reconfigurations specific for vertical handovers, changing to a different radio access technology might imply software download if the RAT has not been used or the terminal storage capabilities are limited (and the required software needed to be deleted). In addition, the whole or part of the algorithms required in order to negotiate with the available networks prior to taking the decision to reconfigure might be offered for download. For example the steps required in the algorithm, the measurements the terminal requires or the mapping functions in order to compare parameters of different networks might be downloaded. The state of the terminal influences greatly the requirements of the reconfiguration process. For example, the possibility to scan the radio frequencies change radically depending on whether the terminal is idle or in connected state. A terminal in idle state does not have strong time constraints for monitoring of alternative radio access technologies or performing software download, but, on the other hand, the necessity of reconfiguration might be quite limited. A terminal in connected state has more reconfiguration triggers but also has higher constraints. Since the terminal has a connection running there is no much time left in the terminal to perform monitoring of different available networks as it can only use transmission interruptions for the frequency testing. A vertical handover to another access technology might have different time restrictions imposed, among others, by the state of the terminal or by the cause triggering the handover. The higher the constraints are, the more important it is to have assistance from the network side retrieving as much information as possible. For example, for a faster identification of possible modes the network could inform the terminal about available radio technologies in the near of the terminals position. The terminal can now limit the scanning to the corresponding frequencies. Furthermore, the network could provide the terminal with additional helpful information, for example different measurements from the neighbouring networks, services provided and their general QoS. Also short-term information (currently occupied resources) can be provided.



© 2002, WWRF 40

If the PRM is aware of the requirements placed by the current session(s) running at the terminal and also of some user requirements and preferences and terminal capabilities, it may provide a further selection of RATs fulfilling these requirements avoiding unnecessary negotiations. If the required software modules for reconfiguration are not available, the terminal has to request them at the PRM. This might also be a decision parameter if the reconfiguration process is urgent. A mode for which the required software is available at the terminal or at the PRM might be preferred above another one for which the software must be downloaded from a server since this introduces further delay. If the PRM is aware of the neighbouring cells it could obtain and store the software required for reconfiguration, the terminal could download these modules in periods when no connection is established, or might perform the download in the background with quite a low priority without impacting the active sessions. If the download is crucial for reconfiguration, this should take place with high priority, the active connections might get their priority reduced or even be stopped/cancelled to allow completing the download in time. This scenario highlights the importance of having the modules cached somewhere close to the terminal, the PRM is seen as the most appropriate entity for storing this kind of software. The SRM might collect less frequently requested downloads as well. Another point considering reconfigurability is the general download of application updates or new driver versions where time constraints are, in general, not so strict. The network could schedule the download and execute the process in a moment of low load and use therefore the resources more efficiently. For this the terminal should provide its reconfiguration requests with a priority indication for the download. In the case of an external initiated reconfiguration, e.g. by the manufacturers server or HRM, the terminal is notified about the available module. If the terminal is in a busy state and currently not able to receive it, the terminal should inform the PRM about it. Otherwise, if the transmission succeeded completely, the terminal should acknowledge the reception. If errors or packet loss occur during the download process, the terminal could request some retransmissions at the PRM.

2.5.1 Proxy Reconfiguration Manager The PRM is in charge of negotiating and obtaining all kind of information from the network in order to minimize interactions on the wireless link and also to avoid wasting terminal resources in these negotiation and information obtainment processes. The PRM acts on behalf of managed reconfigurable terminals; here is a list of some functionality of PRM.

• Information broker for the terminal, • Autonomous Service Discovery and Mode Negotiation (required during Mode

Negotiation), • Download Management (inter-working with other RRM functions), • Terminal Classmark awareness, • Records terminal classmark and capability information,



© 2002, WWRF 41

• Cashes measurements of terminals operating in specific mode (required during Mode

Monitoring), • Caches negotiations of terminals requesting same bearer services (required during Mode

Negotiation).

2.5.1.1 Proxies in IP-based Networks To provide requirements for IP based RAN architecture we start from the following All-IP Scenario supporting reconfigurable terminals. The PRM is functionally split into a user and control plane servers following the methodology of the IP-based RAN. SCOUT as the follow-up project of TRUST introduced the proxy methodology into existing network architectures [33]. The IP based RAN architecture is based on the following paradigms. De-layering It means that the logical and physical separation of the network elements on three functional planes:

• Control plane, • User plane, • Transport plane

The user-plane handles the user data exchanged between the terminal and the CN. Its main task is to transform the user data into radio frames to be transmitted by the Radio Base station and vice versa. Due the real time radio processing requirements, the user plane functions will be implemented by a highly specialized hardware platform: The User Plane Server (UPS). The control-plane manages the radio resources and controls the radio processing in the user plane. The control plane functions are grouped within the Radio Control Server (RCS) that is typically a standard all-purpose platform. One implication is that the control functions (in the c-plane) have the capability to manage and control the radio resource in the u-plane even if are related to different radio technologies. IP Transport Protocol All traffic transport in the whole network is based on IP datagrams. Thus, the network provides end-to-end IP based connectivity and supports virtually all IP based services. Radio base stations (BS, NodeB) are directly connected to the IP transport network. It means that the radio base stations are connected with the rest of the network via IP transport protocol. Hierarchical Function Distribution Hierarchical distribution of the functions means that network functional entities that execute functions related to a particular access technology are grouped into functional domains called ‘access networks’ (IPbRAN). Functions common to all access technologies are provided by the subnetwork called ‘core network’ (IPbCN).



© 2002, WWRF 42

The function split in c-plane and u-plane domain introduces scalability and load balancing for the proxies and their processing capability. Following the same approach the PRM is split into Software Download and Reconfiguration Controller (SDRC) that collects c-plane functions, and Software Download and Profile Repository (SPRE) that collects u-plane functions. Their functions are explained in the following sub-chapters. This scenario is based on IP-based RAN and CN concepts and SDR concepts defined in SCOUT and includes new elements with the aim to address software download and reconfiguration functions (SDRC and SPRE servers). For example, a new evolution of BTS could be used to interface with SDR terminal. This kind of BTS should have an IP interface and contains some of the functionality previously held in the core network with the aim to provide multimode capabilities.

IP

GE-BTS

UT-UPS

UT-UPS

RCS

RCSSPRE

SDRC

SDR-BTS(GSM,

UMTS, 4G)

IPbRAN IPbCN

Up Control

Up Transport

CSS

MGC

MG

IGSN

User Plane Server - UTRAN

Radio Control Server

Sw Download and Reconfiguration Controller

NODE B

Radio Control Server

User Plane Server - UTRA N Sw Download and Profile Repository

Software Radio BTSimplementing old and new air interfaces based e.g. on MC-CDMA

Css : Circu it switched server

Figure 14: IP-based Network and Proxies Supporting Reconfigurable Terminals



© 2002, WWRF 43

•

2.5.1.2 Function Split in Control and User Plane for PRM It follows from Proxy functions, that the PRM is mainly involved in mode monitoring, mode negotiation, mode switching and software download, where information about user, terminal and services and control capability are required. Following the de-layering approach PRM functions can be split in u-plane and c-plane functionality. The u-plane functions collect all the profiles and the information needed for the performing of the software download. The c-plane functions collect all the functions needed to perform the control operations. We call:

SPRE: Software Download and Profile REpository (U-Plane) the logical entity that collects: (1) Terminal, user, service profile, (2) Software modules,

• SDRC: Software Download and Reconfiguration Controller (C-Plane) the logical entity that hosts the PRM controlling functions, in particular: (1) Software download control functions, (2) Reconfiguration control functions.

Figure 15: PRM Function Split

The u-plane PRM (SPRE) should be located in the RAN, because the following information has to be available and updated as fast as possible:

• Channel and system load conditions, • User service profiles, • Application QoS, • Terminal capabilities, • Network address and protocol.

Depending from the type of coupling between different RATs and the time constraints of the service and the necessity or not to perform a seamless handover, the c-plane PRM (SDRC) could be located both in the RAN (near or included in the RNC) or in the core network (near or included in the SGSN). When the SPRE and SDRC are located both in the access network, the interaction with the RRM is more direct and the micro mobility management could be managed from a dedicated SDRC function. The following figures show the location of the SPRE and SDRC in both scenarios.



© 2002, WWRF 44

Figure 16 Example of Proxy Control Functions in the Core Network (left) and in the RAN (right)

2.5.1.3 Inter-PRM-Interface The previous chapters have already shown that the overall functionality of the PRM is beyond the usual proxy functionality. One extension of the PRM could be a connection to neighbouring PRMs and the exchange of additional information via an Inter-PRM-Interface. First of all this could contain long-term information as the general supported QoS in the other radio access network (e.g. the priorities of different traffic classes, maximum bit rate, maximum delay, etc). Thus, the PRM could decide in advance which neighbouring mode is useful and for which mode the terminal should scan. After the detection of an alternative mode, which general QoS is promising, the PRM could request short-term measurements at the neighbouring PRM. The final decision should be made after the consideration of all the measurements. After a mode switch is initiated, the old PRM could transfer useful terminal information to the new PRM over the Inter-PRM-Interface. In this way, the new PRM can prepare the information concerning the attached neighbouring radio access networks for the new terminal and provide it to the terminal at an early stage. As far as the measurement and resource information are concerned, every QoS supporting radio access network must provide a resource reservation mechanism. If there is a resource manager available, the PRM can request the long-term as well as the short-term information from this manager via the Inter-PRM-Interface and the neighbouring PRM and inform back the manager in advance if a mode switch is initiated. If there is no resource manager or other resource information entity in a network, the PRM must measure and store general results on its own.

2.5.1.4 Mass Upgrade For the mass upgrade of terminals the multicast mechanism could be used to avoid network overload. The idea is that every terminal manufacturer, application developer, etc has its own server. If a terminal is now registered with its profile at the PRM, the PRM knows for which components of the terminal a mass upgrade could happen.



© 2002, WWRF 45

After the registration of the terminal, the PRM joins a multicast session for every possible component. If there is a mass upgrade going on, which a certain server initiated, the SW packets are only delivered to these PRMs which joined the multicast group. Appendix 4 (Section 9.4) shows an example of multicast mass upgrade user data flow.

2.5.2 SRM and HRM Role and Location The main idea is to have a hierarchical distributed architecture, which minimizes the network load and speeds up the software download. The home reconfiguration manager (HRM) is located in the home network of the terminal and is informed by providers about new software upgrades. In this case the HRM notifies the availability of new software to the SRM in the radio access networks and forwards the software to them in case of a mass upgrade. If a request for a software download arrives at the HRM, it is also responsible for the authorization of the terminal in case of a request to download a licensed software. Another point considers accounting of software download. For this the HRM uses a charging repository, which is updated if appropriate software is downloaded. The SRMs are located between the PRMs and the HRM. One SRM is connected to several PRMs and is responsible for the provision of reconfiguration software to the attached PRMs. Thus the SRM manages on the one hand a large database of software modules for the reconfiguration process and is on the other hand able to get non-available software e.g. from external servers or HRM. Opposite to the PRMs, which aim to reduce the delay and needed memory and are caching only a small amount of files, SRMs have access to large software repositories and stores a larger amount of files. Furthermore, the SRM could be involved in the control of the mobility, allocation of resources and security of moving terminals. This includes procedures required for vertical handovers; location update and inter-working between different radio access technologies in order to provide the desired QoS. If in case of a mode switch the necessary mode software for another radio access technology is not already stored on the terminal, the required software modules must be delivered by the PRM. Because of the large number of different radio access schemes and different terminals, the PRM does not store every possible software module. Therefore this reconfiguration architecture includes a hierarchically reconfiguration management architecture. To speed up the reconfiguration process, every PRM caches the most frequent used modules within his access network. One difficulty in the speed up reconfiguration process occurs, if the necessary software modules are neither available at the current PRM nor at the new PRM. For this the PRM contacts his Serving Reconfiguration Manager (SRM) and informs him about the appropriate software. Now the SRM is responsible for the provision of the software and forwards it to the requesting PRM.



© 2002, WWRF 46

2.5.3 Reconfigurable Modules and Protocol Stacks The reconfigurable SDR terminals architectures are object of consideration since middle of 90’s. The typical implementation of SDR Forum SW and HW implementation for SDR military platform (SPEAKeasy) is presented in Figure 17 [24].

Figure 17: Military SDR Platform Architecture (SDR Forum)

The relationships between HW and SW in SDR, ensuring open platform characteristics, proposed by E. Buracchini [38], is presented in Figure 18. This clearly depicts the introduction of Application Programming Interfaces (APIs) and the inclusion of Virtual Machine (VM).

Figure 18: Decorrelation of SW and HW in SDR Context



© 2002, WWRF 47

The SDR Forum [24] has compared open platforms architectures, from PC and SDR handheld, as depicted in Figure 19.

Figure 19: Open Platforms Architecture Comparison (SDR Forum)

In order to have an interoperable environment for different SDR components, JTRS Software Communication Architecture (SCA) based on CORBA, which is also adopted by SDR Forum, has been defined [28]. SCA aims to define a middleware that allows baseband modules, modulation modules, protocols working together over different SDR platforms. SDR Forum supports that applications portability is an essential concern for software radio that is why the Forum promotes the Software Radio Architecture (SRA). One of the SRA goals is to be able to port a waveform application from one SDR Set to another one. Portability of SRA Applications is mainly based on two technologies :

• Standardized layers, • Component approach.

The processing environment and the functions performed in the architecture impose differing constraints on the architecture. An Application Environment Profile (AEP) has been defined to support portability of waveforms, scalability of the architecture, and commercial viability:

• An operating system (OS) based on POSIX specifications shall provide, as a minimum, the functions and options designated as mandatory by the AEP,

• A communications middleware layer based on CORBA, • And the Core Framework (CF) layer of the SRA which specify the configuration

management framework in order to install, deploy, run, stop and dismount applications.



© 2002, WWRF 48

To be SRA conformant, applications are supposed to settle above those three layers (Figure 20).

Applications

Core Framework

CORBA ORB

OS Accessunlimited

OS Accessunlimited

OS accesslimited toSRA AEP

Operating SystemOS (function) that supports SRA AEP.Unlimited proprietary APIs forsystem development.

Applications use CF for all file access CORBAAPI

DSP- or ASIC-specific interfaceused forcommunications;can be an Adapter

Device

Drivers

Any vendor-provided OS function calls

HW-specificDevice Driversmay provideaccess to devicefor Applicationor OS

Figure 20 : SRA Architecture Layers

Also, portability relies on the component approach (http://www.omg.org/), conformant SRA applications are supposed to be split into separate components whose ports are connected together at installation time. To achieve better performance and real-time requirements for wireless communication system, non-CORBA based implementation of SDR framework is also considered as another solution. Figure 21 depicts an implementation of SDR software framework based on Linux operating system developed by CCL/ITRI SDR project [38].

http://www.omg.org/



© 2002, WWRF 49

Core Framework

Application

Application

Environment Discoverer

SDR General Manager

Download & Install Manager

ResourceManager

System Service

Device Driver……Device DriverDevice Driver

SDR Hardware Abstraction Layer (HAL)

SDR Module ManagerSDR Module Manager

SDR Software Module

Operating System

……Hardware

SDR RF Device

SDR BB Device

SDR Hardware Device

Hardware DeviceHardware Device

SDR Software Module

SDR Software Module

SDR Hardware Module

SDR Hardware Module

SDR Hardware Module

Hardware Manager

Data Control

Figure 21: Non-CORBA based SDR SW/HW Integration

Different representations of the reconfigurable SDR terminal architectures coexist [23] [25] and one of the main challenges in SDR equipment design resides in the proper description of HW / SW architecture and related interfaces (Figure 22).

Re-config

API

Service Applications

Service Execution Environment

Real TimeOperating

System

Network Layer

Switching Control

Physical Layer (BB, IF,RF)

MAC Layer

LLC RLC RRC Layer

SoftwareRe-configAPI

Service Applications

Service Execution Environment

Real TimeOperating

System

Network Layer

Switching Control

Physical Layer (BB, IF,RF)

MAC Layer

LLC RLC RRC Layer

Software

(a) SDR Architecture and Open APIs (b) SDR Terminal Architecture and Interfaces

Applications

Protocol Stack

Middlew

are services

RTOS / VM

Hardware Platform

Real-Time ORB

System M

anager

Configuration M

anager

1

S2

S3

D1

2

6

5

3

7

4

DriversD2

S1

C1

D3

C3

C2

Figure 22: Reconfigurable SDR Terminal Architectures and Interfaces



© 2002, WWRF 50

For flexible usage of a description of algorithms and more flexibility of implementation of the terminal, the functionality description and the hardware realization should be as much independent as possible. A complete independence probably cannot be achieved, but this characteristic has to be pushed as far as possible. Each communication standard requires a complex algorithm implementation. With the introduction of flexible and re-configurable realization a further dimension of complexity is added. All these complexities have to be handled which can be done by modularization and abstraction. This also implies the detailed definition of modules interfaces (see Chapter 5). All the algorithm descriptions for a reconfigurable SDR terminal can be downloaded and clearly the acceptance for terminal reconfiguration will be strongly influenced by the time needed for this.

2.6 Reconfiguration Security A communication network is exposed to the following basic threats: Messages can be intercepted, modified, delayed, replayed, or new messages can be inserted. A network and provided resources can be accessed without authorization, and they can be made unavailable by denial-of-service attacks. Generic security services defeating these threats are:

• Confidentiality: Data is only revealed to the intended audience, • Integrity: Data cannot be modified without being detected, • Authentication: An entity has in fact the identity it claims to have, • Access Control: Ensures that only authorized actions can be performed, • Non-Repudiation: Protects against that entities participating in a communication exchange

can later falsely deny that the exchange occurred, • Availability: Ensures that authorized actions can in fact take place.

Further security services are anonymity (user identity, tracking), traffic flow confidentiality, or even protection of the fact that communication is taking place. Reconfiguration will allow to change, extend, and upgrade functionality that has by now been fixed. Without suitable protection mechanisms, the flexibility and increased functionality of reconfigurable equipment could be misused in severe ways. It is therefore essential to ensure that reconfigurable equipment can be configured only in safe, authorised ways where the preferences and expectations from the perspective of all involved stakeholders are respected. A reconfiguration architecture comprises security services and mechanisms that implement the reconfiguration security objectives.



© 2002, WWRF 51

Reconfigurable Terminal

Module Store

Reconfiguration Class A

Reconfiguration Class B

M1 M2 M4

M3

Reconfiguration Interface

Local Reconfiguration Manager

IP-Based Core Network Public IP

Network

RM DL RM DL

GW

RAN1 RM

DL

RAN2 RM

DL

Figure 23: Reconfiguration Security System Model

Figure 23 presents a generic system model of the entities relevant for reconfiguration security. Reconfiguration support nodes as reconfiguration managers (RM) and download servers (DL) can be placed in the radio access network (RAN), in the core network, or in a public network connected by a gateway (GW). A reconfigurable terminal provides a reconfiguration interface for the communication between the local reconfiguration manager and the reconfiguration support nodes. A reconfigurable part is called “reconfiguration class”. A reconfiguration class can for example correspond to the radio interface, to voice or video codecs, to communication protocols, to user applications, or to ring tones. The reconfigurable terminal contains a local module store where software, parameters, and further configuration information is stored. The following reconfiguration security objectives specify what the security services and mechanisms are expected to achieve:

• Secure download and execution of software is required to prevent malicious activity from intentionally misbehaving or unfunctional software. Both restricted execution environments (sandbox) that controls access to system resources as well as restrictions on the source of software, either the provider or the download server, can be used,



© 2002, WWRF 52

• Reconfiguration control ensures that only legitimate reconfigurations can take place, i.e.

that only authorized reconfiguration managers that are trusted to obey the user and network preferences can initiate and perform a reconfiguration and only of permitted parts (reconfiguration classes). The signalling traffic has to be protected, and information used for the reconfiguration has to be reliable,

• Access to a user’s private information as his preferences and the current status of his reconfigurable terminal and also himself has to be controlled. It should also be possible for a network operator to keep internal details of his network confidential,

• Reconfiguration allows to flexibly adapt the radio interface during operation. Regulatory bodies pose requirements on radio equipment concerning user safety, electromagnetic compatibility (EMC immunity), and radio spectrum use (EMC emission). It has to be ensured that a terminal can be reconfigured only in such ways that regulatory requirements are met,

• Although security and configuration management mechanisms should prevent the activation of an unfunctional or malicious configuration, fault management procedures could be introduced to detect misbehaving or unfunctional terminals and perform corrective actions.

2.6.1 Secure Software Download and Execution Dynamic software download is a key technology for reconfiguration. Malicious software could invalidate properties required for type approval or assured in a statement of conformance, but it could also lead to other types of harm. For example, it could circumvent other security mechanisms required for secure network access to a cellular network or a company’s Intranet, or it could send a user’s private data to unauthorized parties or make the device simply unusable. The device could also manipulated to behave against the user’s interest, for example by calling premium rate services in the background, or by implementing a surveillance function (bug). To prevent harm from potentially malicious software, two basic approaches can be taken:

• Sandbox Method: In this method, downloaded software runs in a restricted, controlled execution environment (sandbox). Software executing in the sandbox can access only functionality that is considered to be safe; thus, a misbehaving program cannot cause harm. This approach is taken for example for Java MIDlets [40].

• Trust-Based Method: In a trust-based approach, only software from trusted providers is accepted. A solution is expected to be based on signed code where the provider signs a software package using a digital signature (e.g. RSA/PKCS#1 or DSA). Signed code allows the receiver to verify the provider and the integrity of the received software package. The 3GPP 23.057 MExE standard requires that core software may be installed only when it has been authorized by the manufacturer [40]. Especially for open radio platforms on which third party software can be used, a more flexible solution seems to be required.



© 2002, WWRF 53

These two approaches can be combined: Although the software is executed in a controlled execution environment, it is either accepted only from trusted sources, or it receives increased permissions to access restricted functionality when it originates from a trusted provider. For example, the MIDP 2.0 supports trusted applications and privileged domains so that only trusted applications can access sensitive APIs. Mechanisms are defined to sign and authenticate applications using a X.509 public-key infrastructure [43]. The download process has to be protected to prevent illegitimate triggering of a software download, removal or modification of required software on the reconfigurable device or on the download server , and illegitimate access to download servers. Furthermore the usage, copying, and forwarding of software may have to be controlled.

2.6.2 Reconfiguration Control Restrictions on the reconfiguration have to be in place to ensure that only safe configurations are activated that are not only in-line not only with regulatory requirements, but that meet also end user and network preferences and expectations. The checks whether a configuration is safe can be performed by the reconfigurable terminal itself, or by a trusted support node in the network. It has to be defined who is actually allowed to initiate and perform what types of reconfiguration. The manufacturer is expected to be responsible for the implementation of protection mechanisms that ensure the regulatory compliance and protect the terminal from malicious core software. But furthermore it has to be controlled which software is actually downloaded and used, when a reconfiguration takes place and to which mode. These decisions could be under control of the end user, the network operator, the communication service provider, or an independent service provider. Service providers and network operators want to provide a reliable service that meets the expectations of the end users. The activation of a configuration that either does not work or that does not provide the services requested by end users should be prevented to ensure a high user satisfaction and to minimize the need for expensive customer care.

The signalling traffic between the nodes involved in the reconfiguration has to be protected, for example using IPsec or TLS. Furthermore, policy information is required that defines the correct, trustworthy entities and their permissions. Both read and write access to information used for the reconfiguration as profiles, preferences, and information on the current status and configuration has to be protected. Such information may be stored and accessed only by trustworthy entities, and illegitimate modifications have to be prevented.



© 2002, WWRF 54

2.7 SDR System and Network Research Challenges To support the development of software defined and re-configurable radio and networks, the research on SDR System and Software Architectures will have to address the following main areas:

• System, network and protocol architectures supporting re-configurable equipment, • Network-centric re-configuration support, • Terminal-centric re-configuration support.

An immediate impact is expected on:

• Efficient use of the existing network resources, • Enhancing the capabilities for adaptable wireless service provision, • Adaptive and customisable QoS provision by using ‘the right network for the required

service’, • Global access, roaming and service availability.

The three main research areas include a number of technical, regulatory and business issues to be addressed. On the technical side these are: 1) System, network and protocol architectures for re-configuration management: Based on IP-

based RAN and CN architectures and the architectures already defined in TRUST / SCOUT and Mobile VCE Core Project, the requirements for a network infrastructure supporting terminal re-configuration should be assessed. Proxy reconfiguration functions need to be elaborated in the network and dependent on the network infrastructure different approaches need to be developed and evaluated. Distributed architectures for such an infrastructure as well as particular additional components required in the network should be developed. The infrastructure has to provide support for several functions, in particular for enabling distributed profile management, mode negotiation and mode switching decision making, efficient strategies for user-centric mode selection based on context information, and ensuring QoS of software download. Furthermore, new efficient handover procedures for software download need to be defined. Download strategies for fulfilling QoS demands need to be investigated (e.g. in mass upgrade scenarios). A protocol architecture should be developed, which allows the efficient co-operation (coupling) between different RAT. Especially protocol improvements on link layer are to be investigated. The protocol architecture should allow reconfigurable protocol layers to insert, remove, and suspend their services and to inter-work with other protocol layers. The need for a framework for reconfigurable protocol stacks which addresses all layers is needed. Supporting security architecture and functions are needed to allow for secure downloads and reconfiguration.



© 2002, WWRF 55

2) Network-centric support re-configuration. The terminal re-configuration can be at the initiative either of the terminal or the network. A local intelligence on the terminal must interact with the network, other terminals, or new software on another terminal. Procedures and signalling for reconfiguration tasks between communicating entities must be defined. There is also a need for specification of a minimum set of signalling for the purpose of controlling reconfiguration procedures namely, request, control and management processes. The research should also include the following points:

• Analysis of service discovery in support of the re-configuration process and implication of wireless middleware and agent technology from the terminal point of view,

• Automatic modulation and RAT recognition in dynamic spectrum environment to facilitate spectrum on demand functionalities,

• Development of standardized and generic protocols for vertical handover negotiations, • Identification of requirements and constraints on wireless middleware. Definition of

wireless middleware services as transaction management or interaction management. 3) Terminal-centric support re-configuration. The terminal re-configuration manager as part of the local intelligence on the terminal takes care of the successful re-configuration tasks. The research will have to focus on the following technical issues:

• Management of mapping of software on the hardware platform. Management of lock-up, crash, reset and recovery mechanisms,

• Management of run-time insertion, removal, and configuration of software and the modules running on SDR hardware platform through Operating System and Hardware Abstraction Layer (HAL) de-correlating HW platform from application software,

• Definition of open APIs necessary for re-configuration processes, • Development of object-oriented approach for platform design and realization.

Global circulation and issues like standard compliance testing of software re-configurable terminals are the initial topics that need to be addressed by the standardisation bodies with potential interaction with regulators. Furthermore, the provision of a global connectivity channel for software radios and its implications could be investigated and finally research areas as usage of competitors network infrastructure, unified billing and global roaming support have to be explored. Cross network integration and global software radio connectivity and support will have various beneficiaries, the results of this research, the implementation and application of these technologies will influence:

• Global mobility and connectivity to wireless communication systems, • Service specific choice of networks, • Flexible application execution platform and network adaptation, • Global regulation and standardisation.



© 2002, WWRF 56

A transverse challenge is to define a generic model of Software Defined Radio, the result of this research will:

• Create the necessary background to exchange without misunderstanding, • Structure the collaborative work based on a common basis or model • Allow component inter communication • Allow definition of framework: configurability, reconfigurability, control, management,

… The re-configurability support and domains are synthesized in Figure 24 [25]:

Network Architecture

ProtocolsServ

ices

APIApplication

Reconfiguration Control Space

RadioSub-system


ProtocolsServ

ices

APIApplication


TerminalDomainTerminalDomain

AccessNetworkDomain

AccessNetworkDomain

BackboneNetworkDomain


Core Core AccessAccess

RadioSub-system

ConfigurationControl

PartC

onfig

urat

ion

Man

agem

ent P

art


ProtocolsServ

ices

APIApplication


RadioSub-system


ProtocolsServ

ices

APIApplication


TerminalDomainTerminalDomainTerminalDomainTerminalDomain

AccessNetworkDomain

AccessNetworkDomain

AccessNetworkDomain

AccessNetworkDomain





Core Core Core Core AccessAccessAccessAccess

RadioSub-system

ConfigurationControl

PartC

onfig

urat

ion

Man

agem

ent P

art

Figure 24: Re-configuration Support in Re-configurable Access Networks and Terminals

It is inevitable, for potential research into the system and software architecture for Software Defined Radio systems, to include complete access networks into the re-configuration processes and also to introduce reconfiguration management techniques that cover the complete re-configurable communication system. Figure 24 illustrates the co-operation and interaction of network and terminal reconfiguration management; the principle distinguishes between network and terminal reconfiguration management parts (i.e. Configuration Control Part and Configuration Management Part, respectively) but combines them in a ‘Reconfiguration Control Space’.



© 2002, WWRF 57

33 SSDDRR RRFF//IIFF RReeffeerreennccee MMooddeellss aanndd AArrcchhiitteeccttuurreess A key issue in the design of RF-transceivers will be the interaction between the analogue front-end and the digital baseband part. There are a number of RF/IF related non-idealities that can be tackled by means of correction loops in the digital domain (DC-Offsets, IQ-phase and amplitude imbalance, LO-feedthrough, digital predistortion,…). To get an optimised solution in terms of costs, power consumption and performance, modern transceiver architectures have to support a tight interworking of the RF-front-end, the IF-section (analogue and digital), and the digital correction loops in the baseband part. This tendency is strengthened by the advent of RF-CMOS, which may ultimately lead to a “true” single chip transceiver. An example of a 3GPP compliant RF-CMOS transceiver can be found in [45]. Since the development of mobile communication terminals is mainly cost driven, RF-CMOS is a strong contender as key semiconductor-technology for future RF transceivers.

3.1 Receiver Architectures Much of the work done in the field of SDR research focuses on the software part and is based on an approach, which can be called an ideal SDR architecture (see Figure 25). Evidently, this architecture lacks a realistic evaluation of the upcoming technological developments related to the analogue front-end part. If one also takes into consideration the expected power consumption (one of the key problems of today’s mobiles) of such an ideal SDR, it is evident, that the direction of research should turn to more “realistic” front-end architectures. Therefore, feasibility studies of SDR realisations based on different front-end architectures should be performed.

LNA DSPADC

Anti-aliasingFilter

Data sink

Figure 25: Ideal SDR based Receiver

The primary distinction between receivers, is the number of stages taken to down convert a signal to baseband. Direct conversion takes one down-conversion. Superheterodyne receivers employ two or more. In general, complexity increases with the number of down-conversions. There is great interest in direct conversion architecture as a component of a SDR receiver. This interest stems from the fact that direct conversion solves the image signal problem quite neatly. An overview of current state of the art architectures for highly integrated RF-ICs can be found in [46]. Direct conversion architectures are alternatively known as “zero IF” or “homodyne”.



© 2002, WWRF 58

•

•

•

•

3.1.1 Homodyne Receiver Architecture A basic homodyne receiver architecture is shown in Figure 26. The homodyne receiver structure will bring forward vastly different implementation issues when compared with the heterodyne topology. To understand these issues, suppose that the IF in a heterodyne receiver is reduced to zero. The LO will then translate the center of the desired channel to 0Hz, and the channel translated to the negative frequency half-axis becomes the image to the other half of the same channel translated to the positive frequency half-axis. The downconverted signal must be reconstituted by quadrature downconversion (or some other phasing method), otherwise the negative-frequency half-channel will fold over and superpose on to the positive-frequency half-channel. The simplicity of this structure offers two important advantages over a heterodyne counterpart:

The problem of image is circumvented because ωIF=0. As a result, no image filter is required. This may also simplify the LNA design, because there is no need for the LNA to drive a 50Ω # load, which is normally necessary when dealing with image rejection filters. The IF SAW filter and subsequent downconversion stages are replaced with low-pass filters and baseband amplifiers that are amenable to monolithic integration. The possibility of changing the bandwidth of the integrated low-pass filters (and thus changing the receiver bandwidth) is a major advantage if multimode and multiband applications are concerned1.

On the other hand the zero-IF receiver topology entails a number of issues that do not exist or are not as serious in a heterodyne receiver. Since in a homodyne topology the downconverted band extends to zero frequency, offset voltages can corrupt the signal and, more importantly, saturate the following stages. There are three main modes in which DC-offsets are generated.

First, the isolation between the LO port and the inputs of the mixer and the LNA is not infinite. Therefore, a finite amount of feedthrough exists from the LO port to the mixer or the LNA input. This “LO leakage” arises from capacitive and substrate coupling and, if the LO signal is provided externally, bond wire couplings. This leakage signal is now mixed with the LO signal, thus producing a DC component at the mixer output. This phenomenon is called “self-mixing”. A similar effect occurs if a large interferer leaks from the LNA or mixer input to the LO port and is multiplied by itself. A time varying DC offset is also generated if the LO leaks to the antenna and is radiated and subsequently reflected from moving objects back to the receiver.

1 The dynamic range of tunable filters would be a concern for multimode systems catering for air interface standards having a wide variation in signal bandwidth. If we use a single filter with tunable components for a multimode systems catering to the requirements of all the above mentioned systems, it would be difficult to recover the narrowband signals near sensitivity level in the presence of very strong interfering signals. This point is taken up again in 3.4.2.



© 2002, WWRF 59

•

Large amplitude modulated signals that are converted to the baseband section via second order distortion of the IQ-mixers also lead to time varying DC offset. The spectral shape of this signal contains a significant component at DC accounting for approximately 50% of the energy. The rest of the spurious signal extends to two times of the signal bandwidth before downconverted by the second order nonlinearity of the mixers. The cause for the large signal content at DC is that every spectral component of the incident interferer is coherently downconverted with itself to DC. In order to prevent this kind of DC offset, a large second order intercept point (IP2) of the IQ-mixer is necessary.

3GPP compliant receiver front-ends need approximately 80dB gain. The baseband amplifiers contribute most of this gain. That means that even small DC offsets (in the range of several mV) at the mixer outputs may lead to DC levels sufficient to saturate the analog to digital converters (ADC). In time-division multiple access (TDMA) systems idle time intervals can be used to carry out offset cancellation. This kind of offset cancellation can not be used for systems with continuous signal reception. Here, the natural solution for DC offset cancellation is high-pass filtering. This approach is especially suited for wideband systems. From a system level point of view DC-free coding can help to diminish the performance degradation of high-pass filtering. I/Q mismatches are another critical issue for the zero-IF receiver topology. Fortunately, digital correction loops can tackle the problem of I/Q phase and amplitude mismatches from a data point of view. A reasonable level of I/Q match is of course still required. Research Issues

DC offset, • • •

Maintenance of I/Q Balance, Maintenance of low second order distortion.

°90

LNA

Synthesiser (frequency equal to thecentre frequency of desired channel)

BPF

DSP

audio,digital,video

ADC

Gain 20dB

Gain 80dB

Base bandAmplifiers

Gain 80dB

ADC

Figure 26: Direct Conversion Receiver Architecture



© 2002, WWRF 60

3.1.2 Heterodyne Receiver Figure 27 shows the heterodyne receiver structure. This architecture first translates the signal band down to some intermediate frequency (IF), which is usually much lower than the initially received frequency band. Channel select filtering is usually done at this IF, which relaxes the requirements of the channel select filter. The choice of the IF is a principal consideration in heterodyne receiver design (see Figure 27).

LNA

VCO

ADC

°90

I channel for furtherprocessing

IF Amplifier

VCO

Q channel forfurther processing

AGC amplifier

Band selectfilter

Image rejectfilter

Channelselect filter

ADC

AGC amplifier

Figure 27: Heterodyne Receiver Structure with two Hardware Conversions

As the first mixer down converts frequency bands symmetrically located above and below the local oscillator (LO) to the same centre frequency, an image reject filter in front of the mixer is needed. As depicted in the left part of Figure 28, the filter is designed to have a relatively small loss in the desired band and a large attenuation in the image band, two requirements that can be simultaneously met if 2ωIF is sufficiently large. Thus, a large IF relaxes the requirements for the image rejection filter, which is placed in front of the mixer. On the other hand it complicates the design of the channel selection filter (right part of Figure 28), because of the higher IF. In today’s cellular systems the channel selection filtering is normally done with surface acoustic wave (SAW) filters. Another interesting situation arises with an interferer at (ωwanted + ωLO)/2. If this interferer experiences second-order distortion and the LO contains a significant second harmonic, then a component at |(2.(ωwanted + ωLO))/2-2ωLO| = |(ωwanted - ωLO)| = ωIF arises. This phenomenon is called half-IF problem [47]. It is typical of problems that arise if filtering is removed from a radio. Not only do intermodulation problems become exaggerated, but previously unconsidered harmonic distortion problems begin to emerge. Harmonic and intermodulation distortion problems occur when distortion is present in the early stages of RF hardware. Linearity of the LNA and mixer is important with SDR design. It is raised again in 3.4.2. Phase noise and LO distortion also contributes to this problem. This issue is discussed in 3.4.6.



© 2002, WWRF 61

Figure 28: Relation between Filter Bandwidths and IF in Heterodyne Receivers

A major advantage of the heterodyne receiver structure is its adaptability to many different receiver requirements. That is why it has been the dominant choice in RF systems for many decades. However, the complexity of the structure and the need for a large number of external components (e.g., the IF filter) cause problems if a high level of integration is necessary. This is also the major drawback if costs are concerned. Furthermore, amplification at some high IF can cause high power consumption, particularly if a high degree of linearity is to be maintained. Due to the fixed receive bandwidth of the heterodyne receiver structure caused by the external IF-filter, the multimode and multiband capability can only be implemented by using a separate IF section for each mode. This would result in high costs and a complex receiver structure. Research Issues

Image signals – flexible preselect filters – receiver linearity, • • •

Single chip solution, Channelisation filtering – flexible IF bandwidth.



© 2002, WWRF 62

• • •

• • •

3.1.3 Digital IF Receiver Architectures A multiple conversion receiver is shown in Figure 29.

Its advantages are: Good selectivity (due to the presence of preselect and channel filters), Gain is distributed over several amplifiers operating in different frequency bands, Conversion from a real to a complex signal is done at one fixed frequency; therefore a phase quadrature, amplitude balanced, local oscillator, is only required at a single frequency.

Its disadvantages are:

The complexity is high, Several local oscillator signals are required, Specialised IF filters are required.

LNA

Variable LO

ADC

°90

I channel for furtherprocessing

IF Amplifier

Numericallycontrolled local

oscillator

Q channel forfurther processing

DSP

Digital IF

Figure 29: Superheterodyne Architecture with Digital Second Downconversion

Although the multiple conversion stage of Figure 29 only shows two explicit down-conversions (one in the RF hardware and one in the DSP (Digital Signal Processing)), further conversions can be done in the DSP via the processes of “sub-sampling”. If the linearity of the receiver hardware can be maintained to a sufficiently high level, then the channelisation can be performed in the DSP. This can mean that the variable bandwidth IF filter (see 3.1.2) is not necessary. One of the significant stumbling blocks to implementing the superheterodyne architecture would then be removed.



© 2002, WWRF 63

The receiver architecture described above may represent the best choice for a SDR receiver design today, given that the two principal disadvantages2 of direct conversion are very difficult to get around with current technology. With this architecture, the first conversion may be done in RF hardware, and all of the others are done in DSP. Two hardware down conversions will probably be required by the radio LAN (HIPERLAN/2 and IEEE802.11a) which operates in the 5GHz region. With this architecture, the ADC needs to have an analogue bandwidth equal to the IF frequency, and a sampling speed at least equal to twice the bandwidth of the wanted signal. If a superheterodyne architecture is chosen, then the problem of image signals must be seriously addressed. This is done in section 3.4.4. Aspects of digital IF-processing are covered in Section 3.4.7. Research Issues

•

•

•

•

Hardware linearity.

3.1.4 Low IF Architecture Low IF architecture represents an attempt to combine the advantages of a superheterodyne structure, with the advantages of direct conversion architecture (see [48] and [49]). Having a low IF means that the image rejection requirements are not as onerous as with the superheterodyne structure, and the fact that the LO signal is not the same frequency as the wanted signal, minimises the DC offset problems inherent in the direct conversion architecture. Its advantages are:

The DC Offset problems associated with direct conversion architecture can be overcome whilst retaining most of the benefits of this architecture, Lower complexity than the superheterodyne approach (but slightly greater than the direct conversion).

Its disadvantages are:

Better image rejection is required from a low IF receiver than that required of the direct conversion receiver.

Research Issues

• •

Design of complex image filter – Image reject mixer design, Linearity.

2 Local oscillator balance and DC offset.



© 2002, WWRF 64

3.1.5 Six-Port Technology for Terminal Receivers A Zero-IF receiver based on six-port technology is another possible approach to solve the bandwidth requirements of an SDR implementation. Examples of this technique can be found in [50] and [51]. Compared to conventional Gilbert Cell based mixers the Six-Port device has an advantage in power consumption and is inherently broadband. On the other hand there are problems concerning calibration of six-port devices and commercial product are not yet available. Research Issues

• Calibration of the device, • Commercial production of a 6-port mixer.

3.2 Transmitter Architectures In designing the transmitter, like the receiver, there are choices of architecture to be made. Although some of the comments made about certain receiver architectures are directly applicable to the transmitter, there are some differences in emphasis. This section will highlight these differences.

3.2.1 Direct Conversion Architecture If the transmitted carrier frequency is equal to the local oscillator frequency, the architecture is called “direct conversion”. In this case, modulation and upconversion occur in the same circuit. The architecture in Figure 30 suffers from an important drawback. Through a mechanism called “injection pulling” or “injection locking” the transmit LO spectrum is corrupted by the power amplifier (PA). The problem worsens if the PA is turned on and off periodically, as it is the case for TDD systems. Problems also arise if the system has to fulfill tight requirements on output power range, which is usually necessary in W-CDMA systems. Most of the gain has to be achieved in the baseband section, leading to high linearity requirements for the baseband filters and the modulator. Furthermore, the LO lies always in the transmit band, which causes high requirements on the LO-RF isolation. I/Q phase mismatches are also an issue when using direct upconversion. Even a small error in the phase shifting network may lead to a severe degradation of the error vector magnitude (EVM). Direct conversion architecture can only be a successful option if its shortcomings (LO feedthrough, I/Q mismatches) are corrected by means of digital correction loops.



© 2002, WWRF 65

I

DAC

PA

Q

DAC

°90

LO

RF SAW

AGC

AGC

Figure 30: Direct Conversion Transmitter Architecture

Research Issues I/Q balance in the local oscillator, •

• •

Distortion of the LO signal by the PA, Baseband linearity.

3.2.2 Heterodyne Architecture The second possibility of signal upconversion, which circumvents the problem of LO pulling in transmitters, is to up convert the baseband signal in two steps so that the PA output spectrum is far from the frequency of the VCO’s. An advantage of two-step upconversion over the direct conversion approach is that since quadrature modulation is performed at lower “fixed” frequencies, I and Q matching is superior. On the other hand, an IF filter (in most cellular applications, again, a SAW filter) is needed which can increase costs considerably. If high integration is an important feature, then both heterodyne transmitters and receivers can cause problems. Trying to find intermediate frequencies for the transmit and receive section, that does not lead to spurious frequencies falling, for example, in the receive band, may prove to be impossible. This is especially true, if single chip transceivers are to be utilised.



© 2002, WWRF 66

I

DAC

HPA

Q

DAC

°90

LORF

IF stage

LOIF

AGCRFAGCIF

RF SAWIF SAW

Figure 31: Heterodyne Architecture

Research Issues Spurious distortion products, •

• •

IF filter with configurable bandwidth, Single chip solutions.

3.3 The Analog/Digital Interface Besides component issues on ADCs and DACs there are two basic architectures of digital transceivers that can be distinguished from their A/D interface.

• Synchronous A/D interface: This means that the A/D interface is clocked with a standard dependent clock rate i.e., the clock rate is changed for each air-interface which the transceivers supports,

• Asynchronous A/D interface: This means that the A/D interface is clocked with a fixed rate. The sample rate of the digital signal must be converted between chip/symbol/bit rate and the rate of the A/D interface by means of digital sample rate conversion.

Research Issues

• High quality clock generators for a synchronous A/D interface, • Power efficient implementation of digital sample rate conversion for an asynchronous

A/D interface.



© 2002, WWRF 67

3.4 Critical Components This section will review issues that have arisen out of architectural considerations. Current state of the art solutions to these issues will be examined. Necessary research to extend the usefulness of these solutions to a practical SDR design, will be identified.

3.4.1 Filter Functions within a Conventional Receiver In any radio receiver that employs a superheterodyne architecture, filters are required to perform three functions. These are:

• Band-limit the signal to the frequency of interest. This function is often referred to as “channelisation” and is usually implemented within the digital baseband processing of the receiver,

• Suppress the image signal with respect to the wanted signal. This function is performed at the first opportunity in the receiver chain,

• Suppress of out-of-band “blocker” signals to prevent them generating sufficient “in-band” power to interfere with the wanted signal.

It should be noted that if the receiver components were perfectly linear, then it would not be possible for out-of-band signals to generate in-band products, and a filter to achieve this function would not be needed3. In practice, some degree of non-linearity exists in all the amplifiers and mixers that make up the receiver chain. This means that some degree of bandwidth constriction is essential, at an early stage, in the receiver.

3.4.2 Device Linearity A useful measurement of distortion for receiver design purposes is Third Order Intercept (TOI)4. TOI is the value of input (or output power) at which the third order intermodulation distortion product rises to meet the fundamental output power. The second order intercept point (IP2) has also been shown to be important with zero IF architecture. Blocker specifications are an important factor in determining the allowed distortion performance of a receiver. Reference to these specifications for a GSM system shows that if the receiver has a 5MHz RF bandwidth to accommodate the 5 MHz channel of UMTS, then any blocker within ± 2.5MHz of the center frequency may introduce distortion products into the wanted GSM channel. Blockers at these frequencies are allowed to be up to –23dBm. Calculations based on the minimum specified GSM signal and the maximum allowable “in-band” interference due to the

3 The Phase noise of the Local oscillators is another factor that necessitates the presence of filters in RF designs. Unless LO is pure, the LO phase noise will translate the out of band interfering signals through the mixing process. RF filters therefore relax the requirement on the phase noise and spurious specifications of the LO. 4 Alternatively IP3 (Intercept Point, 3rd order).



© 2002, WWRF 68

blockers, will show that the minimum input TOI will be +20.5dBm. This is an onerous linearity specification and obtaining devices (mixers and amplifiers) with this specification is currently not possible, when considering cost and power-consumption issues. We can infer from this result, that the receiver of a SDR should be extremely linear. In general, for best overall distortion performance, the components where the signal is at its highest power levels require the best distortion performance. A large body of research has been undertaken on linearising PA (see for example [52]). To enable SDR receiver design, work needs to undertaken on linearising receiver components. Reference [53] discusses the linearisation of wide-band RF receiver amplifiers. Work on linearising mixers was undertaken under the IST TRUST program (see [54] and [55]). A new technique known as “frequency retranslation” has been developed under this project. This work is further discussed in section 3.4.3.

3.4.3 Mixer Linearisation The inherent nonlinearity of mixers is particularly acute in SDR applications. Here, the broadband receiver frontend ‘sees’ not only the wanted channel, but also a number of nearby signals. A non-linear mixer will downconvert all of these received channels together with the wanted channel to IF. During this frequency translation process inband interference caused by the nearby signals will be added to the wanted channel, making it potentially more difficult or even impossible for the receiver to correctly detect the wanted signal. This places demanding filtering requirements on a broadband receiver frontend to reject the out-of-band unwanted channels (blockers) entering the mixer (Section 3.4.2). Filtering-out strong interfering nearby channels at high RF frequencies is difficult. In a traditional radio application, the frequency of transmission and reception will be fixed and the filter parameters will be set only for these known frequencies. This is incompatible with the SDR concept and filtering-out the blockers of multiple standards will be a challenging task for RF designer, thus making a linear mixer for a SDR frontend an attractive proposition.

3.4.4 Image Signals and Variable Preselect Filters Image signals are a problem that must be dealt with if a superhetrodyne receiver is being employed. One possible way of achieving this is to make use of a variable preselect filter. An image reject filter will always operate at RF, therefore, the option for the design of a flexible preselect filter is at present limited to realisation as either a distributed component design or as a MMIC.



© 2002, WWRF 69

There have been a few variable MMIC filter designs reported in the literature, notably that of Katzin et al. [56]. The device described in this technical paper was produced as a prototype MMIC for the Hittite Corporation. Two versions were produced, both exhibiting ~100MHz bandwidth. One had a centre frequency that could be swept from 1,500 to 2,000MHz, and the other a centre frequency sweepable from 1,980 to 2,650MHz. The filter unfortunately never progressed beyond the prototype stage, due to lack of sufficient dynamic range [57]. Non linearity is introduced into MMIC designs from two sources. Firstly it occurs because a varactor is often used to tune the filter. Secondly, a nonlinear active device is often used to compensate losses in MMIC filter components5. Distributed component microwave filters might be electronically tuned by the following techniques.

• Varactor diode tuning at some strategic point on the filter structure, • Constructing the filter on a substrate, whose dielectric constant could be electrically

varied, • Switching parts of the transmission line so that the physical characteristics of the filter

structure could be changed. Switching the component parts of a filter, in and out of circuit, using Micro-Electro-Mechanical Structures (MEMS) seems to offer an interesting solution [61]. The use of Electro-mechanical switches will mean that the filter is composed entirely of linear components, and therefore the dynamic range of the filter should not be prejudiced.

3.4.5 ADC/DAC Issues The dynamic range requirement of an A/D converter in a radio receiver is determined by a set of parameters closely related to the given application. These parameters include the required SNR for baseband decoding, peak to average signal ratio of the given modulation scheme, channel noise already present at the ADC input and most importantly, the residual signal range after the gain and filtering functions preceding the ADC (often the highest residual interfering signal over the weakest desired signal). The bandwidth requirement, on the other hand, depends on the IF frequency, input bandwidth (signal as well as those interferers to be tolerated), as well as certain amount of over sampling desired by the base-band section of the receiver. A software-defined radio expects the ADC to cope with the worst-case combination of the above parameters in order to cope with a wide range of possible applications. Calculations based on 2G and 3G radio standards point to dynamic range requirements in excess of 100dB and speed of the order of several hundred mega samples per second.

5 By introducing, for example, negative resistance across an inductor.



© 2002, WWRF 70

If converters consuming several watts or more power (those perhaps found useful for a SDR radio on a naval vessel or a juggernaut) are to be excluded from commercial portable applications, then suitable ADCs do not exist today for SDR applications. Given that typical radio ADCs have a dynamic range between 60 and 70dB (10~12bit) today and the dynamic range improvement in the past has occurred at a rough rate of 4 bits (24dB) per decade without power constraints, serious and sustained long-term research is absolutely necessary if the SDR dream is to be fulfilled within the next decade. In the short-run, reconfigurability can be achieved by designing converters that target the most useful combinations of applications. In [77] for example, a very low power, IF sampled ADC has been described for dual mode GSM/WCDMA applications. For the combination of radio standards described in the early part of this document, it should also be possible to find a suitable and clever architecture that fulfils all requirements without excessive power consumption. The generic question of how to provide the desired bandwidth and resolution on demand, must rely on a substantial advancement of the state-of-the-art. Promising architectures for such improvement include those based on sigma-delta modulation and pipelining, as well as hybrids thereof. Extended use of self-calibration techniques as well as digital pre/post-processing techniques may also be a very useful way forward. Scaling of semiconductor technology in the next decade will help us improve speed. Downward scaling of allowable supply voltage, however, makes dynamic range issues even more acute than they are today. While signal range is forced down by available headroom in supply voltage, the lower limit of thermal noise that presents itself in the form of kT/C noise in a sampled-data system, does not scale with the transistor feature size. Research Issues

• Low power, high performance ADC architecture, • Trade-off in the definition of RF receiver and A/D converter, • Dynamic reconfiguration of architecture, • kT/C noise and dynamic range, • Timing jitter in high-IF converters (clock jitter of LO and aperture jitter of the ADC), • Low voltage design, • Device matching, • Intelligent self-calibration schemes, • Digital error correction by means of pre-processing (for the DAC) and post-processing

(for the ADC).



© 2002, WWRF 71

3.4.6 Broadband Synthesiser and its Impact on Phase Noise Characteristics / System Performance

The LO of any SDR receiver must operate over a wide frequency range. The tuning voltage available at the input terminals to an VCO, on the other hand, will be limited. To cover the wide tuning range would necessitate a large tuning sensitivity for the VCO. The higher sensitivity would result in increased LO spurious components and phase noise:

• Increased LO phase noise and spurious outputs would further increase the attenuation demand on RF filters,

• Increased phase noise would be problematic in broadband systems like 802.11a (OFDM carriers would lose their orthogonality effectively increasing the noise floor),

• Increased LO phase noise can cause increased baseband noise in zero IF and low IF designs. This happens because the decreasing correlation between instantaneous LO phase at LO input and LO leakage at RF input produce will produce this noise. This would also create problems mostly in wideband designs.

3.4.7 Digital IF-Processing All digital signal processing that lies in between the baseband processing and the AD interface should be named “digital IF-processing”. A particular receiver architecture where the naming fits perfectly is the “Digital IF Receiver Architecture” of Section 3.1.3. However, also the other receiver architectures as well as transmitter architectures require digital signal processing apart from the baseband processing. Digital IF-Processing on the receiver side prepares the digitized signal in a way that pure baseband processing can follow. Digital down-conversion of the channel-of-interest to baseband, channel filtering, and sample rate conversion belong to the field of digital IF-processing on the receiver side. Respective tasks can be identified on the transmitter side. The fundamental problem of realizing digital IF-processing are the very high sample rates that require very high clock rates of the underlying hardware platform. This results in a high power consumption. Besides this, different air-interfaces require different types of digital IF-processing that must be performed on a common hardware platform. Research Issue

• Design of a common power-efficient hardware platform for digital IF-processing.



© 2002, WWRF 72

3.4.8 Commonality between TX and RX Schemes One important consideration when selecting the architecture for implementing a mobile terminal is to try to exploit common points in receiver and transmitter implementation. This will lead to a reduced complexity, and important cost savings. Receiver and transmitter designs share a number of problems, which if not necessarily the same, are more or less “duals” of each other. The research in the pre-processing filter in reception, and the post-processing filter in transmission have common points. Linearisation techniques, applied to transmitters and receivers, amplifiers and mixers, will be similar. Linearisation techniques are applied to a receiver, to enable the receiver to increase its capacity to handle blocking signals. Linearisation techniques are applied to the transmitter to enable the transmitter to reduce the output of spurious emissions. Linearisation techniques are also applied to both the transmitter, and the receiver, to protect the integrity of the modulation. The architectures for the transmitter and receiver chains of the TRUST Project [23], proposed by the University of Bristol and TTI teams, follow the multi-conversion strategies, with one intermediate frequency almost identical. The use of similar IFs will give us the possibility of employing a common design for the IF reconfigurable filters, with all the advantages this will bring. An important consequence of employing the heterodyne transceiver architecture stems from the fact that the choice of the IF is closely linked to the duplex distance of the system. It is desirable for a SDR to have the choice of independent transmit and receive bands. Based on that requirement we will also have a variable duplex distance between those bands, which increases the number of spurious responses dramatically. A highly integrated solution relies on a frequency planning concept, which ensures that there are no low order spurious signals in the receiver band, since isolation between Tx and Rx paths in an highly integrated transceiver is critical. A direct conversion architecture does not suffer from any limitations of the duplex distance between Rx and Tx bands.



© 2002, WWRF 73

• • •

3.5 SDR Design Choices

3.5.1 Active and Shadow Receiver Chains There is a school of thought that says that if a reconfiguration is to be truly transparent, then there should be two RF chains available in the transceiver. One channel would be active, and the other would be performing housekeeping tasks (such as looking for high power interfering signals), or reconfiguring prior to transparently taking over the traffic. Fairly obviously the alternatives are:

A single transmit - receive chain, An active and shadow transmit - receive chain, A hybrid in which some of the elements of a transmit-receive chain are duplicated.

3.5.1.1 Single Transmit – Receive Chain This architecture relies in the fact that mobile protocols are designed to cope with random blocking of the information transfer. All current standards can cope with this as they are designed to operate in a harsh multi-path environment. One could make this assumption about future standards. It is possible if the user tolerates service breaks of (say) one second within the current generation of services, then a single RF chain architecture could be perceived as being transparent. Advantages

(i.) Complexity and cost could be substantially reduced. Disadvantages

(i.) There is no real possibility of properly monitoring the receiving conditions of other standards. The definition of the target standard would have to be based on some other criteria (maybe it could be defined from the base station).

(ii.) In real terms the standard availability and functionality information would have to be held at the network level and accessed by the mobile for full transparency with this system.



© 2002, WWRF 74

3.5.1.2 Active and Shadow Transmit and Receive Chains The two transmit and receive RF sub-systems should be identical in order to guarantee a proper switching of their functions (both should be capable of working as active or shadow units). The two sub-systems should also be prepared for implementing the monitoring functions that will define the success of the reconfiguration. Advantages

(i.) Monitoring the RF environment to: •

• •

Provide cancellation or filtering of signals likely to upset reception of the wanted signal (nearby high power blockers), Determine which air interfaces are available to the user, Providing “over the air” downloads whilst the main receiver is providing the link for the user.

(ii.) Being set up as a receiver prior to “mode switching” so that the mode switch is “Transparent” to the user.

(iii.) Any failure in the RF chain would not make the terminal useless. The other chain could always act as a reserve unit for those critical cases.

Disadvantages

(i.) The cost and complexity could be prohibitive. The power consumption would be high, imposing critical demands on the batteries.

3.5.1.3 Hybrid Architecture This alternative resolves some of the complexity overhead of having two RF chains. One part of the receiver and transmitter chain would be designed with the active/shadow philosophy (all the mixers, local oscillators and intermediate frequency stages), whilst other parts would be common (the low noise and power amplifiers). There could be two options for a switching strategy for these single element/dual element combinations. If the receiver were re-configured in the usual way, we would end up with an architecture whose transparency would be somewhere between that of the single chain, and that of a dual chain (discussed in 3.5.1.1 and 3.5.1.2 respectively). The power consumption, complexity and cost would also be in an intermediate position. The other option, which could certainly imply a different performance, would be based on a wideband permanent operation of the single or common blocks. The linearity of these common LNA and PA blocks would be critical. The low noise amplifier would have to be capable of simultaneously managing two different standards, which would be processed by different receiver units. The power amplifier would also have to do something analogous on transmission.



© 2002, WWRF 75

With this architecture, the terminal would be fully transparent, and the standards could be monitored in order to define the target one. The power consumption, complexity and cost would not be as critical like in the active/shadow pair. An example of a possible active-shadow chain transceiver is shown in Figure 32. The Reconfiguration Management Module (RMM) manages the set-up of the active and shadow chains. This block diagram accommodates the following situations:

(i.) Switching between antennas to optimise the antenna for the frequency band being transmitted/received.

(ii.) Back to back test of the receiver transmitter combination before it is switched live to air. The RMM would need to set up LO frequencies, and insert appropriate attenuators to manage this situation.

(iii.) Ability to “test” the ether for high power interfering signals, or new air interface standards that the user might prefer to use. This facility could utilise the antenna in current use by the active chain, or it could use the second band antenna.

3.5.1.4 Conclusion Not regarding specific ways of the implementation (e.g. active and shadow transmit and receive chains, or hybrid architectures), it is obvious that for many applications (e.g. inter-standard handover without a common managing network) the receive and transmit functionality must be doubled. It is one of the important research issue to come up with pragmatic and realizable results which achieve this doubling. Research Issue

• Pragmatic realization of doubling the transmit and receive functionality.



© 2002, WWRF 76

Active RX

Dup

lexe

r

Active TX

Shadow RX

TX-R

X fr

eque

ncy

LocalOscillator

Shadow TX

RX

Filt

er P

aram

.s

DSP

TX F

ilter

Par

am.s

TEST

TEST

ACTIVE

ACTIVE

ACTIVERX

ACTIVETX

RMM

LOO

PBA

CK

SENSE

Figure 32: Possible Block Diagram of an Active Shadow Chain Transceiver



© 2002, WWRF 77

3.5.2 Separate Antennas for Individual System The antenna performance is generally optimised for narrow band operation. Increased insertion loss for both transmitter as well as the receiver and reduced input filtering are likely to be the price one would have to pay for using single antenna for multiple systems. Electronic tuning of the antenna is a possibility [64] [65] [66]. Antenna duplexing is complicated for an SDR. This is because the modulation may be either FDD or TDD, so the duplexing must be capable of dealing with signals that are in the one instance not separated in time, or in the other, not separated in frequency. Potential duplexing solutions involving cancellation of the unwanted signals are possible. The required antennas are to be operational over perhaps at least three octaves bandwidth. At present, there are several broadband antennas available to cover these wide bandwidths [67], however, it is not clear if these antennas are suitable for SDR base stations and terminals. For terminals, the required antennas will be small and inexpensive. Although tri-band antennas [68] are available, they do not necessarily have the required bandwidth nor are they compatible with the given real estate within a terminal. There is a distinct deficiency in the type of broadband/re-configurable antennas needed for SDR applications and further research is required. Potential Approach The potential approach should be to consider both the terminal and the base station antennas separately as clearly the sizes of the antennas play a significant role in this area. Initially, a specification for the required antenna will be developed and possible antennas types will be identified and evaluated against these specifications. Several types of antennas are envisaged as possible candidates for the SDR applications:

• The conventional type and hybrid antennas [67], • Softboard and Semiconductor types [69], • Dielectric Resonator Antennas [70].

In the first approach conventional radiators will be appraised to see if they meet the required specifications. These antennas will then used with some emerging technology such as MEMS switches to derive some hybrid form of antennas, which offers a potential for meeting the SDR specification for both/either the terminals or the base stations. The second approach uses semi-conductor compatible material such as gallium arsenide (GaAs, εr approx 10) or softboard (εr approx 2) to print various antennas to achieve the required coverage and other specifications. The third approach uses dielectric resonators as the radiating element. The efficiency of these radiators is extremely high and the size is now much reduced as very high dielectric material is used. These antennas also provide the much-needed bandwidths for the present applications.



© 2002, WWRF 78

It is envisaged that a systematic research approach to the evaluation will lead to the required antennas, which will meet the SDR specification. Other novel types of radiating antennas also needs to be developed for the SDR applications. Research Issues

• • • • •

Electronic antenna tuning, Combined FDD, TDD duplexing, Research into hybrid antennas, Dielectric resonator, Other Novel antenna types.

3.6 Future Directions This section of the white paper will discuss possible research topics, which, it is hoped, will aid the evolution of SDR hardware design. MEMS technology is specifically examined, as it provides the possibility of innovative breakthroughs that established technologies are incapable of providing.

3.6.1 MEMS Technology and its Impact on Software Radio Front-end During the last few years, the sophisticated techniques associated with the manufacture of integrated circuits have begun to be adapted to manufacture mechanical systems on a microscopic scale. Such systems are referred to as MEMS or Micro Electro Mechanical Systems. The most obvious electrical application of such a system is the MEMS switch. A typical MEMS switch is shown in Figure 33 (see [61]). It is envisage that a MEMS switch can be used to electrically alter the line lengths from which a filter is comprised. Because such a switch operates by making physical contact and not by utilising a semiconductor device such as a PIN diode or a FET, little or no distortion will be introduced.



© 2002, WWRF 79

100microns

100microns

60microns

100microns

20m

icro

ns

RF out

RF in

Anchorpoint

Actuationelectrode

insulation

Open

Closed

DC controlvoltage in

DC controlvoltage out

Figure 33: Structure of a MEMS switch

Typical performance details for a MEMS switch are given in Table 1.

Performance Parameter Value DC actuation voltage 20V DC resistance (switch closed). 1.6Ω Insertion loss - switch closed (DC through 40GHz)

0.2dB

Isolation 50dB at low freq. dropping to 27dB at 40GHz

Switching speed 50µsec RF power throughput 1W (50Ω line)

Table 1: Typical MEMS switch Specification

There are a number of other MEMS that may be used to provide a filter tuning action, for example interdigitated capacitors where the fingers are capable of mechanical movement relative to one another. References [67] and [73] provide an excellent introduction to this exciting development. Other potential MEMS components include low loss, low power, mixers, and high Q resonators for low phase noise Oscillators.



© 2002, WWRF 80

3.6.2 Future Research Directions Up until this stage this section of the White Paper has concerned itself with establishing the technological obstacles that impede the development of the RF component of the SDR. Summarising these obstacles briefly we can say that they revolve around the issues of how we deal with image signals, and how we deal with high power interfering signals. The former problem essentially boils down to either development of flexible preselect filters or solving the problems associated with the zero IF receiver. The latter problem can be resolved by improving RF linearity or by the development of some form of interference cancellation. The following is a list of suggested research topics, which can help develop the “enabling technologies”, required to solve these problems. Note that all except one of the topics relates to issues already raise. The diplexerless radio has not been discussed as the issues it raises are on the borderline of the RF system. It is still an important hardware issues, and must be given due consideration.

3.6.2.1 Agile Linear Frequency Translation The aim of this research would be to build what essentially amounts to a linear mixer capable of operating over a wide frequency range.

3.6.2.2 Flexible Linearity Profile (FLP) Amplifiers The object of this work would be to extend previous work on linear LNAs. Linearity performance peaks can be adjusted to “follow” high power interfering signals where high linearity is most important.

3.6.2.3 Diplexerless Frequency-agile Radio Front-end A SDR transceiver will be operating in an environment, in which signals which may be either FDD or TDD. The object of this work would be to implement an appropriate high-isolation porting techniques for the physical coupling of the transmitter and receiver amplifiers to the antenna port.

3.6.2.4 Interference Cancellation or Filtering The object of this research would be to develop a means of detecting a nearby high power blocking signal. Means would then be devised to remove the influence of this signal from the receiver, either by cancellation or adaptive filtering.

3.6.2.5 Adaptive Preselect Filters This research would continue work, already mentioned, to electronically tuned preselect filters to eliminate image signals.



© 2002, WWRF 81

3.6.2.6 Frequency Agile Zero IF Receiver This work would look at techniques by which the front end of a Zero IF receiver can be made to operate successfully over a wide frequency range.

3.6.2.7 Novel Up-Conversion Techniques The transmit path is responsible for most of the power consumption of an RF-front-end. Since low power RF front-ends are a key issue for mobile terminals, new transmit architectures should be researched. One possible starting point would be a transmitter based on a 2-point modulation architecture. Such an architecture should be able to handle arbitrary signal modulation formats. Incorporated into such a transmitter could be an efficient power amplifier (PA) control (e.g. via controlling the supply voltage depending on the necessary output power).

3.6.2.8 Digital IF-Processing This work aims at designing a common power-efficient hardware platform for digital IF-processing. The work can include investigations on the advantages and disadvantages of a synchronous or asynchronous Analog/Digital interface.

3.6.3 Technological Roadmaps Receiver Architectures In this section of the White Paper we will summarise the technology necessary to make a SDR transceiver a reality. We will then try to place the development of these “enabling technologies” into some form of time frame. In order to try to obtain some feel for the rate at which the hardware for a SDR transceiver may evolve, we have produced Table 2. This table lists the technological development required to realise particular transceiver architecture.

Technology required

Receiver Technology

Qua

drat

ure

Loca

l os

cilla

tor

DC

off

set

com

pens

atio

n

Imag

e re

ject

m

ixin

g

Var

iabl

e Im

age

filte

ring

Hig

h lin

earit

y re

ceiv

er

ampl

ifier

s

Hig

h lin

earit

y m

ixer

s

Direct conversion

Low IF

Super-heterodyne

Table 2: Comparison of Technologies Required to Realise a SDR Receiver using Various Architectures



© 2002, WWRF 82

We will now try to assess what order of developmental time frame we are talking about for the development of these technologies. Quadrature Local Oscillator: The realisation of an accurate quadrature local oscillator is crucial to the development of direct conversion and low IF receivers. It is crucial to the development of a direct conversion receiver because all mobile radio systems use some form of complex modulation, and, by definition, the direct conversion receiver will only have one down conversion available. This downconversion therefore needs to be complex. In addition, some image cancellation is required as part of this receiver. 40dB image rejection is typically required for a direct conversion receiver. This requires the local oscillator to exhibit phase quadrature of better than 1 degree accuracy, and amplitude balance of better than 0.1dB. A low IF receiver also requires a complex signal to provide part of the image filtering that is required with this type of receiver. Thus it also relies on there being a local oscillator that has accurate phase quadrature and amplitude balance over a wide frequency range. Because the image of a low IF receiver is separated from wanted signal by twice the (albeit low) IF frequency, the image rejection requirements of a low IF architecture are significantly greater than the requirements of a direct conversion receiver (typically 70dB). Trying to set a time frame over which development of an accurate quadrature oscillator may take place is difficult. The problem has been solved to a limited extent today. Agilent Technologies have developed a chip that is claimed to generate phase quadrature local oscillator over a frequency range that would be very useful for mobile communications use (see [78]). This chip is a combined high pass low pass network, with servo amplitude control. It is used in Agilent instruments, and presumably gives their instruments a commercial advantage. For whatever reason, the chip doesn’t appear to be commercially available. Analog Devices have a Direct Conversion Quadrature Demodulator chip available (The AD8347 see [79]). This chip appears to offer quadrature phase shift with a typical accuracy of about 1° at a spot frequency (1.9GHz). Spot amplitude accuracy is quoted at typically 0.3dBm at the same frequency. Phase variation over the range of 800MHz to 2600MHz is also about 1°. Amplitude balance variation is not quoted. This is getting close to the performance that we require. It is difficult to predict where development will go from here but a 5 to 10 year period for the development of a suitable wide band quadrature oscillator seems a reasonable assumption. A quadrature oscillator is required for the superheterodyne architecture. This oscillator is only required to operate at a fixed single frequency. It will most likely be implemented in DSP and, as such, will not present a significant problem.



© 2002, WWRF 83

Offset Compensation: The only architecture that requires offset compensation is the direct conversion receiver. There are a number of techniques for compensating the DC offset of a direct conversion receiver. Some rely on measuring the DC offset during the idle period of a TDM [80], others rely on using data streams with zero DC component or placing a high pass filter of sufficiently low frequency in the data stream [81]. None of these techniques are directly applicable to a SDR receiver, as the type of modulation is not known a-priori. It is possible that the techniques could be refined for a SDR, and therefore development time of 5 to 10 years is assigned to this technology. Image Reject mixing: As discussed previously, the image rejection requirements of a direct conversion receiver are comparatively low, and can be achieved almost routinely provided the magnitude and phase balance of the local oscillator is reasonable. Image rejection requirements for a low IF receiver are more stringent. Filtering, rather than image reject mixing will be used for image signals when the receiver employs superheterodyne architecture6. Variable Image filtering: Developmental time for this technology has been assigned to 3 to 5 years. There are no obvious extreme performance requirements and the process should represent the adaptation of existing technology. Linearity: The need for high linearity mixers and amplifiers has been established in 3.4.2. Various methods of linearising LNAs and mixers have been developed. Extending the usefulness of these techniques to a wide operational bandwidth is a current research interest. A developmental time frame of 3 to 5 years has been placed on this technology. The time taken to develop these technologies is summarised in Table 3:

Technology Development time Quadrature local oscillator 5 to 10 years Offset compensation 5 to 10 years Image reject mixing Available now7 Variable image filtering 3 to 5 years Linearity 3 to 5 years

Table 3: Estimated Time Frame to Develop Technologies Required for a fully Functioning SDR Receiver

From this table, it can be deduced that the superheterodyne architecture is seen as being the most likely architecture to be developed as a fully functioning SDR receiver in the short term. As has been emphasised in other parts of this white paper, the Zero IF architecture is seen as providing a better long-term solution because of the possibility of achieving a single chip implementation and other issues canvassed in this paper.

6 It could be used, but you would end up with the same problematic quadrature oscillator requirements that exist with the direct conversion architecture. 7 If the performance of the quadrature LO is satisfactory.



© 2002, WWRF 84

44 SSDDRR BBaasseebbaanndd RReeffeerreennccee MMooddeellss aanndd AArrcchhiitteeccttuurree The baseband architecture of reconfigurable SDR equipment has to be designed so that a total and also a partial reconfiguration of the baseband is possible. In case of switching from one radio access technology to another, total reconfiguration is required, which usually requires significant changes in the functionality, behaviour, and interfaces of the baseband modules. Partial reconfiguration is performed if only parameters of one or several baseband modules have to be changed without changing the air interface standard. Certain modules, for example, may be reconfigured in order to improve QoS whilst remaining on the current operating standard. If the baseband should be reconfigured without interrupting the ongoing service, a second so-called ‘shadow transceiver’ has to be provided in the baseband architecture. However, since cost and complexity of the required hardware platform is significantly increased, alternative but less flexible solutions have to be investigated. Duplication of baseband modules, for example, can be avoided by designing generalized modules that can switch their operating parameter during runtime. This sub-optimal, but technically feasible approach requires a reconfiguration table, listing all modules and their parameter requirements for all standards supported by the SDR. The baseband architecture of reconfigurable SDR equipment has to be designed so that it can execute today’s and tomorrow’s wireless access schemes on a future hardware platform and can be integrated into an overall system architecture that allows to reconfigure the platform by executing a program. These contrary design goals suggest defining two reference baseband architecture models, one applied for emphasizing software- and the other for hardware-related issues. Note that the two generic architectures complement each other and should not be contradictory.

4.1 Algorithms

4.1.1 Harmonization and Classification of Transceiver Algorithms Different air interfaces use different algorithms for base-band processing e.g., equalization algorithms, filtering algorithms, the RAKE-receiver algorithm, and DFT-based algorithms. A harmonization based on a generalization of these algorithms might lead to a set of very few common basic algorithms for which a common software platform as well as a common hardware platform can be designed. The same principle applies to synchronization. Synchronization is crucial for every receiver, however, it depends on the air interface. A harmonization of the synchronization algorithms should lead to a “synchronization engine” that is applicable to virtually all known air interfaces. Research Issues

• •

Classification of receiver and transmitter algorithms, Design of a generic synchronization engine.



© 2002, WWRF 85

4.1.2 Interworking between RF/IF Part and Baseband Part A tight interworking between RF-part and baseband processing part of a terminal promises to enable an adaptive calibration as well as compensation of mismatches, offsets, non-linearities etc.of the analog RF/IF part at run-time by means of digital signal processing. The respective research issues have been named in Chapter 3.

4.2 Software Architecture of Reconfigurable Baseband A generic software architecture for a reconfigurable baseband has been defined in the IST project TRUST [23]. This architecture can be well-embedded into an overall system and network architecture that can support and exploit software-defined radio (SDR) equipment. It comprises a baseband management module that controls the configuration of the baseband. In the following the key features and components of the proposed software architecture of the baseband are briefly described. The TRUST baseband sub-system is adaptive because of its ability to reconfigure itself. The software architecture of the reconfigurable baseband is based on object-oriented methodology. Each module of the baseband transceiver chain is reconfigurable by instantiation of an appropriate class and/or re-initialisation with new parameters. It is assumed that the software (class) of each module (modulator, FEC decoder…) is available (downloaded and stored in the baseband library), error free, and compatible.



© 2002, WWRF 86

Shadow Chain - Receive BasebandR

e-Configuration B

aseband M

anagement M

oduleActive Chain - Receive Baseband

Re-C

onfiguration Switch

SW Library

Shadow Chain – Transmit Baseband

Active Chain - Transmit Baseband

RF Unit

Terminal Profile

Resource Management

Module

Terminal Capability

SW Download

Module

Figure 34: Generic Software Architecture of Reconfigurable Baseband

In order to re-configure the baseband without interrupting the ongoing services, the baseband architecture must support dynamic creation and binding of new or modified modules. As a result, instantiation of downloaded classes must be administered through dynamic binding, whereby the required functionality of a given class is only made available at run-time, whilst the structure of the downloaded class is known a priori.

Figure 34 illustrates the reconfigurable baseband architecture, which consists of the following components:

• Re-Configurable Baseband Management Module (R-BBMM): overall controller of the R-BB sub-system. It is responsible for negotiating re-configuration, creating active and shadow transceiver chains, and controlling the run-time behaviour of each module,

• Active Baseband Transceiver Chain: currently operating baseband chain. Each chain consists of several modules, and each module is referred to as a Baseband Processing Cell (BPC),

• Shadow Baseband Transceiver Chain: post re-configuration baseband transceiver chain. It contains references of BPCs that are kept unchanged from the active chain, and one/more new BPCs. The shadow chain does not interfere with the active and constituent processes are kept mutually independent,

• Baseband Software Library: contains the baseband active and shadow configuration maps, corresponding to the active and shadow transceiver chains respectively. A configuration map is a list of baseband modules (type, functionality, algorithmic identity…), their associated interface definitions and inter-connections. The library will also store all the baseband module classes that are currently in use and those that were used previously,



© 2002, WWRF 87

• A ‘read-only’ default configuration map together with all the associated module classes

and parameter lists. This would allow the baseband to confidently re-configure to a known, working standard, which is compliant with the user profile,

• A complete copy of the previously working baseband configuration. This should include the configuration map, associated baseband classes, parameter lists, operating standard, host network registrations… Such a store would allow the terminal to return back to a fully working baseband configuration, without requiring a power off reset,

• Re-Configuration Switch: typical ON/OFF switch. It implements the ON/OFF signal from the R-BBMM, in order to switch the shadow chain ON and the active chain OFF.

The configuration map defines the baseband chain, in terms of functionality of consituent modules and their interfaces and inter-connections. The R-BBMM uses this map to create and then connect the different BPC objects. In order to re-configure the baseband, the R-BBMM creates a shadow baseband chain in compliance with the agreed configuration map for re-configuration.

4.3 Hardware Architecture of Reconfigurable Baseband wideband reconfigurable / programmable baseband radio frontend

reconfigurable logic ( FPGAs, PLDs, DSPs embedded switchable cores, …) controller Note: other interconnect architectures are feasible.

RF/IF

BB modules

BB1

BB modules

BB modules

BB1

BB modules

BB control modules

IF/BB

ADC/ DAC

fixed network

memory I/O

Figure 35: Generic Hardware Architecture of Reconfigurable Baseband



© 2002, WWRF 88

Figure 35 illustrates a generic baseband hardware architecture for a software-defined radio which can be applied to the design of user terminals and basestations for a mobile communication systems beyond 3G. It is well-suited for the execution of a variety of current and future wireless access schemes and provides the flexibility to reconfigure the physical layer transmission scheme under software control. This architecture covers at least some of the competitive hardware platform currently available on the market; it can also be viewed as a generic architecture for a reconfigurable baseband that is implementable as a System-on-Chip (SoC), containing several general purpose and digital signal processor cores, memories, and dedicated as well as reconfigurable hardware blocks. The radio signal received at the antenna is first processed with a wideband radio frontend before it is fed to the digital baseband (BB) signal-processing unit 8. The signal is down-converted with an analog mixer to an intermediate frequency (IF) band, sampled with a wide-band, high resolution A/D converter, and fed to the digital radio-frontend. This digital, re-configurable IF/BB module performs channelization. It extracts from the received signal a single or several user channels for further processing at the baseband and thus implements the signal-processing tasks “downconversion”, and “filtering”. Depending on the required radio access scheme and selected user channels, different channel frequency characteristics and parameters have to be implemented. These numerically intensive functions have to be executed on a dedicated programmable device with today’s available technology; however, we expect that in some years from now these functions can also be implemented on a DSP. Most of the baseband signal-processing functions of the various wireless access schemes are executed as independent BB modules either on reconfigurable logic or digital signal processors (DSPs). The required signal processing modules and their configuration parameters are given by the selected wireless access scheme. We have to determine these module for each candidate scheme, identify the similarities in the different functions, and try to use common reconfigurable or switchable logic devices or DSP code to implement them. This is a challenging task considering the widely differing nature of the different signal processing functions of the above radio access schemes as well as the wide range of involved radio interfaces. At the same time it would be preferable to make the software modules independent of the hardware platform. This would allow upgrading of hardware platform without changing software modules. Something like a resident compiler or java interpretor is an option. Another requirement would be to minimize the reconfiguration data to be downloaded while constraining the total memory requirement.

8 If the advanced multi-input/multi-output (MIMO) transceiver concepts should be considered, several parallel radio fontends are required.



© 2002, WWRF 89

This hardware platform should be partly reconfigurable on the run while some part is executing some functions. An ideal solution would be a combination of independent hardware modules and hardware independent software modules linked together by process control module. All signal processing modules should have standard interfaces so that they can be plugged in and out in any order in a system implementation. This would also allow switching off of some hardware modules to save power in good operating environments. Another issue to be considered would be a selection of the system clock. The least common multiple of the basic clocks of the chosen systems is unrealistically large for practical implementation. This would necessitate a new approach for timing and rate/frequency control. It would be advisable to have a single system clock and clock generation schemes approximating the basic clocks of different systems on the average. Other solutions incorporating multiple clock/PLL based schemes would be bulky. The BB control modules are implemented as independent processes on a real-time operating system (RTOS) on an embedded controller. One process is responsible for selecting the required BB modules according to the selected standard, configuring the parameters of the modules, and determining their execution order. The executable FPGA macros and DSP code implementing the BB modules are stored in memory devices. They can be downloaded to the memory over the fixed network or over-the-air (OTA) before the baseband transceiver operation is started. The reconfigurable logic devices, DSPs, embedded controller, memory, and external I/O devices communicate with each other via a local system bus, which allows the parallel implementation of the baseband signal processing functions for several radio transceivers. Since the hardware architecture shown in Figure 35 is a generic one, more advanced mechanisms other than conventional bus architectures can also be applied to interconnect the various hardware blocks or cores. Another requirement of the baseband processing is some standard way of defining its capabilities like processing power, RAM/ ROM memory size, RF capability, ADC/DAC resolution etc. A protocol to communicate this information to the higher protocol layers and in turn to network is required. This will allow network to assess the terminal capability before entertaining any upgrading in terminal capabilities. In the next Sections, we identify the BB modules of several wireless access schemes by briefly summarizing their baseband functions. As potential candidate systems, we selected the cellular systems GSM and W-CDMA, and the WLANs 802.11a and 802.11b.



© 2002, WWRF 90

4.3.1 Generic Baseband Receiver Chain A generic baseband processing block diagram of the receiver chain for the four identified systems are given in Figure 32. IF processing is not included in the block diagram. In conventional implementations, this is done in the RF front end. In the case of software radio, it is likely that these functions would also form part of the baseband processing. The included functions would be channelisation and decimation. These functions would easily fit to a parameterised block with parameters: center frequency, channel bandwidth. Even though the blocks are shown in a sequential way, the actual implementations may be parallel or may even combine some of them. The idea here is to capture the critical blocks involved in the signal processing. Even though attempt is made to identify critical parameters of some of the blocks in the attached table, it is not complete. The complexity of the systems and the different modes / data rates of different systems would not allow a complete parameterised representation of the systems. Some of the common data rates and their critical parameters are shown in the table. In general, it can be said that the different systems are having different types of framing and encoding requirements. Hence, identifying common building blocks that can be parameterised to meet their requirements is a really challenging task. The channelisation block is followed by an optional filtering block. In the candidate systems, only WCDMA specifies a filter at this stage. This is followed by essentially two parallel blocks: Channel estimation and synchronisation. The performance of the receiver is largely decided in these blocks. The channel estimation is mainly for estimating the critical multipath profile and as such would be closely linked to equalisation / Rake combining. Hence their implementation would be highly dependent on the system characteristics. The synchronisation function is expected to estimate the frame, code symbol timings as well as frequency offset and do the necessary correction. This would be based on the parameters like frame size, no of symbols / frame, no of slots/ frame and the synchronisation information in the slot. This would estimate the correction function and again is dependent on the individual systems. The synchronised information is sent for despreading / Rake combining in WCDMA and 802.11b Systems and FFT processing in 802.11a. These functions are completely different and these blocks are missing in GSM. This is followed by equalisation in non-spread spectrum systems. Finally demodulation, de-framing, decoding and de-scrambling of the received data is carried out. The order of these functions is dependent on the individual systems and the particular service chosen. It would be possible to develop common blocks for these functions with the parameters and frame format for a particular service downloaded for activating that service. Details of some of the services of candidate systems are given in Table 4.



© 2002, WWRF 91

4.3.2 Transmitter Baseband Receiver Chain A generic baseband processing block diagram of the transmitter chain for the four identified systems are given in Figure 37. The user data is fed to the framing block. The encryption of the data is carried out in higher layer protocols or is optional in WCDMA and 802.11a and 802.11b. Only in GSM, the encryption is carried out in the baseband layer 1 processing. The framing information is different for different services in same system and hence is difficult to parameterize. The details of the framing for different services have to be stored separately and fed to the framing module. This is followed by coding, interleaving and framing blocks. (In 802.11a scrambling is done before channel coding). Here also, different services use different formats and would have to be stored separately. A common block for all the systems is possible with sufficient memory depth. This is followed by a precoder in GSM and 802.11b systems. These blocks are followed by modulation, spreading, scrambling like functions and finally the spectrum shaping filters. Some of these blocks may not be present in all the systems or the order may different. These call for a flexible architecture, which can place the processing modules in any order, as defined in the standard. Table 2 lists some of the important parameters of the candidate systems.



© 2002, WWRF 92

SYNCHRONIZATION DESPREADING/RAKE

R1p1 = Type of Filter

R2p1 = Type of SyncR2p2 = Frame sizeR2p3 = No. of slots

per frameR2p4 = Slot structure

R4p1 = Yes or NoR4p2 = Spreading Factor

R4p3 = Type of Speading Code

R1 R2 R4R5

Baseband Receiver Module

InputFILTER

FFT& CYCLIC

PREFIXREMOVAL

R5p1 = Yes or No

R6R7

DEMODULATION

R8R10

OutputData

R7p1 = Type ofEqualizer

R7p2 = No. of tapsR8p1 = Type of

Modulation

EQUALIZERDECODING &DEINTERLEAVER

PARALLELTO SERIAL

R6p1 = Yes or NoR6p2 = No. ofsubcarriers

R4p3 = No. of pilotsubcarriers

CHANNELESTIMATION

R3R3p1 = Type of system

R2p2 = Frame sizeR2p3 = No. of slots per

frameR2p4 = Slot structure

W-CDMAIEEE 802.11b

IEEE 802.11a

GSM

R9

T9p1 = No. of pre, mid &post-amble symbolsT9p2 = Slot structure

T9p3 = Frame sizeT9p4 = No. of slots

T9p5 = Demultiplexingfactor

DEFRAMING

T10p1 = Interleaver sizeT10p2 = Rate matching attribute

T10p3 = Type of codingT10p4 = PolynomialT10p5 = Code rate

T10p6 = Size of CRC

Figure 36: Baseband Receiver Module



© 2002, WWRF 93

Table 4: Parameter Table for Receiver Module Filtering

(R1) Synchronization

(R2)

Channel Estimation (R3)

Type of filter (P1)

Type of synchronization

(P1)

Frame size (P2)

No. of slots per

frame (P3)

Slot structure (P4)

Type of System

(P1) Frame size (P2)

No. of slots per frame

(P3)

Slot structure (P4)

−

Symbol-Timing Frequency-Offset

Frame Timing

Full-rate speech 8 3,57,28,57,3 GSM Full-rate speech 8 3,57,28,57,3

− Half-rate speech 8 3,57,28,57,3 GSM Half-rate speech 8 3,57,28,57,3

GSM

− 9,6kbps full rate data 8 3,57,28,57,3 GSM 9,6kbps full rate

data 8 3,57,28,57,3

Root RC with rolloff = 0.22

Code-Timing, Frame Timing,

Frequency-Offset

420 15 6,4,22,8 W-CDMA 420 15 6,4,22,8

Root RC with rolloff = 0.22 2100 15 28,12,112,8 W-CDMA 2100 15 28,12,112,8


W-CDMA


Frequency-Offset, Frame Timing 48 1 10,1,2,48 802.11a 48 1 10,1,2,48

48 1 10,1,2,48 802.11a 48 1 10,1,2,48 96 1 10,1,2,96 802.11a 96 1 10,1,2,96 96 1 10,1,2,96 802.11a 96 1 10,1,2,96 192 1 10,1,2,192 802.11a 192 1 10,1,2,192 192 1 10,1,2,192 802.11a 192 1 10,1,2,192 288 1 10,1,2,288 802.11a 288 1 10,1,2,288

IEEE 802.11a

288 1 10,1,2,288 802.11a 288 1 10,1,2,288

Code-Timing, Frame Timing

Frequency-Offset variable 1 192, variable 802.11b variable 1 192, variable IEEE

802.11b

variable 1 192, variable 802.11b variable 1 192, variable



© 2002, WWRF 94

variable 1 192, variable 802.11b variable 1 192, variable variable 1 192, variable 802.11b variable 1 192, variable



© 2002, WWRF 95

Table 4: Parameter Table for Receiver Module (cont.)

Despreading/RAKE (R4)

FFT & Cyclic Prefix

Removal (R5)

Parallel to Serial (R6)

Equalization (R7)

Demodulation (R8)

Required? (P1)

Type of spreading code

(P2)

Spreading factor (P3)

Required? (P1)

Required? (P1)

No. of data subcarriers

(P2)

No. of pilot subcarriers

(P3)

Type of equalizer

(P1)

No. of Taps (P2)

Type of modulation (P1)

N − − N N − − MLSE 5 GMSKN − − N N − − MLSE 5 GMSKGSM N − − N N − − MLSE 5 GMSKY OVSF 128 N N − − − − QPSK Y OVSF 32 N N − − − − QPSK Y OVSF 16 N N − − − − QPSK

W-CDMA

Y OVSF 8 N N − − − − QPSK N − − Y Y 48 4 Linear 1 BPSKN − − Y Y 48 4 Linear 1 BPSKN − − Y Y 48 4 Linear 1 QPSKN − − Y Y 48 4 Linear 1 QPSKN − − Y Y 48 4 Linear 1 16QAMN − − Y Y 48 4 Linear 1 16QAMN − − Y Y 48 4 Linear 1 64QAM

IEEE 802.11a

N − − Y Y 48 4 Linear 1 64QAMY Bakers 11 N N − − − − DBPSK Y Bakers 11 N N − − − − DQPSK Y CCK 8 N N − − − − BPSK

IEEE 802.11b

Y CCK 8 N N − − − − QPSK



© 2002, WWRF 96

Table 4: Parameter Table for Receiver Module (cont.) Deframing

(R9) Decoding & Deinterleaver

(R10)

No. of pre-, mid- &

post-amble symbols

(P1)

Slot structure (P2)

Frame size & deinterleaver

(P3)

No. of slots per

frame (P4)

Demutliplexing (P5)

Interleaver size (P1)

Rate matching attribute

(P2)

Type of coding (P3)

Polynomial (P4)

Code rate (P5)

Size of CRC & tail bits

(P6)

3,28,3 3,57,28,57,3 Full-rate speech, N 8 Y, 8 456 − C, − 88 3133 1/2, − 3,4

0,0

3,28,3 3,57,28,57,3 Half-rate speech, N 8 Y, 4 228 − C, − 888 137123155 1/2, − 3,6

0,0 GSM

3,28,3 3,57,28,57,3 9,6kbps full rate data, N 8 Y, 19 456 − C 88 3133 1/2 0,4

0,4,8 6,4,22,8 420, Y 15 Y,4 686 256 C 888 711663577 1/3 160,12,8 28,12,112,8 2100, Y 15 Y,4 4014 256 T 88 1413,1 1/3 16

0,16,16 56,16,232,16 4320, Y 15 Y,4 8464 256 T 88 1413,1 1/3 16

W-CDM

A 0,16,16 120,16,488,16 9120, Y 15 Y,4 9049 256 T 88 1413,1 1/3 16

(10,1,2),0,0 10,1,2,48 48, N 1 N 48 − C 88 171133 1/2 − (10,1,2),0,0 10,1,2,48 48, N 1 N 48 − C 88 171133 3/4 − (10,1,2),0,0 10,1,2,96 96, N 1 N 96 − C 88 171133 1/2 − (10,1,2),0,0 10,1,2,96 96, N 1 N 96 − C 88 171133 3/4 − (10,1,2),0,0 10,1,2,192 192, N 1 N 192 − C 88 171133 1/2 − (10,1,2),0,0 10,1,2,192 192, N 1 N 192 − C 88 171133 3/4 − (10,1,2),0,0 10,1,2,288 288, N 1 N 288 − C 88 171133 2/3 −

IEEE 802.1

1a

(10,1,2),0,0 10,1,2,288 288, N 1 N 288 − C 88 171133 3/4 − 192,0,0 192, variable Variable, N 1 N − − − − − − 192,0,0 192, variable Variable, N 1 N − − − − − − 192,0,0 192, variable Variable, N 1 N − − − − − −

IEEE 802.1

1b 192,0,0 192, variable Variable, N 1 N − − − − − −



© 2002, WWRF 97

Data DATABUFFER PRECODER MAPPING &

MODULATION

SPREADINGFILTER SERIAL TOPARALLEL

CODING &INTERLEAVER FRAME

T1p1 = Type of channelT1p3 = No. of data block

T1p3 = No. of bits perblock

T2p1 = CRC polynomialT2p2 = Size of CRC & tail

bitsT2p3 = Type of coding

T2p4 = Code polynomialT2p5 = Code rate

T2p6 = Rate matchingT2p7 = Interleaving size

T3p1 = Multiplexing &interleaver depth

T3p2 = Interleaver sizeT3p3 = Frame sizeT3p4 = No. of slots

T3p5 = No. of pre, mid &post-amble symbolsT3p6 = Slot structure

T4p1 = Yes or No

T1 T2 T3 T4 T5

T5p1 = Type ofModulation

T6

SCRAMBLING

T8 T7

IFFT& CYCLIC

PREFIXINSERTION

T9T10

Outputto IF

T10p1 = Type of Filter T9p1 = Yes or NoT6p1 = Type ofSpeading Code

T6p2 = SpreadingFactor

T8p1 = Yes or NoT8p2 = No. of data

subcarriersT8p3 = No. of pilot

subcarriers

T7p1 = Yes or No

Baseband Transmitter Module

Figure 37: Baseband Transmitter Module



© 2002, WWRF 98

Table 5: Parameter Table for Transmitter Module Data Buffer (T1) Coding & Interleaver (T2) Framing (T3)

Type of channel

(P1)

No. of data block (P2)

No. of bits per block (P3)

CRC polynomial

(P1)

Size of CRC and tail bits

(P2)

Type of

coding (P3)

Polynomial (P4)

Code rate (P5)

Rate matching attribute

(P6)


Mutliplexing and

interleaver depth (P1)


Frame size (P3)

Full-rate speech 2 182

78 813 3,4 0,0 C, − 88 3133 1/2, − − 456 Y, 8 − Full-rate

speech Half-rate speech 2 95

17 813 3,6 0,0 C, − 888 137123155 1/2, − − 228 Y, 4 − Half-rate

speech GSM

9,6kbps full rate data 1 240 813 0,4 C 88 3133 1/2 − 456 Y, 19 − 9,6kbps full

rate data

W-CDMA 12.2kbps speech 1 244 8210041 16 C 888 711663577 1/3 256 686 Y, 4 420 420

64kbps data 1 1280 8210041 16 T 88 1413,1 1/3 256 4014 Y, 4 2100 2100

144kbps data 1 2880 8210041 16 T 88 1413,1 1/3 256 8464 Y, 4 4320 4320

384kbps data 1 3840 8210041 16 T 88 1413,1 1/3 256 9049 Y, 4 9120 9120

6Mbps data 1 24 − − C 88 171133 1/2 − 48 N − 48 9Mbps data 1 36 − − C 88 171133 3/4 − 48 N − 48

12Mbps data 1 48 − − C 88 171133 1/2 − 96 N − 96 18Mbps data 1 72 − − C 88 171133 3/4 − 96 N − 96 24Mbps data 1 96 − − C 88 171133 1/2 − 192 N − 192 36Mbps data 1 144 − − C 88 171133 3/4 − 192 N − 192 48Mbps data 1 192 − − C 88 171133 2/3 − 288 N − 288

IEEE 802.11a

54Mbps data 1 216 − − C 88 171133 3/4 − 288 N − 288 1Mbps data 1 Variable − − − − − − − N − variable 2Mbps data 1 Variable − − − − − − − N − variable

5.5Mbps data 1 Variable − − − − − − − N − variable IEEE

802.11b 11Mbps data 1 Variable − − − − − − − N − variable



© 2002, WWRF 99

Table 5: Parameter Table for Transmitter Module (cont.)

Framing (T3)

Precoder (T4)

Modulation (T5)

Spreading (T6)

Scrambling (T7)

Serial To Parallel (T8)

IFFT & Cyclic Prefix

Insertion (T9)

Filtering (T10)

No. of slots per

frame (P4)

No. of pre-, mid- &

post-amble symbols

(P5)

Slot structure

(P6)

Required?

(P1)

Type of modulatio

n (P1)

Type of

code (P1)

Spreading factor (P2)

Required? (P1) Required? (P1)

No. of data

subcarrier (P2)

No. of pilot subcarrier

(P3)

Required? (P1) Type of filter (P1)

8 3,28,3 3,57,28,57,3 Y GMSK − − − N − − − GMSK pulse with BT = 0.3

8 3,28,3 3,57,28,57,3 Y GMSK − − − N − − − GMSK pulse with BT = 0.3 GSM

8 3,28,3 3,57,28,57,3 Y GMSK − − − N − − − GMSK pulse with BT = 0.3

15 0,4,8 6,4,22,8 N QPSK OVSF 128 Y N − − − Root RC with rolloff = 0.22

15 0,12,8 28,12,112,8 N QPSK OVSF 32 Y N − − − Root RC with rolloff = 0.22

15 0,16,16 56,16,232,16 N QPSK OVSF 16 Y N − − − Root RC with rolloff

= 0.22

W-CDMA

15 0,16,16 120,16,488,16 N QPSK OVSF 8 Y N − − − Root RC with rolloff

= 0.22 1 (10,1,2),0,0 10,1,2,48 N BPSK − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,48 N BPSK − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,96 N QPSK − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,96 N QPSK − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,192 N 16QAM − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,192 N 16QAM − − Y (before encoding) Y 48 4 Y Mask to be met 1 (10,1,2),0,0 10,1,2,288 N 64QAM − − Y (before encoding) Y 48 4 Y Mask to be met

IEEE 802.11a

1 (10,1,2),0,0 10,1,2,288 N 64QAM − − Y (before encoding) Y 48 4 Y Mask to be met

1 192,0,0 192, variable Y DBPSK Bakers 11 − N − − − Mask to be met

1 192,0,0 192, variable Y DQPSK Bakers 11 − N − − − Mask to be met

IEEE 802.11b

1 192,0,0 192, variable Y CCK CCK 8 − N − − − Mask to be met



© 2002, WWRF 100

1 192,0,0 192, variable Y CCK CCK 8 − N − − − Mask to be met



© 2002, WWRF 101

4.3.3 Other Baseband Transceivers The baseband architecture of reconfigurable SDR equipment has to be designed so that not only the transceivers of the cellular systems like GSM and W-CDMA and 802.11 based WLANs can be efficiently implemented but it should also allow the integration of technology to be used in today’s and tomorrow’s personal area networks (PANs) as well as satellite and broadcast systems. Since these systems require some additional functional baseband modules not shown in the generic transmitter and receiver chain given in the last two sections, we will now briefly discuss the required transmit and receive modules for the PAN “Bluetooth” and the digital broadcast systems DAB and DVB.

4.3.3.1 Personal Area Network “Bluetooth” rate (1/3,2/3,1)enablekeypacket type

UAP

CRCgenerator encryption

whiteningfilter

FECencoding

payload

UAP

HECgenerator

whiteningfilter

FEC1/3

encoding

header

UAP

HECchecking

de-whitening

filter

FEC1/3

decoding

HEC_OK

Acces Code

AccessCode

Correlator

Sync word /access code

header

rate (1/3,2/3,1)enablekeyUAP

CRCchecking decryption

de-whitening

filter

FECdecoding

payload

FEC

CRC_OK

RADIO

FRAME

RADIO

FRAME

packet type

DEM

UX

MU

X

DEMUX

RX SCObuffer

RX ACLbuffer

link controller

MUX

TX ACLBuffer

TX SCOBuffer

TX SCOBuffer

TX SCO buffer

TX ACLBuffer

TX ACLBuffer

TX ACLBuffer

TX ACLBuffer

TX ACLBuffer

TX ACL buffer

controls

transmitradio frameat f=f(n)

receiveradio frameat f=f(n)

TXheaderregister

RXheaderregister

linkmanagerprotocol

WHI_init

WHI_init

WHI_init

WHI_init

hoppingfrequencyselection

f=f(n)

X,Y,A

US

UA

UI

UI

UA

US

linkmamager

trigger

Figure 38: Baseband Transmitter and Receive Chain of Bluetooth

Bluetooth has been accepted by the IEEE 802.15 working group as standard for enabling wireless ad-hoc connectivity between portable and/or fixed electronic consumer products. It can manage within a small local area up to three synchronous connection-oriented (SCO) links mainly for speech transmission at a rate of 64 kbit/s, and up to seven asynchronous connectionless (ACL) links supporting symmetric or asymmetric data transfers at a maximum rate of 433.9 and 723.2 kbit/s, respectively.



© 2002, WWRF 102

The radio subsystem is operated like 802.11b in the globally available unlicensed ISM frequency band at 2.4 GHz, covers distances of up to 10 meters with a transmission power of less than 1 mW, and applies frequency hopping in conjunction with a TDMA scheme for transmitting data at a symbol rate of 1 Mbit/s over the air. Figure 38 shows the baseband modules required for the transmitter and receiver chain of Bluetooth. The upper part of the figure shows the transmitter chain. User synchronous (US), user asynchronous (UA), or user isochronous (UI) data, and link manager (LM) control information are sent via the corresponding logical channels to the transmit (TX) SCO or ACL buffers. The stored information represents the payload to be transmitted over the radio link. Before its transmission, the payload is protected by appending cyclic redundancy check (CRC) bits, ciphering, whitening, and optionally encoding with a rate 1/3 or 2/3 forward error correction (FEC) code. In parallel, a packet header is assembled by the link control (LC) module and stored in the TX header register. The header is also protected with header error check (HEC) bits, whitened, and encoded with a rate 1/3 FEC code. A radio frame is obtained by first concatenating the filtered and coded header and payload information, and then preceding the resulting bit string with the access code. Finally, the radio frame is forwarded to the analog radio frontend for its transmission at a frequency f(n). The value of f(n) is provided by the hopping-frequency-select module. The corresponding receiver chain is shown at the bottom. When the access code correlator detects the arrival of a radio frame at a frequency f(n), a trigger event starts the processing in the receiver chain. The header information is extracted from the received frame, decoded, dewhitened, and stored in the receive (RX) header register. When the HEC check is successful, the receiver can start decoding, dewhitening, deciphering the payload information, and store the packet in the RX SCO or ACL buffer depending on the packet type received. From the RX buffers, the payload is carried via the logical channels US, UA, or UI to the synchronous or asynchronous I/O port. The link control module configures, monitors, and controls the transmitter and receiver chain. In case of packet data transmission, the LC module also coordinates the retransmission of erroneously received data packets with an automatic repeat request (ARQ) scheme. It also carries out the connection setup protocol, authentication, and power management control.

4.3.3.2 Digital Audio Broadcast Systems Digital broadcast systems are investigated since the mid of the 80ties. Main intention for going digital is to make the receiving quality of broadcast services comparable to that of CD reproduction. It gives listeners interference-free reception of high quality sound and simultaneously can provide additional service information like dynamic text labels (e.g. program titles, names of artists) or switching to traffic reports or other services. In 1992, the EUREKA-147 DAB system (DAB=Digital Audio Broadcasting) was recommended world-wide by the Inter Union Technical Committee of the World Conference of Broadcasting Unions.



© 2002, WWRF 103

In December 1994, the system achieved a world wide standard given in ITU-R recommendations BS.1114 and BO.1130. for terrestrial and satellite sound broadcasting to vehicular, portable, and fixed receivers in the VHF/UHF range. It is an accepted European Standard (ETS 300401, March 1997), adopted by the European Telecommunications Standards Institute (ETSI). The DAB system is a sound and data broadcasting system with high spectrum- and power-efficiency. It uses digital audio compression techniques (MPEG 1 Audio Layer II and MPEG 2 Audio Layer II) and by this achieves a spectrum efficiency equivalent or higher than that of conventional FM radio. DAB has got four transmission modes with different parameters as shown in the table below:

Table 6: DAB Characteristics

The DAB transmitted data consists of number of audio signals sampled at a rate of 48 kHz with a 22-bit resolution. This audio signal is then compressed at rates ranging from 32 to 384 kbps, depending upon the desired signal quality. The resulting digital data is then divided into frames of 24 ms. DAB uses differential QPSK modulation for the sub-carriers. A null-symbol (or a silence period that is slightly greater than the OFDM symbol length) is used to indicate the start of the frame. A reference OFDM symbol is then sent to serve as a starting point for the differential decoding of the QPSK sub- carriers. Differential Modulation avoids the use of complicated phase-recovery schemes. DAB uses a rate ¼ convolutional code with a constraint length of 7 for error-correction. The coding rate can also be increased using puncturing. Interleaving is used to separate the coded bits in the frequency domain as much as possible, which avoids large error bursts in the case of deep fades affecting a group of sub-carriers. DAB is designed to be a single frequency network, in which the user receives same signals from several different transmitters. This greatly enhances spectral efficiency. Even though there is a delay in the reception of signals from different transmitters, this situation can be considered as a multi-path situation and can be easily handled by selecting the guard interval properly. Further, this can be considered a form of transmit diversity, that the DAB receiver can take advantage of.



© 2002, WWRF 104

4.3.3.3 Digital Video Broadcasting (DVB) Digital Video Broadcasting (DVB) is a standard for broadcasting Digital Television over satellites, cables and thorough terrestrial (wireless) transmission. DVB was standardized by the ETSI in 1997 [89]. The following are some important parameters of DVB. It has two modes of operation: the 2k mode with 1705 sub-carriers and the 8k modes with 6817 sub-carriers. ½ DVB uses QPSK, 16-QAM or 64-QAM sub-carrier modulation. ² DVB uses a Reed-Solomon outer code (204,188,t=8) and a inner convolutional code with generator polynomials (177,133 octal) combined with two layers of interleaving for error-control. Pilot Sub-carriers are used to obtain reference amplitudes and phases for coherent demodulation. Two-dimensional channel estimation is performed using the pilot sub-carriers, which aids in the reception of the OFDM signal.

4.4 Critical Components

4.4.1 Application Specific DSPs Application specific DSPs have far better performance than general purpose DSPs. In the future it will be more and more important to have a design methodology for application specific DSPs that enables short design cycles with moderate or low costs. Fundamental criterions for the design of application specific DSPs and thus for respective research are:

• Parameterizable Basic Architectures (PBA): Such basic architectures enable a fast adaptation of the baseband processing platform to a given application as early as in the design phase. One PBA must be found for each application class. Among those are the signal processing machine (SPM) and the control processing machine (CPM).

• Application Classes: To find a set of application classes it is necessary to investigate different systems, applications, and kernal algorithms. Fundamental characteristics are extracted leading to a classification.

• Parameterizable Instruction Set Architecture (ISA): This is the interface between programmers and hardware. Its main characteristic is to map the scalability of the hardware platform to the command complexity. The structure must remain unchanged independent from the underlying hardware architecure.

• Parameterizable Design and Programming Tools: These are tools like assemblers, debuggers, simulators etc. Similar to the ISA the tools must be easily adaptable to the different architecture alternatives. It is important that the usage of the tools remains unchanged independent from the underlying hardware architecture so that the programmer can develop a kind of familiarity.

Research Issues

• Design of a Parameterizable Basic Architecture for Application Specific DSPs, • Identification of Application Classes, • Design of a Parameterizable Instruction Set Architecture for Applicatoin Specific DSPs, • Design of Parameterizable Design and Programming Tools for Application Specific

DSPs.



© 2002, WWRF 105

4.4.2 DSP Operating Environment DSP is used for power efficiency but DSP software is not only power consuming algorithms. Reconfigurability is requested for DSP software as for other part of the baseband but should take into account the power efficiency.

Modem software can be split in three parts: • Waveform applications: algorithms, "pure" data processing, waveform sequencer, • Modem manager: control, supervision & management, • Platform services: services awaited for each platform but implementation dependent of

the environment.

Waveform Application

WF Sequencer

Wo

F Specific perations

Wo

F Specific perations WF Specific operations WF Specific

operations WF Specific operations

Standardised Interfaces

Test Manager


Error Manager

Modem Configuration

Modem Manager


SMAPIs SWAPIs

miRTOS

Platform Services

Figure 39: Modem Architecture



© 2002, WWRF 106

This approach allows to separate software modules which are only waveform dependent from those which are platform dependent. As a consequence, the software structure shows three types of interfaces:

• I-SWAPIs: Interface Services for Waveform Aplications provides communications channel able to establish links to/from digital transceiver, BB, … for control and data,

• miRTOS: modem interface for RTOS define a reduce set of RTOS services dedicated to DSP environment

• SMAPIs: Services for Management Application provide a dedicated set of services to manage the DSP software and/or the waveform

The previous figure is an illustration of the DSP operting environment approach. Advantages of this software design is to separate waveform from platform which is the major SDR difficulty and so to facilitate waveform management, update and configuration. Research Issues:

• Design and Standardisation of SWAPIs interface definition, • Design and Standardisation of miRTOS interface definition, • Design and Standardisation of SMAPIs interface definition,

4.5 Future Directions / Research Goals Primary goal of the Research in the field of SDR-BB concept is a generic hardware architecture which is able to cover as many current and upcoming wireless standards as possible. Baseband processing of the future multi-standard terminal or basestation will set very demanding requirements in computational performance and flexibility. The baseband hardware architecture should be designed and implemented with reasonable costs and energy efficiency. The current baseband hardware architectures typically consists of the following elements:

• General purpose processors GPPs, • Digital signal processors DSPs, • Special purpose hardware blocks (e.g. viterbi/turbo en-/decoder, (I)FFT, correlator,

correlation filter), • Busses and interconnections and, • Memories.

It is very probable, that the future baseband processing architectures will also consist of different kind of processing, storage and interconnection resources. As an addition to the list above, different kind of reconfigurable technologies will be used as processing elements. The reconfigurable technologies include configurable processing cores, FPGA-based approaches, embedded FPGA-based approaches and approaches based on arrays of processing elements. Still the special purpose hardware blocks will be needed also for the most demanding algorithms due to their superior silicon area and energy efficiency.



© 2002, WWRF 107

Research is needed to define what is an optimum hardware architecture for a given wireless standard set. A crucial issue of the resulting architecture is the resulting implementation complexity, i.e. power consumption, chip area of single modules and the overall resulting architecture. This may also include research on efficient HW-Structures of re-configurable logic modules. Design flow for implementation of SW-modules for constituent standards on the hardware architecture has also to be considered. In the recent and current research of re-configurability in wireless communications, such as EC funded projects TRUST [1] and CAST [2], the problems of base band re-configuration were identified and addressed. With reference to TRUST [1], the top down design approach was adopted and it was identified that for the base band re-configuration purposes an additional entity is needed. This entity is termed Management Module. In CAST [2] designers tried to address the problem of re-configurability using the top down and bottom up approaches. Therefore, two additional separate control components were designed for managing the process of the base band re-configuration. They are Re-configurable Resource Controller [2] and Physical Layer Controller [2]. These two entities can perform the following:

1. Cover the functionality of Management Module as in TRUST, 2. Allocate physical layer resources, 3. Optimise physical layer resources in terms of:

a. Power consumption, b. Speed of processing, and c. Memory usage,

4. Implement re-configuration, and 5. Accommodate different vendors.

In these projects the designed base band software can be characterised as “passive”. This is because of a need for additional management entities to download, manipulate and control software modules in the process of re-configuration. In order to eliminate the need for these additional management units and reduce the requirements for downloading and re-configuration control signalling, further research is needed in producing new methods for designing the base band processing software. These methods should enable the base band software to be “active”. This means that base band software should have the ability to change functionality, behaviour and performance without the need for additional management units. These actions should be completed by base band software itself. Hence, there will be reduced requirements for downloading and re-configuration control signalling. This approach should allow the design to be based upon known methods with clearly defined data flow, control mechanisms and interfaces. Procedures for re-configuration should also be simple and well defined.



© 2002, WWRF 108

In addition, the research should be conducted in identifying a specification for enhancing existing Real Time Operating Systems into Software Defined Radio based Real Time Operating Systems (SDRbRTOS). The SDRbRTOS will be needed to support “active” base band processing software and perform optimisation of re-configurable physical layer hardware. The overall research process therefore includes:

• Thorough analysis of existing wireless standards, • Tracking of trends in upcoming wireless standards, • Analysis and discussion of SDR-BB architecture proposals, • Research and analysis of state-of the art and future component technology, including

General Purpose-DSP, memory, re-configurable logic, semiconductor technology, • Comparison of cost with conventional approaches.



© 2002, WWRF 109

55 TThhee MMiissssiinngg LLiinnkk –– MMaannaaggeemmeenntt,, CCoonnttrrooll aanndd DDaattaa IInntteerrffaacceess ttoo ccoonnnneecctt SSDDRR PPllaattffoorrmm aanndd SSDDRR SSooffttwwaarree AArrcchhiitteeccttuurree

Basis for reconfigurable equipment are a powerful processing platform and a sensible and structured software architecture capable to implement the system requirements of the various RATs. Major task of this SW architecture is to integrate the different technologies and platforms and to use the programmability of these platforms to make systems reconfigurable. An architectural framework has to be developed which considers the inclusion of open programming interfaces for both the application layer but also for the lower system levels (i.e. an open programming interface for RAT implementation software). Assuming the availability of ’ideal’ SDR terminal, the definition of the interfaces necessary would be simplified. However, reality demands the modularisation of various functional blocks within the receiver and transmitter chains of SDR terminals, as can be seen in Figure 6 and Figure 17 as well as the sections on reconfigurable RF and BB parts. Reconfigurable terminals have, in contrast to non-reconfigurable terminals, the additional need to provide a basic connectivity, in particular if the terminal is not configured to an available RAT. This connectivity can be achieved by ‘polling’, or ‘scanning’ the radio environment and by reverting the terminal to the required configuration (n.b. this requires that a RAT is identified and the configuration software necessary is stored within the terminal [23]). Or, alternatively, by specification and establishment of a global connectivity channel, which could implement the required support infrastructure for reconfiguration of SDR terminals [97]. Independent which approach is being followed, both possibilities require additional features for reconfiguration control and management of the configurations and configurable radio modules/components. The following sections of this chapter describe the various interfaces of reconfigurable systems, starting with the separation of ‘commercial’ and ‘reconfiguration related’ traffic, followed by a look into the separation within and between the reconfigurable BB and RF parts of SDR terminals. The next step then will be the identification of the various control and management interfaces and finally an overview about possible software structures of SDR-radio implementations/configurations.

5.1 Information Exchange between Network and Terminal: Data and Reconfiguration Related Traffic

Once available, reconfigurable radios will provide implementations of mobile communication terminals that adhere to given RAT standards (e.g. UMTS, GPRS, H2, IEEE802.11, etc.). These (software defined) radio implementations will provide, as a minimum, all services and functions that a ‘hardwired’ terminal of the chosen standard would offer. However, to undertake reconfigurations during runtime, reconfigurable terminals do require the means to control and manage such reconfiguration processes.



© 2002, WWRF 110

Figure 40 depicts the principle of this, whereby the data and RAN signalling traffic is handled in the RAT implementation within the SDR terminal (using ‘d’ (data) interfaces), whilst the reconfiguration related traffic requires its own (virtual) transport mechanism (confined by ‘C’ (control) interfaces).

Antenna RF BB General

Proc.UserI/O

CONTROL

Ant RF BBProtocolStacks,

codecs, etc.

Applications,GUI

cc cc c

d d

User Control(reconf)

d d

ReconfigurationSW

SW-configuration to implement a RAT

Antenna RF BB General

Proc.UserI/O

CONTROL

Ant RF BBProtocolStacks,

codecs, etc.

Applications,GUI

cc cc c

d d

User Control(reconf)

d d

ReconfigurationSW

SW-configuration to implement a RAT

SDR platform

Figure 40 SDR Architecture – Data and Control Interfaces

5.2 SDR Platform Module Interfaces Figure 40 illustrates the separation between ‘d’ and ‘c’ interfaces, whereby the upper part of the SDR platform contains a number of functional building blocks. This includes: Antenna, RF, BB, general processing and User I/O sections which form the processing platform to execute the software configuration which implements the target RAT. Single building blocks within this structure are vertically separated by ‘d’ interfaces. The type of information passed through them depends on the actual location within the terminal structure. The ‘d’ interface between Antenna and RF module provides the various (analogue) RF waveforms, whilst between RF and BB modules the signals should be digitised already (depending on the scope and capability of the SDR RF platform).

5.3 Control and Management Interfaces A reconfigurable radio platform will provide the possibility to develop and apply potentially any (soft-coded) radio implementation. Programmability will enable the execution of system software elements or even complete SW-configurations, that may be obtained from a plethora of different sources, including: terminal manufacturer, network operator but also third party software providers. This openness however necessitates that reconfiguration and a required reconfiguration-control/management cannot be confined or delegated to the terminal only. This implies that, if users are given the possibility to install any available software on their radio terminals, which finally determines the air interface and radio emissions from the terminal, there must be the possibility to control and manage administrative access to the SDR platform and to reconfiguration procedures.



© 2002, WWRF 111

The ‘c’ interfaces in Figure 40 do provide the gateway between reconfiguration management and the modules of the implementation platform. Whilst some aspects of configuration management have been researched in TRUST [23] and a Reconfiguration Management Architecture (RMA) has been developed within Mobile VCE [25] [88], the Control and Management interfaces between the radio implementation platform and the Control/Management module are yet to be defined.

5.4 A Software Architecture for SDR Equipment SDR equipment will meet many demands; the possibility to implement any air-interface standard together with a suitable support infrastructure will provide the ability to roam vertically across access networks with one single handset. A change of functionality from one to another RAT is thereby ‘just’ a matter of changing one software configuration to another. The aforementioned architectures (RMA, TRUST functional architecture…) can support the re-arrangement and reconfiguration of the various software modules that implement one configuration. In such a structure, dedicated and open interfaces will allow the addition of new services without needing modifications of hardware modules. Apart from the apparent definition of the radio configuration, the software architecture has to provide reconfigurability: i.e. the SW architecture has to be able to modify a radio's configuration software (this is the reconfiguration from one RAT to another). So far, the main focus has been set on the configurability of BB and RF parts, however not only those parts require to be reconfigurable ’on-the fly’ but also the protocol stacks have to be sufficiently flexible. Since the protocols running at the base station (BS) and mobile station (MS) are basically symmetrically, reconfigurability is applicable to both network elements. Thereby an operator can build up an infrastructure that easily can be reconfigured to support a new, additional RAT standard when necessary. In a SW architecture for systems as complex as SDR equipment, reusability of code and software elements is a big concern. New air-interface standards typically rely on well-understood protocol stacks of predecessor systems and SW implementations of RF/BB modules can have similar elements. Cost intensive re-engineering of software can be avoided and software can be re-used if designed in a suitable way. Modular or object oriented software design entails several advantages [98]. Using well defined interfaces in the complete SW architecture, will facilitate the portability and re-use of the same module in different systems. Whilst it facilitates software-upgrades, since the respective modules can be exchanged individually.



© 2002, WWRF 112

5.4.1 Service Support in Reconfigurable Equipment To achieve real gain for users (and possible increase in revenues for operators and manufacturers), the issue of unanticipated and undesired formation/appearance of services must be investigated. A reconfigurable communication environment is required to support creation and provision of services; the entire system has to be designed to be as flexible as possible and therefore to provide transparent end-to-end reconfigurability and therein to integrate heterogeneous communication environments. This means that software architectures have to encompass the complete system ranging from networking, wireless transmission mechanisms to end-user services. A core abstraction, grouping the system in layers including hardware, network and middleware platform, as well as applications, is shown in Figure 41. Instead of strictly isolated layers, cross-layer collaboration will be essential to allow different degrees of adaptability and reconfigurability for the different parts of the system.

Applications

Middleware Platform

Hardware Platform

Network Platform

Network-ResidentMobile-Resident

Figure 41: 4G System Abstraction Layer Groups

The four layers interact with each other using well-defined interfaces (i.e. these interfaces are subject to research and standardisation). In addition to their regular tasks and cooperation with neighbouring layers in an operational setting, each layer must also be reconfigurable individually and independently via configuration interfaces. The configuration interfaces are used to access either parameterise elements within the layer, or to add, exchange, or remove complete elements. The principle of this has been shown in Figure 22. In the following subsections, the Middleware and Network platform layers are described in detail, whilst application and hardware platform are not covered in this section, their interfaces however (as shown in Figure 41) will need to be defined.



© 2002, WWRF 113

5.4.1.1 Configurable Service and Middleware Platform Provision and design of a middleware platform for reconfigurable equipment is, from service providers point of view, the possibility to effortlessly develop and provide new, adapted and customised services. System operators will expect that a middleware platform supports very high flexibility to allow for simple maintenance whilst being proof for further system evolutions. The middleware platform abstraction layer can be split in three major logical parts: the local execution environment, the distributed processing platform, and the service platform (Figure 42).

1) The local execution platform decouples the middleware components from the services/ applications but also from the details and specifics of hardware components and operating systems.

2) The distributed processing platform abstracts the interaction between different system parts which may reside on different but also within the same device. Mechanisms supported by this platform may range from simple remote procedure calls to complex streams, calls, or resource control.

3) The service platform offers session semantics to any requesting service. Sessions maintained by the service platform can be separated into access, service and connectivity sessions. Specifications addressing this area include the TINA Service Architecture [91] and OMG’s TSAS specification [92]. Extensions to the OSA and Parlay framework APIs [93] provide additional session semantics that may be integrated within the service platform.

The applications abstraction layer is above the middleware platform, it contains mechanisms to interact with layers of both middleware and network platform. However, applications not only rely on their interactions with lower layers, but may also act as clients of other applications. Therefore, they are executed in a local execution environment but rely on the distributed processing platform (in case they are part of a distributed system, spawning more than one process and node within the network). Communication related services can use this platform and gain access to the interfaces and functionality of standard communication protocols. Applications executed within the application layer, can in general be grouped into support and end-user applications. Services in contrast are special applications that require particular session semantics, provided by the service platform.



© 2002, WWRF 114

Distributed Processing EnvironmentDistributed Processing Environment

Local Execution Environment

Service Platform

AccessSessionControl

(1..a)

ServiceSessionControl

(1..b)

ConnectivitySessionControl

(1..c)

RPC(1..n)

Streams(1..m)

Events(1..p)

Module1..x

Component1..y

Plug-In1..z

Middleware Platform

Applications

Services

• TINA SA• TSAS• (Parlay+)

• RPCs• CORBA, RMI, SOAPStreams• RTPSignaling & Call Control• H.323, SIP, ParlayLookup & Support• UDDI, Naming, Trading

• JVM/JRE• .NET UVM• Graphics• Codecs• Crypto• Security (AAA)

End-User Applications• Calendar, CalculatorEnd-User Services• Video Conference,

Multimedia Chat, Emergency Locator, Emailmultimedia chat

Support Applications & Services• Billing, Profile Management,

Context Accumulation,Media Conversion

Figure 42: Middleware Platform and Applications

5.4.1.2 Configurable Network Platform Following the approach to define open interfaces, all networking components in the system should be based on technologies providing open interfaces and open computing platforms, this includes both radio and networking layers of the architecture model in Figure 41. This will simplify the future deployment of new/future radio technologies, protocols and services; Software defined radio technologies in reconfigurable terminals and programmable, active network nodes will enable the fast deployment of new services and applications.



© 2002, WWRF 115

a. Network Infrastructure Nodes

Network Side HW / Networking Platform

Active Network ServiceComponents

Reliable OS Active Network Support

Programmable L2 / L3 Switching / Routing Engine -Dedicated HW -OS Kernel Module

•wLAN Module •IMT 200 Module •Wired Nework •Optical Network •….

Interface Modules Interface Modules

Firmware 1..x

EventTrigger

1..y

Parameters 1..z

Forwarding Engine

Filtering Security QoS

Computing PlatformComputing Platform

RoutingProtocol

QoS Protocol

Connection APIs

Middleware Active Network

Service

Component Configuration Interfaces

Config . Agent

Figure 43: Network Side Networking Platform

Similar to the middleware layer, an architecture for the networking in a mobile network is shown in Figure 44. There are three programmable/reconfigurable components within the layer:

• A computing platform serves as a general purpose platform for processing of stateful protocols, e.g. routing, QoS signalling or connection management.

• A forwarding engine in the data path of a network node connects the different interface modules (e.g. by use of a switch matrix). This engine can be implemented as dedicated hardware or as kernel module (as commonly done in most operating systems). The forwarding engine is programmable for performance-critical tasks, which are performed on a per-packet basis.

• The interface modules are media specific and depend on the different wireless or wired standards. They can be configured or programmed to adapt to new physical layer protocols or to trigger events in higher layers.

Installation of new components and reconfiguration of the functionality within this layer can be performed by reconfiguration management mechanisms.



© 2002, WWRF 116

B) Mobile Terminal Architecture

Second part within the Networking Platform is the mobile equipment (see Figure 44), the main components of a terminal architecture following the four layer model of figure Figure 41 include:

• SIM card, e.g. USIM for UMTS, which includes subscriber identities and also a small, but highly secure execution environment,

• Programmable hardware, designed to implement any possible RAT,

• Native operating system which provides real time support, needed for stacks and certain critical applications, e.g. multimedia codecs,

The main requirements from operator and manufacturer point of view include:

• Survivability, e.g. robustness to misconfigurations, failures, or mis-usage,

• Security for end-user, operator, and manufacturer requirements,

• Mass-market optimisation of hardware and software platforms balanced with time-to market and flexibility or upgrade requirements.

Native RT Operating SystemNative RT Operating System

Programmable HW (RF / BB)

Drivers(1..n)

Stacks(1..m)

Config.Manager

DSPCode

ParameterSets

VirtuaRadio

Interface

Mobile HW / Networking Platform

Native OS•Real time support

ProgrammableRadio/BasebandHardware

SIM Execution EnvironmentSIM Execution Environment

ApplicationModule

Authentication

SecurityAppl.Core

Applications

MW Config.Agent

•USIM with Java Platform

Figure 44: Mobile Terminal Architecture



© 2002, WWRF 117

5.4.1.3 Services in Reconfigurable Systems Service deployment as well as control of terminal and equipment reconfigurations are complex procedures, this is partly due to the complexity of the technology but also to the split of responsibilities between operator and manufacturer. Whilst the manufacturer has to provide appropriate and standard compliant low-level code for reconfigurations, the operator actually requires the control of configurations to fit a) the user needs and b) the network requirements.

For the wide-spread adoption of reconfigurable terminals, open interfaces are essential and may be technically discussed standardized in bodies like the SDR Forum [24] or by ETSI or a ‘4G’ standardisation organisation.

5.4.2 Installing a Radio Configuration The descriptions for the various algorithms in a radio configuration can be and should structured in an hierarchical manner, which generates a highly transparent system. The principle of such an hierarchically organised SW structure for radio implementations is shown in Figure 45, whereby the terminal can store a library of basic algorithms, or even complete radio configurations, and knows how they are to be installed on the HW platform to implemented the required RAT [23].

BPC Process Description ExampleBPC Process Description ExampleTerminal Algorithm LibraryTerminal Algorithm Library

HardwareHardwareFilter, Modulation,

RAKE, Equalize, Demod, ...

Filter, Modulation,RAKE, Equalize,

Demod, ...

SoftwareSoftwareInterleaver,

Coding, Burst Build, ...

Interleaver, Coding,

Burst Build, ...

Implementationon SDR

Implementationon SDR

Rx-FilterRx-Filter DemodDemod

Burst DebuildBurst DebuildInterleaveInterleave

EqualizeEqualizeADCIntfcADCIntfc

DemodDemodBurst DebuildBurst Debuild

InterleaveInterleaveADCIntfcADCIntfc

ADC HWMultiplier HW

Rx-FilterRx-Filter

EqualizeEqualize

uProc

ArchitectureSchedule, Control

Mapping Mapping

ParamsParams

Terminal Download from Net

Figure 45: SDR Hierarchical Architecture

The principle depicted in Figure 45 is based on the assumption that a terminal consists of a number of ‘Processing Cells’ (Baseband Processing Cell (BPC) in Figure 45), each of which implements a (high level) module (e.g. BB/RF) within the terminal (see Figure 6). A reconfiguration process could thereby engulf the mere exchange of few parameters, requiring a very small SW download, or a complete terminal reconfiguration requiring download of the complete SW structure to implement the required RAT. The complete description of this process can be found in [23].



© 2002, WWRF 118

The definition and realisation of such a hierarchically ordered architecture, must consider a number of issues:

• What is a suitable hierarchy abstraction level and depth, • What information does a scheduler need for automatic scheduling, • How can low level parameters be set automatically, • How do parameters effect the overall scheduling.

The hierarchical description of a radio configuration combines two advantages. The first one is the abstraction of complex algorithms and complex SW module structures, which, when inherited can be described with one module name only, and the second one is the access to every detail within the (hidden) complex structure. The following section describes generic and adaptive protocols as example for such a hierarchically organised implementation.

5.4.3 Generic and Adaptive Protocols Software Defined Radio enables to flexibly (re-)configure hardware and software within a mobile terminal for a new radio access technology. The functions required are specified for the target RAT and the SDR is the enabler for the execution of these functions. This raises the requirement that hardware and software platform of the SDR terminal must be specified in such a generic way that it allows to execute all functions that may be required. SDR is thus characterized by parameterising generic functions in the RF and BB parts of a mobile transceiver such that they become compatible to a specific radio technology. In a similar way the protocols applied above the physical layer can adapt to this paradigm and follow a similar approach by identifying generic functions at different protocol layers and making them configurable by defined sets of parameters. As aforementioned, this would reduce the amount of data to be sent to the mobile terminal in case a new access network needs to be contacted and the terminal to be reconfigured. Additionally, parameterisation would speed up the download and reconfiguration process and could help to facilitate seamless handover between different access technologies. Therefore, similar to the efforts to parameterise as much as possible in the BB/RF modules, investigations must also be pursued into the structural composition of the protocol steering software. This can be based on a separation of software, into ‘permanent resident code’ and ‘down-loadable add-on modules’. Thereby, the permanent resident software must be as generic as possible, (i.e. generic software skeleton or generic protocol stack). Using shared resources, the generic skeleton may support efficiency and flexibility at the same time. Assuming that devices are equipped with a generic kernel, the required reconfiguration software can be downloaded in a smart-update fashion since only dedicated functionality needs to be included. The combination of generic stack and specific supplement then results in software that is able to support a dedicated air interface standard. The subsequent sections will elaborate on the way how such a generic protocol stack can be constructed in a general way, followed by the more specific example of a ‘generic link layer’.



© 2002, WWRF 119

5.4.3.1 Development of a Generic Protocol Stack Using the classical ISO/OSI protocol stack reference model to compare the stacks of different RATs, a high degree of similarity can be found. Many of the features of the control software can be implemented as shared resources. Therefore a certain software development process should be applied, called Design of Generic and Adaptive Protocol Software (DGAPS). Applying DGAPS results in a generic protocol stack that provides a common basis for a number of different systems. Specialization by introducing standard-specific functions to the generic stack stepwise results in a specific realization towards a specific protocol stack. In a first step (step1) different systems, say System I and System II, need to be analyzed layer by layer to identify their commonalities. A more detailed description of the analysis process together with a reference implementation is described in [91]. The number of different systems to be considered may be two or larger. The result will be a specification of a common subset of the access protocol stacks for the systems, [95]. Since this stack provides the common characteristics of the considered air-interface standards it is called a generic protocol stack or protocol skeleton. The next step (step2 in Figure 46) is to develop specifications dedicated to given air-interface standards, say for System I or System II. These include functions that are specific to respective standards and thus represent the individual behavior of a system. Different approaches can be taken to achieve that goal. In order to make use of the object-oriented properties together with inheritance, it is suggested to implement these parts as subclasses derived from base classes implemented within the generic stack. This is of special advantage, if more than two systems are considered; procedures that are common to most but not necessarily to all standards still will be implemented within the generic stack. The standard-specific supplements than will have to redefine/overload the respective procedures and the behavior required is achieved then.

System_I System_II

Generic_protocol_stack

System_I_specific_protocol_stack

System_I_specific_part System_II_specific_part

System_II_specific_protocol_stack

step 3

step 2

step 3

same functionality step 1

communities

step 2

step 3

same properties

sameproperties

Figure 46: Interaction of Components for an SDR Protocol Stack



© 2002, WWRF 120

To result in a dedicated air-interface standard, the generic protocol stack and the standard-specific supplement, have to be merged (step3). This can be done by means of inheritance. Figure 46 shows the correlations and dependencies of the aforementioned parts in the notation of UML. In order to distinguish between a specific protocol stack that is designed either conformant with the above presented approach or not, the notation System_X (non-conformant) and System_X_specific_protocol_stack (conformant) is used.

5.4.3.2 Definition of a Generic and Reconfigurable Link Layer In mobile communications the radio link is in general the bottleneck of the end-to-end path and it is costly or even impossibly to increase its capacity. Therefore it is required to utilise the available radio resources in the most efficient way. This role is performed by sophisticated radio physical layers and radio link layers, which are optimised to the radio access technology in use. In Figure 47 (left side) a simplified protocol stack is depicted, in which a correspondent node communicates with a mobile terminal. The end-to-end connection is established with e.g. the Internet Protocol (IP). The radio link layer (here called GLL) and the radio physical layer (PHY) enable data transmission over the radio link. Assuming that the radio link is the bottleneck, most data which is currently in process of being transmitted along the end-to-end path is typically either queued or being processed within the radio link layer. This approach has proven to be an efficient design for communication in today’s mobile communication networks, where a specific mobile network with a specific radio access technology is used. However, there are certain limitations in the context of co-operating networks, in which seamless communication is desired via a multitude of mobile networks, which may deploy different radio access technologies. This scenario is depicted in Figure 47, where a mobile terminal dynamically selects one of the available radio access networks (RAN A or RAN B) during a session. Each radio access network uses its’ specific radio link layer and radio physical layer (left side of Figure 47). During an inter-system handover from RAN A to RAN B, the radio link in RAN A is torn down and a new radio link is being set-up in RAN B. Such a handover can only be lossless if a further layer of error recovery is applied, e.g. end-to-end on top of IP. But even then an inter-system handover is neither efficient nor without disruption of the service.



© 2002, WWRF 121

IP-basedCN

RAN A RAN BLL2L1 LL1

L1

LL1L1

IPLL2L1

IPIP

Multiple link layersIP-based

CNIP-based

CNRAN A RAN BLL2

L1 LL1L1

LL1L1

IPLL2L1

IPIP

Multiple link layersIP-based

CN

RAN A RAN BGLLL1 GLL

L1

GLLL1

IPL1

IPIP

Generic link layerIP-based

CNIP-based

CN

RAN A RAN BGLLL1 GLL

L1

GLLL1

IPL1

IPIP

Generic link layer

Figure 47: Multiple Link Layer Scenario compared to Generic Link Layer Scenario

(GLL – generic link layer, LL – link layer, L1 – layer 1, RAN – radio access network, CN – core network)

Since different radio link layers have in general the same functionality for all radio access technologies, this problem can be solved if the radio link layers are made compatible. The old radio link layer state can then be handed over to the new radio link layer, which continues the transmission in a seamless way. This is achieved by defining a generic link layer, which can be used as radio link layer for all radio links (right side of Figure 47). The Generic Link Layer (GLL) is a specified radio layer protocol, which provides the link layer functions required in every radio link layer [100]. It can be configured in a flexible manner to perform these link layer functions in an optimised way for different radio access technologies with different properties. The generic specification of radio link layer functions enables reconfiguration of the generic link layer in which the existing communication context at time of reconfiguration is transformed into a new context within the new configuration. As a result the communication session can ‘survive’ the reconfiguration procedure lossless and without disruption. From a service perspective it is a seamless reconfiguration. The GLL concept requires a reconfiguration of the GLL on both sides of the wireless link, in the mobile terminal as well as in the radio access node. This is required in order to seamlessly continue with the old context of the communication. To implement a GLL following interfaces and reference points have to be define (Figure 48):

• The higher layer interface: Via the interface to the higher protocol layer data is received for transmission and delivered after reception. This interface further allows to configure the QoS requirements for the transmission of higher layer datagrams,

• The physical layer interface: At the interface to the physical layer radio blocks are sent to the physical layer for transmission over the radio link,

• The control interface: Via control interface the generic link layer is configured and reconfigured,

• The internal interface to embed specific functions: Via this interface it shall be possible to include a specific function, e.g. a ciphering algorithm, into general functions.



© 2002, WWRF 122

generic functions

specfic functions

interface to higher protocol layer

interface to physical layer

interface to control and configuration

manager

GLL

internal interface

Figure 48: Generic Link Layer Functions and Interfaces

5.4.4 Software Radio Architecture (SRA) Configurability The SRA proposed approach is based on a logical Waveform decomposition and on the use of a Core Framework (CF). SRA promotes that new applications should be developed in layers in conformance with the ISO/OSI model:

• Waveform should be split into physical, LLC and MAC components that each figure a (sub)layer,

• Network application should be implemented as a OSI network component.

This model enable the various Baseband reference models proposed in Chapter 4. As represented in Figure 49, SRA identifies two kinds of internal interfaces:

• Type A are (hard) real-time constrained interfaces, • Type B are interfaces that accommodates with statistical (soft) real-time.

The SRA specifications identify the corresponding API for each layer. Some waveforms have been implemented by industries with respect to this model, in HF and VHF spectrum. Major challenge of this model is to design the layer with respect to the model, especially to sequence the data and control processing. Major advantage of this model is, of course, configurability and upgradability of waveform application. An indirect great advantage of this model stands in testability: each component is tested independently of the system because all interfaces and states of the component are defined.



© 2002, WWRF 123

I/O

Network

Physical

A

B

WaveformApplication

A Data and Real-time Control

B Non-real-time Control, Setup and Initialization,from applications, other levels, user interface

ExternalNetwork

Connection

LLC LLC

MAC

A

B

A

B

A

B

A

B

Figure 49 : Waveform Component Model

The underlying structure which support actively the previous waveform model is the Core Framework (CF) which can be seen as a "waveform run time". The Figure 50 summarizes the relationships between Core Framework run-time CSCs (Computer Software Components). This UML model highlights some innovative ideas:

• Importance of the Resource concept: all hardware and software components are subtypes of a Resource,

• Introduction of the DomainManager which acts as a (re)configuration and (re)deployment co-ordinator,

• TestableObject class whose all components inherits through the Resource allowing to run (on-line) tests procedure on component.

The Port class has no relationships with any other one because the Port concept has links only with XML classes defined in. Those XML classes do not appear at runtime, but only at load time when the DomainManager interprets the contents of Profiles files. The DomainManager can be at a network level and so coordinate the network configuration. A Network Provider can extent the DomainManager to its specific needs.



© 2002, WWRF 124

Figure 50: SRA Core Framework Model

The system and applications are described using Configuration Management Files which are a set of XML files that are collectively referred to as a Domain Profile. These files describe the identity, capabilities, properties, inter-dependencies, and location of the hardware devices and software components that make up the system’s configuration. Those files describes executable configurations (e ;g : application) in terms of packages, components, devices ... Each entity is described once and referenced through hyperlink by each entity that use it. The Domain Profile database is used by ApplicationFactory for setting up new software.



© 2002, WWRF 125

5.5 Research Challenges Complete reconfigurability of SDR equipment will only be achieved if single software modules within the SDR platform can be reconfigured individually. This necessitates clearly defined interfaces between the various modules and independence between them. To develop a complete framework of interfaces between the building blocks of a reconfigurable equipment (terminal/base station, etc.), a number of research need to be solved:

• Definition of an overall architecture for future mobile communication systems based on a set of configurable abstraction layers (programmability is to a small extent already realized in second and third generation systems, but fully flexible component configuration in all layers will be a major breakthrough for the creation and deployment of fourth generation services),

• The specification of abstraction layer functionality including the integration of existing and emerging heterogeneous systems and networking environments,

• The definition of cross layer information flows to assist service support on all abstraction layers,

• Clear separation of tasks between the different reconfigurable modules (modules are as indicated in Figure 6),

• Generalisation and specification of individual generic interfaces between RF and BB as well as between BB and the GP modules,

• Identification of all reconfiguration control/management related functions, • Definition of a generic control/management interface between the individual radio

modules and the reconfiguration manager. • The identification of a generic framework comprising policy based reconfigurable

functional entities in various layers and applications, as well as layer independent reconfiguration management and adaptable service creation, deployment and provision environment

Research issues that need to be addressed for the introduction of a generic framework for reconfigurable mobile environments are:

• Identification of open APIs for reconfiguration actions triggering in various layers and components

• Identification of generic reconfigurability management functionality • Identification of advanced network/terminal related applications and functionality for

flexible service provision, software/protocol downloading/offloading and various access systems integration

• Introduction of adaptability enabling architectures and environments



© 2002, WWRF 126

There are a number of research issues that need to be addressed in the definition of Generic and adaptable protocols and protocol stacks, these include:

• Definition of elementary commonalities of the various mobile communication systems, • Resource-sharing within telecommunication software, • Modular software design and interfaces, • Reusability of software, • Structure of a generic protocol stack, • Nature of software extensions to an existent system, • Composition of an adaptive protocol stack architecture, • Identification, description & specification of GLL functions, • Description & specification of GLL interfaces, • Configuration management and reconfiguration of the GLL, • A protocol framework for the GLL, • Integration of the GLL within SDR.

As described in this chapter, various research efforts have been identified and initiated on different ways. Each result exhibits advantages and discrepancies, parallel implementations and evaluations shall be conducted to define the most appropriate one. Those research efforts exhibits a model of SDR based on components or layers interconnected with interfaces and supported by an operating environment. It is obvious that the next step will be to merge those efforts in the definition of a common and shared model and to define the associated SDR framework enabling the development of baseband, services and waveform designed for reconfigurability. This SDR framework will also enable the development of the supervision and management services at the network level.



© 2002, WWRF 127

66 DDeeppllooyymmeenntt RRooaaddmmaappss ffoorr RReeccoonnffiigguurraabbiilliittyy AApppplliiccaattiioonnss In this section we attempt to trace a plausible roadmap for the deployment of reconfiguration applications into equipment and by extension into networks. Such a roadmap may serve as a guide in anticipating evolution, identifying important problem areas and if possible contribute to appropriate organisations (e.g. standard bodies, international fora) in meaningful topics. A roadmap is needed in order to put technology into perspective and for handling the complexity of difficult problems by defining an evolution path of incremental technology introduction.

The roadmaps treat two popular use-case scenarios. First comes the scenario for over-the-air (OTA) software upgrades and second comes the scenario for dynamic radio mode and standard switching [31]. These two scenarios correspond to applications of reconfiguration that appeal to operators according to an extensive market study on SDR requested by the SDR Forum. The deployment road-maps are graphically depicted separately for each scenario in Figure 51.

Need agreement between OEMs, operators on:• what can be upgraded/changed• security, reliability, fault-tolerance, testing• how the upgrade/patch is packaged• reconfiguration link & protocol• needed network infrastructure

Need agreement between OEMs, operators on:• what can be upgraded/changed• security, reliability, fault-tolerance, testing• how the upgrade/patch is packaged• reconfiguration link & protocol• needed network infrastructure

A0: preliminary phasegeneric HW platforms / differentiation in SWuser initiated switch/selection

mmode, multi-application by SW paging

A0: preliminary phasegeneric HW platforms / differentiation in SWuser initiated switch/selection

mmode, multi-application by SW paging

Equipment design to enable remote upgradesbug-fixing, remote software upgradesterminal: wired or wireless connection (e.g. WAP, imode, ...)

OEM-User private affairBTS: extensions to O&M

Equipment design to enable remote upgradesbug-fixing, remote software upgradesterminal: wired or wireless connection (e.g. WAP, imode, ...)

OEM-User private affairBTS: extensions to O&M

Remote upgrades as operator provided servicea service center network entity will manage the remoteupgrades for every type of terminal that can be upgraded

Remote upgrades as operator provided servicea service center network entity will manage the remoteupgrades for every type of terminal that can be upgraded

Deployment of operator requested software upgradesseveral algorithms in the radio interface may be defined asupgradable in order to have the capability to enhancenetwork performance and increase service qualityoperators may design their proper algorithms and then askOEMs to provide the device software upgrades

Deployment of operator requested software upgradesseveral algorithms in the radio interface may be defined asupgradable in order to have the capability to enhancenetwork performance and increase service qualityoperators may design their proper algorithms and then askOEMs to provide the device software upgrades

Preliminary ReflectionPreliminary ReflectionPreliminary Reflection

StandardizationStandardizationStandardization

Need agreement on:• signaling & download• reconfiguration/download for inter-standard handover• multi-standard services• dynamic spectrum allocation• needed network infrastructure for management

Need agreement on:• signaling & download• reconfiguration/download for inter-standard handover• multi-standard services• dynamic spectrum allocation• needed network infrastructure for management

From lower to higher impact to the network design (the existing mechanisms will have to be augmented)• new multi-criteria decision processes,modifications to the signaling aspects, new logical and/or physical channels for download• heterogeneous network collaboration, reconfiguration management & accounting

B4: increased Terminal IQmore intelligence at the terminal in thereasoning/decision process fordownload/switchless work for the network andless related traffic

B4: increased Terminal IQmore intelligence at the terminal in thereasoning/decision process fordownload/switchless work for the network andless related traffic

Preliminary phasegeneric HW platforms with differentiation in SWuser initiated switch/selection

mmode, multi-application by SW pagingno download

Preliminary phasegeneric HW platforms with differentiation in SWuser initiated switch/selection

mmode, multi-application by SW pagingno download

Increased Terminal IQmore intelligence at the terminal in thereasoning/decision process fordownload/switchless work for the network andless related traffic

Increased Terminal IQmore intelligence at the terminal in thereasoning/decision process fordownload/switchless work for the network andless related traffic

ROADMAP I: Remote Upgrades

ROADMAP II: Enhanced Network Management

Network controlled switching2G-2.5G-3G-WLAN operation for coverage, QoS reasonsmulti-band, multi-mode operation, requiring priordownload (of parameters)network signaling issues, decision policies

Network controlled switching2G-2.5G-3G-WLAN operation for coverage, QoS reasonsmulti-band, multi-mode operation, requiring priordownload (of parameters)network signaling issues, decision policies

20052005

Multi-mode servicesDAB + GSM, DVB + UMTS, ...

Multi-mode servicesDAB + GSM, DVB + UMTS, ...

20062006

Network optimizationNetwork controlled download/switch, inter-standard handoff

• spectrum management• optimized radio resource allocation• algorithm diversity for better adaptation to Tx environment

signaling and download via special logical/physical channelspredictive download

Network optimizationNetwork controlled download/switch, inter-standard handoff

• spectrum management• optimized radio resource allocation• algorithm diversity for better adaptation to Tx environment

signaling and download via special logical/physical channelspredictive download

2007 - 20082007 - 2008

20032003

20032003

20042004

20052005

20062006

20082008

20092009

Figure 51: Deployment Roadmaps for Incremental Introduction of Reconfigurability Applications



© 2002, WWRF 128

Over the past ten years previous work on SDR has set a solid foundation for the future evolutions represented by these two roadmaps. Technical issues have been investigated in depth by the SDR Forum. SDRF provided feedback to 3GPP in order for MExE to make provision for the software download required by reconfigurable radios. In this spirit the introductory phase indicated in the roadmaps is based on this previous work. The introductory phase consists in designing the devices in such a way that part or all of their radio functionality is designed to be modifiable by means of software change. This requires from one hand using generic hardware platforms and increasingly software implementations and from the other hand a software architecture permitting to completely or partially modify its function statically or dynamically. In addition, at the network side there is provision in the standards (e.g. 3GPP TS 22.129) for 2G to 3G seamless handoff (i.e. GSM to UMTS). This currently works under the assumptions that standard switching does not need download and that core networks are compatible. After this introductory phase the technical focus will shift from the radio implementation to the reconfiguration aspects of SDR as well as the network involvement in the reconfiguration process. To handle these aspects previous research work, like for instance results of EU projects, provides a good starting point. Within previous studies in 5th IST FW programme dedicated studies have been performed about downloading and SDR mechanisms for dynamic installation and test on new SW modules in a terminal. Several projects (TRUST/SCOUT, CAST, PASTORAL) contributed and still contribute to elaborate proposal for implementation of Reconfiguration control unit able to access and reconfigure SW modules at each layer of the system (Application, Protocol, physical layer) These results allow to anticipate that the concept can be implemented into wireless/mobile terminals, the main limitations are linked to cost, consumption and targeted features that have to be defined for these future systems. Past experience shows that technologies evolve from simple towards more complex applications and on a need basis. Thanks to its simplicity, the scenario on software upgrades for bug-fixing and for performance enhancement as well as algorithm dynamic change (i.e. algorithm diversity) within a single mode of operation could be deployed first. Next will come simple robust schemes (e.g. based on parameter controlled reconfiguration [107]) for multi-mode/multi-service operation without or with minimal network implication. These schemes will eventually permit download and reconfiguration signalling through logical/physical channels existing within the mode of operation (e.g. GSM logical channels or GSM based wireless internet links). Alternative uplink air-interfaces could be used whenever the mode of operation disposes only of a downlink, (e.g. DAB/DVB). During this period device reconfiguration mechanisms and designs will mature a high degree of reliability of the reconfiguration processes will be attained and regulation issues will be more clear. At the same time moving towards 4G will advance work on network interoperability and network management unification. This fact will push forward software radio applications requiring more network involvement and cooperation [108]. An all-IP approach will certainly facilitate resolving these interoperability issues



© 2002, WWRF 129

Such application may target things like:

• Dynamic spectrum and network resource management, • More intelligent air-interface selection for "best" communication and service integration, • Flexible service discovery and provision, • Reconfigurable applications to support context aware network wide reconfigurability, • Reconfigurable charging and security schemes.

Finally, progress in the domain of identification algorithms will greatly contribute in making the reconfigurable radio devices increasingly independent. As it is shown in Figure 51, in all cases there is need for standardisation. Standards will define the required device capabilities, the needed network infrastructure support as well as the communication links and protocols needed for signalling and data transfers. As a conclusion it can be said that the way reconfiguration capabilities will be deployed in the future is not yet completely known. The above roadmaps are only a plausible work hypothesis and have to be taken as such. Other interesting use-case scenarios most probably will have to be considered as well. Commercial applications will initially consider existing air-interfaces. This is because work on future air-interfaces (e.g. 4G) is still ongoing. However a reconfigurable SDR approach offers the benefit of making possible future transition with a low impact on existing infrastructure. As the deployment will be incremental; in between deployment phases experimentation is certainly needed. System prototyping will be a valuable approach in order to concretely demonstrate solutions into a smaller scale before their application in a larger scale. Such experimentation and prototyping could be part of R&D projects investigating future telecom systems.



© 2002, WWRF 130

77 CCoonncclluussiioonnss This White Paper outlined the issues and technological problems of reconfigurable systems and endeavoured the definition of a “Reference Model for Reconfigurable SDR Equipment and Supporting Networks”. The SDR reference model includes the whole range of different access schemes available, stretches through the heterogeneous Beyond 3G environment and provides the means for interconnection of the associated variety of systems. The multitude of different radio transmission and access technologies is included in the reference model, and means for (re)configuration management in the network elements and end equipments have to be installed to control the configurations of nodes between the communication end points. The SDR reference model encompasses System and Network (including core and access network/base stations), the hardware issues in both RF & BB side and the data & control/management interfaces between the various building blocks of the reconfigurable environment. Following introduction of the multi-dimensional aspects of SDR and the needs and constraints for terminal and network reconfigurability in chapter 1, the SDR system and supporting networks reference models and architectures have been presented and analysed in details within chapter 2. A “High-level Reconfiguration System Model” was proposed in this chapter and existing SDR system architectures were reviewed as potential candidates for future research on reconfigurable SDR equipment and supporting networks. Network and terminal reconfigurability and adaptability were deeply covered, security having been also addressed at the end of the chapter as key area for SDR. To support the development of software defined and re-configurable radio and networks, the research on SDR System and Software Architectures will have to address the following main areas: system, network and protocol architectures supporting re-configurable equipment, network-centric re-configuration support and finally terminal-centric re-configuration support. All identified research thematics were summarized as conclusion of the chapter. The different SDR RF architectures choices have been investigated in chapter 3. This chapter reviewed issues that have arisen out of architectural considerations. Current state of the art solutions to these issues have been examined. Necessary research to extend the usefulness of these solutions to a practical SDR design has been identified. Chapter 3 discussed possible research topics, which, it is hoped, will aid the evolution of SDR hardware design. MEMS technology has been specifically examined, as it provides the possibility of innovative breakthroughs that established technologies are incapable of providing. These research thematics include: agile linear frequency translation, flexible linearity profile (FLP) amplifiers, diplexerless frequency-agile radio front-end, interference cancellation or filtering, adaptive preselect filters, frequency agile zero IF receiver, novel up-conversion techniques, digital IF processing and finally data converters. Chapter 3 also proposed a RF road-map to make the SDR transceiver become a reality.



© 2002, WWRF 131

Chapter 4 focused on the SDR Baseband Architectures and critical components. Primary goal of the research in the field of SDR-BB concept is a generic hardware architecture which is able to cover as many current and upcoming wireless standards as possible. Baseband processing of the future multi-standard terminal or basestation will set very demanding requirements in computational performance and flexibility. It is very probable, that the future baseband processing architectures will consist of different kind of processing, storage and interconnection resources. Different kind of reconfigurable technologies will be used as processing elements. The reconfigurable technologies include configurable processing cores, FPGA-based approaches, embedded FPGA-based approaches and approaches based on arrays of processing elements. Still the special purpose hardware blocks will be needed also for the most demanding algorithms due to their superior silicon area and energy efficiency. Research is needed to define what is an optimum hardware architecture for a given wireless standard set. A crucial issue of the resulting architecture is the resulting implementation complexity, i.e. power consumption, chip area of single modules and the overall resulting architecture. This may also include research on efficient HW-Structures of re-configurable logic modules. Design flow for implementation of SW-modules for constituent standards on the hardware architecture has also to be considered. Chapter 4 was concluded with the summary of identified critical components, future directions and research goals. Chapter 5 investigated SDR equipment interfaces, protocol issues and genericity of the link layer. A powerful processing platform and a structured software architecture capable to implement the system requirements of the various RATs are core basis for the development of future reconfigurable SDR equipment. An architectural framework was developed which considers the inclusion of open programming interfaces for both the application layer but also for the lower system levels (i.e. an open programming interface for RAT implementation software). To develop this complete framework of interfaces between the building blocks of a reconfigurable equipment (terminal/base station, etc.) a number of research need to be solved, including clear separation of tasks between the different reconfigurable modules, generalisation and specification of individual generic interfaces between RF and BB as well as between BB and the GP modules, identification of all reconfiguration control/management related functions, definition of a generic control/management interface between the individual radio modules and the reconfiguration manager. The research topics associated to the definition of generic and adaptable protocols and protocol stacks have also been identified. The SRA configurability was addressed at the end of the chapter 5. A specific research challenges section concluded this chapter. Finally, chapter 6 attempted to define some plausible roadmaps for the deployment of reconfiguration applications. These roadmaps treat basic scenarios frequently mentioned in the literature: reconfiguration for remote equipment upgrades and reconfiguration for enhancing network management. Specific technical Appendixes complement the overall White Paper: Appendixes 1 to 5 (section 9.1 to 9.5) provide additional information to Chapter 2 on coupling methods, profile location, mobility management, mass up-grade and signalling. Appendix 6 (section 9.6) complements chapter 3 on amplifier linearisation schemes.



© 2002, WWRF 132

88 RReeffeerreenncceess [1] Book of Visions for the Wireless World, issued by the Wireless Strategic Initiative

(www.ist-wsi.org), December 2000. [2] 2nd Book of Visions for the Wireless World, issued by the Wireless World Research Forum

(www.wireless-world-research.org), December 2001. [3] http://mobivas.cnl.di.uoa.gr/ [4] Alonistioti, N. Houssos, S. Panagiotakis, M. Koutsopoulou, V. Gazis, "Intelligent

architectures enabling flexible service provision and adaptability", Wireless Design Conference (WDC 2002), London, UK, 15-17 May 2002.

[5] S. Panagiotakis, N. Houssos, A. Alonistioti, "Integrated generic architecture for flexible service provision to mobile users", IEEE 12th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2001), San Diego, California, USA, 30/9 - 3/10 2001, pp. 40-44.

[6] Alonistioti, N. Houssos, S. Panagiotakis, "A framework for reconfigurable provisioning of services in mobile networks", Sixth International Symposium on Communication Theory & Applications (ISCTA 2001), Ambleside, Lake District, UK, pp. 21-26.

[7] M. Koutsopoulou, N. Alonistioti, E. Gazis, A. Kaloxylos, "Adaptive Charging Accounting and Billing system for the support of advanced business models for VAS provision in 3G systems" Invited paper at the PIMRC 2001, September - October 2001, San Diego, USA.

[8] Nikos Houssos, Vangelis Gazis, Athanassia Alonistioti, "A flexible management architecture for the support of advanced business models in 3G mobile service provision", 1st International Conference on Mobile Business (M-Business 2002), Athens, Greece, 8-9 July 2002.

[9] N. Houssos, V. Gazis, S. Panagiotakis, S. Gessler, A. Schuelke, S. Quesnel, "Value Added Service Management in 3G Networks", 8th IEEE/IFIP Network Operations and Management Symposium (NOMS 2002), Florence, Italy, 15-19 April 2002, pp. 529-545.

[10] Alonistioti, S. Panagiotakis, N. Houssos, A. Kaloxylos, "Issues for the provision of Location-dependent services over 3G networks", 3rd generation infrastructure and services conference (3GIS) , Athens, Greece, July 2001.

[11] S. Panagiotakis, N. Houssos, N. Alonistioti, "Generic architecture and functionality to support downloadable service provision to mobile users", 3rd generation infrastructure and services conference (3GIS), Athens, Greece, July 2001.

[12] Nikos Houssos, Spyros Pantazis, Athanassia Alonistioti, "Towards adaptability in 3G service provision", IST Mobile Communication Summit 2002, Thessaloniki, Greece, 16-19 June 2002

[13] N. Alonistioti, E. Gazis, M. Koutsopoulou, Spyridon Panagiotakis, “An Application platform for downloadable VASs provision to mobile users”, proceedings of the IST Mobile Communications Summit 2000, Galway, Ireland, September-October 2000.

[14] 3GPP TS 29.198: “Open Service Access (OSA); Application Programming Interface (API); Part 1-12 (version 4.3.0)”.

[15] Open Services Gateway Initiative (OSGi) Service Platform, Release 2, October 2001 , available from URL http://www.osgi.org/resources/docs/spr2book.pdf

http://www.ist-wsi.org/

http://www.wireless-world-research.org/

http://mobivas.cnl.di.uoa.gr/

http://cnl/publications/WDC_2002_final.pdf

http://cnl/publications/WDC_2002_final.pdf

http://cnl/publications/PIMRC2001_RCSPM.pdf

http://cnl/publications/PIMRC2001_RCSPM.pdf

http://cnl/publications/ISCTA_2001_UoA_final_1.PDF

http://cnl/publications/ISCTA_2001_UoA_final_1.PDF

http://cnl/publications/NOMS_2002_UoA_final.pdf

http://cnl/publications/NOMS_2002_UoA_final.pdf

http://cnl/publications/3gis_LocationServices_final.pdf

http://cnl/publications/3gis_LocationServices_final.pdf

http://cnl/publications/3GIS_spyros_camera_ready_160104.pdf

http://cnl/publications/3GIS_spyros_camera_ready_160104.pdf

http://cnl/publications/IST_Summit_2002_UoA_Adaptability_final.pdf

http://cnl/publications/IST_Summit_2002_UoA_Adaptability_final.pdf

http://www.osgi.org/resources/docs/spr2book.pdf



© 2002, WWRF 133

[16] Parlay Group, “Parlay API Spec. 2.1”, July 2000, available from URL http://www.parlay.org/specs/index.asp

[17] J. Keijzer, D. Tait, R.Goedman, “JAIN: A new approach to services in communication networks”, IEEE Communications Magazine, January 2000.

[18] LIF TS 101 “Mobile Location Protocol” v2.0.0. [19] Report #9, UMTS Forum, http://www.umts-forum.org/. [20] Spyridon Panagiotakis, Maria Koutsopoulou, Athanasia Alonistioti, Alexandros

Kaloxylos, “Generic Framework for the Provision of Efficient Location-based Charging over Future Mobile Communication Networks”, PIMRC, Lisbon, Portugal, September 2002.

[21] Spyridon Panagiotakis, Maria Koutsopoulou, Athanasia Alonistioti, “Advanced Location Information Management Scheme for Supporting Flexible Service Provisioning in Reconfigurable Mobile Networks”, IST Mobile Communication Summit, Thessaloniki, Greece, June 2002.

[22] M. Beach, D. Bourse, R. Navarro, M. Dillinger, T. Farnham, T. Wiebke, “Reconfigurable Terminals Beyond 3G and Supporting Network System Aspects”, Presentation in WG 3, Stockholm, Sweden, 17-18 September 2001.

[23] www.ist-trust.org, 2002. [24] www.sdrforum.org, 2002. [25] www.mobilevce.com, 2002. [26] J. Mittola, “The Software radio Architecture,” IEEE Communications Magazine, May 1995. [27] Bourse D, “WWRF WG3 SDR Architectures”, a document circulated in the SDR

community within the Wireless World Research Forum, May 2002. [28] http://www.sdrforum.org/tech_comm/mobile_wg.html [29] Metha M., Wesseling M, “Adaptive Baseband Subsystem for TRUST”, Proceedings of

PIMRC 2000, pp. 29-33, London, UK, 18th-21st September 2000. [30] Gultchev S, et al, “Management and Control of Reconfiguration Procedures in Software

Radio Terminals”, 2nd Workshop on Software Radio, Karlsruhe, Germany, 20/21st March 2002.

[31] N. Nakajima, R. Kohno, S. Kubota, Research and Developments of Software-Defined Radio Technologies in Japan, IEEE Communications Magazine , vol. 39, no. 8 , Aug. 2001, pp. 146 -155.

[32] J.D. Laster, Robust GMSK Demodulation Using Demodulator Diversity and BER Estimation, Ph.D. Thesis, Virginia Tech, 1997.

[33] SCOUT webpage: http://www.ist-scout.org [34] H. Kaaranen et al, ‘UMTS Networks. Architectures, Mobility and Management’, John Wiley

& Sons, Ltd, 2001. [35] X. Qiu et al, ‘Network Assisted Resource Management for Wireless Data Networks’, IEEE

Journal on Selected Areas in Communications, vol. 19, no. 7, pp 1222-1234, July 2001. [36] H. Yomo, S. Hara, ‘Impact of Access Schemes Selectability on Traffic Performance in

Wireless Multimedia Communication Systems’, IEEE Transactions on Vehicular Technology, vol. 50, n. 5, pp 1298-1307, Sept 2001.

[37] http://www.tinac.com/about/about.htm [38] E. Buracchini, “The Software Radio Concept”, IEEE Communications Magazine, September

2000.

http://www.parlay.org/specs/index.asp

http://www.umts-forum.org/

http://www.ist-trust.org/

http://www.sdrforum.org/

http://www.mobilevce.com/

http://www.sdrforum.org/tech_comm/mobile_wg.html



© 2002, WWRF 134

[39] Shiao-Li Tsao, Chia-Ching Lin, Hung-Lin Chou, Chin-Lien Chiu, Min-Chiao Wang, “Design and Implementation of Software Framework for Software Defined Radio System”, to appear in Proceedings of IEEE VTC Fall 2002.www.sdrforum.org, 2002.

[40] 3GPP TS 23.057: “Mobile Execution Environment (MExE) Functional Description”, Version 5.0.0, March 2002.

[41] 3GPP TS 33.102: “3G Security – Security Architecture”, Version 5.0.0, June 2002. [42] Rainer Falk, Nicola Greco: “Securely Reconfigurable Terminals”, IST Mobile

Communications Summit 2001, Barcelona, Spain, September 2001. [43] Lachlan B. Michael, Miodrag J. Mihaljevic, Shinichiro Haruyama, Ryuji Kohno: A

Framework for Secure Download for Software Defined Radio, IEEE Communications Magazine, pp. 88–96, July 2002.

[44] K. Moessner, S. Gultchev, R. Tafazolli, ‘Managing Reconfiguration in Software Defined Communication Systems’, ISCTA’01, Ambleside, Lake District, United Kingdom, 15-19 July 2001.

[45] http://www.iis.ee.ethz.ch/nwp/lemon/lemon.html [46] Springer A., Maurer L., Weigel R., RF System Concepts for Highly Integrated RFICs for W-

CDMA Mobile Radio Terminals, IEEE Transactions on Microwave Theory and Techniques, Vol. 50, No. 1, January 2002, pp254-267.

[47] Sagers R. C., Intercept Point and Undesired Responses, IEEE Transactions on Vehicular Technology, Vol. 32, February 1983, pp121-133.

[48] Crols J., Steyaert M. S. J., “Low IF Topologies for High Performance Analog Front Ends of Fully Integrated Receivers”, IEEE Transactions on Circuits and Systems – II: Analog and Digital Signal Processing Vol. 45, No. 3, March 1999, pp269-282.

[49] Banu M., Wang H., Seidel M., Tarsia M., Fischer W., Glas J., Dec A., Boccuzzi V., A “BiCMOS Double-Low-IF receiver for GSM”, IEEE 1997 Custom Integrated Circuit Conference, pp521-524.

[50] Abe M., Sasho N., Brankovic V., Krupezevic D., Direct Conversion Receiver MMIC based on Six-Port Technology, European Conference on Wireless Technology, 2000.

[51] Hyyryläinen J., Bogod L., Kangasmaa S., Scheck H.O., Ylämurto T., Six-port Direct Conversion Receiver, 27th European Microwave 97 Conference Proceedings, Vol. 1, Sept. 97, pp341-346.

[52] . I. Mann, M. A. Beach, P. A. Warr and J. P McGeehan, “Increasing the talk-time of mobile radios with efficient linear transmitter architectures,” IEE Electronics & Communication Engineering Journal, Vol. 13, No 2, pp., 65-76, April 2001.

[53] P. A. Warr, M. A. Beach and J. P. McGeehan, “Gain-element transfer response control for octave-band feedforward amplifiers,” IEE Electronics Letters, Vol. 37, No. 3, pp., 146-147, 1st February 2001.

[54] T. Nesimoglu and M. A. Beach, “Linearised mixer using frequency retranslation”, UK Patent Application No. 0117801.1, 20th July 2001.

[55] T. Nesimoglu, M. A. Beach, P. A. Warr and J. R. MacLeod, “Linearised Mixer using Frequency Retranslation”, IEE Electronics Letters, Vol. 37, No. 25, pp., 1493-1494, December 2001.

[56] P. Katzin, V.Aparin, “Active, Self Adjusting, L-S Band, MMIC Filter”, IEEE GaAs Symposium, pp 41-43, 1994.

[57] P Katzin, Personal Correspondence, January 2001. [58] G. Matthaei, L. Young, E.M.T. Jones, “Microwave Filters, Impedance-Matching Networks,

and Coupling Structures”, Artech House 1980.

http://www.sdrforum.org/

http://www.iis.ee.ethz.ch/nwp/lemon/lemon.html



© 2002, WWRF 135

[59] R Levy S.B. Cohn “A History of Microwave Filter Research, Design, and Development”, IEEE Transactions on Microwave Theory and Technique, Vol. MTT-32, No.9, pp1055- 1067, September 1984.

[60] I.C. Hunter and J.D. Rhodes “Electronically Tuneable Microwave Bandpass Filters”, IEEE Transactions on Microwave Theory and Techniques, Vol. MTT-30, No9, pp1354- 1360, September 1982.

[61] R. Y. Loo, G. Tangonan, D. Sivenpiper, J. Schaffner, T.Y. Hsu, H.P. Hsu, “Reconfigurable Antenna Elements using RF MEMS Switches”, Proceedings of ISAP2000, pp 887- 890, Fukuoka, Japan, 2000.

[62] M Sagawa, K Takahashi, M Makimoto. “Miniaturised Hairpin Resonator Filters And Their Application To Receiver Front End MIC’s”, IEEE Transactions on Microwave Theory and Techniques, Vol. 37, No. 1`2, pp1991-1997, December 1989.

[63] M Makimoto, S Yamishita, “Bandpass Filters Using Parallel Coupled Stripline Stepped Impedance Resonators”, IEEE Transactions On Microwave Theory And Techniques, Vol. MTT-28, No. 12, pp1413-1417, December 1980.

[64] O Rostbakken, G.S. Hilton, C.J. Railton, C.J., 'Adaptive Feedback Frequency Tuning for Microstrip Patch Antennas', 9th International Conference on Antennas and Propagation, IEE. Part 1, 1995, pp.166-70,vol.1. London, UK.

[65] O Rostbakken, G.S. Hilton, C.J. Railton, “An adaptive microstrip patch antenna for use in portable transceivers” IEEE 46th Vehicular Technology Conference. Mobile Technology for the Human Race. IEEE. Part vol.1, 1996, pp.339-43 vol.1. New York, NY, USA).

[66] P.R. Urwin-Wright, G.S. Hilton, I.J. Craddock & P.N. Fletcher, “A Tuneable Electrically-Small Antenna Operating in the ‘DC' mode”, Abstract submitted for IEE Radio Spectrum Seminar “Getting the Most out of the Radio Spectrum,” London, October 2002.

[67] R. C. Johnson (Ed), ‘Antenna Engineering Handbook’, 3rd Edition, New York, McGraw-Hill, 1993.

[68] Ali, Hayes, Hwang and Sandler, ‘A Triple – band Integrated Antenna for Mobile Hand – Held Terminals, APS 2002, pp 32–35.

[69] Fusco, V., ‘Integrated Antennas for Wireless Applications’, Applied Microwave and Wireless, June 2002, pp 22-31.

[70] S. A. Long, M.W. Mcallister and L.C.Shen, ‘The resonant cylindrical dielectric cavity antenna’, IEEE Trans on Antennas and Propagation, vol AP-31, pp. 406-412, May 1983

[71] http://literature.agilent.com/litweb/pdf/5968-1613E.pdf [72] R. J. Richards, H. J. De Los Santos, “MEMS for RF/Microwave Applications The Next

Wave”, Microwave Journal, Vol. 44, No. 3, pp 20 – 41, March 2001. [73] R. J. Richards, H. J. De Los Santos, “MEMS for RF/Microwave Applications The Next

Wave –Part II”, Microwave Journal, Vol. 44, No. 7, pp 142 – 152, July 2001. [74] P. M. Campbell et al., “A Very Wide Bandwidth Digital VCO Using Quadrature Frequency

Multiplication and Division Implemented in ALGaAs/GaAs HBT’s”, IEEE Trans. Very Large Scale Integration System, pp. 52-55, March 1998.

[75] P. Warr et al., “Quadrature Signal Splitting Technique Offering Octave-Band Performance”, accepted to IST2000.

[76] Abidi, “Direct-Conversion Radio Transceivers for Digital Communications”, IEEE Journal Solid-State Circuits, pp. 1399-1410, Dec. 1995.



© 2002, WWRF 136

[77] T. Burger, Q. Q. Huang, "A 13.5mW 185-Msample/s Delta-Sigma Modulator for UMTS/GSM Dual-Standard IF Reception", IEEE Journal of Solid-State Circuits, vol. 36, No.12, pp.1868-1878, Dec. 2001.

[78] Teetzel A., “Circuit Design: Design of a wideband I Q modulator”, 1997 RF Design Seminar, Hewlett Packard Corporation.

[79] http://products.analog.com/products/info.asp?product=AD8347 [80] Razavi B., “Design Considerations for Direct-Conversion Receivers”, IEEE transactions on

Circuits and Systems II: Analog and Digital Signal Processing, Vol. 44, No. 6, June 1997, pp428-435.

[81] Parssinen A., Jussila J., Ryynanen J., Sumanen L Halonen A.I., “A 2-GHz Wide-Band Direct Conversion Receiver for WCDMA Applications”, IEEE journal of Solid –State Circuits Vol. 34, No. 12, December 1999, pp1893-1903.

[82] M Metha et al., “Reconfigurable Terminals: An Overview of Architectural Solutions”, IEEE Communications Magazine, August 2001.

[83] P. R. Chevillat et al., “Hardware Architecture of a Software-Defined Radio fo Mobile Commmuniction Systems beyond 3G”, WWRF, Helsinki, 2001.

[84] P. Jung et al., “Future Microelectronoic Hardware Concepts for Wireless Communication Beyond 3G”, WWRF, Helsinki, 2001.

[85] P . Ting et al., An adaptive Hardware Platform for SDR”, WWRF, Stockholm, 2001. [86] M. Beach et al., “Re-Configurable Terminals Beyond 3G: Re-Configurable Baseband“,

WWRF, Paris, 2001. [87] S. Hsieh et al., “A SDR Transceiver Design with Re-Configurable IF and Basband

Platform“, WWRF, Paris 2001. [88] K. Moessner et al., “Software Radio Integration and Reconfiguration Management”, WWRF,

Paris, 2001. [89] A. Marath et al., “System Level Issues in the Implementation of a Mulimode Terminal

(WCDMA+GSM+802.11a+802.11b WLAN)”, WWRF, Tempe, 2002. [90] T. Rautio et al., “SDR Architecture Design for Future Information Sense Terminals”,

WWRF, Tempe, 2002. [91] L. Kristiansen: TINA-C Service Architecture. Version 5.0. TINA-C, 1997. [92] OMG Telecommunications Specifications: Telecom Service Access & Subscription.

http://www.omg.org/cgi-bin/doc?dtc/2000-10-03 [93] The Parlay Group: http://www.parlay.org, 2002. [94] M. Siebert, “Design of a Generic Protocol Stack for an Adaptive Terminal”, Proc. of the 1st

Karlsruhe Workshop on Software Radios, pp. 31-34, Karlsruhe, Germany, March 2000. [95] M. Siebert, B. Walke, “Design of Generic and Adaptive Protocol Software (DGAPS)”, Proc.

of the Third Generation Wireless and Beyond (3Gwireless '01), San Francisco, US, June 2001.

[96] M. Siebert, M. Steppler, “Software Engineering in the face of 3/4G Mobile Communication Systems”, Proc.of the 10th Aachen Symposium on Signal Theory, ISBN 3-8007-2610-6, pp. 89-94, Aachen, Germany, September 2001.

[97] K. Moessner “Reconfigureable Mobile Communication Networks”, Doctoral Thesis, University of Surrey, UK, 2001.

[98] J. Mitola, “Software Radio Architecture Object-Oriented Approaches to Wireless Systems Engineering”, Wiley-Interscience, ISBN 0-471-38492-5, 2000.

http://products.analog.com/products/info.asp?product=AD8347

http://www.omg.org/cgi-bin/doc?dtc/2000-10-03

http://www.parlay.org/



© 2002, WWRF 137

[99] 3GPP TS 25.322, RLC protocol specification, ftp://ftp.3gpp.org/specs/latest/Rel-4/25_series/25322-430.zip.

[100] Joachim Sachs, Andreas Schieder, “Generic Link Layer”, Wireless World Research Forum, Tempe, USA, March 7-8 2002

[101] "Request For Proposal PIM and PSM for SWRADIO Components", Object Management Group Document swradio/02-06-02, http://cgi.omg.org/cgi-bin/doc?swradio/02-06-02 .

[102] Sun Microsystems: Mobile Information Device Profile (JSR-37), JCP Specification, Java2 Platform, Micro Edition, 1.0, September 2000.

[103] Sun Microsystems: Mobile Information Device Profile, v2.0 (JSR-118), Public Draft Specification, Java2 Platform, Micro Edition, 2002.

[104] R. Hirschfeld, W. Kellerer, C. Prehofer, H. Berndt: An Integrated System Concept for Fourth Generation Mobile Communication. Eurescom Summit 2002, to appear.

[105] An Architecture Supporting Adaptation and Evolution in Fourth Generation Mobile Communication Systems, Robert Hirschfeld, Wolfgang Kellerer, Christian Prehofer, K. Kawamura, Hendrik Berndt, submitted

[106] A. T. Campbell, M. E. Kounavis, and R. R.-F. Liao: Programmable Mobile Networks. Computer Networks, Vol. 31, No. 7, pg. 741-765, April 1999.

[107] H. Harada, Y. Kamio, M. Fujise, Multimode Software Radio System by Parameter Controlled and Telecommunication Component Block Embedded Digital Signal Processing Hardware, IEICE Trans. on Communications, vol..E83-B, no.6, pp.1217.

[108] J. Pereira, Re-Defining Software (Defined) Radio: Re-Configurable Radio Systems and Networks, IEICE Transactions on Communications, vol. E83-B, no. 6 pp. 1174, 2000.

ftp://ftp.3gpp.org/specs/latest/Rel-4/25_series/25322-430.zip

ftp://ftp.3gpp.org/specs/latest/Rel-4/25_series/25322-430.zip

http://cgi.omg.org/cgi-bin/doc?swradio/02-06-02



© 2002, WWRF 138

99 AAppppeennddiixxeess

9.1 Appendix 1: Coupling Methods Open Coupling Scenario The term “Open coupling” wants to indicate that there is no a real integration effort between two or more access technologies. In fact in this scenario, two access networks, for example WLAN and UMTS, a Billing system is shared between them. It means that separate authentication procedures are used (i.e. SIM based authentication for 3G system and simply user name and password for WLAN) and a common database system is used for handle the billing between the different technologies.

Figure 52: Open coupling Scenario between WLAN and UMTS

Loose Coupling Scenario

Taking as reference the [ETSI TR 101 957 (v1.1.1 2001-08) technical Report], loose coupling is defined as utilization of a generic RAT as an access network complementary to current 3G access networks, utilizing the subscriber databases but without any user plane Iu interface, i.e. avoiding the SGSN, GGSN nodes. The operator will still be able to utilize the same subscriber database for existing 3G clients and new RATs clients, allowing centralized billing and maintenance for different technologies. One of the consequences of this kind of coupling is that the service in progress, is dropped during the switch between the two RATs because there is no a real integration between different RATs except for the sharing of the subscriber database. For the software download scenario, it means that it is not possible to maintain the download of the software when the terminal changes type of coverage. For the loose coupling scenario, the core network coordinates sub-networks during the interworking.



© 2002, WWRF 139

For the authentication and billing, one customer database and procedure is used, and a new link between the wISP and the 3G-core network is provided and need to be standardized (AAA-HLR link). It means that the user has to perform an unique subscription if the network provider is the same for both network, or alternatively, the user has to perform an unique subscription to a certain service that will be available for both access networks.

Figure 53: Loose Coupling Scenario between WLAN and UMTS

Tight Coupling Scenario In the tight coupling, the generic RAT network is connected to the rest of the core of the UMTS network in the same manner as an UMTS radio access sub network (UTRAN). One of the most relevant aspects is that the tight coupling interworking requires the definition of the Iu interface between different radio access technologies and that the vertical handover can be supported. In this scenario the interworking between different RATs is performed at SGSN level In the tight coupling scenario, the interface between different radio access networks is located in the Core network (i.e. SGSN) and the vertical handover is also managed at that level.



© 2002, WWRF 140

Figure 54: Tight Coupling Scenario between WLAN and UMTS

Tighter (Very Tight) Coupling Scenario This scenario is similar to the tight coupling one, however WLAN is viewed as a cell managed at the RNC, i.e. WLAN became a part of the UMTS. In tighter (very tight) coupling scenarios the RAN (RNC) itself manages the intersystem handover this will insure seamless handover but additional standardization effort is needed. In the case of handover between WLAN and UMTS, WLAN access is similar to UTRAN [ETSI DTSI/BRAN-0020003-2v0.c]

Figure 55, Tighter Coupling Scenario between WLAN and UMTS



© 2002, WWRF 141

9.2 Appendix 2: Profile Location in Different Coupling Scenarios Two solutions: 1. In pure loose or tight-coupled networks, terminal (and user/service) profile data are ONLY

stored in SGSN/MS SRM level (CN) and the measurements are forwarded to the involved radio sub-networks represented by the RNC’s or access point where radio resource control (RRC) is terminated. The admission control in the new RNC for the new radio sub-network is consulted and if it is admittable (e.g. at low network load), the vertical handover decision is made in the CN according to terminal capabilities (also user/service profile). It is important that a database in CN (e.g. SGSN) level stores the table of network topology in order to route measurement reports from legacy RNCs (2G, 3G) not capable for processing a new radio interface in a hybrid coupled network scenarios to new RAT’s (e.g. 4G).

2. In pure very tight or hybrid coupled radio sub-networks, the terminal (user/service) profile data must be transferred from the SGSN in the core network to the RNC’s or PRM (co-located with RNC), when a fast vertical handover between RAT1 and RAT2 is to be made. In the very tight coupling case, RNC must fast access to user/service profile and the corresponding terminal profile in order to carry out a fast vertical handover.

The first scenario doesn’t support fast handover, simultaneous connection and Joint Radio Resources Management. In the second scenario a support of all needed functionality for fast handover, all system load reduction especially the load reduction for interference limited system when JRRM is considered and support of simultaneous connection is for seen when this scenario is implemented. The figure below illustrates the hybrid coupling.

4G-RNC

GGSN

SGSN SGSNSGSN

RAT1, RAT2

RAT3, 4RAT3, 4

Tight Coupling between RAT1,2 and RAT3,4

3G-RNC

RAT1, RAT2

RAT3, 4RAT1, RAT2

Tighter Coupling for RAT1,2

Tighter Coupling for RAT3,4

Monitored RAT, a potential RAT to access to

Figure 56: Interworking of different RAT’s, Hybrid Coupling



© 2002, WWRF 142

9.3 Appendix 3: Mobility Management One of the open points is regarding the mobility management according with the PRM distribution in the network. In fact, the location of the SDRC in the RAN gives several advantages in the management of the handover, in the fast performing of the reconfiguration process, but, on the other side, open some issues in the management of the micro and macro mobility. In the following section, some general concepts and possible problems about the mobility will be provided. Mobility Scenario In present day cellular network, node and user mobility are handled mainly by means of forwarding. Thus when a user circulates outside his home network any calls directed to him will be forwarded to the visiting network via his home network. The PRM can give support in this mechanism of mobility management, in particular in the management of the micro mobility. The most widely known of Mobility Management protocol is certainly Mobile IP [“IP Mobility Support”, C. Perkins, Internet RFC 2002, October 2002]. Unfortunately, this protocol suffers for many weaknesses when the mobility doesn’t imply the change of IP address, as can happen inside a RAN. For this reason the mobility concept is split in Macro Mobility and Micro Mobility. To better understand the meaning of these terms, some terminology has to be introduced. If we define domain a large wireless access network under a single administrative authority including more than one base station (BS), we can define macro mobility when the terminal moves from one domain t an other, and we can define micro mobility when the terminal moves from one base station from an other inside the sae domain. A station performing special tasks in the mobility management is called Mobility Agent (MA).In such context, we can take as reference the following scenario:

Figure 20: Mobility Scenario



© 2002, WWRF 143

Macro Mobility Management To handle Macro Mobility situations, Mobile IP is currently the best solution. Mobile IP provides roaming capability to users by utilising agents in each domain. When a mobile host visits a foreign network, a temporary address (care-of address) is given to the host. This is used to receive IP traffic in the foreign domain. An agent in each foreign network (the foreign agent) handles the registration of visiting hosts. Registration is accomplished by using an agent that resides in the host’s home domain (the home agent). This binds the users’ real IP address with the temporary IP care-of address. Any traffic bound for the roaming host is then forwarded by the home agent to the correct foreign network. A route optimisation option for Mobile IP allows roaming hosts and corresponding IP hosts to bypass the home agent. In the new version of the Internet Protocol (IPv6), a foreign agent is no longer needed because the network assign automatically the new address and the terminal is able to understand that it is attached to a foreign network. Then the terminal sends a binding packet to the home agent (located in the home network). When a terminal wants to contact it, the home agent is involved only the first time because the terminal called inform the caller of the new IP address ( the IP address assigned by the foreign network. The Proxy could support this mechanism, implementing some functionality that permit to act as MIP client on behalf of a terminal if the radio link doesn’t support IP protocol (i.e GSM terminal). This concept is called Virtual Mobile Host (VMH) and is particular useful for supporting pure Rel ’99 CS terminals where MIP cannot be supported on the terminal. An other way to manage macro mobility is provided by the application level protocol SIP. The Session Initiation Protocol (SIP) is an emerging protocol, designed to provide basic call control and application-layer signalling for voice and multimedia sessions in a packet-switched network. SIP is able to provide session management, personal, as well as, service mobility. Some SIP extensions have been proposed to extend the protocol in order to support also terminal mobility, resolving some of the problems associated with Mobile IP. Even if there are not constraints, usally SIP is used over UDP so it is indicated for real-time communications. Therefore the best solution would be a hybrid scheme (SIP for real-time and Mobile IP for non-real-time mobile communications) based on a policy table. Micro Mobility Management Mobile IP suffers from several well-known weaknesses that have led to the definition of the macro/micro mobility architecture: • Latency and control traffic: in Mobile IP, the basic mobility management procedure is the

registration to the HA each time the mobile changes of network and it can take a very long time. In the case of a quickly moving mobile, which rapidly changes of network, the registration process will become totally inefficient.

• Address space: Mobile IP requires the availability of an entire pool of valid addresses to serve as care of address (COA) in each domain. Unfortunately, the IPv4 address space has now reached its limits. This has partly led to the definition of IPv6 but we can expect that IPv4 will remain used for many years.



© 2002, WWRF 144

• Quality of Service: frequent changes of point of attachment and of COA make difficult to

support Quality of Service for mobile users. As explained above, Mobile IP has some weaknesses that had led to the different vision Macro/Micro Mobility. Foloowing the consideration above, the management of the mobility can be performed by Mobile IP in Macro mobility situation (with possible support of SIP), while, in Micro mobility situation, new candidates have to be found. At present, the most plausible candidates are: • Hierarchical Mobile IP [Hierarchical MIPv6 mobility management (HMIPv6)” Internet

draft, “draft-ietf-mobileip-hmipv6-06.txt” July 2002]: this protocol is built on top of Mobile IP and separate local mobility (within a site) from global mobility (across site) management. Local handoffs are managed locally and transparently to the mobile node’correspondent hosts while global mobility is managed with Mobile IP. To achieve this mechanism a new network element is defined, namely MAP (Mobility Anchor Point). Mobile Node uses MAP as care of address, during the movements inside a MAP domain. Every terminal receives an IP address from a MAP and every packet addressed to a particular user is forwarded by the MAP itself until the terminal remains under a particular MAP domain, holding the same care of address and without the needing to inform the home network.

• Cellular IP [Internet draft, “draft-ietf-mobileip-cellularip-00.txt”, January 2000]: this protocol relies on Mobile IP for the macro mobility management, while for local mobility uses a very specialized Agent acts as gateway towards the Internet and as Mobile IP Foreign Agent. Mobile user connected to the network uses the IP of the gateway as care of address. The Uplink packets are routed from the mobile node to the gateway by a hop by hop way: the path information are stored on the nodes met during the transmission and these information are used by the downlink packets to reach the mobile node. To achieve this mechanism, each node maintains a routing cache that is periodically updated by beacon packets sent by the gateway or by route update packets sent by the Mobile node when it connects to the network or changes the point of attachment (handover). Cellular IP manages the handover by two different modes: hard handoff and semi-soft handoff. The hard handoff provides no guarantees while the semi-soft handoff ensures that the packet losses will be very reduced.

• HAWAII [Internet draft, “draft-ietf-mobileip-hawaii-00.txt”, June 1999]: this protocol is similar to Cellular IP. In fact it is a micro mobility protocol relying on Mobile IP for the macro mobility and organizes the network as a tree with a single gateway (Domain Root Router) located at the root of the tree. The mobility is managed by the creation of special paths between the gateway and the terminal and the maintaining of such paths is possible by control messages sent by radio stations them self. HAWAII defines two different handover mechanisms adapted to different radio access technologies. These two mechanisms present different properties and can be chosen to optimize the network with respect to packet losses, handoff latency or packet reordering.



© 2002, WWRF 145

9.4 Appendix 4: Mass Up-grade Multicast Flow The Figure 57 shows an example of the delivery of a mass upgrade. The terminals are registered with their profile at the PRMs. The PRMs have joined the appropriate multicast groups and are now able to receive mass upgrades. Now the server of terminal type A manufacturer initiates the mass upgrade, sending the software to the multicast address. The multicast routers in the Internet Backbone are forwarding the packets along the multicast delivery tree. The PRMs as leafs of the tree are receiving the update and transmit it to the terminals of the appropriate type.

SRM

PRM

SRM

PRM PRM

SRM

PRM PRM PRM

PRM

TerminalType B Terminal

Type A

TerminalTyp B

TerminalType A

Internet Backbone

ManufacturerType A Server

TRSA TRSA

TRSA

Figure 57: Example of a Mass Reconfiguration Process Initiated by an External Server with the Use of IP

Multicast



© 2002, WWRF 146

9.5 Appendix 5: Signalling between Network Entities for Terminal Reconfiguration

In this section the control signalling to enable a fast and efficient reconfiguration of the terminal between the different entities is shown. Mode Switching Signalling The mode switching signalling between a terminal and its current PRM is shown in Figure 58, assuming that the terminal informs the PRM about its capabilities and requirements and that the PRM is already informed about the general QoS in neighbouring radio access networks. 1. The terminal requests the available neighbouring modes from his PRM. Included in the

request is a profile with current terminal, application and user requirements. The PRM compares the transmitted requirements with the general QoS in the neighbouring networks and determines all useful modes (i.e. GSM is not a useful mode, if there is a video-conference application active on the terminal). The results of this determination and some additional information are responded to the terminal.

2. The terminal scans for the different possible modes. If the signal quality of another mode is promising, the terminal requests some short-term information about this mode from his PRM (PRM 1). The PRM 1 contacts via the Inter-PRM-Interface the neighbouring PRM (PRM 2), managing the detected mode, and requests the desired short-term information. The PRM 2 delivers the information to the PRM 1 and the PRM 1 forwards this information to the terminal.

3. Optional: The PRM 1 could try to estimate with the help of the profile from the terminal and the received short-term information, if the terminal will initiate a mode switch or not. If PRM 1 comes to the conclusion, that the terminal will perform a mode switch, PRM 1 checks, if the necessary files for the terminal are already in the local cache. If not, PRM 1 requests them in advance at PRM 2. PRM 2 has them available in its local radio access network dependent storage and delivers them to PRM 1.

4. If the terminal decides to switch the mode, it sends a message to the PRM with the request to transfer the appropriate files for the reconfiguration process. PRM 1 checks, if the necessary files for the terminal are already in the local cache. If not, PRM 1 requests them at PRM 2. PRM 2 has them available in its local radio access network dependent storage and delivers them to PRM 1 and PRM 1 forwards them to the terminal. The terminal reconfigures its hardware and switches to the new mode. PRM 1 finally forwards the stored terminal profile to the PRM 2.



© 2002, WWRF 147

Terminal PRM 1 PRM 2

Request Available Modes(Terminal profile included)

Check for useful mode

Response Available Modes(Long-term info included)

Scan for alternative mode

Promising mode detected

Request Short-term Information

Request Short-term Information

Response Short-term Information

Response Short-term Information

Decision for mode switching

Request Reconfiguration Software

Download Reconfiguration Software

Estimate probability for mode switching decision





Mode switching

Forward Terminal Profile

Check cache for software


1.

2.

3.

4.

Figure 58: Signalling between the Terminal, the current PRM (PRM 1) and

the new PRM (PRM 2) in the Mode Switching Case



© 2002, WWRF 148

Application/Driver Update Signalling In Figure 59 the signalling in a terminal initiated software update process is presented.

Terminal PRM SRM

Request Software Update


Response Software Update

1.

2.

Server


Search in database


Store update in database


Put update in cache


Check priority of update request

3.

4.

5.

6.



Schedule download

Figure 59: Signalling between Reconfiguration Network Entities

during Application Update Process



© 2002, WWRF 149

1. The terminal needs an update of an application or a new driver version and sends a request

directed to the server providing the desired software module. A priority indication is included in the request, to describe the urgency of the update.

2. All requests from the terminal cross the local PRM. The PRM checks, if the requested file is already stored in the local cache. If it is available, the request is no further forwarded and the desired update is transmitted out of the cache to the terminal. Otherwise the PRM forwards the request to the corresponding SRM over the PRM-SRM interface.

3. If the request reaches the SRM, the SRM looks into its database if the module is stored. If this is the case, the SRM sends the module to the PRM and from here the module is forwarded to the terminal. If the module is not stored in the SRMs database, the request is after all forwarded to the server.

4. The server receives the request for the software update, gets the module out of his database and delivers it in the direction of the terminal.

5. Now the update packets cross the SRM. Because the files are not yet in the local database of the SRM, the SRM stores and forwards them to the PRM.

6. The PRM put the update module in its local cache. Now the priority indication of the initial request is taken into account. If there is a high priority and/or the network load is low, the packets should be forwarded to the terminal immediately. If, on the other hand, the priority is low and the network load is high, the delivery to the terminal should be scheduled.

Network Initiated Update The network initiated reconfiguration procedure of the presented architecture requires multicast functionality in the radio access networks and backbone as well. The necessary message exchange between the architectural components before and during a mass upgrade process is shown in Figure 61. 1. The terminal announces a terminal profile describing the reconfigurable software and

hardware components of the terminal. 2. The PRM joins for every manufacturer a multicast group and sends therefore IGMP join

group messages to the SRM, who is the next multicast router. The SRM forwards these messages to its next multicast router.

3. If the manufacturer server initiates a mass upgrade, the data packets are delivered per multicast to the recipients. In addition the update is marked by a priority parameter similar to the one in the terminal initiated case.

4. If the multicast packets arrive at the SRM, the SRM stores the update in its database and forwards it according to its multicast router functionality to the PRMs.

5. The PRM puts the update file in its local cache. In the next step the PRM compares the available resources on the radio interface and the priority parameter of the update massage. In dependence on the result, the PRM can schedule the download. For the delivery of the update on the radio interface the PRM can make use of a broadcast transmission to use the available resources more efficient, if more than one terminal in a cell is concerned.



© 2002, WWRF 150

Terminal PRM SRM

Announce Terminal Profile

Join multicast groups

Multicast Upgrade

1.

2.

Server

IGMP Group Join

Initiate mass upgrade

IGMP Group Join

Store update in database

Multicast Upgrade

Put update in cache

Check priority of update request

3.

4.

5.

Deliver Software Update

Schedule download

Figure 60: Signalling in Case of a Mass Upgrade, Initiated by a Manufacturers Server

Notification or Reconfiguration to the Server Application For all-IP networks, TCP should most likely be the transport protocol used for reliable connections. For an SDR terminal, the handover delay also needs to include the reconfiguration time. This extra delay increases the probability of losing packets in the reconfiguration process. If the disconnection time is big and the user is involved in an active session, the application can be adversely affected if it is not accordingly notified of the cause of the disconnection. Some applications using TCP in their transport protocol or some TCP-friendly applications might react with retransmission time-outs or reducing the sending rate as a result of this lack of connection. This reduces the performance obtained by the terminal considerably, specially if relative frequent reconfigurations and vertical handovers take place the obtained throughput might get degraded quite heavily.



© 2002, WWRF 151

The common trend for new access networks is the continuous provision of higher data rates. This is also a factor to be considered if the terminal does not have any connection during reconfiguration and handover, since the amount of data is proportional to the data rate offered by the access network. Having 1 second disruption might suppose losses of some few kilobits (9.6) for current GSM networks, however, for UMTS for the same period some data losses of several hundreds of kilobits or even more (theoretically up to 2 Megabits) might occur. If the server is notified about the terminal disconnection, it can pause the transmission and freeze the transmission state, once the terminal registers in the new network the download can be resumed. By doing this, the probability of packet losses gets reduced. The proposal is shown in Figure 61.

PRM2 Server

Forward buffered packets

Pause Download

Pause Download

Continue Download

Continue Download

Forward buffered packets

Continue Download

Software Download


PRM1

Buffer packets from server (sent before the pause signal arrived)





Terminal

Decission for reconfiguration

Mode switching

2.

3.

4.

1.

Figure 61: Signalling between Terminal, current and new PRM and Server in order to enhance Software

Download Process



© 2002, WWRF 152

1. In a first state, the terminal is performing a download from a server. This software is not required for the forthcoming mode switching, it might be related to terminal reconfiguration, for example downloading a new application or an update, but it could also be any kind of download, e.g. downloading a file from the internet, or in general for any connection using TCP protocol in the transport layer.

2. Before finalising the software download, the terminal needs to reconfigure to another mode. For this purpose it contacts its PRM for the download of the reconfiguration software. The PRM obtains the required software on behalf of the terminal. The terminal then downloads the modules from the PRM. This step does not have any influence on the described mechanism. If the terminal already had the required software for the reconfiguration, this step is not required, but the idea is still valid.

3. Before carrying out the reconfiguration and handover, the terminal sends the pause signal to the server via the PRM. Due to the transmission delay, it is most likely that some data packets have left the server before the pause signal arrives. Since the terminal is performing the reconfiguration process it is not able to receive them. The PRM is then in charge to collect this packets and store them.

4. The PRM can forward the buffered packets as part of the context transfer to the new PRM. Once the terminal has been reconfigured and correctly registered, it can received the missing packets from the new PRM and notify the server in order to continuing the download. This way, packet losses or unnecessary retransmissions and their consequences in terms lower throughput are avoided.



© 2002, WWRF 153

9.6 Appendix 6: Amplifier Linearisation Schemes Introduction It is the intention of this section of the White Paper to outline some enabling technologies that will be useful for the hardware realisation of a SDR transceiver. Specifically, this section of the paper addresses linearisation techniques for amplifiers and mixers. Flexible filtering techniques are also covered. An attempt has been made the highlight the deficiencies in existing techniques, and to flag research requirements.

Amplifier Linearisation Schemes: Feedback Feedforward and Predistortion based There is a large body of published work on power amplifier linearisation techniques. There are four major techniques used. These techniques are “Cartesian Feedback”, “Feedforward Cancellation”, “Predistortion” and “Envelope Elimination and Restoration”. Cartesian Feedback

A Cartesian feedback stage is shown in Figure 64. The operation of this circuit is comparatively straightforward. The feedback comparison is done at baseband, in both the I and Q channels, with a complex signal. Feedback sampling is done at RF with a real signal. The problem with this technique is essentially the same problem that occurs with any negative feedback system. The bandwidth over which the phase shift of the loop gain remains significantly less than 180°, and the loop is stable, is limited. Cartesian feedback is thus a narrowband linearisation technique. Bandwidths of the order of 100kHz have been reported for Cartesian loop systems.

DSP

Coupler

Splitter

HPA

Channel Synthesiser

Non Linear poweramplifier

Summer

I DAC

DAC

−

−+

+

°90

°90

Attenuator

Ifb

I

Q

Q

Qfb

Analogue signal processing amplifiers

Figure 62: Cartesian Feedback Used to Linearise a PA



© 2002, WWRF 154

Research Issues

Bandwidth, • • Loop Stability.

Feedforward Linearisation

For wide band9 linearisation, feedforward can be used. With this technique a replica of the distortion components is obtained by subtracting the distorted output of the main PA from the wanted signal. The distortion components are then amplified and subtracted from the output of the PA. An undistorted output is therefore produced. This process is illustrated in Figure 63. The process requires accurate delay matching between the signal cancellation and the error cancellation loops, if wideband operation is required. The drawbacks with this technique are the loss of efficiency due to power loss in the error amplifier, and the signal splitting that occurs at the output of the PA.

1T

2T

Splitter

Variabletime delay

Splitter

Combiner

Combiner

1G

2G

Variabletime delay

Main PA

Erroramplifier

Attenuator Subtract

Subtract

replica ofwanted signal

replica of distortioncomponents

Amplified signal plusdistortion components

amplified replica ofdistortion components

Input 2 tonetest signal

Figure 63: Feedforward Distortion Cancellation

Research Issues

• • •

Power efficiency, Adaptability to changing conditions, Application over very wide bands.

9 Bandwidths of the order of 30MHz have been achieved with this system.



© 2002, WWRF 155

Predistorsion

Predistortion is a broadband technique10 used to linearise PAs. Essentially a network with complementary distortion characteristics to the main PA is placed before the PA. The required complementary characteristics can be generated at baseband or RF and be implemented by analogue or digital circuits (although digital implementation is obviously more suited to baseband implementation). This technique operates open loop, so the non-linear characteristics of the PA must be known in advance if accurate mapping of the predistortion to the PA is to be achieved. Research Issues

Adaptability to changing conditions, • • Application over very wide bands.

Predistorter P.A.

inv pdv outv

outv

pdv

pdv

invinv

outv

Figure 64: Linearisation using Predistortion

Amplifier Linearisation Schemes: Envelope Separation Based

One possible way of designing an amplifier which combines the advantage of being power efficient, whilst being at the same time linear, is to separate the signal into parts where the amplitude varies, and parts where the amplitude is constant. The constant amplitude component is amplified in a highly efficient non-linear amplifier, and the variable amplitude component is amplified in a linear amplifier. The next three sections describe amplifier linearisation techniques that utilise this principle. As it turns out, the amplitude fluctuations can be represented by phase changes of two component signals. The required amplitude changes can be achieved using a Voltage Controlled Oscillator (VCO). LINC and CALLUM make use of this

10 Bandwidths of the order of 100MHz have been achieved with analogue predistortion. This reduces to about 100kHz using digital predistortion.



© 2002, WWRF 156

1) Amplifier Linearisation Schemes: Envelope Separation Based

Originated by Kahn [3] in the 1950s for application to SSB transmission, where information is carried in both amplitude and phase, the technique is applicable to all linear modulation. Figure 65 shows the system. The low-power modulated signal at RF is sampled and this sample is used to derive a low frequency control signal that, after amplification in a video amplifier, directly modulates the high power RF signal. The incident RF signal is “limited” so that the RF power amplifier sees only phase variation, thus any AM-PM distortion in the non-linear power device is eliminated.

VideoAmplifier

High powerRF Signal

Limiter MixerPowerAmplifier

Tap

Envelope detector

Low powerRF Signal

Figure 65: Envelope Elimination and Restoration

2) LINC – Linear Amplification with Non-linear Components

The LINC and CALLUM transmitter architectures are based on a technique dating back to the 1930’s [4]. In general terms, a number of constant-envelope phase varying phasors are generated and combined in order to form an envelope-varying signal. A significant amount of gain can be applied to each individual phasor via an efficient non-linear process, as no in-band distortion will be generated. Both of these architectures are useful for linear transmitters, as the frequency up-conversion process is inherent within the design. The LINC system is shown in Figure 66. The input may be in the form of polar or rectangular specified baseband data. This data is converted into a pair (potentially more) of phase varying phasors of constant amplitude. The information content is unchanged during this process, however, the redundancy of two power amplifiers can be employed to exploit non-linear efficient operation. VCOs are shown in Figure 66, which translate the information to the carrier frequency.



© 2002, WWRF 157

In some realisations of this technique, direct phasors are generated within the DSP and analogue mixers are used to perform the frequency translation. Here, the local oscillator power may be kept low. The instantaneous magnitude of the combined output of the two power amplifiers is a function of the difference in phasor angle. The instantaneous phase of the combined output of the two power amplifiers is a function of the absolute phase of the two phasors.

G

G

DSP

Dualphasor

Generation

VCOs@ CarrierFrequency

PowerAmplifiers

Figure 66: LINC Linear Transmitter Architecture

LINC is an open loop system and consequently it suffers from the lack of adaptability to changing conditions, which this type of system exhibits. Additionally, the DC-RF efficiency of this technique is limited by the use of signal cancellation in the output coupler to form low magnitude signals. Under such circumstances, most of the generated power is dissipated within the fourth port of the combiner (which may be virtual). The LINC technique has been superseded to some degree by CALLUM. 3) CALLUM – Combined Analogue Locked Loop Universal Modulator

The open loop problems of LINC, are resolved in CALLUM [6] [7]. where any imbalances between the two analogue chains are continually compensated. The bandwidth of operation of this scheme is limited by the relatively high-gain control loop. The comparison process operates in quadrature components, limiting the input format to I and Q. There are several extensions to this scheme, resulting in CALLUM1 and CALLUM2. These extensions to the basic operating principle are based around the requirements of system stability, reduced complexity, and useable bandwidth. Research Issues

• Efficiency of power combining networks.



© 2002, WWRF 158

Non-linearamplifier

Combined frequency translation and separation of components

VCOI+_

∑

sin( ωct)

Q

Non-linearamplifier

VCO

cos( ωct)

+

_

Figure 67: CALLUM Linear Transmitter Architecture

Mixer Linearization The inherent nonlinearity of mixers is particularly acute in SDR applications. Here, the broadband receiver frontend ‘sees’ not only the wanted channel, but also a number of nearby signals. A non-linear mixer will downconvert all of these received channels together with the wanted channel to IF. During this frequency translation process inband interference caused by the nearby signals will be added to the wanted channel, making it potentially more difficult or even impossible for the receiver to correctly detect the wanted signal. This places demanding filtering requirements on a broadband receiver frontend to reject the out-of-band unwanted channels (blockers) entering the mixer. Filtering-out strong interfering nearby channels at high RF frequencies is difficult. In a traditional radio application, the frequency of transmission and reception will be fixed and the filter parameters will be set only for these known frequencies. This is incompatible with the SDR concept and filtering-out the blockers of multiple standards will be a challenging task for RF designer, thus making a linear mixer for a SDR frontend an attractive proposition. Available mixer linearisation techniques were investigated. It is found that, these techniques are unable to simultaneously offer a large dynamic range, low noise performance and suppress intermodulation distortion (IMD). A new technique using “frequency retranslation” was proposed ([54], [55]) in order to overcome these shortcomings.



© 2002, WWRF 159

The system has been developed and a prototype demonstrator was constructed as a receiver downconverting RF to IF (see Figure 68). This technique frequency translates the distorted IF output back to RF and generates an error signal to predistort the input of the nonlinear mixer.

DownconvertingMixer

UpconvertingMixer

LO

RF

RF

RF

IF

IFRFRF

_ +

e

IF

RF

Figure 68 The Block Diagram of the Proposed Technique Applied as a Receiver

Measured results indicate an impressive 33dB suppression of third-order IMD (IM3), whilst at the same time the noise floor is not effected. This improvement corresponds to about 16dB improvement of output TOI and dynamic range. The same prototype was also tested with a TETRA π/4-DQPSK signal and a 22dB improvement in adjacent channel interference (ACI) was measured. Research Issues

Improved linearisation bandwidth and dynamic range, Adaptive control scheme for practical application of the technique.

Image Signals and Variable Preselect Filters Image signals are a problem that must be dealt with if a superhetrodyne receiver is being employed. One possible way of achieving this is to make use of a variable preselect filter. An image reject filter will always operate at RF, therefore, the option for the design of a flexible preselect filter is at present limited to realisation as either a distributed component design or as a MMIC. There have been a few variable MMIC filter designs reported in the literature, notably that of Katzin et al. [56]. The device described in this technical paper was produced as a prototype MMIC for the Hittite Corporation. Two versions were produced, both exhibiting ~100MHz bandwidth. One had a centre frequency that could be swept from 1,500 to 2,000MHz, and the other a centre frequency sweepable from 1,980 to 2,650MHz. The filter unfortunately never progressed beyond the prototype stage, due to lack of sufficient dynamic range [57].



© 2002, WWRF 160

Non linearity is introduced into MMIC designs from two sources. Firstly it occurs because a varactor is often used to tune the filter. Secondly, a nonlinear active device is often used to compensate losses in MMIC filter components11. There are several classic types of distributed component microwave filters. If we restrict consideration to those filters, which could conceivably be realised in microstrip, or similar, technology, then we are left with the following list:

• End coupled microstrip, • Edge coupled microstrip with open circuit or short circuit termination, • Interdigital microstrip, • Combline microstrip, • Hairpin microstrip.

Most of these filter architectures were developed in the late 50s early 60s [58] [59]. All of these filter architectures are designed for a fixed centre frequency, fixed bandwidth application; the question thus remains as to how they might be electronically tuned. A number of suggestions are listed below:

• Varactor diode tuning at some strategic point on the filter structure, • Constructing the filter on a substrate, whose dielectric constant could be electrically

varied, • Switching parts of the transmission line so that the physical characteristics of the filter

structure could be changed. Varactor diode tuning has been investigated with Combline filters [60]. Filter designs are reported in which the centre frequency can be swept from 3,200MHz to 4,800MHz with a bandwidth of about 200MHz. Reported insertion loss for such a filter is of the order of 5dB. Such a filter structure is likely to exhibit distortion problems, because of the presence of the non-linear, varactor, diodes. It would be possible to sweep the filter characteristic by sweeping the effective dielectric constant of the substrate. As the electrical length of a transmission line is inversely proportional to the square root of the dielectric constant, this will cause the centre frequency of the filter to vary. The substrate would allow the dielectric constant to change, in response to variation in an electrical bias. Such a substrate material has been developed by a research laboratory in the UK. This technology has been subsequently sold on to a third party, and its commercial future is presently uncertain.

11 By introducing, for example, negative resistance across an inductor.



© 2002, WWRF 161

Switching the component parts of a filter, in and out of circuit, using Micro-Electro-Mechanical Structures (MEMS) seems to offer an alternative solution [61]. The use of Electro-mechanical switches will mean that the filter is composed entirely of linear components, and therefore the dynamic range of the filter should not be prejudiced. The major problem with electrically switching a filter is to preserve the filter geometry as the centre frequency is translated, whilst at the same time utilising an essentially simple switching arrangement. Structures, such as edge coupled lines, or inter-digitised filters, have geometry problems as switching extends line lengths. At the time of writing, the simplest arrangement for tuning the filter characteristic would appear to be some form of slow wave filter. A slow wave filter has capacitive loading at each end of a short transmission line. The modified hairpin structure shown in Figure 69 is a member of this family (see [62]). This filter has a coupled line, which loads the top of the hairpin and forms part of the filter resonator. Interstage transformer action is bought about by edge coupling of the “U shaped” structures that make up the resonators. Tuning of this filter using MEMS can potentially be achieved by shortening the top loading coupled line via the use of a MEMS based switching arrangement.

Transmissionline

inter-stagecoupling

Open circuit coupled lines providecapacitive loading for the end of the

transmission line.input/

output tap

Figure 69: Modified Hairpin Filter Structure



© 2002, WWRF 162

Appendix 6 References [1] S. Mann, M. A. Beach, P. A. Warr and J. P McGeehan, “Increasing the talk-time of mobile

radios with efficient linear transmitter architectures,” IEE Electronics & Communication Engineering Journal, Vol. 13, No 2, pp., 65-76, April 2001.

[2] P. A. Warr, M. A. Beach and J. P. McGeehan, “Gain-element transfer response control for octave-band feedforward amplifiers,” IEE Electronics Letters, Vol. 37, No. 3, pp., 146-147, 1st February 2001.

[3] L.R. Kahn, “Single Sideband Transmission by Envelope Elimination and Restoration”, IRE Proceedings, Vol. 40, July 1952, pp. 803-806

[4] H. Chireix, “High Power Outphasing Modulation”, IRE Proceedings, Vol. 23, No. 11, November 1935, pp.1370-1392.

[5] S. A. Hetzel, A. Bateman, and J.P. McGeehan, A LINC Transmitter, 42nd IEEE Vehicular Technologies Conference, Denver, May 1992, pp. 759-753.

[6] D.C. Cox, ‘Linear Amplification with nonlinear components’, IEEE Transactions on Communications, Vol. 22, pp.1942-1945, December 1974.

[7] D.J. Jennings, J.P. McGeehan, ‘A High Efficiency RF Transmitter using VCO-derived Synthesis: CALLUM’, IEEE transactions on microwave theory and techniques, Vol. 47, No. 6, June 1999, pp. 715-721.

[8] T. Nesimoglu and M. A. Beach, “Linearised mixer using frequency retranslation”, UK Patent Application No. 0117801.1, 20th July 2001.

[9] T. Nesimoglu, M. A. Beach, P. A. Warr and J. R. MacLeod, “Linearised Mixer using Frequency Retranslation”, IEE Electronics Letters, Vol. 37, No. 25, pp., 1493-1494, December 2001.



[12] P Katzin, Personal Correspondence, January 2001. [13] G. Matthaei, L. Young, E.M.T. Jones, “Microwave Filters, Impedance-Matching

Networks, and Coupling Structures”, Artech House 1980. [14] R Levy S.B. Cohn “A History of Microwave Filter Research, Design, and Development”,

IEEE Transactions on Microwave Theory and Technique, Vol. MTT-32, No.9, pp1055- 1067, September 1984.

[15] I.C. Hunter and J.D. Rhodes “Electronically Tuneable Microwave Bandpass Filters”, IEEE Transactions on Microwave Theory and Techniques, Vol. MTT-30, No9, pp1354- 1360, September 1982.

[16] R. Y. Loo, G. Tangonan, D. Sivenpiper, J. Schaffner, T.Y. Hsu, H.P. Hsu, “Reconfigurable Antenna Elements using RF MEMS Switches”, Proceedings of ISAP2000, pp 887- 890, Fukuoka, Japan, 2000.

[17] M Sagawa, K Takahashi, M Makimoto. “Miniaturised Hairpin Resonator Filters And Their Application To Receiver Front End MIC’s”, IEEE Transactions on Microwave Theory and Techniques, Vol. 37, No. 1`2, pp1991-1997, December 1989.

Documents

Reconfigurable SDR Equipment and Supporting Networks