Re: [LibreQoS] [Rpm] [Starlink] On FiWi

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8135 bytes --]

This is a pretty neat box:

https://mikrotik.com/product/netpower_lite_7r

What are the compelling arguments for fiber vs copper, again?


On Tue, Mar 14, 2023 at 4:10 AM Mike Puchol via Rpm <
rpm@lists.bufferbloat.net> wrote:

> Hi Bob,
>
> You hit on a set of very valid points, which I'll complement with my views
> on where the industry (the bit of it that affects WISPs) is heading, and
> what I saw at the MWC in Barcelona. Love the FiWi term :-)
>
> I have seen the vendors that supply WISPs, such as Ubiquiti, Cambium, and
> Mimosa, but also newer entrants such as Tarana, increase the performance
> and on-paper specs of their equipment. My examples below are centered on
> the African market, if you operate in Europe or the US, where you can
> charge customers a higher install fee, or even charge them a break-up fee
> if they don't return equipment, the economics work.
>
> Where currently a ~$500 sector radio could serve ~60 endpoints, at a cost
> of ~$50 per endpoint (I use this term in place of ODU/CPE, the antenna that
> you mount on the roof), and supply ~2.5 Mbps CIR per endpoint, the
> evolution is now a ~$2,000+ sector radio, a $200 endpoint, capability for
> ~150 endpoints per sector, and ~25 Mbps CIR per endpoint.
>
> If every customer a WISP installs represents, say, $100 CAPEX at install
> time ($50 for the antenna + cabling, router, etc), and you charge a $30
> install fee, you have $70 to recover, and you recover from the monthly
> contribution the customer makes. If the contribution after OPEX is, say,
> $10, it takes you 7 months to recover the full install cost. Not bad,
> doable even in low-income markets.
>
> Fast-forward to the next-generation version. Now, the CAPEX at install is
> $250, you need to recover $220, and it will take you 22 months, which is
> above the usual 18 months that investors look for.
>
> The focus, thereby, has to be the lever that has the largest effect on the
> unit economics - which is the per-customer cost. I have drawn what my ideal
> FiWi network would look like:
>
>
>
> Taking you through this - we start with a 1-port, low-cost EPON OLT (or
> you could go for 2, 4, 8 ports as you add capacity). This OLT has capacity
> for 64 ONUs on its single port. Instead of connecting the typical fiber
> infrastructure with kilometers of cables which break, require maintenance,
> etc. we insert an EPON to Ethernet converter (I added "magic" because these
> don't exist AFAIK).
>
> This converter allows us to connect our $2k sector radio, and serve the
> $200 endpoints (ODUs) over wireless point-to-multipoint up to 10km away.
> Each ODU then has a reverse converter, which gives us EPON again.
>
> Once we are back on EPON, we can insert splitters, for example,
> pre-connectorized outdoor 1:16 boxes. Every customer install now involves a
> 100 meter roll of pre-connectorized 2-core drop cable, and a $20 EPON ONU.
>
> Using this deployment method, we could connect up to 16 customers to a
> single $200 endpoint, so the enpoint CAPEX per customer is now $12.5. Add
> the ONU, cable, etc. and we have a per-install CAPEX of $82.5 (assuming the
> same $50 of extras we had before), and an even shorter break-even. In
> addition, as the endpoints support higher capacity, we can provision at
> least the same, if not more, capacity per customer.
>
> Other advantages: the $200 ODU is no longer customer equipment and CAPEX,
> but network equipment, and as such, can operate under a longer break-even
> timeline, and be financed by infrastructure PE funds, for example. As a
> result, churn has a much lower financial impact on the operator.
>
> The main reason why this wouldn't work today is that EPON, as we know, is
> synchronous, and requires the OLT to orchestrate the amount of time each
> ONU can transmit, and when. Having wireless hops and media conversions will
> introduce latencies which can break down the communications (e.g. one ONU
> may transmit, get delayed on the radio link, and end up overlapping another
> ONU that transmitted on the next slot). Thus, either the "magic" box needs
> to account for this, or an new hybrid EPON-wireless protocol developed.
>
> My main point here: the industry is moving away from the unconnected. All
> the claims I heard and saw at MWC about "connecting the unconnected" had
> zero resonance with the financial drivers that the unconnected really
> operate under, on top of IT literacy, digital skills, devices, power...
>
> Best,
>
> Mike
> On Mar 14, 2023 at 05:27 +0100, rjmcmahon via Starlink <
> starlink@lists.bufferbloat.net>, wrote:
>
> To change the topic - curious to thoughts on FiWi.
>
> Imagine a world with no copper cable called FiWi (Fiber,VCSEL/CMOS
> Radios, Antennas) and which is point to point inside a building
> connected to virtualized APs fiber hops away. Each remote radio head
> (RRH) would consume 5W or less and only when active. No need for things
> like zigbee, or meshes, or threads as each radio has a fiber connection
> via Corning's actifi or equivalent. Eliminate the AP/Client power
> imbalance. Plastics also can house smoke or other sensors.
>
> Some reminders from Paul Baran in 1994 (and from David Reed)
>
> o) Shorter range rf transceivers connected to fiber could produce a
> significant improvement - - tremendous improvement, really.
> o) a mixture of terrestrial links plus shorter range radio links has the
> effect of increasing by orders and orders of magnitude the amount of
> frequency spectrum that can be made available.
> o) By authorizing high power to support a few users to reach slightly
> longer distances we deprive ourselves of the opportunity to serve the
> many.
> o) Communications systems can be built with 10dB ratio
> o) Digital transmission when properly done allows a small signal to
> noise ratio to be used successfully to retrieve an error free signal.
> o) And, never forget, any transmission capacity not used is wasted
> forever, like water over the dam. Not using such techniques represent
> lost opportunity.
>
> And on waveguides:
>
> o) "Fiber transmission loss is ~0.5dB/km for single mode fiber,
> independent of modulation"
> o) “Copper cables and PCB traces are very frequency dependent. At
> 100Gb/s, the loss is in dB/inch."
> o) "Free space: the power density of the radio waves decreases with the
> square of distance from the transmitting antenna due to spreading of the
> electromagnetic energy in space according to the inverse square law"
>
> The sunk costs & long-lived parts of FiWi are the fiber and the CPE
> plastics & antennas, as CMOS radios+ & fiber/laser, e.g. VCSEL could be
> pluggable, allowing for field upgrades. Just like swapping out SFP in a
> data center.
>
> This approach basically drives out WiFi latency by eliminating shared
> queues and increases capacity by orders of magnitude by leveraging 10dB
> in the spatial dimension, all of which is achieved by a physical design.
> Just place enough RRHs as needed (similar to a pop up sprinkler in an
> irrigation system.)
>
> Start and build this for an MDU and the value of the building improves.
> Sadly, there seems no way to capture that value other than over long
> term use. It doesn't matter whether the leader of the HOA tries to
> capture the value or if a last mile provider tries. The value remains
> sunk or hidden with nothing on the asset side of the balance sheet.
> We've got a CAPEX spend that has to be made up via "OPEX returns" over
> years.
>
> But the asset is there.
>
> How do we do this?
>
> Bob
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>


-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com
<https://www.understandinglatency.com/Dave>/
Dave Täht CEO, TekLibre, LLC

[-- Attachment #1.2: Type: text/html, Size: 9641 bytes --]

[-- Attachment #2: Hybrid EPON-Wireless network.png --]
[-- Type: image/png, Size: 149871 bytes --]