[Sois-sdr] RE: Kickoff

[Enoch, Michael]

Hi Larry (& et al)

Thanks for the slide link

An element of interest to me is thinking about how SDR for space might be different than "conventional" or "terrestrial" SDR systems, across the spectrum of views (operational, system, interface, services, etc).

It might also be useful to express where/how this group thinks it should relate to similar or related efforts within SDR Forum and OMG?  For that matter, how should this effort relate to the other efforts within CCSDS outside of SOIS?

Given the potential range of usages for SDR in space, I think it would be worthwhile to try to capture and articulate a couple of the usage scenarios that might serve as uses cases to help define or bound the scope of this group and help with the process of defining a charter...

1) Spacecraft TT&C related communications - typically needs low data rate but high reliability links with high degree of protection/security (at least on command transfers) on an occasional basis to support mission operations.  May operate in broadcast (omni) mode for transmit and receive at S/C to mitigate pointing concerns but may also operate using point-to-point link services.

2) Mission/Payload related communications  - driven by mission sensor data generation needs but may scale from low to high to very high data rates with periodic to continuous transmission requirements with variable quality of service and security needs (mission dependent).  May operate in a point to point, multi-cast or broadcast mode of operations, depending on specific mission.

3) Proximity operations - typically local area space to space communications for coordinating RPOD type activities.  Implies a situational awareness and potential closed loop control needs due to potential use for collision avoidance.  Viewed as similar to TT&C needs wrt data rates.  May have additional functionality embedded in comm system architecture for S/C identification and location information provisioning

4) Cluster/Constellation related communications  - Virtual spacecraft data bus for "distributed spacecraft" concepts that provides the means for transferring data and other spacecraft related "bus services" needed for mission operations. "Distributed spacecraft" concepts may necessitate  (or at least raise the potential) for special features in the comm system architecture, similar to prox ops, but may include timing and frequency distribution and precision relative navigation metrology

5) Navigation, Tracking and/or Data Relay related communications  - SDR as a payload for supporting space operations, such as providing navigation reference signals, performing tracking of incoming signals and/or serving as a bent pipe or processing repeater of some sort. (SATCOM payload systems could also fall into this category, as well as TDRS and GPS type systems)

6) Multi-function Software Defined RF Payloads - SDR systems that can serve multiple purposes, such as act as radar, comm system and even sensor payload for RF sensing missions.

7) Wireless spacecraft bus - SDR as a means of implementing a wireless databus for spacecraft command and control as an alternative to wired (MIL-STD-1553, SpaceWire, optical fiber) options for distributing services within the spacecraft

Regards

Michael

Michael Enoch
Sr. Staff Systems Engineer
Lockheed Martin Space Systems Company
2100 Airpark Road SE
Suite 150 East
Albuquerque, NM 87106
Voice: 505-222-6084
Mobile: 505-301-1166
Pager: 888-861-1141
SMS: 8888611141 at page.metrocall.com
Email: michael.enoch at lmco.com



________________________________
From: sois-sdr-bounces at mailman.ccsds.org [mailto:sois-sdr-bounces at mailman.ccsds.org] On Behalf Of Foore, Larry R. (GRC-RHD0)
Sent: Monday, August 09, 2010 2:48 PM
To: sois-sdr at mailman.ccsds.org
Subject: EXTERNAL: [Sois-sdr] Kickoff

All,
Thanks for subscribing to the mailing list.  In approximately one month, I'll report to Adrian the membership of this list and hopefully any pros/cons we jointly discuss regarding addressing reconfigurable platforms within CCSDS.

What may be an instructive exercise is to consider how Prox-1 may be implemented and fielded on two separately developed/provided SDRs.  What would need to be clarified for waveform developers and/or system integrators to ensure interoperability?  Would it be limited to a common lexicon for SDRs, or perhaps more?  Is a reference architecture necessary with clearly articulated and supported functions?  These are just a few questions to get a dialogue going.

Perhaps such a dialogue would help us understand 1) the necessity (or lack thereof) of an SDR WG, 2) the bounds of such a group, and 3) the objectives of such a group.

As a matter of reference, the content of the STRS Architecture lunchtime talk during the Spring CCSDS meeting in Portsmouth, VA can be found here:

http://public.ccsds.org/meetings/2010Spring/Tech/lunchtime/Foore-CCSDS%20STRS%20Presentation%20May%203rd.pdf


Thanks again,
Larry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-sdr/attachments/20100817/99334043/attachment.html