GPON Gets It Together

10:00 AM -- Despite all the tests, GPON interoperability has never been fully tested. One hangup is the ONT management control interface (OMCI), the communications protocol between the central office and customer premises devices.

OMCI was one of the last pieces of the GPON standard to fall into place, in 2004. (See PON & FTTx Update, from 2005.)

And no one's used it since.

"It's arcane, and service providers don't like arcane," says Steven Glapa, vice president of product managment for Zhone Technologies Inc. (Nasdaq: ZHNE). "What many vendors in the space have done is paper it over with proprietary management."

Here's what it does. The Optical Network Unit (ONU) (also called ONT, for optical network terminal) is a blank slate, with no built-in configuration. So, unlike a DSL modem, the ONU needs to take instructions from the central office every time there's a change -- a reboot, for instance. OMCI is the protocol for carrying those instructions.

But OMCI requires too much work for the service provider; Glapa likens it to having to write your own Windows driver for every printer you use.

There's a bigger reason for OMCI to be ignored, though. The protocol would be a crucial step in true interoperability, letting service providers connect any vendor's ONUs to any Optical Line Terminal (OLT). That's great if you want to buy cheap ONUs. It's less great if you're, say, Alcatel-Lucent (NYSE: ALU), Motorola Inc. (NYSE: MOT), or Tellabs Inc. (Nasdaq: TLAB; Frankfurt: BTLA), and you want carriers to be buying your ONUs. (That's true of any big company; I'm just picking on the North American ones.)

So, while the Full Service Access Network (FSAN) organization has tested GPON interoperability before, it's never been real interoperability. This week, they'll get closer, because OMCI will be part of the FSAN interoperability trial that's going on in Sophia Antipolis, France. (Amazingly, Light Reading did not grant a travel budget for editors to attend.)

"This is the first one where all the layers of management, all the way to OMCI, are going to be dealt with," says Geoff Burke, director of marketing at Calix Inc. (NYSE: CALX)

Zhone, for one, wants to show it's on the OMCI train. It's recently launched its MXK system, which includes a feature called Smart OMCI, trying to make the protocol easier for carriers to use. (See Zhone Releases Son of MALC.) As for the rest, I'd guess their OMCI implementations will play together well, since the test is not a pop quiz; they wouldn't test OMCI if vendors didn't say they were ready, right? How quickly anyone feels like implementing it is another matter.

— Craig Matsumoto, West Coast Editor, Light Reading

Page 1 / 2   >   >>
bollocks187 12/5/2012 | 4:02:03 PM
re: GPON Gets It Together


A failed gpon interop strategy. Net the OLT SHOULD not be invovolved in the management of the ONT. Elimnation of OMCI is the only cure.

Technocrats at carriers are too 'simple' minded resulting in a complex solution. Like govt agencies they think they are solving a problem but in fact they are creating bigger ones.

Is this not proof enough for all you folks out there !

C'mon admitt it and stop trying to justify a bad thing.

paolo.franzoi 12/5/2012 | 4:02:03 PM
re: GPON Gets It Together

The actual state of GPON interoperability is as you say - not actual.  OMCI tends to take a lot of the blame.  That is both fair and highly unfair.

To give the non-infromed reader a better view, it is better stated that the ONT is managed by the OLT in an ITU (FSAN) PON network.  The OMCI is the management channel used for provisioning and is highly standardized.

The problem is a bit more subtle.  An ONT is highly variable in its structure and can support many kinds of interfaces and managed objects.  The issue is how to describe these objects to an OLT in such a way that the OLT knows how to manage the ONT.  So, when a new type of ONT is hooked up somehow the managed objects must then be instantiated in an OLT.

Now, this sounds simple but it (today) generally means a code change on the OLT for every new type of ONT supported.  This has to flow upstream to the management system of the PON network.

DSL, for example, works differently.  G.hs provides a capability exchange across a relatively small set of the DSL line capabilities.  Beyond that, there is basically no management of the DSL Modem by the DSLAM.  Even then, there are significant interoperability issues (try to test say VDSL2 rate/reach across the full suite with a random set of Modems/DSLAMs).

Even with all of this solved there are some sticky challenges in front of the vendor/operator community.  One of the things "managed" by the OLT is the software loaded on the ONT.  Think about release numbering between vendors and how to recognize if random_device_01 has the latest approved software in it.  Then, think about how random_ONT_07 vendor gives the code to the OLT vendor to store somewhere.

Now, there has been lots of blather about eliminating the OMCI.  But FSAN is run by the carriers not by the vendor community, and the carriers have yet to even want to talk about it.  A better solution (are you listening FSAN?) would be to create a number of standard ONT models to be supported by OLTs.  That would simplify some of the challenges.  Proprietary ONT models could always be supported but getting standards in place would make ODM models simpler and interoperability one step closer.



paolo.franzoi 12/5/2012 | 4:02:02 PM
re: GPON Gets It Together



Depends on your viewpoint.  The alternative is to support hundreds of different EMS and management environments from random CPE vendors in order to diagnose problems.

Let me use this as an example.  A point to point ethernet FTTH environment is constructed and then every single customer buys a different home gateway router.  Every single customer reports different problems.  Needless to say this is an extreme example, but that is one of a whole set of possible problems created from the other extreme.

Cable, Cellular, and even DSL networks specify which devices can be placed on their networks before customers can be placed on them.  So in any of these cases, there is not infinite interoperability. 

Just remember separate management = separate cost and extra opex.  Since now you have to have specialists that can deal with issues on each different type of device you put on the network.

Does the OMCI solve that?  No, but neither does it create it.  It is irrelevant to the discussion at that level.



bollocks187 12/5/2012 | 4:02:01 PM
re: GPON Gets It Together How about we juts standardize with a TR69 'similar' model and use an ACS to manange the ONTs rather than depend on the OLT and its propriatory EMS.

It is the OLT that is holding things up on interoperability as NO OLT vendor wants open GPON - that is a "fact not fiction"
paolo.franzoi 12/5/2012 | 4:02:01 PM
re: GPON Gets It Together



If all the pricing pressure is on ONTs (and it is), there is plenty of incentive to get rid of the ONT business. 

TR-69 works for some things and does not work for others.  It is also poorly deployed and in fact most DSL modem networks are not managed by the carriers.  If you have ever been through DSL troubleshooting with a carrier, they focus on the "lights" and don't do a SELT or a DELT or any kind of TR-69 management interface.

Now before you call them stupid (which you have already done), much DSL was rolled out before TR-69 existed.  Nobody is replacing working DSL modems to get managed ones since they have been dealing with unmanaged ones for years.

Now, go over to OMCI.  Yes, you could replace it with a TR-69 model.  But until the ONTs standardize (and Duh - I agree with your comments but hey I had to throw it out there), there is no practical single model to deal with.  So, all that you do is move the problem from one place to another.




Duh! 12/5/2012 | 4:02:01 PM
re: GPON Gets It Together

Seven got it right, as he usually does in GPON matters.

A couple of other points, though.

At some point in the distant past, a decision was made by FSAN to roll their own data modelling and local management protocol rather than using SNMP (as was done, successfully, in ATM and DOCSIS).   The original scheme was based on a management protocol whose principal objective was to fit into 48 bytes (a single ATM cell).  The data model was underspecified and the protocol and model not sufficently descriptive, flexible and unambiguous.  So many years of work and learning in modelling managed objects was effectively lost.  To say nothing of all the MIBs that were relevant and compilable but not usable for BPON or GPON.

The system model, data model/MIB and protocol are all entangled in a single document, G.984.4, which is unwieldy not only in size but also in structure.  Despite the best effort of the editors, many ambiguities survive pre-publication review on each revision, and the document is a maintenance headache.  A lot of the interop issues seem to revolve around the ambiguities and difficulty in making changes after revision of the standard.

At this point, none of the stakeholders have any incentive to change.  It's easier to keep patching what they have.  Ultimately, with enough patches, they'll get to something like interoperability.

Seven is right that it would be easier if a small number of standardized ONT models could be agreed upon.  Good luck with that.   ONT model is related back to the operator's business model and a lot of other business decisions and vendor relationships, so there is no agreement possible in the operator community on that.  If I recall, some attempt was made to downselect models, and really didn't get anywhere.

So, as usual, not a great situation but not bad enough to change any time soon, either.


bollocks187 12/5/2012 | 4:01:56 PM
re: GPON Gets It Together

Yes on the DSL and TR69 issues - but as you may know "operationally" managing services is one of the last items to be addressed by a carrier since the back end office team is usually thornw the technolog and then told to deal with it by the technocrats are generally focused on the 'technology' aspects and not the operational ramifications.

I agree the problem is moved - but it should be  one of the first problems that is addressed.  Once again it is the "technocrats" ask any one workin inthe oeprational side of carrier group and they will resonate on the difficulties they face in building a sustainable cost effective network.

Again back to one of the basic arguments in the original charter for FSAN was and contiues to be "multi-vendor G-PON systems" Yet the method and approach adopted by FSAN is counter productive to that end as it requires OLT involvement.

OLT vendors do not and cannot afford to have true plug and play ONTs. The more the standards bodies try and embrace this approach the more time is wasted and a lot of political technical BS is put out in the market place.

This is not to say it will not be achieved but it has and will take time - for some companies it will take too long to achieve as some GPON ONT supplies have found out to there dismay.

My proposal is simple strip down the OMCI functionality to a minimum and manage the ONTs via other means if its TR69 modified then okay - if its a vendor showing an way to manage the ONT then the carrier can choice if he likes that or not. The net  is the carrier can from an "open market competition that is based on "plug and play" rather than a closed market that is locked to the OLT vendors roadmap.



paolo.franzoi 12/5/2012 | 4:01:55 PM
re: GPON Gets It Together


So, let me get this right the OLT vendors (who are getting 50% margin+ on OLTs) and fighting with a death grip to hold onto a business that is break even at best (ONTs)?

I am not arguing that OMCI makes it simple.  It just does not make it impossible.  The problem is not the OLT vendors.  It is Verizon and their requirements.  Nobody, outside of Verizon's OLT vendors, builds ONT to meet their requirements.  The GPON ONT ODMs build other things but do not build those.

Why is that?  It is back to the problem of a "model".  The highest volume GPON ONT in the world is the Verizon SFU model.  It is relatively complex, and the ONT vendors don't want to do all the work that Verizon requires.  So, they avoid the model.

If you were a bit more clued in to the problem, you would find that folks like ALU and Mot refuse to sell their ONTs to Verizon hooked to somebody elses OLT.  That is because they lose money when they do so.

By the way, the same situation is true in EPON except for NTT (due to having to be in the NTT sphere to supply them).  That again has nothing to do with OMCI and we can talk about DBA algorithms here if you wish.



sglapa 12/5/2012 | 4:01:54 PM
re: GPON Gets It Together

seven --

Good details to add to the picture, generally.  Just a couple of comments from our perspective:  first, the requirement to upgrade OLT software in order to accommodate new ONT models and/or configurations is one of the things Zhone has eliminated via our Smart OMCI implementation (that was a subtlety I wrapped into the general package of "making things easier for operators" in my conversation with Craig), so that's no longer a problem, at least for our customers.

Second, the idea of a smaller number of standard ONT models is a nice one, but our experience to date with operators across many segments is that the details of functional requirements vary so much between markets and applications -- as well as between individual service provider approaches to QoS implementation, service mix, home network interfaces, etc. -- that we see entropy rising in this category over time, not falling, for valid reasons.  Hence the importance of creating an easier-to-use 'abstraction layer' in the element management system.


paolo.franzoi 12/5/2012 | 4:01:52 PM
re: GPON Gets It Together



Happy to hear about your smart OMCI.  So, you guys can recognize random ONTs and download them.  Will be interested in looking at that.  Where can I ship my code to?

As to the 2nd part, I call "BS".  There are about 4 - 5 models that could be made to cover about 80% of the cases.  I will add one for Verizon as they are 80% of the market:

Verizon SFU - 2 POTS, 1 Video, 1 Ethernet, 1 MOCA

Data Only - 1 10/100/1000 Port

Data + Voice - 1 Ethernet, 2 POTS

IPTV - 4 Ethernet, 2 POTS

RF Video - 1 Ethernet, 2 POTS, 1 RF with RF return path

MDU - 16 VDSL2, 16 POTS (I could argue different numbers but whatever).

If those were standardized at FSAN, that would cover the vast majority of the cases. It is not to say that you non-standard models could not be built or supported.  But you (and Calix and Occam) need to think about the proliferation of small quantity ONTs to Tier 3 carriers.  If you guys would agree on a set of models, then everybody would make more money.

QoS is not actually covered by the OMCI, but one could make standard models of the mapping for TCONT management.

One other thing that should be point blank stated here for the record - as far as I can tell Zhone is not a member of FSAN.  Am I correct?



Page 1 / 2   >   >>
Sign In