basic question toCommunicationModule?

[seham salah]

Hello,
I am new in both omnet and Castalia :( I installed Castalia and read
the manual. Almost everything seems fine so far except some commands,
may be these commands are related to omnet knowledge.
Here is the statements that I do not understand :

1- sendDelayed(new App_ControlMessage("Application --> Network
[STARTUP]", APP_NODE_STARTUP), simTime() , "toCommunicationModule");

As it is explained in the code this just a startup message to MAC, but
which MAC and how Castalia call it? "toCommunicationModule"??

2- same question when we send a message to the MAC:

send(packet2Net, "toCommunicationModule");
What castalis do in this case, where is this module located and does
this send is an omnet function.
could you please explain the toCommunicationModule parameter ?

Hope that someone can help.
Kind regards
Sozi

[Athanassios Boulis]

Hi Sozi,

You have to follow the structure of modules in Castalia. 

Probably you noticed that there is a communication complex

module that "houses" the network, MAC and radio modules.

So the application can send something to this module and 

and rest assure that all needed communication  actions

will take place. We do not really need this complex module

but we added to make the structure a bit more clear, it does

not really offer any key functionality.

So the app just knows of this comm module. You can see this

by the way the app module is defined in its ned file and the

way the app module and comm module are connected in the

Node ned file.

Internally, the  comm module is connecting the gates that

the app connects to, to the Network module. (References to

the MAC module here are old and I 'll change them in the

user manual.) So when the app sends a message to the 

comm module this goes to the network module. 

All these connections are goverrned by OMNeT code 

(and our definition of ned files). The send, sendDelayed

and scheduleAt functions are OMNeT functions. 

I hope this is clearer to you now.

[Suzi]

Hi,
Thanks for the explanation, now it is more clear. Also what about the
time accuracy and precision in Castalia?. What unit of time do you
use?.
for example i tried to change the data rates filed in omnet.ini file :
SN.node[*].nodeApplication.packet_rate = 1.5 but it seems that
Castalia ignore the fraction!!!
If I want to send packet each 500ms, then can I just set the
packet_rate = 500ms or 0.5s or ?
Thanks for your help
Sozi

[Athanassios Boulis]

As the name suggests this is a rate, i,e, the inverse of period/time

So 1.5 means 1.5 packets per second. It should work fine. There should

be a difference from say 1 or 2.

If you look at the app code you will see how this rate is used to 

determine the  inter-packet spacing in time.

[Suzi]

Hi,
Thanks for your answer, I still have some questions. I want to compute
the delay in each hop. Suppose we have 4 nodes source--->node1----
>node2 --->sink . So I want to compute the delay in node1 and node 2.
if the source sends one packet/sec to the sink via node1 and node2
(so node1 and node2 just forwarders).
So as long as I know, in order to compute the delay all the nodes
should be synchronized!?

So if I startup the nodes without DRIFTED_TIME(random_startup_delay),
does this mean that all the nodes are really synchronized??

Also I want to know the time when a node transmit a packet ?? what is
the appropriate place to record the transmission time?
It seems that the receiving and transmitting times for a forwarder is
the same in Castalia!! hope this is not the case!!

Thank you for any hints
Sozi

[Athanassios Boulis]

I am not sure i understand what you are asking.
How is time-sync related to measuring the latency?

Look at the throughput app to get an idea on how we measure
latency at the app level. We actually keep track of latency histograms.

this is the actual latency (in msec) measured for one packet received.
long latency = lround((simTime() - rcvPacket->getTimestamp())*1000);

If you need to measure latency at intermediate hops (so the app module
will not see the packet, just the network module will) then you need to
measure latency at the network module.

[Suzi]

Hi,
Thanks for the reply, I see the misunderstanding:
I want to measure the following:
1- delay it takes when a source sends a packet to node1 including:
processing, transmission back-off..etc .. so I assume that each node
has own clock or maybe in simulation we do not have this abstraction?
so how can you measure this delay without having the same point of
time??

2- Delay in each hop (forwarder), just the delay it takes to receive
and transmit a packet. in this case we do not need to synchronize.
still not sure if castlia had timestamp in the radio that i can
extract from the packet! or I have to attache it to the packet . Do I
have to timestamp the packet in the mac module or in the network
module ? I am really confused about this issue !!
Thanks for any suggestion
Sozi

[Athanassios Boulis]

I want to measure the following:
1- delay it takes when a source sends a packet to node1 including:
processing, transmission back-off..etc .. so I assume that each node
has own clock or maybe in simulation we do not have this abstraction?
so how can you measure this delay without having the same point of
time?

Why would you care about each node's own clock??

You want to measure the delay, the real delay.

Just use simTime. In a real system it would be hard to measure

the real delay, but this is one of the advantages of simulation. 

This is exaclty what we do in the example of the Throughput app.

 

2- Delay in each hop (forwarder), just the delay it takes to receive
and transmit a packet. in this case we do not need to synchronize.

So backoff, or other delays are not relevant here? What is the difference

that you perceive in this case?

still not sure if castlia had timestamp in the radio that i can
extract from the packet! or I have to attache it to the packet . Do I
have to timestamp the packet in the mac module or in the network
module ? I am really confused about this issue !!

Really there is no difference. The only thing as I mentioned before is that

the latency is measured at the app layer, so for delay between hops

you will need to measure it at the network module. I do not remember

how is the packet format at the netwrok layer and if it includes a timestamp

(I think it does but I am not sure). If it does not, just implement something

similar to the packet at the app layer. 

[sozi]

Hi,

> Why would you care about each node's own clock??
> You want to measure the delay, the real delay.
> Just use simTime. In a real system it would be hard to measure
> the real delay, but this is one of the advantages of simulation.
> This is exaclty what we do in the example of the Throughput app.

That is true, I was thinking about real system in which each sensor
has its own clock.
any way maybe this is important for someone who wants to study time
synchronization. not sure

> > 2- Delay in each hop (forwarder), just the delay it takes to receive
> > and transmit a packet. in this case we do not need to synchronize.
>
> So backoff, or other delays are not relevant here? What is the difference
> that you perceive in this case?

No, it is relevant, we still have all these delays, I want to say that
measuring the hop delay is not the same as with the throughput
application that measure the delay in the application layer.

My understanding is: for hop to hop delay, the timestamp should take
place in the MAC module! not really sure!! but if the goal of this hop
is just to forward the packet, then why should we pass it the network
layer??
Does this make since just to forward the packet and do the timestamp
in the MAC layer??

Also it seems to me that the receiving time and the sending time of
intermediate hop is the same in Castalia?? true? I just wondering if
you timestamp the packet once the application received it, then if you
want to forward it directlly to the next hop. In this case the sending
and the receiving has the same simTIme()????

>
> still not sure if castlia had timestamp in the radio that i can
>
> > extract from the packet! or I have to attache it to the packet . Do I
> > have to timestamp the packet in the mac module or in the network
> > module ? I am really confused about this issue !!
>
> Really there is no difference. The only thing as I mentioned before is that
> the latency is measured at the app layer, so for delay between hops
> you will need to measure it at the network module. I do not remember
> how is the packet format at the netwrok layer and if it includes a timestamp
> (I think it does but I am not sure). If it does not, just implement
> something
> similar to the packet at the app layer.

I have checked the network module and there is not any timestamp filed
on its frame.
Here how I want to implement it, as you said. Please just check if I'm
right in my steps:

1- I have to create a field for timestamp in NetworkGenericFram.msg

message Network_GenericFrame
{
fields:
netHeaderInfo header;

// simulation-specific fields
double rssi;
double timestamp;
string currentPathFromSource;
};

2- Suppose I want to use "ByPassRoutingModule" then I have to add the
timestamp into the data frame of the network? Please see the yellow
color!

int BypassRoutingModule::
encapsulateAppPacket(App_
GenericDataPacket *appPacket,
Network_GenericFrame *retFrame)
{
// Set the ByteLength of the frame
//there are some lines over here that I removed to make it more
readable.

// --- Set the Simulation-Specific fields of Network_GenericFrame
retFrame->setRssi(0.0);
retFrame->setCurrentPathFromSource("");

retFrame->setTimestamp(simTime()); // here I set the timestamp

// --- Set the Network_GenericFrame -> header fields

return 1;
}

Now if this correct, how and where should I get the timestamp in order
to compute the hop2hop delay?

Kind regards
Sozi

[Athanassios Boulis]

 My understanding is: for hop to hop delay, the timestamp should take
place in the MAC module! not really sure!! but if the goal of this hop
is just to forward the packet, then why should we pass it the network
layer??
Does this make since just to forward the packet and do the timestamp
in the MAC layer??

I am not sure what you mean here. If you want multihop routing

this happens at the network layer. You need to choose an 

appropriate routing protocol to perform your routing.

To measure the delay between hops, timestamping should be done 

at the netwrok layer (although timestamping at the MAC layer should

work as well) 

Also it seems to me that the receiving time and the sending time of
intermediate hop is the same in Castalia??  true? I just wondering if
you timestamp the packet once the application received it, then if you
want to forward it directlly to the next hop. In this case the sending
and the receiving has the same simTIme()????

If you want to measure hop delay you should subtract the receiving 

time at one node from the transmitting time of the PREVIOUS hop/node.

 

1- I have to create a field for timestamp in NetworkGenericFram.msg

message Network_GenericFrame
{
 fields:
netHeaderInfo header;

// simulation-specific fields
 double rssi;
 double timestamp;
 string currentPathFromSource;
};

Yes that's fine.

 

2- Suppose I want to use "ByPassRoutingModule" then I have to add the
timestamp into the data frame of the network? Please see the yellow
color!

I cannot see yellow color but I beleive this is more or less how

you would update the timestamp (I have no time to check in detail)

See what we are doing at the app layer to update and use timestamps.

The important thing to note though is that you should NOT USE

ByPassRoutingModule. If you do then you will have NO routing

as the name suggests.

 

[sozi.seham seham]

Hi,
Thanks Thanassios for your help, but does this really important if I am using unicast?

>The important thing to note though is that you should NOT USE

>ByPassRoutingModule. If you do then you will have NO routing

>as the name suggests."

In my application I send the packet using unicast, so each node knows where to send the packet. Also I do the timestamp at the MAC layer. Why should I care about the routing in this scenario. Please let me know if I am missing something.? becouse i do use the ByPassRoutingModule!!

Thank you for your help
Sozi

 

--

You received this message because you are subscribed to the Google Groups "Castalia Simulator" group.
To post to this group, send email to castalia-...@googlegroups.com.
To unsubscribe from this group, send email to castalia-simula...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castalia-simulator?hl=en.

[Athanassios Boulis]

If you don't need routing then there is no problem.

However, if you need to reach a node which is not your immediate neighbour

(as you suggested already, writing about several hops) then you

need a routing algorithm (to determine which is the next hop at each node you reach). 

As simple as that.

If you feel you do not quite understand the basic ideas of routing then you 

should study some introductory material. This forum is not the place for 

explaning routing or other basic networking ideas. 

[sozi.seham seham]

Hi,
Thank for you email, I understand how routing works but I do not fully understand the following:
When I connect the nodes as following in omnet.ini

SN.node[0].nodeApplication.nextRecipient = 1
SN.node[1].nodeApplication.nextRecipient = 2
SN.node[2].nodeApplication.nextRecipient = 3

and in the intialize() at the application I 
sprintf(dstAddr, "%i", nextRecipient);

for me, when node1 sends a packet then only node 2 will take care of it,  sure some other nodes will receive it but they will ignore it as it is not intended to them. So in this case I feel that no need for a routing protocol!, just "ByPassRouting". Hope that I am correct or what do you think ?

Thanks for your help
 Sozi

 
 

[Athanassios Boulis]

Yes, in this case it should work. Although I am not sure what 

you are doing in the rest of the code. Make sure you retransmit

the packets that you get, and also you do not overwrite the dstAddr.

What you effectively doing here is static routing at the application level!

So you do have routing, you just don't have it in the routing module level

and with a proper dynamic algorithm.

In some sense this is abusing what the application provides, but

I guess if you are just doing it for a couple of hops and you just

want to test a simple scenario, it would be ok. In general,

(properly) use routing, when you need it.