Someone, Please confirm this, Mixim multiConnectionManager example is not "multi channel" ??

[David_MIXIM]

Hi,

I am new to Omnet and C++ programming in general but it seems to me
that the multiConnectionManager example in Mixim (v1.2) is not
actually an example of multiple connection managers. The simulation
just ignores one of the managers and uses one set of parameters for
both NICs. For instance the parameter for pMAX is 100mW regardless of
the NIC, where the .ini file specifies two different values.
Could someone please confirm that the example is not actually using
the two sets of parameters?
Also, could someone point me in a direction to getting two NICs
( 802.11 and 802.15.4) to co-exist in the same network with different
parameters?

Thank you for the advice.

David.

[LIN Peng]

actually when you write in the .ini file specifying the parameters
with different prefix, that would offers moduls with different
parameter value:

host[1].nic.parameter_a would be differnet with host[2].nic.parameter_a,
when you using number to identify the set, not using the * syntax.

2010/7/23 David_MIXIM <dlay...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "omnetpp" group.
> To post to this group, send email to omn...@googlegroups.com.
> To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.
>
>

[David_MIXIM]

Lin Peng,

Thank you for replying. I understand your point. However, I think you
may have missed mine? When I run the unmodified multiConnectionManager
example in Mixim (v1.2) I noticed that Omnet is ignoring one of the
connection managers. For instance, when I add a print statement to
print out the "pMax" value for both GSMChannel and ISMChannel, I see
in the console pMax = 100mW for both channels. Here is the way the
parameters are set in the .ini file in the example, as is.
...
MultiConnectionManager.GSMChannel.pMax = 20mW
...
MultiConnectionManager.ISMChannel.pMax = 100mW
...
Therefore, I agree with you that it is clearly two different
parameters, but Omnet doesn't differentiate them. Furthermore, there
is no use of the star symbol *, so again, there should be no room for
confusion. When I dig in the issue a little I found the following
statement in the Mac80211.cc file which I think shows why the
simulation doesn't make the difference.

BaseConnectionManager* cc =
FindModule<BaseConnectionManager*>::findGlobalModule();

Later on cc is used to access the different parameters.
Therefore, I thought I would try to get someone to confirm the error
or explain to me what is actually going on in that example as I seem
to have this same issue with my own project.

Best regards,

David.

On Jul 23, 11:47 am, LIN Peng <stlinp...@gmail.com> wrote:
> actually when you write in the .ini file specifying the parameters
> with different prefix, that would offers moduls with different
> parameter value:
>
> host[1].nic.parameter_a would be differnet with host[2].nic.parameter_a,
> when you using number to identify the set, not using the * syntax.
>

> 2010/7/23 David_MIXIM <dlaye...@gmail.com>:

[Robert.C.Green]

For getting two NICs to work together you may want to look at this
post: http://groups.google.com/group/omnetpp/browse_thread/thread/e3d28af60609bc4f/d7e70093d0c790d0?show_docid=d7e70093d0c790d0.
I've been working on accomplishing this myself and have run into many
problems.

[Karl Wessel]

Hi David,

sorry for taking me so long to answer you on this but I had been busy with my exams during the last weeks.

I took a look at your problems regarding multiple connection managers:

1. You are right Mac80211 (and I think all of the other macs too) uses the wrong ConnectionManager Reference to check its transmit power against. This results in the simulation wrongly reporting the error regarding the "TX-Power to big". We'll have to fix this, thanks for pointing us to it.
For a quick fix you can replace the following line in your Mac**.cc file

BaseConnectionManager* cc = FindModule<BaseConnectionManager*>::findGlobalModule();

with

BaseConnectionManager* cc = NULL;
cModule* nic = getParentModule();
if (nic->hasPar("connectionManagerName")){
            cc = dynamic_cast<BaseConnectionManager *>(simulation.getModuleByPath(nic->par("connectionManagerName").stringValue()));
} else {
            cc = FindModule<BaseConnectionManager *>::findGlobalModule();

}

2. I tested the MultiConnectionManager example with the "Different CM - *" configurations but it used the correct (different) parameters (pMax, etc) in my runs. To test this I added/changed the following lines:

"base/connectionManager/ConnectionManager.cc" - added after line 32 "interfDistance = pow(waveLength * waveLength..."

ccEV << "Carrier Frequency: " << carrierFrequency << endl;
ccEV << "Max. TX-Power: " << pMax << endl;
ccEV << "Min. Signal Attenuation Threshold (SAT): " << sat << endl;
ccEV << "Min. Pathloss Coefficient: " << alpha << endl;

"base/connectionManager/ConnectionManager.cc" - changed line 8 from

#define ccEV (ev.isDisabled()||!coreDebug) ? ev : ev << "ConnectionManager: "

to

#define ccEV (ev.isDisabled()||!coreDebug) ? ev : ev << getName() << "(CM): "

"base/connectionManager/ChannelAccess.cc" - added before line 57 "if( cc == 0 ) error(..."

coreEV << "Using " << cc->getName() << " as Connection Manager." << endl;

The output during initialisation then was:

GSMNode[0]::PhyLayer: Using GSMChannel as Conenction Manager.
...
GSMNode[1]::PhyLayer: Using GSMChannel as Conenction Manager.
...
ISMNode[0]::PhyLayer: Using ISMChannel as Conenction Manager.
...
ISMNode[1]::PhyLayer: Using ISMChannel as Conenction Manager.
...
Initializing module MultiConnectionManager.ISMChannel, stage 1
ISMChannel(CM): initializing BaseConnectionManager
ISMChannel(CM): Carrier Frequency: 8.68e+08
ISMChannel(CM): Max. TX-Power: 100
ISMChannel(CM): Min. Signal Attenuation Threshold (SAT): -119.5
ISMChannel(CM): Min. Pathloss Coefficient: 3
ISMChannel(CM): max interference distance:4068.12
ISMChannel(CM):  using 1x1x1 grid
ISMChannel(CM): findDistance is (4068.12,4068.12,4068.12)
Initializing module MultiConnectionManager.GSMChannel, stage 1
GSMChannel(CM): initializing BaseConnectionManager
GSMChannel(CM): Carrier Frequency: 8.68e+08
GSMChannel(CM): Max. TX-Power: 20
GSMChannel(CM): Min. Signal Attenuation Threshold (SAT): -100.5
GSMChannel(CM): Min. Pathloss Coefficient: 3.5
GSMChannel(CM): max interference distance:224.493
GSMChannel(CM):  using 1x1x1 grid
GSMChannel(CM): findDistance is (500,500,500)

What exactly did you do to see that both CMs used the same (wrong) parameters?

Greetings,
Karl

[David_MIXIM]

Hi Karl!

Thanks so much for looking into this. I've been trouble shooting this
for quite some time now. I just really don't know what I'm doing.

To see that the parameters are getting confused, the easiest way to
replicate the error is just to switch the order of declaration in the
MultiConnectionManager.ned file of the two connection managers.
i.e. change:

ISMChannel: ConnectionManager {
parameters:
@display("p=33,41;b=42,42,rect,green;i=abstract/
multicast");
}
GSMChannel: ConnectionManager {
parameters:
@display("p=120,41;b=42,42,rect,red;i=abstract/
multicast");

}

to:
GSMChannel: ConnectionManager {
parameters:
@display("p=120,41;b=42,42,rect,red;i=abstract/
multicast");

}
ISMChannel: ConnectionManager {
parameters:
@display("p=33,41;b=42,42,rect,green;i=abstract/
multicast");
}

This should throw an error complaining about pMax in the mac layer.

I haven't tired the modifications you posted yet but I'm about to and
will let you know how it goes.

Thanks again for the reply!

David.

[David_MIXIM]

Hello Karl,

I found the BaseArp.cc file is not written very well for robustness as
it looks for a specific NIC named "nic". In my own project I have two
NICs, named differently of course, per host. Therefore, the BaseArp
code caused the simulation to crash with a cryptic error code as it
could not find an NIC named "nic".
Here are the changes I made to make it work, but I don't feel it is
the right way to deal with this. Maybe you have some suggestions?

changed line 42 in MiXiM/Base/modules/BaseArp.cc

return simulation.getModule(netwAddr)->getParentModule()-
>getSubmodule("nic")->getId();

to

return simulation.getModule(netwAddr)->getParentModule()->getId();

Thanks for all the help you have already provided,

David.

[Karl Wessel]

Hi David,

the problem is that BaseArp is only a very simple ARP-module and not
meant to work with multiple nics. If you have multiple nics you have to
subclass your own ARP-Module from it and find a way how it assignes
addresses to the different nics.

The code you posted will make both nics have the same mac address (the
id of their host) which of course is not ideal for unique address
resolution :).

You are right as it is now it's not very robust. We'll have to either
add warnings to BaseArp if the module layout does not match its
assumptions or have to make it more robust. But it won't be able to
handle multiple nics by itself.

Multiple nics or multiple network stacks in the same host is nothing
MiXiM currently supports by itself since we hadn't time yet to really
think about the problem. In general I think it should be doable, the
main problem will be the linking the correct network stack to the
correct nic which involves changes to BaseArp, MAC layer, Network layer
and maybe the host layout.
We will be glad on every feedback from your side on this matter and can
offer you our knowledge for help with MiXiM specifics on this matter but
currently can't extend MiXiM ourself for better support on this.

Thanks for all your feedback so far!

Regards,

Karl