Reporting some errors in the wimax module

[Steve muni]

Hi

I would like report some erros I have found in the wimax module during the last month.

----The first is in src/wimax/model/default-traces.h. For the modulation 16QAM3/4 there are a lot of drops and seeing the trace values for this modulation in default-traces.h, the table double modulation4[6][115] shows very high BER for high SNR. For example for 31.50 db assign a BER of 0.02085, which in my opinion is wrong. Furthermore the length of this table is anormally short. So I would suggest that the values are calculated again with IT++. I attach the default-traces.h I am refering to.

----Another issue I found is in simple-ofdm-wimax-phy.cc. In the method

Time SimpleOfdmWimaxPhy::DoGetFrameDuration (uint8_t frameDurationCode) const{}

the values for the frame duration that should be 2.5ms, 4ms, 5ms, 8ms,10ms, 12.5ms and 20ms are in seconds. For example:

case FRAME_DURATION_4_MS:

     return Seconds (4);

I do not know actually if this affect the normal behaviour, but I think that it should be changed to milliseconds:

case FRAME_DURATION_4_MS:

    return MilliSeconds (4);

---Another one is related with a general error with the fragmentation/defragmentation procedure. I have noticed some post warning about this. 

https://groups.google.com/forum/?fromgroups#!searchin/ns-3-users/arnau/ns-3-users/scKuCdYvkDU/UDU8NNyOcRQJ

https://groups.google.com/forum/#!searchin/ns-3-users/assert$20failed.$20cond$3D%22m_buffer.GetSize$20()$20wimax/ns-3-users/_jnPvVOsUr4/98nF0K5w59gJ

https://groups.google.com/forum/#!searchin/ns-3-users/assert$20failed.$20cond$3D%22m_buffer.GetSize$20()$20wimax/ns-3-users/Laf88koU5tc/2hUYryKYzFAJ

And at least there is a bug reported: 

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1790

I have trying different ways to solve this but I didnt found where is the error. However I have found clumsily ways to avoid the error. The first of all is comment in bs-schedulre.cc, in the method

bool BSScheduler::CheckForFragmentation (.....), the return statment y change the boolean

NS_LOG_INFO ("\t Fragmentation IS possible");

     return false;

     //return true;

so this way never fragmentation is being used. It works and the simulation do not crash, but since this is not very good for the fidelity of the wimax model I also have tried fix it without disble fragmentation, and I have change again the method bool BSScheduler::CheckForFragmentation (.....). 

Another way, maybe more clean, but almost equally clumsy is this: I noticed debuging that the error happen when packets with 4 byte length arrives and the defragmentation is not done properly. To avoid this I have changed in ss-net-device.cc this:

line 1022:

GetConnectionManager ()->GetConnection (cid)->ClearFragmentsQueue ();

NS_LOG_INFO ( "\t fullPacket size = " << fullPacket->GetSize () << std::endl);

m_ssRxTrace (fullPacket);

ForwardUp (fullPacket, m_baseStationId, GetMacAddress ()); // source shall be BS's address or sender SS's?

}

 for this

line 1022:

GetConnectionManager ()->GetConnection (cid)->ClearFragmentsQueue ();
NS_LOG_INFO ( "\t fullPacket size = " << fullPacket->GetSize () << std::endl);

   if(fullPacket->GetSize () > 4){

                  m_ssRxTrace (fullPacket);

                  ForwardUp (fullPacket, m_baseStationId, GetMacAddress ()); // source       shall be BS's address or sender SS's?

    }

}

This way the fragments which are not well read are discard.

However, this solution do not fix the main problem I have found, and it is that the throughoput values do not match with those the model foresees. I attach a chart with the values obtained for frames of 2.5ms, CP 1/4 and packet size of 1372 bytes at UDP level. It is a UGS downlink flow with 50% frame division UL/DL with SCHED_TYPE_SIMPLE and with the attribute for the flow: DlServiceFlowUgs.SetMaximumLatency(2). I have changed the default-traces.h file in order to avoid drop packets in the phy layer in 16QAM3/4. The offered load means that the load in the link is being increased until several times the expected value of throughput. For example: for BPSK, the offered load goes from 0kbps to 5Mbps (). For qpsk1/2 goes from 0kbps to 10Mbps,for qpsk3/4 goes from 0kbps to 15Mbps and so on...

You can observe that, first of all, the shape of the function is not the correct one. I think it should be a positive slope until the saturation point, and then a constant value to get the 100%. It is weird the curve present after the saturation point. And more weird is that for some modulations, such as bpsk, 16Qam1/2 and qpsk1/2 the behaviour after the saturation point is different from the other modulations. This results have been obtained using the same script, only changing the modulation.

Second, you also can see that the values for the saturation point do not match at all with the expected values given for the model. They are almost double than expected. Maybe the 50% ratio UL/DL is not being respected?

The last thing regarding this issue is that the delay remains constant to 5ms, although the offered load exceeds the expected capacity. I think that there should be an observable effect of the buffers (the default buffer in WifiMac is 1024). The delay it is ok when the link is under saturarion, since it is expected a delay of 2 times the frame duration. However I was expecting to see an abrupt increse of the delay after the saturation point.

(I have attach my code if any wants to investigate further)

----The last thing is related with distance issues.  I have seen that the default values of RTG/TTG are set to 160us, and I think that according the standard they should be 100us for distances greater than 15km and 2*propagation-time if the distance is shorter than 15km.

Regarding the RangReqOppSize parameter, this is set by default to 8 bytes. However I think it should be distance-dependent and it is not in the implementation.

Since this parameters can be changed manually, I have tried to change them this way:

 Ptr<NetDevice> n;

    Ptr<WimaxNetDevice> wd;

    Ptr<BaseStationNetDevice> wbs;

    n = bsDev.Get(0);

    wbs=n->GetObject<BaseStationNetDevice>();

    wd = n->GetObject<WimaxNetDevice>();

wd->SetRtg(100); //or other rtg value

wd->SetTtg(100);
wbs->SetRangReqOppSize(size); //size in bytes of the ranging opp

but no effect is appreciable. So I think that something is going wrong here too. Here I changed manually the Rx power in the model so that the effects of the distance are only reflected in the MAC layer, not in the Phy.

So this is a summary of my experiences with wimax. I am willing of give you more information about any of the remarks I made. Maybe some of my comments are incorrect or I am doing something wrong. I thank you for any suggestion or comment and if you think that I should open a bug report I will do with a test case in those issues you think are clearly a bug.

Kind regards

Steve

[Tommaso Pecorella]

Hi Steve,

thanks for the detailed report. As a matter of fact the WiMAX model is not among the most used ones. As a consequence, there are a lot of unresolved (and probably still unknown) issues. The fact that WiMAX doesn't seems to be a successful standard isn't helping either, but this is another point.

Anyway, I guess we'll have to find out someone willing to take care of the module and improve it, and your report will be extremely useful for sure.

Cheers,

T.

[Red zhaoyj]

Hi Mr Tommaso Pecorella,

After I check SimpleOfdmWimaxPhy::DoGetFrameDuration in ns3.22, I find that the values for the frame duration are still in seconds.

I am so disappointed about this. It makes me feel that wimax module hasn't been updated for years. 

Recently I have added wimax into my program, but it would crash very easily each time i run it, due to different kinds of assert failures. 

It seems wimax module is not well-designed and stable enough to be used, isn't it?

On the other hand, I find some small mistakes in wimax. In method SubscriberStationNetDevice::DoReceive, I find the following statements:

NS_ASSERT_MSG (SS_STATE_WAITING_RNG_RSP,

  "SS: Error while receiving a ranging response message: SS state should be SS_STATE_WAITING_RNG_RSP");

I think it should be 

NS_ASSERT_MSG (GetState() == SS_STATE_WAITING_RNG_RSP,

  "SS: Error while receiving a ranging response message: SS state should be SS_STATE_WAITING_RNG_RSP");

 

I find that this thread could be a place which records the unfixed bugs in wimax module, so i post this mistakes here.

Hope this would help.

Bests,

Tommaso Pecorella於 2014年8月13日星期三 UTC+8下午4時03分12秒寫道：

[Red zhaoyj]

Hi Mr Tommaso Pecorella,

I am sorry I forget to mention that, after I take the small modification above, examples like wimax-ipv4.cc would fails because of failure of this assert.

Bests,

Tommaso Pecorella於 2014年8月13日星期三 UTC+8下午4時03分12秒寫道：

Hi Steve,

[Tommaso Pecorella]

Hi,

you're totally right when you say that the WiMAX module hasn't been updated for years.

This could be because WiMAX is like the famous parrot: dead.

Well, not totally dead, but in a deep coma. As far as I know, the only practical use of WiMAX is in the aeronautics communications, but it's a slightly modified version and it is called AeroMACS. Aeronautics standard orgs are so crazy that the fast that WiMAX is not a widespread technology is considered a GOOD point, so the devices will cost a lot and it's not probable that some figgin' kid will show at the hub with a powerful modified compatible device.

Anyway, for commercial systems WiMAX is almost dead, at least from a commercial point of view. The manufacturers don't produce anymore the chips and so on.

This has a direct implication on the scientific community (WiMAX is not an "hot" topic) and nobody has much interest in spending time fixing a model that is hard to be used for a scientific publication.

I mean, try submitting to a conference or a scientific journal a novel and ultra-good algorithm for WiMAX... I'm ready to bet that they'll ask you to apply the same principles to LTE-A or 5G.

Summarizing... little interest. No maintainer (and no bug reports either).

Still, this is not a good reason to trash the module or dismiss the bugs as "who cares". Your bug reports are very valuable. However, I'd strongly suggest to use Bugzilla once we find that they're real bugs. In this way the bug can be tracked and fixes can be discussed.

About the assert you found, you're right, they're simply skipped (there's no actual check). If you make the check "right", then an assert is thrown, indicating a problem in the SS state machine.

Unfortunately, I'm not into WiMAX either, so I don't know how to fix it. Well, I could, but it would mean a lot of reverse engineering and study of the standard. All things needing time, and time is exactly what I don't have :(

Anyway, please open a bug on bugzilla about these asserts. Better if you do it by yourself, so there will be a trace that you found it. The attribution is important :)

Cheers,

T.

[Red zhaoyj]

Hi,

Thanks for your reply as well as your advice, sir. Your advice is very useful.

So .. I will consider if I should persist in wimax module.

And.. here is the bug report I made: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2089. It's my pleasure to have my own contribution to ns3. ^_^

Bests,

Tommaso Pecorella於 2015年4月6日星期一 UTC+8上午1時16分03秒寫道：

[Steve muni]

Hi Red,

I have compiled my work with the WiMAX module and posted some code here:
https://groups.google.com/forum/?fromgroups#!topic/ns-3-users/57dHUq7Eapc

As you can see, I had similar problems with the WiMAX module. Some of the problems has been avoided (but no totally fixed) using the given patch.
I hope you find it helpful somehow.

Kind regards