Given that I may have triggered this, and with my limited understanding of how Starlink is put together from a resource allocation standpoint, first, some caveats:
• A simulation without inside knowledge is always going to be an approximation. In my case, it’s usually the best-case scenario. • The simulation of a country should not be done in isolation to increase realism. Many of the satellites over the northern US are also serving Canada, which means there are less resources available to US cells than the simulation portrays. • The real constellation would allocate resources based on demand, primarily, and Starlink knows said demand quite accurately (once ESIMs are in place, this will change!). Thus, cells which are in very densely populated areas, which I include, would likely receive very few resources, if any. Many empty cells or those with no customers won’t receive resources either. Starlink has essentially these mechanisms to increase the number of cells covered by the constellation at any given time (others like number of beams are fixed in hardware): • TDM aka beamhopping: split 100% of “airtime” into frames, and allocate certain number of frames to more than one cell. Can provide asymmetric capacity based on demand per cell. The switching time from cell to cell is the driver for how far you can split the beam in the time domain, before the switching overhead starts killing performance. • Beam spread: as the beam is steered away from nadir, it becomes larger and elliptical, thus covering more than one cell (apart from the target cell). Allows to split the beam resources allocated to the center cell amongst all other cells in the FOR (field of regard). Cannot be asymmetric without enforcing terminal discipline, where each terminal is receiving 100% of the downlink (which could be 10% of the full beam if TDM splits into 10 cells), but is only grabbing what is addressed to it specifically (akin to an LTE network). • Multiple beams over a single cell: up to eight spot beams can be projected onto a single cell without running into EPFD limits, as long as each one uses one of the eight frequencies available. These simultaneous beams could come from one or more satellites. This is how you can get additional capacity to a cell, for example, to compensate for reduction by TDM. Two beams at 50% duty cycle make up for one full beam. The advantage is spatial diversity, where a terminal that has one satellite obstructed could opt from a beam from a different, non-obstructed satellite. We must also understand provisioned vs. advertised capacity. In Kenya, we provision 1.5 Mbps per customer, but advertise and sell a 5 Mbps service. Actual average per customer is 1.2 Mbps. If we took a single beam capable of 700 Mbps (many observations and circumstantial evidence support this figure), at 1.5 Mbps provisioned it would serve ~466 customers. Once you start applying TDM, beam spread, etc. the number reduces, and can only be compensated by adding additional beams. It’d be interesting to hear what ISPs in the US provision their customers with. Of course fiber is the top option if you can get it economically, but if there are vast regions of the US (not considered a developing country) still not serviced by it, or even by fast WISPs, then there are reasons to look for alternatives - I’m willing to bet a financial analysis doesn’t warrant laying thousands of kilometers of fiber to serve relatively few customers. Starlink is providing significant service levels to people who could only dream, with all its growing pains and inefficiencies. If you start talking about “connecting the unconnected” (a kitten dies every time that one is said), then fiber is one option, but it becomes more relevant for major backhaul, not even middle or last mile. People who have a disposable income of $1 to $5 per month just cannot be serviced by a financially viable service that relies on fiber. Here, you need to start getting creative. Best, Mike On Aug 30, 2022, 19:32 +0200, Doc Searls via Starlink <[email protected]>, wrote: > All good points. > > I'm also wondering if (and how) Starlink is improving any satellite gear in > successive launches. And, if that's the case, what would be the upper limit > to what's possible with the system? > > I ask the first question because Starlink has been deorbiting quite a few > satellites... > > https://spacenews.com/spacex-launches-starlink-satellites-as-it-deorbits-original-ones/ > > https://www.space.com/spacex-starlink-satellite-deorbit-video > > ... while launching many new ones. > > For example, there will be a Falcon launch from Vandenberg, of several dozen > satellites, at 10:30 (or :40) PM Pacific time on Wednesday night (though > there are conflicting reports, and launches often get canceled): > > https://www.edhat.com/news/spacex-starlink-launch-rescheduled-for-tuesday > > https://www.spacelaunchschedule.com/category/vandenberg-sfb/ > > https://www.space.com/spacex-starlink-group-3-4-launch-rocket-landing > > https://www.ksby.com/news/local-news/spacex-targets-tuesday-night-for-falcon-9-launch-of-starlink-satellites > > A late evening launch time makes for good viewing because it's dark enough to > see the launch from a distance, and the rocket hits sunlight at the edge of > space, where exhaust moves outward in all directions uncontained by > atmosphere, leaving a tubular trail in the sky. > > Here is a collection of screen grabs from a camcorder recording of a launch > in 2005: https://www.flickr.com/photos/docsearls/albums/999576 This launch > will be later in the evening, but still quite visible. One big difference > will be the return trip of the first stage to a platform out in the ocean. I > caught one of those in this series of shots here: > https://www.flickr.com/photos/docsearls/albums/72157701027229232 > > (Forgive my indulgence in space-freakery. I do enjoy this stuff, and I'm not > here in Santa Barbara often enough. But I am here now, so I'll be shooting it > again, this time with a new camera and a longer lens.) > > Doc > > > On Aug 30, 2022, at 9:53 AM, David P. Reed via Starlink > > <[email protected]> wrote: > > > > I have no clue why this matters (other than this is in color). > > > > The phased array antennas used by Starlink are quite limited - in > > particular, there are 4 on each satellite and each earth-ground path is > > half-duplex, TDM, essentially. Limited by hardware. The problem of signal > > equalization and quantization limits prevent "space division multiplexing" > > and "frequency division multiplexing" in practice. > > > > The 4 msec "turnaround time" at the physical level (satellite) means that > > time from a packet arriving at one end to be sent to the other end of the > > sat-dishy links gets worse the more dishys are served by one of the 4 > > antennas on the satellite. > > > > trying to increase the coverage of an individual satellite basically means > > serving more dishys per satellite, with less total bit rate, and much > > longer latency due to the half duplexness. > > > > Now if the total bit rate of a sat-to-dishy link were, say, 1 Gigabit, like > > an 802.11ac AP gives you, and the turnaround time were under 1 microsecond > > rather than 4 msec. maybe then you could get reasonable Internet service to > > dishys. > > > > But 240 Mb/s or 172 Mb/s as proposed for getting a bit more coverage per > > satellite? This is nowhere near competitive with what we expect in the US. > > > > Sorry to rain on all the techy dreaming. > > > > First, it's worth looking at all the problems currently in WiFi performance > > when you share an AP with multiple active stations using 100's of Gb/s on > > the average (not just occasionally). > > > > Dave - you tried in "make-wifi-fast", and the architecture gets in the way > > there. (yeah you can get point to point gigabit/sec single file transfers, > > but to do that you invoke features that destroy latency and introduce huge > > variability if you share the AP at all, for these reasons). > > > > Starlink is a good "last resort" service as constituted. But fiber and last > > few-hundred meters wireless is SO much better able to deliver good Internet > > service scalably. > > Even that assumes fixing the bufferbloat that the Starlink folks don't seem > > to be able to address... > > _______________________________________________ > > Starlink mailing list > > [email protected] > > https://lists.bufferbloat.net/listinfo/starlink > > _______________________________________________ > Starlink mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
