x
Optical/IP

Engineer Slams ITU's New FEC Standard

When is a standard not a standard? When it encompasses every possible variation of the thing being standardized.

That appears to be what's happened with International Telecommunication Union (ITU) standard G.975, which covers Forward Error Correction (FEC), a way to boost signal integrity using algorithms that detect and correct for errors.

An upgrade to the current standard to add so-called "strong" FEC codes -- ones that incur more coding overhead but give better performance -- was approved at the end of February, and is now in the pre-publication stage, which means it can be viewed on the ITU's Website.

Yesterday, an announcement by Phyworks Ltd., claiming that its proprietary FEC algorithm had been standardized by the ITU provoked squawks from its competitors (see Phyworks FEC Becomes ITU Standard). True, Phyworks' code has been incorporated into a document that's part of the G.975 standard. But so, it appears, has everyone else's.

"This is ridiculous," fumed one engineer who declined to be named (we'll called him Engineer X). "Everyone who cares is well aware that the new and informative annex to G.975 lists a whole lot of strong FEC codes supplied by major (and minor) players in the industry."

"We're not claiming to be the only ones," admits Allard van der Horst, Phyworks product manager and the company's ITU contact. "But it's not in our interest to point out that everyone else is in there as well."

The new annex to G.975 lists eight strong FEC codes. The contributors of those codes are not named in the document, but are known to be Alcatel SA (NYSE: ALA; Paris: CGEP:PA), Applied Micro Circuits Corp. (AMCC) (Nasdaq: AMCC), Intel Corp. (Nasdaq: INTC), Lucent Technologies Inc. (NYSE: LU) (two codes), NEC Corp. (Nasdaq: NIPNY; Tokyo: 6701) (two codes), and Phyworks.

How did this come about? Until recently it was generally thought that standardization would never be possible on strong FEC. Proposals had been made but had never succeeded, because too much deployment of network gear with proprietary strong FEC codes had already taken place. FEC was also an immature technology, so whenever a proposal was made, someone quickly came up with a better one.

But last year, rumors spread that a particular company from Japan (NEC) wanted to get its strong FEC into the G.975 standard. Most other companies that had their own strong FEC codes were surprised and confused by this but felt compelled to join in.

"On one hand, we all agreed that this was basically a joke and we did not really need to bother," says Engineer X. "However, if we would not play the game, we feared that we might be left out standing in the rain."

The result was a flood of late submissions to the ITU, all wanting to get into the new strong FEC annex. But the ITU operates by consensus, and since there was no way of telling which code was best, no such consensus could be reached. In the end, a very diplomatic solution was found -- all of the codes were incorporated, with the effect of virtually cancelling each other out.

"Now the situation is nearly as before," says X. "All we have is an informative annex that reflects the current technical status in the industry. Nothing is truely standardized, and any swing towards a particular type of strong FEC in the market is not in sight -- and will likely never take place."

Phyworks does see merit in the publication of the ITU document, however. "We were happy to publish the algorithm," says Horst. "It reassures customers. Now they know exactly what's in there. It also makes it possible for third parties to implement solutions using our algorithm."

Putting its algorithm in the public domain seems like a strange thing to do in one sense, but Horst says his company hasn't given up any trade secrets in the process. "[The annex] describes exactly how the encoding takes place. But quite a bit of the smarts is in the decoding."

Phyworks is probably the only company with a product that implements "soft decoding" at 10 Gbit/s, he claims. Soft decoding makes use of confidence information by detecting different threshold levels in the received optical signal. For example, it might have four possibilities: 100 percent sure it's a zero; nearly sure it's a zero; almost sure it's a one; and 100 percent sure it's a one. Taking this information into account when decoding the data gives better results. Phyworks plans to announce an IP core based on its strong FEC with soft decoding later this month.

— Pauline Rigby, Senior Editor, Light Reading

sevenbrooks 12/5/2012 | 2:06:24 AM
re: Engineer Slams ITU's New FEC Standard
According to this person at Phyworks, the idea is to put the algorithm in the public domain for:

1 - Assurance of potential supply and
2 - Ability to get 3rd party developers/licensees

However, these could both be accomplished through the patent process (assuming the standard was met) or white paper publishing (assuming that the technology was not patentable).

Generally a standard is created to foster interoperability, but it looks that this objective was not met with this standard.

seven
captain kennedy 12/5/2012 | 2:06:22 AM
re: Engineer Slams ITU's New FEC Standard Wasn't the original in-band SONET FEC the reason "mid-span meet" between SONET terminals was never really deployed?
sevenbrooks 12/5/2012 | 2:06:20 AM
re: Engineer Slams ITU's New FEC Standard
Nope, the problem with SONET then and now is the management channels and interoperability of those (how many flavors of the DCC dance on the head of a pin).

Physical interoperability has been easy for a long time.

seven
captain kennedy 12/5/2012 | 2:06:20 AM
re: Engineer Slams ITU's New FEC Standard Quote: Phyworks is probably the only company with a product that implements "soft decoding" at 10 Gbit/s, he claims. Soft decoding makes use of confidence information by detecting different threshold levels in the received optical signal. For example, it might have four possibilities: 100 percent sure it's a zero; nearly sure it's a zero; almost sure it's a one; and 100 percent sure it's a one.

Gee, is Phyworks 100% sure, nearly sure or almost sure they are the only soft decision product at 10Gb/s. I would think they should know their market with certainty. Unless some others vendors listed in this article shelved products they had more than 1 year ago, I am 100% sure Phyworks is incorrect in this statment.


captain kennedy 12/5/2012 | 2:06:18 AM
re: Engineer Slams ITU's New FEC Standard Sorry, but SONET FEC was not standardized at OC-192 until sometime in 1999. Until then physical interoperability could only be accomplished without using SONET FEC. If you want to argue, go ahead, but I was at an ITU standards meeting held in Dallas to resolve this issue. I am simply pointing out the FEC and standards have some history already.
dljvjbsl 12/5/2012 | 2:05:42 AM
re: Engineer Slams ITU's New FEC Standard
Cryptographic algorithms, similarly, undergo peer evaluation after they are published. Is such an exercise being pursued for FEC?


I do not know if it is being done in this case but ITU study groups can have associated interest groups. They are designed to do exactly what you say. Academics and others can come to together in therse interest groups to research and comment on the proposals in the study group. The rapporteur will follow the developments in this group.
PO 12/5/2012 | 2:05:42 AM
re: Engineer Slams ITU's New FEC Standard FEC algorithms are developed by mathematicians, while ITU committees are rarely in a position to properly evaluate such work directly.

Now that the algorithms have been published, what academic review is underway to evaluate the strengths and weaknesses of each algorithm?

I (and I don't think I'm alone here) have met developers in the past who will push ideas forward because they can, not because they're better. In some cases there are fatal flaws. I'm not suggesting that's the case here, but surely there is a need to study and publish the advantages of each algorithm.

Cryptographic algorithms, similarly, undergo peer evaluation after they are published. Is such an exercise being pursued for FEC?
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE