[Starlink] "Interesting set of developments with Starlink. Musk says they will support "international aid orgs" in Gaza, Israel now says they will use "all available means" to stop SpaceX from doing so.

[Ulrich Speidel]

On 31/10/2023 1:03 am, Alexandre Petrescu via Starlink wrote:
> It is indeed interesting.
>
> Le 30/10/2023 à 06:56, Ulrich Speidel via Starlink a écrit :
> >
> > The main problem as it stands with Gaza would be to get Starlink
> > equipment in for the international organisations to use. Coverage
> > wouldn't be an issue, but power and bandwidth would be.
> >
> I agree with these points.
>
> But it is more difficult than that.
>
> Indeed, if they can get starlink receivers in the place, then there is
> need of power to power it.  Maybe it is not easy to find electricity.
I gather that Gazans are used to unreliable power, so many have solar or 
generators. Of course, generators need fuel, which is in short supply.
>
> The bandwidth problem - I dont know precisely what is it in this
> context.  Maybe it's that there would be too many wifi users on a
> starlink DISHY.

It's that Starlink can only support so many Dishys per area on the 
ground. Handwaving explanation: Think of each satellite as having a 
number of slots on each frequency channel during which it can 
communicate with ONE Dishy on the ground that the satellite can see in 
that particular area. Once a Dishy takes that slot, no other Dishy in 
the area can, because that would cause interference. Now scale that by 
the number of Starlink satellites that can be seen from the area, and 
you have a fairly rough idea of how many slots there are available in 
total for that area. Dishys will on average grab multiple slots, though, 
with each slot worth a few Mb/s only. More Dishys therefore doesn't mean 
more capacity. Now we know that Starlink is running out of capacity as 
is in areas with medium population densities, such as the Ahr valley in 
Germany, which suffered a flash flood a couple of years ago that took 
out all terrestrial comms infrastructure:


If a place like this can overload Starlink with a population in the low 
10,000's, then a densely populated place like Gaza with (like now) 
enhanced needs would be running out of capacity in no time. The entire 
Gaza Strip is only about 3 Starlink cells in size, and has over 2 
million people in it. Most of whom have family outside Gaza that they'd 
like to keep updated on a very regular basis.

>
> There are more problems: I think I heard Israel opposes this idea of
> delivery of starlink in that place.  The question is _how_ they'd like
> to oppose.  Is it verbal opposition, is it opposition of delivery of
> starlink DISHYs to the aream or is it jamming, or is it something else.
> For the latter two, there is legislation in place that would guide the
> way in which they could oppose, but that legislation is fragile. For
> example, is there frequency allocation authority in that area, I'm not 
> sure.

How they would oppose is a good question - I'm sure the Russians would 
like to know, too.

Sure, you can try to keep Dishys out, but given that roaming access has 
been available in the wider region for a while (cue Turkey earthquake), 
I would be surprised if there weren't already numerous Dishys in Gaza. 
Frequency allocation authority ... sounds a bit like Israel having the 
authority to tell Hamas where to park its cars. As Starlink isn't 
officially available in Israel yet and it's a small market, the 
regulatory leverage of the Israeli government against SpaceX is probably 
low.

Jamming isn't really all that easy (again, ask Russia): To jam Starlink 
successfully in an area, you'd have to jam the satellites (probably 
about a dozen most of the time, and changing all the time) from the 
ground in the same area as the Dishys using them.

>
> Another problem is the statement of intention of activating starlink
> over the place.  What does it mean in practice.  I suppose it is not
> that simple as turning a knob on.  Because these numerous sats already
> go above the area, and the area is very small.  The borders cant be
> respected very easily from that high. This kind of statement like
> 'activate starlink' over certain area was already made in the recent
> past.  And it is the same unclarity, because that area is a small area.
> (there are other - more clear - statements like 'turn on iphone sat
> emergency calls' over other areas in Europe.  But these areas are much
> larger (4 large countries in Europe).  And they are accomodated by
> legislation allowing frequency use.  Whereas in the starlink 'activate
> over area x at war' there is no frequency agreements.)
Starlink can in principle now be provisioned anywhere between 53 deg 
north and south, and I guess with a few interruptions in service pretty 
much anywhere else, too. Whether a Starlink satellite will provide 
service to a Dishy at location X below it is a decision made in 
software, probably aboard the satellite itself, and that can be 
controlled at will by SpaceX.
>
> Another problem is that, in case of delivery of starlink DISHYs: _who_
> uses starlink in that area at war.  One might deliver starlink terminals
> in the area at war only to designated persons (e.g. a responsible UN
> person).  But a skilled person might plug that starlink into an existing
> cellular basestation for the benefit of all: all regular smartphones
> might connect to the regular basestation which in turn might reach the
> Internet via starlink.  At that  point, it's not clear how the
> responsible UN person might allow only some legitimate' (humanitarian)
> smartphones to connect to these regular base stations.
Simple. You set a password on the Dishy's WiFi router and give it to 
legit users only.
>
> Alex
>
> > It's a pretty dire situation. Palestinian friends of ours have had
> > extended family killed, the wife's mother is currently visiting here
> > and can't go back obviously - plus her apartment got flattened in her
> > absence early on. Then our friend's teenage kids from his previous
> > marriage got buried under rubble when their mother's place got
> > flattened, and that was just up to last week. I really need to ask him
> > what's happened since. They came here because they were sick of Hamas.
> >
> > On the ham radio side, I helped a bit with band watch for MARS
> > (military affiliated amateur radio system) during the first Gulf War
> > when the local US garrison (Old Ironsides) got sent from Germany to
> > Saudi Arabia. A lot of them found out the hard way that if you have a
> > bank account in Germany and you're on deployment, your significant
> > other doesn't automatically get access to it like apparently they do
> > in the US, and the army didn't exactly think that it was their
> > problem, either. Got to listen to a lot of that. First world problems
> > compared to Gaza, though.
> >
> > On 30/10/2023 5:32 pm, Joe Hamelin via Starlink wrote:
> >> The US did shut down ham radio during WW2.
> >>
> >> On Sun, Oct 29, 2023 at 9:27 AM Dave Taht via Starlink
> >> <starlink at lists.bufferbloat.net> wrote:
> >>
> >> I think that the internet should stay up, connecting people to
> >> people,
> >> through all the conflicts we may ever have. The mails kept running -
> >> although censored - all through world war two - the red cross,
> >> allowed
> >> by all sides, to keep it's relief missions running, the churches
> >> (mostly) doing their job to console the weary...
> >>
> >> Many other orgs, like the ITU, and the IETF, are committed to the
> >> continued free exchange of information, no matter what.
> >>
> >> https://www.itu.int/en/about/Pages/default.aspx 
> <https://www.itu.int/en/about/Pages/default.aspx>
> >>
> >> I am happy to see a worldwide ISP committed to the same principles.
> >>
> >> On Sun, Oct 29, 2023 at 9:07 AM the keyboard of geoff goodfellow via
> >> Starlink <starlink at lists.bufferbloat.net> wrote:
> >> >
> >> > ➔➔https://twitter.com/dburbach/status/1718638348812595660 
> <https://twitter.com/dburbach/status/1718638348812595660>
> >> >
> >> > --
> >> > Geoff.Goodfellow at iconia.com
> >> > living as The Truth is True
> >> >
> >> > _______________________________________________
> >> > Starlink mailing list
> >> > Starlink at lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> >>
> >>
> >>
> >> --
> >> Oct 30:
> >> 
> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html 
> <https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html>
> >> Dave Täht CSO, LibreQos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> >>
> >>
> >>
> >> --
> >> --
> >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
> >>
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> >>
> > --
> > ****************************************************************
> > Dr. Ulrich Speidel
> >
> > School of Computer Science
> >
> > Room 303S.594 (City Campus)
> >
> > The University of Auckland
> > u.speidel at auckland.ac.nz
> > http://www.cs.auckland.ac.nz/~ulrich/ 
> <http://www.cs.auckland.ac.nz/~ulrich>
> > ****************************************************************
> >
> >
> >
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel at auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20231031/ae733ccc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 09HyDBsTTw01CTqD.png
Type: image/png
Size: 176665 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20231031/ae733ccc/attachment-0001.png>