From: "David Fernández" <davidfdzp@gmail.com>
To: starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink direct-to-device in NZ
Date: Fri, 31 Oct 2025 10:38:16 +0100 [thread overview]
Message-ID: <CAC=tZ0rK1zceiN1ghtY5QBAgTWVvQA0wHy_4t5wLZtSeVt6GOw@mail.gmail.com> (raw)
In-Reply-To: <176185773121.1561.12225098134842210235@gauss>
About backhauling using a Starlink dishy, as shown in that case of KDDI,
this paper studied how many users you can serve with that setup (< 100
simultaneously):
Concept and Evaluation Of 5G Backhauling via Starlink
<https://www.researchgate.net/publication/365488929_Concept_and_Evaluation_Of_5G_Backhauling_via_Starlink>
Satellite links are widely used nowadays for cellular base station backhaul
when the distance between the base station equipment and the core of the
network is too large for microwave to be an economical solution. While
satellite backhaul for mobile networks is focused on reducing the bandwidth
required to transport voice, backhaul optimization for broadband Internet
access includes header data compression, web and video acceleration and
caching.
Here, another example that has been mentioned in the past in this list:
Connecting Every Home in Africa - Starlink Backhaul?
<https://circleid.com/posts/20230309-connecting-every-home-in-africa-starlink-backhaul>
When combined with solar panels and electric energy distribution networks,
these satellite backhauling solutions can provide mobile coverage to rural
and remote areas: Red Eléctrica prueba la viabilidad de burbujas de
conectividad vía satélite en apoyos de alta tensión | Redes&Telecom
<https://www.redestelecom.es/conectividad/red-electrica-prueba-la-viabilidad-de-burbujas-de-conectividad-via-satelite-en-apoyos-de-alta-tension/>
Regards,
David
Date: Thu, 30 Oct 2025 13:03:20 -0700
> From: J Pan <Pan@uvic.ca>
> Subject: [Starlink] Re: Starlink direct-to-device in NZ
> To: Spencer Sevilla <spencer.builds.networks@gmail.com>
> Cc: Ulrich Speidel <u.speidel@auckland.ac.nz>, Michael Richardson
> <mcr@sandelman.ca>, Dave Taht via Starlink
> <starlink@lists.bufferbloat.net>
> Message-ID:
> <CAHn=e4hCQ5DqkRPiMKgqmh+feu2NPw=
> 2Ka-v7_kSwSVJ_7hqRA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> yes, kddi has been doing this (using starlink for cellular backhaul)
> on remote islands in japan for a while
>
> https://news.kddi.com/kddi/corporate/english/newsrelease/2022/12/01/6415.html
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> On Thu, Oct 30, 2025 at 12:31 PM Spencer Sevilla via Starlink
> <starlink@lists.bufferbloat.net> wrote:
> >
> > > So by running D2C, they're essentially throwing an expensive resource
> at an application with fairly limited earnings potential.
> > >
> > > But hey, it's great if all you need is TXT on a hike.
> >
> > I don’t know a ton about the business relationship between Starlink and
> OneNZ (or T-Mobile here in the States) but to be honest this is how I've
> always viewed any of the direct-to-mobile Starlink services. Can’t imagine
> it being worth the effort on its own, but makes more sense to me as a
> super-low-bandwidth supplement for texting/calling, especially in an
> emergency context.
> >
> > Much more interesting, IMO, is targeted coverage of higher-density
> remote areas (e.g. small towns/villages/farms or highways) using Starlink
> to backhaul a cell tower. I assume some networks are doing that, but it’s
> hard to find good information online as the first case tends to crowd out
> the results.
> >
> > > On Oct 29, 2025, at 13:28, Ulrich Speidel via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> > >
> > > On 30/10/2025 4:29 am, Michael Richardson wrote:
> > >> Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
> > >> > In July 2025, One NZ extended the service to phones on prepay
> plans,
> > >> > including the plan I'm on ... as long as I'd have an eligible
> phone.
> > >> Is your phone eligible because it lacks the right radios, or because
> it's not
> > >> blessed?
> > > I've no idea, but I suspect that a range of cheaper phones (mine does
> 3G/4G/5G) have lower sensitivity radios than the higher end devices (read:
> elevated noise floors due to proximity to heat generating components in the
> phone, smaller antenna size, conductors carrying RF that aren't
> gold-plated, coarser signal processing, interference from processing chips
> in the phone etc.).
> > >> My experience with NZ consists of changing planes in Auckland in 2024.
> > >> (And that's my own time to the southern hemisphere).
> > > That's how I first got here so you're in good company ;-)
> > >> I don't know how much
> > >> of NZ is unserved by 3G/4G. It sounds to be that the One NZ
> terrestial
> > >> network coverage is pretty good?
> > >
> > > Basically, yes. The three mobile carriers here cover - at least to TXT
> quality - most places where people would normally be. Rural locations used
> to be an issue until the government knocked heads together and forced the
> three carriers to found a common subsidiary, the Rural Connectivity Group
> (RCG), to set up cell sites in rural areas on which the three carriers
> would be virtual tenants. The downside of this of course is that when these
> go down, so do all three networks, as we had ample opportunity to witness
> during Cyclone Gabrielle a couple of years ago. There is also pretty good
> coastal coverage for boaties from the terrestrial network, although the
> Starlink-based service reaches further out.
> > >
> > > The remaining "uncovered" area still makes up around 40% of the land
> surface according to One NZ, but these are generally places where there are
> extremely few people. Much is bush / forest and where there is remote
> farmland, the locals usually have land mobile / CB radios to communicate.
> > >
> > >>
> > >> Canada has similiar concentrations of coverage, with most of the
> smaller
> > >> operators having big-city-only coverage. Many smaller towns can have
> > >> effective single suppliers (Yes, there is a duopoly. But some towns
> have
> > >> very few towers from the "other")
> > > Canada is similar in many respects but has a much larger land area and
> lower population density over much of it.
> > >>
> > >> What I'd want is a $4/day-pass for when I go hiking. I don't think
> current
> > >> emergency call support covers emergency txt. Is there even spec for
> txt to
> > >> 911, I don't know. It would, I think be tolerant of much lower
> bandwidth.
> > >> A day-pass could be "messaging" only, like the airlines "free" wifi
> level.
> > > ... which is pretty much what you'd get here (provided you subscribed
> to the more expensive basic prepay package).
> > >>
> > >> > They're also working on getting the data service working. Which
> will support
> > >> > a limited number of mostly messaging apps only by the looks of
> it. Different
> > >> > flavour of TXT I suppose.
> > >>
> > >> I'm not sure why this is difficult; if I were asked to implement I'd
> just
> > >> block a bunch of well-known streaming end-points on day one. Yes,
> blocking
> > >> youtube blocks all sorts of other google services. I'd fix that day
> two
> > >> as I got bandwidth based caps/throttling implemented.
> > >
> > > This isn't a networking problem predominantly, but an RF engineering
> one. Essentially, your classical cellphone network works on the premise
> that you can serve more users by bringing the base stations closer to them,
> which allows (a) lower power use and (b) conserves their battery. The lower
> power use then allows you to re-use your frequencies further down the road.
> > >
> > > This alone implies that when your "cell tower" is many hundred of km
> away, this goes against the grain of the cell system design philosophy. You
> now need more power (or larger antennas) and re-using your frequencies
> isn't all that easy anymore. You can't put large antennas on people's
> phones, so the only place to put them is in space.
> > >
> > > But wait, it gets worse. Frequency matters.
> > >
> > > Normal Starlink downlinks to DIshy users on Ku band frequencies.
> That's between 10,700 MHz and 12,700 MHz (note also that's a 2 GHz
> bandwidth). For the Starlink cell service, One NZ gets them to use 1800 MHz
> in what is now a 15 MHz bandwidth (
> https://www.linkedin.com/posts/richardhaas99_new-new-zealand-mobile-operator-one-has-activity-7358493392294580225-NVsr/).
> That's at least a factor of 6 in terms of frequency.
> > >
> > > Consider an RF communication system with fixed physical dimensions
> (antenna sizes, distance between transmitter and receiver) and a fixed
> transmit power. Assume for a moment that you can make this use any
> frequency you like (i.e., ignore antenna resonances, transmitter/receiver
> tuning etc.). The received power that you will then have available at your
> receiver is proportional to the square of the transmit frequency. This
> gives Ku band a 6*6=36 fold advantage over the cell band, and that's before
> you start looking at the bandwidth.
> > >
> > > Moreover, the higher your frequency, the more directional your
> antennas become. That is, Starlink has a much easier time projecting a Ku
> band beam at a location than a cell signal. And it sure looks like they're
> struggling a bit with the former, even with Ku band cells much larger than
> your typical mobile phone cell. And that's with you pointing your Dishy at
> the sky as instructed rather than having it at the bottom of your gym bag.
> So your cell phone signal from space isn't exactly laser pointer material,
> and getting the tiny device in your pocket to hit just the satellite you're
> meant to communicate with is an uphill struggle at the best of times.
> > >
> > > So, basically, fitting data in next to TXT isn't trivial.
> > >
> > > For One NZ and their colleagues at T-Mobile etc. overseas, this means
> that once they earmark a cell phone frequency for satellite use, they can't
> really use it on the ground anymore because a satellite using it is now
> going to be "heard" all over the place and not just where the user is.
> Neither can they re-use that frequency in multiple locations all that
> easily. Read: Commit a frequency for satellite use in the northern North
> Island and you can't - in all probability - use it anywhere in Auckland.
> Engineering aside, they now face the extra problem that ... spectrum is
> expensive. In 2021, that cost NZ$720,000 per MHz (
> https://www.rsm.govt.nz/about/news-and-updates/renewal-of-management-rights-in-the-1800-mhz-and-2100-mhz-bands).
> So that 15 MHz band for D2C would have cost One NZ just upwards of US$6M.
> > >
> > >
> > >
> > >>
> > > --
> > > ****************************************************************
> > > 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/
> > > ****************************************************************
>
>
next parent reply other threads:[~2025-10-31 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <176185773121.1561.12225098134842210235@gauss>
2025-10-31 9:38 ` David Fernández [this message]
2025-10-31 16:05 ` J Pan
2025-10-31 16:12 ` David Fernández
2025-10-29 3:54 [Starlink] " Ulrich Speidel
[not found] ` <18172.1761751760@obiwan.sandelman.ca>
2025-10-29 20:28 ` [Starlink] " Ulrich Speidel
2025-10-30 19:31 ` Spencer Sevilla
2025-10-30 20:03 ` J Pan
2025-10-30 20:55 ` Inemesit Affia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=tZ0rK1zceiN1ghtY5QBAgTWVvQA0wHy_4t5wLZtSeVt6GOw@mail.gmail.com' \
--to=davidfdzp@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox