|
Bugzilla – Full Text Bug Listing |
| Summary: | Fatal Error while generating netanim trace for 802.11s Mesh network simulation | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Ehsan Elahi <ehsan.zahoor> |
| Component: | mesh | Assignee: | Kirill Andreev <andreev> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | ehsan.zahoor, jpelkey, ns-bugs, riley, silviocs, tomh |
| Priority: | P5 | ||
| Version: | ns-3.14 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Mesh.cc file with netanim code added | ||
|
Description
Ehsan Elahi
2012-08-06 05:07:19 UTC
Same error occurred when generating AsciiTrace in the same simulation I think this bug cause is the same of the bug 1482. The problem cause is that mesh Information Elements (IEs) are defined on the specific files mesh-information-element-vector.h/.cc and not on the wifi implementation IEs (information-element-vector.cc). As an IE definition, in my opnion, it should be implemented on wifi model, regardless the 802.11 amendment. Therefore, the solution could be either move the mesh IE definition and implemetation to wifi model or to force the netanim to search at mesh IEs (which seems to be a bad choice). I'll try to look in depth to this problem... actually this problem is not directly related to the netanim module. Netanim is completely oblivious of mesh/wif and uses generic packet printing similar to ascii tracing. This is likely a result of non-standard design in the mesh module. Going deep into this issue, we will find out that the AsciiTrace will call somewhere the method ns3::Packet::Print which will recognize the presence of Information Elements (in the mesh example). Therefore, in order to read the IEs (which was previously added to the packet as a MeshInformationElementVector set) the method ns3::WifiInformationElementVector::Deserialize will be called, following by the ns3::WifiInformationElementVector::DeserializeSingleIe to deserialize each IE on the packet. However, the method is unable to recognize any IE, as it was implemented as a virtual class. In this manner, only the ns3:MeshInformationElementVector can do this. In my opinion, to implement the ns3::WifiInformationElementVector as a virtual class makes not much sense as the IEs are part of the 802.11 standard (wifi) regardless the amendment (802.11n, 802.11s...). My sugestion is to move the definition of any IE to the wifi model (from mesh or any other which makes use of IEs) to the wifi model and let the ns3::WifiInformationElementVector to deserialize and hence instanciate each IE on the packet. I think by this way we can solve both problems with AsciiTrace and netanim regarding to mesh example (as it is the unique example that includes a vector of IEs direct to the packet and try to get them back from a vector again). Any comments would be greatly appreciated... (even to say that I am wrong) |