[Starlink] gorgeous work on LEO beam spreading

Wed Aug 31 05:55:55 EDT 2022

The simulation is based on many thoughtful assumptions about the PHY level. For starters, as Nathan mentions, each satellite has 4 ESAs, three for downlink, one for uplink. Each ESA is capable of generating 8 simulatenous spot beams in two polarizations, which gives us 48 downlink beams, and 16 uplink beams. Each beam is independently steerable, with an accuracy of 0.1º. This is known from FCC filings and other public sources of information. The statement that "each satellite has  4 phased array antenna that can each "focus" in one direction” is thus incorrect.

The filings also state that downlink beams use 240 MHz of effective bandwidth from a 250 MHz channel, and 8 channels are available in the 2 GHz of spectrum used for downlink. Thus, my simulation takes those 48 spot beams, assigns one of 8 “colors” to each, representing the corresponding channel.

I took the filed GXT contours for the downlink spot beams, and worked out the eccentricity parameters, which allow me to generate a spot beam’s 3dB footprint at any azimuth and steering angle. This has been validated against the GXT contours, and are quite accurate. I can thus work out how many cells fall inside the FOR (field of regard) of a spot beam, allowing for simulation of beam spread.

My simulation also takes into account the gateway links, only uses satellites that have a gateway link and are in the correct orbital slot, or linked via ISL. Bottom line: is my simulation 100% accurate? Absolutely not. Is it completely inaccurate? Absolutely not either. Without knowing how Starlink assigns resources, and a bit more about the air interface, it’s impossible to accurately simulate the constellation. Can I simulate how much overall capacity could be provided to the US, or a group of cells? Yes, to a high degree of accuracy, based on all the knowledge and work I mention above. What I’d also say is that I’m not marketing for SpaceX or Starlink, thus, I have no vested interest in painting a “rosy” picture of anything - I will simulate as accurately as I can, in some cases, the results will be optimistic and best-case, in others, they will be worst-case too.

I’ll discuss other statements made individually:
> Multiple dishys probably will need to share the capacity of those 4 antennas on the uplink from dishy to satellite. They also share the capacity on the downlink (because the beaming tracks individual dishys.
The first sentence is partly correct, in that the terminals must share the 4 antennas. However, one antenna is for uplink, three for downlink, and work full-duplex. The second sentence is incorrect, the beams do not track individual terminals. At nadir, a spot beam is just larger than a single cell, however, at maximum steering angle, a beam can cover 30+ cells. The beam is serving any terminal inside the FOR, without needing to track it individually.
> How are they "time shared"? Well you have two problems here - one is that you constantly drop dishys and pick up new ones as the satellite moves, so the "time division schedule" of each antenna has to be dynamic, especially as density of active dishys varies (and inactive ones might become active any millisecond or less - new packets being sent).

The constellation doesn’t constantly pick up and drop terminals, the resource allocation per cell lasts for minimum 15 seconds, and sometimes as long as 3 minutes (based on direct observation). This resource could be a dedicated beam, or 50% of a single beam’s time. The satellite knows where the beams need to be pointed, and the terminal knows what satellite it should be tracking, the only disruptions are handovers from satellite to satellite (it’s break-before-make). The density of active terminals can vary, but it’s not such that a cell may have 200 terminals, 80% of which are on and off within miliseconds. People tend to turn on their internet connection and leave it on, only to turn it off if they leave or don’t need it for a long period, if at all. In Kenya, 90% of our customers keep their CPE on 24/7.
> Now it takes at least 4 milliseconds for the a new uplink slot to be acquired. That's the dishy->sat->dishy round trip at the speed of light. Multiple dishys per satellite antenna means that the uplink, and downlink traffic rates depend on how predictable the traffic is.

There is a confusion in terms - once you are tracking a satellite, the satellite will tell the terminal what slots it can use to transmit. I have analyzed the uplink RF, and it’s an OFDM signal, with 128 subcarriers on a 62.5 MHz channel, which is then split in the time domain. The measured uplink duty cycle is 14%, which is exactly what is in the FCC filings. If you assume a 6% time overhead from TDM beam switching on the satellite, you could still have 5 cells per uplink beam, with 20% dwell time per cell. You can then split the subcarriers 128 times in the frequency domain, to cater for multiple uplinks from that cell’s terminals (so going full OFDMA). Handover from satellite to satellite can take longer, as you need to sync clocks, decode reference signal, etc. so it could take 10-15ms.
> Internet traffic (unlike classic voice or video which can be seen as a constant bit rate channel with long silence periods) is bursty at all timescales. It's fractally bursty, as studies have shown. Nothing of this sort is even modeled in this work.

Because it’s not meant to, and not even required for my intent. The simulation will tell you how much “brute” capacity you can expect per cell and country, given a set of configurable parameters. How you manage that capacity is a different issue, and also related to what your users are doing. To simulate the burstiness of traffic in the Starlink case would require analysis of a single satellite with the terminals it is serving, gateway links, and upstream links to the POP. You can then extrapolate those to the entire constellation based on active satellites, served cells, etc.

I’m simulating the broad constellation behavior and dynamics, if you want a per-packet level simulation, feel free to create one - mine is not it, and won’t be :-)
> The big problem in a multiplexed two way system (even at LEO) is that the satellite uplink traffic from one of the many terminals had to share one or a few channels (frequencies) and they can't hear each other. So Internet traffic has to be held until it can get a free time slot, or else the frequencies have to be divided among the terminals dynamically.

This is solved by OFDMA as implemented by Starlink, where all resources are centrally controlled, and there is no random component other than initial registration, in the same way PRACH works in LTE.

I see a lot of “that can’t possibly be true!” from the “traditional” satellite industry, as SpaceX seems to be violating dogmas all the time. In the same way “the industry” thought re-usable first stages would never work, Starlink is facing its moment of disbelief. If we take beamhopping as an example, I’ve heard from experts (not in quotes, actual experts) that claim they cannot be doing it, as it’s extremely hard and would require massive computational power on the satellite. Once you poke that one, it becomes clear the statement is driven from years of DVB-S2x exposure, where the timings are so excruciatingly tight, that it is a big problem. Starlink goes about this by doing the computations on the ground by a central scheduler, and then telling the satellites what to do. Oh, and not using DVB-S2x.
> This is the real issue with Starlink as load increases. And yet most people are pretending this scheduling problem doesn't exist!

There is a capacity problem, as evidenced by customer complaints of slow speeds at times, but that is not related to scheduling. They have, IMHO, the scheduling pretty well resolved. If you can ellaborate on where you think the problem is, it’d be useful.
> But the multiplexing at the packet level given the burstiness of load and the need to stay under 20 msec. packet latency from dishy to anywhere in the continent is a problem. That's gonna destroy all interactive services as load grows. And that on top of bufferbloat (queueing delay under load caused by not dropping packets) that is apparently a problem in the system. and not being addressed.

There are definitely issues to be solved, and promises that were made which can be questioned. Whenever I hear anyone promising latency in a blanket statement, eg “This service will provide 20ms of latency!”, I push back with “To where, exactly?”.

The RDOF proposal itself wasn’t clear on this point, which drove SpaceX and others to question how the conformity parameters shoud be measured. Is latency to the POP useful to a customer? Sure, but what if 90% of the customer’s traffic is to some VPN service in Latvia used for streaming soccer illegally? Does the customer have a right to complain? Is the latency measurement that the ISP is held to account with the POP latency, or the latency to the farthest reaches of the Internet? If you want a bed time read on responses to RDOF comments, head over here: https://docs.fcc.gov/public/attachments/DOC-361785A1.pdf
> My response to these kind of studies is "measure based on reality" before you imagine what a good model is.

Unfortunately, only SpaceX can measure the entire system (and obviously does), us mere mortals have to come up with models and simulations :-)

Best,

Mike
On Aug 31, 2022, 02:43 +0200, Nathan Owens via Starlink <starlink at lists.bufferbloat.net>, wrote:
> Based on the spacing on the sat bus, it’s likely there’s 3x TX antennas and 1x RX on the satellite.
>
> > On Tue, Aug 30, 2022 at 5:30 PM David P. Reed via Starlink <starlink at lists.bufferbloat.net> wrote:
> > > Hi Sascha -
> > > On Tuesday, August 30, 2022 6:39pm, starlink-request at lists.bufferbloat.net said:
> > > > Date: Tue, 30 Aug 2022 08:37:24 -0400
> > > > From: Sascha Meinrath <sascha at thexlab.org>
> > > > To: Dave Taht <dave.taht at gmail.com>, Dave Taht via Starlink
> > > > <starlink at lists.bufferbloat.net>
> > > > Subject:
> > > >
> > > > I'd be curious how accurate these simulations are -- even within something as
> > > > simple as LAN Wi-Fi, the "simulations" often are wildly/hyperbolically
> > > > over-stated. I could imagine that even a few over-rosy assumptions would
> > > > exponentially metastasize optimism within the satellite context.
> > >
> > > Very good point. They don't seem to be based on very thoughtful assumptions about the PHY level.
> > > Remember, each satellite has  4 phased array antenna that can each "focus" in one direction. That's a pretty severe limit. Those antennas can either transmit or receive. They can't do both at the same time. Multiple dishys probably will need to share the capacity of those 4 antennas on the uplink from dishy to satellite. They also share the capacity on the downlink (because the beaming tracks individual dishys.
> > >
> > > How are they "time shared"? Well you have two problems here - one is that you constantly drop dishys and pick up new ones as the satellite moves, so the "time division schedule" of each antenna has to be dynamic, especially as density of active dishys varies (and inactive ones might become active any millisecond or less - new packets being sent).
> > > Now it takes at least 4 milliseconds for the a new uplink slot to be acquired. That's the dishy->sat->dishy round trip at the speed of light. Multiple dishys per satellite antenna means that the uplink, and downlink traffic rates depend on how predictable the traffic is.
> > >
> > > Internet traffic (unlike classic voice or video which can be seen as a constant bit rate channel with long silence periods) is bursty at all timescales. It's fractally bursty, as studies have shown.
> > >
> > > Nothing of this sort is even modeled in this work.
> > >
> > > Now I first started working with 2 way satellite technology back in the Iridium days, and also with 2-way geosynchronous satellites that used RF transponders that just translated the frequency of the uplink to the downlink frequency and vice versa. (Tachyon was the company, I was working on some technology for Nicholas Negroponte's 2B1 project that decided on Tachyon and not Iridium for all kinds of reasons).
> > >
> > > The big problem in a multiplexed two way system (even at LEO) is that the satellite uplink traffic from one of the many terminals had to share one or a few channels (frequencies) and they can't hear each other. So Internet traffic has to be held until it can get a free time slot, or else the frequencies have to be divided among the terminals dynamically.
> > >
> > > This is the real issue with Starlink as load increases. And yet most people are pretending this scheduling problem doesn't exist!
> > >
> > > Even Dave Taht and his buddies who have worked on trying to solve the problem of sharing with 802.11 haven't made much progress in dealing with bursty traffic sharing with heavy load.
> > >
> > > And yet people are modeling as if this didn't even matter!  (well, it's not something that has arisen much in the classic one-way or non-multiplexed satellite systems. I don't think even commercial airline satellite systems try to share capacity among multiple planes dynamically.)
> > >
> > > The phased array tracking of satellites is indeed magical, and the ability to (in principle) switch directions between every 6 bit symbol time is very nice for the downlink from the satellite to multiple dishys.
> > > Great technology.
> > >
> > > But the multiplexing at the packet level given the burstiness of load and the need to stay under 20 msec. packet latency from dishy to anywhere in the continent is a problem. That's gonna destroy all interactive services as load grows. And that on top of bufferbloat (queueing delay under load caused by not dropping packets) that is apparently a problem in the system. and not being addressed.
> > >
> > > My response to these kind of studies is "measure based on reality" before you imagine what a good model is.
> > >
> > > >
> > > > --Sascha
> > > >
> > > > On 8/30/22 07:52, Dave Taht via Starlink wrote:
> > > > > mike is doing some great visualizations here:
> > > > >
> > > > > https://twitter.com/mikepuchol/status/1564544963857326081
> > > >
> > >
> > > _______________________________________________
> > > Starlink mailing list
> > > Starlink at lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220831/a988c525/attachment-0001.html>