NASA Technology For Software Defined Radio Request For Information
Synopsis – Jul 07, 2014
General Information
Solicitation Number: NNC14ZRH014L
Posted Date: Jul 07, 2014
FedBizOpps Posted Date: Jul 07, 2014
Recovery and Reinvestment Act Action: No
Original Response Date: Sep 30, 2014
Current Response Date: Sep 30, 2014
Classification Code: 59 — Electrical and electronic equipment components
NAICS Code: 334220
Set-Aside Code:
Contracting Office Address
NASA/Glenn Research Center, 21000 Brookpark Road, Cleveland, OH 44135
Description
NASA’s Technology for Software Defined Radio Request for Information
Important Notice: This RFI notice is open to all interested parties. 1 Introduction:
In 2002, as the Department of Defense Joint Tactical Radio Systems program was in development, routine deployment of Software Defined Radios (SDRs) for NASA missions was a new concept. This was primarily due to the limitations of reconfigurable components useable for space radios. The need to reduce the cost and risk of using SDRs was identified and a multi-center NASA team was created to investigate SDR technology and the development of a software abstraction layer, similar to the Joint Tactical Radio Systems (JTRS)’s Software Communication Architecture (SCA) concept, to enable porting of applications among platforms. This led to the development of the Space Telecommunications Radio System (STRS) architecture. The STRS architecture for software-defined radios (SDRs) is an open architecture for NASA space and ground radios. STRS provides a common, consistent framework to abstract the application software from the radio platform hardware to reduce the cost and risk of using complex reconfigurable and reprogrammable radio systems across NASA missions. It achieves this objective by defining an architecture to enable the reuse of applications (waveforms and services implemented on the SDR) across heterogeneous SDR platforms and reduce dependence on a single vendor. The Standard provides a detailed description and set of requirements to implement the architecture. The Standard focuses on the key architecture components and subsystems by describing their functionality and interfaces for both the hardware and the software, including the applications.
In 2007, the STRS architecture was determined to be ready for flight implementation in a technology development project. This project was originally called the Communication, Navigation, and Networking reConfigurable Testbed (CoNNeCT). CoNNeCT was later renamed the Space Communication and Navigation (SCaN) Testbed. Three SDRs, compliant with the STRS architecture, were procured in 2008 and 2009 for the SCaN Testbed, using the architecture defined in a technical memorandum and referred to in the procurement specifications as STRS Architecture Standard Release 1.02.1. The SCaN Testbed was launched in July 2012 and operates on an external truss on the International Space Station (ISS).
The SCaN Testbed is an experimental communications system that provides the capability for S Band, Ka-Band, and L-Band communication with space and ground assets. Investigation of SDR technology and the STRS architecture are the primary focus of the SCaN Testbed. As a completely reconfigurable testbed, the SCaN Testbed provides experimenters an opportunity to develop and demonstrate experimental waveforms and applications for communication, networking, and navigation concepts and to advance the understanding of operating SDRs in space. Lessons learned from the platform provider, application developers, and integrators of the SCaN Testbed provided critical insight for the development of the current Standard, NASA-STD-4009.
Many of the original concepts for the design, development, and use of SDRs for NASA missions has progressed significantly since the original development of STRS and updates to the architecture are being considered. The purpose of this Request for Information (RFI) is to solicit input from industry, academia, and other government agencies about the current and future SDR capabilities, hardware and software architectures, and recommended enhancements to STRS for the development of SDR applications.
The information received through this RFI will be used by NASA to enhance the STRS architecture, and improve the processes for application development and reuse for SDRs. There will not be a follow-on funded solicitation directly from this RFI. Multiple NASA centers will review the responses, providing an opportunity to increase NASA’s awareness of the respondent’s efforts in the Software Defined Radio area. 2 Objectives:
The primary objective of the RFI is to solicit information in the following three areas:
1. Investigate the State of the Art of near-term, space applicable Software Defined Radio technology. 2. Understand the barriers to establishing a developer community to create or reuse applications for NASA communication systems. 3. Gather information on the technologies and concepts that will enable space-based communication systems in the near future (~10 years). The following concepts for NASA missions should be considered: a. Cognitive radio and networking b. Optical c. Integrated optical and Radio Frequency(RF) d. Security e. Cost and risk reduction f. Considerations for extreme environments g. Safety/mission critical h. Integrated platform with multiple functions (science processing) i. Sharing on-board computational resources 4. Recommend updates to the current version of the STRS architecture NASA-STD-4009. The STRS architecture standard NASA-STD-4009 and accompanied handbook NASA-HDBK-4009 can be found at the NASA Standards website located at https://standards.nasa.gov , click NASA Developed Standards and scroll down to the appropriate document. Additional information on the STRS architecture are available at https://strs.grc.nasa.gov . 3 Scenarios:
The following two potential scenarios for the use of SDRs in NASA missions are provided for consideration when answering the subsequent questions.
Relay spacecraft
The following scenario represents a future relay spacecraft operations and demonstrates the complexity of future radios in a networked space environment.
A spacecraft is performing as a relay point in a communications network, where it orbits the body of interest every 20 -120 minutes. Since the spacecraft is also doing science measurements, the orbit changes to accommodate the science measurements. However, at any given time, the spacecraft knows where it is and what its orbit is.
As the orbiter flies over the surface, it can establish short range links with landed assets or other orbiters. The range of these links may be anywhere from a few tens of km, in which case the period of visibility is short (a few minutes) or tens of thousands of km, in which case the period of visibility is longer (and potentially infinite, if the orbit period matches the rotation period of the body, as with a Clarke orbit on earth).
It is expected that these short range links are established automatically, and data is transferred in both directions with some sort of error detection and retry protocol. There is significant multipath fading due to surface topography and the pattern of the antenna on both ends of the link. For some of the passes, the relay satellite may not get very high above the horizon, but if there is high priority data to send, then it should be sent as soon as possible. For other data, a longer latency may be appropriate, and a later pass with better geometry (higher elevation, better antenna available, longer duration) might be used. The decision about how and when to send the data is autonomous, without needing ground commanding.
Any of the assets may have a high or medium gain antenna which can be pointed appropriately (and autonomously), and the decision about which antenna to use, and where to point it, should be made autonomously on the basis of the data needing to be sent, with some sort of Quality of Service (QoS) metric. Note that a given communication opportunity may start with low gain omni antennas, and after the link is established, the fact that one end has high priority data to send would cause a shift to a higher gain antenna that can support the link. The higher gain antenna may not necessarily be on the end of the link with the data to be sent.
There may be multiple other spacecraft/rovers/astronauts within the “field of regard” of the relay spacecraft at the same time, all needing to communicate at the same time, in the same band, perhaps even in the same channel, so the physical layer (PHY) and media access control (MAC) communications protocols should accommodate this capability. On the other hand, the two end points may have wildly disparate capability: one may be a legacy asset using an old protocol and link layer, and the other a newer one, so the ability to support two different protocol stacks on the same RF band/channel is important.
Each of the endpoints will have protocols that change. For example, a lander may use some protocol like Prox-1 normally, but in the event of an emergency, it reverts to a legacy safe mode with low bit rate, lots of coding, and transmitting in the blind. The orbiter must be able to recognize that this has occurred, and shift it’s demodulation strategy appropriately, and be able to forward this presumably high priority traffic as appropriate (either on a Direct to Earth backbone consisting of both RF and optical links, or, perhaps if two astronauts are communicating via the relay, to the other astronaut).
Since SDRs can also serve as science instruments doing radio science, radars, or navigation measurements, they should be doing that while communications are occurring, or during the intervals between comm passes. Naturally, the scheduling of these should be autonomous, in response to a priori task lists.
The orbiter may also be carrying a high precision clock, or may be able to get high precision time and frequency data from its direct to earth link, or from another asset. It should be able to pass that on to the other assets, so that the entire network is on a common time basis and long term frequency drift can be accommodated without requiring expensive oscillators on all the spacecraft.
Both orbiter and lander should be able to make use of navigation signals (which may be the comm signals as well, assuming they are well “known” enough) to determine their positions, which in turn should be used to autonomously build connection graphs and link schedules.
All of this should require minimum commanding intervention, other than to set the overall priorities for the data flow, and perhaps to set limits and/or caps on data. The establishment of links, and deciding which data to send over which links, should be autonomous.
Constellation of Cubesats
NASA is currently investigating the capability to deploy up to 11 cubesats from the first Space Launch System (SLS) flight in 2017. The cubesats could be deposited in deep space, close to the moon and beyond. Previously, cubesats have been limited to balloon, sounding rocket and orbital fights, but this SLS opportunity would open up the possibility for significantly enhanced science. However, cubesats in deep space also present unique complexities and challenges, especially in the transmission of meaningful and timely science data to Earth. Given this, NASA is interested in technologies that may be useful to allow data transfer and telemetry at the MBps rate from 6U-sized cubesats at lunar distances. A sampling of the interests include:
* Cubesat form-factor software defined radios
* Advanced modulation and error correction schemes
* Delay tolerant networking methodologies
* Power efficiency
* Radio frequency / optical relays
* Resistance to harsh flight and space environments including heavy vibration; extreme heat and cold; and radiation hardness, tolerance, and mitigation
* Ability to integrate wireless sensors
* Autonomous control and operation 4 Specific questions:
Given the objectives for the RFI and the scenarios above, provide insight in the following areas. Answer the questions that relate to your company’s area of expertise. It is not expected that all participants will answer all questions.
1. What barriers do you see to establishing a community of application developers for creating applications for NASA ground and space communication systems to enable reuse of SDR applications? a. What platform properties are necessary to reduce the burden? b. What features make it easier to produce third party applications? c. What component architectures being considered enable software and firmware reuse? d. Any suggestions for dealing with the data rights issues inherent in software sharing? 2. How are SDR technologies being used in the current developments of space radios? a. Are space customers requesting in-flight reconfigurability in their radios? b. What are the major impediments to providing reconfigurability in space? Frequency of reconfiguration? Mission criticality? c. Anticipating using an SDR for a mission critical command link? What will it take for mission developers to trust the SDR as the mission critical radio? 3. What is the state of the art of the near-term, space applicable technologies relevant for implementing a SDR in space? These technologies are likely to include: a. Hardware components such as memory, ADC/DACs, FPGAs, and processors b. Software and architectural concepts such use of multi-core processors, message passing structures, dynamic vs. static loading. The disposition of functionality between avionics and the radios is also of interest. 4. Assuming space customers will be expecting reconfiguration in the space environment in 20 years, what research interests are you pursuing or do you see being pursued which will enable this? How many have you developed in the last 5 years and number projected in the next 5 years. What type of product line that supports multiple customers requesting SDRs have you considered? 5. Discuss the need or lack of need for real time processing. 6. How do you address self test and automatic / self recovery and automatic reversion to known working version? 7. Do you have any recommendations for modifications or additions to the current version of the STRS standard? If yes, please include information on your current efforts related to STRS. Have you implemented an STRS Operating Environment or Application? Implemented a similar architecture? 8. What is the current state of the art in software defined radios that are capable of performing both RF (quadrature phase shift keying (QPSK) and gaussian minimum shift keying (GMSK) modulation; low-density parity-check (LDPC) and Turbo coding) and optical (pulse position modulation) communication? What kind of development would be necessary to design a combined RF and optical SDR? Would it be possible to start from an existing radio design (either RF or optical) and make additions of either RF or optical? Would it be preferable to start over with a new radio design? What would an ideal combined RF and optical SDR design look like? 5 Submittal Instructions:
1. Please email relevant literature and information no later than 5:00pm EST on September 30, 2014 to: To: Melissa.A.Merrill@nasa.gov Cc: STRS-comments@lists.nasa.gov Subject: “NASA GRC SDR Technology RFI”. Do not email sensitive data unencrypted. If you need to send an encrypted email please contact us first to give you further instructions.
2. Any electronic file submitted in response to this RFI shall be in either Microsoft Word, or PDF (PDF is preferred). If practical, please limit the number of pages to less than 10. As part of your information package, please include company Technical Point(s) of Contact including address, telephone number and e-mail address.
3. Information Protection: NASA anticipates using support service contractors and Jet Propulsion Laboratory (JPL) contractors in the assessment of partner submittals. All information received in response to this notice that is marked Proprietary will be handled and protected accordingly. NASA support service and JPL contractors are under an obligation to keep third-party proprietary information in confidence. By submitting a response to this notice, the responder is deemed to have consented to release of proprietary data to such NASA support service and JPL contractors.
4. At its discretion, NASA may request further discussions and/or clarification of the information submitted. If agreeable to both parties, such discussions may take place via video teleconferencing, or an on-site visit to NASA Glenn Research Center in Cleveland, Ohio, or at a conference or other venue, at the responder’s expense. If they do occur, discussions will be constrained to a two hour time duration, and will consist of vendor presentations and subsequent discussions of the presented material only. Representatives from the United States Government Agencies and its contractors may be present for such discussions.
5. Questions and requests clarifications may be sent to : To: Melissa.A.Merrill@nasa.gov Cc: STRS-comments@lists.nasa.gov Subject: “NASA GRC SDR Technology RFI Questions” No phone calls will be accepted. It is at the discretion of NASA whether to reply or not to submitted questions and requests for clarification.
THIS RFI IS ISSUED SOLELY FOR INFORMATION AND PLANNING PURPOSES AND DOES NOT CONSTITUTE A SOLICITATION. Responses to this RFI will not be returned. Responders are solely responsible for all expenses associated with any response to this RFI.
This Request for Information is not to be construed as a commitment by the Government, nor will the Government pay for the information submitted in response. Respondents will not be notified of the results.
An ombudsman has been appointed — See NASA Specific Note “B”.
The solicitation and any documents related to this RFI will be available over the Internet. These documents will reside on a World Wide Web (WWW) server, which may be accessed using a WWW browser application. The Internet site, or URL, for the NASA/GRC Business Opportunities home page is https://www.fbo.gov/?s=opportunity&tab=search&mode=list . It is the offeror’s responsibility to monitor the Internet site for the release of the solicitation and amendments (if any). Potential offerors will be responsible for downloading their own copy of the solicitation and amendments, if any.
NOTE: All prospective companies should update or create user accounts in the System for Award Management (SAM) at https://www.sam.gov/portal/public/SAM/#1
Point of Contact
Name: Melissa A Merrill
Title: Contract Specialist
Phone: 216-433-6359
Fax: 216-433-5489
Email: Melissa.A.Merrill@nasa.gov
