---

Ever noticed how phones tend to work well together? On the other hand, did you bump into non-voice-call-or-SMS-features that didn’t quite work? MMS anyone? Or maybe video calls in their early days? Standards are hard to follow.

Mobile handsets, like most communication devices today, follow standards. They do so in hopes of interoperability – having one product communicate well with another (we’re doing that here frequently enough). You can think of the printing business as an example: one company manufactures paper and one builds printers, and yet almost any printer paper will fit into any printer. That’s because there’s a standard for paper (actually you have more than one – take A4 and US Letter for example – competing on relatively similar page sizes).

So why do products fail to follow standards?

Well, if following standards is so great, why not follow them when designing a product?  Ever hear of the “two Jews, three opinions” case?  It’s the same with standards. As more than a single person is involved, there will be a lot of opinions about how a standard should be defined and if it should be followed.

To this, you can add the balance of power in the Standardization Organizations (SDOs) involved. This balance places barriers on successful implementation of standards.

Time and Stability

It takes time to write a standard.

It starts with an idea from an individual or a company that becomes a contribution to an SDO.

Other individuals from other organizations in the SDO will have comments about the contribution. These will consist of plain rejection, mild enthusiasm, suggestions for improvements, etc.

After this stage, the contribution will usually be modified to meet the comments made and satisfy the other members of the SDO.

At this point in time, companies will start implementing the half-baked standard to get a head start on the competition with it. The initial contributor might even have a prototype up and running. This will make his competitors try and divert the contribution as much as possible to work differently and reduce his advantage over them – I’ve seen this happen too many times already.

Standard approval may take several rounds, and SDOs usually meet 3-4 times a year. So each round takes several months.

And then there’s the implementation part on behalf of companies, and testing against each other, which takes months as well, and needs to fit in the release cycle of their own products.

This can easily take 3-4 years from idea to a stable first production grade implementation.

Complexity

Standards are complex. And even this has its own set of reasons:

• Companies wishing to protect their advantage will make the standard complex as a barrier of entry from competitors.
• Companies who comment on standards will make them more complex, as they start adding more user cases and scenarios into it.

The more complex the standard, the more inconsistencies developers will find when they try to implement it and interoperate with others.

One of the best examples I can give here is the standardization process of MONA. MONA was created from a fight between companies, each trying to push its own 3G-324M call setup acceleration mechanism. The culmination of this fight happened in Geneva, at an ITU meeting, when it was obvious that the companies were not going to agree on a single solution, pacing the industry at a stalemate on the issue. The end result was a decision to combine all relevant solutions (3 in number) and create MONA – a new standard, more complex than any of the 3 that were placed.

I am sure this situation repeats itself with the other standards as well. Where there’s a business incentive, there’s a good fight.

Patents

Specific aspects within standards will usually be protected by patents. MONA is protected by a bunch of them, along with H.264 and many other standards for that matter.

When operators or handset vendors decide whether or not they want to implement and deploy a specific feature, they need to start dealing with patent issues as well, which mar the acceptance and reach of many solutions out there.

So Why Use Standards?

Without standards, we wouldn’t be able to make calls at all. With Skype, the proprietary implementation is actually the exception that proves the rule: in order for their SkypeIn and SkypeOut services to work at all, Skype had to negotiate between their proprietary protocol to the standard ones of telephony all over the world.

Just look at how well GSM works the world over – this is due to the rigorous standardization work done (and later on interoperability and certification that got mandated).

Standards take time to mature. And when they do – things start to work.