Bugzilla – Bug 2467
Do not schedule StartRx for receivers with orthogonal SpectrumModels
Last modified: 2016-10-19 09:03:08 EDT
Created attachment 2526 [details] Proposed patch This patch adds SpectrumModel::IsOrthogonal method that allows checking if one SpectrumModel is orthogonal to another SpectrumModel. It means that SpectrumModels have no overlapping bands. This method is further used by MultiModelSpectrumChannel to avoid creating SpectrumConverters with zero conversion matrix and calling StartRx when receiver gets no power in any of its subbands. The patch adds nearly zero runtime overhead for common scenarios, because IsOrthogonal is checked only in AddRx. After that everything works as usual except that if SpectrumConverter is not found for some TX-RX pair, this pair is skipped and next receiver is processed. I checked that all tests still pass. As long as no model relies on receiving signals with all-zero PSD, experiment results should not change.
Created attachment 2529 [details] Proposed patch Moved NS_LOG_LOGIC inside if()
Created attachment 2530 [details] Proposed patch Added doxygen comment
Created attachment 2533 [details] Proposed patch Added similar changes to MultiModelSpectrumChannel::FindAndEventuallyAddTxSpectrumModel
Created attachment 2534 [details] Proposed patch Hopefully final version
This patch could be quite beneficial in terms of computational savings. However, my main concern is the following assumption: (In reply to Alexander Krotov from comment #0) > I checked that all tests still pass. As long as no model relies on receiving > signals with all-zero PSD, experiment results should not change. I am not sure whether all models satisfy this assumption (not relying on receiving signals with all-zero PSD). I'd suggest to check with the maintainer of spectrum-based models before committing this patch. Once all of them are ok, I think it makes sense to go ahead and push this change.
(In reply to Nicola Baldo from comment #5) > This patch could be quite beneficial in terms of computational savings. > However, my main concern is the following assumption: > > (In reply to Alexander Krotov from comment #0) > > I checked that all tests still pass. As long as no model relies on receiving > > signals with all-zero PSD, experiment results should not change. > > I am not sure whether all models satisfy this assumption (not relying on > receiving signals with all-zero PSD). I'd suggest to check with the > maintainer of spectrum-based models before committing this patch. Once all > of them are ok, I think it makes sense to go ahead and push this change. I suppose the people to check with are Marco (LTE), me (Wi-Fi), and Tommaso (LR-WPAN). But I didn't spot the reliance on having non-zero PSD; the orthogonality check is done on band frequencies. Can you clarify? I also think that if a model relies on StartRx() being called for a signal with no power (zero PSD in all bands), the model should be fixed (because channel objects should be able to suppress calls to StartRx() for weak signals). So I don't have a concern with this aspect.
> I also think that if a model relies on StartRx() being called for a signal with no power (zero PSD in all bands), the model should be fixed (because channel objects should be able to suppress calls to StartRx() for weak signals). So I don't have a concern with this aspect. When I wrote that "As long as no model relies on receiving signals with all-zero PSD, experiment results should not change", I first of all thought about the case when StartRx converts power into packet error rate and draws some random variable to compare with this error rate. In this case packet error rate would be 1 and RNG stream would be advanced. After the patch, it would not be advanced and further RNG output will be different, so regression tests for out-of-tree model may fail. I think it can be mentioned in the ChangeLog so maintainers of out-of-tree models don't spend too much time wondering why their regression tests fail and existing experiments start producing different results.
> I think it can be mentioned in the ChangeLog so maintainers of out-of-tree > models don't spend too much time wondering why their regression tests fail > and existing experiments start producing different results. Understood, thanks.
I think this patch is a good step ahead, and it could actually increase the simulation performance. Just one question: would it be feasible to cache the IsOrthogonal results ? Perhaps we could use a map and, just by looking at the other SpectrumModel UID make a decision. If you don't know yet (the map entry doesn't exist) you do the maths, otherwise... well, you know it already. On the other hand, probably it's not that useful. The spectrum conversion map is (or should be) calculated only at the simulation start, and the performance hit should be minimal. +1 from my side.
(In reply to Alexander Krotov from comment #7) > > I also think that if a model relies on StartRx() being called for a signal with no power (zero PSD in all bands), the model should be fixed (because channel objects should be able to suppress calls to StartRx() for weak signals). So I don't have a concern with this aspect. I agree on this point that if such behavior exist it would be good to fix it - I just raised the warning to try to detect these cases before introducing a possibly problematic commit. I am mainly concerned with the possibility that metadata from some transmissions (e.g., SpectrumSignalParameters and derivates) might be considered by a receiver even if the PSD is zero. I think some instance of such behavior was already fixed in the past, but I am not really up-to-date with the latest status of the models.
I'm a bit scared on the LTE uplink control channel, since as "ideal" it is supposed to work always, even with zero PSD (e.g., with orthogonal signals). For instance, an ideal PUCCH signal is sent when no data has to be transmitted and it might be received with zero PSD in case eNB is not expecting any data from all the UEs (in this case eNB will have a "null pass" filter in uplink. This would affect the HARQ behavior, but also the upper layers.
> For instance, an ideal PUCCH signal is sent when no data has to be transmitted and it might be received with zero PSD in case eNB is not expecting any data from all the UEs (in this case eNB will have a "null pass" filter in uplink. In this case zero PSD will be delivered even after patch. If you are synchronized to correct frequency, you will still receive zero PSD. Zero PSD signal will not be delivered only if you are synchronized to different cell that operates on orthogonal band, and in this case even ideal channels should not be received anyway because of physical cell id mismatch.
(In reply to Alexander Krotov from comment #12) > > For instance, an ideal PUCCH signal is sent when no data has to be transmitted and it might be received with zero PSD in case eNB is not expecting any data from all the UEs (in this case eNB will have a "null pass" filter in uplink. > > In this case zero PSD will be delivered even after patch. If you are > synchronized to correct frequency, you will still receive zero PSD. Zero PSD > signal will not be delivered only if you are synchronized to different cell > that operates on orthogonal band, and in this case even ideal channels > should not be received anyway because of physical cell id mismatch. Many thanks for your clarification. According to this, I would say that the proposed patch should not affect the LTE module.
It seems that we have consensus to merge this improvement. Regarding how to leave a note about possibly changed experimental results, I suggest to add an item in the 'Changed behavior' section of CHANGES.html.
Hi, just a minor comment regarding IsOrthogonal() function. Maybe I do not follow all the details, so please correct me if I am wrong. Do we need always to have some gap between orthogonal SpectrumModels? I am concerned for the case when SpectrumModels are adjacent and the highest frequency of one is equal to the lowest of the other, can this happen? E.g. if we define wi-fi channels 36 (5170-5190) and 40 (5190-5210). Then the function would return that they are not orthogonal, right?
> Then the function would return that they are not orthogonal, right? In this case the IsOrthogonal would return true. For bands to be non-orthogonal, they should overlap, not just be adjacent. If subbands overlap in just one point, for example myIt is [0..1] and otherIt is [1..2], then std::max (myIt->fl, otherIt->fl) == std::min (myIt->fh, otherIt->fh) because max == 1 and min == 1. So, the condition std::max (myIt->fl, otherIt->fl) < std::min (myIt->fh, otherIt->fh) is always false for such subbands and after checking all subbands IsOrthogonal returns true. I consciously selected < instead of <= because in the case of adjacent channels all conversion coefficients are 0 anyway.
Thanks for explaining. I got it. Really nice code!
Pushed in changeset da4a73886497, going to add changed behavior item as a separate commit