From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2096.outbound.protection.outlook.com [40.107.102.96]) (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 46EC73B2A4 for ; Wed, 31 Aug 2022 19:44:39 -0400 (EDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SFOhPCZlLCDspQF+l7HWzLxlE4mpVMVHrA12lOEbGisAqcOlyGv8wk+1LNf5sUmXhd2VftpoEZDW35kwQ4FN2f+wS3PrKp+l7f8b2AgPL0aeQ70MckEwtWwcRIiHon1T6UGZHvpuo7RSRFic7ITN7XcHdDhRK6y0huWbEGSVSLSIiR80jEq+Ou+C8oT/F/4Ky3711EO9B5NxlfjldIv2n0Yxpnz5w2EfOnzQ9T3Kz/mlMxRqIsBizP5szKvyYdMgAiBujFK3WRFszsF9ffasbwc10NzUbw8ULnOvMStww2JAsE731tp7+NDNABPJszr55XtA/J9PpxPG7B06WUa2lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7ShaXeA72QK++tk7M2uploZ/fEK8UnIWYCNtZoBZbyg=; b=Dwnhz8lh+pBB7vyMAvDtfis/08jU5YiR0l2dGBtN9MsGMXGBhlyKP4+DG0bC/CvSpknDimKm1lEW08FY9/s+6msRBfBx2ivpc+JU7ohQSzXZvm/NMznIIi9vd3CT401XCAAS9rFbvtQP3Q96Eyz4Dibi7HWh96TcHVWLwE14+XTgk2KqndTqiQMGiRt+0jW5Ik/jsQy+/Eh0In+2lc6V2CjmxpyNToO5AucQrAsMTX1pESN4zUJutuDwWqVb13+OMnp0wikzOLAbq26zlBh2hReaGqbNNYNTKGpwY6JdEue6gptmfj4AYCZAjl/Zpc0wZIyIGi0SrhM98eUsY/qsHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7ShaXeA72QK++tk7M2uploZ/fEK8UnIWYCNtZoBZbyg=; b=GeWwQNdjsyuGq2+KWeHhWRXHq8Tl5iV0KKe3urkpXzJJ976ak4vZ7qTR/b9wPRTM5Al9bQPLMJe9yfWQe87o3tyc8/QAkWOg6C50EHmrz5j2+Vmb0A2xAf7cfD9t8IYxvOOu69o9hadcbbu08Q34LhDfOIkEY8sG4CcdTiBTNhc= Received: from BY5PR13MB3144.namprd13.prod.outlook.com (2603:10b6:a03:18c::27) by DM6PR13MB3820.namprd13.prod.outlook.com (2603:10b6:5:245::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.5; Wed, 31 Aug 2022 23:44:37 +0000 Received: from BY5PR13MB3144.namprd13.prod.outlook.com ([fe80::543:3d02:acf:ac03]) by BY5PR13MB3144.namprd13.prod.outlook.com ([fe80::543:3d02:acf:ac03%7]) with mapi id 15.20.5588.010; Wed, 31 Aug 2022 23:44:37 +0000 From: Lin Han To: Ulrich Speidel , "starlink@lists.bufferbloat.net" Thread-Topic: [Starlink] Starlink "beam spread" Thread-Index: AQHYvUkfyuC9ZflANE+AWe2GABhYRK3Ji6MAgAAeE8A= Date: Wed, 31 Aug 2022 23:44:37 +0000 Message-ID: References: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz> In-Reply-To: <7a357510-2d61-dd4a-a59f-3d7d4bd3727c@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33fcabda-e456-4553-7aba-08da8baac3c3 x-ms-traffictypediagnostic: DM6PR13MB3820:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U3XigLjIxLEul6SCDbchDhFAGt23vu22Om5nVk6eZ19CLjHnnezN5e1CXifgnOmDDJfIaTFjhZ48jkcuKt1F+a0vCqKGFev5j2BGyoI6RaTacFTgYNxHVCqACi4jz2IS16JBtYHLohiwuYoZNNMFGx7WXGYzDtezbwCd7gLRz9488YVhU6Nz/1GOa0OCkx42bBIpHTcXxi2yCk8ZsmTCyR98RsM7tRJfSmGusDf/5slZJUwTWPNZGhJiIoS0MhUtzQlEgymsZKRlzWbJBK+8+TcROriKuCchTryulwT1JtO62Ld+seRO+tHZSj1lmaX3tOubTPe1d15/kWbPaAgfMZj5BaNrPRH65lxHmBaY0zjqLeS2RNt77zr5ZCh9iq2YH3OV0PP9Ql+ChcMWnOzxjPkODp5jwHuce8ox6+NBQSMlJvmOl1p9YQ3yZB3+TN1mKLgqhTniYiq2OmPYOpgB02zcYIjPODR7f1Bd18xqBYFlyh26q/x01Hkm20hMbicQXnAVOrcGY2te+YWKuxBb6ujraeaqsSsu00xYkWqJsldnQBoEzlsg0laXxAcL0aDi70GTD18QAIwnogWS9+E6btDSNZrldChZLHobppOYSBjGzKKErRIpnC91a+EK8NEJLuZtHiQAn59CAZFxRNJu+48sjFdx/QeOcE1ZI4FyDgQBHWD61jPwcmU7s5Psf7GSH14lFyWEK1NtkqHmcdnYAajz2dB+eybazkdeK6F3bx2HfLP1BOgI4QbB7+/7QOZO6x9kG9y+P5p8i3zNQRrZHAWmdfdo6xYY39M+fzaMadHsIY56payo3UFjJNu1IcmO x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3144.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(39840400004)(396003)(346002)(376002)(366004)(136003)(45080400002)(110136005)(316002)(71200400001)(966005)(478600001)(38070700005)(38100700002)(166002)(86362001)(41300700001)(52536014)(8936002)(5660300002)(44832011)(6506007)(7696005)(2906002)(53546011)(26005)(83380400001)(9686003)(122000001)(66574015)(55016003)(66476007)(8676002)(64756008)(66946007)(66556008)(76116006)(66446008)(33656002)(186003)(513134003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?xwLzxep6fbQ9KTo6GnFIII0/vEGteoJ0jqILPBHZCnezQyk015fv/godwK?= =?iso-8859-1?Q?XJ7P3pJkEE3TXg5+V5tsO5p/otfISvFwZfB/zM2m4VHFrHMVhy0SVsI3aQ?= =?iso-8859-1?Q?OHITDT/ysppe/26s409mXJeBUzqtarMwsmGCN7YUnlNj6rGCYntBIoSM9p?= =?iso-8859-1?Q?7Yk2BnoT6wht5b0JRJj+3WqljdiTSLZ5BPOyl6nDZV2o88hmLdRvZUrAuD?= =?iso-8859-1?Q?dLARO9dyn1dkjvodgLkCMprb+1Er4HnZV9msx8eBeX83CFG9o6d7RYoAPy?= =?iso-8859-1?Q?cn7N4TK7hDqYd98bEHIqoOYGr3s671mxH7xJs5bvxvNUlIRdrlxWlItYJw?= =?iso-8859-1?Q?d/n8dmBBf8L416aNn9FFYBs9asiGn9eTjoyaNfGdhnRKz603P7Ai+aDrEC?= =?iso-8859-1?Q?T9APfKDdxgY1EEOaDQF26AT5nWYmhTCKaHDs1WKUxxWIweUB8U3e5/ZCN3?= =?iso-8859-1?Q?iec9a3n5S86y+lA8TMrVGsq8ExZ0rs77GXcUC8JUH1NTL5TtblWgqeAVMx?= =?iso-8859-1?Q?eGxMjrWPTnxRKmS9LK37Q5P41iaD6BN1Z5tEtztAqPP58lOCHCTOJD6NhD?= =?iso-8859-1?Q?G+p0C6ANhjSoKCiULcjWi16y///cyyvW+exMXGvcP14vyCVdp3XW/HLX7k?= =?iso-8859-1?Q?/2XdIxQ2H3Z8CA+24TGX462yjLBKDGHZZsHe98/8pmTabm7SLFhE9Bxl48?= =?iso-8859-1?Q?/5kiF6irx1/D+N76iVe7Q/UEOAV/EUUK9kIifQZuJXXpGXZeVDDMlQp7rO?= =?iso-8859-1?Q?nxzN+UVINi6cFccEHRExRa5MLDMVsMSJ5l+Whb2QBiXJe1016YnXjU+k3E?= =?iso-8859-1?Q?weN3GfOYPzzvzqmqfb0zYPtxdn7ZrsLROSDjV1sG4cLVOsgpuEGnhb4VOV?= =?iso-8859-1?Q?AbAmPx/JZYt8KR8OS1ImG8WsKpNpSlPndGA1hWHH7+y36SVqh0eMmooKG/?= =?iso-8859-1?Q?cZ4msc1yn68EAQd4BYJrKNqo+tcdN+/yrs6VG0AFHFLDU03L7o1Z3eQ851?= =?iso-8859-1?Q?B0gaTZBWUytK393W2/w1HRwlJWbc/3JxjP4PQdgamDedyhroNhoHdvKaiL?= =?iso-8859-1?Q?P8pOkOGfrVbI/A8++wHf/vzHEsSVuyFlw+odY9bN8qfa+wKdq+yLf0GmvF?= =?iso-8859-1?Q?eRhANsoAdbRVFe5fxykyF7ahSTI2JNQpJqvyFuuvy/jrf9wRpZY7P9vSt9?= =?iso-8859-1?Q?RD5rcWi4/xn42Aq22jBDtLfV+qsvJDmL9w1WFEoblcq/AL2K0brFPvnV2e?= =?iso-8859-1?Q?DXkipzk4zUuW/JJuDqg5JxQa7IlSuhH7P3v1RjndN3emPZAN36MmkTOyAZ?= =?iso-8859-1?Q?KCuEywsax/y0GLm8HYs5vWDHv3i/ISB9MGGJhnPg9nj0lUdP93U73omMiZ?= =?iso-8859-1?Q?XEglfGkqx42sK9d0Kzlgg0uPCLOeAY/PTFKJabdk7o+suz5ugnkkks0y9I?= =?iso-8859-1?Q?h7tFSKhhbIBNidkMSGA8SAgCrNJXsw/ZGbL8F5qrjnmwrf6vrEGQmiYxUw?= =?iso-8859-1?Q?GXdPTaiLlLOJbLf1Bi4cqqHNYOq6qaylmsOZJKHnyGoim/u7dQj4TvE+bB?= =?iso-8859-1?Q?XJt84KF2G5PROdmKnt7zY1LAMumm5qVnAg2YI/qCSVRGLXCV7/MaBC/E4c?= =?iso-8859-1?Q?PC22Mx01d7XgM=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3144A6C8C1A08B85C38AEF09E9789BY5PR13MB3144namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3820 X-Mailman-Approved-At: Thu, 01 Sep 2022 15:19:45 -0400 Subject: Re: [Starlink] Starlink "beam spread" 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: Wed, 31 Aug 2022 23:44:39 -0000 --_000_BY5PR13MB3144A6C8C1A08B85C38AEF09E9789BY5PR13MB3144namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Ulrich, I agree with you even I don't know if StarLink satellite will process IP pa= cket. IETF may work on this area soon. IP is the mandatory if some IP based= features are moved to satellite, such as DNS, CDN, etc. Also, from 3GPP pe= rspective, future LEO satellite network should be IP based. Then, the NTN i= ntegration with 5G and Internet can be done. check out my slide: https://datatracker.ietf.org/doc/slides-114-hotrfc-sess= a-the-leo-satellite-networking-lin-han/. We will have side meeting to discu= ss this in the next IETF 115 (London). BRs. Lin From: Starlink On Behalf Of Ulrich= Speidel via Starlink Sent: Wednesday, August 31, 2022 2:46 PM To: starlink@lists.bufferbloat.net Subject: Re: [Starlink] Starlink "beam spread" I work on the assumption that Starlink satellites are, or at least will eve= ntually be, processing IP packets. For inter-satellite routing it's more or= less a must-have unless you have some other packet switching protocol laye= red in between. On 1/09/2022 2:51 am, David Fern=E1ndez via Starlink wrote: "DNS on Starlink satellites: Good idea, lightweight, and I'd suspect maybe already in operation?" Are the satellites processing IP packets? Are the ISLs even in operation? I have been told Starlink satellites are transparent. > Date: Thu, 1 Sep 2022 01:41:07 +1200 > From: Ulrich Speidel > To: David Lang > Cc: Sebastian Moeller , Ulrich S= peidel via Starlink > > Subject: Re: [Starlink] Starlink "beam spread" > Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > Um, yes, but I think we're mixing a few things up here (trying to bundle > responses here, so that's not just to you, David). > > In lieu of a reliable Starlink link budget, I'm going by this one: > > https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potent= ial-emf-david-witkowski/ > > Parameters here are a little outdated but the critical one is the EIRP > at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka > band signal over a 600 km path, which is more reflective of the current > constellation. Then Friis propagation gives us a path loss of about 178 > dB, and if we pretend for a moment that Dishy is actually a 60 cm > diameter parabolic dish, we're looking at around 45 dBi receive antenna > gain. Probably a little less as Dishy isn't actually a dish. > > Then that gives us 97 dBm - 178 dB + 45 dB =3D -36 dBm at the ground > receiver. Now I'm assuming here that this is for ALL user downlink beams > from the satellite combined. What we don't really know is how many > parallel signals a satellite multiplexes into these, but assuming at the > moment a receive frontend bandwidth of about 100 MHz, noise power at the > receiver should be around 38 pW or -74 dBm. That leaves Starlink around > 38 dB of SNR to play with. Shannon lets us send up to just over 1.25 > Gb/s in that kind of channel, but then again that's just the Shannon > limit, and in practice, we'll be looking a a wee bit less. > > That SNR also gives us an indication as to the signal separation Dishy > needs to achieve from the beams from another satellite in order for that > other satellite to re-use the same frequency. Note that this is > significantly more than just the 3 dB that the 3 dB width of a beam > gives us. The 3 dB width is what is commonly quoted as "beam width", and > that's where you get those nice narrow angles. But that's just the width > at which the beam drops to half its EIRP, not the width at which it can > no longer interfere. For that, you need the 38 dB width - or thereabouts > - if you can get it, and this will be significantly more than the 1.2 > degrees or so of 3dB beam width. > > But even if you worked with 1.2 degrees at a distance of 600 km and you > assumed that sort of beam width at the satellite, it still gives you an > >12 km radius on the ground within which you cannot reuse the downlink > frequency from the same satellite. That's orders of magnitude more than > the re-use spatial separation you can achieve in ground-based cellular > networks. Note that the 0.1 deg beam "precision" is irrelevant here - > that just tells me the increments in which they can point the beam, but > not how wide it is and how intensity falls off with angle, or how bad > the side lobes are. > > Whether you can re-use the same frequency from another satellite to the > same ground area is a good question. We really don't know the beam > patterns that we get from the birds and from the Dishys, and without > these it's difficult to say how much angular separation a ground station > needs between two satellites using the same frequency in order to > receive one but not be interfered with by the other. Basically, there > are just too many variables in this for me to be overly optimistic that > re-use by two different sources within a Starlink cell is possible. And > I haven't even looked at the numbers for Ku band here. > > CDNs & Co - are NOT just dumb economic optimisations to lower bit miles. > They actually improve performance, and significantly so. A lower RTT > between you and a server that you grab data from via TCP allows a much > faster opening of the congestion window. With initial TCP cwnd's being > typically 10 packets or around 15 kB of data, having a server within 10 > ms of your client means that you've transferred 15 kB after 5 ms, 45 kB > after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25 > ms. Make your RTT 100 ms, and it takes half a second to get to your 465 > kB. Having a CDN server in close topological proximity also generally > reduces the number of queues between you and the server at which packets > can die an untimely early death, and generally, by taking load off such > links, reduces the probability of this happening at a lot of queues. > Bottom line: Having a CDN keeps your users happier. Also, live streaming > and video conferencing aside, most video is not multicast or broadcast, > but unicast. > > DNS on Starlink satellites: Good idea, lightweight, and I'd suspect > maybe already in operation? It's low hanging fruit. CDNs on satellites: > In the day and age of SSDs, having capacity on the satellite shouldn't > really be an issue, although robustness may be. But heat in this sort of > storage gets generated mostly when data is written, so it's a function > of what percentage of your data that reaches the bird is going to end up > in cache. Generally, on a LEO satellite that'll have to cache baseball > videos while over the US, videos in a dozen different languages while > over Europe, Bollywood clips while over India, cooking shows while over > Australia and always the same old ads while over New Zealand, all the > while not getting a lot of cache hits for stuff it put into cache 15 > minutes ago, would probably have to write a lot. Moreover, as you'd be > reliant on the content you want being on the satellite that you are > currently talking to, pretty much all satellites in the constellation > would need to cache all content. In other words: If I watch a cat video > now and thereby put it into the cache of the bird overhead, and then > send you an e-mail and you're in my neighbourhood and you watch it half > an hour later, my satellite would be on the other side of the world, and > you'd have to have it re-uploaded to the CDN on the bird that's flying > overhead our neighbourhood then. Not as efficient as a ground-based CDN > on our ground-based network that's fed via a satellite link. > > As long as Starlink is going to have in the order of hundreds of > thousands of direct users, that problem won't go away. > > On 31/08/2022 7:33 pm, David Lang wrote: > >> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote: >> >>> This combines with the uncomfortable truth that an RF "beam" from a >>> satellite isn't as selective as a laser beam, so the options for >>> frequency re-use from orbit aren't anywhere near as good as from a >>> mobile base station across the road: Any beam pointed at you can be >>> heard for many miles around and therefore no other user can re-use >>> that frequency (with the same burst slot etc.). >> >> not quite, you are forgetting that the antennas on the ground are also >> steerable arrays and so they can focus their 'receiving beam' at >> different satellites. This is less efficient than a transmitting beam >> as the satellites you aren't 'pointed' at will increase your noise >> floor, but it does allow the same frequency to be used for multiple >> satellites into the same area at the same time. >> >> David Lang >> > -- > **************************************************************** > 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/ > **************************************************************** > _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink -- **************************************************************** 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/ **************************************************************** --_000_BY5PR13MB3144A6C8C1A08B85C38AEF09E9789BY5PR13MB3144namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Ulrich,

 

I agree with you even I don’t know if StarLink= satellite will process IP packet. IETF may work on this area soon. IP is t= he mandatory if some IP based features are moved to satellite, such as DNS,= CDN, etc. Also, from 3GPP perspective, future LEO satellite network should be IP based. Then, the NTN integration= with 5G and Internet can be done.

check out my slide: https://datatracker.ietf.org/doc/slides-114-hotrfc-sessa-the-leo-satellite-= networking-lin-han/. We will have side meeting to discuss this in the n= ext IETF 115 (London).

 

BRs.

 

Lin

 

 

 

From: Starlink <starlink-bounces@lists.buf= ferbloat.net> On Behalf Of Ulrich Speidel via Starlink
Sent: Wednesday, August 31, 2022 2:46 PM
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"<= /p>

 

I work on the assumption that Starlink satellites are, or at least will = eventually be, processing IP packets. For inter-satellite routing it's more= or less a must-have unless you have some other packet switching protocol l= ayered in between.

On 1/09/2022 2:51 am, David Fern=E1ndez via Starlink= wrote:

"DNS on Starlink satellites: Good idea, lightwe= ight, and I'd suspect
maybe already in operation?"

Are the satellites processing IP packets? Are the ISLs even in
operation? I have been told Starlink satellites are transparent.


> Date: Thu, 1 Sep 2022 01:41:07 +1200
> From: Ulrich Speidel <u= .speidel@auckland.ac.nz>
> To: David Lang <david@lang.hm><= /a>
> Cc: Sebastian Moeller <moeller0@= gmx.de>, Ulrich Speidel via Starlink
> <starlink@lists.b= ufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <56e56b0f-07bd-fe0c-9434-2663ae9d4404@auckland.ac.nz>
> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed
>
> Um, yes, but I think we're mixing a few things up here (trying to bund= le
> responses here, so that's not just to you, David).
>
> In lieu of a reliable Starlink link budget, I'm going by this one:
>
> https://www.linkedin.com/pulse/quick-analysis-starlink-link-budget-potentia= l-emf-david-witkowski/
>
> Parameters here are a little outdated but the critical one is the EIRP=
> at the transmitter of up to ~97 dBm. Say we're looking at a 30 GHz Ka<= br> > band signal over a 600 km path, which is more reflective of the curren= t
> constellation. Then Friis propagation gives us a path loss of about 17= 8
> dB, and if we pretend for a moment that Dishy is actually a 60 cm
> diameter parabolic dish, we're looking at around 45 dBi receive antenn= a
> gain. Probably a little less as Dishy isn't actually a dish.
>
> Then that gives us 97 dBm - 178 dB + 45 dB =3D -36 dBm at the ground > receiver. Now I'm assuming here that this is for ALL user downlink bea= ms
> from the satellite combined. What we don't really know is how many
> parallel signals a satellite multiplexes into these, but assuming at t= he
> moment a receive frontend bandwidth of about 100 MHz, noise power at t= he
> receiver should be around 38 pW or -74 dBm. That leaves Starlink aroun= d
> 38 dB of SNR to play with. Shannon lets us send up to just over 1.25 > Gb/s in that kind of channel, but then again that's just the Shannon > limit, and in practice, we'll be looking a a wee bit less.
>
> That SNR also gives us an indication as to the signal separation Dishy=
> needs to achieve from the beams from another satellite in order for th= at
> other satellite to re-use the same frequency. Note that this is
> significantly more than just the 3 dB that the 3 dB width of a beam > gives us. The 3 dB width is what is commonly quoted as "beam widt= h", and
> that's where you get those nice narrow angles. But that's just the wid= th
> at which the beam drops to half its EIRP, not the width at which it ca= n
> no longer interfere. For that, you need the 38 dB width - or thereabou= ts
> - if you can get it, and this will be significantly more than the 1.2<= br> > degrees or so of 3dB beam width.
>
> But even if you worked with 1.2 degrees at a distance of 600 km and yo= u
> assumed that sort of beam width at the satellite, it still gives you a= n
> >12 km radius on the ground within which you cannot reuse the downl= ink
> frequency from the same satellite. That's orders of magnitude more tha= n
> the re-use spatial separation you can achieve in ground-based cellular=
> networks. Note that the 0.1 deg beam "precision" is irreleva= nt here -
> that just tells me the increments in which they can point the beam, bu= t
> not how wide it is and how intensity falls off with angle, or how bad<= br> > the side lobes are.
>
> Whether you can re-use the same frequency from another satellite to th= e
> same ground area is a good question. We really don't know the beam
> patterns that we get from the birds and from the Dishys, and without > these it's difficult to say how much angular separation a ground stati= on
> needs between two satellites using the same frequency in order to
> receive one but not be interfered with by the other. Basically, there<= br> > are just too many variables in this for me to be overly optimistic tha= t
> re-use by two different sources within a Starlink cell is possible. An= d
> I haven't even looked at the numbers for Ku band here.
>
> CDNs & Co - are NOT just dumb economic optimisations to lower bit = miles.
> They actually improve performance, and significantly so. A lower RTT > between you and a server that you grab data from via TCP allows a much=
> faster opening of the congestion window. With initial TCP cwnd's being=
> typically 10 packets or around 15 kB of data, having a server within 1= 0
> ms of your client means that you've transferred 15 kB after 5 ms, 45 k= B
> after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after = 25
> ms. Make your RTT 100 ms, and it takes half a second to get to your 46= 5
> kB. Having a CDN server in close topological proximity also generally<= br> > reduces the number of queues between you and the server at which packe= ts
> can die an untimely early death, and generally, by taking load off suc= h
> links, reduces the probability of this happening at a lot of queues. > Bottom line: Having a CDN keeps your users happier. Also, live streami= ng
> and video conferencing aside, most video is not multicast or broadcast= ,
> but unicast.
>
> DNS on Starlink satellites: Good idea, lightweight, and I'd suspect > maybe already in operation? It's low hanging fruit. CDNs on satellites= :
> In the day and age of SSDs, having capacity on the satellite shouldn't=
> really be an issue, although robustness may be. But heat in this sort = of
> storage gets generated mostly when data is written, so it's a function=
> of what percentage of your data that reaches the bird is going to end = up
> in cache. Generally, on a LEO satellite that'll have to cache baseball=
> videos while over the US, videos in a dozen different languages while<= br> > over Europe, Bollywood clips while over India, cooking shows while ove= r
> Australia and always the same old ads while over New Zealand, all the<= br> > while not getting a lot of cache hits for stuff it put into cache 15 > minutes ago, would probably have to write a lot. Moreover, as you'd be=
> reliant on the content you want being on the satellite that you are > currently talking to, pretty much all satellites in the constellation<= br> > would need to cache all content. In other words: If I watch a cat vide= o
> now and thereby put it into the cache of the bird overhead, and then > send you an e-mail and you're in my neighbourhood and you watch it hal= f
> an hour later, my satellite would be on the other side of the world, a= nd
> you'd have to have it re-uploaded to the CDN on the bird that's flying=
> overhead our neighbourhood then. Not as efficient as a ground-based CD= N
> on our ground-based network that's fed via a satellite link.
>
> As long as Starlink is going to have in the order of hundreds of
> thousands of direct users, that problem won't go away.
>
> On 31/08/2022 7:33 pm, David Lang wrote:
>
>> On Wed, 31 Aug 2022, Ulrich Speidel via Starlink wrote:
>>
>>> This combines with the uncomfortable truth that an RF "be= am" from a
>>> satellite isn't as selective as a laser beam, so the options f= or
>>> frequency re-use from orbit aren't anywhere near as good as fr= om a
>>> mobile base station across the road: Any beam pointed at you c= an be
>>> heard for many miles around and therefore no other user can re= -use
>>> that frequency (with the same burst slot etc.).
>>
>> not quite, you are forgetting that the antennas on the ground are = also
>> steerable arrays and so they can focus their 'receiving beam' at >> different satellites. This is less efficient than a transmitting b= eam
>> as the satellites you aren't 'pointed' at will increase your noise=
>> floor, but it does allow the same frequency to be used for multipl= e
>> satellites into the same area at the same time.
>>
>> David Lang
>>
> --
> ****************************************************************
> 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/
> ****************************************************************
>
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloa= t.net
https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************<=
/o:p>
Dr. Ulrich Speidel
 
School of Computer Science
 
Room 303S.594 (City Campus)
 
The University of Auckland
u.speidel@auckland.ac.nz 
ht=
tp://www.cs.auckland.ac.nz/~ulrich/
****************************************************************<=
/o:p>
 
 
 
--_000_BY5PR13MB3144A6C8C1A08B85C38AEF09E9789BY5PR13MB3144namp_--