HWMP in omnet++

[rashad kasim]

Hello everyone,
    I am new to omnet++ and I would like to know if there is any implementation of HWMP in omnet++.

Any pointers on this, would be appreciated.

Regards,
Rashad

[Alfonso Ariza Quintana]

You can try inetmanet, it has a basic implementation of HWMP

 

Enviado desde Correo para Windows 10

--
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.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

 

[rashad kasim]

Thanks Alphonso.

I have added inetmanet package by downloading from the below link and importing the project in omnet++.
https://github.com/aarizaq/inetmanet-3.x


While trying to built the project, an error is thrown when it was processing the below step in the built process.
Creating shared library: ../out/gcc-debug/src/libINET.dll

The error thrown on the above step is given below:
g++.exe: error: CreateProcess: No such file or directory
make[1]: *** [Makefile:1558: ../out/gcc-debug/src/inet/linklayer/base/MACBase.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/c/Users/Rashad/Downloads/inetmanet-3.x-inetmanet-3.5/src'
make: *** [Makefile:6: all] Error 2

Error is thrown while trying to execute any example in inetmanet and they are shown below:
 Cannot load library '../../../src//libINET.dll': The specified module could not be found


Can you explain me why this error is happening.
Thanks in advance.

[Alfonso Ariza Quintana]

There is a compiler problem, you need to start omnet from the mingw Shell, in other case the paths and definitions can be erroneous

[rashad kasim]

Thanks for the reply Alfonso.

I started omnetpp using mingwenv.cmd and while building inetmanet, I got below error.

collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:1548: ../out/gcc-debug/src/libINET.dll] Error 1
make[1]: Leaving directory '/c/omnetpp-5.1-src-windows/omnetpp-5.1/samples/inetmanet-3.x-inetmanet-3.5/src'

make: *** [Makefile:6: all] Error 2

Regards,
Rashad
-------------------------------------------------------------------------------

[Alfonso Ariza Quintana]

Have you rebuild the framework from scratch?

 

These errors are errors of the compiler and link, not of the framework.

[rashad kasim]

Hello Alfonso,
  I followed below step
1. Placed downloaded folder into the workspace folder C:\omnetpp-5.1-src-windows\omnetpp-5.1\samples
2. Opened omnetpp using mingwenv.cmd and imported the project into the workspace.
3. Once imported, then build the project.

I did the same procedure for INET and they are working fine. Is there something wrong I am doing..?
-----------------------------------

[Alfonso Ariza Quintana]

If you download the zip file from github, the showcases and tutorials directories will be empty because there are git submodules and the code are in the inet framework repository, in this case you can copy the code from inet-framework. Without the code in these directories the linker will fail

[rashad kasim]

Thanks a lot Alfonso.
It works now.

Regards,
Rashad

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[rashad kasim]

Hello Alfonso,
  I tried running "meshTestsimple", which come under "manetrouting" folder. It is working fine for reactive and proactive part separately. But when "Hwmp" is selected from the pop-up "set up Inifile Configuration", it is throwing error shown in the attached screenshot.
 Please let me know, why this is happening.

Regards,
Rashad

[Alfonso Ariza Quintana]

I have uploaded a modification that should solve the problem

 

It has some time that I don’t use the code and when I ported the latest inet medications I haven’t had time to test everything

[rashad kasim]

Thanks a lot Alfonso. It works now.

By reading other posts, I understand that the default metric is hopcount and it can changed to ALM by adding below lines in the ini file.
**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true
If the above changes are done, then I could see the parameters like above in the .sca file generated. But if above changes are not done, I could not see that Hop count in the .sca file. 
Can you confirm if above statements are right or not for the metric.

 Also is there any way where I can see the hopcount/ALM value for different paths.?

[Alfonso Ariza Quintana]

The hop count is not register in the file, it doesn’t sense if you consider that you have nodes at 1, 2, 3, … hops, the results can be the mean number of hops, it is an statistic that it doesn’t have sense, only if you divide the values in function of the source and destination can have sense.

[rashad kasim]

Hello Alfonso,
     I am stilll puzzled about the metric in HWMP. I created a 6 node scenario. In case 1, I did not make any modification in the init file. In case 2, I included below changes to make ALM as the metric.

**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true

The path taken from source to destination was same for both cases. I tried with different node positions and all cases came out identical.

My question is,
1. Am I missing something while setting ALM as the metric..?
2. Is there any way to check the metric used in the mesh during simulation in qtenv?

Regards,
Rashad

[Alfonso Ariza Quintana]

The Air time metric should be measured by the mac/physical sublayer, but the actual implementation of the mac/physical sublayer doesn’t measure it. The code of 802.11 physical and mac has been deeply changed and I haven’t had need to modify the code to include this metric.

[rashad kasim]

Hello Alfonso,
    First of all, thanks for your reply.
Due to my naivety, I could not understand completely. Were you saying that ALM implementation is there in the new code or it is not? Please clarify.

1. If implementation is there, please let me know if below addition in ini file make metric as ALM or it need anything additional.

**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true

2. Is there any indicator after simulation which says mesh metric is minHop or ALM..?

[Alfonso Ariza Quintana]

The air time link metric was computed by the mac and physical layer, the problem is that both layer are been completely rewritten and now they don’t compute this value, by default the metric used is min hop in this case.

 

It is necessary to modify the code if you want to compute this metric. It is the lower layers that know the information to compute this value is available (disf, sifs, data error rate …)

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 10 de octubre de 2017 0:15
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,

    First of all, thanks for your reply.
Due to my naivety, I could not understand completely. Were you saying that ALM implementation is there in the new code or it is not? Please clarify.

1. If implementation is there, please let me know if below addition in ini file make metric as ALM or it need anything additional.

**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true

2. Is there any indicator which says mesh metric is minHop or ALM..?

[rashad kasim]

Thanks Alfonso for clearing this issue.

Regards,
RK

[rashad kasim]

Hello Alfonse,
   I have one more trouble with mesh while using multi radio part (like the manetrouting example for multiradio).
I am adding below part into the .ini file
# number of radios per host
**.numRadios = 2
# number of channels used
**.mgmt.numChannels = 3
# wlan interface - radio channel assignemnt
**.fixhost[0].wlan[0].radio.channelNumber = 1 
**.fixhost[0].wlan[1].radio.channelNumber = 0
**.fixhost[1].wlan[0].radio.channelNumber = 1
**.fixhost[1].wlan[1].radio.channelNumber = 2
**.fixhost[2].wlan[0].radio.channelNumber = 2
**.fixhost[2].wlan[1].radio.channelNumber = 0

Issues:
1. fixhost[0] with channel=1 broadcasts the RREQ . Then Channel 1 of fixhost[1] receive the RREQ and it is broadcasted through channel 1 again. Broadcasting is not being done from channel 2. As a result, fixhost[2] is not able to receive the RREQ. Can you tell me why this is happening?. Ideally all the interface should be broadcasting RREQ right?

2. Why do the RREQ broadcasting starts with .wlan[0] not the other interface?.

Regards,
Rashad

[Alfonso Ariza Quintana]

 

The HWMP is implemented in the link layer, in the management, the multiradio won’t work, you will have several disjoint network that will need the network layer, in this case you will need a routing protocol in the network layer.

 

There is a possibility in the code, is the same management module with several radio interfaces and mac, it is implemented lake multimac. In this case you will have something like this

 

**.fixhost[0].wlanMesh.radio[0].channelNumber = 1 
**.fixhost[0].wlanMesh.radio[1].channelNumber = 2
**.fixhost[0].wlanMesh.radio[2].channelNumber = 3 
The same link layer module has several mac and radio interfaces.

[rashad kasim]

Hello Alfonso,
Thanks for the reply and your patience.

Like you suggested, I modified my .ini file like below.

**.fixhost[0].wlanMesh.radio[0].channelNumber = 1 
**.fixhost[0].wlanMesh.radio[1].channelNumber = 2
**.fixhost[0].wlanMesh.radio[2].channelNumber = 3

**.fixhost[1].wlanMesh.radio[0].channelNumber = 1 
**.fixhost[1].wlanMesh.radio[1].channelNumber = 2
**.fixhost[1].wlanMesh.radio[2].channelNumber = 3
**.fixhost[2].wlanMesh.radio[0].channelNumber = 1 
**.fixhost[2].wlanMesh.radio[1].channelNumber = 2
**.fixhost[2].wlanMesh.radio[2].channelNumber = 3

But the channel being used now is the default channelNumber 0 by all the nodes. Am I still missing something?

Regards,
Rashad

[Alfonso Ariza Quintana]

You need to configure the nodes in multichannel mac, it is a different type of interface that the common interface

[Alfonso Ariza Quintana]

https://github.com/aarizaq/inetmanet-3.x/blob/inetmanet-3.5/src/inet/linklayer/ieee80211mesh/nodes/HostMeshMulti.ned

[rashad kasim]

Hello Alfonso,
  I configured the node to be "HostMeshMulti" in place of "HostMesh" and **.numRadios = 3. But it was throwing below error upon running
" check_and_cast(): Cannot cast (inet::IPv4Datagram*)UDPBasicAppData-0 to type 'inet::EtherFrame *' -- in module (inet::ieee80211::Ieee80211MgmtAP) Hwmp_Performance_1.fixhost[0].wlan[0].mgmt"
The above error is thrown when UDP data packet start to be sent. What exactly is happening here?

Also from  the connection part of code from "HostMeshMulti.ned", it looks like with numRadios=3, there will be 3 Wlan interface and one wlanmesh interface (since default meshChannels=1). Hence channelnumber is shown as 0 for wlan thrice and channelnumber 1 is assigned to wlanmesh. It does not create channelnumber=2 and 3 as it can be created only with more meshchannels.

Issue2: When meshchannels is made more than 1, I am getting below error
" addInterface(): interface 'wlanMesh' already registered -- in module (inet::ieee80211::Ieee80211Mac) Hwmp_Performance_1.fixhost[0].wlanMesh.mac[1] (id=63), during network initialization"

Please find the .ini file and .ned attached along, to reproduce the issue.

Thanks for your patience
RK

On Monday, October 16, 2017 at 2:06:20 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

Strange, Ieee80211MgmtAP is the AP not the Ieee80211Mesh in the management module

 

In any case, I need to check the multimac with the new 802.11 implementation, this multimac implementation was for the old 802.11 code and the new has change a lots things.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: lunes, 16 de octubre de 2017 17:47
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,

  I configured the node to be "HostMeshMulti" in place of "HostMesh" and **.numRadios = 3. But it was throwing below error upon running
" check_and_cast(): Cannot cast (inet::IPv4Datagram*)UDPBasicAppData-0 to type 'inet::EtherFrame *' -- in module (inet::ieee80211::Ieee80211MgmtAP) Hwmp_Performance_1.fixhost[0].wlan[0].mgmt"
The above error is thrown when UDP data packet start to be sent. What exactly is happening here?

Also from  the connection part of code from "HostMeshMulti.ned", it looks like with numRadios=3, there will be 3 Wlan interface and one wlanmesh interface (since default meshChannels=1). Hence channelnumber is shown as 0 for wlan thrice and channelnumber 1 is assigned to wlan. It does not create channelnumber=2 and 3 as it can be created only with more meshchannels.

Issue2: When meshchannels is made more than 1, I am getting below error

" addInterface(): interface 'wlanMesh' already registered -- in module (inet::ieee80211::Ieee80211Mac) Kavis5_Hwmp_Performance_1.fixhost[0].wlanMesh.mac[1] (id=63), during network initialization"

Please find the .ini file and .ned attached along, to reproduce the issue.

Thanks for your patience
RK

On Monday, October 16, 2017 at 2:06:20 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

And I know that there are failures, I implemented this code for several test that I finished and I haven’t need to use other time with inet 3.5-3.6. I don’t have time to test it

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: lunes, 16 de octubre de 2017 17:47
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,

  I configured the node to be "HostMeshMulti" in place of "HostMesh" and **.numRadios = 3. But it was throwing below error upon running
" check_and_cast(): Cannot cast (inet::IPv4Datagram*)UDPBasicAppData-0 to type 'inet::EtherFrame *' -- in module (inet::ieee80211::Ieee80211MgmtAP) Hwmp_Performance_1.fixhost[0].wlan[0].mgmt"
The above error is thrown when UDP data packet start to be sent. What exactly is happening here?

Also from  the connection part of code from "HostMeshMulti.ned", it looks like with numRadios=3, there will be 3 Wlan interface and one wlanmesh interface (since default meshChannels=1). Hence channelnumber is shown as 0 for wlan thrice and channelnumber 1 is assigned to wlan. It does not create channelnumber=2 and 3 as it can be created only with more meshchannels.

Issue2: When meshchannels is made more than 1, I am getting below error

" addInterface(): interface 'wlanMesh' already registered -- in module (inet::ieee80211::Ieee80211Mac) Kavis5_Hwmp_Performance_1.fixhost[0].wlanMesh.mac[1] (id=63), during network initialization"

Please find the .ini file and .ned attached along, to reproduce the issue.

Thanks for your patience
RK

On Monday, October 16, 2017 at 2:06:20 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

Hello Alfonso,
I understand you are busy, but it would be great if you could fix those if they are really an issue.

Also, is there any way I can implement just multichannel in HWMP not multi-radio?

Thanks a lot!!

On Monday, October 16, 2017 at 9:26:02 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

I have fix the problems and here you can see an example

 

https://github.com/aarizaq/inetmanet-3.x/tree/inetmanet-3.5/examples/manetrouting/meshTest

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 17 de octubre de 2017 9:03
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,

[rashad kasim]

Thanks a lot Alfonso.
  interface registry issue is solved for HostMeshMulti with the new change. But the first issue of casting the ethernet frame in Ieee80211MgmtAP still exist. This issue is happening only for the HostMeshMulti not for HostMesh. It would be great if you could look into this issue as well


Regards,
Rashad


On Tuesday, October 17, 2017 at 1:04:16 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

You have bad configured the routing tables and the nodes.

 

The wlan[0], wlan[1] and wlan[2] have the configuration of AP, and are connected to the network layer, and AP must be connected to an Ethernet, the default route sents the ip frame to the interface wlan[0] and this throw and error. The intervade should be ad-hop. If you want to use the mesh interface the default route must be this interface.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 17 de octubre de 2017 16:13
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Thanks a lot Alfonso.

[rashad kasim]

Dear Alfonso,
  Thanks for the prompt replies.
Though I did not completely understand your answer, I have added like below and the error is gone. Now the previous error of ethernet frame cast issue does not happen anymore.
**.fixhost[*].autoconfigurator.interfaces = "wlanMesh wlan0"#"wlan0"
**.fixhost[*].autoconfigurator.defaultInterface = "wlanMesh"#"wlan0"
**.fixhost[*].autoconfigurator.addressBaseList = "192.168.0.0 192.168.0.0"#"192.168.0.0"
**.fixhost[*].autoconfigurator.addressMask = "255.255.0.0 255.255.0.0"#"255.255.0.0"

Topology
Node1 ===========Node2===========Node3 

Now I have another issue, PREP is not getting ACK from Node1 to Node2. As a result UDP packet transfer is not happening.
Sequence of happenings:
1. Node1 sents RREQ
2. Then Node2 sent RREQ
3. Now Node3 sent RREP and Node2 sent ACK
4. Node2 sent RREP but no ACK is sent by node1. It says "This frame is not for us"

Note: Node1 and 3 are far away that they can not communication directly.

On Tuesday, October 17, 2017 at 6:13:14 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

While playing around the configuration, I made **.numRadios = 0, then ACK was not given for PREP from node2. Same case happened when **.numRadios = 2.
The one explained in the previous post was for **.numRadios = 1 (which looks logical as I was thinking for one wlan)

Is this some random observation or it has something to do with the operation?

Thanks!

[Alfonso Ariza Quintana]

I don’t understand you question, if you use the mesh node you will have at least a radio interface in the wlanMesh, even with numRadios = 0.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: miércoles, 18 de octubre de 2017 22:26
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

While playing around the configuration, I made **.numRadios = 0, then ACK was not given for PREP from node2. Same case happened when **.numRadios = 2.

[Alfonso Ariza Quintana]

In this case the default interface is the wlanMesh

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: miércoles, 18 de octubre de 2017 16:58
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

  Thanks for the prompt replies.
Though I did not completely understand your answer, I have added like below and the error is gone. Now the previous error of ethernet frame cast issue does not happen anymore.
**.fixhost[*].autoconfigurator.interfaces = "wlanMesh wlan0"#"wlan0"
**.fixhost[*].autoconfigurator.defaultInterface = "wlanMesh"#"wlan0"
**.fixhost[*].autoconfigurator.addressBaseList = "192.168.0.0 192.168.0.0"#"192.168.0.0"
**.fixhost[*].autoconfigurator.addressMask = "255.255.0.0 255.255.0.0"#"255.255.0.0"

Topology
Node1 ===========Node2===========Node3 

Now I have another issue, PREP is not getting ACK from Node1 to Node2. As a result UDP packet transfer is not happening.
Sequence of happenings:

1. Node1 sents RREQ and Node2 sent ACK
2. Then Node2 sent RREQ and Node3 sent ACK.

3. Now Node3 sent RREP and Node2 sent ACK
4. Node2 sent RREP but no ACK is sent by node1. It says "This frame is not for us"

Note: Node1 and 3 are far away that they can not communication directly.

On Tuesday, October 17, 2017 at 6:13:14 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

Dear Alfonso,
Sorry about the unclear way the question was asked.
The observation about the **.numRadios was posted after changing its number and seeing any change.

My actual question was for below topology using multi-radio:
Topology
Node1 ===========Node2===========Node3 

PREP is not getting ACK from Node1 to Node2. As a result UDP packet transfer is not even starting.

Sequence of happenings:
1. Node1 sents RREQ
2. Then Node2 sent RREQ
3. Now Node3 sent RREP and Node2 sent ACK
4. Node2 sent RREP but no ACK is sent by node1. It says "This frame is not for us"

 
I am attaching the log file and .ini file along.
Thanks for your help!

On Thursday, October 19, 2017 at 10:57:56 AM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

Hello Alfonso,
I tried with some different combination of meshChannel and numRadios like below
1. **.numRadios = 0 and.meshChannels = 1: It works
2. **.numRadios = 0 and.meshChannels = 2: It works
3. **.numRadios = 1 and.meshChannels = 2:  Not working. Node1 is not sending ACK to Node2 for PREP.
4. **.numRadios = 2 and.meshChannels = 2:  It works
5. **.numRadios = 0 and.meshChannels = 3:  Not working. Node2 is not sending ACK to Node3 for PREP.
6. **.numRadios = 1 and.meshChannels = 3:  Not working. Node1 is not sending ACK to Node2 for PREP.
7. **.numRadios = 2 and.meshChannels = 3:  Not working. Node2 is not sending ACK to Node3 for PREP.
8. **.numRadios = 3 and.meshChannels = 3:  Not working. Node2 is not sending ACK to Node3 for PREP.

Why is this happening like this?

Regards,
Rashad

[Alfonso Ariza Quintana]

In the trace, can you see if the message arrives?

 

I don’t have the scenario that you are testing

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: jueves, 19 de octubre de 2017 13:38
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,

[rashad kasim]

The reason I started to try applying multi-channel case is because single channel scenario has almost 50% loss for every hop. So if I start with 20Mbps, first hop output is 10.5Mbps and its reduces exponentially with number of hops. So from literature review, I read that multi-channel scenario, improve the case as it happens as a result of collision.
Please correct me if I am wrong.

Regards,
Rashad

On Thursday, October 19, 2017 at 8:12:08 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

the trace doesn't contain the send/ack sequence. I have uploaded a modification that should solve the problem, the different mac now have the same address now and this should prevent the problem

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>
Enviado: jueves, 19 de octubre de 2017 21:01
Para: OMNeT++ Users

Asunto: Re: [Omnetpp-l] HWMP in omnet++

[rashad kasim]

Thanks a tonne Alonso,
   Now its working super cool :)

Now I am using HostMesh as an access point. Will the same work with HostMesh as full mesh node as well?. I am just curious to know this.

Regards,
Rashad

[rashad kasim]

Dear Alfonso,
    Like I told before, it was working fine for a single hop network. Now I extended it to 2 hop network with everything same except adding one extra node between source and target and distance is increase so that there will be 2 hop between source and target.
Now I am getting an error like below
" Not interface register -- in module (inet::HostAutoConfigurator2) Hwmp_Performance2.fixhost[0].autoconfigurator (id=45), during network initialization"

Can you tell me if I have to do anymore change?

 Please find the .ini and .ned file for recreating the issue.

[rashad kasim]

Hello Alfonso,
   The error was happening as a result of not using HostMestMulti. It was a silly mistake from my side. I apologize :)

On Monday, October 23, 2017 at 1:09:36 PM UTC+3, rashad kasim wrote:

Dear Alfonso,
    Like I told before, it was working fine for a single hop network. Now I extended it to 2 hop network with everything same except adding one extra node between source and target and distance is increase so that there will be 2 hop between source and target.
Now I am getting an error like below

" Not interface register -- in module (inet::HostAutoConfigurator2) Kavis9_Hwmp_Performance2.fixhost[0].autoconfigurator (id=45), during network initialization"

[Alfonso Ariza Quintana]

In any case the HostAutoConfigurator2 allows to include nodes that only have defined the link layer, the default configurator assume that they have the link layer, but in this case, there are the possibility that some nodes could have defined only the lower layers.

The other advantage is that it allows the configuration of nodes that have been created dynamically in middle of the simulation.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: lunes, 23 de octubre de 2017 12:10
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

    Like I told before, it was working fine for a single hop network. Now I extended it to 2 hop network with everything same except adding one extra node between source and target and distance is increase so that there will be 2 hop between source and target.
Now I am getting an error like below

" Not interface register -- in module (inet::HostAutoConfigurator2) Kavis9_Hwmp_Performance2.fixhost[0].autoconfigurator (id=45), during network initialization"

Can you tell me if I have to do anymore change?

 Please find the .ini and .ned file for recreating the issue.

On Friday, October 20, 2017 at 12:53:26 AM UTC+3, Alfonso Ariza Quintana wrote:

the trace doesn't contain the send/ack sequence. I have uploaded a modification that should solve the problem, the different mac now have the same address now and this should prevent the problem

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>
Enviado: jueves, 19 de octubre de 2017 21:01
Para: OMNeT++ Users
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

The reason I started to try applying multi-channel case is because single channel scenario has almost 50% loss for every hop. So if I start with 20Mbps, first hop output is 10.5Mbps and its reduces exponentially with number of hops. So from literature review, I read that multi-channel scenario, improve the case as it happens as a result of collision.
Please correct me if I am wrong.

Regards,
Rashad

On Thursday, October 19, 2017 at 8:12:08 PM UTC+3, Alfonso Ariza Quintana wrote:

 

[rashad kasim]

Thanks a lot Alfonso,
   I will check those.

I also would like to ask a general question on improving throughput of mesh. Previously I was using single channel mesh which give only 1/n of throughput after n hops. When multichannel mesh was used, throughput improved to good amount but again not beyond 3 hops. So the question I have is, Is there is any other way to improve end to end throughput in mesh?

On Monday, October 23, 2017 at 2:01:27 PM UTC+3, Alfonso Ariza Quintana wrote:

[Alfonso Ariza Quintana]

http://journals.plos.org/plosone/article/authors?id=10.1371/journal.pone.0119679

 

 

 

Enviado desde Correo para Windows 10

 

De: rashad kasim
Enviado: martes, 24 de octubre de 2017 12:49
Para: OMNeT++ Users
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Thanks a lot Alfonso,

[rashad kasim]

Hello Alfonso,
  I have simulated a single hop network and 5 hop network using single channel and 4 channel scenario. Throughput vs packetsize and delay vs packetsize is plotted for the scenarios and are shown in the attachments.
I am wondering why there is an abnormal behaviour for 4 channel 1 hop delay vs packetsize plot for lower packetsizes ? (As per literature I did, delay increases with packetsize) . Also some similar abnormal observation for throughput vs packetsize for lower packetsizes are also observed. Any reason behind this?

[Alfonso Ariza Quintana]

The multimac scenario is a bit tricky, if the upper layer detect the a mac is busy it search a mac that is in idle state or the mac that has the lower frames in the queue, if you increase the packer size you increase the number of frames in parallel that the interface can transmit, probably the interface is transmitting 4 frames in parallel.

[rashad kasim]

Thanks Alfonso :)

On Tuesday, October 31, 2017 at 5:39:05 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

Dear Alfonso,

  I have one more question.

When I used 802.11a by using below piece of code, carrier frequency is still in 2.4GHz. For 802.11a, the band used is 5GHz right?

**.opMode = "a"

**.bitrate = 54Mbps

Observation:

 datamode = { Ieee80211OFDMDataMode},  

datarate =  2.4e+007 bps, 

carrierFrequency = 2.412e+009 Hz and

 bandwidth = 2e+006 Hz

Also the bandwidth of wifi channels are 20MHz right. Is it not 2MHz which is shown here (The same is coming for 802.11g as well)

Regards,

Rashad

On Tuesday, October 31, 2017 at 5:39:05 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

There was some typo error in the last question. It has been edited.

[Alfonso Ariza Quintana]

Yes the channels bandwidth is 20MHz, but these value only affect to compute the interference with other channels

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: miércoles, 01 de noviembre de 2017 15:19
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

  I have one more question.

When I used 802.11b by using below piece of code, carrier frequency is still in 2.4GHz. For 802.11b, the band used is 5GHz right?

**.opMode = "b"

**.bitrate = 11Mbps

 

Observation:

 mode = { Ieee80211HrDsssMode },  

bitrate = 1.1e+007 bps, 

carrierFrequency = 2.412e+009 Hz and

 bandwidth = 2e+006 Hz

 

Also the bandwidth of wifi channels are 20MHz right. Is it not 2MHz which is shown here (The same is coming for 802.11g as well)

 

Regards,

Rashad

On Tuesday, October 31, 2017 at 5:39:05 PM UTC+3, Alfonso Ariza Quintana wrote:

[rashad kasim]

Dear Alfonso,

   Also please let me know why carrier frequency is coming as 2.412e+009 Hz for 802.11a. It should in 5GHz range right?

Regards,

RK

[Alfonso Ariza Quintana]

In the standad

 

18.3.8.4 Operating channel frequencies

18.3.8.4.1 Operating frequency range

The OFDM PHY shall not operate in frequency bands not allocated by a regulatory body in its operational

region. Regulatory requirements for a given frequency band are set by the regulatory authority responsible

for spectrum management in a given geographic region or domain. The particular channelization to be used

for this standard is dependent on such allocation, as well as the associated regulations for use of the

allocations. These regulations are subject to revision, or may be superseded.

In some regulatory domains, several frequency bands may be available for OFDM PHY-based WLANs.

These bands may be contiguous or not, and different regulatory limits may be applicable. A compliant

OFDM PHY shall support at least one frequency band in at least one regulatory domain. The support of

specific regulatory domains, and bands within the domains, shall be indicated by PLME attributes

dot11RegDomainsImplementedValue and dot11FrequencyBandsImplemented.

The OFDM PHY shall use dot11CurrentFrequency to determine the operating frequency.

18.3.8.4.2 Channel numbering

Channel center frequencies are defined at every integral multiple of 5 MHz above Channel starting

frequency. The relationship between center frequency and channel number is given by Equation (18-27):

Channel center frequency = Channel starting frequency + 5 × nch (MHz) (18-27)

where

nch = 1,…200.

Channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz or

is defined as 5 GHz for systems where dot11OperatingClassesRequired is

false or not defined.

For example, dot11ChannelStartingFactor = 10000 indicates that Channel 0 center frequency is 5.000 GHz.

A channel center frequency of 5.000 GHz shall be indicated by dot11ChannelStartingFactor = 8000 and nch

= 200. An SME managing multiple channel sets can change the channel set being managed by changing the

value of dot11ChannelStartingFactor.

This definition provides a unique numbering system for all channels with 5 MHz between center

frequencies, as well as the flexibility to define channelization sets for all current and future regulatory

domains.

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: jueves, 02 de noviembre de 2017 11:57
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

[rashad kasim]

Dear Alfonso,

 Thanks a lot for your time answering my question, but I am a bit confused about your reply.

  My question was why is carrier frequency is coming as 2.412e+009 Hz for 802.11a. As per the specification, 802.11a should be operating in frequencies coming in the range of 5GHz right..? Or am I wrong..?

I have below situation:

There are 3 types of nodes: NodeA, NodeB and NodeC.

 NodeA has 802.11a wifi, NodeB has both 802.11a anf 802.11g. NodeC has 802.11g. 

So NodeB is a hybrid node. How do we do that in omnet++? 

[Alfonso Ariza Quintana]

For 802.11a the channel 0 is at 5GHz

[rashad kasim]

Hello Alfonso,

I am getting carrierFrequency as 2.412e+009 Hz as opposite to what you told. Why is this happening?

I used below piece of code:

**.opMode = "a"

**.bitrate = 54Mbps

During simulation, below observation is obtained from the trace.

Observation:

 datamode = { Ieee80211OFDMDataMode},  

datarate =  2.4e+007 bps, 

carrierFrequency = 2.412e+009 Hz and

 bandwidth = 2e+006 Hz

[Alfonso Ariza Quintana]

**.wlan[*].radio.transmitter.carrierFrequency = 5.9GHz

 

Not

 

**wlan[*].radio.carrierFrequency = 5.9GHz

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: jueves, 02 de noviembre de 2017 14:39
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Please find the .ned and .ini files for reproducing the observation.

 

Regards,

RK

[rashad kasim]

Dear Alfonso,

    It did not change anything. The carrier frequency is still shown as  2.412e+009 Hz. Also, if the wifi std to be used is 802.11a, then automatically the carrier frequency should be in the range of 5GHz right..?. Am I missing something here?

Regards,

Rashad

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[rashad kasim]

Also, it would be great if could tell me how to create a network with a hybrid node. Hybrid node for me is an AP which deals with 2 wifi (802.11a and 802.11g) and UE only dealing with 802.11g

AP[0]-------------------------------------------------AP[1]------------------------------------------UE

                           802.11a                                                   802.11g

I tried .ini file like below, but no help

# nic settings

**.UE**.wlan[*].opMode = "g(mixed)"

**.AP**.wlan[*].opMode = "a"

If I make, both UE and AP to be one of the standard, then it works. What is the way to AP having interface for both wifi standards.

Regards,

Rashad

[rashad kasim]

Hello Alfonso,

I used like below in .ini file

# nic settings

**.UE**.wlan[0].opMode = "g(mixed)"

**.AP**.wlan[0].opMode =  "g(mixed)"

**.AP**.wlanmesh.radio[0].opMode ="a"

It make all the node to work like g(mixed), which is the default wifi std.

But when I try in .ini file like below

# nic settings

**.UE**.wlan[0].opMode = "a"

**.AP**.wlan[0].opMode =  "a"

**.AP**.wlanmesh.radio[0].opMode ="g(mixed)"

Between APs it work with 802.11g and between AP and UE it works with 802.11a. 

Why is it not working as expected in the first case? 

Regards,

Rashad

[rashad kasim]

Hello,

  it works now with below configuration

**.UE**.wlan[0].opMode = "g(mixed)"

**.AP**.wlan[0].opMode = "g(mixed)"

**.opMode = "a"

Eventhough, connection between APs are in 802.11a, the carrier frequency is set purely based on the channel selected (not based on the wifi standard). For wlan[0], assigned channelnumber is 1. Hence, its carrier frequency is always 2.417GHz(it is fine in this case since it use 802.11g). For other interfaces, the channel assigned is ChannelNumber 0. For those case, the carrier frequency will be 2.412GHz eventhough its in 802.11a mode (which should be in 5GHz range).

Can you please confirm?

Regards,

Rashad

[Alfonso Ariza Quintana]

If you want to use other carrier frequency, you need to set in the configuration, by default is 2.4GHz

 

**.wlan[*].radio.transmitter.carrierFrequency = 5.9GHz

 

 

Enviado desde Correo para Windows 10

 

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>

Enviado: Monday, November 6, 2017 10:05:38 AM
Para: OMNeT++ Users

[rashad kasim]

Dear Alfonso,

   Is there any other way to change the value of frequency? I tried all the possible way from my side

Regards,

Rashad

On Monday, November 6, 2017 at 4:15:42 PM UTC+3, rashad kasim wrote:

Hello Alfonso,

   I tried adding below part in .ini file

**.wlan[*].radio.transmitter.carrierFrequency=5.9GHz
But the carrier frequency is still in 2.4GHz range.In the .ini file, it is shown that this is an "unused entry".

I also tried with  **.carrierFrequency=5.9GHz.  But the frequency is still the same. While keeping the mouse pointer on this entry it says that it belongs to either one of the below

:

 

MediumLimitCache.carrierFrequency

NarrowbandRadioBase.carrierFrequency

I am attaching my .ini file and .ned file. Can you please check it from your side. 

Regards,

Rashad

[rashad kasim]

Dear Alfonso,

    The carrier frequency is now set to 5GHz and its done by below line

**.bandName="5 GHz". 


Setting **.carrierFrequency=5GHz do not cause any difference.
Thanks and Regards,

Rashad

[Alfonso Ariza Quintana]

It is both, first you select the band, and later you assign the carrier, for example

 

**.bandName="5 GHz"

**.carrierFrequency=5.4GHz

 

Enviado desde Correo para Windows 10

 

De: rashad kasim
Enviado: martes, 7 de noviembre de 2017 12:51
Para: OMNeT++ Users
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

    The carrier frequency is now set to 5GHz and its done by below line

**.bandName="5 GHz"

Setting **.carrierFrequency=5GHz do not cause any difference.
Thanks and Regards,

Rashad

On Tuesday, November 7, 2017 at 2:29:19 PM UTC+3, rashad kasim wrote:

Dear Alfonso,

   Is there any other way to change the value of frequency? I tried all the possible way from my side

 

Regards,

Rashad

On Monday, November 6, 2017 at 4:15:42 PM UTC+3, rashad kasim wrote:

Hello Alfonso,

   I tried adding below part in .ini file

**.wlan[*].radio.transmitter.carrierFrequency=5.9GHz
But the carrier frequency is still in 2.4GHz range.In the .ini file, it is shown that this is an "unused entry".

 

I also tried with  **.carrierFrequency=5.9GHz.  But the frequency is still the same. While keeping the mouse pointer on this entry it says that it belongs to either one of the below

:

 

MediumLimitCache.carrierFrequency

NarrowbandRadioBase.carrierFrequency

 

 

I am attaching my .ini file and .ned file. Can you please check it from your side. 

 

Regards,

Rashad
On Monday, November 6, 2017 at 1:40:29 PM UTC+3, Alfonso Ariza Quintana wrote:

If you want to use other carrier frequency, you need to set in the configuration, by default is 2.4GHz

 

**.wlan[*].radio.transmitter.carrierFrequency = 5.9GHz

 

 

Enviado desde Correo para Windows 10

 

[Alfonso Ariza Quintana]

Or at least it should be, because the radio has these parameter.

But in the code I cannot find where is read.

 

 

Enviado desde Correo para Windows 10

 

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de Alfonso Ariza Quintana <aari...@hotmail.com>
Enviado: Tuesday, November 7, 2017 1:01:47 PM
Para: omn...@googlegroups.com
Asunto: RE: [Omnetpp-l] HWMP in omnet++

 

[rashad kasim]

Thanks Alfonso,

I understand.

 But I have one more issue. 

When the **.bandName="2.4 GHz", everything is working fine.  

But when **.bandName="5 GHz", STA and AP does not interact and below the message is found from trace

"STA is not associated with an access point, discarding packet(inet::IPv4Datagram)VideoStrmReq". Same problem happen for **.bandName="5.9 GHz"

what could be the problem here?

Regards,

Rashad

[Alfonso Ariza Quintana]

You need to check if the node receives the bacon frame of the AP correctly.

 

 

Enviado desde Correo para Windows 10

 

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>
Enviado: Tuesday, November 7, 2017 1:40:42 PM

[rashad kasim]

Hello Alfonso,

  None of the nodes are receiving beacon frame of any other nodes.

[Levente Mészáros]

I added the following lines to examples/wireless/lan80211/omnetpp.ini. The example works as expected, it sends packets in the 5GHz band according to the simulation log. It also correctly prints the statistics of received ping replies. Perhaps you should increase the transmitter power, because in the 5 GHz band signals lose power more quickly.

**.bandName = "5 GHz"

**.wlan[*].radio.transmitter.power = 200mW

**.printPing = true

I run the test with the upcoming 4.0 version but I think it should work with 3.6 as well.

levy

On Tue, Nov 7, 2017 at 3:37 PM, rashad kasim <rasha...@gmail.com> wrote:

Is it because, the source code need change for frequency outside 2.4GHz (ie 5GHz and 5.9GHz) ?

Please let me know me if you have any thoughts on this.

.ned and .ini is attached along

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.

[rashad kasim]

Yeah. Thanks a lot of Levy. Now its working 

[rashad kasim]

Hello Alfonso,

  I have another situation. Till now I have been using APMeshRelay as the AP. Since it does not have multichannel feature, I am trying with APMeshNode.

Below was the configuration used:

**.fixhost*[*].autoconfigurator.interfaces = "wlanMesh wlan0"

**.fixhost*[*].autoconfigurator.defaultInterface = "wlanMesh"

**.fixhost*[*].autoconfigurator.defaultAddressInterface = "wlanMesh"

**.fixhost*[*].autoconfigurator.addressBaseList = "192.168.0.0 192.168.0.0"

**.fixhost*[*].autoconfigurator.addressMask = "255.255.0.0 255.255.0.0"

 Error happened even before initialization process got completed and it says "Configurator module 'configurator' not found"

Then I added IPv4NetworkConfigurator (which I am not sure if its correct or not). Now initialization is successful, but after VideoStrmReq is received, its says

"(inet::EthernetIIFrame)VideoStrmReq: Unexpected packet type -- in module (inet::IPv4) meshAP1.fixhost4[3].networkLayer.ip"

Am I suppose to do any extra configuration if I am using APMeshNode in place of APMeshRelay?

Thank you so much for all your support.

[Alfonso Ariza Quintana]

APMeshRelay doesn’t has autoconfigurator module, it doesn’t need it, it doesn’t have network layer.

[rashad kasim]

Dear Alfonso,

Thanks for your reply.

  In the above question, I was already using autoconfigurator module. But it was saying "Unexpected packet type" when AP completes the  VideoStrmReq reception.

I was asking, if I have missed anything else.

Thanks and regards 

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/ie9LqMrW_aA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+unsubscribe@googlegroups.com.

[Alfonso Ariza Quintana]

With this information I don’t know what is the source of problems, but if both interfaces are in the same channel you can have problems

 

Enviado desde Correo para Windows 10

 

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>

Enviado: Friday, November 10, 2017 12:45:02 PM
Para: omn...@googlegroups.com

[Alfonso Ariza Quintana]

You are using a network layer in an AP, the AP doesn't have network layer.

---

De: omn...@googlegroups.com <omn...@googlegroups.com> en nombre de rashad kasim <rasha...@gmail.com>

Enviado: viernes, 10 de noviembre de 2017 13:38

Para: omn...@googlegroups.com
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Dear Alfonso,

Both the interface are using different channel like below

**.wlanMesh.radio[0].channelNumber = 0

**.meshHost[*].wlan[0].radio.channelNumber = 1

Also both interface are in different band.

Please find the .ned and .ini file which I used. 

Let me know if you could understand the problem

[rashad kasim]

Dear Alfonso,

  Thanks for the reply. I guess I have issue with understanding a bit of basics of AP configuring of various nodes like APMeshRelay and APMeshNode. It would be great if you could point some example to understand those concept clearly.

Like I told before, when I used APMeshRelay, I did not use configure anything for network layer. Everything was working fine. But for node APMeshNode to work I had to use IPv4NetworkConfigurator. Else it will throw some error. So what exactly do I have to do here?

Sorry about asking these kind of simple questions. But I could not sort out any other way.

Regards,

RK

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim

[Alfonso Ariza Quintana]

An AP works at the link layer level, it doesn’t have network layer. The ApMeshRelay, has a interface in infrastructure mode and other in mesh mode and it allows that a node that Works in mode infrastructure, that is the common configuration for nodes, could connect to the mesh network, an every work at the link layer level.

If you use a node with network layer, you will have subnetworks,

--

[rashad kasim]

Hello Alfonso,

   While using a simple network with APMeshNode and a MeshSta, I found an issue with channelNumber allocation of MeshSta.

Below is the a part of .ini file

**meshHost**.numRadios=2

**fixhost**.wlan[0].radio.channelNumber = 10

**.wlan[1]**.channelNumber = 10 #The second radio is automatically given 5GHz band.

**.wlanMesh.radio[0].channelNumber = 2

**.wlan[0]**.channelNumber = 2   #This is not making meshHost.wlan[0].**.channel to 2. Its still 1. Even below statement is not changing it.

**.channelNumber = 11

During the initial beacon process. channelNumber of meshHost.wlan[0] is 2. But after a while its automatically changing to channelNumber 1. Whatever the initial channelNumber is, after a while it is automatically changing to ChannelNumber 1. It looks like an issue. Can you confirm please.

On Tuesday, November 14, 2017 at 1:24:57 PM UTC+3, rashad kasim wrote:

Now I understand.

 Thanks a lot Alfonso for the information.

Now I am trying to extend the APMeshRelay node to use multichannel by referring hostMeshMulti node's code. I extended the code as shown in the attachment. It works fine when **.meshChannels = 1 (like normal single channel mesh). 

But when **.meshChannels = 2, error happens saying "Gate 'ifOut[2]' of compound module **.relayUnit is not connected on the outside, upon arrival of message (inet::EthernetIIFrame)VideoStrmReq". 

Do you know why this is happening? 

Regards,

Rashad

[Alfonso Ariza Quintana]

I will try to test. I need to find some free time J . The classes and exams let scarce free time

[rashad kasim]

It does not have any dependency on my simulation. Just observed this unewhile going around. :)

Thanks,

RK

[rashad kasim]

Dear Alfonso,  

   I was just wondering a situation shown below

MeshNode1--------APMeshRelay1--------------APMeshRelay2------------MeshNode2.

Here MeshNode1 is the server and MeshNode2 is the source. So MeshNode2 sent PREQ and it reaches MeshNode1 through APs. But when MeshNode1 sent back PREP, at APMeshRelay1 it says "this frame is not for us". Hence, no further connection happens.

Channels are configured like below:

**.meshHost**.wlan[0].radio.channelNumber = 0 

**.wlanMesh.radio[0].channelNumber = 0 

**.wlan[0].radio.channelNumber = 1

[rashad kasim]

Dear Alfonso,

   Can you please guide me to make the modification to use ALM.

Much obliged,

RK

On Tuesday, October 10, 2017 at 7:18:06 PM UTC+3, Alfonso Ariza Quintana wrote:

The air time link metric was computed by the mac and physical layer, the problem is that both layer are been completely rewritten and now they don’t compute this value, by default the metric used is min hop in this case.

 

It is necessary to modify the code if you want to compute this metric. It is the lower layers that know the information to compute this value is available (disf, sifs, data error rate …)

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 10 de octubre de 2017 0:15
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,
    First of all, thanks for your reply.
Due to my naivety, I could not understand completely. Were you saying that ALM implementation is there in the new code or it is not? Please clarify.

1. If implementation is there, please let me know if below addition in ini file make metric as ALM or it need anything additional.
**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true

2. Is there any indicator which says mesh metric is minHop or ALM..?

On Thursday, September 28, 2017 at 6:00:35 PM UTC+3, Alfonso Ariza Quintana wrote:

The Air time metric should be measured by the mac/physical sublayer, but the actual implementation of the mac/physical sublayer doesn’t measure it. The code of 802.11 physical and mac has been deeply changed and I haven’t had need to modify the code to include this metric.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: jueves, 28 de septiembre de 2017 16:36
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,
     I am stilll puzzled about the metric in HWMP. I created a 6 node scenario. In case 1, I did not make any modification in the init file. In case 2, I included below changes to make ALM as the metric.
**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true
The path taken from source to destination was same for both cases. I tried with different node positions and all cases came out identical.

My question is,
1. Am I missing something while setting ALM as the metric..?
2. Is there any way to check the metric used in the mesh during simulation in qtenv?

Regards,
Rashad

On Thursday, September 21, 2017 at 1:00:24 PM UTC+3, Alfonso Ariza Quintana wrote:

The hop count is not register in the file, it doesn’t sense if you consider that you have nodes at 1, 2, 3, … hops, the results can be the mean number of hops, it is an statistic that it doesn’t have sense, only if you divide the values in function of the source and destination can have sense.

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: jueves, 21 de septiembre de 2017 11:51
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Thanks a lot Alfonso. It works now.

By reading other posts, I understand that the default metric is hopcount and it can changed to ALM by adding below lines in the ini file.
**.minHopCost = false
**.ETXEstimate = true
**.airtimeLinkComputation = true
If the above changes are done, then I could see the parameters like above in the .sca file generated. But if above changes are not done, I could not see that Hop count in the .sca file. 
Can you confirm if above statements are right or not for the metric.

 Also is there any way where I can see the hopcount/ALM value for different paths.?



On Wednesday, September 20, 2017 at 8:18:55 PM UTC+3, Alfonso Ariza Quintana wrote:

I have uploaded a modification that should solve the problem

 

It has some time that I don’t use the code and when I ported the latest inet medications I haven’t had time to test everything

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: miércoles, 20 de septiembre de 2017 15:40
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,
  I tried running "meshTestsimple", which come under "manetrouting" folder. It is working fine for reactive and proactive part separately. But when "Hwmp" is selected from the pop-up "set up Inifile Configuration", it is throwing error shown in the attached screenshot.
 Please let me know, why this is happening.

Regards,
Rashad


On Tuesday, September 19, 2017 at 3:28:58 PM UTC+3, rashad kasim wrote:

Thanks a lot Alfonso.
It works now.

Regards,
Rashad

On Tuesday, September 19, 2017 at 1:14:08 PM UTC+3, Alfonso Ariza Quintana wrote:

If you download the zip file from github, the showcases and tutorials directories will be empty because there are git submodules and the code are in the inet framework repository, in this case you can copy the code from inet-framework. Without the code in these directories the linker will fail

 

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 19 de septiembre de 2017 10:30
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Hello Alfonso,
  I followed below step
1. Placed downloaded folder into the workspace folder C:\omnetpp-5.1-src-windows\omnetpp-5.1\samples
2. Opened omnetpp using mingwenv.cmd and imported the project into the workspace.
3. Once imported, then build the project.

I did the same procedure for INET and they are working fine. Is there something wrong I am doing..?
-----------------------------------

On Tuesday, September 19, 2017 at 11:24:42 AM UTC+3, Alfonso Ariza Quintana wrote:

Have you rebuild the framework from scratch?

 

These errors are errors of the compiler and link, not of the framework.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de rashad kasim
Enviado el: martes, 19 de septiembre de 2017 10:07
Para: OMNeT++ Users <omn...@googlegroups.com>
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Thanks for the reply Alfonso.

I started omnetpp using mingwenv.cmd and while building inetmanet, I got below error.

collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:1548: ../out/gcc-debug/src/libINET.dll] Error 1
make[1]: Leaving directory '/c/omnetpp-5.1-src-windows/omnetpp-5.1/samples/inetmanet-3.x-inetmanet-3.5/src'
make: *** [Makefile:6: all] Error 2

Regards,
Rashad
-------------------------------------------------------------------------------
On Tuesday, September 19, 2017 at 12:56:56 AM UTC+3, Alfonso Ariza Quintana wrote:

There is a compiler problem, you need to start omnet from the mingw Shell, in other case the paths and definitions can be erroneous

 

Enviado desde Correo para Windows 10

 

De: rashad kasim
Enviado: lunes, 18 de septiembre de 2017 22:53
Para: OMNeT++ Users
Asunto: Re: [Omnetpp-l] HWMP in omnet++

 

Thanks Alphonso.

I have added inetmanet package by downloading from the below link and importing the project in omnet++.
https://github.com/aarizaq/inetmanet-3.x


While trying to built the project, an error is thrown when it was processing the below step in the built process.
Creating shared library: ../out/gcc-debug/src/libINET.dll

The error thrown on the above step is given below:
g++.exe: error: CreateProcess: No such file or directory
make[1]: *** [Makefile:1558: ../out/gcc-debug/src/inet/linklayer/base/MACBase.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/c/Users/Rashad/Downloads/inetmanet-3.x-inetmanet-3.5/src'
make: *** [Makefile:6: all] Error 2

Error is thrown while trying to execute any example in inetmanet and they are shown below:
 Cannot load library '../../../src//libINET.dll': The specified module could not be found


Can you explain me why this error is happening.
Thanks in advance.


On Wednesday, September 13, 2017 at 5:20:16 PM UTC+3, Alfonso Ariza Quintana wrote:

You can try inetmanet, it has a basic implementation of HWMP

 

Enviado desde Correo para Windows 10

 

De: rashad kasim
Enviado: miércoles, 13 de septiembre de 2017 14:03
Para: OMNeT++ Users
Asunto: [Omnetpp-l] HWMP in omnet++

 

Hello everyone,
    I am new to omnet++ and I would like to know if there is any implementation of HWMP in omnet++.

Any pointers on this, would be appreciated.

Regards,
Rashad

[Alfonso Ariza Quintana]

The easier is to modify this method

 

const IReceptionResult *ReceiverBase::computeReceptionResult(const IListening *listening, const IReception *reception, const IInterference *interference, const ISNIR *snir) const

 

and emit a signal with the computation.

[rashad kasim]

Sorry Alfonso,

   The function computeReceptionResult is in RadioMedium as per the latest inetmanet. Not in ReceiverBase. There is no such function in ReceiverBase

The function I see is below one

const IReceptionResult *RadioMedium::computeReceptionResult(const IRadio *radio, const IListening *listening, const ITransmission *transmission, const std::vector<const ITransmission *> *transmissions) const


Or am I checking in a wrong place?