Says G.975 isn't a standard – it's a collection of pre-existing proprietary algorithms

April 7, 2004

4 Min Read
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

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like