From: J Pan <Pan@uvic.ca>
To: "David Fernández" <davidfdzp@gmail.com>
Cc: starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] Re: Starlink direct-to-device in NZ
Date: Fri, 31 Oct 2025 09:05:58 -0700 [thread overview]
Message-ID: <CAHn=e4hOEqECDDm7fEeSWzmVUZkHXwCEC5JLPbTwSeM0jnHLtg@mail.gmail.com> (raw)
In-Reply-To: <CAC=tZ0rK1zceiN1ghtY5QBAgTWVvQA0wHy_4t5wLZtSeVt6GOw@mail.gmail.com>
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:06 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 [this message]
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='CAHn=e4hOEqECDDm7fEeSWzmVUZkHXwCEC5JLPbTwSeM0jnHLtg@mail.gmail.com' \
--to=pan@uvic.ca \
--cc=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