作者：陈小凤 王思华　摘自：电子技术应用
%A
%A 　　摘要：介绍了软件无线电系统的开放式软件通信体系结构，提出在可重新配置的硬件平台上建主一种分布式处理环境，运行不同供应商提供的软件组件以支持各种服务，从而达到系统软件的可移植性、重用性和伸缩性。
%A
%A 　　关键词：软件无线电 软件通信结构 CORBA IDL 域描述体
%A
%A 　　伴随蜂窝无线个人通信系统服务的快速发展，产生了很多无线通信标准，如GSM、IS95、IS54/136、PDC等。这些空中接口对不同的应用和服务都有各自约定的波段、调制解调机制、编解码方式、复合接人技术和协议。可以预见，在不久的将来，无线电通信系统必将把各种无线接入网集成到一个通用系统结构中，通过一个硬件平台实现多种标准和服务。二十世纪90年代初开始，无线电的服务正从长期依赖的硬导线连接向软件无线电演进。
%A
%A 　　1 基本思想
%A
%A 　　软件无线电SDR(Software Defined Radio)为以软件方式实现各种空中接口，提供灵活的无线通信方式以便于实现灵活的传输机制、协议和应用。图1所示为多模式(多个性)的SDR系统的功能模块及标准接口点约定，其中无线电节点指基站或移动终端。多模式技术要求可在一个以上的信道RF频带上接人，在图1中为信道集。
%A
%A
%A
%A 　　一个软件定义的个性包括RF频带、信道集、空中接口波形及相关功能。RF／信道接人模块提供多个信号通道及跨越多个RF频段的RF频率变换。IF处理模块包括滤波、进一步频率变换、空／时分集处理、波束成形及相关功能。多模式无线电产生多个空中接口波形，波形在调制解调器模块确定。信息安全(INFOSEC)功能在无线应用中越来越重要，该模块主要实现传输安全、身份认证及保护隐私等功能。调制解调器输出的编码信道比特流在INFOSEC被称为黑色(密文)比特流，经由INFOSEC变换为红色(明文)比特流。然后通过协议栈加以处理，产生网络比特或源比特。网络比特依从网络协议通过网络接口接人到远程源；源比特则通过源解码器接到本地源。图1中发展支持部分的功能是支持软件目标的下载及新技术插入[1]。
%A
%A 　　SDR的基本宗旨是利用数字信号处理技术代替现在主要的模拟信号处理。通过智能天线、宽带RF器件、宽带模数转换器(ADC)及数模转换器(DAC)，利用通用可编程处理器实现IF、基带及比特流处理。因为用可重新编程的软件代替了硬件模拟电路，通过动态分配射频、中频、ADC、DPS硬件和算法，并将软件对象分配到硬件组件中，使得软件无线电可以在线改变自己的特性。支持软件无线电可重新配置的技术有：
%A
%A 　　(1)可通过重载微程序进行重新配置的可编程门阵列(SP?column=news&key=FPGA target=_blank class=qqx_gjz>FPGA)；
%A
%A 　　(2)可通过重载代码在指令存储区进行重新配置的通用处理器。
%A
%A 　　这些软硬相关的微程序和代码的仓库运行在系统某处的通用处理器，它包含带有文件系统访问FPGA和处理器的操作系统。这个通用处理器通常也包含与外部信号处理子系统进行通信的接口，例如用户接口或者临近的监控站。
%A
%A 　　2 SDR的软件通信体系结构
%A
%A 　　军用联合策略无线电系统(JTRS)定义的软件通信体系结构SCA (Software Communication Architecture)规范经历了Steps 2A和Steps2B两期的修正改进。当前版本Version 2．2是2001年11月30日在JTRS网站上发布的，被软件无线电论坛(SDR Forum)作为SDR的标准。
%A
%A 　　SCA不是一个实现方面的结构，而是要建立一种为JTPS软件无线电开发而与实现无关的框架。SCA规范包括一篇阐述软件通信体系结构的主要文档和相关附录文档。附录文档有JTRS定义的应用环境描述体(AEP)以及域描述体(Domain Profile)，描述体包含协议信息。SCA规范的附录文档还包括波形配置的应用程序接口(API)、服务定义API、安全性说明、Rational UML文档，以及配置管理文档。
%A
%A 　　2．1 系统结构
%A
%A
%A
%A 　　图2为SDR系统软件结构和模块接口示意图，其中CORBA ORB & Services模块和Operating System模块使用现有商用产品。该软件结构的特点是：最大程度地利用了商用产品和协议；通过开放式分层结构将核心应用程序和非核心应用程序从底层硬件独立出来；通过通用对象请求代理结构(CORBA)提供了一种分布式处理环境，从而达到软件应用程序的可移植性、重用性和伸缩性。按比特流分段，系统分为黑色总线(密文传输)、信息安全(INFOSEC)和红色总线(明文传输)三个子段。这些子段在物理上是相互隔开的，从而保证黑／红之间的隔离和INFOSEC的完整性。参照OSI的七层模型，系统主要实现物理层、MAC层和部分逻辑链路层的任务，然后通过I／O模块与外界进行数据交互。
%A
%A 　　系统由操作环境(Operating Environment)、应用程序、逻辑设备和通用软件规则构成。OE包括核心框架(CF)、中间件(如CORBA的对象请求代理ORB)和操作系统，其中ORB必须支持minimumCORBA(最小CORBA)规范。CORBA的扩展服务，如命名服务、日志服务、事件服务和标准事件等也作为中间件的一部分。
%A
%A 　　2．2 核心框架IDL与应用程序接口(APl)
%A
%A 　　核心框架CF(Core Framework)由一组开放式软件接口和描述体构成，定义了嵌入式通信系统中的应用程序组件的配置信息、管理机制及相互通信方式。CF接口通过IDL进行定义，分为下面几类：
%A
%A 　　(1)基本应用程序接口，包括端口(Port)、生命周期、属性集、资源工厂和资源等；
%A
%A 　　(2)框架控制接口，包括应用程序、应用程序工厂、域管理器；设备和设备管理器；
%A
%A 　　(3)框架服务接口，包括文件、文件系统、文件管理器。
%A
%A 　　SCA规范的附录C以Rational UML的表达方式详细描述了各类接口之间的关系。这些以IDL定义的接口以及这些接口的继承类也就形成了应用程序的接口(API)，被波形应用程序引用。CF利用CORBA结构进行消息传递。标准的API对于应用程序的灵活使用和设备的替换使用都很重要，同时也可以保证服务提供者和用户无需考虑开发和使用时操作环境(OE)和编程语言的不同。
%A
%A 　　2．3 应用程序环境描述体 (Application EnvironmentProfile)
%A
%A 　　SCA应用程序环境描述体(AEP)基于POSIX实时应用程序支持标准(IEEE Std 1003．13―1998)，支持波形的可移植性、结构的伸缩性以及商用服务期限。图2中的Operating System要求POSIX兼容的实时操作系统(OS)应提供AEP指定的功能和选项。CORBA对象请求代理ORB、CF框架控制接口、框架服务接口和硬件设备驱动在访问OS提供的AEP服务时不受限制，而应用程序访问OS的这些服务时受限制，需要通过CF访问文件系统。SCA规范附录B详细说明了与AEP相关的标准。
%A
%A 　　2．4 域描述体(Domain Profile)
%A
%A 　　SDR设备的目的是建立一个可重新配置的平台，这个平台可运行不同供应商提供的软件组件支持用户需要的服务，硬件设备和软件组件构成了一个SCA的系统域。SCA规范要求可移植的软件组件提供通用信息，清楚地定义硬件设备和软件组件的信息和交付格式，包括组件的位置、标识、属性、性能及相互间的关系，这些信息称为域描述体。域管理器就是利用域描述体的组件配置信息来启动、初始化和维护SCA兼容的系统中安装的应用程序。
%A
%A 　　对象管理组织OMG(Object Management Group)制定的CORBA组件规范定义了面向对象的框架中软件组件的交付配置过程，交付格式采用扩展标记语言XML。SCA规范关于域描述体的约定遵循CORBA组件模型原理，域描述体使用文档类型定义(DTD)格式，文档后缀为“．dtd”。SCA规范定义的DTD文档有以下几类，开发过程中还可以增加自己的DTD文档。
%A
%A (1) Profile Descriptor：为SAD、SPD或DCD实例提供完整的文档名，通过CF接口的“Profile”属性进行访问。
%A
%A (2)Software Assembly Descriptor(SAD)：描述应用程序／波形的软件配置特性和组件的连接特性。
%A
%A (3)Software Package Descriptor(SPD)：确定一个软件组件的实现情况，如处理器类型、操作系统、执行代码类型和文件名等。
%A
%A (4)Software Component Descriptor(SCD)：描述CORBA软件组件及其接口。
%A
%A (5)Device Package Descriptor(DPD)：用于确定制造商的信息。
%A
%A (6)Device Configuration Descriptor(DCD)：指明组件如何在最初时启动一个设备并找到域管理器。
%A
%A (7)Properties Descriptor File(PRF)：描述软件包或设备包的属性。
%A
%A 　　SCA规范附录D详细说明了有关的DTD文档。下面以DCD类型文档为例说明这类文档的用途和使用方法。DCD类型文档引用的DTD文件名为“deviceconfiguration．+SCA版本号+．dtd”，如deviceconfiguration．2．1．dtd。根据它产生的XML文档实例通常以“_DCD．xml”为扩展名，如NodeI_DCD．xml。XML文档在第二个有效行指出引用的DTD文档，XML解析器根据指定的DTD文档来验证XML文档的有效性。
%A
%A 　　2．5 安全结构(Seeurity Architecture)
%A
%A 　　在军用系统中，有专门的组织定义、维护和研究安全措施方面的问题。随着工商部门对保守企业秘密要求的不断提高，安全性功能不再只是针对JTRS的需求，信息安全(INFOSEC)处理器的重要性也在不断提高。利用可编程的INFOSEC器件，可实现软件定义的INFOSEC。SCA的体系结构也采用了可编程的信息安全模块。
%A
%A 　　3 参考案例
%A
%A 　　3．1典型的SDR收发器子系统
%A
%A 　　典型的SDR收发器应包括以下三个组成部分：
%A
%A 　　(1)RF接口模块：信号下行传输时，RF模拟信号需要经过频率变换和A／D转换，形成宽带中频数字信号；信号上行传输时反之。本模块负责实现变频、模数、数模转换，这里不采用可运行OS和ORB的嵌入式处理器。
%A
%A 　　(2)通道化和预处理模块：本模块由多个FPGA和一个控制这些FPGA的处理器构成。信号下行传输时，将中频数字信号经过数字下变频(DDC)得到窄带基带信号，上行传输时反之，数字下变频和上变频(DUC)均通过FPGA实现。每个FPGA必须有它自己的逻辑设备，代表传输模块的逻辑设备必须放在本模块的嵌入式处理器上，以便其它SCA设备和应用程序访问本模块。设备管理器和设备驱动以及支持软件也必须运行在这个嵌入式处理器上。需要注意的是，通过CORBA总线，处理器可以运行任何CF组件，不论这些组件在系统何处实例化。
%A
%A 　　(3)基带处理模块：该模块对基带数据进行调制／解调和位流处理得到用户数据。负载数据(Payload)通过Ethernet送出收发器子系统。
%A
%A 　　所有的处理器都必须运行一个操作系统(OS)和对象请求代理(ORB)。波形应用程序运行在通用处理器上。
%A
%A 　　3．2 SDR-3000软件无线电收发器
%A
%A 　　经过Step2A和Step2B两期的研发，Boeing、Harris、Motorola等公司各自开发出了自己的SDR产品。SDR-3000是加拿大Spectrum Signal Processing公司FlexComm平台的最新产品。该产品支持上百个同步收发的信道，每个信道包含一个独立的空中接口协议。FlexCommSDR-3000平台几乎支持所有天线接口标准，适合于联合战术无线业务(JTRS)、机载通信站点(CAN)，以及各种蜂窝标准的软件无线电系统开发与使用。其优越性在于：在已有硬件的基础上，可通过无线或网络安装新的升级版本、新的应用程序和波形，支持现场更换；已配置系统不需要进行额外的硬件投资即可提供新的业务和能力，可节省很大的成本。
%A
%A
%A
%A 　　FlexComm SDR-3000是一种模块化的软件无线电收发器结构，由三块板组成，系统模块接口如图3所示。从天线获得的射频信号经转换模块得到中频数字信号，并通过基于RapidIO的高速串行总线被送到软件I／O模块；在这里执行通道化功能、数字下变频DDC和其它预处理，然后经过串行总线传送到基带处理模块；数据收发器子系统得到的负载数据最后经嵌入式CompactPCI分组交换背板的Ethernet总线送到外部子系统。
%A
%A
%A
%A 　　图4为SDR-3000的软件结构示意图。其中VSI／Pro是MPI软件公司提供的矢量信号图像处理标准库。该车兼容VSIPL嵌入式API标准，包括各种通用处理函牧，如FIY、FIR滤波器。quicWave是基于VSI／Pro开发的车，用于开发波形组件。quicComm库用于支持板级功能函数，如处理器间的通信、可编程的FPGA和PowerPC的启动及某些I／O操作等。
%A
%A 　　SDR-3000的硬件和软件都支持SCA，实际应用中可以选择是否采用这种系统架构。 目前，FlexComm SDR―3000系列产品并没有包含SCA核心框架(CF)的服务功能，但收发器子系统可以通过CORBA总线(通过Ethernet总线传输)访问运行在系统中其它子系统的CF服务。
%A
%A 　　3．3 PC上的参考实现模型
%A
%A 　　加拿大通信研究中心(Communications Research Centre Canada)在SDR论坛的支持下开发出了兼容SCA的软件无线电系统参考实现模型。该系统基于Linux操作系统，使用JAVA语言进行开发。详细资料可从其网站http：／／www．crc．ca获得。
%A
%A 　　可编程的FPGA和DSP等硬件技术与面向对象的分布式处理技术使软件无线电技术的实现成为可能，但其发展还要面对很多挑战，需要硬件开发商、核心框架开发者、波形应用程序开发人员和系统集成开发商的共同努力。
%A