From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.21.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 986EB3B29D for ; Sat, 11 Nov 2023 18:47:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1699746427; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8v7wWnJcKe/3N+0Lnvf9YnSxnaMraycxlgMH9V55Now=; b=Y2IIi0UgJotAvbGiRpk19//PpgGYfWVPOAKqhhTFsy4N6ax6BqVedcJRhOOov4e/i2tdE3 Bl3IFFu6uSPwwHnZcNW2r6Ja9SAa3dN1sSrdjKPfvDCa63gjijgEF/fh/iaTBC2gPe3R9g tsRat8F8SGgwkPMUMXbOMg+DxdHYyN4= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2232.outbound.protection.outlook.com [104.47.71.232]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-51-Z30A4HhyP5Sebjm0NBmxIA-1; Sun, 12 Nov 2023 10:47:05 +1100 X-MC-Unique: Z30A4HhyP5Sebjm0NBmxIA-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by MEYPR01MB6566.ausprd01.prod.outlook.com (2603:10c6:220:113::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.28; Sat, 11 Nov 2023 23:47:03 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::ce:ae5e:ef6b:2f11]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::ce:ae5e:ef6b:2f11%3]) with mapi id 15.20.6977.028; Sat, 11 Nov 2023 23:47:03 +0000 Message-ID: Date: Sun, 12 Nov 2023 12:47:00 +1300 User-Agent: Mozilla Thunderbird To: starlink@lists.bufferbloat.net References: <07fac4e4-809a-43ba-b46c-e0f468343e30@auckland.ac.nz> <623cfce5-06cb-4ba2-98d0-808157437ba8@gmail.com> <1956e783-3795-4409-8e97-7b836994e911@auckland.ac.nz> <032a9c2d-c5fc-4b5f-9579-c22b791e29f2@gmail.com> From: Ulrich Speidel In-Reply-To: <032a9c2d-c5fc-4b5f-9579-c22b791e29f2@gmail.com> X-ClientProxiedBy: SY4P282CA0011.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:a0::21) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|MEYPR01MB6566:EE_ X-MS-Office365-Filtering-Correlation-Id: 23db9e08-81fe-4409-c89b-08dbe3108114 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: HPWeVLootKQaqnvyTcl5QCBG1LlkVl4r+quavdZIQ4l05oEYjn6Y9zzWQPrhDj16HoX7i24O6D2PWj649KiZFolrJGfOqSRap3DctCqDjNv70mclM4/nEyozJ5HSZ2qCMnYVd+3wTt6sYhTh+06HpELDOsBe4xe2xdHD1S26hq00ShIGqQAmplG3nWphXL4zyu6/CW/4LW8JFVdtC5W5toZgPcZMgOK2Icg/9CGjzRf/urlygtu8Yvph+9x2R+C1JQZKeT1ZYZSvhdNOoP3C40TuAP5081VQVcslPNBsn2nxm5K3s3s2/iAgD/rOa7EoQ6S1jyb9ntAy61WlQ1o12sIDX4cjjjXylXG29wxSt8iPM21cIzWf45IN+Vzp+vOrN/oTpYZG4Pm/IZUh4DajQMBbBtCWAWT0+QT1qr+o1YKPn3MRSy2iacJW7pQ20ddT0Z0SnRQrPYPK7Gl9cqkPDKKRoD8s8+BAyGFgdyU6cJSWqVO/1nWIX1shsirDcWfkKL4/8lzX8aLBPqjNWgpcYBUMmSedG4ER7qE8wnHM3z/QTP/kAYwUzvkEFI11tDrPbmwAhReAMD0yQRXJitlIX5by+tk3iuWwkRZfmol2gSaMLPqY+WqQtG1rg4GjEIJ5xQX95GVQYv5x4VQm1HnCig== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(39860400002)(136003)(346002)(376002)(366004)(230922051799003)(64100799003)(186009)(1800799009)(451199024)(2906002)(6506007)(53546011)(478600001)(31696002)(86362001)(2616005)(6512007)(6916009)(786003)(316002)(66476007)(66556008)(66946007)(16799955002)(6486002)(966005)(38100700002)(83380400001)(5660300002)(8936002)(36756003)(8676002)(41300700001)(31686004)(66899024)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tjjffJJ6RO5QOWzHZ5gmeHTB2yo6YgT7YUtnpqNSM/ADxtecyVAoBBVlFHaa?= =?us-ascii?Q?Dnyl2bGPv6eXqwr4BR4C1huhd30SWilC0VbrwYVmWVwaH7Merl/lP/h6Ex8Y?= =?us-ascii?Q?LgVqj8X74SSvFIVGAf96qJadSN/h/xLo2F6qfbWxOsktJPFdhdBqerFw9rrv?= =?us-ascii?Q?6NHeUrtiX1AzUJ3qAqlgyAoczCqfiFYuMvZ1shc4apIeHtlZYEmMumG8Vzpx?= =?us-ascii?Q?ukGuWbMmlEuD4tTTYOhWqmROHUnoR/EPat4EQ5LTXGcX57+cGigZUnIfcK+C?= =?us-ascii?Q?GXqwaNUakZ3YnKTCmmbvGfV40XrBpz1vhUqY1kidGqHrbJ1PwFwy1qkpAozW?= =?us-ascii?Q?9P64GvE8igMSP35tA4lvrOXepDXYRv5zLAYlNRkJ4Da2rz82tZpM/fqsCSOs?= =?us-ascii?Q?CVhb+kmpRyQHwhpOSShPhCRrgtfaj9uMB2jgFxEitH+p6Qs9Avcy2Y0xo8pq?= =?us-ascii?Q?BAIG8u6/vty+3ymEphl9t6Ebw01LTBmAZcn402s1y6pDHLDih49Rp3LHc9fh?= =?us-ascii?Q?KHGWOxOGi6n/+xHLopbL7cKoFs1xPczH5Jb8UNvOf3BQeTsDwdnCgWAm1bZf?= =?us-ascii?Q?ppMYmNY5PU3rhtBaF+Lec0FIm2B51BLLRavcjI69loJuM6ZIgHYIF/YVqXpJ?= =?us-ascii?Q?kEjyMiZVbW1UsjmVKe9/1oSuvaHxTpB3SsNV6oKhjlyuENiaBn6bvhB1jYUD?= =?us-ascii?Q?24MEoVzDTBUA6I5IDWHuDoKwjUBIllrdxmHvINmYRRT4E+nLnHVkKAc4jNUK?= =?us-ascii?Q?yIq9Stwq0nTmLqOGj/6g00FccA3eXfhv4ufh44A7zkw+dF7Pk2IRc5jxWvXC?= =?us-ascii?Q?UOVRX1l3Q7FKx7PUYiJailNJuIAyCO9WJPsXn4csMCV69Gpp0r/QvtYo2vaO?= =?us-ascii?Q?AIRNyAx8zkKd9MdGhtM8XV87l+79HRXMsYpmBrgp6G0+82oZZB2t4er6is5w?= =?us-ascii?Q?rbp2fOfVbOhSSrI+lZ3BnnbH+vAteLknEMhNEs8zPQ+IB5jT8sTBdrXekM8Y?= =?us-ascii?Q?7Lk+mzjiWJJIXM8TpJgQXJoSrNlfZdFyyEK9JUnVPvryckDSbbMw5iL/1/gH?= =?us-ascii?Q?6x2uGCvHxokKhufYT93ve++85Nef9sh9mWLmbq3th+rJbRwF+BlgrEFNG6PE?= =?us-ascii?Q?Lgi7DmEI+MTTIaqQKaXu161fvZ2mj6rrY01LFB9obvt9rYr+9XkgvEi1GZjI?= =?us-ascii?Q?md0qSRK8m52kwI3LyefZ1panqd5ig8tJ38IOyOrh7xOTM/7LbwoKqr/9HJ1z?= =?us-ascii?Q?QgoNbnK92qxmQ1XvI4qFIrOaPL2F5SiBvJQCBoDpOAhDqETc4ocLWQc7GeWB?= =?us-ascii?Q?xFETn5tbNYx2AVDjsR9mKseKAcQmGyzPAgK8HFUSuN9HNOFKuXMKN4MpM0Ia?= =?us-ascii?Q?SQZ65ZW3YZhnBN1anbLjj1rCCXzFdI5Xc/mk+0+WKlbMxp+Htg8ZT+uNjelO?= =?us-ascii?Q?SiUmKxzrYtynYKGPw0q/7cKHt5enc8fJFuAizQqbHm3a8xUlaztuJbYkDs0A?= =?us-ascii?Q?4rzKHKj3A8gnms5ejSJhggZqAxYba0vG1cAsDThDThg2ST89H8YcVxFa9xoX?= =?us-ascii?Q?vVjc35eQc4dXOLfODAqHl6jioijHTzA2Ov1b0QUyTXR2fTWW/QZotcnqZCYu?= =?us-ascii?Q?FtLQUf9aAG0ikm4/I4A1KDH9pBcTywDuJSgsDFoIfb3GMmfbEd+aDLd9Fx8X?= =?us-ascii?Q?1qGU0w=3D=3D?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 23db9e08-81fe-4409-c89b-08dbe3108114 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2023 23:47:02.9817 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vmylesoTPZeMudPZElUCWDcPN7ffbojb2In9vp1ZH5MoRWSdSnwuGyJ4AZhjTMmLUshFRLjy+oiN4tlRcDFChLj4s6AQM4zFiF1vL7lLQuY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYPR01MB6566 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [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. X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2023 23:47:10 -0000 On 11/11/2023 6:09 pm, Alexandre Petrescu via Starlink wrote: > > I want to say that I think this hexagon is an imaginative idea of the > GUI designer.=C2=A0 I think it does not correspond to reality.=C2=A0 I am= not sure > about even the most basic fact such as the dimension of the hexagon, or > of a more circular 'spot' radius. Well it's the basis on which SpaceX will sell you a fixed subscription=20 or not, so it's a bit more than just a GUI designer's fancy. > > It was the case like that with earlier maps of cellular network > deployments.=C2=A0 The name 'cell' itself that comes from it - it's a > hexagon, like in a honey pot.=C2=A0 In practice, no cellular network > deployment I am aware of has cells of that kind of precise shape. The > base stations themselves are not following such precise patterns. =C2=A0 = The > precise forms of coverage shapes can not be given by operators because > it is unique, difficult to calculate, and depends on many landscape > factors and other propagation conditions.=C2=A0 What can be given is the = type > of antennas, their precise placement and orientation.=C2=A0 That is publi= c > info of cellular systems in some countries. Yes, but I wouldn't think of the Starlink hexagons as "cells" in the=20 cellphone sense. In the cellphone sense, you'd have a base station per=20 cell - and some seem to think that Starlink has something like a "spot=20 beam per cell". But that's clearly not what it is. Starlink cells are quite obviously predominantly a tool to control user=20 density on the ground. We know well that Dishy orients itself to the=20 area of the sky where it can expect to see the largest number of=20 satellites without falling foul of GSO protection rules where=20 applicable. Dishy then associates with one of them at a time for period=20 that are multiples of 15 second intervals (we know that from the=20 obstruction maps available from Dishy via grpc). We also know that the=20 capacity we get via these associations fluctuates along with the 15=20 second intervals. These are all hallmarks of a burst slot based system where each=20 satellite handles a set of time and frequency slots (TDM+FDM), such that=20 a combination of a periodic time slot, a frequency channel and perhaps a=20 number of other parameters (spreading code, polarisation, spatial=20 multiplexing through beamforming at the satellite) defines a channel=20 through which Dishy talks to the satellite or receives from the=20 satellite. This sort of technology has been around for decades (see GSM=20 mobile comms). During your slots, the satellite your Dishy is associated=20 with will project a beam towards you. Fluctuations in the capacity are a result of a Dishy having more or=20 fewer of these slots assigned during subsequent 15 second intervals. If=20 a satellite picks up more users for the next interval, the number of=20 slots it can make available to your Dishy goes down. If it sheds users=20 as it moves along but you hang on, then you get a few more slots, until=20 either the satellite picks up more user or you change satellite. For a scheme like this to work, you need to ensure that the number of=20 slots that the visible satellites can offer to their users on the ground=20 works out to an acceptable average minimum number of slots per user at=20 all times. As the number of slots per satellite is likely fixed (at=20 least for the same generation satellite), that puts a limit on the=20 number of users within view on the ground. This is where the hexagons=20 come in - they help ensure that the user density doesn't grow to a level=20 anywhere where a Dishy would struggle to get enough slots. I'd presume that the size of the hexagons was chosen to reflect the=20 ability of the beamformers on the satellites to resolve a locality on=20 the ground (no need to go for higher resolution then). I'd also presume=20 that the number of fixed users allowed per hexagon would depend a bit on=20 geographical latitude, visible satellite density and load contributions=20 from a location's surroundings (Colorado farmers would likely see more=20 of those from their neighbours down the road than folks on Rapa Nui).=20 Roaming subscribers aren't guaranteed the same service levels (read:=20 their number of slots is allowed to dip further than those of fixed=20 subscribers), but as they can't be told where to be, SpaceX uses pricing=20 to control user density indirectly. > > With starlink antennas there is no authoritative public info (from > starlink) about the precise orientation and types of antennas of the > sats.=C2=A0 The reported positions of sats are rather irregular - much mo= re > irregular than that precise shape of hexagons shown in the photo. Yes - see above. > > The placement of teleports is also unknown, but speculated by end users. In some cases, their locations are precisely known from their spectrum=20 licenses. > > The info about satellite tracking, their precise situation: I still need > to find out where that info comes from more precisely and how is it > obtain (is it reported by sats or is it=C2=A0 other cameras/radars that > 'range' each one of them, or is it simply speculated from an initial > plan of trajectory; and what is the delay between the actual fact and > what is seen on GUI: seconds, minutes or hours delays). https://celestrak.org/NORAD/elements/index.php --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz http://www.cs.auckland.ac.nz/~ulrich/ ****************************************************************