Using hosted payloads to architect near Earth space communica5on networks

Transcription

1 Using hosted payloads to architect near Earth space communica5on networks Marc Sanchez Net, Inigo del Por5llo 2nd Interna5onal Federated Satellite Systems Workshop October 14th 2014 Marc Sanchez Net 1

2 Outline Introduc9on Research ques9on and approach Tool overview Problem formula9on User Defini9on Metrics & Sa9sfac9on Communica9on Technology Results Tradespace explora9on HP mass and power Conclusions Marc Sanchez Net 2

3 Introduc5on Federated Satellite Network IRIS ARTES Private Networks Examples of hosted payloads Payload Satellite Mass Power Volume Data- Rate Type Owner (kg) (W) (m3) (bps) WAAS Intelsat M comm AIS Orbcomm k comm IRIS Intelsat M router CHIRP AGS M sensor ADF Intelsat k comm Commercially Hosted Government Payloads: Lessons from Recent Programs Marc Sanchez Net <msnet@mit.edu> 3

4 Research Ques5on and Approach Can current hosted payload opportuni5es be used to architect networks to successfully addresses the communica5on needs of near- Earth scien5fic missions? Scenario defini5on Stakeholder decomposi9on Comm. service specifica9on: Comm. Conops Requirement weights Hosted payload opportuni5es Iridium Next and Prime (LEO) GPS (MEO) Inmarsat/Intelsat (GEO) Comm. technology S, Ku, Ka payloads Op9cal telescopes ITACA Tradespace Explora5on Comparison of LEO, MEO and GEO constella9ons Tradespace drivers User sa9sfac9on HP feasibility analysis Mass limita9ons Power limita9ons Marc Sanchez Net 4

5 Integrated Tradespace Analysis of Communica9ons Architectures (ITACA) Inputs Tradespace defini5on 1. Antenna selec9on 2. Antenna alloca9on 3. ISL antenna selec9on 4. Network type 5. Contract modali9es 6. Frac9ona9on strategy 7. Relay ground sta9ons 8. User ground sta9ons Rule- based System Search Strategy Architecture Space and ground segment design Lifecycle Cost TDRSS-like arch 3 satellites 6 satellites 9 satellites Outputs Normalized Benefit Network Evaluator Cost Es9mator User Needs Timeframe: Mission classes: Number of expected missions Comm. requirements Conops Metrics For each architecture Network performance (data volume, latency, user burden) Relay spacecrae design Breakdown cost structure for the network Marc Sanchez Net <msnet@mit.edu> 5

6 Scenario Defini5on Payloads and buses Payload Characteris5cs Payload data is similar to the one actually developed by NASA for TDRSS- based (SMA and RF payloads) LCRD- based (Op9cal payload) SMA Max gain 12 db Max Rb 1 Mbps Power TX 8.92 W # beams 5 Modula5on M- PSK OPTICAL Mass 69 kg Power 130 W Power TX 0.5 W Dimensions 50x50x20 cm. # beams 1 Max Rb 622 Mbps Modula5on PPM Similar to Sat. Mass Sat. Power HP Mass HP Power [kg] [W] [kg] [W] Intelsat GPS III (*) 450(*) Iridium GPS III Host Spacecra` Iridium Next SA S- band Ku- band Ka- band Mass Power Power TX 29.5 W 1.32 W 8.13 W Dimensions Max Rb 6 Mbps 300 Mbps 600 Mbps Modula5on M- PSK M- PSK M- PSK Intelsat (*) Es9mated Marc Sanchez Net <msnet@mit.edu> 6

7 Scenario Defini5on Architectures Host spacecrae SMA Opt SA Host spectrum SMA Opt GEO (Intelsat) 3 sats SMA Opt SA Host spectrum SMA Opt MEO (GPS III) 24 sats SMA Opt SMA ISL HP spectrum Opt LEO (Iridium) 66 sats Marc Sanchez Net <msnet@mit.edu> 7

8 Scenario Defini5on User Defini5on Category Number of Users Service Total DV per day (Gb) & user Examples Cubesats 15 Polar Orbit 35 Equatorial Orbit # contacts 70 dura5on 300 s data- rate 1 Mbps 20 SwissCube, SmallSats 5 Polar Orbit 5 Equatorial Orbit # contacts 56 dura5on 450 s data- rate 4 Mbps 100 Jason- 1, Myriade LEO Sci- Low 5 Polar Orbit 5 Equatorial Orbit # contacts 56 dura5on 450 s data- rate 4 Mbps 100 # contacts 56 LEO Sci- Mod 3 dura5on 450 s 200 ICE Sat II data- rate 8 Mbps # contacts 56 LEO Sci- High 2 dura5on 450 s 1000 SWOT data- rate 40 Mbps # contacts 56 dura5on 450 s data- rate 120 Mbps LEO Sci- Ultra HST, NI- SAR # contacts 15 dura5on 5300s data- rate 150 Mbps HSF ISS Marc Sanchez Net <msnet@mit.edu> 8

9 Scenario Defini5on Metrics & Sa5sfac5on Metric Weigh5ng Data Volume User Burder Latency 1 Metrics weight is assigned depending on the type of user Small satellites are concerned about the user burden Large spacecrae give more importance to the data- volume downloaded. HSF is really concerned about latency of the data. Users Weigh5ng to calculate Sa5sfac5on Human missions account for 50 % of the benefit The LEO- Sci_UltraH user weight is higher than the SmallSats, LEO- Sci- Low & Cubesats together. LEO-Sci-Mod (10 %) SmallSats (5 %) LEO-Sci-Low (5 %) HSF CubeSats LEO-Sci-UHigh LEO-Sci-High LEO-Sci-High (12.5 %) HSF (50 %) LEO-Sci-Mod LEO-Sci-Low SmallSats Metric Weight LEO-Sci-UltraH (15 %) CubeSats (2.5 %) Marc Sanchez Net <msnet@mit.edu> 9

10 Results (I) GEO architectures are cri9cal to service full coverage users. Antennas Benefit Cost (M$) ΔBenefit LEO SMA 2x op9cal % SMA % 2x op5cal % SMA Op9cal % MEO SMA % Op5cal % Cost LEO > Cost MEO > Cost GEO Op9cal communica9ons dominate RF Adding the SMA to an op9cal telescope decreases benefit due to user burden Phased array + Op9cal outperforms combined low frequency/high frequency antenna GEO RF (S, Ka, Ku) % SMA Op9cal % SMA % Op5cal % RF (S, Ka, Ku) % Marc Sanchez Net <msnet@mit.edu> 10

11 Hosted payload mass Marc Sanchez Net 11

12 Hosted payload power Marc Sanchez Net 12

13 Conclusions A distributed communica9on network based on hosted payloads can successfully sa9sfy the needs of future missions However, the results of this study have highlighted that: MEO and LEO networks can easily provide connec5vity to medium/ small scien5fic missions and cubesats. Advancements in op9cal communica9ons are key to developing HP- based networks. Current HP opportuni9es are capable of hos9ng the high data rate payloads, however signal processing and reconfigurability will be key. It is not only about the user to relay link. Spectrum alloca9ons for the host spacecrae are key to what the HP can provide. Other issues: legal, tes9ng and integra9on, other programma9cal Marc Sanchez Net <msnet@mit.edu> 13

14 Backup Slides Marc Sanchez Net 14

15 Implementa5on details of ITACA ITACA TRADESPACE EVALUATION DATABASE INPUT FILE PARSER TRADESPACE EXPLORER SCENARIO DEFINITION STK PRE- COMPUTATION SEARCH STRATEGY RESOURCE MANAGER TRADEPACE VISUALIZER ARCHITECTURE EVALUATOR INPUTS FILE VISIBILITY WINDOWS FILE PERFORMANCE EVALUATOR SPACE & GROUND SEGMENT DESIGN COST EVLUATOR RESULTS FILE RESULT RESULTS MANAGER ITACA is implemented using 3 programming languages: MATLAB: User interfaces, data visualiza9on, post processing & scrip9ng Java: Infrastructure (execu9on paralleliza9on, data storing). Computa9on intensive ITACA is implemented using 3 programming languages: MATLAB: Marc Sanchez Net <msnet@mit.edu> 15

16 ARCHITECTURE Architecture Evalua5on ANTENNA PAYLOAD USER MANIFEST DEMANDS Generates Antenna, User, Ground Sta9on facts from Architecture. Inherits values from database Translates User requirements into contact informa9on. PAYLOAD PAYLOAD DESIGN SPACECRAFT DESIGN Computes Mass and Power of the relay satellites. This is the driver for the satellite design Computes Mass and Power of the rest of subsystems of the relay satellites. REQ- CONTACT SATELLITE ANTENNA DESIGN ANTENNAS Sizes the antennas so that the link can be closed. as LAUNCH VEHICLE SELECTION Allocates the designed satellites into available launch- vehicles PATHS Loads fies precomputed with STK LAUNCH- VEHICLE VISIBILITY WINDOWS SCHEDULING Assigns visibility windows to each contact COST ESTIMATION Computes costs for different assets and es9mates total cost SCH- CONTACT VASSAR CAPABILITIES SATISFACTION Using the informa9on of the schedule computes what are the capabili9es of the system. (i.e: what s the latency for a user) Computes the sa9sfac9on of each stakeholder based on the capabil9es of the network. Aggregates the capabili9es to stakeholder. RESULT Benefit Cost FACTS (Traceable design) Legend General Execu9on Time for 3 satellites in GEO Marc Sanchez Net <msnet@mit.edu> is something between 10 and 60 s. 16 Performance Evalua9on Cost Evalua9on

17 Rule Based Expert Systems: An Example FACTS It is raining There is an umbrella Iñigo has to go out INFERENCE ENGINE RULES If it is raining and you have to go out then take an umbrella The inference engine implements an efficient algorithm to perform the many to many parern matching. It is called the Rete algorithm. (defrule MAIN::take-an-umbrella-if-its-raining (MAIN::WEATHER (status raining))?p <- (MAIN::PERSON (name?name) (has-to-go-out yes)) => (modify?p (has-an-umbrella yes)) ) (defrule MAIN::take-an-umbrella-if-its-raining-2 (MAIN::WEATHER (status raining))?p <- (MAIN::PERSON (name?name) (has-to-go-out yes))?u <- (MAIN::UMBRELLA) => (modify?p (has-an-umbrella yes)) (retract?u) ) Marc Sanchez Net <msnet@mit.edu> 17

18 Introduc5on FSS Network Topology Iridium Next Alphasat IRIS ARTES RF vs. Op9cal Access Mechanism Rou9ng Mechanism Manual vs. Autonomous Sta9c vs. Dynamic Privately owned Hosted Payloads Business Model Network Capacity Payload Satellite Mass Power Volume Data- Rate Type Owner (kg) (W) (m3) (bps) WAAS Intelsat M comm AIS Orbcomm k comm IRIS Intelsat M router CHIRP AGS M sensor ADF Intelsat k comm Commercially Hosted Government Payloads: Lessons from Recent Programs Marc Sanchez Net <msnet@mit.edu> 18