omnet retransmitting the data packet at routing protocol - omnet++

I am working on a wireless routing protocol. I have created a Queue at every node. In this queue, every node kept packet which it already transmitted. If packet is not transmitted by nexthop then previous node will retransmit the packet after timeout. The problem is that when node is trying to retransmitt the packet by calling postRotingHook in handle function to retransmit then it is not doing anything. This postRoutingHook is created locally so it is not actually sending the packet. So how to connect this packet with network for retransmission?
Example: Suppose We have 3 nodes A, B and C. A is source, B is intermediate and C is destination. Node A sent a packet initially. Now node B will forward it to node C. At this time node A will overhear this packet and it will cancel the timer and delete this packet from its Queue. (in normal condition)
Suppose node B could not forward the packet because of some reason then node A should re-transmit the packet after time out. I am unable to achieve this functionality.
My programming scenario is:
I have modified GPSR protocol. Where header file have definition of these 5 INetfilterHooks methods. I didn't use any control packet e.g. request, response, beacon etc. I am directly dealing with data packet which contains some control information. I have implemented my logic in datagramPreRoutingHook() method (when data is received from lower layer) and datagramLocalOutHook() method (when data is received from upper layer).
Source node (at network layer) receives packet from upper layer at IPv4.cc using handlePacketFromHL() ->datagramLocalOutHook(datagram, destIE, nextHopAddr) == INetfilter::IHook::ACCEPT) when it calls datagramLocalOutHook(datagram, destIE, nextHopAddr) then control goes to my routing protocol. It makes necessary changes, Adds source, destination address, creates options and keeps the packet in Queue (for retransmission by scheduling timer) then return ACCEP. Then control again goes to IPv4.cc.
After this process, if time out occurs at my protocol then I am unable to send packet to IPv4.cc. I called postRoutingHook to retransmit the packet then it simly return ACCEPT (as defined in header file) and does nothing. I have tried to call some methods of IPv4.cc by making object of IPv4 in my protocol but these methods are protected so I couldn't access these methods.
I tried with making some public methods of IPv4.cc but it is giving error at further stage.
I have tried to make the object of INetfilter::IHook for calling its postRoutingHook() but is also providing error as object of abstract class can not be created.

Related

How to destruct messages after calling endSimulation() in omnet++?

I have a sensor network where nodes exchange messages and calculate some parameters on which we decide if a clone has been inserted into the network or not. If it is the case, I call the endSimulation() instruction in order to stop the simulation. But I noticed that some messages continue to be exchanged after the instruction endsimulation() and I got the message:
undisposed object: (omnetpp::cMessage) Drones.clone.app.event2 -- check module destructor"
Although I have a finish() method where I cancelAndDelete(event2). I want to know how to delete event after calling endSimulation().

Sent acks are received by multiple nodes in Veins-4a2 using prepareWSM method

I use OMNeT++-4.6, sumo-0.22.0 and Veins-4a2.
In my scenario, when an RSU receives a message from a node, it sends an ACK using the prepareWSM method:
sendWSM(prepareWSM("ack", ackLengthBits, type_SCH, ackPriority, senderId , 2))
So, the RSU sends an ACK to senderID which is the sender node of the message.
In my log file, I notice that there are some nodes - not only the original sender node - which receive this ACK.
I need to know if prepareWSM method diffuse the ACK to all nodes encountered or if what I did to send only the ACK to the sender node is correct?
Although you can set the receiver address for the WaveShortMessage, it is ignored in the Mac1609_4.cc (line 178 ff.), since originally only broadcast transmission is used in C2X-communication:
//send the packet
Mac80211Pkt* mac = new Mac80211Pkt(pktToSend->getName(), pktToSend->getKind());
mac->setDestAddr(LAddress::L2BROADCAST);
To achieve your wished acknowledgement system you have to check the recipient address of each message you receive in the APP layer and ignore messages which are not addressed to your address (myId).

Is a packet duplicated when sent across multiple stations in OmNeT++/INet?

With particular regards to Ieee80211 in INet library, I have a question about what happens when a cPacket/cMessage is sent across multiple stations.
It is possible that this is not strictly about INet, but a general behavior of OmNet++. Here's the question:
When sending a cPacket/cMessage and it is received by multiple stations/modules, is it copied or all receivers get a pointer to the same instance?
Real scenario
So, in such a network:
Station A is sending a cMessage which is received by all the other stations. Of course only one station is the receiver, everyone else will drop the packet. So if B is the receiver and C, D, E and F go:
void handleMessage(cMessage *msg) {
if (this->isNotForUs())
delete msg;
}
Will it cause B to have its frame destroyed?
In OMNeT++/INET sending a cMessage to multiple receivers is modelled by creating multiple copies of this message and sending one copy to one receiver. There is dup() method that creates an exact copy of the message. For example:
cMessage *msg2 = msg->dup();
As a consequence, every receiver will receive a new instance of cMessage object, and it can remove or process it in any way. Therefore, in your example deleting a message by C,D,E, and F does not affect the message received by B.

Broadcasting of Messages in Veins example

I noticed that in the Veins demo scenario a node broadcasts the data message it creates to each and every other node in the simulation.
I tried to modify that a bit. I modified the sendMessage() function in TraCIDemo11p.cc file by initializing the address of the recipient in the WSMusing the setRecipientAddress() function. But while running the simulation in Veins 3.0, I find that this message is still being broadcast to all the nodes apart from the target node.
How do I implement this p2p connection?
How do I generalize by adding an RSU to the scenario to implement a heterogeneous communication framework?
In its basis the 802.11p standard, which is the main communication standard for Vehicular Communication (and also the one used in Veins), does broadcast.
So basically, whatever you send via a 802.11p network interface, it will always be broadcasted, however you can make-up some type of p2p by doing "source-destination checking" from the frames.
You can extend the WaveShortMessage to contain Source and Destination fields specific for your application, and then perform checks if the destination is receiving from the intended sender.
Lets say we have two nodes nodeSender and nodeReceiver who want to communicate.
nodeSender would need to include its own identifier (name, ID etc) in the message:
msgToSend->setSourceAddress("nodeSender")
nodeReceiver would need to check if the message it "hears" is from the intended sender. Because in reality it will be hearing from multiple senders due to the broadcast nature of 80211p
if(receivedMsg->getSourceAddress() == 'nodeSender')
{
/* this is the message which I need */
else
{
/* do nothing with the message from other senders */
}
You can use vehicles SUMO id as their unique identifier for the addresses. You can obtain that by querying the TraCIMobility module:
cModule *tmpMobility = getParentModule()->getSubmodule("veinsmobility");
mobility = dynamic_cast<Veins::TraCIMobility*>(tmpMobility);
ASSERT(mobility);
mySumoID = mobility->getExternalId();

Packet Acknowledgements in TinyOS

Iam using telosB motes for implementation.
I have come across one of the way for acknowledging the packets,
task void send() {
call PacketAcknowledgements.requestAck(&myMsg);
if(call AMSend.send(1, &myMsg, 0) != SUCCESS) {
post send();
}
}
event void AMSend.sendDone(message_t *msg, error_t error) {
if(call PacketAcknowledgements.wasAcked(msg))
// do something if packet was acked
else
// do something else if packet was not acked (possibly resend)
}
Actually my doubt is, the receiving mote should have to acknowledge the packet or it should have PacketAcknowledgements interface in its application in order to send ACKs.
How this type of acknowledgement works?
And I have checked with my own type of acknowledgement, it works like after receiving the packet the mote acknowledge the packets, if source mote does not receive positive ack in certain time frame then re transmit the packet .
So which is better way of doing?
Please guide & thanks,
In TinyOS acknowledgements are implemented on the lowest communication abstraction level - active message[1]. This means that any component that operates with active messages has a built in support for synchronous acknowledgements.
Actually my doubt is, the receiving mote should have to acknowledge
the packet or it should have PacketAcknowledgements interface in its
application in order to send ACKs.
If you used PacketAcknowledgements.requestAck(&myMsg) to request acknowledgement, then you don't have to write extra code in Receive.receive event handler to process acks as this is done for you by underlying communication layer. All you need to do is wire PacketAcknowledgements interface that your component/module uses to one of the providers (AMSenderC or ActiveMessageC).
How this type of acknowledgement works?
The high level idea is following - calling PacketAcknowledgements.requestAck(&myMsg) sets a flag in a packet header and tells sender component not to signal sendDone event until ack was received (or timed out). When receiver component handles the packet on the other end it reads the flag and sends and ack if requested.
Having said all that, description of your way of acknowledging packets seems very similar to what PacketAcknowledgements offers, so personally I would avoid writing extra code for handling acknowledgements myself and stick with the tools provided.

Resources