| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
It’s not clear my reply made it to
everyone the first time. Ken From: Kenneth Stanwood
[mailto:KStanwood@xxxxxxxxxxxx] I am still very concerned about the
insistence to remove the channel occupancy metric without an appropriate
replacement. As was discussed in 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 From: Mariana
Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx] 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 From: Shellhammer,
Steve [mailto:sshellha@xxxxxxxxxxxx] Minutes posted on the server, https://mentor.ieee.org/802.19/file/08/19-08-0002-11-0000-conference-call-minutes.doc 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). ************************************************************************************ |