From: "David Fernández" <davidfdzp@gmail.com>
To: J Pan <Pan@uvic.ca>
Cc: starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink direct-to-device in NZ
Date: Fri, 31 Oct 2025 17:12:28 +0100 [thread overview]
Message-ID: <CAC=tZ0oixPhf1zCDcMgwbHGYy1H=BcisXQ9aZEQPn=eByWH9pQ@mail.gmail.com> (raw)
In-Reply-To: <CAHn=e4hOEqECDDm7fEeSWzmVUZkHXwCEC5JLPbTwSeM0jnHLtg@mail.gmail.com>
👍
David Fernández reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>
On Fri, 31 Oct 2025 at 17:06, J Pan <Pan@uvic.ca> wrote:
> yes, starlink (or other leo-sat-nets too) can be a good mid-mile
> solution in addition to direct-to-home and direct-to-cell phone. we
> have a project (see attached) for the canadian north too
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA,
> Web.UVic.CA/~pan
>
> On Fri, Oct 31, 2025 at 8:41 AM David Fernández via Starlink
> <starlink@lists.bufferbloat.net> wrote:
> >
> > 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/
> > > > > ****************************************************************
> > >
> > >
> > _______________________________________________
> > Starlink mailing list -- starlink@lists.bufferbloat.net
> > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net
>
next prev parent reply other threads:[~2025-10-31 16:13 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
2025-10-31 16:05 ` J Pan
2025-10-31 16:12 ` David Fernández [this message]
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=tZ0oixPhf1zCDcMgwbHGYy1H=BcisXQ9aZEQPn=eByWH9pQ@mail.gmail.com' \
--to=davidfdzp@gmail.com \
--cc=Pan@uvic.ca \
--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