NASA Solicitation: Microwave and Communications Systems Branch Surface Wireless Concepts
Synopsis – Sep 17, 2009
General Information
Solicitation Number: NASA-GSFC-RFI-SURFACE-WIRELESS-CONCEPTS
Posted Date: Sep 17, 2009
FedBizOpps Posted Date: Sep 17, 2009
Recovery and Reinvestment Act Action: No
Original Response Date: Nov 06, 2009
Current Response Date: Nov 06, 2009
Classification Code: A — Research and Development
NAICS Code: 334220 – Radio and Television Broadcasting and Wireless Communications Equipment Manufacturing
Contracting Office Address
NASA/Goddard Space Flight Center, Code 210.S, Greenbelt, MD 20771
Description
Microwave and Communication Systems Branch
Surface Wireless Concepts
Request for Information
THIS IS *NOT* A REQUEST FOR PROPOSAL, QUOTATION, OR INVITATION TO BID NOTICE.
Overview
NASA is currently developing an architecture and concept of operations for communications and tracking on the lunar surface or other small planetary bodies. Under the Constellation Program, there will be vehicles, habitats, science equipment, and EVA crewmembers on the lunar surface. There is a strong belief that long haul communications direct to Earth, or to a lunar relay satellite system, will be traditional point-to-point microwave links at S-Band or Ka-Band, and/or optical communication links. These will be implemented via “gateway nodes” on the lunar surface, such as a Ka-Band or optical transmitter on the Altair Lunar Lander. Short range communications between various entities and the gateway nodes needs to be implemented. Using an international standard, such as something based on the IEEE 802.xx family, appears to be ideal for surface short range communications. For example, EVA crew members or science packages could be connected to Altair or a lunar rover via 802.16 or 802.11. Some systems will be fixed while others, such as EVA crew members and rovers, will be mobile. The network will need to support voice, data / telemetry, and multiple streams of standard and high definition video. The Constellation Program’s communications architecture is IP based and that is expected to continue on the lunar surface.
Whatever architecture is developed should also be suitable for surface communications at other destinations in the solar system, such as on an asteroid or on a moon of Mars. With limited technology development funds, having a destination independent architecture is critical.
Why IEEE 802.xx?
NASA would like to use a non-proprietary international standard on the lunar surface. This should help foster communications between NASA provided systems and any commercial or international systems. A robust Media Access Control (MAC) protocol that provides maximum flexibility would be extremely useful in developing and operating a lunar outpost.
Using a commercial wireless standard should reduce life cycle costs in developing, deploying, and operating lunar surface communication systems. Given the widespread deployment of 802.11 networks around the world, it is natural to ask whether 802.11 or another 802 standard, such as 802.16, could likewise be deployed on the Moon. This is especially true since NASA doesn’t really understand all of the requirements that have to be met. Starting with a commercial standard forces people to ask if something is really a “requirement” if meeting that requirement means moving away from the standard. Thus a standard could also help prevent “requirements creep”.
However, as NASA’s concepts mature, it may turn out that it is impossible to meet all of the requirements with an off-the-shelf standard. Thus it may be necessary to make minor modifications. Slightly modifying an international standard is perceived to be better, in terms of meeting schedule and reducing life cycle costs, than for NASA to develop everything on its own.
An IEEE 802 architecture should also work at other locations in the solar system, such as on a small asteroid or on a moon of Mars. Thus this appears to be a good approach even if NASA’s exploration plans change in the near future.
Scenarios
There are two near term scenarios under study:
a. Lunar Sortie Scenario:
The Lunar Sortie Scenario is very similar to Apollo. This scenario assumes an Altair, an Apollo-class rover to provide some mobility, and two simultaneous EVA activities. One EVA activity will be further away from Altair in the vicinity of the rover and one will be within the vicinity of Altair. The communication architecture needs to support multiple simultaneous links and multi-hopping capability.
b. Lunar Outpost Scenario:
In the Lunar Outpost Scenario, outpost buildup and science excursions are assumed to be going on simultaneously. There would be a small habitat zone which would contain a cargo handling unit in addition to a habitat facility and Altair. Multiple small pressurized rovers would allow the crew to travel further from the habitat zone for science excursion. A surface wireless network would allow the EVA crews to communicate to/through the other lunar surface elements. Like before, while not a firm requirement, the EVA Project Office would like direct point to point links between crew members of the EVA team; in other words, without going through an intermediate node or access point.
Requested Response
The Microwave and Communication Systems Branch at NASA Goddard Space Flight Center requests that interested parties provide inputs and suggestions as to how the IEEE 802.xx family could be best used to achieve the communication goals of the Constellation Program. Responses may include component or system level concepts including how to implement IEEE 802 based communication systems in the lunar environment. The branch is interested in learning of individual component technologies as well as complete system concepts.
Hardware implementation options need to meet space qualification and radiation exposure requirements for lunar operations. Discussion should clearly demonstrate capability to implement design solution in space qualified hardware or define a transition path to qualified hardware and identify associated risks. For lunar operations the proposal should assume operations over a 10 years period (TBR) and a total exposure of 1.5 kRAD (TBR) of total induced radiation (TID). Discuss how proposed solution mitigates single event upset (SEU) effects and provides single event latch-up (SEL) immunity.
Cost and schedule are discriminators in the eventual selection of any solution. However, the branch is very interested in learning of potential technology developments that could benefit Constellation and the Agency.
In addition to the general concept discussed above, the branch requests information on the following topics. Interested parties do not have to respond all of the following topics if they do not apply to their proposed component / technology / system.
1. Discuss a minimum cost, minimum risk method of implementing an IEEE 802 wireless architecture on the lunar surface to support Constellation. Discuss the proposed system and components. Discuss which frequency bands should be used with considerations of terrain and possible interference from sources on the Earth. Provide Rough Order of Magnitude (ROM) estimates for Non-Recurring Engineering (NRE) and procurement costs as well as schedule estimates after receipt of order (ARO). Discuss expected mechanical, thermal, mass and power requirements.
2. Discuss a minimum size, weight, and power method of implementing an IEEE 802 wireless architecture. Note that this may be different than (1) since the goal here is to minimize SWAP. Provide ROM estimates for NRE and procurement costs as well as schedule estimates ARO.
3. Discuss the impact on the total capacity of the 802.xx network if the data rates of the users differ by more than a factor of 10 among the users. What impact would there be if some of the users limited signal level adjustments and all the users had more than a factor of 10 data rate needs between the minimum data rates and the maximum data rates?
4. Discuss how data can be relayed between an edge user, such as an astronaut on EVA or a small robot with limited communication transmit power, to a larger mobile user and then the data be relayed back to a central communication node. Discuss the frequency and timing requirements for all the elements.
5. Discuss what modifications could be made to the IEEE 802 family to support navigational / tracking needs. This could include making Doppler and range measurements, or being as simple as just providing time of flight measurements. Providing radiometrics to support navigation is not a firm requirement for the lunar surface wireless architecture, but it would be beneficial. Discuss how those modifications would be accomplished.
6. Discuss a method of providing point-to-point “ad hoc” links without going through an access point to support the EVA Project Office’s desire for crew members to be able to communicate with each other without any other infrastructure. While not a firm requirement, this would be useful in a “walk back” situation where a team has to walk a maximum of 10 kilometers to get back to Altair or the habitat in case of failure of the rover. As an alternative concept, what can be done to support the “walk back” scenario that doesn’t include custom modifying an 802 protocol?
7. How can the IEEE 802 concept be extended to support other NASA missions, not necessarily on the lunar surface? For example, if NASA developed space qualified IEEE 802 radio systems, are there scenarios in space, as opposed to a planetary surface, that could make use of the technology?
8. Discuss options to incorporate mesh networking or other approaches to extend the range of the network with minimal increases in power or impacts to network reliability.
9. Discuss a reconfigurable method of achieving the communication goals of the Constellation Program. The systems should be adaptable and reconfigurable by software / firmware load while on the lunar surface. The branch wishes to consider this option to understand the implications of building adaptability to support future technologies that may be developed as the program moves forward. This would also be extremely important if more than one IEEE 802 protocol is used, such as 802.11 and 802.16. Discuss the proposed architecture and components. Provide ROM estimates for NRE and procurement costs as well as schedule estimates ARO. Discuss expected mechanical, thermal, mass and power requirements of this solution.
10. Discuss a minimum hardware option that aims to combine the ability to support 802 for the lunar surface as well as higher power conventional S-Band microwave links for the direct to Earth or direct to lunar relay satellite need. There will be platforms, such as Altair, that will be required to support both functionalities. Discuss the proposed architecture and components. Provide ROM estimates for NRE and procurement costs as well as schedule estimates ARO. Discuss expected mechanical, thermal, mass and power requirements of this solution.
11. Discuss any other communications and tracking methods, options or technologies you believe of benefit to the Constellation Program. Topics of interest include Delay Tolerant Networking (DTN) and data routing strategies.
Information submitted to GSFC in response to this RFI will be treated as strictly proprietary unless otherwise indicated. No procurement is planned as a direct result of this Request for Information. Information submitted in response to this Request for Information will be used for Constellation development activities. Parties proposing concepts of interest to GSFC and Constellation may be invited to submit more detailed information or to discuss their concepts further.
It is emphasized that this RFI is for planning and information purposes only and is NOT to be construed as a commitment by the Government to enter into a contractual agreement, nor will the Government pay for information solicited.
No solicitation exists; therefore, do not request a copy of the solicitation. If a solicitation is released, it will be synopsized in FedBizOpps and on the NASA Acquisition Internet Service. It is the potential offeror’s responsibility to monitor these sites for the release of any solicitation or synopsis.
Technical questions should be directed to: Bernard Edwards at (301) 286-8926 or Bernard.L.Edwards@nasa.gov.
Interested offerors shall address the requirements of this RFI in written format as described in the previous paragraphs by electronic mail to: Bernard Edwards at Bernard.L.Edwards@nasa.gov no later than 5:00 PM EST on November 6, 2009.
An ombudsman has been appointed — See NASA Specific Note “B”.
The solicitation and any documents related to this procurement 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/GSFC Business Opportunities home page is http://prod.nais.nasa.gov/cgi-bin/eps/bizops.cgi?gr=D&pin=51 . It is the offeror’s responsibility to monitor the Internet cite 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.
Any referenced notes may be viewed at the following URLs linked below.
Point of Contact
Name: Bernard L Edwards
Title: Chief Communications Systems Engineer
Phone: 301-286-8926
Fax: 301-286-1750
Email: Bernard.L.Edwards@nasa.gov
