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!