Six Ways to Kill Interop Alistair URIE

Interop problems - Many different issues covered by the same phrase At least 6 different issues: Ambiguity in standard Error in an implementation Mismatch in profiling Vendor adds non-standardised feature Vendor establishes market with “non-compliant”implementation Unexpected combination of different standards …and at least 6 different solutions And sometimes interop is not necessary nor required Competing standards Competing markets

Interop problem #1 – Ambiguity in standard Issue: Ambiguity in standard results in vendors making different implementations based on the same standards Detection: Problem surfaces during bi-lateral interop testing and experts trace problem to standard Action: Common understanding reached on how to improve text in standard Vendors update implementations and retest for interop ?# x y   Standard Vendor A Vendor B

Interop problem #2 – Error in an implementation Issue: Vendor made error in their implementation Detection: Problem surfaces during interop testing and/or certification and one vendor traces problem to their implementation Action: Concerned vendor updates their implementation and retest for interop  ?#   Standard Vendor A Vendor B

Interop problem #3 – Mismatch in profiling Issue: Vendors made different choices of options in standard Detection: Problem surfaces during interop testing and/or certification and vendors trace problem to in-compatible options Action: Agree common profile (often with large set of vendors and operators)   Standard Vendor A Vendor B

Interop problem #4 – Vendor adds non-standardised feature Issue: Particular vendor’s implementation includes feature that is not standardised and “compliance” to this additional feature essential to access market Detection: Problem surfaces in vendor laboratory or in interop event when a vendor that is compliant with the standard encounters interop issue Action: Other vendors often FORCED to emulate non-standardised feature Better solution is to standardise additional feature +   Vendor B Standard Vendor A

Interop problem #5 – Vendor establishes market with “non-compliant”implementation Issue: Particular vendor’s implementation includes errors with respect to standard and particular implementation become “de facto” reference Detection: Problem surfaces during interop testing and/or certification when a vendor that is compliant with the standard encounters interop issue Action: Other vendors often FORCED to emulate non-standardised implementation Sometimes error is documented as part of revised standard ?#   Vendor B Standard Vendor A

Interop problem #6 – Unexpected combination of different standards Issue: Different standards were never designed to work together Detection: Problem surfaces during system integration Or, at end-user premises… Action: Cross-industry discussion to determine which standard needs to be changed to ensure compatibility OR, “glue” features added to resolve problem  Vendor A Standard A  … …  Standard B Vendor B

So, what makes a "good" interop process? Based on standards Developed within open environment Clear feedback path to take proposed corrections back to "source" standards body(s) Able to handle interactions between different standards from different "worlds" .. plus an interop profile ALSO defined within open environment Only contains features that are covered by base standards Conducting interop events That follows the agreed interop profile Operating in an climate that encourages participants to determine root cause of interop issues

..and what about regulator's role? Interop is a basic guarantee for competition dominant players cannot "abuse" of their market positions fair, non-discriminatory treatment of interconnection "open" standards means "open access" to essential facilities Regulators can intervene at dominant player's network at: bulk traffic exchange interconnection points end-user terminals information system access points (O&M, OSS, etc.) Scope of intervention can include: mandatory adoption of a common open interconnection point list of mandatory service provisioning features economic compensation against unbalanced competition

Concluding remarks: the “carrot” and the “stick” problem Basic issue facing industry: What is the self-interest in being interoperable? Two answers: “The Carrot”: Advantages in being interoperable Lower CAPEX/OPEX Higher revenues (through open end-to-end services) But: Early mover advantage is not protected Industry certification reduces cost/delay of operator (re-)validation “The Stick”: Cost of not being interoperable Regulatory pressures/remedies Framework Directive Article 17, RTTE Directive “the sleeping article 3.3a”, Access directive article 5 and Competition law Loss of market entry only if operators insist on interop testing and/or certification!

www.alcatel.com