SOFTWARE DEFINED RADIO BASED GLOBAL ...

D. Haley, L. M. Davis, A. Pollok, Y. Chen, G. Lechner, M. Lavenant, A. Barbulescu, J. Buetefuer, W. G. Cowley, A. Grant, T. Kemp, I. Land, R. Luppino, R. G. McKilliam, H. Soetiyono, “Software defined radio based Global Sensor Network architecture,” in Prof. Wireless Innovation Forum Conference on Communication Technologies and Software Defined Radio (WinnComm), pp.11-19, Schaumburg IL, USA, March 2014.

SOFTWARE DEFINED RADIO BASED GLOBAL SENSOR NETWORK ARCHITECTURE

1

RI NT

David Haley ([email protected])1 , Linda M. Davis1 , André Pollok1 , Ying Chen1 , Gottfried Lechner1 , Marc Lavenant1 , S. Adrian Barbulescu1 , John Buetefuer1 , William G. Cowley1 , Alex Grant1 , Terry Kemp1 , Ingmar Land1 , Rick Luppino1 , Robby G. McKilliam1 , and Hidayat Soetiyono1 Institute for Telecommunications Research, University of South Australia, Adelaide, South Australia, Australia ABSTRACT

Continuing this trend, further capabilities in space-qualified hardware have facilitated the more recent shift towards software defined radio (SDR) implementations for satellite communications payloads [5]. With large parts of the radio functionality defined in software, the radio application and waveform can be changed during operation by software control. SDR thus offers the possibility of adaptive and cognitive operation, multi-band and multi-mode operation, radio reconfiguration, remote upgrade and the potential to accommodate new applications and services without hardware changes [6]. An additional benefit of the move to SDR is portability of the software waveform applications. An application can be ported to different underlying SDR hardware and/or operating systems, allowing for interoperability and staggered hardware upgrades. However, the flexibility and portability offered by SDR results in a trade-off in implementation efficiency including size, power, and perhaps even performance [7].

PR

EP

The Institute for Telecommunications Research has led a consortium to develop a Global Sensor Network architecture for remote sensor data gathering and communication. The research has focused on a Low Earth Orbit (LEO) micro-satellite system, with support from the Australian federal government’s Australian Space Research Program. We have explored the use of software defined radio (SDR) technology for the space segment, ground station and terminals. We have developed novel techniques for highly efficient one and two-way data communication with large numbers of remotely located sensors and devices. The system includes new architectures and waveform designs and makes innovative use of SDR. The end result is a cost effective, scalable and flexible system that is able to support very large numbers of users while requiring only a small amount of radio bandwidth. Development has been driven using a living reference model as the basis for an agile SDR methodology. This approach has enabled rapid transfer of fundamental research into a working system. A successful bench demonstration with space hardware was achieved within 12 months of commencing waveform design. Less than 12 months later the system was field trial proven using an aircraft as a satellite surrogate. Recently the system has been validated using a LEO satellite. This paper describes the SDR system architecture, development and test methodology, and presents results from the field proven system.

was Australia’s FedSat micro-satellite communications payload launched in 2002 which included a code upload mode allowing its baseband signal processing to be reprogrammed while in orbit [3]. From the same era, another example of FPGA-based reconfigurable satellite payload design is provided in [4], where the reconfigurable computing platform was designed for mitigation of radiation effects rather than reconfigurable application.

1.

INTRODUCTION

Traditionally, satellite and space communications payloads were custom-designed and implementations optimized, not only to meet communications specifications [1], but also the demanding mission requirements on size, weight, power and cost [2]. Then, once reconfigurable and densely integrated hardware such as field-programmable gate arrays (FPGAs) became space-qualified, these technologies were utilized to reduce obsolescence and increase the return on investment in design, build and launch of satellite payloads. An early adopter of reconfigurable technology for space applications

The two key challenges for SDR in space over and above its terrestrial counterpart are: i) creating advanced SDR platforms (hardware plus operating system) with high-reliability, space-qualified hardware; and ii) establishing standard architectures and software standards to facilitate software reuse and portability in a more niche market with fewer industry players [8]. For the most part, research and development of terrestrial SDR has been driven by the demand for flexible and reconfigurable radio communications in support of military and public safety operations [6], including the Joint Tactical Radio System (JTRS) [9]. Its development has been underpinned by advances in the enabling technologies, foremost analogto-digital and digital-to-analog converters (ADCs, DACs), but also general purpose processors (GPPs), digital signal processors (DSPs) and FPGAs. As the main driving force behind SDR for space applica-

Page 1 of 9


cepts. The architecture shown in Fig. 1 employs SDR equipment in both space and ground segments. The satellite is equipped with an SDR, allowing on orbit realtime waveform processing, and the ability to switch operating frequencies. The satellite uses a store-and-forward approach to transport data between remote user terminals and gateway terminals. User terminals, which may also be SDR based, provide remote side user connectivity. Users may run remote applications directly on the terminal and can also connect external equipment such as sensors and data loggers. On the remote side this architecture supports both unidirectional ST1 communications and bidirectional ST2 communications. Gateway terminals provide satellite connectivity to a central application hub. The gateway radio interface to the satellite is provided using the same bidirectional ST2 service that operates on the remote side. Channel resources may then be dynamically allocated between remote and gateway sides. Using the same wireless interface across remote and gateway sides also drives down the processing requirements (and hence size and cost) of the gateway terminal towards those of the user terminal. Large numbers of gateways may then be geographically distributed, reducing store and forward latency between the satellite and central application. Gateway terminals connect to the hub terrestrially through a network, e.g. via the internet. The user interface is provided by a central application that connects to the hub through a network, e.g. via the internet, allowing the user to communicate with remote equipment from their premises or using a mobile device. The central application is a peer to the remote application running on the user terminals. Transmissions are received from remote ST1 and ST2 user terminals and processed onboard the satellite. Received data is then delivered via gateways to the central application hub. The hub distributes the received data to connected central applications. The bidirectional ST2 service allows users to send commands and files to the remote terminal. The ST2 service may also be used to deliver firmware upgrades to SDR devices throughout the system. The satellite payload and all terminals are equipped with GPS. This provides a global timing reference to the communications system, and may also be used by tracking applications. The architecture shown in Fig. 2 uses a satellite payload which digitally captures and stores the remote side radio channel. The channel samples are then transferred to a ground station using a high speed downlink. A processing cluster is then used to perform ST1 receive waveform processing and extract remote user data, which is then delivered to the central application hub for distribution to end users. This architecture does not support realtime waveform processing onboard the satellite, hence we do not consider it for implementation of the bidirectional ST2 service. The benefits of centralized ground segment baseband processing are similar to those offered to terrestrial systems through the SDR concept of cloud radio access networks

2.

EP

RI NT

tions, NASA developed the Space Telecommunications Radio System standard (STRS) [8]. This software architecture is specifically tailored towards resource-constrained systems as they are typically employed for space applications [10]. Similar to the software communications architecture (SCA) for terrestrial systems, STRS aims to decouple waveform and platform. As part of NASA’s Communications, Navigation and Networking reConfigurable Testbed (CoNNeCT) project [11], three STRS-compliant SDR platforms are available: a JPL Sband communication and GPS payload, a General Dynamics S-band radio for fourth generation TDRSS (Tracking and Data Relay Satellite System) and a Harris Ka band high-speed SDR. From 2011-2013, the Institute for Telecommunications Research (ITR) led a consortium that was awarded 5 million Australian dollars (AUD) under the Australian Space Research Program, to deliver technology enabling a Global Sensor Network (GSN) for remote sensor data gathering via low earth orbit (LEO) satellites. The consortium partners were COM DEV (Canada), the Defence Science and Technology Organisation (DSTO), SAGE Automation, the Australian Institute of Marine Science (AIMS), and the Commonwealth Scientific and Industrial Research Organisation (CSIRO). The total program including partner contributions was worth over 12 million AUD. The program covered all aspects of system development, including user requirements analysis, Phase A mission study, communication system design, advanced waveform and receiver design, demonstration system implementation and field trials. The remainder of this paper is organized as follows. The SDR based GSN system architecture is presented in Sec. 2.. Components of the demonstration system are described in Sec. 3.. SDR enabled agile approaches to system implementation and testing are presented in Sec. 4. and Sec. 5. respectively. Sec. 6. describes GSN aircraft and satellite field trials. Sec. 7. then concludes the paper. SYSTEM ARCHITECTURE

PR

Prior to commencing the design of the Global Sensor Network a detailed analysis of end user requirements was conducted. This resulted in the development of two service types:

• Service Type 1 (ST1) provides unidirectional transport of small messages and is suitable for sensing and tracking applications that include very large numbers of remote terminals. Potential applications are in vessel tracking, asset and livestock tracking, and defense. • Service Type 2 (ST2) provides bidirectional communication of flexible length messages, suitable for machineto-machine (M2M) communications, remote monitoring and control. The bidirectional service also offers the potential to upgrade remotely deployed SDR equipment.

In this paper we present two variants of the GSN system architecture, both of which employ SDR technologies and con-

Page 2 of 9


SDR Payload ST2 bidirectional wireless interface

ST2 User Terminal

User Device

ST1 User Terminal

Gateway Terminal

ST1 unidirectional wireless interface

RI NT

User Device

ST2 bidirectional wireless interface

Network

ST1 User Terminal

Network

Central Application Hub

Central User Application remote side

Figure 3: Demonstration SDR payload.

gateway/central side

Figure 1: Global Sensor Network system architecture using satellite onboard processing.

Channel Capture Payload ST1 unidirectional wireless interface

high speed downlink wireless interface

ST1 User Terminal

ST1 User Terminal

Finally, we note that the architectures described in this section can coexist. For example, a satellite may carry both payload types, or an SDR payload may be implemented that also includes a channel capture and storage function.

Ground Station

3.

Central Processing Cluster

Central Application Hub

DEMONSTRATION SYSTEM

In this section we present the components of a field deployable demonstration system, able to support the above architectures. The demonstration system is SDR based allowing waveform research, development and testing to be conducted efficiently, as described in Sec. 4. and Sec. 5.. It supports operation at VHF and UHF frequencies.

EP

User Device

centralized processing architecture.

Network

Central User Application

remote side

3.1.

Space Segment

central side

Figure 2: Global Sensor Network system architecture using centralized ground based processing.

PR

(CloudRAN) [12]. Shifting baseband processing from the space to ground segment offers the potential to reduce satellite communication system mass, volume and power. Centralizing the ground segment processing also allows the use of pooled compute cluster resources, and for baseband receive processing to be upgraded independently of the space segment. However, this architecture may not offer the benefit of low complexity gateway terminals, as the high data volume requirements for transporting raw channel samples will typically necessitate traditional satellite ground station facilities. CloudRAN networks employ fiber in order to carry high volumes of baseband samples between the remote radio heads and baseband processing pool. In contrast, the typical latency of a LEO storeand-forward system deployment presents a further challenge for realtime connectivity. The ST1 service does not require bidirectional connectivity and can be implemented using the

The onboard processing architecture shown in Fig. 1 uses SDR in the space segment. For the purposes of communications system development and demonstration we use a commercialoff-the-shelf (COTS) SDR. Although not space qualified, a COTS SDR provides a flexible processing architecture indicative of that expected for future space grade SDR. Fig. 3 shows the demonstration SDR payload. The Spectrum Signal Processing SDR–4902 COTS platform is the top module in the rack. The module beneath it contains a custom built UHF RF front end and payload GPS unit. For the centralized processing architecture shown in Fig. 2 the role of the satellite is to capture the channel and downlink the digital samples for ground based processing. Fig. 4 shows the space qualified payload used for demonstration. The front end consists of a COM DEV proprietary NCAP receiver, which samples a 25 kHz wide VHF channel on two receiver antennas, and then passes the samples to a data recorder. In space deployment the channel captures are forwarded from the recorder to a ground station using a high speed downlink. For terrestrial demonstration we transfer the captures from the recorder via ethernet.

Page 3 of 9

RI NT


Figure 5: Demonstration SDR user terminal.

Figure 4: Space qualified channel capture payload.

3.2.

Ground Segment

PR

EP

Demonstration user and gateway terminals are implemented using the Ettus Research E110 Universal Software Radio Peripheral (USRP). The WBX RF front end is employed to support operation in VHF and UHF bands. Terminal hardware also includes a GPS unit for timing and positioning. A battery powered rugged enclosure is used for field deployment, as shown in Fig. 5. The USRP USB port provides an interface for user devices, such as the SCADA remote terminal unit shown in Fig. 6 provided by SAGE Automation. Other demonstration user devices include marine sensor equipment provided by the Australian Institute of Marine Science, and temperature sensors. The demonstration central application hub is implemented using a desktop PC. In the case of the centralized processing architecture, a Dell PowerEdge compute cluster is used to perform ST1 receive waveform processing. 4.

DEVELOPMENT METHODOLOGY

Traditional development methodologies place a hard demarcation between research and implementation. Waveform research is typically conducted prior to commencing implementation, using software simulation to predict system performance and provide a reference model. We consider the traditional development process shown in Fig. 7 in which waveform research is conducted using a MATLAB framework. A functional reference model is created that includes MATLAB modules and MEX wrapped C/C++ modules, where the moti-

Figure 6: SAGE Automation SCADA remote terminal unit.

vation for the latter is to increase simulation speed. Once design goals have been met under simulation a description of the algorithms is then documented. Implementation is conducted at arm’s length to research, and modules are re-implemented by hand in either software or firmware. The reference model is used to generate test vectors and performance statistics, which are used for system debugging and implementation sign-off. The traditional development workflow can lead to inefficiencies through re-implementation and slow turnaround between research and implementation. It can also lead to inefficient use of human resources by forcing individuals into the role of either researcher or engineer. Removing the barrier between research and implementation domains allows each side to appreciate overall design and implementation complexities, and thus work together to meet the system development goals. SDR enables an alternative to traditional development workflow. By shifting waveform processing into software we can share software module implementations across both the reference model and the system implementation. Hence a living reference model is created and evolves in parallel with system implementation. This approach breaks the barrier between re-

Page 4 of 9


Living MATLAB Reference Model MATLAB Reference Model MEX wrapped C/C++ module

MEX wrapped C/C++ module

Description of Algorithms

Functional Reference


MATLAB module

MATLAB module

C/C++ module


C/C++ module

Hand Code


Hand Code

Simulation Results

MATLAB module

VHDL module


Test Vectors MATLAB module

MEX wrapped C/C++ module MATLAB Coder

VHDL module



RI NT

MATLAB module


Platform Firmware

MATLAB module

Hand Code

Hand Code

hard handover

research side

Figure 8: Living reference model SDR development methodology.

implementation side

months later the system was proven in aircraft trials, and then in satellite trials, as described in Sec. 6..

Figure 7: Traditional development methodology.

5.

FLEXIBLE SDR TESTBED

The GSN services are demonstrated using a flexible SDR testbed that employs the equipment described in Sec. 3.. • Service Type 1 (ST1): is demonstrated using the centralized architecture shown in Fig. 2, with the payload shown in Fig. 4 operating in the VHF band.

PR

EP

search and implementation, making algorithms more rapidly available to engineers and providing fast feedback on implementation performance to waveform researchers. Any necessary changes to waveform processing are made within the reference model and then easily reintegrated into the system. Thus the living reference model offers a highly agile SDR development methodology. In designing the living reference model we first provide upfront consideration for target platforms. In the case of the SDR onboard processing architecture presented in this paper, the SDR–4902 demonstration payload provides FPGA, DSP and GPP resources. A specific design target for the GSN system is to implement the majority of waveform processing on the GPP, using the FPGAs primarily for front end up/down conversion and filtering. A similar approach is taken for terminal development, targeting a GNU Radio wrapped C/C++ waveform implementation on the USRP. In both cases the DSP is not targeted. The living reference model methodology used for GSN development is shown in Fig. 8. It allowed C/C++ modules to be shared between the reference model and embedded implementation. It also provided an alternative path to implementation using MATLAB Coder to automatically generate code. Firmware was hand coded, as this was the most effective way to interface with platform support packages. In the case of the centralized waveform processing architecture, the living reference model is also used to perform ST1 receiver processing on the compute cluster. The living reference model methodology has enabled parallel development and rapid transfer of fundamental waveform research into the GSN demonstration system. A successful bench demonstration with space hardware was achieved within 12 months of commencing waveform design. Less than 12

• Service Type 2 (ST2): is demonstrated using the onboard processing architecture shown in Fig. 1 with the payload shown in Fig. 3 operating in the UHF band.

Waveform processing for the USRP based demonstration user and gateway terminals is implemented in software, allowing them to easily switch between ST1 and ST2 modes. The SDR based terminals also incorporate advanced test features, such as: 1. the ability to inject emulated channel effects at the transmitter prior to packet transmission; 2. the ability for a single terminal to emulate the presence of multiple terminals through transmit signal superposition; and 3. baseband receive sample capture, allowing post-test channel characterization.

Feature 1 allows the testbed to apply channel effects consistent with those experienced during orbit. The testbed allows scripted per-packet injection of channel offsets in time, power, Doppler, and Doppler rate, consistent with those induced by a satellite channel. A script containing the channel offsets to be applied to each packet is generated offline prior to testing, using a LEO channel simulator to provide offset parameter values, as shown in Fig. 9. The script generator can schedule

Page 5 of 9


Single physical SDR terminal (USRP)

Apply channel

..

....

.. Apply channel

Baseband Tx Channel Offsets: Power Time Doppler Doppler Rate Scenario Script

Number of physical SDR terminals (USRPs) to target

Scenario Script Generator (run offline)

Simulation Parameters: Satellite Dynamics Terminal Distribution Transmit Schedule Operating Frequency

LEO Channel Simulator

Scenario scripts for remaining USRPs

EP

(run offline)

RI NT

Packet

Front End

Baseband Tx

Combine

Apply channel

Baseband Tx

both demonstration payloads described in Sec. 3.. The ST1 and ST2 services were tested in parallel, using the flexible testbed described in Sec. 5.. A key goal of ST1 is to retrieve sensor data when a very large number of terminals are simultaneously in the satellite field of view. The flexible SDR testbed was used to examine ST1 system performance with the centralized processing architecture shown in Fig. 2, by replaying scripted LEO satellite channel scenarios over the air. On the ground, nine SDR terminals were used as ST1 transmitters. Each SDR terminal transmitted up to 8 packets per time slot, emulating the presence of 8 different user terminals. This allowed more than 70 simultaneous packet transmissions to overlap during a single time slot. Channel offset parameters (time, power, Doppler, Doppler rate) were applied to each outgoing packet, consistent with a LEO deployment at 630km orbit. Channel parameters were generated using COM DEV’s satellite channel simulator which models orbital dynamics, path loss, and ionospheric effects such as Faraday rotation [13]. Each scenario reconstructed a 14 minute satellite pass using a single 25 kHz wide VHF channel. Transmissions were replayed from a very large number of terminals (such as vessels or marine sensors) with applied channel effects representing distribution around the coastline of mainland Australia and India. At 630 km orbit the diameter of the satellite field of view is sufficient to span the width of Australia in a single pass. Signals captured at the aircraft hosted satellite payload appeared as if they arrived at the payload while it was orbiting in space. The centralized ground based ST1 receiver was then given the task of decoding the signal as if it had been captured in orbit. The ST1 receiver uses advanced iterative multiuser decoding techniques that permit packets to overlap, enabling highly efficient use of the limited 25 kHz of spectrum. The Australian coastline scenario is shown in Fig. 10. During a single 14 minute pass the ST1 system successfully detected 39,816 out of a total 46,049 terminals, thus providing 86% detection probability. In the Indian coastline scenario is shown in Fig. 10. During a single 14 minute pass the ST1 system successfully detected 47,299 out of a total 59,415 terminals, thus providing 80% detection probability. During the trials we observed interference into the payload receiver coming from the aircraft electrical systems. The ability to detect large numbers of terminals was demonstrated despite the presence of this interference, further emphasizing the overall robustness of the system. The demonstration system was also used to examine ST2 system performance, using the onboard processing architecture shown in Fig. 1. The central application hub and gateway terminal were located at ITR. User terminals were located at several sites across South Australia. The demonstration SDR payload shown in Fig. 3 was used to perform real-time onboard processing, while reporting channel and performance statistics. Robust physical layer performance was verified at the

Figure 9: Advanced test features of SDR testbed.

PR

transmissions for the scenario across multiple target USRPs, providing load balanced scalability. Hence, even in the case when the system is located terrestrially and is physically stationary, test scenarios can be created such that signals arriving at the payload appear to the receiver as though they have travelled via a LEO channel. Feature 2 virtually increases the total number of terminals that can be included in testing by superposing multiple packets into the baseband transmit signal, with appropriate back off applied in order to avoid clipping the composite signal. The combination of these features allows for a very powerful form of hardware in the loop testing, at the full system level. 6.

FIELD TRIALS

In this section we describe demonstrations of the GSN system using aircraft and satellite field trials. 6.1.

Aircraft Trials

During April 2013 GSN aircraft trials were performed using DSTO’s defense experimental airborne platform as a satellite surrogate. The aircraft flew over South Australia, carrying

Page 6 of 9

RI NT


Figure 12: SAGE central application user interface for remote drill rig monitoring and control.

Figure 10: Aircraft trial Australian coastline scenario.

commands correctly. 6.2.

Satellite Trials

EP

Satellite trials of the ST1 system were performed during July of 2013 using the NTS satellite provided by exactEarth [14]. The centralized processing architecture shown in Fig. 2 was used. During orbit at 630 km the NTS satellite captured VHF channel samples while passing over South Australia, as shown in the flight path simulation prepared by COM DEV in Fig. 13. Samples were then downlinked and forwarded to ITR for receiver processing. Nine user terminals were deployed in South Australia, each having less than 40mW transmit power. The terminals sent information on position, device temperature and temperature from an attached sensor. Trial sites were selected to provide diversity in terrain conditions. The sensors attached to terminals T3, T7 and T10 were submerged in water. Terminals T4 and T5 were deployed in the Adelaide Hills area. Terminal T2 was located in downtown Adelaide. Terminal T6 was placed in a vehicle traveling on a highway at 100 km/h. Despite the low transmit power the receiver at ITR successfully decoded signals via the satellite from all nine terminals. Position and temperature information for the terminals was extracted and plotted, as shown in Fig. 14. Three terminals were collocated and successfully detected near ITR, however two of these are obscured by terminal T10 in the figure.

Figure 11: Aircraft trial Indian coastline scenario.

PR

maximum terminal to aircraft separation beyond 200 km. End user equipment and applications were interfaced to the system to demonstrate the ST2 bidirectional communication capability. The SCADA remote terminal unit shown in Fig. 6, provided by SAGE Automation, was interfaced to a remote user terminal in order to demonstrate a remote drilling rig application. Drill rig parameters, such as temperature and oil pressure were transferred from the user terminal, via the SDR payload and gateway terminal, to the central application. An interface layer was developed allowing the industry standard DNP3 protocol to connect into the GSN communications stack. This provided seamless integration of SAGE’s user interface application for remote drill rig monitoring and control, shown in Fig. 12. The bidirectional link was verified by sending commands from the central application to the remote terminal, and then verifying that the remote equipment had responded to the

7.

CONCLUSION

In this paper we have presented the SDR enabled Global Sensor Network architecture for remote sensor data gathering and communication. Two architecture variants were presented and compared, both of which implement a Low Earth Orbit (LEO) micro-satellite system. The SDR onboard processing archi-

Page 7 of 9

RI NT


Figure 13: NTS flight path over Australia.

PR

EP

tecture employs SDR in both space and ground segments, enabling a highly flexible and scalable system. The centralized ground based processing architecture moves receiver waveform processing away from the space segment, and offers some similar benefits to the CloudRAN concept. We have presented an agile living reference model development methodology that leverages SDR to accelerate system implementation. Efficiency gains are obtained by removing barriers that can traditionally occur between research and development tasks. The approach has enabled GSN waveform research and implementation to rapidly evolve in parallel into a working system. It has been validated through its ability to implement and demonstrate both GSN architecture variants in under two years. An advanced SDR enabled testbed has been presented that allows large scale over the air testing, with the full hardware system in the loop. The testbed uses transmit waveform processing to introduce modeled satellite channel effects, thus allowing large scale satellite scenario performance to be examined during terrestrial and aircraft trials. Software defined radio technology, concepts, development and test methodologies have enabled the Global Sensor Network architecture to evolve rapidly from concept into a satellite trial proven scalable and flexible system. 8.

ACKNOWLEDGEMENTS

The authors acknowledge Global Sensor Network program leader Jeff Kasparian. We acknowledge Peter Lulham for his contribution into the ITR ground segment network, in particular for establishing and maintaining the compute cluster. We also acknowledge engineering and field trial contri-

Figure 14: Sensor equipped terminals detected during satellite trial.

butions from Mirko Smiljanic, Sam Yang, Jose Torres Diaz, Ashoka Bantumilli, Trevene Leonard, Larry Pereira, Bao Nguyen, Yinyue Qiu, Assefa Teshome, Jilong Zhang and Julien Starozinski. The authors acknowledge the support of the Australian federal government’s Australian Space Research Program. We acknowledge Global Sensor Network program partners COM DEV, DSTO, SAGE Automation, CSIRO and AIMS. We also acknowledge exactEarth for providing NTS satellite access and operational support. REFERENCES [1] D. Chakraborty and C. J. Wolejsza, “A survey of modem design and performance in digital satellite communications,” IEEE J. Selected Areas in Communications, vol. 1, no. 1, pp. 5–20, 1983. [2] R. Alena, B. Gilbaugh, B. Glass, and S. Braham, “Communication system architecture for planetary exploration,” IEEE Aerospace and Electronic Systems Magazine, vol. 16, no. 11, pp. 4–11, 2001. [3] E. S. Seumahu, T. S. Bird, W. G. Cowley, and A. J. Parfitt, “The FedSat communications payload,” in Proc. 2nd International

Page 8 of 9


[5]

[6]

[7]

[8]

[11] S. K. Johnson, R. C. Reinhart, and T. J. Kacpura, “CoNNeCT’s approach for the development of three software defined radios for space application,” in Proc. IEEE Aerospace Conference, 2012, pp. 1–13. [12] China Mobile, “C-RAN: The road towards green RAN,” in White Paper, Oct. 2011. [Online]. Available: http://labs.chinamobile.com/cran/wp-content/uploads/ CRAN_white_paper_v2_5_EN.pdf [13] E. Coleshill, “AIS: Technology development to commercialization,” in Proc. NSAW–2010 (National Space Awareness Workshop), Nov. 2010. [14] E. Coleshill, J. Cain, F. Newland, and I. D’Souza, “NTS–A nanosatellite space trial,” Acta Astronautica, vol. 66, pp. 1475– 1480, 2010.

PR

EP

[9]

[10] NASA Glenn Research Center, “STRS standard architecture,” NASA Website, June 2011. [Online]. Available: https://microgravity.grc.nasa.gov/SOPO/SCO/SCaNTestbed/ Candidate/documents/STRS-AR-00002_Rel_1.02_STRS_ Architecture.1.pdf

RI NT

[4]

Conference on Information, Communications and Signal Processing (ICICS’99), 1999. M. Caffrey, “A space-based reconfigurable radio,” in Proc. Military and Aerospace Applications of Programable Devices, 2002. [Online]. Available: http://klabs.org/richcontent/ MAPLDCon02/abstracts/caffrey0_a.pdf W. Chen, T. Jones, A. Macikunas, P. Thomas, and E. Choi, “Software defined radio (SDR) payloads for microsatellite missions,” in Proc. CASI Astronautics Conference, May 2010, pp. 1–6. T. Ulversoy, “Software defined radio: Challenges and opportunities,” IEEE Communications Surveys & Tutorials, vol. 12, no. 4, pp. 531–550, 2010. E. M. Witte, T. Kempf, V. Ramakrishnan, and G. Ascheid, “SDR baseband processing portability: a case study,” in Proc. Workshop on Software Radios, Karlsruhe University, 2008. R. Reinhart, S. Johnson, T. Kacpura, C. Hall, C. Smith, and J. Liebetreu, “Open architecture standard for NASA’s softwaredefined space telecommunications radio systems,” Proceedings of the IEEE, pp. 1986–1993, Oct. 2007. D. R. Stephens, B. Salisbury, and K. Richardson, “JTRS infrastructure architecture and standards,” in Proc. Military Communications Conference (MILCOM), Oct. 2006, pp. 1–5.

Page 9 of 9

SOFTWARE DEFINED RADIO BASED GLOBAL ...

SOFTWARE DEFINED RADIO BASED GLOBAL ...

Suggest Documents

Software Defined Radio Project

Software Defined Radio Handbook

Software-Defined Radio Handbook

Software Defined Radio Handbook

Subsampling Based Software Defined Radio with ... - Bioelectronics

A Software Defined Radio platform based on

Software Defined Radio and Cognitive Radio:

An All-GNU Radio Software-defined Radio

Tutorial: Software-Defined Radio Technology

Modular Software-Defined Radio

Software Defined Radio (SDR) - BioMedSearch

global navigation satellite system software defined radio

global navigation satellite system software defined radio

LABVIEW BASED SOFTWARE-DEFINED

Modular FPGA-Based Software Defined Radio for CubeSats by ...

A Software Defined Radio platform based on NetFPGA - CiteSeerX

Software-defined Radio Based Measurement Platform for ... - NIST

GNU Radio Based Software-Defined FMCW Radar ... - GNU mailing lists

Software-defined radio baseband system for satellite ... https://www.researchgate.net/.../Software-defined-radio-baseband-for-satellite-manage...

Two-Stage System Based on a Software-Defined Radio - MDPI

Nomadic Base Station (NBS): a Software Defined Radio (SDR) based ...

GNU Radio Based Software-Defined FMCW Radar for Weather ...

Modular FPGA-Based Software Defined Radio for CubeSats by ...

Model-Based Design for Software Defined Radio on an FPGA