Conference PaperPDF Available

Using UML for the Design of Communication Protocols: The TCP Case Study


Abstract and Figures

Project site: Object Technology has been widely adopted and UML has emerged as a generally accepted notation for software systems development. Software Engineers are already accustomed with the OO technology and a great number of CASE tools support them in the development process. However, protocol design is still based on traditional methodologies. In the context of this paper, we present an approach that utilizes object technology and the UML notation for the development of communication protocols. A methodology is presented and a number of extensions to the UML notation are proposed to address the peculiarities of protocol design. The construction of a TCP protocol for RTLinux was selected as an example to demonstrate the methodology. Design and implementation issues are presented and the resulting system is evaluated.
Content may be subject to copyright.
submitted to International Conference on Software, Telecommunications and Computer Networks, SoftCOM 2003
Using UML for the Design of Communication Protocols: The TCP case study
K. Thramboulidis, A. Mikroyannidis
Electrical & Computer Engineering Dept.
University of Patras, Greece
Abstract: Object Technology has been widely adopted and UML
has emerged as a generally accepted notation for software
systems development. Software Engineers are already
accustomed with the OO technology and a great number of
CASE tools support them in the development process. However,
protocol design is still based on traditional methodologies. In the
context of this paper, we present an approach that utilizes
object technology and the UML notation for the development of
communication protocols. A methodology is presented and a
number of extensions to the UML notation are proposed to
address the peculiarities of protocol design. The construction of
a TCP protocol for RTLinux was selected as an example to
demonstrate the methodology. Design and implementation
issues are presented and the resulting system is evaluated.
We have under development an Object-Oriented (OO)
framework to implement the IEC61499 proposed architecture
for open, interoperable and re-configurable distributed
control application [1]. For the implementation of the
CORFU interworking unit we selected RTLinux and we
defined a modular architecture to satisfy the real-time
constrains imposed by this kind of applications. The
Industrial Process Control Protocol (IPCP) has been defined
to satisfy real-time and non real-time requirements [2]. TCP
functionality was required for the IPCP to support
commissioning, configuration and on-line re-configuration
of the control application. However, a TCP/IP protocol stack
for RTLinux was not available. The only one found was the
RTNet protocol stack [3]. RTNet provides direct access to
IP-based networking from RTLinux real-time code. It
implements the IP, ARP, UDP, and ICMP protocols over
Ethernet. It also provides a sockets implementation for use by
real-time tasks. The RTNet implementation is based on the
standard Linux networking source code, with the necessary
changes to make it real-time.
In [4] we have used RTNet to implement a prototype for
the interconnection of a Profibus fieldbus with a Lonworks
fieldbus. To satisfy the requirement for TCP functionality a
first draft implementation of TCP, based on TCP Lean [5]
was given, embedding it in the RTNet module. To provide a
more robust, modular, expandable and layered protocol stack,
we decided to redesign the TCP layer. A survey on previous
works that consider the use of object-orientation and UML in
the protocol design was carried out. The main directions in
protocol design are briefly presented in section 2. Having
applied the OO approach and the UML notation successfully
in many application domains, we decided to proceed to this
direction. We adapted our development methodology to
address the peculiarities of protocol design. The resulting
methodology, that can be applied for the design of
communication protocols is presented in section 3. The
design of a TCP layer for RTLinux is presented and
implementation details are discussed in section 4. Finally, the
proposed approach is discussed with more emphasis on
performance evaluation and the paper is concluded.
Current industrial practices in communication protocol
design and implementation are unsatisfactory. There is a gap
between state-of-the-art Software Engineering and the way
communication protocols are designed and implemented. The
development of communication protocols is still mainly
based on the traditional procedural paradigm. The
methodologies used to construct protocols can be grouped in
3 categories. According to the first category that follows the
functional approach, a protocol is developed with a
functional design method and a functional language that is
mainly C. Although this approach results in efficient
implementations, reusability and flexibility are rather poor.
The second category uses a formal description technique to
create the protocol’s specification, which is then translated
into program code. SDL [6], Estell [7] and Lotos [8] are the
most important specifications used, with SDL being the most
widely adopted. Reusability in code but also in design time is
also limited in this case. The third category, which is
continuously gaining ground, includes methodologies that
have adopted the OO approach. This approach results in
implementations that exhibit increased modularity,
flexibility, extensibility and reusability. Successful results
have been reported by researchers applying methodologies of
this category. Traditional tools have been expanded to exploit
the benefits of the OO approach. Conduits+ [9] is one of
UML that is the standardized notation for OO, lacks
many of the semantics needed for protocol engineering.
Towards this direction is the work of Parssinen et al. [10],
who have developed an extension of UML, the Graphical
Protocol Description Language (GPDL). They have also
developed an environment aiming to translate the GPDL
models into SDL models. Several researchers have also
submitted to International Conference on Software, Telecommunications and Computer Networks, SoftCOM 2003
reported their results on enhancing the OO approach,
utilizing features of other methodologies. Hanish and Dillon
for example have showed how a high-level Petri Net can be
mapped into an OO model for use with protocol design [11].
King and Pooley have used UML to generate Petri Net
models for performance prediction in a communication
network [12].
For the development of the TCP protocol stack we decided to
utilize our already successfully applied methodology in other
application domains. However, the methodology was tailored
to satisfy the peculiarities of protocol design. Furthermore,
some extensions to the UML notation are proposed to better
handle the communication and synchronization requirements
in the protocol development domain. In this section, we
briefly refer to the outline of the applied methodology giving
emphasis on the modifications imposed by the nature of
protocol software.
For the development of the analysis model the use case
driven approach of Ivar Jacobson was adopted to delimit the
system and define its functionality. Two types of models
mainly constitute the analysis model of the system. The use
case model and the problem domain logical view. For the use
case model to be constructed, the actors that represent the
roles that the software entities, which interact with the
protocol play, are first identified. Each actor may perform a
number of use cases. The use case, according to Jacobson,
“constitutes a complete course of events initiated by an actor
and specifies the interaction that takes place between the
actor and the system”. In order to increase reusability from
this early phase, we developed a use case diagram that
captures associations between the use cases. These
associations may be: adds and extends according to Jacobson
or simply uses according to Rumbaugh. For the description
of each use case the format proposed by Rumbaugh was
adopted. However, we consider each use case in at least two
levels of abstraction. The first-level description considers the
interaction of the system as a whole with the entities of its
environment. A more formal representation of this
description is obtained using a corresponding first-level
Object-Interaction Diagram (OID) [13]. In this first-level
OID the protocol under development is represented as an
entity and its interactions with external systems are captured.
Fig. 1 illustrates the first level OID for the “active open” use
case of the TCP protocol that was considered as case study in
the context of this work.
This first-level OID is next expanded to a lower level
OID, which we call detailed-OID. The objects that are
required to compose the system for the described behavior to
be provided should be identified and their collaboration
defined. Coupling and cohesion are among the parameters
that help the designer to identify these objects but
unfortunately there are no well-defined rules to proceed. The
designer’s skills are at the moment the most important
parameter for an effective design to be achieved. However,
the proper definition of specific design patterns from the
protocol domain should increase productivity in the design of
communication protocols and speed up the development
process. We are currently working to this direction. Fig. 2
depicts the detailed OID of the “active open” use case. A
detail reference to this OID is given in the section that deals
with the TCP case study.
Figure 1 - First level OID of the “active open” use case.
The problem domain model is composed of class diagrams
that capture the key objects of the problem domain and
constitute the logical view of the system. It is composed of
objects that represent entities or concepts from the problem
domain for which the system should handle information.
These objects are usually used in the construction of system’s
OIDs. However, a data driven approach results in the
construction of the problem domain model before the use
case model. A hybrid approach that involves the construction
of the use case model in parallel with the construction of the
problem domain model seems to be the best choice.
Figure 2 - Detailed OID of the “active open” use case.
To proceed with the design of the system, we refine each
OID to evolve to an OID that can be implemented with the
selected implementation environment. During analysis, every
object of the system is considered as active. However, this is
not possible for the implementation. Concurrency and
submitted to International Conference on Software, Telecommunications and Computer Networks, SoftCOM 2003
synchronization must be considered and the communication
and synchronization mechanisms provided by the
implementation environment should be properly utilized for
an optimum implementation to be accomplished.
Nevertheless, the UML standard does not provide the
required constructs to capture these design issues. The
mechanisms used in activity diagrams can not be used, since
they refer to single thread executions, which at some point
can fork and join, having only one initial and final state. In
contrast, our aim is to show the synchronization between
active objects that interact in the context of a use case. Moore
and McLaughlin have proposed a concurrency or tasking
diagram, which has been based on the collaboration
diagram[14][15]. This diagram depicts the tasks and the way
they interact through various mechanisms (i.e. fifos,
mailboxes). These concepts are not applicable to the OIDs,
so we proposed the following extensions to the UML
notation to capture these semantics:
a) Concurrency. In order to be able to represent in an OID
more than one thread of control, we have introduced the
dashed line notation in the body of an object. When a thread
of control is suspended or blocked, its body lines are
converted to dashed. Automatic conversion can be obtained
based on the semantics of the posted and received messages.
To simplify the diagram, we decided to allow a passive
object to be shown in the OID more than once. The con
object for example in fig. 3 is executed by both threads i.e.
the Client instance thread and the InputSegmentHandler
instance thread. This can not be shown with the standard
UML notation.
b) Synchronization. Operations with special semantics like
set-timer(), wake-up(), wait() and notify() are defined and
used to support synchronization between threads of
In fig. 3, which presents a detailed level OID of the
“active open” use case of TCP, the above extensions are used
to introduce concurrency and synchronization into the OID.
Figure 3 - Design level OID of the “active open” use case.
Three active objects have been shown: the Client instance,
the IP instance and the InputSegmentHandler that represents
the TCP’s input thread. The arrival of a segment is passed as
an asynchronous message from IP to InputSegmentHandler.
Synchronization between the Client and
InputSegmentHandler threads is obtained using an instance
of Timer. The client thread which sets it, is suspended
(dashed lines) until a stop signal arrives, or there is a timeout.
The suspended thread is then woken-up and returns to normal
The Rational Rose general-purpose CASE tool [16] was used
for the design of the TCP protocol for RTLinux. The use case
model is presented in fig. 4. Each use case was described and
a first-level OID and at least one detail-OID was constructed
for it.
Figure 4 - The use case diagram of TCP.
Fig. 2 shows the detailed OID of the “active open” use
case. We can discriminate the ConnectionHandler object that
is responsible for managing the connection objects. Its
responsibility includes reserving and releasing a connection
object, as well as finding an existing connection object with
specific characteristics.
The problem domain class diagram was constructed in
parallel with the construction of detailed OIDs. Fig. 5 shows
a part of the class diagram of TCP. The Connection class
that is the heart of the class diagram has as data members all
the information that in traditional TCP implementations is
stored in a TCB. Method specifications are given according
to the instance responsibilities. Method takeSegment for
example, processes the incoming from IP segments; it checks
the segment’s sequence number, acknowledgement number,
flags, then copies any data to the connection’s input buffer
and, if needed, an ACK segment is sent back. The class
diagram will form the basis for the system’s implementation.
It should be refined to produce the design class diagram.
There are two active objects: one for handling incoming from
IP segments and one for managing the transmission of
segments. Actors are of course other active objects.
The output thread receives messages, through an rtfifo,
from the application’s thread in order to send data or close a
submitted to International Conference on Software, Telecommunications and Computer Networks, SoftCOM 2003
connection, thus making these methods non-blocking for the
For the implementation of our TCP layer, C++ was
selected. The language is object-oriented and compilers to
produce code that can be easily imported into the RTLinux
kernel are available. Some programmers are wary about
using C++ in the RTLinux kernel. However, even though our
code utilizes many of the RTLinux’s constructs and
mechanisms, like threads, mutexes, real time fifos, we have
never experienced any problems due to lack of compatibility
between our C++ modules and RTLinux kernel. Version 3.1
of the kernel was used for the development.
Figure 5 - Analysis class diagram of TCP (partial).
Thread communication was implemented by real time
fifos (rtfifos). For the protection of shared resources we have
used mutexes (type pthread_mutex_t). All Connection
instances are created when the TCP module is loaded into the
kernel. Dynamic allocation is not supported. The operator
new and the malloc() function are allowed to be used in the
RTLinux kernel only in the initialization of a module
(function init_module()), since they do not satisfy real-
time constraints. All mutexes and rtfifos must also be
initialized (functions pthread_mutex_init() and
rtf_create()) by the init_module()function.
A mutex is used to protect the table of Connections. Each
Connection object also has two mutexes: one for protecting
its data members associated with incoming data (i.e. input
buffer, input window) and a second one for the data members
that have to do with output activity (i.e. output buffer, output
window). The output buffer is a FITO (First In Trial Out)
buffer that we created based on [5], in order to handle partial
acknowledgements (ACKs) and retransmissions when
sending data.
One serious problem was that the C++ code of our TCP
could not be compiled when we included several Linux
header files, i.e. <linux/skbuff.h>. These headers are
used by RTNet and define fundamental structs, like skbuf,
which is a buffer used by Linux to store the contents of a
datagram [17]. In order to overcome this, we created a
separate module, written in C, to handle the interconnection
with RTNet. In this way, our C++ module, named ootcp.o
(Object-Oriented TCP), was isolated from RTNet and
communicated only with the C module, rt_interface.o. Fig. 6
illustrates the architecture we adopted.
Figure 6 - TCP’s interface with IP
The rt_interface module communicates with RTNet
directly through function calls. When rt_interface is loaded,
it registers one of its functions to RTNet in order for RTNet
to call this function every time a TPDU arrives. When this
function is called, rt_interface passes a pointer to the TPDU
to ootcp through an rtfifo. This fifo has been registered to
rt_interface by ootcp, when the latter is loaded. An rtfifo
handler is used to wake up the ootcp’s thread every time
rt_interface writes into the fifo.
When ootcp has finished processing a received TPDU,
the skbuf containing it has to be released in order to be
reused. This is done by rt_interface, since ootcp can access
only the skbuf’s data, that is the TPDU. Finally, upon
sending a TPDU, the corresponding function of RTNet is
called through rt_interface.
Our OO methodology was tailored to the specific
requirements of the protocol software and some extensions to
the UML notation were proposed. The development of a
protocol using the OO approach was successful. The
resulting protocol implementation is easy to be understood;
the detailed design diagrams mask the time consuming, low
level implementation details. It is also expandable; new
functionality was added first in the design models and it is
then translated to code. However the most important factor
was for us the performance of the resulting protocol. This is
why we created a testbed in order to measure, under certain
conditions, the performance of the developed protocol stack,
i.e., our TCP (OOTCP) along with RTNet. We also repeated
the performance measurements for Linux’s TCP/IP, using
them as a yardstick. It must be clarified that our TCP has not
been optimized for best performance, consequently the main
Register input fifo
Register receiver function
Receive TPDUs
Receive TPDUs
skbuf Send TPDUs
Send TPDUs
submitted to International Conference on Software, Telecommunications and Computer Networks, SoftCOM 2003
motivation of this evaluation was to verify the smooth
operation of our protocol stack under heavy load.
The performance evaluation of a protocol stack involves
measuring several parameters. Zanella et al [18] for the
performance evaluation of TCP Westwood and Reno used
simulations as well as the application of the implementations’
analytical models. They measured the TCP’s throughput with
respect to variations of the error probability, buffer size,
bandwidth and round trip time (RTT). Perkins and Hughes
[19] have investigated the performance of TCP in mobile ad
hoc networks (MANETs) by evaluating the impact of path
length, node mobility and routing on the throughput of TCP.
Pentikousis [20] has tested TCP Tahoe, Reno and NewReno
under random and burst errors as well as combinations of
these two categories. He simulated these errors during the
transfer of a 5MB file between two hosts over a 10Mbps
network and measured the delays inserted.
Since our protocol stack was implemented for a real-time
OS, our performance tests were focused on error-less, real-
time communications. The tests were conducted between two
dedicated hosts, connected by crossed ethernet cable
providing a speed of 100Mbps. The server application was
running on Windows. On the other host was running the
client application for our TCP and Linux. Once the client
established a connection with the server, it received a 5MB
file, stored it locally and sent it back. The results are given in
Table 1.
Table 1 - Performance evaluation results
Bytes received 5242900 5242900
Receiving time (sec) 1.181 1.201
Bytes sent 5242900 5242900
Sending time (sec) 0.821 0.882
TCP throughput (Mbps) 51 47.5
Total time (sec) 2.002 2.083
The receiving and sending time is the time taken for each
protocol stack to receive and send the file respectively. The
TCP throughput [21] is calculated as:
BytesSent * 8 / Sending time
It can be seen that the results are almost identical for both
stacks, even though an overhead was expected from the OO
In this paper, a methodology to facilitate the development of
communication protocols was presented. This methodology
is a tailoring of our methodology that we have used
successfully for many years in many application domains.
The methodology exploits the Object-Oriented approach and
the widely accepted UML notation. In our attempt to address
the design issues of protocol engineering, a number of
extensions to the UML notation were proposed. The
methodology was utilized for the development of a TCP
protocol stack for the RTLinux Real-time Operating System.
The experiment was successful. The resulting
implementation not only has enhanced readability,
modularity, and expandability but also presents performance
characteristics comparable with those of the corresponding
protocol stack of Linux, even though no extra optimization
techniques were used to enhance performance.
[1] K. Thramboulidis, C. Tranoris, “Developing a CASE tool for
Distributed Control Applications", The International Journal of
Advanced Manufacturing Technology, Springer-Verlag
[2] Thramboulidis, K. “Development of Distributed Industrial Control
Applications: The CORFU Framework”, 4th IEEE International
Workshop on Factory Communication Systems, Sweden, August
[3] Lineo's OpenSource Development Repository Project Page,
[4] K. Thramboulidis, P. Parthimos, G. Doukas, “Using RTLinux to
Interconnect Field Buses: The Profibus Case Study”, International
Conference on Manufacturing Engineering (ICMEN), October 2002,
[5] Jeremy Bentham, “TCP/IP Lean, Web Servers for Embedded Systems”,
CMP books 2000.
[6] Jan Ellsberger et al, “SDL: Formal Object-Oriented Language for
Communicating Systems”, Prentice Hall 1997.
[7] ISO-IEC/JTC1/CS21/WG1/FDT/B, Estelle, ISO International Standard
IS8807, July 1989.
[8] ISO-IEC/JTC1/CS21/WG1/FDT/B, Lotos, ISO International Standard
IS8807, February 1989.
[9] H. Huni, R. Johnson, R. Engel, “A Framework for Network Protocol
Software”, ACM 1995.
[10] J. Pärssinen, N. Knorring, J. Heinonen, M. Turunen, “UML for
Protocol Engineering – Extensions and Experiences”, Technology of
Object-Oriented Languages and Systems (TOOLS 33), June 05 - 08,
2000 , St. Malo, France.
[11] A. Hanish, T. Dillon, “Communication protocol design to facilitate re-
use based on the object-oriented paradigm”, Mobile Networks and
Applications, Volume 2 Issue 3, December 1997, pp 285-301.
[12] Peter King, Rob Pooley, “Derivation of Petri Net Performance Models
from UML Specifications of Communications Software”, Computer
Performance Evaluation: Modelling Techniques and Tools, 11th
International Conference, TOOLS 2000, Schaumburg, IL, USA,
March 27-31, 2000.
[13] Thrampoulidis, K. K. Agavanakis, “Introducing Object Interaction
Diagrams: A technique for A&D”, Journal of Object-Oriented
Programming (JOOP) June 1995.
[14] Alan Moore, “Extending UML to Real-Time Systems”, Embedded
Developers Journal, March 2001.
[15] Michael J. McLaughlin, Alan Moore, “Real-Time Extensions to UML”,
Dr. Dobb's Journal December 1998.
[16] Rational home page,
[17] Jon Crowcroft, Iain Philips, “TCP/IP and Linux protocol
implementation”, John Willey, 2002.
[18] A. Zanella, G. Procissi, M. Gerla, M. Sanadidi, “TCP Westwood:
Analytic Model and Performance Evaluation”, Globecom 2001, San
Antonio, Texas, November, 2001.
[19] D. Perkins, H. Hughes, “Investigating the performance of TCP in
mobile ad hoc networks”, Computer Communications, Volume 25,
Issues 11-12, 1 July 2002, Pages 1132-1139.
[20] K. Pentikousis, “Error Modeling for TCP Performance Evaluation”,
Master’s Thesis, State Univ. of New York, May 2000.
[21] L. Peterson, B. Davie “Computer Networks”, 2nd edition, Morgan-
Kaufmann, 2000.
... UML is the most widespread software modeling language, it can be applied to the design modeling of any type of software project, and it is the standard language adopted by industry for modeling the design of object-oriented systems [22]. The UML state machine (previously referenced as a statechart) has widely been used to describe the service and protocol specifications for communication systems (e.g., [23,24,25,26,27,28,29,30,31,32,33]). ...
... Allowing for nested hierarchical states is a feature that is neither supported by Petri Nets nor by conventional finite state machines, which makes the synthesis methods based on these two models inapplicable for service specifications that include hierarchical states. Autonomous communication systems, such as the Internet and mobile communication systems, are currently widely used (e.g., [24,29,32]). In such systems, a user can initiate a service at any time. ...
... UML has been shown to be useful in model-ing communication protocols (e.g., [27,28,32]). ...
Full-text available
The object-oriented paradigm is widely applied in designing and implementing communication systems. Unified Modeling Language (UML) is a standard language used to model the design of object-oriented systems. A protocol state machine is a UML adopted diagram that is widely used in designing communication protocols. It has two key attractive advantages over traditional finite state machines: modeling concurrency and modeling nested hierarchical states. In a distributed communication system, each entity of the system has its own protocol that defines when and how the entity exchanges messages with other communicating entities in the system. The order of the exchanged messages must conform to the overall service specifications of the system. In object-oriented systems, both the service and the protocol specifications are modeled in UML protocol state machines. Protocol specification synthesis methods have to be applied to automatically derive the protocol specification from the service specification. Otherwise, a time-consuming process of design, analysis, and error detection and correction has to be applied iteratively until the design of the protocol becomes error-free and consistent with the service specification. Several synthesis methods are proposed in the literature for models other than UML protocol state machines, and therefore, because of the unique features of the protocol state machines, these methods are inapplicable to services modeled in UML protocol state machines. In this paper, we propose a synthesis method that automatically synthesizes the protocol specification of distributed protocol entities from the service specification, given that both types of specifications are modeled in UML protocol state machines. Our method is based on the latest UML version (UML2.3), and it is proven to synthesize protocol specifications that are syntactically and semantically correct. As an example application, the synthesis method is used to derive the protocol specification of the H.323 standard used in Internet calls.
... UML has been shown to be useful in modelling communication protocols (e.g., [7,8,9]). In [4], a synthesis method that derives protocol specifications from UML-based service specification has been introduced. ...
... This extension makes the synthesis method applicable for real time applications. The extension uses UML state machine for modeling both 9 the service and protocol specifications. In this paper, the assignment of the timing constraints to the service specification is discussed. ...
Full-text available
Synthesizing specifications for real time applications that involve distributed communication protocol entities from a service specification, which is modeled in the UML state machine with composite states, is a time-consuming and labor-intensive task. Existing synthesis techniques for UML-based service specifications do not account for timing constrains and, therefore, cannot be used in real time applications for which the timing constraints are crucial and must be considered. In this paper, we address the problem of time assignment to the events defined in the service specification modeled in UML state machine. In addition, we show how to extend a technique that automatically synthesizes UML-based protocol specifications from a service specification to consider the timing constraints given in the service specification. The resulting synthesized protocol is guaranteed to conform to the timing constraints given in the service specification.
... SysML [23], Developing communication protocol is a special type of software development, which is a critical, complex and real time software. There is a gap between the art of software engineering and the practice of developing communication protocols [14]. Communication protocols usually developed using C language because of its time performance and fast execution time, which make it a good choice for developing communication protocols and embedded systems [5]. ...
... SDL [8], Estell [12] and Lotos [11] are examples of formal description languages used for this problem. Since SDL is the most widely adopted language, there is no reusability [14] in the design phase and very limited in the implementation phase. Adams Dunkels presented two proposal based on the first approach for this problem which called UIP [1] and IwIP [18]. ...
Full-text available
The use of embedded software is growing very rapidly. Accessing the internet is a necessary service which has large range of applications in many fields. The Internet is based on TCP/IP which is a very important stack. Although TCP/IP is very important there is not a software engineering model describing it. The common method in modeling and describing TCP/IP is RFCs which is not sufficient for software engineer and developers. Therefore there is a need for software engineering approach to help engineers and developers to customize their own web based applications for embedded systems. This research presents a model based system engineering approach of lightweight TCP/IP. The model contains the necessary phases for developing a lightweight TCP/IP for embedded systems. The proposed model is based on SysML as a model based system engineering language.
... Communication protocol design process is a special type of software design processes which requires a fast runtime execution and a flexible modeling technique [25]. The methodologies used for the development of protocols can be grouped in three categories [13] : ...
Full-text available
Embedded systems are usually suffering from limited resources which require a modified architecture of software to take the best usage of the resources. TCP/IP is the most important communication protocol for networked embedded systems which provide internet connectivity for hosts. Many of TCP/IP development for embedded systems lack system modeling, analysis and design. This paper presents a proposed lightweight TCP/IP architecture which consists of TCP/IP kernel, memory management, multi-threading and socket support to fit limited hardware resources devices. SysML is a general purpose modeling language is used to model the lightweight TCP/IP. The proposed SysML model discusses full functional analysis, design and requirement of the proposed architecture.
Conference Paper
In real time applications, the time required to execute the events can be crucial and must be considered. However, the existing technique for synthesizing computer communication protocol specifications from UML-based service specification does not account for timing constraints and, therefore, cannot be used in real time applications. In this paper, we address the problem of time assignment to the events defined in the service specification. In addition, we show how to extend a technique that automatically synthesizes protocol specifications from a service specification to consider the timing constraints given in the service specification. Both the service and protocol specifications are modeled using a UML state machine.
Conference Paper
Due to new emerging areas in the communication field there is a constant need for the design of novel communication protocols. This demands techniques for a rapid and efficient protocol design and development. Systematic protocol designs using formal description techniques (FDTs), such as SDL, LOTOS, etc., have proven a successful way to develop correct protocols. FDTs enforce, however, a semantic-oriented description which makes it difficult to reuse parts of the specification of other FDTs. A general-purpose modeling language like the UML may help to easily bridge between different description techniques. In contrast to the standardized FDTs, UML lacks a formal semantics. A model-driven protocol design, which aims at supporting the reuse of designs, makes only sense, when the designs of basic protocol mechanisms fit in reusable design patterns or components with a formally defined semantics. In this paper, we propose a component based protocol development approach with UML. Typical structures and behaviors of protocols are pre-defined as components using UML diagrams. The semantics of the UML diagrams is formally defined using the compositional Temporal Logic of Actions (cTLA). Based on this formalization, transformation into other presentations, e.g. Promela for verification, are supported. We demonstrate the approach for an example transfer protocol.
Full-text available
Many different proprietary field buses supporting different standards have been installed in industry in different time periods under different circumstances. Working in the domain of distributed control applications we have defined the CORFU framework to address the interoperability issue and facilitate the development of distributed control applications. In this paper, a prototype implementation of the CORFU Interworking Unit using Real-Time Linux is presented. The Profibus was adopted as a case study and a wrapper was developed to abstract it to the IEC 61499 compliant Virtual Field Bus. The Rtnet, an RTLinux protocol stack was adopted and extended to provide TCP connectivity to fulfil the requirements imposed by the configuration management of field buses.
Conference Paper
Full-text available
Today's control applications are either based on traditional distributed control systems or on programmable logic controllers. They are usually composed of monolithic applications that are almost impossible to integrate and even to expand. Even more, the many different types of commercial fieldbuses resulted in a wide diversity of devices and tools to support the development of Industrial Process Measurement and Control Systems (IPMCSs). The demand for integration, both during the development phase as well as during the operational phase is becoming more than evident. In this paper, we present CORFU, an OO framework to improve the engineering process of JPMCSs in terms of reliability, development time and degree of automation. The defined framework embodies an abstract design that is capable to provide solutions for the family of distributed JPMCSs.
Conference Paper
Full-text available
We present a performance model of TCP Westwood (TCPW), a new TCP protocol with a sender-side modification of the window congestion control scheme. TCP Westwood controls the window using end-to-end connection bandwidth share estimation, obtained by monitoring the ACK reception rate. An analytic model using Markov Chain techniques is developed in this paper, and then used to assess the performance improvements obtained using TCPW. The model takes into account the estimation and filtering method used in TCPW, as well as the following system parameters, bottleneck link bandwidth, buffer space at the bottleneck router, end-to-end propagation time, and error rate. The model reveals substantial TCPW gains over Reno whenever losses due to link or other errors are taken into consideration. The analytic model accuracy is confirmed by comparing to simulation results
Boasting high performance, high availability, and open source code, Linux has emerged as an optimal choice for an operating system. Yet for Linux to be adopted by the mainstream of Unix-based corporate and ISP networks, it must be capable of supporting the TCP/IP Internet protocol, like any other network operating system. This book provides the rapidly growing audience of Linux site managers, as well as researchers and developers worldwide, with the information they need on how Linux TCP/IP keeps the network running. The authors walk readers through the Linux TCP/IP protocol stack, offering detailed explanations on how Linux implements its communications protocols.
The main motivation for the present work stems from the wide gap which exists between the research efforts devoted to developing formal descriptions for communication protocols and the effective development methodologies used in industrial implementations. We apply Object-Oriented (OO) modelling principles to networking protocols, exploring the potential for producing re-useable software modules by discovering the underlying generic class structures and behaviour. Petri Nets (PNs) are used to derive re-useable model elements and a slightly modified TTCN notation is used for message sequence encoding. This demonstrates a formal, practical approach to the development of a protocol implementation through OO modelling. Our utilisation of PNs in the context of object based modelling allows for isolation of the behavioural characterisation of objects into a separate design plane, treated as a meta-level object control. This separation permits greater execution flexibility of the underlying object models. It is that very aspect of our modelling approach which can be utilised in software implementations where dynamically determined ‘re-programming’ (i.e., change of procedures) is needed. For example, one of the requirements in wireless networking software is the ability to cope with ever-changing transmission/reception conditions and that, in turn, creates greatly varying error rates. Similarly, handoff procedures create situations where dynamically determined change of operational modes is required. To illustrate the modelling concepts, the paper addresses the problem of inter-layer communication among multiple protocol entities (PEs), assuming the standard ISO/OSI Reference Model. A generalised model called the Inter-Layer Communication (ILC) Model is proposed. An example of a PE based on the Alternating-Bit Protocol (ABP) is also discussed. The final example demonstrates how meta-level object control (PNs) allows for the dynamic selection of different ARQ based algorithms.
Mobile ad hoc networks have several inherent characteristics (e.g. dynamic topology, time-varying and bandwidth constrained wireless channels, multi-hop routing, and distributed control and management). The goal of this work is to investigate the impact of these characteristics on the performance of TCP. First, we investigate throughput performance of TCP as a function of path length (i.e. multiple wireless hops), node mobility, and traffic intensity. Next, we examine the ‘fairness’ of the ad hoc network with regard to equal sharing of network bandwidth among multiple TCP flows. Third, we evaluate the impact of two on-demand routing protocols (i.e. AODV and DSR) on the throughput of TCP. Finally, a factorial design experiment is conducted to quantify the effects and interactions of three factors, which influence the throughput of TCP. These factors include routing, node speed, and node pause time. Two key results were observed. Results show that traffic intensity (e.g. number of concurrent flows) is significantly affects TCP throughput, suggesting the need for congestion control, scheduling and traffic management schemes. Second, source routing achieves higher throughputs while also generating significantly less routing overhead than AODV. Results also show that in some instances, the fairness of the network is very uneven among concurrent TCP flows, resulting in several sending stations achieving very little or no throughput.
Mobile ad hoc networks (MANETs) have become increasingly important in view of their promise of ubiquitous connectivity beyond traditional fixed infrastructure networks. Such networks, consisting of potentially highly mobile nodes, have provided new challenges by introducing special considerations stemming from the unique characteristics of the wireless medium and the dynamic nature of the network topology. The TCP protocol, which has been widely deployed on a multitude of internetworks including the Internet, is naturally viewed as the de facto reliable transport protocol for use in MANETs. However, assumptions made at TCP’s inception reflected characteristics of the prevalent wired infrastructure of networks at the time and could subsequently lead to sub-optimal performance when used in wireless ad hoc environments. The basic presupposition underlying TCP congestion control is that packet losses are pre-dominantly an indication of congestion in the network. The detrimental effect of such an as-sumption on TCP’s performance in MANET environments has been a long-standing research problem. Hence, previous work has focused on addressing the ambiguity behind the cause of
Conference Paper
This paper presents a Unified Modeling Language profile for describing communications protocols. UML is a popular standardized, general-purpose visual language, but the current version lacks formal action semantics which is needed to define any complicated communications system. It is also difficult to generate an efficient protocol specific implementation from standard UML notation only. The authors developed a Graphical Protocol Description Language, a UML profile, to fulfil the needs of protocol engineering, UML stereotypes are used to add protocol-specific semantic information to class diagrams, enabling code generation for protocol implementations. GPDL contains graphical elements and a textual language that is used to describe actions in statechart transitions called the Generic Action Extension Language. A system described with GPDL can be converted to an implementation for any protocol framework. As an example a chain of tools which performs a translation from GPDL to SDL was developed by the authors