Chapter 3

CLAPDAWN: Comparative Study

In chapter 1 we had discussed available cross layer architectures in the literature and
their limitations. After going through the details of CLAPDAWN in chapter 2, in this

chapter we are comparing CLAPDAWN with the available cross layer architectures. Us-

ing available literature, we have identified a set of parameters based on which we have

performed comparative study of cross layer architectures. Section 3.1 shows the set of
evaluation parameters and section 3.2.1 covers the comparative study. Based on study

did in 3.2.1 we have highlighted limitations of CLAPDAWN in section 3.3.

3.1 Evaluation Metrics

By going through work done in literature we have identified a few metrics to evaluate the
performance of cross layer architectures. This section briefly explains each of the metrics.
Each architecture is evaluated considering following performance measures.

3.1.1 Multiple cross layer interaction, any layer to any layer

communication (A)

We check whether the architecture supports multiple cross layer interactions or not. In our
study, we have considered only those architectures which are designed to support multiple
cross layer interactions. In a cross layer interaction, a layer shares its information for

32
3.1 Evaluation Metrics 33

other layers or accesses the control mechanism of the other layers. In the case of multiple
cross layer interactions, next important point is whether all the layers can access the
information from all the other layers. In other words, whether the architectures supports
any layer to any layer communication.

3.1.2 Rapid development time (B)

Cross layer interaction introduces the secondary controls in the system. Cross layer archi-
tecture implements this additional control as a part of layer, adding horizontal or vertical
layer, or as separate component. Here, time required to implement cross layer interac-
tion depends on the support provided by the architecture. Based on adopted method,

different architecture takes different time to introduce cross layer interaction in the sys-

tem. By analyzing the process of how architecture introduces cross layer interactions in

the system, we have evaluated different architecture for their development time. Rapid
development time study highlights the complexity involved in the architecture.

3.1.3 Rollover from cross layer interaction (C)

During design time, protocol designer experiments with different cross layer interactions
for better performance. In networks like, wireless sensor networks and ad hoc networks,

the working environment and network protocol experience frequent changes. For such
dynamic networks, it requires that architecture must provide necessary support to such
experimentation. It is required that architecture provides support for smooth addition
and removal of cross layer interaction in the system. Rollover analysis is a study of how
easy it is to remove the existing cross layer interaction for the system.

3.1.4 Footprint on reference architecture (D)

Cross layer interactions are introduced to the system to improve the performance of the
system. In that process, how much modification is required to the referenced protocol or
layer is measured by the footprint of cross layer interaction on the reference architecture.
3.1 Evaluation Metrics 34

3.1.5 Feedback loop prevention (E)

Applications like video conferencing on vehicular ad hoc network requires multiple cross
layer interactions for the smooth functioning of the application. With the multiple cross
layer interactions it is likely that changes made by one layer triggers a sequence of changes,
that endup having a loop. Loop formed by such cross layer interactions is called a feedback
loop in the system. Feedback loops are critical measures of the cross layer architecture.
With the multiple cross layer interactions it is very likely that the system may face
feedback loops. It is the responsibility of the architecture to take care of such feedback
loops. Architectures are measured on the basis of their support provided to prevent

feedback loops from the system.

3.1.6 Conflicting cross layer interactions (F)

With the multiple cross layer interaction, it may happen that more than one cross layer

interaction is creating side effect on a common parameter. Cross layer interactions which
updates the same parameter are considered as conflicting cross layer interactions. If that

is the case then system experiences instability in its working. Here, we have analyzed

different architectures to see how they are handling possible conflicts occurring between
multiple cross layer interactions.

3.1.7 Time Overhead, space overhead and message overhead

(G-I)

Cross layer interactions are the secondary control added to the system. They require
information from other layer and they process this information for decision making. This
requires computation time, memory to store cross layer interaction and messages to bring
required information. Time overhead measures the additional time required to perform
the cross layer interaction that includes delay in bringing necessary information to the
cross layer interaction and processing time. Space overhead measures the additional
memory required to store the cross layer interaction code and parameters. Message
3.2 Comparative Study 35

overhead is a measure of the number of additional message exchange that take place
between various components of cross layer architecture.

3.1.8 Flexibility measure (J)

Cross layer interactions are dynamic in nature. With changing environment they require
some modification. Flexibility measure evaluates this process. It checks how easy it is

for the cross layer architecture to make necessary correction to adapt according to the
changing conditions like underlying protocol changes, change in cross layer interaction
itself or change of host operating system.

3.2 Comparative Study

In our study we have compared architectures covered in chapter 1 with CLAPDAWN.

For each performance measure the architecture is given points on the scale of 1 to 5.

Here point 5 shows high performance and point 1 shows the low performance for that

parameter. Performance parameters are as follows:

3.2.1 Multiple cross layer interaction, any layer to any layer

communication (A)

This section looks at the comparative study of different architectures considering whether
they provide support for multiple cross layer interactions or not. Mainly we have selected
only those architectures which provide support for multiple cross layer interactions. With
multiple cross layer interactions, our second objective is to check that is it possible to
have any layer to any layer communication in the architecture. This study sees that some
of the cross layer architectures like [28] which provide support for multiple cross layer

interactions do not provide possibility of any to any layer communication.

3.2 Comparative Study 36

Table 3.1: Multiple Cross Layer Interaction Support

Architecture Support for Multiple Cross Layer Interaction Points(A)
TinyCubus Various cross layer interactions are managed by Tiny 5
Cross Layer Framework. Cross Layer Framwork state
repository to implement multiple cross layer interactions
and any to any module communication.
MobileMAN Multiple cross layer interactions are implemented with 5
the help of additional layer referred as Network Status
Layer.
CL interaction Middleware is provided to support multiple cross layer 3
interactions. Main focus is on bottom up communication
only.
CrossTalk Provides local and global view to implement multiple 5
cross layer interactions.
ECLAIR Using Tuning layer and Optimizer agent it provides the 5
support for multiple cross layer interactions and any to
any layer communication.
CLAPDAWN Through separate control plane it provides the support 5
for multiple cross layer interactions and any layer to any
layer communication.

3.2.2 Rapid development time (B)

Table 3.2 provides the comparative analysis of rapid development time. They are ranked

on the basis of effort required to be put to make cross layer interaction part of the system.

Point 1 difficult to implement new cross layer interaction showing complex process and
Point 5 shows easy process of adding cross layer interaction in the system. It shows that

majority of the architectures implement the cross layer interaction in the layer itself.
That increases the development and debugging time of the cross layer interaction. Here
ECLAIR and CLAPDAWN implements the cross layer interaction outside the reference
architecture. That helps in reducing the development time. Further, CLAPDAWN uses
ECA rules in knowledge base that makes development process simpler than the ECLAIR.

3.2.3 Rollover from cross layer interaction(C)

Many experimental studies or protocol development require experimentation. In that

process they frequently go for rollover and restore the system in the previous state.
Table 3.3 shows the comparative study of rollover in different architectures. Because of
3.2 Comparative Study 37

Table 3.2: Rapid Development Time

Architecture Rapid Development Time Points(B)
TinyCubus Tiny Configuration Engine adds new cross layer inter- 2
action in the system. Cross Layer Interaction are im-
plemented using TinyOS callback mechanism. With
TinyOS callback it is difficult to wire new components
in the system
MobileMAN It consumes data provided by Network Status Layer and 3
cross layer code is implemented inside the layer itself.
CL interaction Cross layer interactions are implemented inside the layer 3
by modifying layer code.
CrossTalk Cross layer interactions are implemented inside the layer 3
and required information is provided by global and local
database
ECLAIR Cross layer interactions are implemented as separate op- 5
timizer agents independent of network protocol stack
CLAPDAWN Cross layer interaction are implemented inside the sepa- 5
rate control plane independent from the network protocol
stack

separation of cross layer interaction from the network protocol stack it becomes easy for

ECLAIR and CLAPDAWN to perform rollover in the system.

Table 3.3: Rollover from Cross Layer Interaction

Architecture Rollover from Cross Layer Interaction Points(C)
TinyCubus TinyCubus maintains wiring between the components 3
and uses data stored in the repository to implement cross
layer interaction. It is hard to recover from this wiring
between components.
MobileMAN Cross Layer Interaction code is implemented inside the 1
layer itself. Requires changes in the layer code itself.
CL interaction Cross Layer Interaction code is implemented inside the 1
layer itself. Requires changes in the layer code itself.
CrossTalk Cross Layer interactions are implemented inside the layer 1
itself. Requires changes in the layer code itself.
ECLAIR Cross Layer interactions are implemented as separate 4
agents configured with tuning layer. Removing them
from the system still triggers the development cycle.
CLAPDAWN Cross Layer interaction are implemented inside the sep- 5
arate control plane with the use of cross layer knowledge
base. Removal of rules from the knowledge base removes
the cross layer interaction from the system.
3.2 Comparative Study 38

3.2.4 Footprint on reference architecture(D)

To maintain stability in the system it is highly desirable that cross layer interaction
creates small footprint on the referenced architecture. Table 3.4 shows the comparative
study of cross layer architecture highlighting footprints on the layers. Those architectures,
which implement cross layer interactions inside the layer itself, have large footprint on
the layer compared to those, which implements cross layer interaction outside the layer.
In that regards ECLAIR and CLAPDAWN have small footprint compared to other ar-
chitectures. Here CLAPDAWN provides the standard interface that makes this process
smooth compared to other architectures.

Table 3.4: Footprint on Referenced Architecture

Architecture Footprint on referenced architecture Points(D)
TinyCubus Each cubus in TinyCubus is combination of applica- 3
tion parameter, Operating system parameter and opti-
mization parameter. Cross layer interactions modeled as
cubes and maintained by framework.
MobileMAN Changes Layer itself for cross layer implementation. Per- 2
sistent footprint on the layers.
CL Interaction Changes Layer itself for cross layer implementation. Per- 2
sistent footprint on the layers
CrossTalk Changes Layer itself for cross layer implementation. Per- 1
sistent footprint on the layers. Modifies the inter node
messaging structure to get the global view.
ECLAIR Cross layer interactions are implemented outside the 4
layer and only interfaces are created inside the layer to
get required information. Each information comes with
separate interface .
CLAPDAWN Cross layer interactions are implemented outside the 5
layer and only two interfaces are created inside the layer
for the input and output communication. Standard in-
terface makes footprint small and easy to manage.

3.2.5 Feedback loop prevention (E)

Table 3.5 shows the comparative study of possibility of feedback loop in the different cross
layer architectures. It shows that no cross layer architecture provides complete solution
to the feedback loop problem. Those architectures, which implement cross layer interac-
3.2 Comparative Study 39

tion inside the layer, they do not have the knowledge of other cross layer interactions in
the system. Here chances of feedback loops are high. In other cases architectures which
manage the information about the cross layer interaction like CL interaction and CLAP-
DAWN reduce the chances of feedback loops with the help of additional knowledge. But
still there are chances that parameters which are transparent to the cross layer interaction
may create feedback loops in the system.

Table 3.5: Prevention from feedback loop

Architecture Feedback loop prevention Points(E)
TinyCubus Configuration Engine using resource repository main- 2
tains information about the cross layer implementation
but with dynamic components it is hard to keep track of
feedback loop in the system
MobileMAN Cross Layer Interactions are implemented in the layer 1
itself and they use information provided by the network
status layers and the current layer. Network status layer
does not keep track of the information flow among the
layers.
CL Interaction Middleware layer is provided between the Network layer 4
and MAC layer that manages the different cross layer
interactions. That reduces the chance of feedback loop
in the system.
CrossTalk Cross Layer interaction implemented inside the layer 1
communicates using information provided by local and
global view layer. This distributed control flow increases
the chance of feedback loop in the system.
ECLAIR Cross layer interactions are implemented independent 2
from each other outside the layer as optimizing agent.
Distributed control increases the chance of feedback loop
CLAPDAWN Cross layer interactions are implemented inside the con- 4
trol plane with the help of cross layer knowledgebase and
cross layer engine. Available information of cross layer
interaction reduces the chance of feedback loop.

3.2.6 Conflicting cross layer interactions(F)

Conflicts are easy to locate in the system compared to feedback loops. Table 3.6 shows the
comparative study of different architectures considering whether they provide safeguards
against the possible conflicts among cross layer interactions. It shows that the archi-
tecture which manages the cross layer interaction information provides better protection
3.2 Comparative Study 40

against the conflict. Architectures which use central repository for cross layer interaction
information have not discussed conflicting scenario among cross layer interactions. These
architectures can be upgraded to provide conflict free cross layer interaction by using race
condition avoidance mechanisms. CLAPDAWN uses dependancy graph which helps it to
identify all possible conflicts occurring between different cross layer interactions.

Table 3.6: Preventions from conflicting cross layer interactions

Architecture Conflicting Cross Layer Interactions prevention Points(F)
mechanism
TinyCubus TinyCubus uses Callback mechanism of TinyOS and it 5
has limitation with reconfiguration and that limitation
makes it Conflict free.
MobileMAN Cross Layer Interactions are implemented in the layer it- 2
self and they consume the information provided by layers.
Network status layer does not have information about
different Cross layer interactions.
CL Interaction Middleware layer is provided between the Network layer 5
and MAC layer that manages the different cross layer
interaction. That reduces the chance of conflict among
the cross layer interactions.
CrossTalk Local and global view have no control over information 1
consumed and produced by the layers that increase the
chances of conflict in the system.
ECLAIR Separate tuning layer provides the required information 2
to each optimizer which updates them independently.
This distributed update process increases the chance of
conflict in the system
CLAPDAWN Cross layer knowledgebase maintains all the cross layer 5
interaction with the required input and output parame-
ter. Using dependency graph it manages all the possible
conflict in the system.

3.2.7 Time overhead

Table 3.7 shows the time overhead involved in different cross layer architectures. It
shows that architecture, which implements the cross layer interaction inside the layer, has
less time overhead compared to architecture which implements it outside. Architectures
like CL interaction implements cross layer interaction inside the layer but the required
information comes piggybacked inside the packet that adds additional delay to the overall
3.2 Comparative Study 41

processing.

Table 3.7: Time overhead in cross layer architecture

Architecture Time Overhead Points(G)
TinyCubus With dynamic modules, it requires additional time to 3
find the correct component associated with the repository
data.
MobileMAN Cross layer interaction implemented inside the layer, 4
takes information from network status layer.
CL Interaction It uses piggybacked mechanism to bring required infor- 2
mation to cross layer interaction from the middleware
that adds additional delay. Network layer queue may
increase this delay.
CrossTalk Cross layer interactions are implemented in layer itself 3
using information provided by local view layer and global
information. Local view is updated by direct interfaces
while global view is updated by information provided by
piggybacking, that adds additional delay.
ECLAIR Information is provided by tuning layer and each opti- 3
mizer works independently. It is implemented outside
the layer that increases delay.
CLAPDAWN Information provided by interfaces and processed by 2
cross layer engine. To increase the efficiency output pa-
rameters are mapped to specific engine. Processing is
done outside the layer and in sequence adds delay to the
system.

3.2.8 Space overhead

One of the important parameter is the space required to implement different cross layer
interactions. In networks like sensor networks, available memory space is less compared to
other networks. The table 3.8 shows the space required by different cross layer architec-
tures. It shows that all the architectures require additional space to maintain parameters
involved in cross layer interactions. For example, in ECLAIR, information exchange code
and local parameters are replicated in different optimizers. In the case of CLAPDAWN,
execution engine only keeps control over such replication.
3.2 Comparative Study 42

Table 3.8: Space overhead in cross layer architecture architecture

Architecture Space Overhead Points(H)
TinyCubus Configuration Engine, Topology Control Frame- 2
work and Data Management Framework requires
additional memory for each of the TinyCubus.
MobileMAN Network Status Layer maintains the required in- 4
formation.
CL Interaction Middleware layer manages information about all 2
the cross layer interaction and parameters, with
cross layer interaction implemented inside the
layer.
CrossTalk Cross Layer information is managed by local view 3
and global view. Cross layer interaction are im-
plemented inside the layer.
ECLAIR Cross layer information is provided by tuning 2
layer and interactions are implemented outside
the layer, which requires additional memory.
CLAPDAWN Cross layer information is provided by separate 3
layer and each cross layer interaction is stored as
ECA rule in knowledge base which requires mem-
ory.

3.2.9 Message overhead

Table 3.9 shows the comparative study of message overhead involved in cross layer in-

teraction. Those architectures, which use common database to store the cross layer
interaction and implement it inside the layer itself, do not have any messaging overhead.

The architecture which use the piggybacked mechanism to convey required information

to the cross layer interaction is free from the messaging overhead. The architecture,
which implements the cross layer interaction outside the layer, have messages overhead
proportional to the event frequency and the number of parameters involved in it.

3.2.10 Flexibility measure(J)

Flexibility measure is one of the important parameters involved in cross layer architecture
design. It is the responsibility of cross layer architecture to provide required mechanism
to adapt to changing environment as well as changing cross layer interactions.
3.2 Comparative Study 43

Table 3.9: Message overhead in cross layer architecture

Architecture Message Overhead Points(I)
TinyCubus Dynamic wiring between the components do not require 4
any messaging.
MobileMAN Messages required to get and put information to Network 3
Status layer.
CL Interaction Through piggybacking information forwarded to middle- 4
ware.
CrossTalk Using piggybacking information is provided to global 4
view and local view.
ECLAIR Cross layer interaction are implemented outside the net- 2
work stack . Additional messages required for each piece
of information exchanged between a) network protocol
stack and tuning layer, and b) tuning layer and optimiz-
ers.
CLAPDAWN Cross layer interactions are implemented outside the net- 3
work stack . Additional messages required for each piece
of information exchanged between Functional Plane and
Control Plane.

Table 3.10: Flexibility with Cross Layer Interactions

Architecture Flexibility Measure Points(J)
TinyCubus Due to underlying dependency of TinyOS, the architec- 3
ture does not have the flexibility of adjusting different
demands. Further, callback mechanism of TinyOS re-
stricts the scope of TinyCubus.
MobileMAN Each cross layer interaction implemented inside the layer, 1
takes information from network status layer. Any mod-
ification made to network status layer affects the all the
cross layer interactions.
CL Interaction Middleware layer manages all the cross layer interactions 4
implemented inside the layers.
CrossTalk Cross layer interaction are implemented inside the layer. 2
Modification made to the global view and local view trig-
gers update in the system.
ECLAIR Cross layer interactions are implemented as separate op- 4
timizer using tuning layer. System is flexible and adapt-
able to different changes in underlying protocol. Modifi-
cation to cross layer interaction is also transparent to the
rest of the system.
CLAPDAWN Cross layer interactions are implemented as separate con- 5
trol plane. System is flexible and adaptable to different
changes in the underlying protocol. Modification to cross
layer interaction is also transparent to the rest of the sys-
tem.
3.3 CLAPDAWN Limitations 44

3.2.11 Relative ranking

We have summarized the comparative study of cross layer architectures by defining the
rank for the cross layer architectures. Overall performance is calculated as average of
individual performance achieved by cross layer architectures for different parameters. To
decide the relative rank we have short listed our architectures based on their average value.
Following table shows the average performance with the rank. It shows the CLAPDAWN
has higher rank compared to other architectures.

Table 3.11: Comparative Study of different Architectures

Architecture A B C D E F G H I J Average Rank
CLAPDAWN 5 5 5 5 4 5 2 3 3 5 4.2 1
ECLAIR 5 5 4 4 2 2 3 2 2 4 3.3 2
TinyCubus 5 2 3 3 2 5 3 2 4 3 3.2 3
CL Interaction 3 3 1 2 4 5 2 2 4 4 3 4
MobileMAN 5 3 1 2 1 2 4 4 3 1 2.6 6
CrossTalk 5 3 1 1 1 1 3 3 4 2 2.4 5

3.3 CLAPDAWN Limitations

Above sections show the comparative study of different architectures with their relative

ranking information. Ranking is calculated based on the average performance achieved by

all the parameters. It shows that CLAPDAWN has higher rank than other architectures.

Though it has higher rank, architecture performs relatively low in some of the aspects
like memory overhead and running time overhead.
As all the cross layer interactions are implemented as ECA rules, it requires additional
memory to store those cross layer interactions. Further architecture also has to maintain
its parameters list that also requires additional memory. Here memory requirement is
proportional to the number of parameters involved in cross layer interaction and number
of rules affected by the give parameter. Further CLAPDAWN maps incoming and outgo-
ing parameters with the parameters involved in ECA rules that adds initial configuration
time.
3.4 Summary 45

CLAPDAWN uses single execution engine to execute the given rules that creates delay
in overall processing. This delay can be overcome by introducing more than one execution
engines. As ECA rules are independent from each other, set of rules can be mapped to
different execution engines to make execution faster.

3.4 Summary

In this chapter we have highlighted evaluation metrics for the cross layer architectures.
Based on identified metrics we have evaluated some of the well known cross layer ar-
chitectures available in literature. Their comparison shows that CLAPDWAN provides
better support for the cross layer interaction implementation than the others. Further

we have ranked these architectures based on their cumulative performance. Based on

these ranking we have selected ECLAIR with the CLAPDWAN and implemented it on

simulator to derive experimental results for better clarity and criticism.