OK... Like Einstein, math is not my strong suit. Unfortunately, I don't have his prowess with physics, either.
Owen On Feb 1, 2013, at 14:59 , Henri Hannula <henri.hann...@msoy.fi> wrote: > You propably calculated the second one (5 - 2.34 -16)-15 + 0.26 since you got > -28.08 > > (5 - 16 - 2.6) - 15 = -28.6 > (5 - 2.34 - 16) - 15 - 0.26 = -28.6 > > > -Hena > > -----Alkuperäinen viesti----- > Lähettäjä: Owen DeLong [mailto:o...@delong.com] > Lähetetty: 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 <ja...@thebaughers.com> wrote: > >> It's still a 23dB loss for each customer from the CO to the ONT. >> >> I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26dB >> loss per km. My 1x32 splitter is going to add about 16dB more loss. Assuming >> we ignore connector losses, and also assume that the customer is 10km away: >> > > 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 the > fact that you lost 15/16th of the power effectively going to the fiber when > 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 = ½ power, 32 = 2^5) > Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. > > Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) > Substituting: (5db - 2.34db -16db)-15db-.26db = -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 invite > those more expert than I to review the calculations and tell me what I got > wrong. > > Owen > >> CO-based splitter: >> +5dBm - 16dB - (10km x .26dB) = -13.6 >> >> Splitter at 9km: >> +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) = -13.6 >> >> >> 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. >> >> >> On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong <o...@delong.com> wrote: >> Actually, this is an issue. I should have seen it. >> >> >> You have 3 loss components. Power out = (Power in - loss to splitter - >> splitter loss) / nOut - loss-to-customer >> >> So, if the loss to the splitter is 3db and you have 20db (effective >> 320db on a 16x split) loss on each customer link, that's a radically >> worse proposition than 20db loss to the splitter and 3db loss to each >> customer (which is effectively 48db loss on a 16x split). >> >> It's still do-able, but you either need amplifier(s) or very short distances >> between the customer and the MMR. >> >> Given this consideration, I think the situation can still be addressed. >> >> Put the splitters in the B-Box and allow for the possibility that each >> subscriber can be XC to either a splitter or an upstream dedicated >> fiber. The provider side of each splitter would be connected to an upstream >> fiber to the MMR. >> >> So, each B-Box contains however many splitters are required and each >> splitter is connected upstream to a single provider, but you can still have >> multiple competitive providers in the MMR. >> >> This setup could support both PON and Ethernet as well as other future >> technologies. >> >> Owen >> >> On Feb 1, 2013, at 1:04 PM, Jason Baugher <ja...@thebaughers.com> wrote: >> >>> I should clarify: Distance x loss/km + splitter loss. = link loss. >>> >>> >>> On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher <ja...@thebaughers.com> wrote: >>> I disagree. Loss is loss, regardless of where the splitter is placed in the >>> equation. Distance x loss + splitter insertion loss = total loss for >>> purposes of link budget calculation. >>> >>> The reason to push splitters towards the customer end is financial, not >>> technical. >>> >>> >>> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms <khe...@zcorum.com> wrote: >>> Owen, >>> >>> You're basing your math off of some incorrect assumptions about PON. >>> I'm actually sympathetic to your goal, but it simply can't work the >>> way you're describing it in a PON network. Also, please don't base >>> logic for open access on meet me rooms, this works in colo spaces and >>> carrier hotels but doesn't in broadband deployments because of >>> economics. If you want to champion this worthy goal you've got to >>> accept that economics is a huge reason why this hasn't happened in >>> the US and is disappearing where it has happened globally. >>> >>> >>>> Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >>>> fiber-drops to each house -> ONT. >>>> >>> >>> So far you're correct. >>> >>> >>>> >>>> All I'm proposing is making n really short and making "fiber-drops >>>> to each house" really long. >>>> I'm not proposing changing the fundamental architecture. Yes, I >>>> recognize this changes the economics and may well make PON less >>>> attractive than other alternatives. I don't care. That's not a >>>> primary concern. The question is "can PON be made to work in this >>>> environment?" It appears to me that it can. >>>> >>> >>> >>> Here is where you're problems start. The issue is that the signal >>> *prior to being split* can go 20km if you're splitting it 32 ways (or >>> less) or 10km if you're doing a 64 way split. AFTER the splitter you >>> have a MAX radius of about 1 mile from the splitter. >>> >>> Here is a good document that describes the problem in some detail: >>> >>> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >>> >>> >>> Also, here is a proposed spec that would allow for longer runs post >>> splitter with some background on why it can't work in today's GPON >>> deployments. >>> >>> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_ >>> review/2008/3_PON.pdf >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> >> >> > >
