How to retrieve RSSI values from Veins Application Layer (BaseWaveApplLayer)?

[Mevlut Turker Garip]

I am running a VANET simulation (Veins) where I am trying to get the RSSI values associated with packets sent by other cars in my VANET application that extends BaseWaveApplLayer. I could not carry the RSSI values that are calculated in the Physical layer (Decider...) up to the application layer where I will be doing further processing/analysis on the sampled RSSIs from different cars. I do not want to have to process these values in the Physical layer. The only interaction between the application layer and lower communication layers is the "sendDelayedDown" function which sends the given packet and the "handleLowerMsg" function that will be called when a packet is received. The packet given to the application layer by the lower network layers is a "cMessage" that does not carry any information about the associated Signal or RSSI, or contain any pointer to the lower network layer modules. I really need help leading me towards the correct direction on this. 

[David Eckhoff]

there are many ways to do this.
one way to do this is to just add a field to the WaveShortMessage
"double RSSI" and then set this field in the decider/Phy when the RSSI
is calculated. (you probably have to decapsulate the macpacket and cast
it to WaveShortMessage to do that)
In the Applayer simply cast the cMessage back to WaveShortMessage and
you can access your RSSI field then.
Note, that you can add as many auxiliary fields to the WaveShortMessage
as you wish, it does not change the network behavior, as packet size is
set separately and independent from the actual fields of the message

-david

> --
> You received this message because you are subscribed to the Google
> Groups "OMNeT++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to omnetpp+u...@googlegroups.com
> <mailto:omnetpp+u...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/omnetpp.
> For more options, visit https://groups.google.com/d/optout.


--
Dr. David Eckhoff
Computer Networks and Communication Systems
University of Erlangen, Germany
http://www7.cs.fau.de/en/people/eckhoff/

[Mevlut Turker Garip]

Thanks David, that sounds like a logical way to do it. Can you give more hints where would be the best place to insert this logic in Physical layer? Also, the problem with this approach would be that, after decapsulating the MAC packet to be able to cast and modify the WaveShortMessage, you would have to re-encapsulate it to MAC packet before passing it up to link layer. However, after decapsulating, you will lose the MAC header of the received packet, which will make it challenging to re-encapsulate the modified WaveShortMessage. I personally think that your suggestion is the best way to proceed with, but I would appreciate further hints/suggestions to overcome this obvious problem.