SDRsim: A PC-based Simulator of
Software Defined Radio
Yuan-Deng Chuang’, Yue-Shan Chang’, Ruey-Hsiang
Wu3, Shu-Ching Lin3,
Shyan-Ming Yuan’
Department
of
Computer Science and Information Engineering
National Taiwan University
Department
of Electronic Engineering, Minghsin Institute of Technology
3Department of Computer and Information Science, National Chiao Tung University
[email protected], yscliimhit.edu.tw,
jgis89898, gis90573. smwan}@cis.nctu.edu.tw
12
Abstract
This paper represents a pc-based tool for simulation and rapid control prototyping of Software Defined Radio (SDR) technology. The tool describes a software platfonn implemented to facilitate the SDR software architecture at the analysis, design and implementation stages. SDRsim is a prototyping platform which provides modularity, and requires minimal implementation effort to accommodate the SDR device. It is able to demonstrate the practical use of software prototyping in reducing the complexity of product analysis and design. This simulator provides the flexibility to modify and analyze the impact of various architecture parameters and components as well as enable more detailed statistics collection than real SDR device.
1. Introduction
The concept of reconfigurable “software radio” [1][2] has been an active research topic which is driven initially by Military requirements for flexibility. It is best defmed as
the software implementation of functions inside a radio transceiver more usually implemented with analogue or digital electronic circuits, where software can be defined as a set of instructions running on a programmable processor.
Software Defined Radio (SDR) [3][4] is introduced as a new radio concept. Its objective is to use the software technology to control digital components so that a user’s hand-held device may roam over different wireless networks from a building to the global and use the technologies in the fields which range from micro-cell to satellite.
SDR integrates the digital wireless communication technology and software technology. Therefore, the main topic of SDR is how a hand-held device can dynamically change
the software control module to match the wireless communication system, in other words, smoothly hand-over to a different system.
The Joint Tactical Radio System ( J T R S ) [5] has proposed a Software Communication Architecture (SCA) specification 261 that defines clearly the architecture of software technology in SDR. Referring to the SCA specification, “SDR Forum Technical Report 2-1” [4] and related documents [7][8], we will propose a software prototyping which is called SDRsim in this paper. It provides high-level functional models that are capable of being mapped into specific software-defined devices such as hand-held, mobile, and base station applications. SDRsim is a prototyping platform which provides modularity, and requires minimal implementation effort to accommodate the SDR device. Due to the complexity and associated cost of building modem computer systems, simulation is often the only practical way to test architectural ideas and access system performance.
This paper is organized as follows: Section 2 proposes the SDRsim software architecture. Section 3 discusses the design and analysis of SDRsim. Section 4 proposes the implementation mechanisms of SDRsim. Section 5 surveys some related works. Finally, Section 6 makes some conclusive remarks.
2.
The
overview of
the
SDRsim
software architecture
Some important technologies and software components are needed to support SDR technology according to the requirements of SDR concept. Figure 1 shows the layered elements in the SDRsim software architecture. Its functionalities will be described respectively as follows:
We t h d Industrial Technology Ressarsh Instimte -t
T1-9W28, the National Science Council grant
Hardwan h r e
Figurel. The SDRsim software architecture 2.1 Application
Application may be SDR utilities or be the end-user applications which are developed by the third-party commercial parts. Application could be e-mail utilities, Java objects (MlDlet, PersonalJava), user interfaces etc. Application can directly use Core Framework's
functionalities or invoke Sofhare & Hardware
Module to accomplish jobs.
2.2 Core Framework
Users can invoke the provided objects (such
as Domain Manager 7 Resource Manager 7 and
File Manager etc.)in Core Framework to control SDRsim. For example, Core Framework car1 be used to switch among various protocols so that SDRSim can roam on multiple modes of person- al communication systems. Core Framework consists of:
Base CORBA [9] interfaces (Configure, Life, Test and Port)are inherited by Software
& Hardware Module to provide the functionalities for controlling and communicating with Software & Hardware Module.
Functional elements (like Domain Manager, Resource Manager and File Manager etc.) provide framework conbol of
all system operations via CORBA interfaces.
Domain Profie describes the properties of Software & Hardware Module and the information of mode configuration, resource description etc.
2.3 Software & Hardware Module
Software Module provides the standard interfaces for the control and communication behavior which includes repeater, link, biidge,
network, router, and gateway operations. Software Module relies on commmial components to support multiple unique serial and network interfaces. Reliable transport mechanisms may include error checking and correction at the network and serial inkdace
level, Possible serial and network physical interfaces include RS232, RS422, RS423, RS485, Ethernet, 802.x, and others. In order to support the standard interfaces, various low-level network protocols may he used. They may include PPP,
SLIP,
CSLIP, LAPx, and others. Using these protocols, other protocols such as IP, TCPAJDP, and X.25 can he added toprovide network connection. Software Module also includes typical security operations which provide key fill, key management, programmable security device control, and software integrity and authentication.
Hardware Module is also a software component. It provides the hnctionalities such as modulation, CODEC, interleaving, and equalization etc. It also can be downloaded from content providers and dynamically loaded and executed. Hardware Module includes two major elements: the driver and signal processing
algorithm sofhare. They are described as follows:
Driver: With respect to different communication protocols, they need differential drivers which provide the hctionalities of controlling Hoirhvore Device. Therefore, drivers download is needed when starting the operation of
changing or establishing communication protocols.
Signal processing algorithm software: Signal processing algorithm is used in the recontigurable device such as DSP (Digital Single Processing). Like drivers, the single processing algorithm software may need to be downloaded when executing the operation of changing or establishing communication protocols. Therefore, the
single processing algorithms have to allow dynamically downloading and loading into the reconiigurahle device. Binding up the needed single processing algorithms into a software object is needed for effective downloading.
2.4 Operating System & Middleware
In order to provide the powerful execution environment for SDRsim, it is needed to support the real-time Operating System and Middleware which can supply the following functionalities: 0 Real-time requirement: SDRsim provides
the functionalities of configure mode,
establish mode, change mode etc. It is able to accomplish these jobs in a constrained time. Therefore, a real-time Operating System is required.
0 Minimal memory requirement: For general hand-held device, the storage size is limited because of the concern for the
volume and cost. In order to utilize the constrained memory size, the size of Operating System and Middleware whch used in SDRsim will suit to the storage size. Services providing: According to “SDR
Forum Technical Report 2-1” [4], the standard interfaces and API are already proposed. The implemented functionalities of these interfaces and APIs all execute on the CORBA environment. Therefore, a suited CORBA environment will be provided.
The real-time Operating System used in SDRsim has to provide the functionalities to deal with the time-constrained problems. These functionalities are depicted as follows:
0 Threadmrocess handling: Operating System controls the scheduling operation which utilizes the properly level of thread and process. The scheduling operation is an important feature which can facilitate accomplishing jobs before the deadline. 0 Resource management Operating System
can supply the resource status management and provide the functionalities for querying and setting system resources (likes memory and disk). It helps to allocate the applications with needed resources which are used to complete the time-constrained jobs.
0 High-performance
U 0
system: The high-performance WO rate is to ensure the constrained-timed data transmission be completed before the deadline.0 Providing high-performance network for
data transmitting. 0 Supported processor.
0 Supported developing language. 0
Based on a real-time Operating System, the real-time CORBA environment can be used with a high quality.
T h e
real-time CORBA environment in SDRsim has to meet following criteria:0 Based on a real-time Operating System. 0 Providing a real-time ORB(0bject Request
Broker).
0 Providing high-performance
YO.
0 Providing scheduling operation which can be integrated in ORB.
0 Providing high-performance network for data transmitting.
0 Supported developing language.
The following contents put the emphasis on
the survey of the COTS (Commercial -Of-The-Shelf) real-time Operating System and CORBA environment. It is needed to combine a real-time Operating System and CORBA
-< .Q,.W.,XHI. IodB
-M.SP”W-
~~-
”MIM
!$was1
environment together to supply SDRsim. Table 1 includes the information about the COTS real-time Operating System.
According to “Measuring OS Support for Real-time CORBA ORBS” [IO], the traditional Operating Systems such as Windows NT, Solaris, and Linux are not competent to meet the real-time requirements. The reasons are that the non-real-time Operating Systems cannot promise to accomplish the task in a constrained time. Therefore, we have to find the specified Operating System which can provide the real-time fuuctionalities. The following depicts several COTS real-time Operating Systems and compare these Operating Systems with the conditions addressed above.
2.5 Hardware Device
The elements belonging to Hardware Device may be the general hardware devices (such as Ethernet Card, Audio Card etc.) or the reconfigurable hardware devices (such as DSP device), Hardware Device is the physical implementation of SDRsim which will have values for the relevant attributes based on the system’s physical requirements and the procurement performance requirements.
3. Design and analysis
This section focuses on the SDRsim design flow which is a representation of SDRsim that rationalizes, arranges, and connects components to produce the desired functionality, With re.jpect to the design and analysis of SDRsim, dividing the design and analysis flows into four parts can help to describe more clearly. The first part is to identify the functional elements included in the SDRsim software architecture. In the second and third parts, use LJML (Unified Modeling
functionalities for querying and setting system resources (like memory and disk). It is also responsible for detecting the error status of Hardware Device and reporting this status back to Domain Manager. Resource Manager provides a set of functionalities for Software Module Manager 8 Hardware Module Manager and
Application to allocate the system resources.
apPll”
- . ~ . -..-.-. ~.-.
Language) technology to design the Use Case . . ~ architecture and Sequence Diagrams which are centrdl to
model the behavior of SDRsim. 0 File Manaeer: File Manager is responsible 3.1 The functional elements of the SDlLim
software architecture
Figure 2 is proposed to present the design of several functional elements and the relationships among these functional elements of the SDRsim software architecture. The SDlbim software architecture includes the functional elements which can be separated into five individual layered components: Application,
Core Framework, SofrWare & Hardware Module, Operating System & Middleware and Hardware
Device. Application, Operating System and Middleware are all the COTS software that satisfies the requirements of the SDR concepts which are described above. Therefore, the design flows will focus on the functional elements of Core Framework and Software & Hardware Module.
The functional elements belonged to Core Framework depicted as follows:
0 Domain Manager: Domain Manager i,r the central administrated element in Core Framework, It is responsible for controlling the functionalities of Core Framework and assigning jobs to the corresponding elements. It is also responsible for monitoring the execution status of Core Framework.
Resource Manager: Resource Manager is responsible for managing the resource status of Hardware Device and providing the 0
for manag& the files and file systems in SDRsim.
0 Remote Download Manager: Remote Download Manager is responsible for downloading the software which includes Software Module, Hardware Module and Application.
0 Mode Configuration Manager: Mode Configuration Manager provides the status lists of Hardware Module and Software Module. It is responsible for detecting the status of currently used communication environment, and then deciding if it has to execute the operation of changing mode or not. It also provides the lists of available communication environments which can be used right now. When receiving the command of changing mode, Mode Configuration Manager will estimate the status of currently used communication environment to check if it can accomplish this operation in the constrained time. 0 Software Module Manager: Software
Module Manager is responsible for managing and monitoring the status of Software Module. It is also responsible for reconfiguring Software Module.
0 Hardware Module Manager: Hardware Module Manager is responsible for managing and monitoring the status of Hardware Module. It is also responsible for reconfiguring Hardware Module.
Logger: A Logger is utilized by SDRsim to store informational messages. These informational messages are also called as
/og recordr in this paper. The Logger is responsible for recording the execution messages and exception messages. It is implemented according to CORBA Log
Service.
Timer: A Timer provides operations for synchronizing time within radio as well as for creating and managing time-based events. The Timer is based on CORBA lime
Service.
Domain Profile: Software Module and Hardware Module make up an SDRsim domain which is described by a set of files that are collectively called a Domain Profile. All of the descriptive data in the Domain Profile is expressed in the XML (extensible Makeup Language) vocabulary which describes a distinct aspect of Software Module and Hardware Module. These files describe identifies, capabilities, properties, inter-dependencies, and locations of Software Module and Hardware Module. They also describe the records of services which subscribed from content providers.
To facilitate controlling Software Module and Hardware Module, the standard interfaces are needed to be provided. Both Software Module and Hardware Module provide the standard interfaces which are formatted as IDL (Interface Definition Language) type. They all execute on the CORBA environment. The standard interfaces are depicted as follows:
Configure: provide the configuring operations with the specified properties. Life: provide controlling functionalities such as startup and stop operations. T a t provide the self-test functionalities with the specified properties. Pon: provide the co-operation functionalities which can be put into work together with other Software Module and Hardware Module. 3.2 UML design for SDRsim
With respect to design the operations of SDRsim, using UML technology is suited to
describe the design flow more clearly. The UML is a graphical language for visualizing, specifying, wnstrncting, and documenting the artifacts of software-intensive system. The UML gives a standard way to write the system’s blueprints, covering conceptual things, such as system’s functions, as well as concrete things, such as system’s classes written in a specific programming language, and reusable software components. Core Framework is the most impomnt component which provides the
functionalities for controlling all the components in SDRsim, and monitors their execution status.
Therefore, the design flow will base on Core Framework and then expand to SDRsim
Section 3.2.1 uses UML to design the Core Framework Use Case Diagrams which show a set of use cases, actors and their relationships. It is applied to illustrate the static use case view of a system. Section 3.2.2 devises the Core Framework Sequence Diagrams which show a set of functional elements of SDRsim and the messages sent and received by those functional elements.
3 2. I The Core Framework Use Case Diagrams
Twelve use cases and five actors are included in this diagram. The five actors are described as follows:
OAbM: It may be users of hand-held
devices or system venders.
0 Content Provider: provide applications and services to be downloaded and supply the functionalities for executing services and applications.
SoJhvare Module, Hardware Module and
Hardware Device
Figure 3 is the Use Case Diagrams of Core Framework. It shows the twelve use cases. These use cases will be described as follows:
Bootup: boot-up or reconfigure SDRsim. Remote Download: wnnect with content providers and download the specified software which includes Software Module, Hardware Module and Application. Manage Resource: manage the resource status of Hardware Device, provide the functionalities for querying and allocating system resources (like memory and disk). 0 Configure Software Module: configure
Software Module’s status and functionalities.
0 Configure Hardware Module: configure Hardware Module’s status and functionalities.
Mode Configuration Management: provide the status lists of the current used Software Module, Hardware Module and communication environment It is also responsible for executing the operation of changing mode.
0 Establish Mode: establish the specified communication environment
0 Release Mode: release the current used communication environment.
0 Change Mode: change the current used communication environment to the specified one.
0 Environment Detection: detect the 0
0
available communication environment from Software Module and which can be used right now.
Status Report: provide the functionaiities 0 Shutdown: OA&M shutdown
for receiving .the messages which come
Module. SDRsim. Hardware or release
. .
tonbOtRw+?a S" M UFigure3. Core Framework Use Case Diagrams
R t O 6 0
6
(3
6
6
6 0 0 0
I -a--nu-. lil.Y.".l.l:navln*.n...r-l. -om." **,, Y.d"I.
-
iQ&!la4&scz
.
.
&%ayj M " l M m a u *.I-.
.
.
.
Figuwl. I3ootup Sequence Diagram
3.2.2 The Core Framework Sequence Diagram received by those functional elements which are typically named or anonymous instances of Sequence Diagrams show a set of classes or collaborations, components, and nodes. functional elements and the messages sent and The Core Framework Sequence Diagrams
present the specified use case’s behavior in the Core Framework Use Case Diagrams. They are described in the following process in which the execution steps are depicted. The example of the
Boohrp Sequence Diagram represents the behavior of “Bootup” use case in the Core Framework Use Case Diagrams. The example is presented in Figure 4 and the execution steps are depicted as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9 .
OA&M may he actions caused by users of hand-held devices or system venders. It starts the hootup operation of Core Framework.
OA&M hinds Domain Manager.
OA&M demands that Domain Manager execute the bootup operation.
Domain Manager binds File Manager Domain Manager demands that File Manager read the system setting file which includes the previous system configuration information.
File Manager reads the system setting file. Domain Manager hinds Resource Manager. Domain Manager hinds Remote Download Manager.
Domain Manager binds Timer. L
10. Domain Manager binds Logger.
11. Domain Manager demands that Logger write the log records of bootup operation.
12. Domain Manager binds Mode Configuration -
-
Manager.13. Domain Manager binds Hardware Module Manager.
14. Domain Manager hinds Software Module Manager.
15. Domain Manager demands that Mode Configuration Manager establish the communication environment according to the mode sequence properties.
4.
Implementation
SDRsim is implemented according to the design flow in Section 3. The features and functionalities of SDRsim have been implemented as primitives in a “class library” that focuses on the design flow which bases on Core Framework, Software Module and Hardware Module.
The implemented “class library” of Core Framework are included in sdr.cf package. All implemented classes use the Java programming language [lS] and provide standard interfaces which are formatted as IDL type. All implemented classes execute on the VisiBroker CORBA middleware and RTLinux [16] platform.
For example, the implemented classes and interfaces in the sdr.cf.domainManager package provide the functionalities of Domain
Manager.
The Domain’hofile is consisted of five kinds of files which are Sofmare Module
Descriptor, Hardware Module Descriptol; Mode Assembly Descriptor, Resource Descriptor, and
Available Mode Descriptor file.
A Software Module Descriptor file contains information about the interfaces that the specific Software Module provides and/or uses. A Hardware Module Descriptor file contains information ahout the interfaces that the specific Hardware Module provides and/or uses. A Mode Assembly Descriptor file contains information about the specific Software Module and Hardware Module that make up a communication protocol. A Resource Descriptor file contains information about allocating and de-allocating system resources to a processor, DSP, FPGA, and other resources which will report their presence in the system through the Resource Manager. An Available Mode Descriptor file contains information about the available communication environments that can used right away, Mode Configuration Manager will maintain this file and use it when establishing or changing mode. All of the descriptive data in Domain Profile is expressed in the XML vocabulary.
The implementing elements of Software Module and Hardware Module focus on the standard interfaces which are formatted as IlJL type. All elements can be implemented in several programming languages which are supported by the CORBA environment.
Figure 5 depicts the functional elements of Core Framework. Figure 6 depicts the system operations of Software Module and Hardware Module designing. The system developer can use SDRsim to automatically consmct the basic functions of Software Module and Hardware Module according to the standard interfaces which are described above.
5.
Related works
The past and present projects have sponsored the research in SDR-related technologies include IBMS (Integrated Broadband Mobile System) [17], MOBIVAS (downloadable MOBIle Value Added Service) [181, TRUST (Transparently Reconfigurable UbiquitouS Terminal) [19] and so on.
The objective of IBMS project is the integration of low and high data rate services for outdoor and inhouse mobile commnnication system based on ATM transmission.
The MOBIVAS project is proposed by IST-1999-10206 and the overall objective of MOBIVAS is to develop architechual approaches and prototypical implementations of
integrated software platforms and syscems, which will enable the flexible provision of Value-Added Services (VAS) in mobile communication networks. These platforms should be adaptable to different network services and technologies and will constitute new opportunities for third-party Value-Added- Service Providers (VASPs).
The IST project TRUST that attempts to rationalize the “seamless wireless utopia” by studying the real user requirements for reconfiguring terminals and then creating realistic working scenarios.
*..-”.””--
FigureS. The SDRsim simulator (1:)
Firmre6. The SDRsim simulator L (21
6. Conclusions
This paper represents a pc-based tool for simulation and rapid control prototyping of SDR system, based on industry standard architecture and COTS technologies. We propose a soflware prototyping which is called SDRsim. It provides high-level functional models that are capable of being mapped into specific software-defined devices such as hand-held, mobile, and base station applications. SDRsim is a prototyping platform which provides modularity, and requires minimal implementation effort to accommodate the SDR device.
We implement the SDRsim simulator which is developed by the COTS software technobgies such as RTLinux, WsiBroker CORBA environment and Java technology etc. The features and functions of this SDRsim simulator have been implemented as primitives in a class library that focuses on the design flows which
are based on the requirements of SDR concept.
References
[l]. J.Mitola, “Software Radio: Survey, Critical Evaluation and Future Directions”, IEEE
National Telesystems Conference, pp. 13-15- 13-23, May 1992.
[2]. J.Mitola, “The Software Radio Architecture”,
IEEE Communication Magazine, Vol. 33, No. 5,
pp. 26-37, May 1995.
[3]. The SDR Forum (formally MMITS), hnp://w.sdrfomm.com
[4]. SDR Forum Technical Report 2-1. http://www.sdrforum.com
[5]. Joint Tactical Radio System (JTRS),
http://www.jtrs.saalt.army.mil
[6]. Modular Software-programmable Radio Consortium, “Software Communications Architecture Specification”, MSRC- 5000SCA. [7]. Gi-Ping Lee, Yue-Shan Chang, Shyan-Ming Yuan, “A Software ‘Framework for Software Radio,” in Pmc. of WCC2OOOflCCT2000, Beijing, China, August 21-25, 2000. pp.
1102-1105.
[ 8 ] . Yuan-Deng Chuang, Yue-Shan Chang, Shyan-Ming Yuan; “A Framework for Integrating MExE . with SDR’s Software
Architecture,’’ Networks 2002(Joint conference ICWLHN2002 and ICN2002), Aug. 26
-
29, 2002, Atlanta, Georgia, USA, pp.-
.[9]. The Object Management Group * The Complete CORBAiIIOP 2.3.1 Specification, OMG document formal/99-10-07;
[IO]. David L. Levine, Sergio Flores-Gaitan, Christopher D. Gill and Douglas C . Schmidt ,
“Measuring OS Support for Real-time CORBA
ORBS”,
Proceedings of the Fourth IEEElntemational Workshop on Object-oriented Real-time Dependable Systems (WORDS’99), Santa Barbara, California, January 27-29, 1999 [Ill. TAO, “httu://www.cs.wustl.edu/-Schmidt/ TAO-intro.html”
[12]. VisiBroker, Borland Corp.
httu://www.borland.cotnhes/ visibrokerl [13]. Orbix, http://+.orbix.gq.nu/
[14]. The Object Management Group, http://www.omg.org” 0
[15]. Sun Microsystems, httu://iava.sun.com [16]. FSMLabs, RTLmux (Real Time Linux),
http://fsmlabs.com/conununityl
[17]. BMS(1ntegrated Broadband Mobile System) project, http://www-ibms.ee.tu-berlin.de/
[IE]. IST-1999-10206 MOBNAS (downloadable MOBIle Value Added Service) Deliverable D-2.1.2 Requirements for general architecture & interface specification.
[19]. IST-2000 TRUST (Transparently Reconfigurable UbiquitouS Terminal), http://www.ist-trust.org/title.html
