Standards, open standards and Interoperability II 20-21 September 2005 Sophia Antipolis

1. Standards, open standards and Interoperability II 20-21 September 2005Sophia Antipolis Track 1: Interoperability Break-out session Room = IRIS 6 Moderator: Hans van der Veer Support: Anthony Wiles

2. 15 Attendees • Jonas Sundberg (Ericsson) • Timo Leppinen (Ficora) • Ronald Zink (Microsoft) • Dave Penkler (HP) • Didier Chauveau (ARCEP) • Fred Harrison (OMA) • Gilbert Buty (Alcatel) • Genevieve Feyt (CENELEC) • Freek Posthumus (Norampme) • Philippe Pilcher (Group CANAL+) • Thomas Nogues (NDS Ltd) • Gerfried Handke (Unisys) • Jaap Wansbeek (Ministry of Ec. Affairs) • Hans Van Der Veer • Anthony Wiles

3. Input documents presented and discussed • Summary of Interoperbility • Hans Van Der Veer • This summary is based on GA/Board/SOS-Interop-1 presentations • Development of IOT specifications for IMS applications in 3GPP • Jonas Sundborg

4. Subjects discussed • Question to be addressed: • What can a standardization body do to contribute to the solution of an emerging interoperability "nightmare"? • Interoperability definition • Scope of our discussions • Interoperability Inhibitors and how to address them • Pre - standardization considerations • During standards development • Conclusions • Characteristics of a Best-in-Class SDO & Forum/Consortium • Concrete example

5. Interoperability: Definition • The concept of interoperability has different meanings depending on the context • Limit to two different forms ofTechnical Interoperability • Conformity and interoperability tests are defined as ‘the activities by which implementations are tested against the standard and by which successful cooperation between different implementations of the same standard is tested in practice’ • Inter-working is defined as ‘the ability to link two or more systems, networks or services which differ essentially in technical respects, so that they can successfully provide an electronic communications service or can exchange and process information’. This definition refers in particular to the linking of systems, which are based on different standards or technical specifications.

6. Application Layer Services Layer Substituting Technologies Session Control Layer Transport Layer (incl. Access and Core Network) Complementing Systems Technical Interoperability An Interoperability problem? Most certainly yes: • Different administrative domains: • (access or core) Network providers • Service providers • Many different technologies per layer specified by many different SDOs • Horizontal and Vertical interfaces (incl. QoS, security) • In need for efficient Network and Service Management (OPEX reduction) • Securing Maintenance Inter-Working Conformity and Interoperability Tests

7. Technical Interoperability Pre-Standardization Considerations (1) • Converged multimedia market with an increasingly complex structure • Mass market development requires technical interoperability based on open standards, but ……. • Barriers to technical interoperability • Tendency to vertical business models • It may be justified to have a vertical business model in some instances, e.g. learning what the market needs • Standardization needed when the market decides (not before!) • Fast evolution of technology with unclear IPR implications (e.g. open source, proprietary or non-open standards)

8. Technical Interoperability Pre-Standardization Considerations (2) • Market players: what, where, when to standardize depends on their business strategy! • Many SDOs, forums, consortia • Multiple sets of inter-workable standards required (e.g. NGN, 3GPP) • Standards held by one body need to be recognized by others • Competition between standards bodies may result in market fragmentation • Fragmentation of end-user markets should be avoided • Interoperability can help • Innovation should be promoted • Decision making process & applied methodology • Should be harmonized / matched • An Agreed Architecture is key to Interoperability

9. Technical Interoperability Standardization Considerations (1) • Main aim is to enable interoperability in a multi user type, multi-vendor, multi-network, multi-service secure environment • (Open process, attractive IPR policy) • Possible interoperability inhibitors: • Specifications are imprecise, incomplete or incorrect, or have too many options • No clear owner for an agreed architectural approach • Interoperability is all about architecture • Different Standardization approaches (e.g. ex-post vs ex-ante, top-down vs bottom-up, “component” approach, revision & change request management) • Collaboration of SDOs, fora/consortia still is essential in many cases

10. Technical Interoperability Standardization Considerations (2) • Measures to ensure technical interoperability: • Ex-ante specs: requirements, architecture, protocol • Unambiguous, commonly agreed requirements & architectures (e.g. other SDOs) • “Design for interoperability” (conformance & inter-working) • Avoid options; strive for a “one profile per protocol” • Strictly applied project control procedures • Tight collaboration with other standards bodies, fora and consortia • Ex-post specs: conformance tests, interoperability tests • Better, structured feedback of results into standards development process • Structured approach to interoperability testing • Affordable interoperability testing, incl. (if required) certification to ensure market acceptance

11. Conclusions (1) • Required characteristics for an SDO, Forum/Consortium • Have efficient and effective working methods (e.g. project control, decision making) and be able to impose them • Currently rigor project management and control methodologies are not really applied. • They do not impose feedback from conformance, interoperability testing and other validation activities • Include Interoperability requirements from an end-user perspective from the beginning • Have a structured approach to interoperability testing in place, embedded in the standards development phases • A permanent test bed associated with large standards projects and in support of such a structured approach is a plus!

12. Conclusions (2) • Required Characteristics for an SDO, Forum/Consortium • Have effective, efficient collaboration with other SDOs, Consortia and Forums • Avoid duplication of work • Agreed roles/interfaces • Agree on the architect, system integrator (=design for interoperability) and project coordinator roles • If Realistic • Deal with it on an organisational level • Promotion & Awareness are key • Critical subjects requiring immediate follow-up • White paper for terminology, definitions, problem area needed