TTCN-3 and ASN.1 interworking

1. TTCN-3 and ASN.1 interworking Analysis of backward compatibility in ASN.1 Géza Horváth geza.horvath@nsn.com TTCN-3 User Conference 2011 7 – 9 June 2011 - Bled, Slovenia

2. Introduction • Nokia Siemens Networks • Joint Venture of Nokia and Siemens • Started operations on April 1, 2007 • 65,000+ employees • 75 of top 100 operators worldwide • 150 countries • 3 billion mobile subscribers and ¼ of • world’s voice households served • Géza Horváth • Release 4 Product Support Engineer

3. Agenda Concept of ASN.1 – TTCN-3 Compatibility of ASN.1 Planning a comparator tool Result, future

4. ASN.1 introduction ？ • Vendor- and language-independent • Recursive notation for complex data types • Avoid the transfer of concrete syntax • Encoding rules

5. Using ASN.1 with TTCN-3 • TTCN-3 provides a clean interface for using ASN.1 specifications: ETSI ES 201 873-7 • Alternative data type and value syntax • Implicit mapping: import • Internal representation of imported objects • Without any lost information

6. Agenda Concept of ASN.1 – TTCN-3 Compatibility of ASN.1 Planning a comparator tool Result, future

7. The need of ASN.1 compatibility • INTEGER(1..10) • INTEGER(1..10,...) • Extension marker ”...” • Specification v2 must include v1 • Two compatible specifications are not necessarily syntactically identical • Syntactic differences should be detected • Semantics are very bound to syntax • Two distinct specifications of the same protocol can be compared to evaluate the impact on the interface

8. Syntactic compatibility between ASN.1 specifications • OPTIONAL keyword • Extensible subtyping constraints • Permutation of SET components • What if v1 does not send the INTEGER to v2? • What if v2 sends the value 11 to v1? • Without the extensions marker? • We should know all the changes on the interface • In case of SEQUENCE?

9. Agenda Concept of ASN.1 – TTCN-3 Compatibility of ASN.1 Planning a comparator tool Result, future

10. Structure of the comparator • Parser: syntactic error messages as well • Normalization: avoiding circular definitions • Transitive closure: checking references, imports

11. Root Root PDU 1 PDU 1 statement 1 statement 1 statement 2 statement 2 PDU 2 PDU 2 Comparator algorithm • A diff-like (textual) algorithm? • Detailed comparison algorithm on graphs! • The goal is the find a matching between two trees • Nodes of the two trees are numbered • A global default mark is assigned to the root • It is divided between each branch of the root, and so on recursively • According to how each node matches with the corresponding one • The mark is inherited completely or • Decreased portionally to the result of the comparison

12. Comparator algorithm • Synthesised mark at highest level can be considered as the global level of syntactic mapping • Compare each PDU of v1 to all PDU of v2 to determine the best matching

13. Agenda Concept of ASN.1 – TTCN-3 Compatibility of ASN.1 Planning a comparator tool Result, future

14. Result • Simple semantic deductions based on syntactic differences • * Only notice, not incompatibility • ** In some cases it can be incompatibility • *** Incompatibility • Important to build up an effective visualization • A specification can be very huge

15. Extension for future • Complete formalization of all the comparison rules • Fortunately the algorithm is easily extensible • All the error messages are mainly syntactic • Addition of the semantics in order to refine messages • Integration with specification environment

16. Thank you for your attention! • Géza Horváth • geza.horvath@nsn.com