problem for using airtime link metric in hwmp protocol

[stars york]

Dear all,

Following the previous discussion https://groups.google.com/forum/#!topic/omnetpp/bd7nYx9uRaA,

I try to enable airtime link metric of hwmp protocol in inetmanet 2.0-2.2, but it always use hopcount as the routing metrics. My settings are:

*.wlan[*].mgmt.useHwmp = true ## enables HWMP protocol by default in reactive mode

**.wlan.mgmt.useReactive = false #DYMO-UM in the mac layer, it's possible to use AODV

**.wlan.mgmt.useProactive = false #OLSR-UM in the mac layer, 

**.HwmpProtocol.minHopCost=false 

**.useEtxProc=true 

**.UseLwMpls=true 

Anyone can help me to enable this feature?

thanks

[stars york]

Dear all,

When I set the following parameters  

**.HwmpProtocol.minHopCost = false

**.wlan.mgmt.ETXEstimate = true,

However, I always get the 268435455 (0xFFFFFFF) from the hwmp::GetLinkMetric() and this means the node does not have any neighbor. Actually, it has the neighbors and the routing/data forward can be finished successfully.

If someone can help me to address the problem, I will appreciate it very much.

Thanks

stars york於 2014年4月8日星期二UTC+8下午4時12分59秒寫道：

[stars york]

I hope someone can help me to clarify this point. I will appreciate it.

Thanks

stars york於 2014年4月9日星期三UTC+8下午3時37分55秒寫道：

[stars york]

Dear all,

I know the Hwmp protocol includes the airtime link computation in the Etx.cc file. 

However, it does not work successfully. 

I guess I do not turn on the parameters in .ini.

Do you know how to active ETX protocol in the ieee 802.11s mesh hwmp?

my .ini setting:

**.wlan[*].mgmt.useHwmp = true ## enables HWMP protocol by default in reactive mode

**.wlan.mgmt.useReactive = false #DYMO-UM in the mac layer, it's possible to use AODV

**.wlan.mgmt.useProactive = false #OLSR-UM in the mac layer, 

**.HwmpProtocol.minHopCost = false

**.ETXEstimate = true // <-----------why the parameter does not exist in the hwmp or Etx. ned?

I observer the following conditions:

1. In the beginning, the ETX packet cannot estimate the link cost since it seems no neighbor exist (myAddress==msg->getNeighbors(i) is true, so the loop breaks ) in the handleEtxMessage()

2. HWMP::GetLinkMetric(addr) call IEEE80211Etx::getAirtimeMetric(const MACAddress &addr, const int &iface), it seems miss one variable?

Note that the route path can be worked successfully according to the minimal hop concept. This is because the metric always gets 0xFFFFFF = 268435455 and the best route with the smaller value is selected. 

thank you

York

[stars york]

Dear All,

I have tried the inetmanet-master version to run airtime link metric in 802.11s mesh networks. 

The ETX can work successfully and neighbor list is ok. 

I dont know why inetmanet-2.0-2.2 version cannot work. 

There are very few people to work for 802.11s mesh network model?

If you ever use the mesh model of OMNet, please help me to address the issue in the inetmanet-2.0-2.2 version.

I will appreciate it very much.

York 

stars york於 2014年4月8日星期二UTC+8下午4時12分59秒寫道：

[Alfonso Ariza Quintana]

I have uploaded a modification that allows that the S/N could be registered by the ETX module, it is necessary also to active in the radio module

**.airtimeLinkComputation = true

---

Date: Thu, 17 Apr 2014 04:19:25 -0700
From: yorkst...@gmail.com
To: omn...@googlegroups.com
Subject: [Omnetpp-l] Re: problem for using airtime link metric in hwmp protocol

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

[stars york]

Dear Alfonso,

At first I appreciate you very much for providing an airtime metric setting of hwmp. 

But, I am sorry for a bit misunderstanding.

I agree with your opinion that the radio module won't send the S/N information. Instead, PHY layer only forwards the packet error information to the MAC layer (i.e., mark the bit error) and then MAC layer will check the CRC  to determine the "MAC" packet is error or not. Finally, the ETX can calculate the packet error rate.

My question is to sure the ETX module can be worked successfully for the 802.11s HWMP protocol in the inetmanet 2.0-2.2 version

I am doing observation for airtime metric computation in inetmanet 2.0-2.2 version, but it always returns the metric = 268435455 (0xFFFFFFF) from the hwmp::GetLinkMetric(). 

However, hwmp:GetLinkMetric() works successfully in inetmanet-master version.

I take time to trace what it happened. I found that  it seems no neighbor exist and this causes  (neighbors.size() is always 1, so the etx packet cannot be transmitted successfully) in the handleEtxMessage()

Now, I am looking for the process of the neighbor setting.

Can you help me to check the question why the detecting of neighbor is not incorrect in inetmanet 2.0-2.2 version?

The followings are my .ini file about mesh and etx.

**.wlan[*].mgmt.useHwmp = true ## enables HWMP protocol by default in reactive mode

**.wlan.mgmt.useReactive = false #DYMO-UM in the mac layer, it's possible to use AODV

**.wlan.mgmt.useProactive = false #OLSR-UM in the mac layer, 

**.minHopCost = false

**.ETXEstimate = true

Thanks,

BRs,

York

Alfonso Ariza Quintana於 2014年4月18日星期五UTC+8下午5時45分14秒寫道：

[Alfonso Ariza Quintana]

Have you included this patch?

https://github.com/aarizaq/inetmanet-2.0/commit/255d731f4bfa5b21b27a8121e77f4d0cc4dd0c04

 

this should fix the problem

[stars york]

Yes, I have updated this patch when you upload the new patch(4/18).  :)

Also, the airtime link metric is used successfully for hwmp routing.

But I want to know how to get the airtime metric value in the simulation in detail.

  
I found that the code has been embedded in the radio.cc to get the some parameters used for calculate airtime link metric

if (radioModel->haveTestFrame())

    {

        cinfo->setAirtimeMetric(true);

        cinfo->setTestFrameDuration(radioModel->calculateDurationTestFrame(airframe));

        double snirMin = pow(10.0, (airframe->getSnr()/ 10));

        cinfo->setTestFrameError(radioModel->getTestFrameError(snirMin,airframe->getBitrate()));

        cinfo->setTestFrameSize(radioModel->getTestFrameSize());

    }

These parameters are independent from ETX  parameter settings such as ETX packet size?

I am not clear about the process for estimating airtime link metric.

Thank you, 

Alfonso Ariza Quintana於 2014年4月21日星期一UTC+8下午5時20分54秒寫道：

[Mohamad Sbeiti]

Dear York,
regarding the calculation of the airtime link metric, have a look on the following mesthods in the file: Ieee80211Etx.cc

Method1: Ieee80211Etx::receiveChangeNotification

// code snippet 1
if (snrDataTime.airtimeMetric)
                    snrDataTime.airtimeValue = (uint32_t)ceil((snrDataTime.testFrameDuration/10.24e-6)/(1-snrDataTime.testFrameError));

// code snippet 2
                if (snrDataTime.airtimeMetric)
                {
                    // found the best
                    uint32_t cost = 0xFFFFFFFF;

                    for (unsigned int i = 0; i < ng->signalToNoiseAndSignal.size(); i++)
                    {

                        if (ng->signalToNoiseAndSignal[i].airtimeMetric && cost > ng->signalToNoiseAndSignal[i].airtimeValue)
                            cost = ng->signalToNoiseAndSignal[i].airtimeValue;
                    }
                    ng->setAirtimeMetric(cost);
                }
                else
                    ng->setAirtimeMetric(0xFFFFFFF);
            }

Method2: Ieee80211Etx::getAirtimeMetric

Best regards
Mohamad

[stars york]

Dear Mohamad,

Yes, I have studied these data and know the ETX process. 

Besides methods 1 and 2, I am studying the duration computation in the ieee80211radioModel.cc and Radio.cc.

I got two different frame duration 

snrDataTime.testFrameDuration = 0.000232

snrDataTime.testFrameDuration = 0.001448

I am looking for the reasons and I think I need to take a lot of time to trace the detail processes.

I appreciate Alfronso and Mohamad very much 

Thanks

BRs,

York

Mohamad Sbeiti於 2014年4月21日星期一UTC+8下午8時11分32秒寫道：

[Mohamad Sbeiti]

Dear York,

the testframe duration is first calculated at the PHY layer in radio.cc (sendUp):

  if (radioModel->haveTestFrame())
    {
        cinfo->setAirtimeMetric(true);
        cinfo->setTestFrameDuration(radioModel->calculateDurationTestFrame(airframe));
        double snirMin = pow(10.0, (airframe->getSnr()/ 10));
        cinfo->setTestFrameError(radioModel->getTestFrameError(snirMin,airframe->getBitrate()));
        cinfo->setTestFrameSize(radioModel->getTestFrameSize());
    }

It is then updated at the MAC layer in IEEE80211Mac.cc(handleLowerMsg):
      double frameDuration = cinfo->getTestFrameDuration() + controlFrameTxTime(LENGTH_ACK)+rtsTime;
        cinfo->setTestFrameDuration(frameDuration);
    }

So in case you are using a fix PHY data rate (autobitrate is false), the duration of the frame should be the same as long as the size of the frame is not varying. However, if the PHY data rate is not fix, the duration might change even if the size of the frame is not changing.

Best regards
Mohamad