Mega Constellation Downlink

On the Use of Mega Constellation Services in Space: Integrating LEO Platforms into 6G Non-Terrestrial Networks

Dec 02, 20247 min read

Paper Details

AuthorsGabriel Maiolini Capez, Mauricio A. Cáceres, Roberto Armellin, Chris P. Bridges, Juan A. Fraire, Stefan Frey, Roberto Garello
PulbicationIEEE Journal on Selected Areas in Communications
doi10.1109/JSAC.2024.3459078

Summary

The paper describes the idea of attaching a satellite in a “lower” LEO to a mega constellation in a “higher” LEO. Primary contributions are a framework for analysis of such a system, and a baseline system model.

General Thoughts

Very important paper in the context of our project as it deals directly with the subject matter.
However it also leaves room for improvements, as the paper doesn’t delve into the exact implementations of the system, and “only” deals with the problem from a relatively large meta perspective.

For most of the results they only use OneWeb, as it is the constellation with higher altitudes and is therefore maybe also more suited for the task. However it seems OneWeb is struggling in the real world so maybe we should do some analysis on only starlink?

Good Things

I like the methods for evaluation / simulation the paper proposes and we could more or less use their methods exactly as they are built to deal with this exact system model.

They provide a lot of good

Room for Improvement

The fact that they use the same connection for both “UE’s” and “gNB’s” is smart as it can be sold as a more versatile system, however the two implementations have vastly different implications for requirements wrt. latency and throughput.
Focusing on one aspect (most probably UE) may be advantageous.

They don’t assume any beamforming from the UE, leaving it up to the satellite designer to implement. This may be an area to improve the link and create a general solution to this.

For most of the results they only use OneWeb, as it is the constellation with higher altitudes and is therefore maybe also more suited for the task. However it seems OneWeb is struggling in the real world so maybe we should do some analysis on only starlink?

Edit note

Annotations

Highlight ColorMeaning
RedAim to Improve
YellowNeutral comments
GreenAim to replicate
BlueFurther Reading

  • “Missing these brief communication windows results in delays from several minutes to hours before the next opportunity arises” Page - As we also try to argue, the resulting delays are high


  • “6G Next Generation NodeB” Page 2 - Is this a standard thing?

  • “Current commercial MEO and LEO optical data relay constellations, such as Kepler’s…Aether Optical High-Data Rate Service [13],” Page 3 - FSO Data relay systems

  • “However, these optical systems’ premium cost and rigorous operational demands have led us to exclude them from our comparative analysis, focusing instead on more established and broadly applicable RF data relay solutions.” Page 3

  • “The core opportunities and challenges of inter-satellite links are discussed by Kodheli et al. in [4].” Page 3

  • “The exploration of leveraging LEO mega-constellation linksfor communication began with H. Al-Hraishawi et al. in 2021 [26], where multi-layer space information networks were considered. This concept was further expanded upon by G.Maiolini Capez et al. in 2023 with a detailed characterizationof the Mega-Constellation links for LEO Missions [27]. Inthe same year, H. Chougrani et al. contributed a feasibility study, emphasizing the significant potential of MCSS [28].” Page 4

    • further_reading
    • We should look into these papers for historical context / citations

  • “Starlink and OneWeb operate in overlapping frequency” Page 4

  • “bands and share similar terminal configurations, hinting at the possibility of future terminals seamlessly switching between these networks” Page 5-

  • “FCC filings related to Earth Stations (termi-nals, gateways) and Space Stations (satellites) of specific satel-lite operators [38], [39]” Page 5

  • “Finally, we consider the link budget analysis outlined in [41].” Page 5

  • “Our previous study in [27] thoroughly ana-lyzed the Doppler effect within the MCSS framework” Page 6

  • “We determined that in the Ku-band, SUTs experience a maximum Doppler offset of up to 550 kHz. The Doppler rates observed range from below 2 kHz/s at elevation angles lower than 70 degrees to approximately 20 kHz/s when the satellite is directly overhead (at the Zenith).” Page 6

    • doppler
    • Interesting findings about doppler

  • “This approach allows us to explore how MCSS can leverage standard 5G-NR bandwidths and adapt to conventional 5G parameters, such as 5, 10, and 20 MHz bandwidths” Page 6

    • 5G-NR,bandwidth
    • How they choosed the bandwidth for the communication channel

  • “we apply a 20% reductionto the calculated capacity. Additionally, we consider a 20% protocol overhead in our calculations.” Page 7

  • “(SC-FDMA)” Page 7

  • “It was determined that starting with 5000 SUTs yields a robust estimate of system capacity with a 60-second timestep across a 24-hour window. For latency metrics, we ran simulations with 19650 LEO users from the OneWeb constellation at one-second intervals over 128 minutes, guaranteeing the capture of a complete orbital period for every user’s trajectory.” Page 7

    • simulation
    • We can maybe use these simulation parameters

  • “Insteadof delineating specific antenna beams, a satellite’s visibility isdetermined solely based on the off-Zenith angle, providingterminal designers with the flexibility to optimize antennadesign within the bounds of a viable minimum elevationangle. This approach simplifies the design process, although aspecific radiation pattern mask can be applied if detailed beamcharacterization is necessary” Page 8

    • room_for_impovement
    • This leaves room for focusing on beamforming from the UE for possibly better results

  • “For the purposes outlined in this paper,we have chosen to fix the user bandwidth and focus on opti-mizing the Modulation and Coding Scheme (MCS) selection.” Page 9


    • metrics,table,application
    • Application parameterization table, to be considered together with other tables, like it, from other papers.

  • “An alternative approach for high-altitude users could be using the side lobes of constellation satellites, though this introduces challenges in managing interference between beams.” Page 11

  • “Fig. 7: MCSS Latency for CC configuration and OneWeb constellation. The Z-axis is limited to 600 seconds (10 minutes). Black indicates no coverage/latency. White corresponds to nominal mega-constellation latency (about 50 ms).” Page 11

    • possible_improvements
    • For most of these figures they only use OneWeb, as it is the constellation with higher altitudes and is therefore maybe also more suited for the task. However it seems OneWeb is struggling in the real world so maybe we should do some analysis on only starlink?

  • “Terrestrial demands typically utilize 20-30% of network resources, with satellites often reaching total capacity during peak times [50].” Page 12

  • “With dynamic traffic patterns and congestion management requirements, up to 90% of capacity may be reserved for ground users. Given these conditions, the system could support approximately 4,000 SUTs in the High-End (HE) configuration to 100,000 SUTs in the Low-End (LE) configuration.” Page 12

    • capacity
    • They dont show how they get to this number But very interesting.

  • “Further research for future studies includes service and technical aspects like licensing, addressing, routing, compatibility, channel allocation, more sophisticated handover criteria, and interference mitigation.” Page 12


Graph View

Backlinks

  • No backlinks found

Recent Notes