The impact of any system on its neighbors depends on not only the protocol design and implementation of the system in question, but on the protocol design and implementation of the neighboring systems. Thus, system A can have one throughput impact on System B, another on System C, etc., even if System B and System C are co-located.
Building on what was said at the teleconference, the important thing to consider is the percentage decrease in the throughput capacity of the systems being simulated. An optimal point to consider as a design goal is for all systems to experience an equal percentage drop in throughput capacity.
This goal can be incorporated in the protocol design of the systems in a community if information related to this throughput metric is shared between systems, and used to implement appropriate evasive action. What we have here is essentially a distributed optimization problem, so it is important that each system has the right information to make local decisions that improve the common good.
The channel occupancy metric is a blunt instrument for measuring coexistence problems because different systems use different PHY technology. This means that for each combination of system type, we could potentially determine a different coexistence sensitivity to channel occupancy. Even still, the metric is useful in helping us identify which combinations are the most problematic if we do an exhaustive search.
What gets tricky is when we make adjustments to the protocol design and implementation of systems. Any modification would require a complete redo of our simulations, since the channel occupancy metric will have a new impact on coexistence. For example, if a system disables certain tones when it experiences high levels of interference, two systems can share the same band by subdividing it in an FDD fashion. A similar modification could take place in the time domain by synchronizing transmission opportunities. Without this disabling, the systems might interfere. In both cases, the channel occupancy has not changed.
Mind you, we could modify the metric to account for percentage of the band occupied, but the real issue is not just how much of the band is occupied by a system, but where in the band a system occupies the channel, and when it is occupied, in relation to all neighboring systems.
To address your issue of zero throughput systems that impact neighbors, the throughput capacity metric should be studied. A zero throughput system will reduce the throughput capacity of neighbors. Its throughput capacity will also be affected by its neighbors. We can therefore study the phenomenon you mentioned with this metric, and use it as a tool to better understand how well the community is getting along.
Harry
On Aug 6, 2008, at 7:36 AM, Kenneth Stanwood wrote: I am still very concerned about the insistence to remove the channel occupancy metric without an appropriate replacement. As was discussed in Denver, it is very valuable to assess how a system implementing one technology may block the use of all or a part of the channel by systems implementing other technologies. In particular, it is important to see how a technology blocks access by others when the first technology has little or no actual data to send. As we are already aware, any 802.16/WiMAX based technology should be suspect due to the designed operation of unmodified WiMAX systems. Modified WiMAX systems should be required to prove they do not limit access by other technologies under low demand situations within the WiMAX system. NextWave proposed the channel occupancy metric in question because inclusion of that metric in our simulations was key to understanding and modifying the WirelessMAN-UCP protocol in section 6.4 of 802.16h so that it would not excessively block access by similar channel bandwidth 802.11 systems when the 802.16 system had low demand. It is not clear to me that the WirelessMAN-CBP protocol described in section 15 of 802.16h has addressed this problem. Lack of an appropriate metric could hinder the identification and resolution of issues in currently proposed systems and systems likely to be proposed in the future. I understand the reluctance to accept the metric. At NextWave we had heated internal debate over whether or not to include the metric in our simulations, but when the results came in and the value was overwhelmingly apparent argument ceased. At a minimum, if a throughput metric is used instead, there must be a solid requirement that system A’s impact on the throughput of system B must be simulated for a variety of cases where system A has low or no demand. Thanks, Ken Hi All, Regarding the yesterday teleconf and the way forward: 1. In my view metrics which do not have a clear interpretation as coexistence criteria shall be omitted, and this is the case of the Medium occupancy where two opposite target criteria were proposed by Paul and Eldad (Paul – 50% of time in case of two collocated systems – was no agreement on this, because is ignoring the antenna separation, powers, modulation, coding, etc.; Eldad 100% or similar occupancy). In addition it is not defined yet what the occupancy is, and we spent 45min. just with a discussion on the different possibilities. This in addition to the time spent in the meeting. 2. I (and probably many others) appreciate the straightforward metrics and criteria proposed by Richard, looking at the relative throughput degradation of the two systems as result of interference. Similar degradation means acceptable coexistence. 3. The hidden nodes are also important, being the exact image of the “harmful interference”. The reception of the signal is directly affected by the hidden nodes. The hidden node statistics is “hidden” in the averaged throughput results, and this is why we need this metrics in addition to the throughput. 4. I think that for the next teconf. we need to invest the time in advancing the CA document itself. We need to discuss the simulation results and agree on the CA text. 5. We spent already more than one year on this issue (Apr. 07 is the date of the first parameter document), in meetings and bi-weekly teleconf. I hope that we will be able to finalize this process asap. We have committed for a much shorter process and the planned resources have gone. Probably the 802.19 guys have also other issues to address. Regards, Mariana Minutes posted on the server, Steve
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43).
************************************************************************************
|