Six Ways to Kill Interop

1. Six Ways to Kill Interop Alistair URIE

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. ..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

11. 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!

12. www.alcatel.com