**3. Methodology overview**

In order to obtain a performance evaluation-based analysis of telecommunications protocols and systems, the proposed methodology extracts all the necessary information from the available form of the analyzed standard. Taking into consideration that we are talking about an early stage of communication system development, the standard for such particular system is usually available as a draft version which combines the work provided by different working groups. The aim is to build an appropriate model from which the performance of the communication system will be assessed. This kind of model is commonly referred to as performance evaluating model. The communication standard under evaluation generally contains three basic parts: textual, SDL-represented and MSCrepresented. Depending on the standard and standardization body, the proportion of these parts can vary. Mainly, the textual part dominates as "in the standardization process, words are still the final product" (Sherif, 1992).

But there is a major setback of the textual part of the standards caused by its inherent ambiguousness which is more deeply related to the natural languages' doublethink. This is the reason why the textual part of standards lacks of scientific foundation and is commonly the reason for miss-communication between standard developers, regarding the communication system requirements and expectations.

related work uses a specification notation based on one of the most commonly used standard requirement languages HMSC/MSC, which can be automatically translated into a generic SDL specification. The obtained SDL system can then be used for the analysis of the addressed security properties, by using an observer process scheme. Besides the main goal to provide a notation for describing the formal specification of security systems, (Lopez, 2005) studies the possible attacks to the system, and the possibility of re-using the produced

The related work (Chen Hui, 2010) analyzes a Networked Control System (NCS), which governs the communication activities and directly affects the communication Quality of Service (QoS). Full or partial reconfiguration of protocol stack offers both optimized communication service and system performance. (Chen Hui, 2010) proposes a formal approach for the design and implementation of reconfiguration protocol stack based on Specification and Description Language for NCS. In Telelogic TAU environment, detail SDL models to support communication and reconfiguration functions of communication link layer, network transmission layer and application layer are discussed respectively. Similarly to the most of the presented related papers, only MSC verification results validate the effectiveness of the reconfiguration concepts of the protocol implementation

The methodology which is presented in the following section differs from all previously presented work, as it extends the performance evaluating aspect of the communication systems engineering process. The methodology tries to maintain the functional correctness efforts regarding developing communication entity (similarly to the most of the related work), but at the same time provides the developers with a realistic insight of its

In order to obtain a performance evaluation-based analysis of telecommunications protocols and systems, the proposed methodology extracts all the necessary information from the available form of the analyzed standard. Taking into consideration that we are talking about an early stage of communication system development, the standard for such particular system is usually available as a draft version which combines the work provided by different working groups. The aim is to build an appropriate model from which the performance of the communication system will be assessed. This kind of model is commonly referred to as performance evaluating model. The communication standard under evaluation generally contains three basic parts: textual, SDL-represented and MSCrepresented. Depending on the standard and standardization body, the proportion of these parts can vary. Mainly, the textual part dominates as "in the standardization process, words

But there is a major setback of the textual part of the standards caused by its inherent ambiguousness which is more deeply related to the natural languages' doublethink. This is the reason why the textual part of standards lacks of scientific foundation and is commonly the reason for miss-communication between standard developers, regarding the

specifications to describe and analyse more complex systems.

for NCS.

performance capabilities.

**3. Methodology overview** 

are still the final product" (Sherif, 1992).

communication system requirements and expectations.

On the other hand, the SDL and MSC parts of the standard introduce more rigorous protocol or system specification, brought to a mathematical precision, and these formal parts of the standard are the guarantee for a correct system requirements presentation, as well as for an unambiguous definition of the system behavior. As it was previously said, different standards contain variable amount of formal representation, e.g. IEEE 802.16 (WiMAX, 2010) contains only sequences of formal protocol behavior, IEEE 802.11 (WiFi, 2007) encloses entire Medium Access Control (MAC) Layer presented in SDL, and IEEE 802.15 (Bluetooth, 2005) is completely offered in formal representation.

Using the three basic types of standard representations, the proposed methodology creates a so called behavior model of the analyzed standard, as it is presented in Fig. 1. The behavior model describes the protocol behavior and its abstract data structure by using SDL. In particular, the behavior model evaluates the relationship of single stimuli - response pair applied to the analysed protocol stack. This model is ideal for testing of protocol entity's functional correctness.

Fig. 1. Transformation of a communication standard into a performance model.

As it can be seen in Fig. 1, the last step of the methodology is the conversion of the behavior model into a so called performance evaluating model. The performance model can emulate a real scenario of communicating devices implementing the described protocol. It is built into a standalone executable that embeds the created behavior model and channelizes its preciseness into an accurate event driven type of simulator. This type of simulator is used for performance evaluation of the communication system or protocol, where every change and tuning of the specification can be easily evaluated. For instance one can measure the achieved data throughput or delay when a group of protocol based devices are communicating between each other.

Both, behavior and performance models provide valuable information regarding the functional and performance issues of the developing communication system, which is then looped-back to the specification process for further improvement of the system.

#### **3.1 Detailed steps in the methodology**

The behavior model can be defined as a SDL representation of the requirements, behavior and capabilities of the specified system or protocol. As it was explained earlier, it is created using all three representation parts of standards (text, SDL, and MSC). The SDL part of a standard is easily incorporated in the behavior model. This is the reason why the SDL part of the standard formulates the backbone of this model. Obviously it is the most mathematically rigorous component of the behaviour model. The MSC part of the standard includes all signal exchange sequences occurring among the protocol entities defined by the standard. To incorporate this part into the behavior model, it is necessary first to convert the MSCs into SDL code sequences. Although automated tools for such a conversion exist, the manual step-by-step translation is preferred, as the SDL code produced by the automated tools is not optimized, and also for providing nomenclature and stile consistency of the SDL code. The trickiest part of the behavior model development is to convert all the informal textual representation of the standard into SDL code. This is an unavoidable step, as long as all the missing parts of a complete functional system description are given in a textual form. The SDL code sequences produced from the textual part of the standard act as a glue that connects all the previously created parts of the behavior model. The need to convert text into SDL is also unavoidable because of the fact that for most of the communication standards the SDL and MSC parts are supplementary, while the textual part is mandatory. These are the reason why this step should be taken as the one with greatest importance. Additionally, the communicating signals which are exchanged among entities, along with the signal parameters, are most of the times constructed according to the text of the standard. The practice have shown that it is much easer if the textual represented requirements of the standard are firstly translated into MSC sequences, and after that converted into SDL code. This principle proves to be especially suitable for capturing the complex communication system or protocol behavior.

For the completeness of the previous explanation, this section will present an example of a generic behavior model of an abstract communication standard (Fig. 2). As it can be seen in Figure 2, SDL copes with the protocol complexity by using a hierarchical decomposition and by implying several levels of abstraction. The highest level of abstraction is called the system level. The system level is composed of multiple SDL blocks connected through unidirectional or bidirectional SDL channels. SDL channels are transferring SDL signals, which can carry additional signal parameters. Inside the SDL blocks lays the second level of abstraction represented by groups of processes located in the blocks. The processes use signal routes for transferring the signals among them or to the higher-level channels. Inside the SDL processes, Extended Communicating Finite State Machines (ECFSMs) are used for description of each protocol entity behavior. This is the lowest and the most detailed level of the behavior model. The functionalities of the protocol entity are presented unambiguously by using SDL discrete states, triggers, transitions, tasks, procedures, decisions, manipulation of variables, management of

Both, behavior and performance models provide valuable information regarding the functional and performance issues of the developing communication system, which is then

The behavior model can be defined as a SDL representation of the requirements, behavior and capabilities of the specified system or protocol. As it was explained earlier, it is created using all three representation parts of standards (text, SDL, and MSC). The SDL part of a standard is easily incorporated in the behavior model. This is the reason why the SDL part of the standard formulates the backbone of this model. Obviously it is the most mathematically rigorous component of the behaviour model. The MSC part of the standard includes all signal exchange sequences occurring among the protocol entities defined by the standard. To incorporate this part into the behavior model, it is necessary first to convert the MSCs into SDL code sequences. Although automated tools for such a conversion exist, the manual step-by-step translation is preferred, as the SDL code produced by the automated tools is not optimized, and also for providing nomenclature and stile consistency of the SDL code. The trickiest part of the behavior model development is to convert all the informal textual representation of the standard into SDL code. This is an unavoidable step, as long as all the missing parts of a complete functional system description are given in a textual form. The SDL code sequences produced from the textual part of the standard act as a glue that connects all the previously created parts of the behavior model. The need to convert text into SDL is also unavoidable because of the fact that for most of the communication standards the SDL and MSC parts are supplementary, while the textual part is mandatory. These are the reason why this step should be taken as the one with greatest importance. Additionally, the communicating signals which are exchanged among entities, along with the signal parameters, are most of the times constructed according to the text of the standard. The practice have shown that it is much easer if the textual represented requirements of the standard are firstly translated into MSC sequences, and after that converted into SDL code. This principle proves to be especially suitable for capturing the complex communication

For the completeness of the previous explanation, this section will present an example of a generic behavior model of an abstract communication standard (Fig. 2). As it can be seen in Figure 2, SDL copes with the protocol complexity by using a hierarchical decomposition and by implying several levels of abstraction. The highest level of abstraction is called the system level. The system level is composed of multiple SDL blocks connected through unidirectional or bidirectional SDL channels. SDL channels are transferring SDL signals, which can carry additional signal parameters. Inside the SDL blocks lays the second level of abstraction represented by groups of processes located in the blocks. The processes use signal routes for transferring the signals among them or to the higher-level channels. Inside the SDL processes, Extended Communicating Finite State Machines (ECFSMs) are used for description of each protocol entity behavior. This is the lowest and the most detailed level of the behavior model. The functionalities of the protocol entity are presented unambiguously by using SDL discrete states, triggers, transitions, tasks, procedures, decisions, manipulation of variables, management of

looped-back to the specification process for further improvement of the system.

**3.1 Detailed steps in the methodology** 

system or protocol behavior.

signals, etc. In the same manner, all protocol primitives are described, along with the signal's parameters exchanged among the protocol entities.

Fig. 2. Insight of a generic behavior model.

In order to assess the real performance of the analyzed system or protocol, it is necessary to build a performance evaluating model. The SDL performance model can emulate real working scenarios of communicating devices. It is a standalone model that embeds the behavior model and translates its preciseness into an accurate event driven type of simulator. The results obtained by the performance model are reliable indicator of the expected performance of the future communication device, which will be built according to the analysed standard.

The process of 'assimilation' and upgrade of a generic behavior model into a generic performance model is depicted in Fig. 3. The presented generic behavior model contains several protocol layers, represented by SDL processes. The following layers are included: Convergence layer, MAC layer, PHY layer, and a vertical Management layer. The behavior model describes all possible interactions between these entities in a single stimuli-response manner.

Fig. 3. Building a generic performance model.

Unlike the behavior model where only single stimuli - response pair of a protocol entity is evaluated, the performance model introduces new entities which are needed for completing the communication scenario emulation, both on system and block level. On the system level besides multiple instances of the modified behavior model, it is crucial to introduce a simulation control block and a channel block. The control block manages the generation of block-instances and controls the simulation time, while the channel block ensures a proper emulation of exchanging packets (e.g. radio frequency packets) among the communicating entities. Each block instance is characterized by a unique process identifier (PID), which enables differentiation and addressing of the identical entities.

As it was previously stated, in the foundation of the performance model lays the behavior model. It is necessarily modified (i.e. upgraded), in order to conduct its expected role of real communicating device emulation. Many new processes with an appropriate purpose should be introduced in this upgraded version of the behaviour model: controller of the primitive exchange process, procedures for queuing and prioritization of the signals, processes for segmentation and reassemble of the massages, manipulators of simulation time (timers and clocks), etc. All these processes are introduced according to the textual part of the protocol specification.

After building the performance model using the SDL Graphical Representation (SDL-GR), abstract Data Types (ADTs) are added in order to introduce important functionalities (e.g. reading and writing to file, different kinds of random number generators, etc.).

The analyzer then runs the performance model for detecting all the ambiguities. Next step is the conversion of the built model into a so called Phrasal Representation of SDL (SDL-PR). Using SDL-PR, the code generator produces C++ source code, compiles it and links it with appropriate libraries. The result of these steps is a standalone simulator executable which requires as an input only the configuration files, needed for the description of the desired network scenario.
