RE: [EFM] Moving forward on extended temperature range optics
Piers,
I want to thank you for your thoughtful answers. For fiber access to be
successful, optics specifications in access standards need to facilitate
cost reduction so the business cases are profitable. Cost reduction of
optics remains a very difficult problem especially with little volume, few
purchase orders, and reduced investment capital.
For the EFM optics group,
The need to drop optics cost is very important and I am providing some
thoughts to the exploder on methods to drop the cost of optics further. Its
not my intention to provide them as recommendations or positions.
Here are several items to loosen EFM optics specs:
1)Lower upstream rate option (asymmetric) for operators with long loops
(>10km) to extend using the same short range 10 km PMD set. Do we really
need symmetry if its limiting scalability of EPON to be viable for longer
loops found in parts of the world? Perhaps 100 Mbps is fine for upstream
shared across 16 users on a PON.
2)Shortening reach objectives to closer fit real optoelectronic technology
for deployment in the access network? Should we move to 8 km and 16 km
instead of 10 and 20 km. (I know we prefer powers of ten in the group, but
if it costs more money I can learn to live without the tradition). It seems
the EPON 20 km PMD at 1.2 Gbps upstream, w/ hardening is going to be very
very difficult to make economic in reality.
3)Wider wavelength range to allow laser drift. Do we really need to support
an overlay in EFM?
4)Optional temp specification if hardening is infeasible and indoor ONT is
forced upon a carrier as the only economic solution.
5) Reduce power budget. Reducing power budget is really difficult include in
this list, since the EFM budgets provided so far are barely adequate given
existing access fiber construction methods I am aware of in the field.
Perhaps knowledge about temperature hardening feasibility is now becoming
available and understood in the group. The indications are that economic
and technical feasibility of several PMD classes remain in question in EFM.
It may be better to adjust the optics specs either in this PAR or a future
activity.
Its an interesting question whether staying with the traditions of Ethernet
for EFM is the best approach to leverage existing Ethernet optics products
(close the gap on differences to spur EFM products) or whether retaining
certain Ethernet traditions are hindering EFM from reaching successfully
into the access market space where temp hardening, and reach are very
important success factors.
Thanks, Kent
Kent G. McCammon
Broadband Access
SBC Technology Resources, Inc
4698 Willow Road
Pleasanton, CA 94588
925-598-1246
kmccammon@xxxxxxxxxxx
> -----Original Message-----
> From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
> Sent: Tuesday, February 18, 2003 3:15 PM
> To: kmccammon@xxxxxxxxxxx
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] Moving forward on extended temperature range optics
>
>
> Hi Kent,
> Answers in line, with apologies for the delay in replying.
>
> > -----Original Message-----
> > From: Mccammon, Kent G. [mailto:kmccammon@xxxxxxxxxxx]
> > Sent: 31 January 2003 01:00
> > To: 'piers_dawe@xxxxxxxxxxx';
> Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
> > stds-802-3-efm@ieee.org
> > Cc: billq@xxxxxxxxxxxxx
> > Subject: RE: [EFM] Moving forward on extended temperature
> range optics
> >
> > Piers and other optics experts in EFM,
> > I am left with a concern that we did not have the extended
> temperature
> > range and economic feasibility in mind when we made previous PMD
> > decisions in EFM.
>
> We have made decisions about optical specifications as
> favourable as we know how, for economic feasibility including
> the extended temperature range. Our wavelength ranges are
> wide enough, and in general as wide as we are allowed, given
> the fibre specs and the decision to enable a video overlay.
> The specs are temperature-agnostic in that a compliant
> transmitter and receiver can be at any temperature the
> manufacturer allows, and they will still interwork, and each
> end does not have to know or consider the temperature of the
> other end in any way. We have some work to do to validate
> the PON power levels and penalties but that is an absolute
> question not a temperature-related one.
>
> The question that remains is: is the best we can do, really
> feasible enough? The committee will want to form an opinion
> about this over the coming months, just as in other
> generations of Ethernet. Ingredients which go into this
> decision include cost, price and temperature among others -
> all formally out of scope and not to be specified IN THE
> STANDARD. But people will (properly) vote for / against the
> standard because they think its implementations will / will
> not be economically viable.
>
> > Perhaps I am jumping to conclusions since not everyone in the
> > forum has
> > responded. So, my line of comments and questions are directed
> > toward more than Piers if others are so inclined.
> >
> > If the optics technology is just not ready to deal with
> > extended temps and
> > high reliability I would like to hear those arguments in this forum.
>
> It's getting very close, and the situation varies from PMD to
> PMD. The most temperature-sensitive item is the laser. In
> recent years the industry has got better at making lasers
> that can run hot enough, but making them transmit well, on
> dispersive fibre, over a very large temperature RANGE, is a
> challenge. The 1000 Mb/s PMDs face more challenge than the
> 100 Mb/s ones, which I think people see as technically feasible.
>
> For DFB lasers (for 1000 Mb/s - not needed at 100 Mb/s), one
> widely used manufacturing process deliberately delivers a
> range of DFBs in each batch, which are tested and sorted.
> Some are scrap, others will achieve different temperature
> ranges. A customer for the pick of the crop (most extended
> temperature fraction) benefits from the sale of the other
> fraction(s) of more "vin ordinaire" DFBs. So, unlike most
> mass production processes where all the parts can be made the
> same and commoditization drives costs and prices down, here
> some diversity in the market is good - a little like
> agriculture or oil refining. Attempts to outlaw non-premium
> temperature grades would be counter-productive and create a
> further cost obstacle to be surmounted. In today's financial
> conditions, we need an evolutionary path forward instead.
> This effect would not be significantly affected by tweaking
> any specification. It's just the way DFBs are - years ago
> the "cure" was Peltier coolers, but the temperature range has
> been stretched.
>
> > FTTCurb architectures that share a higher cost hardened optic
> > among 16+
> > subscribers then becomes more viable than FTTH since optics
> > cost is such a
> > large part of the overall cost. It may be FTTCurb market is
> > really where
> > most Ethernet PMD vendors want to go after for near term profits. I
> > understand there is resistance to making extended temperature
> > a normative
> > element in our document. Also, placing optics inside becomes
> > a study topic
> > although I am fairly confident that model does not work
> well in single
> > family living units areas I want to try to serve with FTTH.
> > I would like to
> > know what temperature range is supportable with little cost
> > increase?
>
> It's one of those "last straw" situations: every additional
> 10'C of range is tougher than the one before. For example,
> -10 to 85'C might be noticeably easier at the optics level.
> "Difficulty" might go as the square of the temperature range,
> so -40 to 85'C (125'C range) is about 3 times more
> "difficult" than 0-70'C. But cost would be a very non-linear
> function of "difficulty".
>
> > Did
> > the SFP MSA consider extended temperature range in scope? Is
> > that an area
> > where temperature is better suited to be hammered out?
>
> It seems that some recent MSAs have done a great deal of work
> on temperature and cooling, but what shows up in the MSA may
> be a very condensed output of a much larger study, and mostly
> I suspect they addressed the equipment room. An MSA would be
> a suitable place to define what is meant by the temperature
> of a transceiver (i.e. where do you measure it and how?).
>
> Some MSAs define maximum temperatures which are not to be
> exceeded to stop people getting burns from hot metal
> surfaces. Presumably someone handling metal parts in a hot
> sunny desert just has to protect himself.
>
> I don't have the specific answer about the SFP MSA.
>
> > I have heard many arguments about applying the vast volume of
> > enterprise
> > Ethernet ports to lower the cost for access with an Ethernet
> > based system.
> > The arguments for not doing extended temperature tells me
> > that those volumes
> > don't necessarily apply when extended temperatures are part of the
> > requirements. If it was easy, I don't think this would be
> > such a big issue.
>
> There is still the point of principle about the "normative"
> angle: the fact because someone wants to install optics in a
> certain environment does not mean that someone else, who
> wants to address a different environment, should be burdened
> by extra costs for the first person's sake, and that we are
> writing a global standard for a diverse market. But you're
> right: if it was easy, no-one would spend their time trying
> to add it to a standard, they'd just define it on the
> purchase order - so the point would not arise.
>
> > I was hoping that IEEE could produce EFM specs heavily
> > leveraging previous
> > specifications on B-PON, and finding ways to lower the cost
> > of PON PMD.
>
> I believe the vast volume of enterprise Ethernet ports is
> still the right starting point. No-one wants to develop new
> technology for a fledgling market, in present financial
> conditions. Re-using and stretching the current technology
> is the best bet, and trying to create independent "economies
> of scale" for such nascent volumes, seems misguided;
> something like Ethernet has economies of scale; something
> that isn't like existing optics, doesn't.
>
> In fact, under the surface it's the same semiconductor
> materials that are causing the same temperature issues
> whether it's enterprise or telecomms.
>
> > Frankly, if it delivers services I can sell at a low cost, I
> > don't care if
> > Ethernet, GFP, ATM is at Layer 2 on a PON. I believe this was the
> > methodology around taking Fiber channel specs and tweaking
> > specs for GigE to
> > lower the cost. In other words, does leverage of enterprise
> > Ethernet optics
> > volume really viable when extended temperature is a requirement?
>
> Definitely!
>
> Piers
>
> > Regards,
> > -Kent
> >
> > Kent G. McCammon
> > Broadband Access
> > SBC Technology Resources, Inc
> > 4698 Willow Road
> > Pleasanton, CA 94588
> > 925-598-1246
> > kmccammon@xxxxxxxxxxx
> >
> > > -----Original Message-----
> > > From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
> > > Sent: Tuesday, January 28, 2003 10:07 AM
> > > To: Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
> stds-802-3-efm@ieee.org
> > > Cc: billq@xxxxxxxxxxxxx
> > > Subject: RE: [EFM] Moving forward on extended temperature
> > range optics
> > >
> > > "The road to hell is paved with good intentions". I thought
> > > Bill and Howard had got the discussion onto a sensible
> > > footing but a process of feature creep seems to have set in
> > > immediately after.
> > >
> > > Let's repeat, for those who have not yet unsubscribed from
> > > this reflector: environmental conditions such as temperature,
> > > supply voltage and so on are considered out of the scope of
> > > the standard. So are customer-facing requirements (parts of
> > > a procurement spec) such as cost, reliability and labelling,
> > > and component temperature. 802 concentrates on
> > > interoperability requirements: observable behaviour at ports.
> > >
> > > That doesn't mean we should not discuss the other conditions,
> > > as far as they relate to technical and economic feasibility
> > > or broadness of market. We can "take on" the temperature
> > > issue in that sense, and seek optical parameters which are
> > > compatible with the access environments. But we won't make
> > > normative requirements out of them in our standard; we'll
> > > leave that to the buyers, who will.
> > >
> > > We have reconciled these two conditions with an overwhelming
> > > vote for an informative annex. Let us all honour that agreement.
> > >
> > > An informative annex wouldn't have a PICS.
> > >
> > > We have better things to do with our time than re-invent
> > > wheels. We don't need to write temperature test procedures!
> > >
> > > As Bill points out, the market will provide the driving force
> > > for temperature specs. Following that thought, I would say
> > > that any environmental spec that 802 wrote would be futile -
> > > money talks; some operators will install their
> > > optoelectronics in sheltered locations and temperate
> > > climates, and save capex, whatever the standard says, others
> > > wish to install their optoelectronics in non-weatherprotected
> > > locations in extreme climates, whatever the standard says, to
> > > save opex. And it is the operator's $ that will encourage
> > > "more effort ... at the extended range", not empty words.
> > >
> > > Some have claimed that "access is different" and therefore we
> > > need to specify things which have been out of scope for many
> > > generations of the Ethernet standard. We compare with the
> > > traditional IT market where the temperature range is much
> > > less, so meeting it is not such a problem. But in that
> > > market, there still IS a temperature requirement, set by the
> > > market and documented in datasheets and purchase specs. Now
> > > in the access market, the temperature ranges are wider and
> > > the market is much less homogeneous. Does this mean that our
> > > methodology must change? Of course not, only our assumptions
> > > and the optical parameters which address them should change.
> > >
> > > Several people now have expressed an interest in the
> > > underlying issues of technical and economic feasibility or
> > > broadness of market (Howard's task A: Ensure that ... the ...
> > > Optical ... parameters ... can be met ... across an "extended
> > > temperature range" of operation). But while some people are
> > > still asking for normative material which they will vote
> > > against so that they can hold the standard to ransom, and
> > > which would waste a great deal more of our time to no effect
> > > (see market forces), it's difficult to have a reasonable
> > > discussion on these underlying issues.
> > >
> > >
> > > Now some information about labelling. The problem here is
> > > one of very restricted space and overlapping jurisdictions.
> > > Labels don't contain much, but that's OK, these days one can
> > > find the datasheet on the web. Labels have to obey national
> > > laws (safety marks, "made in") and the MSAs also have
> > > something to say:
> > >
> > > Quoting from the SFP MSA,
> > >
> > > "A5. Labeling of SFP Transceivers
> > > Color coding requirements for optical SFP transceivers are
> > > specified in Figure 1B. Each SFP transceiver should be
> > > clearly labeled. The complete labeling need not be visible
> > > when the SFP transceiver is installed. Labeling should
> > > include appropriate manufacturing and part number
> > > identification, appropriate regulatory compliance labeling,
> > > and a clear specification of the external port
> > > characteristics. The external port characteristic label may
> > > include such information as optical wavelength, required
> > > fiber characteristics, operating data rate, interface
> > > standards supported, and link length supported.
> > >
> > > Fig. 1B, note 4
> > >
> > > Color code: An exposed colored feature of the transceiver (a
> > > feature or surface extending outside the cage assembly) shall
> > > be color coded as follows:
> > > * Black or beige for multi-mode
> > > * Blue for single mode"
> > >
> > > And 802.3 has sections like "It is recommended that each PHY
> > > (and supporting documentation) be labeled in a manner visible
> > > to the user, with at least the applicable safety warnings and
> > > the applicable port type designation. Labeling requirements
> > > for Class 1 lasers are given in the laser safety standards
> > > referenced in ...."
> > >
> > > But I don't think this defeats Bill's idea; is it not the
> > > case already that the datasheet will give a temperature range
> > > (who would buy if it didn't) and an implementation claimed to
> > > be compliant to the (normative)
> > > optical/timing/electrical/protocol PICS must meet them over
> > > the stated temperature and supply ranges given in the
> > > datasheet. So I had thought Bill's point 4 was already covered.
> > >
> > > Piers
> > >
> >
>