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 44F5E3B29E for ; Tue, 22 Feb 2022 02:59:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1645516737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lfl9yXfTWY6b/KfCaD1/O3sf5Qofpv/1SjRZYOsEFj0=; b=ADtVkOijczfBOVAJJCxzMS8tbmzwtq/J8uFziQcJpj90iiHrh48uGUhXGAbPf8iJkGu7u9 YdovZ5Sz3i2Wr8EEU96cH8g+2573dxXKMq2SSnUiwEsNQK2LTqFSaInuDlSCdZbQNZ8ogQ LdcQ/Tei0r7CINKkF/cpRXKgPJcgiUs= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2233.outbound.protection.outlook.com [104.47.71.233]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-23-QSAzLZtENwiTMW32hPJeUA-1; Tue, 22 Feb 2022 18:58:55 +1100 X-MC-Unique: QSAzLZtENwiTMW32hPJeUA-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by MEYPR01MB7580.ausprd01.prod.outlook.com (2603:10c6:220:15d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.16; Tue, 22 Feb 2022 07:58:48 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::89c1:8ca9:129a:3a84]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::89c1:8ca9:129a:3a84%3]) with mapi id 15.20.4995.027; Tue, 22 Feb 2022 07:58:48 +0000 Message-ID: <5fc8796b-62d5-054d-1825-816809d355fe@cs.auckland.ac.nz> Date: Tue, 22 Feb 2022 20:58:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 To: starlink@lists.bufferbloat.net References: <1p492142-q944-r494-6s6r-p6q37s57qnq4@ynat.uz> <1F1EB112F8CB446FAB4BF308A76955FA@SRA6> <0ac195f5-3668-4c96-8dec-8a2d59a0bd52@Spark> <866405-s043-n12n-6pqs-46o38r189218@ynat.uz> <38pr9p5s-3ro4-49p9-9535-7o92oqrq62r1@ynat.uz> Cc: u.speidel@auckland.ac.nz From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SYBPR01CA0051.ausprd01.prod.outlook.com (2603:10c6:10:2::15) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6b11fe5b-95ac-4b13-f5d5-08d9f5d92867 X-MS-TrafficTypeDiagnostic: MEYPR01MB7580:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: mfCe056lWW/jTCYwi4iTPcXuUiKpCDQWXv+UWGMemlNGEQobwXbZkmEgmxcYbqZJMa1rawOtLJFGsjkYwZ03PRYyRo3sUiuJhHp+hPqe2zC1xTWYV55tJHFqUny2XdZ9uMuscwyt3fiyjFT156Cpz8wi44ajOyMftXa25mdAQRcfxlFGgpaXTCed274dxu2iSZfeDyJK6Yrl6DoT+wZvId3GjiAcQdig3Y4l3YDGVvtvuLpLN/4fo1HBDLmNtB7alv0JtwAKR4Ju8yHbV4wuir/Xux6v66M19S/0qR1LMY59dCpBHtM6W1w21Tas2Qm1wP5TUHg7jxq38UgEM6EZdMmjDXwrD0DZOPPur8wN3vXdQ2T+bvcAsqhGBNKJ7uRDC479DDbpL3YpaoL+O2Bjle7mIx3ustl6r4KNwtROKpNAdMiY7x+ozrmFR6oTK/kPFw32zycSbPxBdVbODkgABDhfH7DdGLBvzM63Tp92Ti+EyssoAA5qe51cwy6zIxn589qQgwiaOpka53yR1BpOAeslY5nwh0ti+SzhD/DJ27OWkr3AnG+gVN7cUFdgTD1re1d+b6AT6Xk1KFWu4Zp5I124TjH2/a30VYdWaTszV0mjjaOqjHWkWP3OAiZ0X2oJXglVJC6M4XUEeKKq2fDvpWw21qnjQMLhUQTklPWvxjGS2T1LqdqYGtmdACtkNoigV+eoo2pJv1MrKyaAa+l7KEZRmY9aZgwEf26bxEAP9IvybPYy5HnKLGAbzD9iX8quiKbUbTRcRJBPGwQ3krRqESGBM7ZiK9cv28S71myarVdiGY5NRgC0N4+NR+Gz8ApgeEGProguiU8isRkDCGVIbBJBHqy/VqFdVGlDWkp8ApQ= 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:(13230001)(4636009)(366004)(66946007)(2906002)(966005)(66556008)(66476007)(8676002)(38100700002)(6506007)(53546011)(30864003)(166002)(8936002)(6512007)(6486002)(4326008)(6666004)(33964004)(508600001)(5660300002)(316002)(107886003)(786003)(31686004)(2616005)(31696002)(186003)(83380400001)(83170400001)(6916009)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N1JPNzluR0F2cU0rbFhVc0QvSUFyQi9laW5hS3FkM1ZML21XdG5jQnN3cFli?= =?utf-8?B?YzBzMGpZUkxTRzU0UkxwK3VxSWxkYUZUZTI2QUVWV3YwWXplMkdCRFQydmNz?= =?utf-8?B?SGJ3VUpkaDBLeFFxUU1UZmVDMzZxUGdzWWlWZE84MkVqZmFEaGZxWGVpTWtv?= =?utf-8?B?NzdGY3ErZVlmeUFnUjd4WUVzOThsUzIwMG1KRFdvMHpGVmc4M2I3cjdOZFpM?= =?utf-8?B?dWZDRlZEaFAvMHY4b3Z3Q3M2dVIvSS9PMkR1SktPM1F3WmI4M0xPdVgrTG5H?= =?utf-8?B?RmI2ZFAyVmdpa3NYUGZJZi80UlQxQ2xBb0dCTlI5M0R6TDRLbCtaYXhDOWJr?= =?utf-8?B?S1YxZDhTazA0MGQ5cVhqU3NPWk85UkgxeWNTbDFXaCswdmZ0WUFjUkV6TndP?= =?utf-8?B?ZDZYekZBQ1dwNmJUSGhGNXdaU2gvV1JsYmR5V0dFdFU0dnZtcnplQ0tTTWVj?= =?utf-8?B?ZGRWcGkweUNqTXhaa3JGSTdnMStqQ285TE9NTFFDa1ZNYmE1YnNxcHBmSUVx?= =?utf-8?B?M0Jtazg5YS9RT0dNM2JaLzh0ayt2RUloTUFqcmJ2Skxvbk9wZWk0REtlUEph?= =?utf-8?B?QWhJTDBGUjVPMWV2Ym83RE9DTHdZbDJ3MnljdElyNjBodVFQRHdUNXZxQTNV?= =?utf-8?B?N1A0WWJHc3BWVEJ4d1lnbDF5V05hQkRScFFhYU5MdjFmYjJ5d3FJa0MwbmZQ?= =?utf-8?B?TU8xMVVyQ3FNS1ZWTXhmTmxHOS9zV053bmxpYTQ1NmxDWUNoeGJTU3FRRGZp?= =?utf-8?B?Q253c2RXVzE5RU9NdXU3RmxpRVN2RXhUd2tlbXpScHY3U3IwbTQzSy9WeWE5?= =?utf-8?B?L09iSU9odGlUcCtodXAwQUpmTThwaUUwVFBOL0hSUGY5R0VYNWxJVkpTbFFL?= =?utf-8?B?MkdXZE8rYXBPbDFWYTdHYVV4OGVjSjdsV0RjUDhuTFVpbjNRUGZFeDJxaGF3?= =?utf-8?B?Z1pWQk1XWUtSRlBSQkg2eHdXRG1pZDBkU2F4VXMyUEtOL2t5VmI1YmlqL1Ar?= =?utf-8?B?K2NVWmc0aWlnd2pRUFZ1M2Z5WHptOVJJbTNSMDJvc3RMdGlzbDdLcEsvaEY0?= =?utf-8?B?TjZuVnRzTWtjUVR5bWR0RUticjByQm9PTGlFaW1IN1VOcmpSeFVlbHRtOE9F?= =?utf-8?B?UGFyd1RhaXQrdjFKaEczS3M2STJRQytxd0E5Yng4UWFRZE5ETW9mMWlqWnU3?= =?utf-8?B?RHBtTFpGWHRxTVd4djIvaFhxemtRTklVQnExbnNNUnQrQjB5UzBlT1IwWUtT?= =?utf-8?B?RXZRZTF2aGx4ZENWZXI4WlgvWkF1N2Exc3R1MVM3WkRsNWg3NGtURVRnRk1C?= =?utf-8?B?M0VNcWtaMXJpNlg5dlBjejdtSzV4a0lVY3I1VVhtTUEvZVVjV00wOXBYQS93?= =?utf-8?B?L2d6NVluYXl4V0hyNklFZDIxWjN5Q0FKeEJLWHp4NmR3WGNNYko5QVNkQkpP?= =?utf-8?B?TWZIMnlVTlVYWFZDV1dwaFB2ZVorTGhIdXo2OEhZejlsb2w2MFdEaDFhekc4?= =?utf-8?B?TWFFQm5PRFhXVUl2WWFTeElWMU8zZzdKd3BnR1lKem5HakJ1YWNLQ3p1NXVG?= =?utf-8?B?K0RzaXpseklGMU1Gb2VNQ0R1K0EySTlla0NtQmk0WnViRVY1MmI0ZG9OR1Vz?= =?utf-8?B?aVFtQXN1SWpxNStYSGhZSHF3MHlPb0VRZ2dTcU5qdHNjNDZkd2JYQ2NHMmlw?= =?utf-8?B?MXptMFZRUHhKeXgwNGNTRDJFZ3Z2a2Y4bWkwcXIvYjRqcFVJemxyYlVzaDU4?= =?utf-8?B?RkhnV2kzeTcya0hydUFwZHJGV2tKbWFQSk9PZkZ2U1NhdVlvWVRjZ0RxWktp?= =?utf-8?B?bzRYeGh0VG1WNW1KdW1tWmNvVWVRelF2eTg0aUNveXlsS0VWUStSa0pWdzRU?= =?utf-8?B?cFhPOXVIK2RVSk5jMEl4Tnh1OFBISDdqZ2ZrZ3JMaFJaODhnL3BxVmxzaWw0?= =?utf-8?B?NkF3citzK09SUFRUMVhzZ0Y4aU9OUG4zWkFyM0RHZlQ0bk9LTU1FZDE5d2dO?= =?utf-8?B?dlp3WnRpQWg5cEkrdlg4dmxsNVpXTjVVamMxL3VHNmdPOUlOc3JHWWZvcG5S?= =?utf-8?B?RjFEZExsUTdvaWg2c0FCbHQ1bHJLZ1FUeENBVURGV1ZUTkYxSFAvWHJqYi9S?= =?utf-8?B?KzNlVWRXMXJmb0NhbkJyQTVSb0gxVlJUREtUczc2eTVQU3ZWZDYydm5Ibnhw?= =?utf-8?B?bldCNURQRVdtdkVHb1VTSW0wR1VseVNpbTYxV2QwNmVHdlRhMkE4aWg1aXA3?= =?utf-8?B?b3hqTFBXSFBYUUEybFFjUXRjVmhzZTJTRVNVS2RURndoR0FoMjNzQWx2S3ZP?= =?utf-8?B?RGFtaU1WK0srNlh0TnlmZy9kOUhiYVkvYVd2SGxaWkJzaGVHMVVISUp2cmtr?= =?utf-8?Q?SaSwQ9OLUSX0M/xk=3D?= X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 6b11fe5b-95ac-4b13-f5d5-08d9f5d92867 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2022 07:58:48.6276 (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: 7BnMbi0JAQ7L0LaXs1wMgQjYiCtTYLqAiMSeJ1OEcdTB+XlPa4psVNg7lI1QbKKYyWGR5SqAY3twT1avGBhvpqw9D9OvUsudO/ZL5O+ahcM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYPR01MB7580 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------A6qhJkoCAurH7s54Gr4tfnbs" Content-Language: en-US Subject: Re: [Starlink] Starlink Roaming 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: Tue, 22 Feb 2022 07:59:05 -0000 --------------A6qhJkoCAurH7s54Gr4tfnbs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Perhaps worth remembering that they don't have to engineer the final=20 system right now. Consider that: - Building ground station gateways costs money, but as the number of=20 subscribers grows, so does the income stream that allows for ground=20 station construction. - Gateway ground stations, if generally kept close to users, at least=20 where there are lots of users, don't have the problem that there's no=20 land to put them on as there aren't normally lots of users in the middle=20 of the sea. - Where there are more than 10k users, someone will generally put a=20 fibre optic cable there or at least think hard about how they can get=20 that done. We've seen this widely in the Pacific, where such islands now=20 generally have fibre (with some notable exceptions). Once you have=20 fibre, there's no reason why you can't have a LEO ground station there.=20 So you can generally always build more - Constellations that are short of capacity can be added to=20 incrementally. Remember Starlink is at a very early stage of what=20 they're planning. - Satellite capacity depends on a lot of things, from on-board=20 processing capacity to the bandwidth of the uplinks and downlinks and=20 the received signal levels on those. Current Starlink gateway antennas=20 are tiny by satellite infrastructure standards, but that doesn't=20 preclude bigger antennas and more gateways for the future, which allows=20 more satellites to be provided with direct gateway links. In some ways, this evolution mirrors that of mobile networks. In the=20 early stage of mobile network evolution, the providers aimed at getting=20 coverage with the least number of base stations from the highest hills=20 and buildings available. These never had the potential to provide the=20 capacity that today's networks have, so as the networks evolved, they=20 moved down from the lofty heights to the bottom of the valleys, cashing=20 in on improved frequency re-use potential (you could re-use the same=20 frequency a valley over, you see, because the ridge between yours and=20 theirs meant that signals wouldn't interfere). It also meant less path=20 loss to the end users (so more battery life for them). Not to mention=20 fewer lawsuits from people who were worried about large towers=20 irradiating their kids. The cost of those lawsuits, by the way, was seen=20 simply as something to factor in when making engineering decisions. On 22/02/2022 8:20 pm, Dick Roy wrote: > > ------------------------------------------------------------------------ > > *From:*Starlink [mailto:starlink-bounces@lists.bufferbloat.net] *On=20 > Behalf Of *Mike Puchol > *Sent:* Monday, February 21, 2022 9:35 PM > *To:* Daniel AJ Sokolov; David Lang > *Cc:* starlink@lists.bufferbloat.net > *Subject:* Re: [Starlink] Starlink Roaming > > Actually, laser links would make gateway connectivity *worse*. If we=20 > take the scenario attached, one gateway is suddenly having to serve=20 > traffic from all UTs that were not previously under coverage. > > A satellite under full load can saturate two gateway links by itself.=20 > If you load, say, 20 satellites in an orbital plane, onto a single=20 > gateway, over ISL, you effectively have 5% of each satellite=E2=80=99s=20 > capacity available (given an equal distribution of demand, of course=20 > there will be satellites with no UTs to cover etc.). > > */[RR] I think to do this analysis correctly; one needs to consider=20 > the larger system and the time-varying loads on the components=20 > thereof. What you say is true; just a bit over-simplified to be=20 > maximally useful. Routing through complex congested networks is=20 > well-studied problem and hnts at possible solutions can probably be=20 > found there/**/J/**/)/* > > > > Eventually they will go for optical gateways, it=E2=80=99s the only way t= o get=20 > enough capacity to the constellation, specially the 30k satellite version= . > > */[RR] What do you mean by =E2=80=9C=E2=80=9Doptical gateway=E2=80=9D? An= optical link from=20 > the satellite to the ground station? That would be real expensive at=20 > least power-wise and unreliable./* > > > Best, > > Mike > > On Feb 22, 2022, 05:17 +0300, David Lang , wrote: > > On Mon, 21 Feb 2022, Daniel AJ Sokolov wrote: > > On 2022-02-21 at 13:52, David Lang wrote: > > > They told me that I could try it, and it may work, may be degraded a > bit, or may not work at all. They do plan to add roaming capabilities in > the future (my guess is that the laser satellites will enable a lot more > flexibility) > > > Isn't that a very optimistic assessment? :-) > > Laser links are great for remote locations with very few users, but how > could they relieve overbooking of Starlink in areas with too many users? > > The laser links can reduce the required density of ground stations, but > they don't add capacity to the network. Any ground station not built > thanks to laser links adds load to other ground stations - and, maybe > more importantly, adds load to the satellite that does eventually > connect to a ground station. > > Can laser links really help on a large scale, or are they just a small > help here and there? > > > My thinking is that the laser links will make it possible to route the=20 > traffic > from wherever I am to the appropriate ground station that I'm=20 > registered with as > opposed to the current bent-pipe approach where, if I move to far from my > registered location, I need to talk to a different ground station. > > Currently there are two limits in any area for coverage: > > 1. satellite bandwidth > 2. ground station bandwidth > > laser links will significantly reduce the effect of the second one. > > We know that they can do mobile dishes (they are testing it currently=20 > on Elon's > gulfstream, FAR more mobile that I will ever be :-) ) > > David Lang > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink=20 > > > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------A6qhJkoCAurH7s54Gr4tfnbs Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Perhaps worth remembering that they don't have to engineer the final system right now. Consider that:

- Building ground station gateways costs money, but as the number of subscribers grows, so does the income stream that allows for ground station construction.
- Gateway ground stations, if generally kept close to users, at least where there are lots of users, don't have the problem that there's no land to put them on as there aren't normally lots of users in the middle of the sea.
- Where there are more than 10k users, someone will generally put a fibre optic cable there or at least think hard about how they can get that done. We've seen this widely in the Pacific, where such islands now generally have fibre (with some notable exceptions). Once you have fibre, there's no reason why you can't have a LEO ground station there. So you can generally always build more
- Constellations that are short of capacity can be added to incrementally. Remember Starlink is at a very early stage of what they're planning.
- Satellite capacity depends on a lot of things, from on-board processing capacity to the bandwidth of the uplinks and downlinks and the received signal levels on those. Current Starlink gateway antennas are tiny by satellite infrastructure standards, but that doesn't preclude bigger antennas and more gateways for the future, which allows more satellites to be provided with direct gateway links.

In some ways, this evolution mirrors that of mobile networks. In the early stage of mobile network evolution, the providers aimed at getting coverage with the least number of base stations from the highest hills and buildings available. These never had the potential to provide the capacity that today's networks have, so as the networks evolved, they moved down from the lofty heights to the bottom of the valleys, cashing in on improved frequency re-use potential (you could re-use the same frequency a valley over, you see, because the ridge between yours and theirs meant that signals wouldn't interfere). It also meant less path loss to the end users (so more battery life for them). Not to mention fewer lawsuits from people who were worried about large towers irradiating their kids. The cost of those lawsuits, by the way, was seen simply as something to factor in when making engineering decisions.

On 22/02/2022 8:20 pm, Dick Roy wrote:
=20

 =

 =

From:<= /b> Starlink [mailto:starlink-bounces@lists.bufferbloat.n= et] On Behalf Of Mike Puchol
Sent: Monday, February 21, 2022 9:35 PM
To: Daniel AJ Sokolov; David Lang
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Roaming

 

Actually,= laser links would make gateway connectivity *worse*. If we take the scenario attached, one gateway is suddenly having to serve traffic from all UTs that were not previously under coverage. 

A satellite under full load can saturate two gateway links by itself. If you load, say, 20 satellites in an orbital plane, onto a single gateway, over ISL, you effectively have 5% of each satellite=E2=80=99s capac= ity available (given an equal distribution of demand, of course there will be satellites with no UTs to cover etc.).

[RR] I think to do this analysis correctly; one needs to consider the larger system and the time-varying loads on the components thereof. What you say is true; just a bit over-simplified to be maximally useful. Routing through complex congested networks is well-studied problem and hnts at possible solutions can probably be found there= J)=



Eventually they will go for optical gateways, it=E2=80=99= s the only way to get enough capacity to the constellation, specially the 30k satellite version.

[RR] What do you mean by =E2=80=9C=E2=80=9Doptical gateway=E2=80=9D? An optical link from the satellite = to the ground station? That would be real expensive at least power-wise and unreliable.

=
Best,

Mike

= On Feb 22, 2022, 05:17 +0300, David Lang <david@lang.hm>, wrote:

= On Mon, 21 Feb 2022, Daniel AJ Sokolov wrote:

= On 2022-02-21 at 13:52, David Lang wrote:

=
They told me that I could try it, and it may work, may be degraded a
bit, or may not work at all. They do plan to add roaming capabilities in
the future (my guess is that the laser satellites will enable a lot more
flexibility)

=
Isn't that a very optimistic assessment? :-)

Laser links are great for remote locations with very few users, but how
could they relieve overbooking of Starlink in areas with too many users?

The laser links can reduce the required density of ground stations, but
they don't add capacity to the network. Any ground station not built
thanks to laser links adds load to other ground stations - and, maybe
more importantly, adds load to the satellite that does eventually
connect to a ground station.

Can laser links really help on a large scale, or are they just a small
help here and there?

=
My thinking is that the laser links will make it possible to route the traffic
from wherever I am to the appropriate ground station that I'm registered with as
opposed to the current bent-pipe approach where, if I move to far from my
registered location, I need to talk to a different ground station.

Currently there are two limits in any area for coverage:
1. satellite bandwidth
2. ground station bandwidth

laser links will significantly reduce the effect of the second one.

We know that they can do mobile dishes (they are testing it currently on Elon's
gulfstream, FAR more mobile that I will ever be :-) )

David Lang
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


______________________________=
_________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz=20
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------A6qhJkoCAurH7s54Gr4tfnbs--