Formal Method to Derive Interoperability Requirements and Guarantees

Interoperability among telecommunications systems, possibly by different vendors, is essential for both the development of many telecommunications networks, and today's civilization development. Interoperability testing is very costly, as it has a complexity of (n**2) for n systems, and somewhat informal. In this paper, we develop a 'Conformance Testing (CT)'-based formal technique to determine interoperability requirements/guarantees. It allows automated derivation of the interoperability' requirements of various networks as well as the interoperability guarantees among different telecommunications systems. This is achieved using static analysis of the conformance classes of the standard and knowledge of the implementation's degree of conformance (DoC) of the telecommunications systems. Consequently, it results in a lot of cost saving in addition to being a formal technique.


INTRODUCTION
Different telecommunications networks are typically by different vendors.This is often associated with many interoperability problems.This is the case even when these products are conforming products to an international standard.Also, different telecommunications products by the same vendor and that play different roles in the network may have interoperability problems in certain cases.Nevertheless, building a multi-vendor network has become a key requirement of every intelligent telecommunications user.This is to relief that user from dependency on any single telecommunications vendor.Such independence, when achieved, results in better economics of the network expansion and more importantly a feature richer network and continuous supply of telecommunications products.This motivated the work on Interoperability Testing.Methods [8.9.10,11].
Interoperability testing methods developed so far are mainly informal methods that are both protocol dependent and product dependent.By protocol dependent, we mean that the method's applicability is limited to only one protocol.Product dependency means that the method has to be applied for every pair of products for which interoperability is required; consequently, the complexity of the "interoperability testing"-based methods for interoperability analysis is (n**2).So, for n different telecommunications products, all the following are required: Results Analysis.In this paper, we develop a CT-based method for interoperability analysis and guarantees.CT is the type of testing that aims at increasing the confidence in the correct implementation of the telecommunications products.As CT is also an ISO (which aims at facilitating Open Systems Interconnections) research work, it has to also increase the confidence that conforming implementations interoperate.The CT-based method has a complexity of just n for n different products.As the method depends on static analysis of the standard and the determination of the DoC of every product, no additional tests are required: this includes no design at all of any interoperability test suites.Furthermore, the method is formal and facilitates full automation.
I: set of interactions BS: Specification of allowed protocol behavior.From BS, all the allowed sequences of interactions (BSeq) can be derived.Also, the inter-dependencies between the interaction parameters can be extracted.Each sequence (trace) BSeq s = (s,P s , C s ) represents: a) A syntactically allowed ordering s of interactions.b) A number of constraints (C s ) on the parameters (P s ) of the interactions in the ordering s.From BS, it is possible (in principle) to derive all possible traces (BSeq) as follows: Let -S be the set of syntactically allowed orderings of interactions as derived from BS; -R : Constraints relation www.ijacsa.thesai.org-For each s  S,  C s  R where C s represents a set of constraints on parameters P s in s.
Then, the set of all possible traces is denoted BSeq = {(s.P s .C s )} where s (=<i,.i 2 .. .,i n >) S P s = {(p j , v (p j )/  i(p 1 ,p 2, .. .,p k )  s, K ≥ j ≥ 1} Meas of Specifying Components: I, P, and BS can be formally specified using an FDT.TDPICSP is given in tabular form.ServDesc, ConfStat, and NCTC are given in a natural language.

III. CONFORMANCE CLASSES
A Standard typically has capabilities whose faithful support is mandatory for conformance or optional or conditional [2.6.7].This generates Conformance Classes.Thus, we have: Let M, 0, and C be the sets of mandatory, optional, and conditional capabilities respectively.Let also, R: C x C. Interdependency Relation where (c i , c j ) is in R iff faithful support of c i requires faithful support of c j .Then, ConfClass is defined to be Set of Conformance Classes =(MXOj) U DOj where Oj  O and DOj = {c i /(c l ,c i )  R and c l  Oj}.
Every conformance class corresponds to a self-contained set of capabilities.Each conformance class identifies a unique set of conformance requirements that has to be satisfied by an implementation to be a conforming implementation to the conformance class.
Conforming implementations are more likely to perform the required functionality as well as interoperate than nonconforming implementations.Interoperability problems typically involve:  receiving an illegal PDU that the implementation cannot understand; or  receiving a legal PDU but with an illegal parameter; or  receiving a legal PDU in an unexpected state.These problems may result from error in designing the protocol itself or in implementing the protocol.Protocol Verification and Validation aim is to resolve errors in designing the protocols.Conformance Testing may handle errors (uncover them) in implementing the protocols.

IV. INTEROPERABILITY REQUIREMENTS AND GUARANTEES
In this section, we develop a formal method to derive interoperability requirements and guarantees.The method is based on conformance testing and the use of a Testability-Directed protocol Standard.
A conformance class ConfClassj is interworkable with a conformance class ConfClass;.denoted by ConfClassj INTERW ConfClassj.iff ConfClass i meets all the requirements for interworking with ConfClass j ; i.e.. ConfClassj may not receive, from ConfClass j a request for a service for which ConfClassj cannot guarantee delivery as per the standard.However, ConfClassj may offer more services functions/capabilities than ConfClass j .It is important to note that the relation INTERW is not symmetrical as anticipated."Conformance Testing" of an IUT determines the IUT's "Degree of Conformance (DoC)".
Here, we consider the lUT's (maximum) degree of conformance to correspond to the largest conformance class that the IUT faithfully supports.The determination of the Conformance Classes and the DoCs facilitates static investigation and study of the interoperability between the implementations of the various conformance classes: this is illustrated in the next section.This is particularly important because it provides extensive information about the potential for interoperability between the various conforming systems without having to have any physical development of any of these systems.Such information can assist manufacturers in making decisions (marketing decisions) about what standard capabilities to support, and assist the users in making decisions on what capabilities to require faithful support for in the products they intend to purchase.The Conformance Statement component of this testabilirydirected standard is now constructed according to the guidelines in [1.6,7].and the International Conformance Testing Standard ISO/IEC 9646.

END_Tcstability-Directed_TP_Class_2_Standard ________________________
Analysis with Respect to Interoperability Requirements/ Guarantees The TDPICSP-based conformance requirements, as indicated by the TDPICSP.indicate that every implementation, to conform to the specification, has to support at least three capabilities: DT.DC. and either IC or RC; also, if the RC capability is supported, the support of the NegO R is mandatory.A conforming implementation supports up to seven capabilities.The support of the NegO I (NecO r ) capability requires the support of the IC (RC) capability.Consequently, there are nine conformance classes of implementations as follows (where the # field provides the conformance class identifier and the other field provides the capabilities that constitutes the conformance class): Every conformance class corresponds to a unique degree of conformance of implementations; consequently, there are ten implementation's degrees of conformance (IDoC) (one degree of conformance corresponding to each conforming implementation class plus a zero value (Implementation's Degree of Conformance of Zero) corresponding to implementations that fail to faithfully support any of the mandatory requirements).The static analysis of these conformance classes along with the "Implementation's Degree of Conformance" of the various implementations provides a good basis for determining the chance of interoperability between the various conforming implementations: for example.two conforming implementations with Implementations Degree of Conformance = 4 (i.e.. faithfully supports conformance class 4) cannot interwork because neither of the two implementations can initiate the establishment of a connection (each of the two acts always as a responder); while two implementations with Implementation Degree of Conformance = 9 can interwork with each other.Such type of interworking, that is capability-based, is called, here, "Capability (functional) Interworking" and can be determined by static analysis of the testability-directed standard.
On the other hand, class-9-conforning implementations (implementations that faithfuly) supports every capability, in the standard) have the highest chance to successfully interwork as long as TP(2) standard is considered, with every other conforming implementation.Generally, these class 9 conforming implementations interwork with every other faithfully conforming implementation provided that the standard is error free: such interworking covers only those layers/protocols covered by the standard.
For the testability-directed standard.We have the following interworking guarantees, illustrated in Figure 3 in a lattice form, where every node represents implementations that faithfully support a valid class and the conforming www.ijacsa.thesai.orgimplementations of a node can interwork with every conforming implementation in its sub-tree: the type o! interworking meant here is that the conforming implementations of a node may not initiate/invoke a capability that the conforming implementations of any of its parent nodes cannot positively (according to the standard) respond to it.For example, the IC capability of a conforming implementation interworks with an RC capability of another conforming implementation: consequently, implementations conforming to class 1 interwork with the implementations conforming to class 4 but not class 1: consequently, a class -4 node (but not a class 1 node) is a parent of a class 1 node.Also, class-4conforming implementations can intenvork with class-8conforming implementations because the latter may not initiate the invocation of a capability that the class-4conforming implementations cannot faithfully respond to it (i.e., there is a class 4 node that is a parent to a class 8 node).The "interwork with" relation as defined on the conformance classes is not reflexive because, for example, the class-1-conforming implementations cannot interwork with the class-1-conforming implementations (they deadlock).Also, "intenvork with" relation is not transitive.For example, the class-1-conforming implementations interwork with class-4-conforming implementations and class-4-conforming Implementations interwork with the class-2-conforming implementations.But, class-1-conforming implementations do not interwork with class-2-conforming implementations.
However, a testability-directed standard facilitates the static analysis of the specification for interworking guarantees based on the implementation's degree of conformance which, in turn, is very useful for resolving many conformance testing issues and interoperability issues as well as assisting industry in making intelligent decisions regarding what capabilities to require the implementations to faithfully support.

VI. CONCLUSIONS
In this paper, we have developed a CT-based technique to analyize interoperabiliy requirements and guarantees.The technique is a formal technique which makes it not error prone.Also, the technique is general enough to be applied to various communications protocols as far as they are formally specified using an International FDT: Lotos, Estelle, or SDL.The analysis is a static analysis which saves a lot of cost in performing interoperability testing.For n implementations of a standard, the method requires running only n conformance tests rather than n times n interoperability tests.Furthermore, the n conformance tests are needed in any way.Consequently, the method does not require conducting any additional tests and therefore saves a lot of cost.The applicability and practicality of the method has been demonstrated by a real large protocol standard.Finally, the method can be fully automated.
C s ={(p i .pj )/p i ,p j  P s } TDP1CSP: Testability-Directed Protocol's Implementation Confomance Statement Proforma [l].ConfStat: Conformance Statement ServDesc: Service Description of the various capabilities covered by the standard.NCTC: Non-Conformance Testing Clause.
said to be 1 interoperable with an implementation I', denoted by I INTERO I', iff there is not a capability, out of those offered by the standard, that I' may request from I and I cannot faithfully offer.Lemma: For two implementations I and I': I INTERO I' iff I CONF ConfClass I , I' CONF ConfClass j , and ConfClass I INTERW ConfClass I' .Proof: Follows from having I CONF ConfClass j , I' CONF ConfClass I' and the definition of INTERW.V. EXAMPLE Automated derivation of interoperability requirements and guarantees are illustrated by a Testability-Directed version of the Transport Layer Class 2 protocol given as follows.tcc (al v a5):M I B15 TConnectionRequest tcr (al v a6):M R B16 TDisconnectionlndic tdi (al v a4 va6):

Figure 2 :
Figure 2: Lattice Representation of the interoperability guarantees between the various conforming classes.