Re: [EFM] PON Optics Telephone Conference, December 5th
Hugh,
At 08:17 PM 12/5/2002 -0800, Hugh Barrass wrote:
>Sanjeev,
>
>Firstly, I would strongly recommend that you should not mention real (or even
>realistic looking) dollar numbers in this forum. It's the rule!
Thanks for reminder and your strong recommendation well taken.
>Secondly, rather than looking at an absolute value, why don't you keep it as a
>percentage?
>
>In that case the equation might be:
>
>If the SP can get n revenue from their EPON, the improved efficiency could
>could
>allow up to 1.012*n revenue. Unfortunately this is a little simplistic.
>
>It is more likely that only a small proportion of the installations will
>be working
>at maximum load. In which case the increase in revenue may be less than 0.36%.
Point is that if you have installed x mbps (I hope this is ok as it is not
%), provider sells
all of it (else why you install it to be idle) if subscriber uses it or not
it is not provider's problem
and if at a point if usage gets to max point then provider has to guarantee
it else may have to
pay back what it could not deliver (may be 0.36% may be more).
>Furthermore, it is also likely that the installations will only reach
>saturation as
>the technology nears the end of it's (useful) life. If we assume that we
>continue
>to increase the performance at ~ 10x every 4 years then we should expect
>10G-EPON
>in about 4 years. If our implementation is 1.2% less efficient then we
>must hope
>that the 10G-EPON arrives about 2 weeks earlier than otherwise.
As you are indicating the % may be misleading as wastage of 1% of 1Mbps is
not same as
wastage of 1% of 10Gbps.
>Must get our skates on and deliver that 10G version!
I thought 10Gbps is old news. :)
Thanks,
Sanjeev
>Hugh.
>
>Sanjeev Mahalawat wrote:
>
> > At 02:51 PM 12/5/2002 -0800, Ariel Maislos wrote:
> >
> > >The only questions remaining for the service providers to answer is can
> > >they make more money from the network with the extra 1.2% of bandwidth?
> >
> > SP should do the calculation. But it is tempting to see the money
> > difference, so just that.
> > This 1.2% translates to about 11.616 Mbps, around 7.5 1.54Mbps DSL
> connections.
> > Assuming $50 per DSL it is around $377/PON/month. Assume one 32-port OLT
> > serving
> > 1024 customers (assuming 1:32 ratio) it would be $12064/month.
> > Does this SP lost revenue breaks their neck, they would know?
> >
> > Thanks,
> > Sanjeev
> >
> > >Regards,
> > > Ariel
> > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of
> > > > Mccammon, Kent G.
> > > > Sent: Wednesday, December 04, 2002 17:45
> > > > To: 'Thomas.Murphy@infineon.com'; stds-802-3-efm@ieee.org;
> > > > Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> > > > Subject: RE: [EFM] PON Optics Telephone Conference, December 5th
> > > >
> > > >
> > > >
> > > > Tom,
> > > > Since I have a conflict with the call tomorrow and I am
> > > > interested in this decision, here are some questions.
> > > >
> > > > 1)Do any of the options for PON timing impact the delivery of
> > > > services such as toll quality voice, a T1, or multicast
> > > > video? We had this concern previously and the answer
> > > > previously was claimed to be only an efficiency hit for loose
> > > > timing. Are the modeling assumptions to compare efficiency
> > > > valid for TDM services or is that not a consideration in this
> > > > debate to date? 2)The negotiation of timing parameters rather
> > > > than a tight specification have any impact on future
> > > > interoperability testing? If we ever decide to test
> > > > interoperability of EPON OLT and ONT, can a lab testing
> > > > system be reasonably built to test compliance to a
> > > > specification for OLT/ONT timing for the various options
> > > > under debate?
> > > > 3)Do operating temperature swings have an impact on timing
> > > > options. Is their reason to add extra margin or extra
> > > > negotiation time of timing parameters due to temperature
> > > > variations? What about cold start in cold temperatures, that
> > > > was an issue for power levels, does it also impact the
> > > > electronics of the PMD?
> > > >
> > > > Comment: As an advocate of PON technologies I echo my earlier
> > > > comments about striving for common PON PMD to get the volume
> > > > started in today's economy. I am optimistic a compromise can
> > > > be found in January. Thanks, -Kent
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas.Murphy@xxxxxxxxxxxx [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> > > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > > > > To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; wdiab@cisco.com
> > > > > Subject: [EFM] PON Optics Telephone Conference, December 5th
> > > > >
> > > > >
> > > > > Hello Again,
> > > > >
> > > > > Attacted two possible approaches to this discussion forming
> > > > > two decision trees. Glen and I worked on these I I did not
> > > > > have a chance to co-ordinate with him and refine to one
> > > > > slide. The first slide is mine and I would like to start
> > > > > here as it allows us to generate values without having to
> > > > > make decisions. When the values are agreed upon, we can work
> > > > > towards the decision and perhaps this is simpler with the
> > > > > values we have.
> > > > >
> > > > > If this does not work, we can try the seconf slide, Glen's
> > > > > approach, which is a more top-down attack.
> > > > >
> > > > > Talk to you tomorrow
> > > > >
> > > > > Tom
> > > > >
> > > > > <<PON Timing Decision Tree.ppt>>
> > > > >
> > > > > Hello All,
> > > > >
> > > > > Items to Be Covered
> > > > >
> > > > > 1) Determine the exact meaning of the terms "Fixed Value"
> > > > > and 'Upper Bound" in terms
> > > > > of their use for PMD timing parameters.
> > > > >
> > > > > 2) Try assign placeholder values for all of the options
> > > > >
> > > > > 3) Are these values fixed or bounded for the different options.
> > > > >
> > > > > 4) Other items
> > > > >
> > > > > Regards
> > > > >
> > > > > Tom
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >