RSSI measurements cannot be switched off

[Jan]

In one of my simulation campaigns I noticed that the biggest portion of simulation time was spent computing RSSI values even though I do not use them. When I investigated this, I found that in Receiver.cpp the computation is only done if someone actually observes the RSSI because (as the comments in the code point out) the computation can be quite expensive. The problem, however, is that in Station.cpp the observation is always started in each OFDMA station so that the Receiver will always perform RSSI computations.

I guess the RSSI observation in Station.cpp should only be started if some configuration option is set accordingly!?

Any comments?

Receiver.cpp:
727 // For each started and stopped transmission, the Received Signal Strenght
728 // (RSS) at the receiver changes. Upper FUs can observe the RSS to detect a
729 // busy channel.
730 // The signalling is made only if observers are present, as the operation
731 // (adding dBm values) is costly and must be done for every packet at every receiver.
732 if (this->wns::Subject<RSSInterface>::hasObservers())
733 {...

Station.cpp:
108 // Start to observe the receiver for onNewRSS calls
109 this->wns::Observer<RSSInterface>::startObserving(receiver);

[Daniel Bültmann (daniel.bueltmann)]

Dear Jan,

you are right. If the RSS values are not needed then we should not
calculate the RSS values, i.e. we should not add the Station as an
Observer. However, as far as I can see the Station forwards the RSS
value within the CarrierSensing notifies. It is itself a
wns::Subject<CarrierSensing>. I think what we must do is the following.
If at least one Observer is added to wns::Subject<CarrierSensing> we
need to attach the Station to the Receivers wns::Subject<RSSInterface>.
As far as I can see we can control this by hooking into the virtual void
addObserver() method of wns::Subject within the Station class.

Then we should control whether there are any Observers of the
CarrierSensing Subject. I think this can be then done by using
configuration values. If we directly make it configurable within the
Station, we are likely to run into inconsistent configurations.

We also should get Sebastian's opinion who makes use of the RSS values
within the WiFiMac.

Best Regards,
  Daniel

wns::Observer<RSSInterface>

Jan wrote:
> Public bug reported:
>
> In one of my simulation campaigns I noticed that the biggest portion of
> simulation time was spent computing RSSI values even though I do not use
> them. When I investigated this, I found that in Receiver.cpp the
> computation is only done if someone actually observes the RSSI because
> (as the comments in the code point out) the computation can be quite
> expensive. The problem, however, is that in Station.cpp the observation
> is always started in each OFDMA station so that the Receiver will always
> perform RSSI computations.
>
> I guess the RSSI observation in Station.cpp should only be started if
> some configuration option is set accordingly!?
>
> Any comments?
>
> Receiver.cpp:
> 727 // For each started and stopped transmission, the Received Signal Strenght
> 728 // (RSS) at the receiver changes. Upper FUs can observe the RSS to detect a
> 729 // busy channel.
> 730 // The signalling is made only if observers are present, as the operation
> 731 // (adding dBm values) is costly and must be done for every packet at every receiver.
> 732 if (this->wns::Subject<RSSInterface>::hasObservers())
> 733 {...
>
> Station.cpp:
> 108 // Start to observe the receiver for onNewRSS calls
> 109 this->wns::Observer<RSSInterface>::startObserving(receiver);
>
> ** Affects: openwns-ofdmaphy
> Importance: Undecided
> Status: New
>
>

[Sebastian Max (smx-comnets)]

Dear Jan,

Yes, you are definitely right :-)

But, I would propose a different solution than Daniel:
The current wns::Subject<CarrierSensing> does not follow the general service/handler architecture in the openWNS - in general, this architecture is similar to a subject/observer(s) pattern that allows one observer only. I would propose to change the current wns::Subject<CarrierSensing> to this architecture, which allows to write an own registerRSSHandler() function in Station.hpp; this function then adds the station to the observers of the receiver - on demand, so to say.

Changes in libwns:
src/service/phy/ofdma/Notification.hpp: Notification is not longer derived from wns::Subject<CarrierSensing>, add virtual function registerRSSHandler
src/service/phy/ofdma/Handler.hpp: Add class RSSHandler with virtual function onRSSChange

Changes in OFDMAPhy:
src/Station.hpp: Add function registerRSSHandler & variable rssHandler
src/Station.cpp:
* Remove startObserving(receiver), save rssHandler when registerRSSHandler is called and startObserving!
* onNewRSS calls rssHandler->onRSSChange instead of forEachObserver

In my WiFiMAC, the appropriate FU will register itself as the RSSHandler. If no FU registers itself, station does not call startObserving and the RSS value is not calculated. No additional (python) configuration is required.

I am currently testing this changes and will commit them soon for review.

[Jan (jan-ellenbeck)]

Dear Daniel and Sebastian,

thanks for the confirmation and your proposals. Sebastian's solution sounds good to me. However, I am not so familiar with the RSSI/CarrierSensing mechanism because we don't use it over here.

Looking forward to your patch.

Cheers
Jan