0

Having a packet

cPacket *pk

how can I obtain the bit representation of it? For example, in the form of

std::bitset<pk->getBitLength()> pk_bits;

My final goal is to apply an encoding scheme to the packet, i.e. Reed-Solomon encoding.

rebrid
  • 430
  • 8
  • 27
  • I'm familiar with Reed Solomon, but not OMNet. Looking at the documentation, I'm getting the perhaps false impression that cPacket's have a bit length, but not actual data. The only data pointer is for an optional name. Perhaps the packet simulation is only interested in number of bits, timing, and if bit errors are present, without actually having pre-defined data in the cPackets. There's some sort of random data generator, so the packet data could be generated on the fly? – rcgldr Jul 07 '17 at 13:19
  • In my specific case, at the moment yes, there is a random generator but I've been working to implement a serializer to include the actual data. I found a model for the Reed Solomon that encode std::vector. My problem is indeed how to bring the cPacket to that type. Or alternatively, how to apply the RS coding in another way, e.g. to the bitset representing the packet? – rebrid Jul 07 '17 at 13:43
  • The issue is the data needs to be stored somewhere, and the RS redundancy data would need to be appended to that data. Are you able to replace std::bitset so that it generates data with RS redundancy data? If OMNet doesn't have this capability, then it seems all you can do related to RS error correction is to calculate uncorrectable error rate for a given bit length and bit error rate, then perhaps adjust the simulation bit error rate to the uncorrectable rate. – rcgldr Jul 07 '17 at 18:22

1 Answers1

2

As @rcgldr commented, a simple cPacket in itself does not hold any data, at least not in the sense of how real packets do. And it's not necessary in most models, because they operate on a higher, more abstract level, which makes working with them easier, and running them faster.

The information that travels between the nodes of the simulation is what you put in the fields of your messages (preferably custom made using the message compiler of OMNeT++, from .msg files).

This is, however, completely independent of the bitLength/byteLength properties of the cPacket class, which is just a number that can be set to any value for any message.

You can, of course, choose to model a realistic protocol by adding fields to your message that correspond to a real(istic) network protocol header, like TCP or IP, or even something you just made up. But this still doesn't provide any (reliable) byte-sequence-like access to the contents, because it is not always trivial how the individual fields should be serialized into simple octets.

To achieve this, INET for example has separate *[De]Serializer classes for a number of its custom message types. You can do the same with yours if you want.

A simpler solution would be to represent any payload in the packet by adding an std::vector<unsigned char> or even an std::bitset if you prefer that. And just treat that part separately from the easily accessible fields, applying any encoding on its content.

And finally, just like with any question like "how to add an encryption library to a simulation and use it to transform packets": Are you sure that adding a real byte-by-byte encoder/serializer/etc. to a simulation is the right choice to achieve what you're trying to do? I mean, it could be, and it's possible, but there might be better/simpler/faster ways. In terms of modeling.

Attila
  • 1,445
  • 1
  • 11
  • 21
  • I was indeed wondering why the transmission time of a packet was always the same no matter how many fields were present in _customMessage.msg_ According to what you wrote, I manually need to set the _byteLength_ of the message. Correct? The encoder part, I want to to model the _802.15.4a_ standard, which encodes the PSDU with Reed-Solomon codes. It is the first time I try to do something similar, I'm just trying to follow the steps of the IEEE standard to model the transmission as best as possible but if you have any suggestion on how to do these kind of things, I'd be happy to hear from you – rebrid Jul 12 '17 at 07:42
  • And about the encoding part: At the beginning, especially if this is your first model, I think you would be better of forgetting about all the low-level details, like the exact algorithm used for error correction, and just hide all that behind a "probability of successful reception", as a function of the situation at hand, taking into account things like the distance of the antennas, background noise, and transmission power for example. Badically employing an "error model". You can swap in a more detailed model later. – Attila Jul 12 '17 at 08:34