N. Pachler, I. del Portillo, E. F. Crawley and B. G. Cameron, “An Updated Comparison of Four Low Earth Orbit Satellite Constellation Systems to Provide Global Broadband,” 2021 IEEE International Conference on Communications Workshops (ICC Workshops), 2021, pp. 1-7, doi: 10.1109/ICCWorkshops50388.2021.9473799.

这篇文章发表在ICC的workshop上面,不算很正式,主要是对Portillo I D , Cameron B G , Crawley E F . A technical comparison of three low earth orbit satellite constellation systems to provide global broadband[J]. Acta Astronautica, 2019, 159(JUN.):123-135.的补充,对FCC的某些参数的修改以及Kuiper星座进行了补充,其实际的分析方法没有变化。关于前文的相关翻译分析工作可以看卫星与网络公众号的分析

摘要

二十年来技术一次又一次的尝试回答NGSO提供网络接入的问题。许多公司最近申请了新作,通过成千卫星以及更大规模的地站来完善并竞争于地面互联网基础设施。。本文从吞吐角度对Telesat,OneWeb,SpaceX,Amazon进行了对比分析。首先给出2021年1月的FCC文件中的星座描述,然后介绍了方法和模型,包括轨道动态性和天气情况。最后我们分析结果并讲述FCC参数变化对整体吞吐的影响以及平均利用率的影响。

尽管Telesat卫星最少,但由于其双网关连接及更广泛的领域的关注,获得和SpaceX类似的吞吐。尽管OneWeb的卫星利用率最低,但由于其最大的卫星群,OneWeb成功实现了第二高的吞吐量。最小仰角的减少以及高度提升了SpaceX的整体吞吐和利用率。Amazon实现了最高的吞吐,在53.4Tbps,代价是更大的地面部分。另外,增加20Gbps的ISL对所有系统有13%~42%的收益

introduction

A motivation

使用LEO提供全球宽带服务已经进行了30年,90年代Iridium和Globalstar就已经使用NGSO提供通信服务,但是由于经济上缺乏可行性而破产。在20年后,新的硬件和软件技术使运营商重新燃起了从太空覆盖全球互联网的兴趣。最近几年有多家公司向FCC申请了大型NGSO卫星星座,其中这四家由于规模和发展前景而引人注目。

新时代巨型星座在经济上的可行性取决于三个因素:提升但颗卫星性能(多亏了数字有效载荷、可操纵多波束天线、高级调制和编码(MODCOD)方案以及频率复用策略)、减少发射以及制造成本、以及经济提升引起的偏远地区对移动网络的需求的增加。技术的提升允许厂商设计超过1000颗卫星的结构并提供数十Tbps

上篇文章从宽带服务角度对比了三个星座,本篇文章根据FCC数据进行更新并加入了Amazon

B 相关工作

90年代一些LEO星座提供电话和其他通信服务,但由于商业原因没有获得成功,很多工作对这些失败进行了分析[3,4,5],[6,7]对GEO/MEO/LEO进行了系统性的对比以及技术挑战的讨论。

关于新系统,迄今为止的工作集中在估计卫星之间的碰撞概率[8]、分析[9]和提出解法[10]中。[11]对这些LEO以及GEO星座的碰撞情况进行了对比,但很少有文献对卫星的性能进行对比。[12]给出了当前的架构如何提升航海服务,而我们之前的工作从轨道和频率的角度详细对比了Telesat,OneWeb和SpaceX的系统性能。

C 目标

目标是以科学的视角模拟系统的性能,包括吞吐和利用率(2021年1月前)

D 概况

II介绍了四个星座的配置,III进行了方案和模型的介绍,IV给出结果,V进行总结

星座轨道配置

Telesat

两个阶段,第一阶段包含298颗第二阶段增加到1671颗。所有卫星分布在两类轨道中,极地轨道1015km倾角98.98,倾斜轨道1325km,倾角50.88。

第一阶段包含613极轨和2011倾斜轨道,为了提供服务这些卫星是必要的;第二阶段极轨变成2713,倾斜轨道变成4033。每个轨道都是为特定的目标而设计的,这使得Telesat能够更有效地为客户服务:极轨轨道旨在覆盖两极,而倾斜轨道则将大部分能力集中在人口稠密的地区。

ISL包含轨内和轨间的。机载载荷允许形成4个可操纵的网关波束加上24个可操纵和可成形的用户波束,而卫星资源如功率和带宽会动态的基于需求分配。网关波束将通过高达3.5米的天线连接到战略分布的网关站。使用17.8-20.2GHz的下行链路和27.5-30.0的上行链路

OneWeb

两阶段:初始阶段716颗,第二阶段到达6372颗,所有卫星都在1200km

第一阶段:极地轨道倾角87.9,,1249;倾斜轨道55°,816

第二阶段:目标是覆盖人口较多的区域,极轨:87.9,3649,倾斜轨道:55,3272;40,32*72

不使用ISL,因此服务在同一能见域(Field of Regard,FoR)中,因此需要很多网关。

初始星座中每个卫星有16个高椭圆用户波束。至于最后的部署,星座中的每颗卫星可以形成多达32个可操纵的用户波束。在这两种卫星中,卫星将能够形成至少两个可操纵的圆形网关波束。网关波束通过与网关链接来与用户通信,网关一般有2.4m-3.5m的天线。

频率:

网关上行:27.5-30.0;网关下行:17.8-19.3

用户上行:14.0-14.5,用户下行:10.7-12.7

SpaceX

这是操作性最强的一个星座,已经发射了数百卫星。根据提出的FCC文件,将会包含4408颗卫星,5个shell:540km,7222,53,2;550km,7222,53;560km,658,97.6;560,443,97.6;570,36*20,70;第一个shell为第一阶段且正在部署中。尽管看起来比其他的更具有层次感,但是也是相同的思想:首先完成全覆盖,然后在人口较多的区域增加卫星数。

Starlink计划使用激光ISL,从而即使不在FoR区域也能服务。初始发射中不包含ISL。每颗卫星都可以使用两种极化的全频率范围连接到网关,最多可以有四颗卫星同时连接到网关。SpaceX网关进行了全球化的部署,目前大多数网关的文件中都是使用了1.5m高的天线。与OneWeb相同,Starlink也使用Ka波段进行网关的通信和Ku波段进行用户通信。

网关:下行:17.8-19.3;上行:27.7-30.0

用户:下行10.7-12.7;上行14.0-14.5

亚马逊

在2019年最新提出的,将卫星分布在三个shell中,590km,33,2828;610km,42,3636;630km,51.9,3434。部署分为5个阶段,最终达到3236颗卫星。初始阶段,发射630km的一半1734由于缺少高倾角轨道,这个系统无法提供全球覆盖(即不能服务极地),而是集中于高需求区。

FCC文件中没有包含它们是否有ISL,如果没有ISL则无法服务无网关区(如航运)。与其他系统相同,他们的网关天线高度在1-2.4m。对频率使用:

网关:上行:27.5-30.0;下行17.7-20.2

用户:上行:28.35-30.0;下行:17.7-20.2

轨道配置对比

第一阶段部署计划:

最终部署结果

由于偏好的不同很难进行比较,但我们对一些普遍的规律进行观测。

首先,除亚马逊其他卫星都分配了部分卫星在极地轨道(12%-28%),这将允许这三个公司能够服务极地——一个一直没有被服务且难以到达的区域,并能服务全球任意区域的用户。另一方面,亚马逊将有效容量全都放置在人口集中的区域。所有公司的大部分容量(72%-88%)都在40-55纬度之间,该区域是地面用户最密集的。

最小仰角的讨论

由于最小仰角的不同,如图1中不同经纬度的视线内(Line of sight,LoS)的卫星数各不相同。但是当整个星座部署时,Telesat、OneWeb和SpaceX不太可能以如此低的仰角运行,因为这会对地面终端施加额外的限制,并由于更高的损失而降低有效吞吐量。从星座动态来看,这些数字似乎与初始部署有关,在初始部署中,仰角必须被拉长,以提供连续的覆盖。然而,当涉及到系统吞吐量估计时,我们认为基于文件中指定的角度来比较容量是不公平的,并且会导致混淆的结果,因为这可能不能代表他们的操作概念。因此我们将结果分为连股份:使用文件定义的仰角评估初始部署,而使用我们评估的仰角来仿真整体部署。

方法和模型

在我们之前的工作中已经给出了方法、模型和假设,下面给出简单的介绍。

大气模型:使用[24]中的ITU模型,考虑了气体,云,对流层闪烁和雨的损害

链路预算模型:链路预算和大气模型结合可计算不同大气条件下上下行链路可达数据速率。

需求模型:使用人口分布0.1°精确度的模型[25],假定10%人口接入,每个人平均流量300Kbps

地面段:使用遗传算法优化获取95%和99%的覆盖可用性

将每个卫星当作图中一个节点。其需求均匀的分布于视线范围内。卫星根据大气条件与地面站连接,并提供补给。卫星和同shell的前后左右相连。系统使用最大流算法。利用率计算方式是平均数据速率和最大数据速率(根据链路预算模型计算)之比

结果

对初始部署和最终部署结果进行分析,其中最终部署我们认为都有星间链路,不过实际上OneWeb和亚马逊目前没有ISL计划。

初始部署

图2展示了容量相较于地面站数量的函数。OneWeb和SpaceX我们认为没有ISL。telesat、oneweb、spacex、亚马逊没有ISL的吞吐为6.37,1.44,10.3,8.97Tbps。SpaceX吞吐最高但这需要两倍的地站天线数量——这是缺乏卫星数量以及ISL的直接结果。另外,尽管telesat和亚马逊的卫星数量更少,但是比oneweb更高,其背后的原因是使用两个卫星天线连接网关,而不是一个。他俩的瓶颈是网关上行链路,使用两条连接将允许它们二倍速率。Telesate和亚马逊如果使用20Gbps的ISL将会获取7.52和11.3sTbps的流量。

表III总结了四个星座的初始配置telesat能实现73.4%的利用率,主要是由于较小的仰角,双网关链接。表4则是之前的设计方案,相比下OneWeb由于更高的轨道饱和度而变差了,SpaceX由于轨道仰角的减少而变好了,而亚马逊如果不用ISL的话将取得和SpaceX相同的结果,因为二者的海拔相似。如果有ISL的话,它们将提升26%的利用率。

最终部署

这里的仰角设定为我们最终估计可用的仰角。我们模拟了不同仰角的星座,并计算了在-60◦到60◦纬度范围内的覆盖范围,图4是不同仰角下的覆盖率。由于系统希望使用最大的仰角来实现最大的覆盖,因此仰角设置为必须的仰角即可。因此我们最终的设定为:telesat40,oneweb70,spacex35,Amazon35。

图3是全部部署后的系统吞吐随着地站数量的变化。所有的系统将由于有了ISL而增加吞吐。由于星座配置不同,SpaceX在ISL的收益最大,而OneWeb的收益最少。考虑到卫星数量的庞大,网关数量增加是必要的,在所有例子中都需要超过3000的网关。

telesat由于有双网关连接系统因而能实现和SpaceX相同的吞吐,该系统也让亚马逊实现了最高的吞吐。另外,尽管OneWeb和Amazon的吞吐比telesat和spacex高,但这需要地面段有超出50%的网关。如果有50Gbps的ISL,四个公司将能有更高的吞吐,这一限制是最大卫星饱和与需求分布相结合的结果。

表V中是不同网关数和ISL配置下的吞吐的统计。对spacex和oneweb,网关数从2000到3000对整体吞吐的提升为6%和8%,而telesat和Amazon则是20%和23%。这仍然是因为双网关连接技术的影响。

表VI展示了利用率。当使用20GbpsISL的时候利用率分别是44,24,31,32,如果不用ISL的的时候OneWeb和Amazon分别会降至21.4和25.2。尽管使用了比初始星座多一个数量级的卫星,由于双网关通信和更高的海拔,Telesat设法保持40%以上的利用率,但Oneweb的利用率则由于卫星容量的提升而急剧下降(瓶颈由用户链接变成网关链接),恢复到了修改FCC之前的值。SpaceX由于仰角的降低和海拔的降低,利用率增加了25%。Amazon如果用ISL利用率与SpaceX类似,但不用ISL就下降很多总结

虽然Telesat的初始星座将卫星利用率提高了73%,但由于使用更大网络的回报递减,最终部署的结果恶化了先前的结果。双网关通信系统将卫星的最大有效容量提高了一倍,尽管卫星数量较少,但其吞吐量可与SpaceX相媲美
OneWeb初始吞吐最低的原因:用户链路的瓶颈、无ISL、无双网关链路。后面以更多数量的卫星和网关为代价实现了更高的吞吐
仰角的降低让SpaceX能提供更好的覆盖,利用率提升10%,吞吐增加3.5Tbps
Amazon吞吐最高,但需要约4000网关实现最高吞吐
OneWeb和Amazon都因为不用ISL导致更低的吞吐,而使用20Gbps的链接能实现13%~25%的提升
仿真显示所有星座可以提供数十Tbps的吞吐,这个量级的速率无法与当今地面网络竞争(地面网络由千计Tbps的量),但是能对地面网络的覆盖的完整度有所提升

2021 An Updated Comparison of Four Low Earth Orbit Satellite Constellation Systems to Provide Global相关推荐

  1. Telesat、OneWeb及SpaceX三个全球宽带低轨卫星星座系统的技术对比

    编者按:本文来自微信公众号"卫星与网络"(ID:satnetdy),作者Inigo del Portilloa,*, Bruce G. Cameronb, Edward F. Cr ...

  2. LaTeX学习笔记:使用bibtex引用参考文献

    最近在写小论文时频繁使用latex排版论文,在正文部分直接套用要投的期刊或者会议给出的模板,填入内容即可.但是在参考文献的引用时操作比较复杂,自己在编写时也遇到了一些问题,就在此总结一下 STEP 1 ...

  3. 数字集成电路面试常见问题_关于空间级集成电路的常见误解

    数字集成电路面试常见问题 对集成电路辐射硬度的常见误解 (Common misconceptions on the radiation hardness of integrated circuits) ...

  4. 大规模LEO星座波束管理调研报告

    大规模LEO星座波束管理调研报告 目录 一.绪论 3 1.1研究背景 3 1.2研究意义 4 二.相关理论 6 2.1 波束管理 6 2.2 多波束卫星通信系统(系统模型 7 2.3 场景模型(卫星信 ...

  5. 我国长征系列航天飞船剖解

    长征一号系列 长征一号 长征一号运载火箭于1965年开始研制,包括长征一号运载火箭和长征一号丁运载火箭两个型号,是一种三级火箭,主要用于发射近地轨道小型有效载荷.火箭全长29.86米,最大直径2.25 ...

  6. 深度强化学习在天基信息网络中的应用——现状与前景

    源自:系统工程与电子技术 作者:唐斯琪  潘志松  胡谷雨  吴炀  李云波 摘 要 未来天基信息网络(space information network, SIN)领域将面临由结构复杂.环境动态.业 ...

  7. 接入amazon avs_每日新闻综述:亚马逊将互联网接入推向全球的宏伟计划

    接入amazon avs Plus Snap's big push to stay relevant, Amazon's Alexa-powered AirPods alternatives, mor ...

  8. 成立一周?谷歌人工智能道德委员会解散了?近日,金山云和小米刚签订了不超过9000万的硬件产品供应协议,闹哪样? | 极客头条...

    关注并标星星CSDN云计算 极客头条:速递.最新.绝对有料.这里有企业新动.这里有业界要闻,打起十二分精神,紧跟fashion你可以的! 每周三次,打卡即read 更快.更全了解泛云圈精彩news g ...

  9. 为给全球提供互联网服务 这家公司决定发射3236颗卫星

    [TechWeb]4月6日消息,据国外媒体报道,亚马逊计划将3236颗网络卫星送入近地轨道(low Earth orbit),在全球提供互联网服务. 亚马逊 据外媒介绍,亚马逊近地轨道卫星群计划代号为 ...

最新文章

  1. python导入类有红线_python踩坑系列之导入包时下划红线及报错“No module named”问题...
  2. java里remark是什么意思_remark的用法和短语例句是什么意思
  3. Arduino超声波测距程序
  4. pku 3087 Shuffle'm Up 说的是bfs,其实就是个模拟
  5. as工程放到源码编译_Android 7.1源码编译导入AS完整教程
  6. NIPS 2018 论文解读集锦(11月28日更新)
  7. 3D Human相关研究总结:人体、姿态估计、人体重建等
  8. java 8 lambda sort_Java8 用Lambda表达式给List集合排序的实现|chu
  9. 阮一峰的JavaScript 的 this 原理
  10. 【引用】成熟人格六要素
  11. CMakeLists编译
  12. c语言实现《学生管理系统》
  13. appfuse mysql_Appfuse 教程
  14. 下厨房怎么显示服务器错误,4s只有一个下厨房app显示网络连接失败
  15. 第1章 Redis查阅官网和基本配置
  16. 软件产品选型测试/POC测试
  17. 微信公众号开发 入手
  18. 华芯微特SWM320TFT屏人机交互方案手册
  19. 路径中 斜杠/和反斜杠\ 的区别
  20. java excel 设置列为日期,POI - 如何将单元格值设置为日期并应用默认Excel日期格式?...

热门文章

  1. jmeter 5.5+influxdb 2.0+grafana v9.3.2 - 压测看板setup
  2. iOS之 2020年最新苹果移动设备屏幕的大小和系统
  3. 网站改版怎么做才能保住排名和权重
  4. Hadoop 安装snappy(编译源码)
  5. 隐含马尔可夫模型——Hidden Markov models (HMM)
  6. 【离散数学】数理逻辑 第一章 命题逻辑(7) 命题逻辑的推理理论
  7. mysql上机实验报告_数据库上机实验7实验报告.doc
  8. 【SDCC讲师专访】房芳:高德地图开放平台,一场本地生活服务市场入口的争夺战
  9. Map之containsKey()
  10. 基础-02-日语中为何会有体言用言?