TTCN-3 and ASN.1 interworking

TTCN-3 and ASN.1 interworkingAnalysis of backward compatibility in

ASN.1

Géza Horvá[email protected]

TTCN-3 User Conference 2011

7 – 9 June 2011 - Bled, Slovenia

2 © Nokia Siemens Networks TTCN-3 and ASN.1 interworking / Géza Horváth

Introduction

Géza Horváth

•Release 4 Product Support Engineer

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


Agenda

Concept of ASN.1 – TTCN-3

Compatibility of ASN.1

Planning a comparator tool

Result, future


ASN.1 introduction

Record ::= SEQUENCE { name PrintableString (SIZE(1..30)), age INTEGER, gender ENUMERATED { unknown(0), male(1), female(2) } }

typedef struct Record { char name[31]; int age; enum { unknown = 0; male = 1; female = 2 } gender; } Record;

type record = { name : string; age : num; gender : t_gender }and t_gender = Unknown

| Male| Female

Abstract syntax in ASN.1

Machine AConcrete syntax in C

Machine BConcrete syntax in Objective Caml

Transfer syntax

(bytes or bits)

• Avoid the transfer of concrete syntax

• Vendor- and language-independent•Recursive notation for complex data types

•Encoding rules

？


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


Agenda




Result, future


The need of ASN.1 compatibility

• 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

•INTEGER(1..10)•INTEGER(1..10,...)


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?

•We should know all the changes on the interface•In case of SEQUENCE?

•What if v2 sends the value 11 to v1?•Without the extensions marker?


Agenda




Result, future


Structure of the comparator

•Parser: syntactic error messages as well

•Transitive closure: checking references, imports

•Normalization: avoiding circular definitions


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

Root

PDU 1

PDU 2

statement 1

statement 2

Root

PDU 1

PDU 2

statement 1

statement 2


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


Agenda




Result, future


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


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


Thank you for your attention!

Géza Horvá[email protected]

Documents

TTCN-3 and ASN.1 interworking