# lb34_r0

Comment:
""Committee of the IEEE Society"", and ""Abstract"" are in incorrect position.


Comment:
Missing period at the end of the sentence.


SuggestedRemedy:
Please rewrite this section using better English and a more coherent flow of ideas.


Comment:
Table numbers should not include the em-dashes.


Comment:
The word ""required"" doesn't make sense here.


Response:
TE-Do Not Accept, This is from Bluetooth to reflect that there are two differenct frequency hopping sets due to regulations 79 or 23.  See 802.15.1 for further details


SuggestedRemedy:
Replace with ""The power spectrum of the Barker codes is: Lee [B11]""


Comment:
It's not clear to me why a narrowband interferer will be attenuated more at the middle of the spectrum than at 1 MHz away.

SuggestedRemedy:
Provide an explanation of this reasoning.


SuggestedRemedy:
Clean up the reference to Bluetooth (802.15.1?)

Response:
TE-Agree  Will remove the end of the sentence


Comment:
Figure shows Bluetooth devices instead of 802.15.1 devices.


Comment:
Incomplete sentences in scope description

SuggestedRemedy:
Use complete sentences to describe the scope of the document.

Response:
TE-??  Scope must match scope in PAR, cannot change unless text in PAR is changed


Comment:
Line 3 says 2 MHz is included; line 7 says it is not.

SuggestedRemedy:
As I understand the draft, 2 MHz is not included.  If so, remove it from line 3.

Response:
TE-?? Remove editor's note line 7, or perhaps make clear that 2 MHz is done for Physical, but not for MAC


Comment:
The phrase ""set of rules"" is used in many definitions, and is undefined.

Response:
TE-Do not accept.  A term shall be general enough to be applied else where within the IEEE.


Comment:
"Coexistence" is poorly defined:(a)  The "task" is not defined.  All tasks?  Any one task?  Some specific task?  All the time?(b)  The definition is one-sided:  "The ability of *one* system to perform a task ...".  A dictionary definition is "to exist together, at the same time, or in the same place," implying that A does not coexist with B, nor B with A; rather, A and B coexist *together*.

SuggestedRemedy:
""The ability of each of a set of (perhaps disparate) systems to perform specified tasks in a given shared environment.""


Comment:
Style error:  Definition is a complete sentence; all others are not.

Response:
TE-Do not accept  This is copied from the given reference.  If permission is not obtained, entire definition will be removed.


Comment:
While I know this is the definition in the IEEE dictionary, defining ""interference"" using the word ""interfere"" doesn't provide much light on the matter--especially since ""interfere"" is not in the IEEE dictionary.

SuggestedRemedy:
Avoid using ""interfere""--for example, ""...that might reduce the quality of desired received signals ...""


Comment:
""respectively"" is confusing here, since there are three precedents but only two sequels.

SuggestedRemedy:
The coexistence modeling approach used is based on detailed simulation models for the Radio Frequency (RF) channel and the Medium Access Control (MAC) and Physical (PHY) layers developed in OPNET and ANSI C, respectively.

Response:
TE-?? English reading indicates only two, but it is confusing for detemining the pairing


Comment:
"frequency nulling" has not yet been defined; since this term usually refers to matching the frequencies of two independent sources, it's quite a puzzle what this means here without a definition.  (As an aside, the definition given later in the text more closely resembles an adaptive notch filter ... why not call it that?)

SuggestedRemedy:
Either change the sentence to ""An adaptive notch filter can be used to ..."" or define the term ""frequency nulling"" prior to its use.


Comment:
""near-field"" is not an ""implementation effect.""

SuggestedRemedy:
change to, ""due to near-field and implementation effects.""


Comment:
""The intended transmission is attenuated by the path loss as defined in subclause 5.2 to the receiver. This is the signal power at the receiver.""  This is not correct.

SuggestedRemedy:
""The intended transmission is attenuated by the path loss as defined in subclause 5.2 to the receiver. The transmitted signal power, less the path loss, is the signal power at the receiver.""


Comment:
Where did these numbers come from?  A sample calculation would be most welcome.


Comment:
15.1 is *not* orthogonal FSK.  The modulation index h = 0.315, not 0.5.

SuggestedRemedy:
Delete the reference to orthogonal FSK, and ensure that the following technical derivation is still valid without the assumption of orthogonality.


Response:
TE-?? Not the only place where this term is used,  which is correct?


Comment:
""The GFSK signal can be represented by Murota [B6], Aulin [B1], and Steele [B9] as"" is really awkward (I mean, the rest of us can also represent the GFSK signal the same way).

SuggestedRemedy:
""The GFSK signal can be represented as ([B1], [B6], [B9])...""

Response:
TE-Do not accept  IEEE Standards Style Manual (9/20/02) clause 19 states as currently used.


Comment:
References should be cited by number [1] or author (Smith 2002), not both Smith [1].

SuggestedRemedy:
eferences should be cited by number [1].


Comment:
To define A, mention that it is the peak amplitude.

SuggestedRemedy:
To define A, mention that it is the peak amplitude.


Comment:
List of symbol definitions does not keep a single format throughout (extraneous semicolons and ""ands"" abound).  Also, units should be included in all symbol definitions.

SuggestedRemedy:
Keep a single style format thoughout the symbol list.  Include units in all definitions.


Comment:
Should be ""symbol intervals,"" not ""symbols.""  (We assume possibly multiple bits per symbol, but not multiple symbols per bit.)

SuggestedRemedy:
Should be ""symbol intervals,"" not ""symbols.""


SuggestedRemedy:
Define phi2 as deviation, and as a function of t and b, like the BT case in 5.4.1.1.


Comment:
I don't understand the explanation for the delay spike.  Does this imply that the simulated time period was too short (i.e., too few packets being received for good statistical inference)?


SuggestedRemedy:
say, ""Mb/s WLAN"" not just ""Mbit/s.""  (Isn't Mb/s standard form, not Mbit/s?)


SuggestedRemedy:
Should say, ""Thus, the interference between the WLAN FH and TG1 systems is limited.""


Comment:
This puzzles me.  How does this result compare with the earlier theoretical prediction that TG1 packets will hit almost every WLAN packet (s. 4.1.1), but most TG1 packets will not be hit by WLAN packets (due to the difference in hop rate--s. 4.1.3)?  How can "the packet error rate for both the IEEE802.15.1 and WLAN is negligible (below 5%)"?

SuggestedRemedy:
Compare and contrast the simulated results with the earlier theoretical predictions.


Comment:
extra space before period: ""transmitting or receiving .Additional""

SuggestedRemedy:
Check spacing before and after periods throughout table.


Response:
TE-??  Might be a variable and not an extraneous "t"


Comment:
Incorrect period placement and capitalization:  ""above. (See 12.1)""

Response:
TE-Do not accept  As per The Gregg Reference Manual


Comment:
""vendor specific"" is not what is intended, I think.


Comment:
Who owns the trademark on ""Wireless Personal Area Networks""??

Response:
TE-Do not accept   TG1 holds WPAN trade mark


Comment:
There's lots of ""M Weik"" in section 3.1

SuggestedRemedy:
Add to reference section and make references by [1] rather than name.

Response:
TE-Do not accept  Permitted as IEEE Standards Style Manual, but if permission is not obtained, then the entire definition will be removed.


SuggestedRemedy:
I'll give you a wmf from my original drawing.


Comment:
Last para of 10.1 doesn't mention that PTA should also be used when SCO needs to be supported.

SuggestedRemedy:
Add "" or when SCO links need to be supported."" to the end of this para.


Comment:
Section 10.2 needs some work.  The T1 and one of the TWLAN/TWPAN need to be communicated. The other duraction can be calculated from TB.   This document should include changes to 802.11 in the form of editing instructions to a particular revision of 802.11(see the other 802.11 drafts for examples).

SuggestedRemedy:
Signal T1 and TWLAN.Add ""editing instructions"" to this document for any required changes to 802.11.


Comment:
Section 10.2.2.  It is not necessary to have both an MLME and a MIB interface to these values.  Recommend just a MIB one (less text!).Should have just T1 and TWLAN variables.

SuggestedRemedy:
Remove the MLME interface and add section saying that the MIB values are updated whenever a beacon is received.  Beacon transmitted contains latest MIB values of these variables.   Support T1 and TWLAN MIB variables (TWPAN is redundant and problemmatical if TWLAN+TWPAN != TB).


Comment:
Don't select an element ID, but instruct the editor to find an unused one.You cannot be sure this value will be available.

SuggestedRemedy:
Add editing instruction:""Add the following element to table 20 of ... and assign an available element ID"".


Comment:
"The Clear-to-Send (CTS) packet is addressed to its own 802.11 MAC address plus the group address bit is set to 1 (multicast group). This allows any other Access Point on the same channel to determine that this isa pseudo-reservation message and to not delay any of its own transmissions, such as CTSs or Beacons."No it doesn't.The current 802.1 makes no such interpretation on the CTS RA.

SuggestedRemedy:
Remove this comment or add normative editing instructions to change 802.11.


Comment:
Table 19 has an error.  The adjacent ""none"" and ""receive"" cells near the bottom RH need to be swapped.


Comment:
I see packet scheduling only of value when a new master device talks to a legacy device.  A legacy device is unable to characterise the channel and report the frequency usage table.

SuggestedRemedy:
Remove all mention of communication between slave and master in this section.  Make appropriate adjustments so that master operates only on the basis of local knowledge.


Comment:
There is no point defining behaviour requiring negotiation before use (such as setting up an EV3 connection) if there is no agreed means for 802.15.2 to define modifications to the connection setup process and LMP commands.


Comment:
This section is meaningless.  There is no NACK in 802.11 or 802.15.1.


Comment:
Section 12.2.  It is not clear from this section whether it is an alternative to the AFH that will be defined by the BT SIG, or is intended to be compatible with it.

SuggestedRemedy:
Add a statement of compatibility to the BT SIG AFH mechanism.


Comment:
It is meaningless to define values contained in LMP commands unless there is a defined coordination between the BT SIG and 802.15.2 that permits 802.15.2 to define LMP commands and features.

SuggestedRemedy:
In the absence of any such coordination,  remove section 12.3.


Comment:
All methods suggested for collaborative coexistence impose an unacceptable burden on 802.11 equipment (requiring either "marriage" to 802.15 equipment and/or incorporation of sophisticated "interference ameliorating" subsystems) as well as upon 802.11b ne

SuggestedRemedy:
Remove all references to collaborative coexistence techniques in the document.  Modify Section 4.3 to delete references to Collaborative models.  Delete Section 4.3.2  Delete Section 10


Comment:
This clause starts with a reference to the group that wrote the recommended practice as ""IEEE 802.15.2"".  It is awkward in the context of a completed recommended practice

SuggestedRemedy:
Replace ""IEEE 802.15.2 has decided to select"" to ""This recommended practice selects"".


Comment:
Frequency nulling is mentioned, but the definition is not easily found (or possibly unavailable.)

SuggestedRemedy:
Add ""Frequency nulling"" to clause 3.1 as a definition or term.


Comment:
This discussion of stationarity indicates that the parameters are constant when they are, in fact, assumed constant.

SuggestedRemedy:
Change ""(and hence link loss) is constant."" to ""(and hence link loss) is assumed constant.""


Comment:
Dividing beacon interval for 802.11 will have problems for legacy stations, will have problems maintaining QoS for 802.11e, and will interfere with certain timers.

SuggestedRemedy:
Delete all references to it in the Recommended Practice


Comment:
AWMA is the best of the collaborative techniques, but it has a few flaws. If an AP is AWMA capable then it should be able to determine the traffic flow of the WLAN and WPAN that it has control over. A method of dynamically changing the timing allocation needs to be created.

SuggestedRemedy:
Re-word sentence:These two parameters are programmable over the WLAN and can be allowed to change dynamically according to the load of the two wireless systems.


Comment:
AWMA is recommended for high density WLAN/WPAN areas. As such there will be 3 non-overlapping WLANs in the same area.. For AWMA to be effective, all the WLANs need to share the same time sharing parameters and have the same clock timing. A method needs to be developed that allows all the WLANs to coordinate timing.

SuggestedRemedy:
Add sentence:Additionally, in an environment where there are multiple WLANs in the same coverage area the clocks of all WLANs are synchronized.


Comment:
In order for AWMA to work and to not burden low cost WPAN devices with the need for WLAN radios, the term Alternating Wirless Medium Access Control Area needs to be defined (AWMACA). As such all devices entering into the AWMACA shall adopt the rules of the area.1. All WPAN master devices must role-switch to a AWMA master in the area.2. Only piconets with a AWMA master are allowed3. IBSS networks must adopt the timing parameters and synchronize its clock with the AWMACA.4. All WLANs in the AWMACA shall adopt the timing parameters and synchronize its clock with the AWMACA.

SuggestedRemedy:
Add sentence:Alternating Wireless Medium Access Control Area (AWMACA). All devices entering into the AWMACA shall adopt the rules of the area.1. All WPAN master devices must role-switch to a AWMA master in the area.2. Only piconets with a AWMA master are allowed3. IBSS networks must adopt the timing parameters and synchronize its clock with the AWMACA.4. All WLANs in the AWMACA shall adopt the timing parameters and synchronize its clock with the AWMACA.


Comment:
PTA can only work if the WPAN device also uses adaptive frequency hopping to avoid interfering with other WLANs in the same location.

SuggestedRemedy:
Add sentence:The PTA technique only works well if the WPAN device also uses adaptive frequency hopping to avoid interfering with other WLANs in the same location.


Comment:
the three sentances need and introduction. Or perhaps ""the scope... is"" Bullet 1 ""To ..."" Also note that on page 2 it starts ""The scope of this document..."".  Are lines 40-54 really needed?


Comment:
Paragraph  1.1 has 2 Mbit/s specified.  Why the comment?


Comment:
the sentance talks about a project.  Isn't this a recommendation, like stated in line 18?


Comment:
line 5 states ""This document defines several coexistence mechanisms.."" The next sentance states ""This recommended practice defines two classes of coexistence mechanisms"".  This is confusing.  Are three two classes of several types?


Comment:
In section 1 it states the scope of this document is "" 802.11b and 803.15.2""  But on line 11 we state ""For example, both IEEE 802.11b and IEEE 802.15.1""  like the document addressed more than 802.11 and 802.15.2.


Comment:
The word ""for say 100 ms"" should be ""for example 100 msec""


Comment:
""So the odds are that"" should be deleted


Comment:
The example does not support  the text.  In fact the example appears not to be an example


Comment:
redo ""The IEEE 802.11 MAC incorporates automatic repeat request (ARQ) to insure reliable delivery of dataacross the wireless link. So there is little chance that the data will be lost. The effect the interference has onthe WLAN is that the delivered data throughput decreases and the network latency increases. Depending onthe application this may or may not be tolerable.""

SuggestedRemedy:
The IEEE 802.11 MAC incorporates automatic repeat request (ARQ) to insure reliable delivery of data across the wireless link, without data loss. A interference increases, the network latency increases, and  data throughput decreases.


Comment:
Most implementations allow either manual or automatic modification of the data rate.

SuggestedRemedy:
Most implementations allow manual or automatic modification of the data rate


Comment:
This line makes no sense- The higher rates are desirable for many applications but the distance of transmission using the higher rates is less than that of the lower rates.


Comment:
There is a potential packet collision between a WLAN packet and an interfering 802.15.1 packet any time the WPAN hops into the WLAN passband.

SuggestedRemedy:
There is a potential packet collision between a WLAN packetand an 802.15.1 packet when the WPAN hops into the WLAN passband.


Comment:
the following sentance makes no sense Since the bandwidth of the 802.11b WLAN is 22 MHz, as the WPAN hops around the ISM band 22 of the 79 WPAN channels fall within the WLAN passband.


Comment:
where is the detailed interfence model (place reference in text)


Comment:
reword One of the important issues that effects the level of interference is the WLAN automatic data rate scaling. If it is implemented and enabled it is possible for the WPAN interference to cause the WLAN to scale to alower data rate. At a lower data rate the temporal duration of the WLAN packets is increased. This increasein packet duration can lead to in increase in packet collisions with the interfering WPAN packets. In someimplementations, this can lead to yet a further decrease in the WLAN data rate. This can result in theWLAN scaling down its data rate to 1 Mbit/s.


Comment:
redo ""The IEEE 802.11 MAC incorporates automatic repeat request (ARQ) to insure reliable delivery of data across the wireless link. So there is little chance that the data will be lost. The effect the interference has on the WLAN is that the delivered data throughput decreases and the network latency increases. Depending on the application this may or may not be tolerable.""


Comment:
change Both frequency-hopping systems are usually only susceptible to interference on the channel in use and the two adjacent channels.

SuggestedRemedy:
Both frequency-hopping systems are susceptible to interference on the channel in use andthe two adjacent channels.


Comment:
specify where the model is located- The detailed model described later quantifies the level of packet error rate.


Comment:
change  So with limited packet error rate the ACL link will have a small decrease in network throughput and a small increase in network latency. However, for delivery of voice IEEE 802.15.1 uses a synchronous connection-oriented (SCO) link. The SCO link does not support automatic repeat request. As a result there will be some perceivable degradation in voice quality over an SCO link in the presence of 802.11 FH interference. The detailed model described later quantifies the level of packet error rate. The 802.11b represents a worse interferer than the 802.11 FH. For data transfer the network throughput would decrease and the network latency would increase, in the presence of 802.11b interference. The packet error rate for SCO link can cause voice quality degradation.

SuggestedRemedy:
to IEEE 802.15.1 voice communications use a synchronous connection-oriented (SCO) link. Since the SCO link does not supportautomatic repeat request, there will be some perceivable degradation in voice quality dyuring periods of IEEE 802.11 FH interference.The detailed model described later quantifies the level of packet error rate. The network throughput would decrease and the network latency would increase for 802.11b interference. A  A large number of errors on an SCO link can cause voice quality degradation.


Comment:
change  IEEE 802.15.1 uses frequency hopping spread spectrum, while IEEE 802.11b is a frequency-static system that uses direct sequence spread spectrum and complementary code keying. The bandwidth of 802.11b is about 22 MHz so of the 79 channels that 802.15.1 hops over, approximately 22 of those channels are subject to interference, depending on signal power levels. 18 The detailed model described later quantifies the level of packet error rate. The 802.11b represents a worse interferer than the 802.11 FH. For data transfer the network throughput would decrease and the network latency would increase, in the presence of 802.11b interference. The packet error rate for SCO link can cause voice quality degradation. Since a frequency hopping system is susceptible not only on the channel it is operating, but also the adjacent channels, the 22 channels susceptible channels could be increase to 24 channels.

SuggestedRemedy:
to IEEE 802.15.1 uses frequency hopping spread spectrum, while IEEE 802.11b uses direct sequence spread spectrum and complementary code keying. The bandwidth of 802.11b is 22 MHz.  22 of the 79 hopping channels available to IEEE 802.15.1 hops are subjectto interference.  A frequency hopping system is susceptible to interference from the adjacent channels. This increases the total number of  interference channels from 22 to 24.161718The detailed model described later quantifies the level of packet error rate. The802.11b represents a worse interferer than the 802.11 FH. For data transfer the network throughput woulddecrease and the network latency would increase, in the presence of 802.11b interference. The packet errorrate for SCO link can cause voice quality degradation.


Comment:
remove the word ""respectively"".  With respect to what?


Comment:
change The MAC layer models are interfaced to these PHY models,

SuggestedRemedy:
to-The MAC layer models  interface to these PHY models,


Comment:
change  impact the performance of higher layer applications and the MAC layer.

SuggestedRemedy:
to impact the performance of higher layers.


Comment:
change Similarly, changes in the behavior of the MAC layer protocol and the associated data traffic distribution could play an important factor in the interference scenario and affect the overall system performance.

SuggestedRemedy:
to Changes in the behavior of the MAC layer protocol and the associated datatraffic distribution impact the interference scenario and  the overall system performance.


Comment:
change Collaborative is defined as a coexistence mechanism where WPAN andWLAN exchange information between one another to minimize mutual interference while Non-Collaborativeis defined as a coexistence mechanism where no exchange of information is used between two wirelessnetworks.

SuggestedRemedy:
Collaborative is defined as a coexistence mechanism where WPAN andWLAN exchange information r to minimize mutual interference.  Non-Collaborative is defined as a coexistence mechanism where no exchange of information  between two wirelessnetworks occur.


Comment:
reword - In addition, by carefully scheduling packet transmission so that the IEEE 802.15.1 devices transmit during hops that areoutside the WLAN frequencies and refrain from transmitting while in-band, interference to WLAN systemscould be avoided/minimized and at the same time increase the throughput of the IEEE 802.15.1 systems.


Comment:
This is then converted into an effective BER given the number of bits per symbol.

SuggestedRemedy:
Given the number of bits per symbol, the SER is converted into an effective BER.


Comment:
The document specifies three ""recommended"" approaches.   1- No where does it state if that there is compliance between devices if tow vendors choose two different approaches 2- If these are recommendations, what happens if a vendor implements a non-standard approach?


Comment:
In this subclause, the modeling of the physical layers of the IEEE 802.15.1 and IEEE 802.11b (WLAN) sys-tems are discussed, and then their bit error rate performances in interference-limited environments are exam-ined.

SuggestedRemedy:
In this subclause, the modeling of the physical layers of the IEEE 802.15.1 and IEEE 802.11b (WLAN) systemsare discussed,.  Followed an examoination of  the bit error rate performances in interference-limited environments.


Comment:
delete ""The resulting performance curves are quite accurate, butthey are obtained at the expense of significant computation.""


Comment:
The outline of the clause is as follows: subclause 5.4.1 describes the model for IEEE 802.15.1, while sub-clause 5.4.2 does the same for 802.11b.

SuggestedRemedy:
The outline of the clause is as follows: subclause 5.4.1 describes the model for IEEE 802.15.1 and  sub-clause 5.4.2 describes the model for for 802.11b.


Comment:
Some of the text and the figures have been taken from Soltanian [B14], which also contains additional results for flat fading channels.

SuggestedRemedy:
Soltanian [B14] contains additional results for flat fading channels.


Comment:
This sampling rate is appropriate for f d up to 22 MHz. A uniform random delay t d = [0,T) and a random phase

SuggestedRemedy:
This sampling rate for f d up to 22 MHz  is appropriate.


Comment:
The PTA technique however coordinates sharing of the medium on dynamically, based on the traffic load of the two wireless networks.

SuggestedRemedy:
The PTA technique coordinates sharing of the medium on dynamically, based on the traffic load of the two wireless networks.


Comment:
the word ""dynamically"" is an adverb.  What is it modifying?  ""The PTA technique however coordinates sharing of the medium on dynamically, based on the traffic load of the two wireless networks.""


Comment:
Change the double arrow to two inward pointing arrows.  I thought the double arrow was a diamond.


Comment:
is this a recommended practice or a standard?


Comment:
title in figures 39 and 40 have extra period after ""nulling""


Comment:
figure 42 has a legond of 8 items, but only 7 curves


Comment:
figure 48 legand states ""wo"" it should be ""w/o""


Comment:
the values in ""error rate is ~ 24% for DM5 and DM3, and 19% for and DM1 packets,"" are not supported in figure 48


Comment:
Note that, when bad channels are used, packets are dropped and have to be retransmitted, which yields large delays.

SuggestedRemedy:
When bad channels are used, dropped packets are retransmitted,  yielding large delays.


Comment:
run on sentance- ""Since there may be vendor-specific variations and even implementations besides the examples described here, to qualify andaccept a channel classification implementation should call for an objective criterion, and even a testing pro-cedure,which are beyond the scope of this clause.""


Comment:
(usually a bit map standing for conditions of different channels) will be used to compile a final list of good

SuggestedRemedy:
(a bit map standing for conditions of different channels) will be used to compile a final list of good


SuggestedRemedy:
12.1.1.1. received signal strength indication (RSSI)


Comment:
the term ""RSSI has been low the error(s) nature is propagation effects"" and ""RSSI has been high the error(s) nature is interference"" makes no sense? inFor example, if the packet has not been decoded successfully and RSSI has been lowthe error(s) nature is propagation effects. On the other hand if the packet has not been decoded successfullybut RSSI has been high the error(s) nature is interference.


Comment:
you state ""failure to synchronize the access code (or access code correlator fails)"" in line 13.  In 21 you only use ""if the access code correlator fails,"".  Does line 21 have an incomplete list?


Comment:
any time slot or odd time slots? in ""any receiving time slot (i.e., each odd time slot)""


Comment:
don't all packets have access codes and headers? ""These packets (during connection) contain at least an access code and a header.""


Comment:
This paragraphs repeats the first paragraph.  It should be deleted.


Comment:
if you are offline, how can you collect anything?""The channel classification can be performed by blocks, during the connection state or offline.""


Comment:
This will, however, compromise the accuracy of the measurements at each channel.

SuggestedRemedy:
This will compromise the accuracy of the measurements at each channel.


Comment:
The draft consists of a number of ideas supported by detailed simulations. Most of the ideas will never be implemented in practice (particularly the collaborative mechanisms and the mechanisms that require communictations between entities) and it is not even clear that the simulations are valid given their limited scope

SuggestedRemedy:
File the document away as an interesting set of ideas and let the market forces develop appropriate solutions. Giving the document the status of recommended practice at this stage implies we understand the spectrum of solutions and can make a reasonable recommendation; we can't!


Comment:
The first paragraph is a list (or non sentences) that needs an introduction


Comment:
The scope includes ""to suggest modifications to other IEEE 802.15 standard(s) to ..."" Why does this practice ""suggest modifications"" to other 802.15 standards? Wouldn't it be more sensible to actually change the standards themselves rather than making it a two step process.

SuggestedRemedy:
Change scope so that this document provides ""guidelines for all current and future 802.15 standards to ensure interoperability""


Comment:
The scope is confusing; the first paragraph appears to suggest a wide scope including all 802.15 now and into the future. The second paragraph limits the scope to just current 802.11h. Which is it?


Comment:
Line 3 claims 2Mb/s is included; line 7 claims it is not. Which is it?


Comment:
0.5 metres appears arbitrary; on what basis is this distance chosen?

SuggestedRemedy:
Insert a functional definition for colocation


Comment:
""meter"" is spelt ""metre"", even in US English!


Comment:
To the best of my knowledge, a recommended practice is not permitted to directly make changes to a standard.  A new beacon element for 802.11 violates my assumption.  The description of AFH later in the document attempts to modify 802.15, which is also beyond the license of a recommended practice.

SuggestedRemedy:
Either correct my assumption about what a recommended practice may do, or complete the required coordination with 802.11 to insert this into the standard (possibly under QoS enhancements).  (802.15 coordination needed too)


Comment:
There is insufficient information in the beacon element to determine the start of the WPAN interval.  The value of T1 is required and does not explicitly appear.  There is a mention of shared knowledge of T1, but I can't see how.

SuggestedRemedy:
Illustrate how the knowledge of T1 is shared, or explicitly share it in the beacon element.


Comment:
Table 19 appears to swap ""None"" and ""Receive"" in the ""in-band"" and ""out-of-band"" locations of ""receive"" vs ""receive"".

SuggestedRemedy:
Since table 20 defines the ""receive"" collision type as ""in-band"", then it makes sense to swap the entries in table 19 so ""receive"" appears in the ""in-band"" location.


Comment:
Table 24 shows PCF reacting to denied TX requests by waiting a PIFS time before resuming operation.  I don't understand if this is an additional PIFS time, or a PIFS instead of a SIFS, or something else.  I read this to mean that the PCF is unaffected by a denial of a TX request.

SuggestedRemedy:
Explain more fully how the PCF is affected by a denial at a TX request.


Comment:
The minimum number of frequencies permitted by the FCC is something on the order of 72 or 76 hops of the total 80 available.  Does eliminating 3 to 7 hops do much to enhance cooperation between technologies?  The importance of the AFH technique is not apparent.

SuggestedRemedy:
Include a comparison of before and after AFH similar to figure 46 and its supporting text.


Comment:
Great research, information and proposals.  Good job.


Comment:
AWMA will not work for legacy stations, will not provide QoS support for 802.11e, and will interfere with timers for legacy equipment.  It may also have problems with overlapping BSSs.

SuggestedRemedy:
Delete it as it exists. A better method is to have fixed channelization partitioned between the 2 systems as in 10.4


Comment:
To expand on other comments about AWMA, in this clause, a change is required to 802.11, beyond, I believe the PAR of 802.15.2.  Furthermore this change would have to be dealt with in light of changes being made now in 802.11h, 802.11e, and 802.11i.

SuggestedRemedy:
Delete this clause- in fact, delete the whole section relating to AWMA


Comment:
Here's another deficiency with AWMA: the use of a CTS would only silence the medium for 3.2767ms.  Thus it would be effectively unusable to signal the end of a WLAN period, assuming a beacon interval of approximately 100ms, unless one wanted to limit the 802.15.1 system to use less than 3% of the available time.


Comment:
Subtitle for 4.3.1 and 4.3.2 Non-Collaborative and Collaborative ""proposals""


Comment:
Figure 1--- (remove/fix the long dash) applies throughout document.


Comment:
Figure text smaller that that allowed in IEEE Style Guide (applies throughout) Figures 9, 10, 11, 12, 13, 14, 15


Comment:
The result in figure 21 is quite counter-intuitive when compared with the PER in figure 20.

SuggestedRemedy:
Make a clearer explanation or redo the work?


Comment:
The sentence is not cleared. "Note that the same partition sequence value is assigned to both the master and the slave."

SuggestedRemedy:
"Note that the same partition sequence value is assigned to both the master-to-slave slot and the immediately following slave-to-master slot."


Comment:
Currently superframe is periodic and we have to define its boundary with respect to some reference signal (i.e. CLK).

SuggestedRemedy:
Need a new subclause describing the timing alignment of superframe and clock.

Response:
TE-Refuse The information is defined in the IEEE 802.15.1, if it were present here, it would lead to confusion on whether this Recommendation is redfining it.  Since this is a Recommended pratice for IEEE 802.15.1 and IEEE 802.11b, it is assumed, and also


Comment:
Table 19 Receive-Receive in-band entry should be Receive collision, while out-of-band entry should be None entry.


Comment:
The two MAC layer techniques both involve.... (reword)

SuggestedRemedy:
Both MAC layer techniques involve ......


Comment:
TWPAN ...(WPAN should be sub-scripted). The combined duration of these two subintervals must equal... (must is a depricated IEEE word)


Comment:
...values must be sent to each... (search on the word ""must"" and replace with appropriate(either shall or should) especially in Clause 10...


Comment:
Figure not readable (also applies to Figure 45 pg 65)


Comment:
In the example below, the first pair..... (refer to example in Figure 44 by name, not location)


Comment:
...average the schedulaing policy yields to a delay increase....


Comment:
Strike the word ""two"" in the first sentence.


Comment:
Refer to ""Master"" as ""The Master"" throughout subclause.


Comment:
Figure citation needs fixing....(Figure XXX)


Comment:
An ACL only connection implies that only data...

SuggestedRemedy:
...implies that only asynchronous data....


Comment:
Bad grammer in first sentence of 4th paragraph.


Comment:
The overview is not quite consistent with the PAR title. The overview focused on WLAN/WPAN 
coexistence, while the PAR addresses more general wireless devices operating in unlicensed frequency bands.


Comment:
Significant formatting problems.  The headings that appear in the  Acrobat menu are completely inappropriate.

SuggestedRemedy:
Make sure heading styles are consistent and used appropriately.


Comment:
""For example, both IEEE 802.11b and IEEE 802.15.1 operate in the same 2.4 GHz Industrial, Scientific, and Medical (ISM) band.""  This may be a minor point, but it is not relevant to refer to the 2.4 GHz band as an ISM band, because the devices to which we refer are not ISM devices.  ISM, according to the FCC is ""equipment or appliances designed to generate and use radio frequency (RF) energy to perform some work other than telecommunications.""  The ISM band is actually 2400-2500 MHz, while the Part 15 band, the relevant rule section in the US, is 2400-2483.5 MHz.  References to ISM bands occur in other places as well, for example Section 12.

SuggestedRemedy:
Refer to the bands as unlicensed, or license free, 2.4 GHz bands.


SuggestedRemedy:
Change the formatting for references to figures.  This occurs throughout the document.


Comment:
The word ""gray"" in ""gray coded"" should be capitalized.


Comment:
""The performance for 802.11 interference"" should be ""The performance for 802.11b interference.""  Other work will need to be done to look at 802.11g, 802.11 frequency hopping, etc.


Comment:
Should the references to ""BT"" be changed to 802.15.1?


Comment:
The curve for scenario 3 may need some more explanation.  It is clear that at short distances the 802.15.1 voice connection is causing severe interference to the WLAN, blocking packets, and increasing latency.  However, why would this peak at 1.5 m?  Why isn't the effect worse at 0.5m and 1.0m?

SuggestedRemedy:
Add explanation for the shape of this distribution.


Comment:
""The foundation for the effectiveness of these types of methods is to be able to figure out the current channel conditions accurately and timely.""  Does this mean ""in a timely manner?""


Comment:
Several figures(43, 45) refer to Bluetooth throughput, rather than 802.15.1.

SuggestedRemedy:
Change references from Bluetooth to 802.15.1.


Comment:
There are very few explicit ""recommendation"" sections.  (An exception would be section 10.1.)  That being the case, should all statements in the document be taken as recommendations?  For example, in section 5.4.3 it says ""This result is not surprising, since the CCK provides a higher bit rate but occupies the same 22 MHz bandwidth, thereby having less of a coding gain. Generally, the receivers used for both 1 Mbit/s and 11 Mbit/s are fairly simple, and improved performance can most likely be obtained using more sophisticated signal processing. This fact is especially true for the 11 Mbit/s CCK system.""  Is it, then, a recommendation from IEEE that improved signal processing be used in 11 Mbps 802.11 DS devices in order to reduce their sensitivity to interference from 802.15.1 devices?


Comment:
In all of the coexistence simulation modeling, for example in section 9, there are many figures showing the effect on throughput and delay of various interference scenarios.  In section 10, though, which discusses collaborative mitigation techniques there does not appear to be any discussion of the effect that these techniques will have on throughput.  For example, AWMA in its simplest implementation would allow 50% of the time for WLAN transmissions, and 50% of the time for 802.11 transmissions.  This should reduce the effective throughput by approximatly 50%.  Even the PTA, which operates more dynamically, will reduce the throughput of each of the systems according to the load being offered by the other system.  Since this is recommended practices document, such an effect should be explicitely stated.

SuggestedRemedy:
Add some discussion in section 10 of the effect on user throughput of these mitigation techniques.


Comment:
The scope of 802.15.2 D05 is limited to coexistance of 802.11b-1999 and 802.15.1. 
There is need for information  on 802.11g performance in the presence of a 802.15.1
intereference.  The  co-existance mechanisms should address the specific case when 802.11e is the mac. 
 
Although these standards are in draft ballot stage, they are reasonably complete enough to address  coexistance issues,   P15.2 should address both g and e to be useful.

SuggestedRemedy:
Liason with 802.11 TGe.  Add text to address the issue of 802.11g, perhaps based on studies described in 01061r0g-Coexistence_of_BT_with_80211g.


Comment:
The period time ... should be changed to


Comment:
Deterministic spectral excision is a poor recommended practice.1. WLAN devices still interfere with WPAN deviced2. WPAN devices still interference with other WLAN devices unless those device have scatternet capable WPAN receivers3. WPAN device needs to be scatternet capable4. Overlapping piconets will transmit simultaneously on different WPAN channels within the WLAN channel


Comment:
AWMA is recommended for high density WLAN/WPAN area. As such there will be 3 non-overlapping WLANs in the same area.. For AWMA to be effective, all the WLANs need to share the same time sharing parameters and have the same clock timing. A method needs to be developed that allows all the WLANs to coordinate timing.


SuggestedRemedy:
Add sentence:Alternating Wirless Medium Access Control Area (AWMACA). All devices entering into the AWMACA shall adopt the rules of the area.1. All WPAN master devices must role-switch to a AWMA master in the area.2. Only piconets with a AWMA master are allowed3. IBSS networks must adopt the timing parameters and synchronize its clock with the AWMACA.4. All WLANs in the AWMACA shall adopt the timing parameters and synchronize its clock with the AWMACA.


Comment:
PTA can only work if the WPAN device also uses apative frequency hopping to avoid interfering with other WLANs in the same location.


Comment:
In Figure 4, there is no curve for the 802.15.1 receiver.


Comment:
How is T1 decided? Why the 1-10ms range? Is T1 to be negotiated by the devices or should it be the same within BSS?

SuggestedRemedy:
Please provide the rationale for T1's range, and how it will be decided or negotiated.


Comment:
It is not clear to me how the collaborative methods in 10.2 and 10.3 will work in a QoS enhanced 802.11 environment. Since it is likely that the collaborative methods will be implemented at the same time as the 802.11 QoS enhancements more than the 802.11 legacy case should be treated.

SuggestedRemedy:
Clarify how the collaborative methods in 10.2 and 10.3 will work in an 802.11 QoS enhanced environment.


Comment:
Deterministic spectral excision is a poor recommended practice.1. WLAN devices still interfere with WPAN devices2. WPAN devices still interference with other WLAN devices unless those devices have scatternet capable WPAN receivers3. WPAN devices needs to be scatternet capable4. Overlapping piconets will transmit simultaneously on different WPAN channels within the WLAN channel


Comment:
""In a communication system, extraneous"" should be ""Extraneous""


Comment:
The document contains too much ""why"" (with very detailed supporting equations and simulations) rather than a concise statement of the problem and a recommended solution (or solutions)

SuggestedRemedy:
At the very least remove all the ""why"" to an appendix


Comment:
fhop is claimed to be a frequency and yet the definition seems top refer to channel numbers. Is is a frequency or a channel number?


Comment:
Presumably the recommended practice is more restrictive than just ""IEEE 802.11 WLANS""; it should be 802.11 WLANS operating in 2.4GHz bands


Comment:
""to in increase"" should be ""to an increase""


Comment:
The equations do not cover all cases, eg when RTS/CTS is sent before a packet/ACK


Comment:
The clause does not make clear in what period the CTS is transmitted. If it is sent in the WLAN period there will be cases in which it would not be sent at all. If it is sent in the WPAN period the 802.15.1 master had better know about it


Comment:
Why wouldn't you want to use the CTS to itself technique to stop all transmission during the WPAN period? It seems strange that other AP's on the same channel are alllowed to transmit


Comment:
Using a notch filter to remove the interference effects of an 802.15.1 signal from an 802.11b signal will work if the interference location is static through the entire 802.11b packet (which it is not since it hops 160 times in 100ms).  Otherwise, changing the location of the notch filter as the 802.15.1 interference hops will create what looks like a time-varying channel response to the 802.11b packet.  This type of channel behavior would necessitate the use of an advanced equalization method.

SuggestedRemedy:
Remove the recommended practice of using spectral excision for PHY layer coexistence.


Comment:
How is AWMA coordinated with probable enhancements of fair-queuing in WLAN, such as HCF and EDCF, where time division of the beacon interval is used for QOS reasons.  Have the mechanisms of HCF been studied when used in conjunction with AWMA?


Comment:
Remove editor’s note referring to 2Mbps. 2Mbps is part of 802.11b and therefore this not is incorrect.


Comment:
This introductory clause says that the scope of this document is limited to DCF and  does not address PCF. However, Table 24 in 10.3.5 addresses how PTA functions for PCF.

SuggestedRemedy:
Correct introductory text, or remove PCF behaviour in PTA.


Comment:
This high-rate PHY is often referred to as IEEE802.11b. It is not ‘often referred to’ but was ‘standardized’ as IEEE802.11b!


Comment:
This document would be easier for a new reader if the analytical work that is the background to the actual recommended practice was moved to an annex (this applies to sections 5 through 8).

SuggestedRemedy:
Consider dividing the document into a recommended practice body and informative simulation/analysis annexes.


Comment:
’No new on-air signalling is required’. However, a new information element for beacon and probe response management frames is defined. Sounds like new on-air signalling. This together with new MLME primitives and MIB extensions seems to be defining extensions to the 802.11 MAC. Given this is the case I don’t see how this can be a recommended practice since it is defining new protocol elements and modifying the behaviour of the 802.11 MAC - it has to become a new 802.11 standard surely.

SuggestedRemedy:
I don’t believe that modifications to the 802.11 MAC are permitted within the scope of a 802.15 recommended practice. Therefore, either this has to be a new 802.11 standard, or the functionality has to be built on top of the existing MAC without modification (like 802.11 TGh has). Maybe it would be possible to still have this coexistence mechanism by assuming that implementations following the recommended practice have a view of the internal state of the MAC but surely new elements, primitives and the like are out. Even if this view is not the case, there does seem to be new on-air signalling!


Comment:
Timing values to be distributed through the WLAN network management tool (i.e. outside the scope of this recommended practice). This implies that the element defined is not actually required and that some 802.15.2 MIB is being set by a higher layer protocol. If that is the case why define the element at all (which is outside the scope of a 802.15 recommended practice). I also note that (a) these need to get into STAs before active scanning to avoid getting management frames sent in the WPAN period, and (b) some description of IBSS operation is required.

SuggestedRemedy:
This coexistence mechanism seems to be very confused. Either remove it, or rewrite it to be (a) self-consistent and (b) consistent with a recommended practice. Does it use a side channel, or new elements for parameter communication? Are the parameteters set by the AP in an infrastructure BSS? Are they set by the STA that starts an IBSS? Do other IBSS STAs inherit the values when they join?


Comment:
New 802.11 MLME primitives are outside the scope of this recommended practice. If it is possible to specify this coexistence mechanism without change to the 802.11 MAC then this MIB should be defined as an 802.15.2 MIB.

SuggestedRemedy:
It is not possible to change, or add to the 802.11 MAC from this document (I believe). Redefine this coexistence mechanism to use the existing MAC and define any new functionality separately. Maybe it is OK to say that implementations following the recommended practice have a view of the internal state of the 802.11 MAC? Even if MLME additions are allowed, there is no need for new primitives. This interface would be better done using MLME-GET/SET on the new MIB attributes defined (with the addition that it would be nice to have a capability MIB attribute too).


Comment:
Firstly see comments from this author on appropriate scope for an 802.15  recommended practice. Second the 802.11 MAC behaviour around the start and end of the WPAN interval needs to be more precisely defined, for example, do STAs that defer due to a pending WPAN period select a backoff value, increment their retry counters, etc..

SuggestedRemedy:
If I'm incorrect about it being inappropriate for this 802.15 recommended practice to add to, or modify the 802.11 MAC, then specify explicitly the MAC behaviour around the WPAN period, including back-off, IFSs used and retry counter behaviour. See the behaviour of the .11 MAC around dwell boundaries for an example.


Comment:
The 802.11 MAC does not allow the transmission of a CTS frame in isolation with a specific duration value. This frame exchange sequence and duration setting facility simply do not exist in the current 802.11 MAC. This is one reason why in the IEEE802.11 TGh draft we have defined a new quiet period mechanism (an aside is that even if it did exist the duration is limited to 32Kus). Note that (a) even if this CTS mechanism existed it would be imperfect and (b) the group addressing scheme to involve other APs violates the current rules further. This latter point is due to the fact that CTS is not used in multicast communication.

SuggestedRemedy:
Remove this mechanism as no such facility exists and it overloads the CTS functionality.


Comment:
The definition of coexistence seems to (partly) overlap with interoperability. Do we want to strictly divide between the two?

SuggestedRemedy:
State clearly whether interoperability is included in coexistence or not.


Comment:
This says No new on-air signalling is required . However, since we need a new information element for beacon and probe response management frames I don t see how this statement is true. In fact I think new on-air signally is required and this is outside the scope of a recommended practice.

SuggestedRemedy:
If there is no solution that can be implemented without these signalling changes then the recommended practice should be dropped and a PAR sough for a new standard.


Comment:
The recommended practice to use a notch filter has the problem that 802.15.1 signals are frequency hopping; this means that the 802.11b receiver would have to change its notch and equalizer if a hop occurs within a packet. It is not clear whether this is possible without fatal transient effects that would kill the 802.11b packet.

SuggestedRemedy:
Remove the recommended practice of using notch filtering.


Comment:
The document only addresses 802.11B interference while current
standardization in the
2.4 GHz band is covered in the 802.11G annex. The new modulation schemes
proposed in
11G need to be taken into account in the analysis on mutual interference and
in proposed
solutions. Any new development in this band is likely to address 802.11G
rather than just 11B.
Any investment in collaborative schemes must have applicability for 11G to
be of interest.

SuggestedRemedy:
Include analysis and simulation material addressing the 802.15 and 802.11G
coexistance.
Include outcome of those analysis and simulation in proposed schemes for
interference 
reduction.


Comment:
The document lacks a systematic overview of scenarios of mutual interference
and which solutions
address which scenario of interference.

SuggestedRemedy:
Include a systematic overview of scenarios of mutual interference and which
solutions
address which scenario of interference.


Comment:
T1 could possibly be better expressed in 802.11 TU's.


Comment:
T1 is also required in order to do an accurate calculation of the two
periods.


Comment:
The proposed control of legacy systems will not work when a legacy device
is operating in power save mode and wakes up to transmit a packet.


Comment:
Table 24, third column (PCF(as CF-pollable STA)): This condition here seems rather artificial. If a STA gets a poll and has a WLAN MPDU to send, would it be still denied access? Am I not understanding this correctly?

SuggestedRemedy:
Clarify. If my understanding is correct, remove this restriction.


Comment:
As the recommendation suggests additions of the Information elements, this needs to be added into 802.11 standard so that non-802.15.2 devices can still be conformant

SuggestedRemedy:
Work with 802.11 group to make that addition.


Comment:
It seems that the Collaborative proposals are creating new system which need some interaction fucntions between .11b and .15.1 system. How many chances these two systems exist in one physical unit, which happens to have such functions? Why bother to create so complicated scheme which will hurt both systems performance?

SuggestedRemedy:
remove collaborative proposals; focus on non-collaborative proposals.


Comment:
Since there is no sensing in .15.1 master, how can the proposed collaborative proposal to prevent the .15 device sending in WLAN subintervals?


Comment:
Shows IEEE 802.15.1 (Draft 1, July 2001 Sponsor Ballot).

SuggestedRemedy:
Replace with IEEE 802.15.1 Standard (and appropriate date)


Comment:
Section 11.2 (Packet Scheduling for Improving SCO Links) needs to be harmonized with Bluetooth 1.x Speech Improvement when schedules from both groups allow.

SuggestedRemedy:
Depending on the progress/schedule of this LB, it may be possible to incorporate changes to harmonize with Bluetooth SIG. If it becomes feasible to do so, changes are recommended.


Comment:
Section 12 (Adaptive Frequency Hopping) needs to be harmonized with Bluetooth Coexistence group work when schedules from both groups allow.

SuggestedRemedy:
When the schedule for this LB allows, AFH section should be harmonized with Bluetooth SIG.


Comment:
Need to consider the impact of equalizer for the coexistence PHY model simulation.

SuggestedRemedy:
Suggest adding multipath results in the simulated and analytical results.


Comment:
Some of the simulation curves only cover BER down to somewhere between 10-2 and 10-3. Should use BER of at lease 10-4 as the threshold for more useful results, because a BER of 10-2 to 10-3 will yield too high a Packet error rate for pactical usage.

SuggestedRemedy:
Rerun simulation to extend the results to more BERs.


Comment:
Should use BT hopping sequence instead of random sequence in MAC OpNet model

SuggestedRemedy:
Change the hopping sequence in the MAC model to BT sequence


Comment:
Take out Section 10.4: the method is only shown effective for 802.11b 1Mbit/s mode. The impact of equalizer is unknown. Cost of implementing an 802.15.1 receiver to just get the hopping sequence and timing is expensive and hardly feasible due to cost consideration.

SuggestedRemedy:
Take this section out or ask more results to backup its performance: 2,5.5, 11mbps, with equalizer considered.


Comment:
It would be nice to have source code for the PHY coexistence model as Appendix


Comment:
It would be nice to have the OPNET MAC model as appendix.


Comment:
lines after figure number, i.e. figure 34-


SuggestedRemedy:
coordinate the order number with other task groups, 11e,
11i, 11h


Comment:
The specturm factor is not necessarily unity at frequency offset zero. Consider the case of 802.11b tx 
and 802.15.1 rx, the full tx power occupies a bandwidht of 22MHzm, and only a fraction of it can pass 
the 1MHz channel filter of 802.15.1.


Comment:
The definition of frequency offset in Table 3 should be clarified.

SuggestedRemedy:
It should be defined as the offset between the central frequencies of the transmitter and the receiver.
The rows of two types of transmitters should be splitted, and the table of content should be modified 
according to the above frequency offset definition.


Comment:
There should be no difference betweem spectrum factors of Barker mode and CCK mode in Table 4.


Comment:
It is said to be a complex baseband model. But the equations in the subclauses sometimes
are presented in a passband form.


Comment:
TGg is describing mechanisms to enable coexistence between legacy .11b devices and .11g capable devices. Have the performance impacts and increased complexity of these mechanisms been modeled when used in conjunction with AWMA. A mechanism needs to be defined regarding the prioritization of 802.15, 802.11b legacy and 802.11g.

SuggestedRemedy:
Remove AWMA recommended practice for now.


Comment:
TGg is describing mechanisms to enable coexistence between legacy .11b devices and .11g capable devices. Have the performance impacts and increased complexity of these mechanisms been modeled when used in conjunction with PTA?

SuggestedRemedy:
Remove PTA recommended practice for now.


Comment:
The use of a notch filter to remove the interference effects of an 802.15.1 signal from an 802.11b signal will likely not be effective, since the interference location is not static through the entire 802.11b packet (hops 160 times in 100ms). Changing the location of the notch filter as the 802.15.1 interference hops creates what appears to be a time-varying channel response to the 802.11b packet. This type of channel behavior necessitates the use of an advanced equalization method.

SuggestedRemedy:
Remove the recommended practice of using spectral excision for PHY layer coexistence


Comment:
Given that TGg has made significant progress and is likely to be finished soon, it makes much more sense to expand the scope of this document now to include the issues associated with coexistance between 802.15 devices and 802.11g devices. It is highly likely that most if not all future products in the 2.4 GHz WLAN space will be incorporating .11g it is practically irrelevant to speak to coexistence with .11b only devices.

SuggestedRemedy:
Expand the scope of this set of recommended practices to include .11g now, rather than waiting for some future revision.


Comment:
TGg is describing mechanisms to enable coexistence between legacy .11b devices and .11g capable devices. These need to be taken into account in regards to the AWMA recommended practice or the recommended practice needs to be removed.


Comment:
This draft is for a recommended practice, not a (supplementary) standard. However, I find that it changes many MAC operations at least from the 802.11 perspective. For example, AWMA in Clause 10.2 modifies the 802.11 MAC to time share with 802.15.1. The operations to handle the legacy (?) 802.11 stations as described in Clause 10.2.4 are not also compliant with 802.11-1999.

SuggestedRemedy:
Remove all the mechanisms and operations which are not compliant with 802.11-1999 specification. Otherwise, reclassify this draft specification as a draft for a supplementary standard.


Comment:
Given that a modification of PCF (called HCF) would most certainly exist in the future, I think the co-existence mechanism should cover that as well

SuggestedRemedy:
Provide a mechanism that addresses co-existence in PCF and HCF


Comment:
It is not clear how the spectrum factor values have been derived. An informative reference would be useful to the reader.


Comment:
It is not clear from the text if PTA is another technique or part of AWMA. Both of them appear to have the requirement of WLAN/802.11 and WPAN/802.15.1 are collocated. Also, is there a reason to distinguish between WLAN and 802.11 as well as WPAN and 802.15.1


Comment:
It appears to me that the AWMA technique can be easily extended to PCF/HCF.


Comment:
Spectral excision is a sub-optimal method of removing the effects of WPAN devices on WLAN devices. If a device is required to have both WPAN and WLAN receivers, an optimal receiver would make joint decisions given information from both detectors, i.e. searching the entire receive space given knowledge about the two waveforms. Furthermore, if spectral excision is used, more advanced equalization techniques will need to be used in the WLAN reciever at the hop-boundaries due to the time-variation required on the nulling filter. Using a joint detector will obviate the need for a nulling filter or an equalizer.

SuggestedRemedy:
Remove the recomended practice of spectral excision.


Comment:
This document only applies to WPANs and
802.11-1999,
                           not to any other wireless technologies.

SuggestedRemedy:
Change title word "Other" to 802.11-1999


Comment:
This document is a yeoman technical effort, but needs a thorough editorial review and fixes.

SuggestedRemedy:
Have one or more technical editors review and fix the text.  Watch out especially for number mismatches ("one item are..."), "effect" when "affect" is meant, and typos in table fields.  Aside:  Is a "Recommended Practice" a *Standard*?


Comment:
Initial Page nees to be checked.  When I printed mine, the ""Committe of the IEEE Society"" , "" Abstract:"" and ""Keywords "" were floating in amoungst the text.


Comment:
Although not part of the standard, the comment that the Intro is not part of the standard should be complete and correct.

SuggestedRemedy:
Correct the ""This introduction is not part of the IEEE std xx-200x, title"" statement.


Comment:
THe Editor's note states that 2 Mbit/s is not included, yet the paragraph just above the statement does include 2 Mbit/s.  Which is it?

SuggestedRemedy:
The rates supported needs to be consistantly stated in the doc.  I suggest that you Remove the Editor's note:


SuggestedRemedy:
I believe the correct reference should be 802.11b.


Comment:
Line 15 is confusing.  The sentance fragment ""but also the adjacent channels, the 22 channels susceptible channels could be increase to 24 channels.""  needs to be clarified.

SuggestedRemedy:
possible correction:""but also the adjecent channels, the 22 channels that are susceptible could be increased to 24 channels"".


Comment:
AWMA will have limited benefit in the presence of overlapping cell. This is because BSS are not coordinated in an ESS. However, clause 10.1 page 41 line 51 recommends using AWMA when there is a high density of users.


Comment:
The bookmarks in the PDF file are incorrectly extracted from the main document. They do not include the headings or subheadings of the document, but rather portions of the body text.

SuggestedRemedy:
Configure Acrobat properly - verify bookmarks before distributing next draft


Comment:
The sentence only refers to a single working group. Because this document is being reviewed by 2 working groups, we need to list both lists.Also the term ""At the time this standard was completed,"" is ambiguous: is that time when the standard is sent to sponsor or when sent to revcom?

SuggestedRemedy:
Change ""working group"" into ""working groups"" and change ""this standard was completed"" into ""this standard approved for submission to Sponsor Ballot""


Comment:
The definition of coexistence is not giving a clear picture as to the impact to the pain it would cause. Currently, the reader could assume that neither system is being impacted in performance

SuggestedRemedy:
Add appropriate text to the definition, such as adding at th eend of the sentence ""while the systems are not more degraded then 1/n th of the total of systems operating together compared to operating autonomously"".


Comment:
The word ""shall"" is not appropriate in a Recommended Practice, especially in the area dealing with service primitives, which is supposed to be infomal anyway.


Comment:
The Bookmarks in the PDF do not make any sense.

SuggestedRemedy:
Replace bookmarks with usable list or remove them all together.


Comment:
It is not clear to me how the 802.11b MAC should recover if the PTA
determined that the transmission is not allowed. I think, the following
scenarios are possible:

1. Transmit immediately after the deny condition is revoked.
2. Schedule a new transmission attempt, as if the previous attempt
didn't happen (e.g. don't regards it as a retry).
3. Consider the deny as a 'virtual' collision and schedule a new
transmission attempt as a retry.

SuggestedRemedy:
Refer me to the text that specifies the expected behavior or add
clarifying text on how to recover, possibly based on one of the
scenarios I identified above.


Comment:
PDF bookmarks could do with being reduced in number!


Comment:
scope ""limited to coexistence of IEEE Std 802.11b-1999 Wireless Local Area Net-works (WLAN) and IEEE Std 802.15.1 Wireless Personal Area Networks (WPAN)"" is inconsistent with document title ""Coexistence of Wireles Personal Area Networks with _Other_ Wireless Devices Operating in Unlicensed Frequency _Bands_.""

SuggestedRemedy:
Change title to ""Coexistence of Wireles Personal Area Networks with  Wireless LAN Devices Operating in 2.4GHz Unlicensed Frequency Bands.""


SuggestedRemedy:
Replace ""project"" with ""this recommended practice""


Comment:
""allows any other Access Point"" implies that this node is an AP.  I don't this is the most likely scenario.  A co-loctaed STa-BT device seems more likely.

SuggestedRemedy:
remove the word ""other"" so implying that STAs may also send CTS to reserve the channel for WPLAN.


Comment:
It is unclear what will happen if there is more than one AP(or perhaps STA) reserving WPAN intervals.

SuggestedRemedy:
It may be desirable to have a method to synchonise the WLAN intervals and so WPAN intervals to allow meaningful 802.15.1 transmissions perhaps by sychronisation of TBTT's between BSS's?


Comment:
The CTS mechanism is not a valid protocol sequence in the current 802.11 specification. Furthermore, the use of multicast group bit by STAs for purposes other than multicast by STAs would not be in compliance with the specifications.Since this draft is for a recommended practice, not a (supplementary) standard it can not modify the current standard.


Comment:
This draft is for a recommended practice, not a (supplementary) standard.
It changes too many MAC operations at least from the 802.11 perspective.
For example, AWMA in Clause 10.2 modifies the 802.11 MAC to time share with 802.15.1.
The operations to handle the legacy 802.11 stations as described in Clause 10.2.4
are not also compliant with 802.11-1999.

SuggestedRemedy:
Remove all the mechanisms and operations which are not compliant with 802.11-1999 specification.
Otherwise, reclassify this draft specification as a draft for a supplementary standard.


Comment:
Scope (coexistence of .11b & .15.1) not consistently
applied; 802.11 used in place of 802.11b when
referring to PHY.
This occurs in other clauses as well (see note in Remedy).


Comment:
Editor's note is not consistent with document.
2Mbps is included in 5.3.6.3 and 5.4.3 Figure 10.


Comment:
Statement on scope is under descriptions, and
is inconsistent.  PCF is part of Table 24, and
subclause 10.2 (as Access Point / beacon) as
well as other places in the document.

SuggestedRemedy:
Remove the sentence starting with:
"The scope of this document is limited to DCF"


Comment:
802.11 FH is not in the scope of the RP.

SuggestedRemedy:
Remove subclause 4.1.3, "IEEE 802.15.1 in the
presence of an IEEE 802.11 frequency hopping interferer"


SuggestedRemedy:
Remove subclause 9.3, "802.11 1 Mbit/s frequency hopping
and IEEE 802.15.1 interference"


Comment:
2Mbps DSSS system model missing; results
presented in 5.4.3 include 2Mbps but there
is no discussion of the 2Mbps model.
Also, the 5.4.2 introduction section is a
little confusing; it doesn't mention the 5.5Mbps
model in 5.4.2.2.

SuggestedRemedy:
In 5.4.2:
1) clarify that only the 5.4.4 results are limited
to 1 & 11Mbps
2) add a reference to the 5.5Mbps model
3) add a new subclause for the 2Mbps model and a
reference to it in the intro


Comment:
While there is an extensive treatment of the calculation of bit error rate from SINR, the performance results shown in clause 9 show packet error rate. There is a dubious statement that 'the packet error rate for the WLAN corresponds to the loss of ACK messages'. In reality the packet error rate will be dominated by the loss of data packets, since they tend to be longer than ACK packets and hence more vulnerable to bit errors. This would yield more pessimistic results then those shown. On the other hand there is no discussion of the correlation of the bit errors. If there is structure in the interference (and in this case there is) then bit errors tend to be correlated. This would yield a packet error rate which is less than that for i.i.d. distributed bit errors, i.e. it would make the results more favorable. 
		A third effect which aggravates the packet error rate is the effect of interference on packet detection, which is not modeled and which tends to dominate the probability of packet loss by decoding errors, especially at low SINRs.

SuggestedRemedy:
Specify the model for translating bit errors to packet errors and add a discussion of contributing factors to packet loss which have not been modeled.


Comment:
The coexistence results shown assume HV1 type voice, which uses three times the air time of HV3 type voice (using 1 mbps capacity for just one full duplex 64 kbps link) voice and is more robust due to redundancy than HV3. To add realism and generality to the simulations HV3 traffic should also be treated and the results should be compared with the existing ones.

SuggestedRemedy:
Add an analysis scenario using HV3 type voice, model, analyze, and compare with present results.


Comment:
802.15 is defining other standards that have bearing on coexistence in the
2.4GHz frequency bands (802.15.3, 802.15.4 are examples).  In addition, this
document does not address the 11g technology and coexistence aspects with
the 11b and 15.1/Bluetooth.

SuggestedRemedy:
Develop a revision of this document to include the impact of the newer
standards under 802 (mentioned above) and suggest recommended practices and
changes to those standards.


Comment:
This draft is generally well written and ready for comment.


SuggestedRemedy:
Note that most of the analysis and simulations are for 1 and 11 Mbps.


Comment:
'or the disturbance caused by the undesired power' seems redundant

SuggestedRemedy:
remove 'or the disturbance caused by the undesired power'


Comment:
differentiatedIn note 3 at bottom of page 'much likely that'

SuggestedRemedy:
replace with differentialReplace with 'much more likely than'


SuggestedRemedy:
add (BER=0) to Upper limit column and (BER=.5) to Lower limit column


Comment:
-15 to +20dB appears to be wrong from Figure 4


Comment:
could not find an explicit expression for using td and Phid


Comment:
The methods described are no longer proposals.

SuggestedRemedy:
Please change the section heading of 4.3.1 to ""non-collaborative methods""


Comment:
The collaborative methods are no longer proposals.

SuggestedRemedy:
Please change the section head of 4.3.2 to ""collaborative methods.""


Comment:
The paragraph here describing the two collaborative approachs does not seem to use the same vocabulary or be in synch with the detailed description of the collaborative methods presented in sections 10

SuggestedRemedy:
Please review the summary paragraph contained in 4.3.2 and bring in line with the section 10. Consider writing it in the sytle of paragraph 4.3.1 which provides a nice highlevel overview of the non-collaborative methods. Please specifically use the vocabulary of section 10, namely the AWMA and the PTA technique.


Comment:
I don't know what the sentence ""The 1 and 11 Mpbs mdoes of IEEE 802.11b are implemented""  means. 802.15.2 Models corresponding to 1, 5.5, and 11 Mbps of 802.11b are described in 5.4.2.1 through 5.4.2.3. Results of interference simulation corresponding to 1, 2, 5.5, and 11 Mbps are presented in 5.4.3. The C code models for all modes appear to be included. And finally, 802.11b is implemented fully in the industry.

SuggestedRemedy:
Change the sentence to state ""802.15.2 contains system models of 802.11b 1, 2, 5.5, and 11 Mbps modes.""


Comment:
No system model is presented or discussed for 802.11b 2 Mbps. Simulaiton results are displaeyd in 5.4.3.

SuggestedRemedy:
Please describe the 802.11b system model by adding a new section in 5.4.2.


Comment:
Incorrect word processor reference ""\cite{Bluet99}.


Comment:
It is not clear to the reader that PTA is the second MA layer technique.

SuggestedRemedy:
Please change the first sentence to state"" In the PTA technique, the second MAC layer technique, the 802.11b...""


Comment:
The contents of section 10 is making modificaitons to the 802.11 base document(s). It is very important that this material be presented in a clear format so that the base document can be very well understood by the hundreds of engineers currently extended it in all the various projects. It appears that the material in 10.2.2.1, 10.2.2.2, 10.2.2.3, 10.2.2.4, 10.2.2.5, 10.2.2.6.1, 10.2.2.6.2, and 10.2.2.6.3 make changes to the base document.10.2.2.6.1-3 state that the base document is 802.11.

SuggestedRemedy:
Add somewhere near the top of the document that this 802.15.2 makes changed to the 802.11b-1999 document. Add other documents if you want them modified, too.Add a statement associated with the 10.2.2.x sections that they modify the 802.11b-1999 document.Change the statement associated with 10.2.2.6 to state it is ammending 802-11b-1999.


Comment:
This section contains much explanatory material as well as some normative functional material. This is difficult to know exactly what the new 802.11b document should look like.

SuggestedRemedy:
Please take the functional material (plus any desired explanatory material) and gather it into an Annex or Appendix of 802.15.2. Include in this material a pro forma title Draft supplement to STandard for LAN/MAN Specific Requirements - PArt !!: MAC and PHY specifications: Specificaiton for Coexistesnce of Wireless Personal Area Networks in Unlicnesced Frequency Bands using the Alternating Wireless Medium Access (AWMA) Collaborative Method.Add pro-forma statments that ""This supplement is based on the current edition of IEEE STD 802.11b, 1999. Note -- the editing instructions chaintedin thie supplement define how to merge the material contained herein into the existing base stnadard to form a new comprehensive standard as created by the addition of this Annex. The editing instrucitons are shown in bold italic. Three editing instructions are used: chagne, delete, and insert. [explain the terms as in 802.11d] Editorial notes will not be carried over into future editions.


Comment:
The order 11 in a beacon frame body is defined by 802.11d already and conflicts with this definition.

SuggestedRemedy:
The first unused item in approved 802.11 ammendments is 14; however, proposed 802.11h has already brought forward proposals for 14-18. I recommend changing the order of the item displayed in Table 16 in 802.15.2 to 19.


Comment:
The order 11 items in a probe response frame has already been defined by 802.11d supplement.

SuggestedRemedy:
802.11d defined element 13-n as being present in a probe response frame when the request information item (order 3) asks for them in a porbe request frame. Proposed 802.11h inserts new items 13-17 and defines 18-n as being those present in reponse to a reqeust information item. I recommend that we call the needed item for 802.15.2 order 18 and list 19-n as being present in response to the reqeust information item.


Comment:
The information element with ID 8 has already been defined by 802.11d supplement.

SuggestedRemedy:
The next available number not used in an approved 802.11 draft supplement is 11. PRoposed 802.11h has not used these (but has defined 32 to 41). I recommend that the element id as displayed in Table 18 be changed from 8 to 11. The note reserving elements should list 12-15 as reserved.


Comment:
The draft described a method by which the 802.11b AP can sent out a false RTS/CTS to clear the air so that legacy stations will not transmit (freeing the air for the coordinated WPAN transmissions).This method may work. RTS/CTS without data transmission is not an allowed sequenced in the base document.

SuggestedRemedy:
Add the RTS/CTS into the allowed sequences in Table 21 of the base document. Include editing instructions to insert this sequence in section 9.7. Include this in the Annex/Appendix of the 802.15.2 Supplement to 802.11b.


Comment:
The text describes a method of transmitting RTS/CTS to clear the eair of non-collaborating legacy 802.11b STAs so that collaborating WPAN may transmit.Another method that works and is fully within the sllowed scope of the 802.11b document is to trnamist a BEACON(CF) to start a contention free period. The collaborating AP will avoid polling during the time allocated for the WPAN.


Comment:
The first setence has independent clause.


SuggestedRemedy:
Change the start of the sentence to ""The key idea is to...""


SuggestedRemedy:
Change the sentence to ""Channel classification is described in 12.1""


Comment:
What are the frequencies being marked here with ""yes"" and ""no"" to indicate?

SuggestedRemedy:
I think maybe the yes means ""good"" and the no means ""bad"" based on the information in 12.1.


Comment:
By marking the frequencies is not sufficiently specific to guide implementation. Do we mean marking the freuqices as good or bad according to the frequency classification scheme defined in 12.1?

SuggestedRemedy:
Add sufficient detail to support implementation at the slave.


Comment:
Refresh the frequency usage table is not sufficient to guide implementation. Do we mean by updating the good/bad list at the master end as per 12.1? Do we mean more in terms of updating the slave frequency lists?

SuggestedRemedy:
Provide sufficient desription to guide implementation and to ascertain interoperability between all master and slave implementations.


Comment:
I would prefer to see the material in 12.1 introduced prior to the two methods that use it rather than inside the second method and after the first one.

SuggestedRemedy:
Please consider movign the material in 12.1 to a standalone subsection prior to any reference to it. (Or after all references to it).


Comment:
Numerous references are made to the DS PHY having a channel bandwidth of 22 MHz.  This is not correct.  all current implementations use a SAW filter of about 17 MHz or a LPF of about 8.8 MHz to constrain the emitted spectrum to fit the spectral mask.  Generally speaking the 90% power bandwidth of the signal is around 11 MHz unless artifically processed to expand it.  This is a result of the sinx/x nature of the waveform.  Thus, the actual performance of this simulation will be in error by too pessimistic estimate of the interference potential of the DSSS signal and of the interference rejection of DSSS receivers.

SuggestedRemedy:
Use the more practical bandwidth of 17 MHz for the signal and use actual SIR ratios that can be measured on any of the existing hardware available.


Comment:
Numerous references are made to the DS PHY having a channel bandwidth of 22 MHz.  This is not correct.  all current implementations use a SAW filter of about 17 MHz or a LPF of about 8.8 MHz to constrain the emitted spectrum to fit the spectral mask.  Generally speaking the 90% power bandwidth of the signal is around 11 MHz unless artificially processed to expand it.  This is a result of the sinx/x nature of the waveform.  Thus, the actual performance of this simulation will be in error by too pessimistic estimate of the interference potential of the DSSS signal and of the interference rejection of DSSS receivers.


Comment:
There is no receive mask and if there were it would have a bandwidth of about 17 MHz, not 22 MHz.

SuggestedRemedy:
Use the more practical bandwidth of 17 MHz for the receiver


Comment:
Why does the 802.15.1 system model have a DBPSK mod?


Comment:
Why does the 802.11b system model have a GFSK mod?


Comment:
Most current implementations use the optimal receiver, so why is the sub-optimum receiver used in the model?


Comment:
Why does the CCK system model have a GFSK mod?


Comment:
Why not use the aCWmin feature like in TGg to reserve time for the WPAN transmissions?  Sending a CTS with a huge duration may break legacy implementations

SuggestedRemedy:
Consider change to aCWmin style reservation.


Comment:
An assumption is made that the PN sequence have sufficient length.  That is a laugh with 11 chips.


Comment:
It is said that the LDI receiver design meets the IEEE 802.15.1 on IEEE 802.15.1 interference specifications. A bit confusing wording.

SuggestedRemedy:
Perhaps it means the LDI receiver design meets the IEEE 802.15.1 interference specifications.


Comment:
"A simple two-state Viterbi receiver is introduced for IEEE 802.15.1.  Since these sections deal with coexistence models to quantify interference effects, the reference to a Viterbi receiver would be better placed in non-collaborative mechanism sections."

SuggestedRemedy:
Move all references to Viterbi receiver to a new section on non-collaborative mechanism (between section 11 and section 12?)


Comment:
"Reference is cited with encoded data ""\cite{Bluet99}"""

SuggestedRemedy:
Replace code by normal numbered reference.


Comment:
"Table 10 refers to different ""experiments"" to evaluate the interference effects. Figs. 18-29 show interference simulation results in the presence of different ""scenarios"". Apparently, they refer to the same but it is not clear from the context. Thus, to avoid confusions a unique term should be used."


Comment:
"Figs. 18-29 use a similar legend to identify curves. The legend contents are related to Tab. 10 in someway but it is not full clear.  For instance what does it mean ""Scenario 2 BT Slave""? what is the difference with respect to ""Scenario 1 BT Slave""?"

SuggestedRemedy:
Add an explanatory note defining the meaning of all scenarios.


Comment:
"All figures related to access delay (Figs. 19, 21, 23, 25, 27 and 29) present three curves only. They miss one scenario. why? There is no units for the delay values on y-axis."

SuggestedRemedy:
"Include the missing curves in access delay figures. Write ""seconds"" in the y-axis label."


Comment:
"Figure 21 presents a rare ""peak"" in the delay curve of ""scenario 3 WLAN Mobile"". It is said that it is due extremely high packet error rate.  However looking to Fig 20 (on Packet error rate), it is seen that within 2 meters the PER decays from 90% to 80% and in the same 2-meter interval, the access delay rises from 0.05 sec to 0.15 sec. How can it be that for roughly the same high PER we get variations of more than 100% in the access delay?"

SuggestedRemedy:
Analyze the simulation parameters used to generate this curve and validate the simulation results with longer simulations.


Comment:
"By comparing legend between Fig. 24 and 20, it is clear that there is no a common style to assign the ""signs"" and ordering the scenarios.  To help the reader in doing comparisons, it would be nice to have a general rule to build-up the legends and follow it. "

SuggestedRemedy:
"Write the legend starting with Scenario 3 BT Slave (diamond), then Scenario 3 WLAN Mobile (square),  Scenario 4 BT Slave (triangle) and Scenario 4 WLAN Mobile (x).  Apply similar rule for all figures of this section."


SuggestedRemedy:
"Use sub-index to write ""WPAN"" in TWPAN."


SuggestedRemedy:
"Include ""SME"" in the list of abbreviations."


Comment:
"It is said that if WLAN frame is too long for the WLAN subinterval, its transmission must be deferred  to the next WLAN subinterval. How can we be sure that the bext WLAN subinterval is long enough for the deferred WLAN frame? May it happen that the selected WLAN subinterval is never long enough? "

SuggestedRemedy:
Some specifications for the minimum and maximum duration of the WLAN subinterval could help here to prevent forever deferred transmissions.


Comment:
"In Description field of Tab. 23, there is a reference to section 14.1.4.6.  This section does not exist."


Comment:
"The variable ""N"" is used many times without saying what it is."

SuggestedRemedy:
Indicate that the filter has (2N+1) taps.


Comment:
"There is an useless additional ""t"" in the sentence."


Comment:
The performance gain of the adjustable transversal filtering is shown in Fig. 42 for IEEE 802.11 1 Mbit/s system. Is it possible to show the benefits of this technique (if any) for 11 Mbit/s systems.

SuggestedRemedy:
Include figure with performance gain for 11 Mbit/s system.


Comment:
"Figs. 43, 45 and 46 are a very low quality objects. It is very hard to appreciate any results from these figures.  "

SuggestedRemedy:
"Improve the quality of Figs. 43, 45 and 46 to get at least the same quality of figures from previous sections."


Comment:
The first part of this clause repeats the scenario from Fig. 17. It is needed?

SuggestedRemedy:
Refers to Fig. 17 and minimize repetitions.


Comment:
"Sentence referring to Fig. 48 says packet error arte is 24 % for DM5 and DM3, and 19% for an DM1 packets. But looking to Fig. 48, actual values are 20% and 15 %."


Comment:
"It is said that the channel classification implementation is up to the coexistence mechanism solution vendor. In this case, how can we guarantee interoperability between master and slaves devices from different vendors if every implementation has its own definition of ""good"" and ""bad"" channels."

SuggestedRemedy:
A minimal set of mandatory rules for channel classification should be included to ensure multi-vendor interoperability.


Comment:
"There is no indication on how often the channel classification should be done. Before to reduce the classification time, an indication on the update frequency is required."

SuggestedRemedy:
Indicate when a channel classification must be done and how often it should be updated.


Comment:
"There is an useless "","" after ""event""."


Comment:
"On interference collision ratio formula, a ""B"" variable used.  A definition of ""B"" is required."


Comment:
"Many variables are used without indicating their meanings, namely:NG, Nmin and p(k)."


Comment:
It is said that some bad channels should be kept in the hopping sequence.why should the device do it?

SuggestedRemedy:
Explain the reasons to keep bad channels in the hop sequence.


SuggestedRemedy:
"Apparently, you should replace ""xxx"" by 53. Please check it."


Comment:
The impact of the proposed AWMA procedure on QoS performance of each involved technology is not covered yet in detail. What is the impact of QoS on TWPAN & TWLAN? How to consider/schedule the priority of services which are offered by  different technologies?

SuggestedRemedy:
Joint investigations/considerations of 802.15.2 and .11e are recommended.


SuggestedRemedy:
Change to ""…. IEEE 802.11b WLAN and ….""


Comment:
inexact statement: ""… can support up to three channels in the IMS band.""

SuggestedRemedy:
e.g. change to ""… can support up to three non-overlapping channels in the 2.4 GHz IMS band.""


Comment:
typo: ""signal power at recevier"" and ""interference power at recevier""


Comment:
missing space character: ""Recommendation:Thus AWMA ...""

SuggestedRemedy:
Change to ""Recommendation: Thus AWMA ...""


Comment:
space character is missing: ""Recommendation:Thus PTA ...""

SuggestedRemedy:
Change to ""Recommendation: Thus PTA...""


Comment:
A reference to clause 10.2.4 would be useful to indicate that legacy STAs are covered as well.

SuggestedRemedy:
A reference to clause 10.2.4 would be useful to indicate that legacy STAs are covered as well.


Comment:
The order 11 in the .11 beacon frame body is already used by 802.11 and refers to the Country information.


Comment:
In line 14, I believe that "effect" should be "affect".


Comment:
The two models should be defined such that their results can be used to
collaborate each other.

SuggestedRemedy:
Use the same definitions for the signal-to-interference ratio in the two
models.


SuggestedRemedy:
Need to have BER at least 10^-3 or lower.


SuggestedRemedy:
Modify second equation to Path Loss = 58.29 + 33log10(d/8)


Comment:
Place a period after the end of an equation if it is the end of the sentence.


Comment:
This technique has only been shown to work for 1 Mbps and not sure how well it will work for higher rates. In addition, the cost of adding an 802.15.1 receiver may be prohibitive in an 802.11b receiver.


Comment:
802.15.1 hopping sequence is not implemented as defined in Bluetooth standard. Frequencies were chosen randomly. This does not correct modeled the correlations between hopping frequencies.


Comment:
Fix formating. Top equation is off the page.


Comment:
Both equations on the second row should be the same.

SuggestedRemedy:
Modify the second row, second column equation as follows:WG(n+1) = P NG - nWG(1)


SuggestedRemedy:
Modify the second row, second column equation as follows:WB(n+1) = P NBk - nWB(1)


Comment:
Partition sequence parameters do not match the algorithm described in 12.2.1.


Comment:
One of the 1Mbit/s curves of either 802.11b or 802.15.1 is missing

SuggestedRemedy:
Indicate which of the 802.11b or 802.15.1 the existing
curve respresents


Comment:
None and Receive seems to have been switches in the last two
columns of the last row.


Comment:
Prefer WLANinterval to be listed in place of WPANinterval as this
might be used/useful for other synchronizations such as quite periodes for
measurements or antenna sharing/coexistence with GSM, EDGE, WCDMA mobile
phones or GPS devices.

SuggestedRemedy:
Use WLANinterval in place of WPANinterval in the syntax of
the control signals.


SuggestedRemedy:
Line 48 - change to As suchLine 51 - another, in order


SuggestedRemedy:
Therefore the Medium is free of WLAN traffic when the Medium Free signal is True.


Comment:
'agAWMAgrp' may be wrong (just my feeling)


Comment:
Change 'An optional ....addressed its.....' to

SuggestedRemedy:
'As an optional ......addressed to its ......'


Comment:
From Figure 37 since .15.1 is not transmitting it must be receiving  so should the table entry (and the decision block in Figure 37) read

SuggestedRemedy:
802.15.1. Rx activity have greater [i.e., add the Rx; I am not sure of this one]


Comment:
'Methods of adaptive packet selection' is not needed


Comment:
Line 49 - maintained. In this case, randomLine 51 - 'that uses more error protection will increase the performance of the SCO link.'

SuggestedRemedy:
Line 49 - should read 'maintained, random bit..'Linr 51 - should read 'that uses more error protection the performance of the SCO link will be increased.'


Comment:
Line 3 - 'case, by increasing'Line 8 - 'to around 1..'

SuggestedRemedy:
Line 3 - should read 'case, increasing'Line 3 - should read 'to less than 1...'


SuggestedRemedy:
add - 'LMP = Link Manager Protocol' to figure


Comment:
'LMP format' and 'AFH clause' not referenced

SuggestedRemedy:
add reference clauses for 'LMP format' and 'AFH clause'


Comment:
I am not familiar with this algorithm and could use a little informative text. This seems more complicated than necessary; I am sure it is me but don't we need to simply find the good (non interfered with) channels and use them to set up a sequence?Also, on page 76, lines5,7,10 what is K

SuggestedRemedy:
Explain the overall goal of the algorithm. For example, why keep track of any of the bad channels (see line 31, page 75)Define K


Comment:
Figure xxx needs definingTable 29 formulas run into boarder

SuggestedRemedy:
xxx -> 53(?)move formulas down or enlarge table


SuggestedRemedy:
Define the LMP commands and enter the op codes in Tables 34, 35, 37, 38


Comment:
AWMA in Clause 10.2 modifies the 802.11 MAC to have time sharing with
802.15.1. This is not allowable for a recommended practice. In addition,
the operations to handle the legacy 802.11 stations as described in
Clause 10.2.4 are not compliant with 802.11-1999 as well.

SuggestedRemedy:
Remove those mechanisms and operations which are not compliant with
802.11-1999.


Comment:
Figure 38: This diagram makes no distinction between present collisions versus future collisions the way that Figure 37 does. 

        What should happen when the 802.15.1 logic makes a Tx Request but the 802.11 is already transmitting?


Comment:
AWMA has dramatic impact on the proposed 802.11e. 
        Since 802.11e may be approved prior to the approval of this recommended practice, the impact on QoS operation should be addressed.

SuggestedRemedy:
It appears that AWMA is incompatible with QoS operation. If so, that should be explicitly stated, similar to the statement that AWMA is incompatible with SCO links..


Comment:
DBPSK & DQPSK use "differentiated", but the text in the document body use "differential".


Comment:
Several, but not all, instances of "effect" should be "affect"

SuggestedRemedy:
Change appropriate instances to "affect".


Comment:
"79(23)" should be expanded to something more meaningful.


Comment:
The graph of the power spectrum of the Barker code is misleading. 
The formula should be a series of impulses with amplitudes following the sinc2() function, except for k = 0.

SuggestedRemedy:
Either remove the sinc2 envelope imposed over the series of impulses 
or else change its line type to a light gray halftone to distinguish it from the power spectrum function itself.


Comment:
The PTA algorithm should be the recommended practice whenever SCO links
need to be supported; this should be added to this section (10.1).

SuggestedRemedy:
Add text to recommend PTA for SCO link support.


Comment:
While there is an extensive treatment of the calculation of bit error rate from SINR, the performance results shown in clause 9 show packet error rate. There is a dubious statement that 'the packet error rate for the WLAN corresponds to the loss of ACK messages'. In reality the packet error rate will be dominated by the loss of data packets, since they tend to be longer than ACK packets and hence more vulnerable to bit errors. This would yield more pessimistic results then those shown. On the other hand there is no discussion of the correlation of the bit errors. If there is structure in the interference (and in this case there is) then bit errors tend to be correlated. This would yield a packet error rate which is less than that for i.i.d. distributed bit errors, i.e. it would make the results more favorable. A third effect which aggravates the packet error rate is the effect of interference on packet detection, which is not modeled and which tends to dominate the probability of packet loss by decoding errors, especially at low SINRs.


Comment:
Words of abbreviation do not match use in document

SuggestedRemedy:
Change to signal to interference plus noise ratio


Comment:
802.11b has many more channels than 3, so the statement is perhaps incorrect.

SuggestedRemedy:
Please change the wording to ""can support 3 non-overlapping channels in the ISM band.""


Comment:
The order of the collaborative and non-collaborative discussion in the overview does not match the order of the material in the main sections.

SuggestedRemedy:
Please reverse the order of 4.3.1 and 4.3.2.


Comment:
BER_f is to be measured for each frequency.  Commonly, the receivers cannot measure BER, just PER.  Perhaps this is a misprint.


Comment:
Ensure that the document addresses 802.11g (OFDM)
interference, together with 802.11b

SuggestedRemedy:
Include results of the analysis and simulation.


Comment:
"Overall the draft is a good effort to analyze the interference problem in 2.4 GHz indicating possible solutions. However, it presents some areas to be enhanced in terms of quality of presentation and completeness of the contents."

SuggestedRemedy:
Further work is required to complete the quantification of the interference problems.  More detailed specification can be included in described coexistence mechanisms.


Comment:
It is said that the scope of the document is limited to DCF implementations of IEEE 802.11. Has it been considered seriously the alternative to mandate PCF in next WLAN generations? Having a single node as IEEE 802.15.1 master and IEEE 802.11 Point coordinator would help a lot to reduce interference problems between both systems.

SuggestedRemedy:
Analyze the impact of mandating PCF for IEEE 802.11 implementations in terms of system performance and interoperability.


Comment:
"Paragraph ""The IEEE 802.11 MAC ... may not be tolerable"" is repeated at the end of clause 4.1.2. "

SuggestedRemedy:
Remove the repetition of the paragraph and place it at the end of clause 4.1.


Comment:
Non-collaborative proposals are described only for IEEE 802.15.1. Why were non-collaborative proposals for IEEE 802.11 excluded from the recommendations?

SuggestedRemedy:
"There are many valid non-collaborative proposals for IEEE 802.11 based on equalization, antenna diversity and similar which can be included in the draft. Some evaluation of these alternatives should be made."


Comment:
It is said that results provided by the two models are not directly compared because of different definitions of signal-to-interference ratio.

SuggestedRemedy:
"To understand the consequences/effects of certain system configurations, it would be helpful to have a unique, coherent and unambiguous definition of signal-to-interference ratio. The suggestion is to standardize this definition."


Comment:
"Caption of Figure 4 refers to 802.11b and 802.15.1 modulation types, however the curve for 802.15.1 is missing."

SuggestedRemedy:
Please include the curve of 802.15.1 in Figure 4.


Comment:
Simulation results are shown without indicating the parameters used for the computer simulations.

SuggestedRemedy:
Indicate length of simulations as well as 802.15.1 and 802.11 parameter values.


Comment:
"Some uniformity in the figure style is required.  Fig. 11 presents no grid in contrast with all others.  Fig. 12 shows ""EbNo"" x-label while the other figures use ""SIR"" x-label.  Fig. 13 uses x-values with inclination, while the other figures present normal horizontal text.  Fonts in all figure labels need to be standardized."

SuggestedRemedy:
"Include grid in Fig. 11. Replace ""EbNo"" by ""SIR"" in Fig 12. Use normal horizontal x-value sin Fig. 13. Select one font for labels and keep it."


Comment:
The order 11 in the .11 probe response frame is already used by 802.11 and refers to the FH parameter information.


Comment:
missing space character: "" … transmit activity.The decision …""

SuggestedRemedy:
Add space character "" … transmit activity. The decision …""


Comment:
: ""… 802.15.1 activity havegreater priority …""

SuggestedRemedy:
Insert a space character and question mark: ""… 802.15.1 activity have greater priority than the requested 802.11b packet?""


Comment:
row5, column2: Question mark is missing.


Comment:
missing space characters: ""… 1.6ms to 2.6ms …""


Comment:
reference is missing: ""Figure xxx shows …""


Comment:
reference is missing: ""IEEE Std XXX-2002""


Comment:
typo: "" … discusses the physcial layer …""

SuggestedRemedy:
Change to "" … discusses the physical layer …""


Comment:
typo: "" … Wireless Personnal Communications …""

SuggestedRemedy:
Change to "" … Wireless Personal Communications …""


Comment:
Although the AWMA mechanism is interesting, I'm not sure whether it is valid for a Recommended Practice document as it requires modification to existing standards.  If the 802.11 standard is modified to add the Element in the Beacon and Probe Response, then it ceases to be a recommended practice, and probably becomes a "shall" if the WPAN option is implemented..…

SuggestedRemedy:
Remove this option from the document  or find an alternative method to achieve the bandwidth sharing without requiring changes to 802.11 standard.  

For example an AWMA-like mechanism can be obtained by using the upcoming 802.11e TxOPs.  An 802.11 device can request additional TxOPs from the AP, to cover the bandwidth required by the co-resident 802.15 device.  In this way the 802.11 standard does not need to be modified (nor the 802.11e draft) and the Master can gate it's operation based on granted TxOPs to achieve coexistence and possibly even supporting SCOs.


Comment:
This Document gives details on 802.11B interference while current
standardization in 2.4 GHz Band is 
covered in 802.11G Annex.  The new modulation methods mentioned in 11G needs
to be taken into consideration in 
the analysis on mutual interference and in proposed solutions.

SuggestedRemedy:
Analysis and simulation material addressing 802.15 and 802.11G coexistance
needs to be 
included.


Comment:
Control of legacy systems will not work when a legacy device is not in power
save mode and wakes up to transmit a
packet.

SuggestedRemedy:
Mention this shortcoming in the document.
included.


Comment:
This document addresses only 802.11b, but 802.11g is being standardized for
the 2.4 GHz ISM band and will be more susceptible to 802.15 interference at
the higher speeds. Most new developments for the 2.4 GHz band will focus on
802.11g, and thus any coexistence development must be applicable to 802.11g.

SuggestedRemedy:
Include 802.11g in the analysis and in the proposed coexistence approaches.


Comment:
Would like to see priority to all network control and management
functions, for example Beacons, Slave ACL, ID, FHS emphasized. Highest
priority to be given to Master and AP. Then Slave and STA. After that:
Synchronious communications such as SCO. Finally other data.


Comment:
Nulling filters can be used in WLAN systems to remove the WPAN interference given that the interferer does not hop during the WLAN packet. If the interferer hops, either into or out of, the WLAN bandwidth during the packet, the nulling filter transients must be carefully considered. A better approach would be to use a joint detection algorithm that does not require nulling filters.

SuggestedRemedy:
Remove spectral nulling as a recomended practice.


Comment:
These clauses belong in an informative annex to the Recommended Practice, as there is nothing within them to 'practice.'

SuggestedRemedy:
Move clauses 6-9 to a first informative Annex and renumber the document.


Comment:
Simulation results for 1,2,5.5 and 11Mbps are necessary to form a recommendation to be practiced. The 1Mbps case is insufficient in practice.

SuggestedRemedy:
add simulation results for 2, 5.5 and 11Mbps 802.11b


Comment:
All of 10.4 is independent of 10.1-10.3, and should be presented as a separate clause.

SuggestedRemedy:
Move clause 10.4 to be the clause that follows the collaborative scheduling clause, and create a figure like Figure 30, but including both Figures 39 and 40 as blocks within.


Comment:
In 802.11b, RSSI is defined to be valid: 15.4.5.10.3 When generated
This primitive shall be generated by the PMD when the DSSS PHY is in the receive state. It shall be continuously available to the PLCP, which, in turn, provides the parameter to the MAC entity.
but it represents the energy at the moment in time when a valid 802.11b header checksum is received, not just anytime. You have to use the Energy Detect apparatus: 15.4.5.13 PMD_ED.indicate
15.4.5.13.1 Function
This optional primitive, which is generated by the PMD, shall indicate to the PLCP layer that the receiver has detected RF energy indicated by the PMD_RSSI primitive that is above a predefined threshold.to measure as described in page 71 of the draft.

SuggestedRemedy:
Rewrite 12.1.1.1 to use RSSI as specified in 802.11b 15.4.5.10


Comment:
RxQuality is a much better indicator of 802.11b channel reception than packet error rate(PER), and is available in all commercial 802.11b chipsets. It should be used instead of PER for this function.

SuggestedRemedy:
Rewrite 12.1.1.2 to use RxQuality instead of or in addition to PER.


Comment:
There is a missing analysis in this section.  The campus-wide
ubiquitous coverage deployment of 802.11b (at least b, if not 802.11 1Mbps
DSSS and 802.11 2Mbps DSSS) is not addressed and needs to be.  Ubiqitous
coverage campuses in enterprises like Boeing and Microsoft are becoming
commonplace.  This continuous non-collaborative environment includes the
need to use 802.11b channelization for alternating cells.  Take the instance
of several ubiquitous-coverage 802.11b Boeing campuses - overlapping cells
are the norm and full channelization is in effect in those campuses that
have ubiquitous coverage.  The analysis of this environment with bleeding
between cells needs to be in the document or its value is diminished.  What
is the recommended practice for the campus ubiquitous coverage environment.

In addition, consider the conference room.  In that conference room with
perhaps 30 people, with a mix of Bluetooth and 802.11b, what studies have
been done to show and model the effects of the dense use of 2.4GHz radios.
What is the recommended practice for the conference room model?  Also
consider the effects of being on an airplane and half of the airplane's
passengers use mobile computing devices with half of those using Bluetooth
and half using 802.11b.

SuggestedRemedy:
Charts and text to reflect the ubiquitous coverage and the
density issues in the interference in the non-collaborative environment.


Comment:
AWMA is recommended for high density WLAN/WPAN area. As such there will be 3 non-overlapping WLANs in the same area. For AWMA to be effective, all the WLANs need to share the same time sharing parameters and have the same clock timing. A method needs to be developed that allows all the WLANs to coordinate timing.


SuggestedRemedy:
change to ..... three non overlapping channels ....


SuggestedRemedy:
Add BER=0 in Upper Limit column heading, and add BER>/= 0.5 in Lower Limit column heading.


Comment:
The Eb/N0 is incorrect for a BER of 10-3.

SuggestedRemedy:
Line 32 should read ..... sub-optimal system provides a BER of 10-3 for an Eb/N0 of 7 dB ......


CommenterFax:
610-704-2349 (may change before Sydney if new cellphone
arrives in time)

Comment:
While this document does reasonable job of characterizing interference
potential between 802.11 FH and 802.11b WLANs and 802.15.1 (Bluetooth) WPANs
and proposing some methods of improving coexistence, I think it falls short
of what is currently needed in the following respects:
First, it will be obsolete in short order because it does not address the
proposed 802.11g extension at all.
Second, neither does it address 802.15.3 WPANs.
Third, neither does it address 802.15.4 WPANs.
Finally, while it offers a definition of "coexistence," that definition is
very "fuzzy" and essentially ignores the pressing need to quantify just what
constitutes acceptable coexistence between systems and what does not.
What is needed is a "figure of merit" or "measure of goodness" that defines
both
how much a system is affected by other systems and how much it affects them,
and that should apply to ALL 802 wireless standards that operate in a given
band, not just a subset.

SuggestedRemedy:
Provide a quantifiable definition of "coexistence" and methods of evaluation
of the interactions between ALL 802 wireless standards that share a common
frequency band, allowing those combinations of systems to be evaluated in a
sensible, measurable manner and defining what is "good enough" to constitute
acceptable coexistence and what is not.
Include analysis and simulation models of 802.11g, 802.15.3, 802.15.4 so
that the COMPLETE coexistence picture of current and "in development" 802
standards
in the 2.4 GHz band can be evaluated.
Propose (or, in the case of "in development" standards, insist that the
developing
workgroups propose and provide) coexistence mechanisms for ALL combinations
of systems,
with the onus on the "newcomer" to propose and provide coexistence
mechanisms that
can be shown to provide reasonable protection to incumbent systems,
accoarding to
the aforementioned definition of "what is good enough" to constitute
acceptable
coexistence.


Comment:
The transmit and receive masks (Clause 5.3.5) should appear beforeSpectrum factor (Clause 5.3.3) because the spectrum factor is calculated using Table 6 given in Clause 5.3.5.


Comment:
It should read ""In the case of a 802.11b 1 Mbit/s chip ...""


Comment:
Do you need this Clause? Although Spectrum factor is shown in Figure 3,it doesn't seem to be used anywhere else.

SuggestedRemedy:
This Clause needs some clarification. Add another Figure or Table showing the BER with different frequency offsets (spectrum factors) with a fixed value of transmit power and/or path loss.


Comment:
The definition of GFSK signal can be found in most textbooks.It is not necessary to have it here.


Comment:
5.5 Mbit/s CCK has already been specified in the IEEE standards so the reference to Halford[B13] can be removed.


Comment:
Typo: c7 should be -e^(j phi1+phi2).(c = [c1 c2 ... c8])


Comment:
There should be a comparison for 5.5 Mbps 802.11b as well because the sub-optimal receiver is used instead of the optimal one.Comparison with QPSK is not necessary.


Comment:
To better compare performance degradation of 802.11b (11 and 5.5 Mbps) due to Bluetooth interference, there should be a comparison using the same receiver architecture (ie, optimal receiver - correlator). It is hard to do the comparison with different sub-optimal receivers.

SuggestedRemedy:
Add results on optimal receiver performance.


Comment:
The simulation tool OPNET is mentioned several times throughout the
draft. I am just wondering whether it is appropriate and conforms to the
IEEE rules to refer to a commercial tool within this document.

SuggestedRemedy:
Replace all occurences of OPNET with an appropriate description of the
functionalities that have been used.


Comment:
The Editor's note says 2 Mbit/s is not included, yet there are simulatiosn for this rate and the document seems to apply to 2 Mbit/s.


Comment:
The text lists three models (RF, MAC, PHY) and says 'developed in OPNET and ANSI C, respectively"".  I can't parse this sentence.

SuggestedRemedy:
Delete 'respectively'.  It doesn't apply and, anyway, there is clarification in the next paragraph.


Comment:
The structure and language confuse me.  Why has it been decided that there are three coexistence mechanisms?  Surely we have two in Non-collaborative (AFH and APSS) and two (SCO over ACL priority and TDMA) in Collaborative.  How is it that we describe these as 3?

SuggestedRemedy:
Change the language and structure to acknowledge 4 mechansims.


Comment:
The long dash at the end of every figure or table reference is non-standard, annoying and seems to serve no useful purpose.

SuggestedRemedy:
Appropriately remove all dashes in references


Comment:
Should there be an entry in the bottom right of the table?? or does the same value apply to both column 3 and other?


Comment:
Comment: Ignoring the PCF completely in the analysis of 802.11(b)  traffic patterns brings many of the conclusions into question.  The PCF traffic patterns are considerably different than the ones discussed in subsequent sections, and while point-coordinated networks are relatively uncommon today, the HCF in the MAC extensions for QoS being developed in TGe will have many characteristics in common with PCF traffic, including multi-MPDU bursts separated by SIFS intervals.

SuggestedRemedy:
Update the simulation-based analyses of 802.11(b) traffic to also include error analyses with PCF traffic.  I believe the OPNET 802.11 model now includes a point coordinator.  If not, you should be able to get a copy of the one developed by the TGe simulation subgroup from Matthew Sherman of AT&T and/or Sunghyun Choi of Phillips, both of whom worked on developing that model and have presented results of simulations performed using that model in submissions to TGe.


Comment:
The statements that ARQ "insures" reliable delivery is an overstatement, even in the absense of interference from 802.15.1 transmissions.  What the ARQ in the 802.11 MAC does is to attempt to make the incidence of packet loss sufficiently low that the higher layer protocols can treat 802.11 as a LAN rather than as some other sort of intermediate-s
the assertions that there is "little chance of data loss" is highly questionable, especially at lower 802.11 data rates such as 1 or 2Mb/s because the probablility of 802.15.1 hops within the 22MHz occupied bandwidth of 802.11 during each frame transmission attempt.

SuggestedRemedy:
Modify these statements to indicate that ARQ improves reliability, not insures reliability, and remove the statement about little chance of data loss, replacing it with a quantative statement of simulated chance thereof if desired.


Comment:
Neither the short preamble option of 802.11b (which ought to improve the mutual interference situation when used) nor the PBCC modulation option of 802.11b are mentioned or analyzed.

SuggestedRemedy:
Update the simulation-based analyses of 802.11b to take account of short preamble vs. long preamble and to consider whether the susceptibility/interference source characteristics of PBCC modulation are the same as CCK or not.  If not include analysis of PBCC as well in the appropriate sections.


Comment:
Element ID 8 is already used by the hopping pattern parameters element in 802.11D-2001.

SuggestedRemedy:
Use a non-allocated element ID, taking into account those presently assigned for provisional use in the TGe, TGh, and TGi drafts.


