Animation-Based Explanation of Basic Data Communication Principles

Animation-Based Explanation of Basic Data Communication Principles Author: Drago Hercog, University of Ljubljana, Faculty of Electrical Engineering, Tr_a_ka 25, SI-1000, Ljubljana, Slovenia, Drago.Hercog@fe.uni-lj.si Abstract The complexity of communication systems is high. Hence, the presentation of modern communication methods to undergraduate students is difficult. A graphic presentation, and especially an animation can be much more effective than a bare text. The animations must concentrate on basic methods, be enough abstract, user friendly, aesthetic, and possess some kind of flexibility concerning animated scenarios, speed of presentation, possibility of being suspended etc. During our elementary course on communication protocols, we use animations of several types of communication processes. Most of them were developed by undergraduate students as their final projects which forced them to study the relevant protocols in detail and also to do some design/programming work. In the paper, an animation of communication process involving two adjacent layers according to the OSI reference model are presented in more detail. In the lower layer, a very basic and simple ARQ (Automatic Repeat request) protocol is used. The notion of Service Access Point and the use of primitives can be explained, as well as basic ARQ protocol mechanisms, such as the relation between protocol and service data units, the need for memory buffer and the role of timer. The difference between real and virtual channels can also be clearly shown. The abstraction priciple used in the OSI reference model is particularly emphasised. Index Terms Abstraction, animation, basic concepts, communication protocols, OSI reference model INTRODUCTION Although many techniques are being used nowadays to reduce communication system complexity, this complexity continues to be high. This fact, as well as the fact that communication processes evolve both in space and time [1], make modern communication methods quite difficult to be presented to and to be understood by undergraduate students. It is therefore very important to use appropriate pedagogic methods in such a presentation, including those offered by modern computer-based techniques. Simulations have already been recognised as successful research, development and pedagogic tools, used for validation, correctness verification and performance evaluation of protocols, while animations are being used especially as didactic tools to support teaching and understanding of communication systems and protocols by means of their graphic presentation. Many animation programs and particularly simulators have been developed for numerous real-life protocols and usually based on their formal specifications written in formal description techniques, especially those that already possess some graphical syntax, such as SDL [2] or MSC [3]. Although animations have not shown as popular as simulations [4], simulators have often been upgraded by animation user interfaces, in order to graphically present the communication process [5]. Generic animation tools, based on formal protocol specification and applicable to the animation of different communication protocols [6], are very flexible and offer a very broad area of usability, but we will describe here how to create custom-tailored animations. Undergraduate telecommunications students are usually not taught real-life protocols at the very beginning of their protocols course. Rather, they must be given some simple and illustrative notion about how protocols work at first. Therefore, some very streamlined and abstract protocols (even if not usable in every-day practice) are used to this end. Additionally, even more abstract animations can be employed to illustrate them graphically. These animations must focus only on the very essential properties of basic communication algorithms [7]. In the rest of this paper, the most essential points of a basic communication protocols course, as experienced by the author, will be highlighted first. After this, some basic principles of communication protocol animations for didactic purposes will be exposed. Then we will explain how protocol animations are developed for our own educational needs. Finally, an example animation and its didactic aims will be described into details. 1

A FIRST COMMUNICATION PROTOCOLS COURSE FOR UNDERGRADUATES Within their first communication protocols course, undergraduates must be exposed to the basic data communication principles, rather than to some complex real-life protocols. During serveral years of teaching a communication protocols course for undergraduate students of telecommunications, the author has found the following to be the key didactic points. The notion of the communication service offered by a service provider to service users must be explained first. Then, it must be shown how users and the service provider interact by means of primitives across service acces points (SAPs). Only then the basic implementation of the service provider, consisting of protocol entities, exchanging protocol data units (PDUs) via the channel, according to the protocol used, and interacting with users across service access points, can be given. The difference between the peer-to-peer communication process running between peer protocol entities and the user-to-provider interaction carried out between protocol entities and service users, must be emphasised. The difference between service data units (SDUs) exchanged across SAPs and protocol data units exchanged across the communication channel is also explained at this point. The relation between the service data unit and protocol data unit and the role of protocol overhead are described as well. The basic model of a protocol entity as interacting with users and communicating with its peer entities is also indicated, together with its basic functions of processing, memorising and time measuring. After these basic principles which closely follow the Open Systems Interconnection (OSI) [8] paradigm, the role of abstraction in design and analysis of complex systems is emphasised. The border between the communication service users and the service provider is described as the border between two adjacent levels of abstraction, with service access point acting as a well-defined interface between them. The difference between the virtual channel connecting users and the more concrete channel connecting protocol entities is also indicated. Only then the principles of OSI reference model and other protocol stack architectures can be explained. Finally, some basic algorithms, used by communication protocols, such as framing, error and flow control, segmentation, etc., are shown, followed by a few actual protocols as examples. GENERAL PROPERTIES OF ANIMATIONS TO EXPLAIN BASIC COMMUNICATION PROTOCOL PRINCIPLES It is well known that, in a learning process, a good picture can be better than a lot of less interesting or even tedious text. This is even more true for a dynamic picture presenting a dynamic process evolving in both time and space. An animation is an artificially prepared picture shown on a two-dimensional screen surface that is being dynamically changed in time. All of this is made in a highly controlled way. Due to their ability to present a process both in time and space on a two-dimensional screen of a computer, animations can be considered among the most interesting modern didactic tools that are quite easily prepared (due to many available tools), and even more easily shown. However, in order to be used effectively in an education process and to be better than some similar media, like video, animations must possess some important properties. Animations must be aesthetic, their use must be user friendly and flexible, as their contents and speed of presentation are concerned. The flexibility of contents means that a user has several options as to choose what to see. Different processes with different properties or event sequences are referred to as different scenarios. The speed of presentation is almost never the natural speed of the process shown and must also be modifiable in order to allow a teacher to add their comments to the animation, or to show it more quickly, not to bore students. The animation must also be interruptable. The picture usually consists of its static part presenting the static environment of the presentation, such as the structure of the animated system, or the space where the animated process is evolving, as well as its dynamic part with moving objects showing the behaviour of the animated system in time, such as data being exchanged between system entities. Both static and dynamic objects have their contents that can be symbolically indicated by their position, shape and colour. Symbols must be used so that they implicitely imply their contents. Animations must be as simple as possible. Both the objects and the scenario must contain only the contents that are essential for the understanding of the topic that is to be explained. In other words, animations must be as abstract as possible, omitting all details that are necessary in real-life systems, but are not absolutely necessary for the basic problem understanding, and usually overburden students' minds. One could say that the abstraction and symbolic nature are the most important properties of animations that distinguish them from videos. ANIMATIONS TO EXPLAIN BASIC COMMUNICATION PROTOCOL PRINCIPLES If animations are used to explain basic communication protocol principles care must be taken to show the communication process along all the essential coordinates: space, time and contents. Along each axis, an appropriate level of abstraction must be chosen. Along the space dimension, both communication entities and communication channels must be easily distiguishable. If the process is concurrently shown at different levels of abstractions (such as in different layers of a protocol stack), the 2

boundaries between these levels have to be clearly seen. Entities are usually shown as boxes of different shapes and colours that depend on their respective roles and importances. Messages are presented as dynamic objects that are created when the messages are transmitted, can be shown propagating through the channel, and may be removed from the scene when they are consumed by receiving entities. Usually their contents are denoted either with their abstract syntax or, even more abstractly, with only their message types. Either simple text or colours, and possibly combination of both, can be used for this purpose. Sometimes, however, the essential structure of the messages can even be shown, if this is considered important by the animation designer. The time dependence can be shown as only the development of the picture in time, or the trace of behaviour can be left on the scene to produce a figure similar to timing diagrams, Message Sequence Charts (MSC) or some other form. However, for this latter possibility, we need at least one spacial dimension on the screen. PRODUCTION OF ANIMATIONS There are many different tools available to create animations, with different prices, powers, flexibilities, and requirements for designer's experience. One possibility, although neither most powerful nor most flexible, and above all not the easiest one, is to create animations using one of usual programming languages, such as C, C++ or Java. Nevertheless, we have chosen this latter option for the following reasons. The animations we use have mostly been designed and implemented by our students as their final projects. Such projects have to be completed by all students in about 3 to 6 months period before achieving their diploma degree. In this situation, the computer program design and development in one of usual programming languages is considered pedagogically much more advantageous than the use of some exotic special purpose software for animation creation. A student developing an animation program must carefully study and deeply understand the protocol or system to be animated design the user interface design the graphic presentation of the problem to be animated design the animation program code, test and debug the program document the design and development process, as well as the animation program itself Thus, the endeavour needed to develop the animation tool can be considered at least as important as its use from the pedagagic point of view. Projects that are considered too complex for a single student, can of course be partitioned among two of them. Students are free to choose the programming language according to their preferences and existing knowledge, although C, C++ and Java are most frequently used. Animations written as executable programs are very flexible in the sense that animations of different scenarios can be run with the same program, and even different protocol/system parameters can be used. Executable programs require only modest disc space, and can be developed using relatively cheap resources, including only a personal computer, a software development system with compiler for the chosen language, and a word processor to write the documentation. All of these tools are readily available in almost all cases. Executable programs can be run from within different environments, such as from the operating system, other programs, presentations, or web pages. AN EXAMPLE ANIMATION: ERROR CORRECTION IN DATA-LINK LAYER As an example of an animation that was conceived following the described principles and is quite simple, but pedagogically effective, the animation of a simple error-correction protocol in the data-link layer according to the OSI reference model will be presented with more detail. The protocol is very streamlined. It is connection oriented and relies only on the use of positive acknowledgments and timer. The request, indication and confirm primitives are used for connection establishment/release, while only request and indication are employed for data transfer. The protocol itself is not the only point of interest of this animation. The others, at least as important, include: two-layer OSI-type achitecture abstraction principle user to protocol entity interaction versus peer to peer communication the difference between the confirmed service of connection establishment/release and the unconfirmed service of reliable data transfer the presence of overhead in protocol data units 3

the importance of buffer memory the importance of timer The animation is a Windows program that runs in a window and offers to the user three basic menus (see Figure 1). In the 'OSI' menu, a user may choose any available animation scenario or exit the program. In the 'Options' menu, a user may modify the property of window resizing or animation speed (either in terms of computed frames per second or drawn frames per second). The remaining menus offer the usual animation controls 'Play', 'Pause' and 'Stop'. The basic picture is static and is also shown in Figure 1. It presents two OSI layers (layers 2 and 3), with the delimitation between them emphasised with a dashed red line, in two distant machines (station A and station B), each of them shown as a grey box. Each machine contains an entity (shown as a light blue box) in each layer. The two entities within the same machine can interact by means of primitives exchanged across the service acces point shown as a dark blue box. The two machines are connected by a channel (a thick black line) in the lower layer, through which protocol data units are to be exchanged. However, a virtual channel may also be imagined connecting the two entities of the upper layer, as indicated by a thin black line in our animation. The latter indicates an imaginary means to directly exchange user data. Primitives are graphically shown as yellow arrows directed either from the upper to the lower layer or vice versa (see Figure 2). A primitive is further described with the OSI-like syntax DL-Service.Primitive, where Primitive indicates the kind of primitive (Request, Indication or Confirm), Service indicates the service that is requested, indicated or confirmed (Establish, Data, or Release), and the prefix DL indicates that the service is provided by the Data-Link layer. User data are presented as a green box marked with the text DATA. They are generated and consumed within the upper layer, but are carried across the channel within the lower layer. Protocol Data Units (PDUs) are generated and consumed in the lower layer and are also shown as green boxes. If a PDU contains user data, the overhead is indicated as H (header) and T (trailer) and is of different colour as user data, otherwise the type of control PDU is indicated (SETUP, DISC or ACK). Timer is presented as a red column that, when running, empties from top towards bottom. The expired timer is shown as an empty column. Four different scenarios can be animated. The connection establishment and release scenarios are very similar and include SETUP/ACK and DISC/ACK, respectively, protocol data unit pairs and the use of timer. All the three primitives are used. The data transfer scenario begins with the DL-Data.Request primitive when the user data are copied across the service access point from the upper to the lower layer. Here, a copy of user data is memorized in case it would be damaged or lost during the PDU transfer. The header and trailer are added to form the PDU which then moves through the channel towards the peer entity. Concurrently, the timer is running. At the receiving end, the header and trailer are stripped away and user data are passed to the upper layer with the DL-Data.Indication primitive. The ACK acknowledgment is sent back towards the sending entity; after its reception, the timer is stopped. For the sake of illustration, we can see in Figure 3 the animation of user data transfer in the moment when the protocol data unit is being transferred through the lower-layer channel, with the timer in the transmitting entity running and a copy of the user message stored in the memory of the transmitting protocol entity. The data transfer with error scenario differs from the previous scenario in the fact that the PDU is damaged during the first transfer, which is indicated with the change of its colour from green to violet. No acknowledgment is sent, the timer expires and the PDU is sent once more. This time, everything goes well and the scenario is terminated like the previous one. The notion of the abstraction that is involved in our animation is twofold. Firstly, the abstraction is used in the presentation itself. All the components of the animated system are shown as abstractly as possible, including the messages themselves that are shown as simple boxes with only their types indicated. More importantly, we must emphasise (and the animation supports us in this) the abstraction that is inherently used in the OSI reference model and all the other protocol stacks. The upper layer is the user of the service provided by the lower layer and does not care about how this service is provided. The dashed red line prevents the upper layer entities to see what is going on in the lower layer. The only way both adjacent layers can interact is by means of primitives passed across the service acces points, and this interaction is strictly controlled. For instance, the upper layer entities do not see the lower layer overhead and do not bother it either. Or. when a protocol data unit is damaged in the lower layer, the upper layer knows nothing about it; it receives the user data only when they have been succesfully transferred from one machine to the other. CONCLUSIONS The use of very simple animations of communication processes that emphasise the basic methods used in communication protocols is advocated. Currently we use animation programs customly designed in one of high-level programming languages 4

by students as part of their final projects, which is an important pedagogic advantage of such a production of animations. However, we plan to use a common animation program shell in the future in order to unify the appearance of animations. Actually we use several animations besides the one described here, especially animations of some medium access control (MAC) algorithms. The animations can be used as standalone programs, or can be linked to a computer-based slide presentation or web pages. Currently, the author uses MS Power Point presentations during his lectures, where he includes an animation presentation from time to time. The students' response is positive. REFERENCES [1] Hercog, D., "Didactic Presentation of Wave Phenomena by Means of Computer Animations", in W. Aung et al., Eds, Engineering Education and Research-2001: A Chronicle of Worldwide Innovations, ineer, 2002, pp. 35-42 [2] ITU, "Specification and Description Language (SDL)", ITU-T Recommendation Z.100, International Telecommunication Union, 1999 [3] ITU, "Message Sequence Chart (MSC)", ITU-T Recommendation Z.120, International Telecommunication Union, 1999 [4] Turner, K. J., "Guest Editorial: Protocol animation", Computer Networks, Vol. 40, 2002, pp. 595-598 [5] Hercog, D., " A LAPB Protocol Computer-aided Learning Tool",, August 18-21, 2002, Manchester, UK [6] Combes, P., Dubois, F., Renard, B., "An open animation tool: application to telecommunication systems", Computer Networks, Vol. 40, 2002, pp. 599-620 [7] Braune, B., Wilhelm, R., "Focusing in Algorithm Explanation", IEEE Transactions on Visualisation and Computer Graphics, Vol. 6, No. 1, Jan. - March 2000, pp. 1-7 [8] Day, J., Zimmermann, H., "The OSI Reference Model", Proceedings of the IEEE, Vol. 71, No. 12, Dec. 1983, pp. 1334-1340 FIGURES AND TABLES FIGURE. 1 ANIMATION PROGRAM WINDOW. FIGURE. 2 A PRIMITIVE. 5

FIGURE. 3 A SAMPLE ANIMATION SCENARIO. 6