[160185] in North American Network Operators' Group
VS: Muni fiber: L1 or L2?
daemon@ATHENA.MIT.EDU (Henri Hannula)
Fri Feb 1 18:06:20 2013
From: Henri Hannula <henri.hannula@msoy.fi>
To: 'Owen DeLong' <owen@delong.com>
Date: Fri, 1 Feb 2013 22:59:46 +0000
In-Reply-To: <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
You propably calculated the second one (5 - 2.34 -16)-15 + 0.26 since you g=
ot -28.08
(5 - 16 - 2.6) - 15 =3D -28.6
(5 - 2.34 - 16) - 15 - 0.26 =3D -28.6
-Hena
-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Owen DeLong [mailto:owen@delong.com]=20
L=E4hetetty: 2. helmikuuta 2013 0:00
Vastaanottaja: Jason Baugher
Kopio: NANOG
Aihe: Re: Muni fiber: L1 or L2?
On Feb 1, 2013, at 1:43 PM, Jason Baugher <jason@thebaughers.com> wrote:
> It's still a 23dB loss for each customer from the CO to the ONT.=20
>=20
> I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26=
dB loss per km. My 1x32 splitter is going to add about 16dB more loss. Assu=
ming we ignore connector losses, and also assume that the customer is 10km =
away:
>=20
Nope. The power going into each fiber out of the splitter is 1/16th that of=
what went into the splitter.
Yes, your total in-line loss is still 10km, but you are forgetting about th=
e fact that you lost 15/16th of the power effectively going to the fiber wh=
en you went through the splitter (in addition to the splitter loss itself).
So: CO Based splitter:
Each customer gets (IN - 16dB - (10km x .26db))/32
Splitter at 9km:
Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db)
If we use 5dBm as our input, this works out:
CO: (5db - 16db - (10km x .26db) / 32
/32 is effectively -15 db (-3db =3D =BD power, 32 =3D 2^5)
Substituting: (5db - 16db - 2.6db) -15db =3D -28.6db to each customer.
Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db)
Substituting: (5db - 2.34db -16db)-15db-.26db =3D -28.08db to each customer
So there is a difference, but it seems rather negligible now that I've run =
the numbers.
However, it's entirely possible that I got this wrong somewhere, so I invit=
e those more expert than I to review the calculations and tell me what I go=
t wrong.
Owen
> CO-based splitter:
> +5dBm - 16dB - (10km x .26dB) =3D -13.6
>=20
> Splitter at 9km:
> +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) =3D -13.6
>=20
>=20
> If someone can explain why this math would be wrong, I'd love to hear it =
and I'd be happy to run it past our vendor to see if they agree.
>=20
>=20
> On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong <owen@delong.com> wrote:
> Actually, this is an issue. I should have seen it.
>=20
>=20
> You have 3 loss components. Power out =3D (Power in - loss to splitter -=
=20
> splitter loss) / nOut - loss-to-customer
>=20
> So, if the loss to the splitter is 3db and you have 20db (effective=20
> 320db on a 16x split) loss on each customer link, that's a radically=20
> worse proposition than 20db loss to the splitter and 3db loss to each cus=
tomer (which is effectively 48db loss on a 16x split).
>=20
> It's still do-able, but you either need amplifier(s) or very short distan=
ces between the customer and the MMR.
>=20
> Given this consideration, I think the situation can still be addressed.
>=20
> Put the splitters in the B-Box and allow for the possibility that each=20
> subscriber can be XC to either a splitter or an upstream dedicated=20
> fiber. The provider side of each splitter would be connected to an upstre=
am fiber to the MMR.
>=20
> So, each B-Box contains however many splitters are required and each=20
> splitter is connected upstream to a single provider, but you can still ha=
ve multiple competitive providers in the MMR.
>=20
> This setup could support both PON and Ethernet as well as other future te=
chnologies.
>=20
> Owen
>=20
> On Feb 1, 2013, at 1:04 PM, Jason Baugher <jason@thebaughers.com> wrote:
>=20
>> I should clarify: Distance x loss/km + splitter loss. =3D link loss.
>>=20
>>=20
>> On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher <jason@thebaughers.com> wr=
ote:
>> I disagree. Loss is loss, regardless of where the splitter is placed in =
the equation. Distance x loss + splitter insertion loss =3D total loss for =
purposes of link budget calculation.
>>=20
>> The reason to push splitters towards the customer end is financial, not =
technical.
>>=20
>>=20
>> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms <khelms@zcorum.com> wrote:
>> Owen,
>>=20
>> You're basing your math off of some incorrect assumptions about PON. =20
>> I'm actually sympathetic to your goal, but it simply can't work the=20
>> way you're describing it in a PON network. Also, please don't base=20
>> logic for open access on meet me rooms, this works in colo spaces and=20
>> carrier hotels but doesn't in broadband deployments because of=20
>> economics. If you want to champion this worthy goal you've got to=20
>> accept that economics is a huge reason why this hasn't happened in=20
>> the US and is disappearing where it has happened globally.
>>=20
>>=20
>> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter ->=20
>> > fiber-drops to each house -> ONT.
>> >
>>=20
>> So far you're correct.
>>=20
>>=20
>> >
>> > All I'm proposing is making n really short and making "fiber-drops=20
>> > to each house" really long.
>> > I'm not proposing changing the fundamental architecture. Yes, I=20
>> > recognize this changes the economics and may well make PON less=20
>> > attractive than other alternatives. I don't care. That's not a=20
>> > primary concern. The question is "can PON be made to work in this envi=
ronment?" It appears to me that it can.
>> >
>>=20
>>=20
>> Here is where you're problems start. The issue is that the signal=20
>> *prior to being split* can go 20km if you're splitting it 32 ways (or=20
>> less) or 10km if you're doing a 64 way split. AFTER the splitter you=20
>> have a MAX radius of about 1 mile from the splitter.
>>=20
>> Here is a good document that describes the problem in some detail:
>>=20
>> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf
>>=20
>>=20
>> Also, here is a proposed spec that would allow for longer runs post=20
>> splitter with some background on why it can't work in today's GPON=20
>> deployments.
>>=20
>> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_
>> review/2008/3_PON.pdf
>>=20
>> --
>> Scott Helms
>> Vice President of Technology
>> ZCorum
>> (678) 507-5000
>> --------------------------------
>> http://twitter.com/kscotthelms
>> --------------------------------
>>=20
>>=20
>=20
>=20
