# Main

Comment:
The standard aims to comply with 15.247. This regulatory document requires a 6dB bandwidth of 500 KHz, but the specified 915 MHz PHY has a 6dB bandwidth of only 360 KHz.

SuggestedRemedy:
It is desirable to comply with 15.247 because it allows for higher transmission power than 15.249. Consequently, any remedy should involve changing the 915 PHY specified by the standard rather than deleting the requirement for compliance with 15.247. The most obvious solution is to increase the chip sequence length from 15 to 31, although this may affect the preamble length.  All possible remedies shall result in the 868 and 915 PHYs diverging. This is a natural consequence of the the fact that a minimum 6dB bandwith of 500 KHz for the 915 PHY is incompatible with an entire channel width of just 600 KHz for the 868 band.


Comment:
The pulse shape specification seems to be incorrect because it shall produce an irregular waveform.

SuggestedRemedy:
Verify the pulse shaping and fix the standard if necessary.


Comment:
The specified turnaround times seem to be unnecessarily tight for 868/915 PHYs, given that they employ a bit rate of only 20 Kbps, and this corresponds to a bit-time of 50 uS. The RX-to-TX time virtually eliminates the possibility of software playing a significant role. Consequently, this specification forces more of the MAC layer to be integrated into hardware thereby adding to cost and complexity.  More importantly, both turnaround times are very stringent in terms of PLL settling time. With the lower data rate and lower carrier frequency used in the 868/915 bands, the PLL settling time shall be considerably longer than for the 2.4 GHz band because greater accuracy is required.

SuggestedRemedy:
Specify different turnaround times for the 868/915 bands, with the times being in the region of 500 uS to 1 mS.


Comment:
The 868.0 - 868.6 MHz band is wrongly specified as 868 - 868.8 MHz.


Comment:
The bit counts in Figure 12 do not seem to add up.


Comment:
Please add Jacco van Muiswinkel to this list.


Comment:
Atleast as for as the MAC portions are concerned, this document is at best a requirements document. This does not describe the mechanisms required for claimed features in the draft. Some examples are association, disassociation, GTS-request/allocate/deallocate, NC/DD nomination, change of NC/DD within LR_WPAN, cluster formation/tearing-down and power management. All these are assumed to be "somehow" done by higher layers and communicated through MAC-SAP. There is no "higher layer" protocol mentioned that provides for the TG4 requirements from that higher layer.Only very basic functions are defined and they are, (a) beaconing (b) data frame tx and (c) ack. These functions alone does not constitute a MAC that claims all the good list of features claimed in clause 5.

SuggestedRemedy:
Define ALL the mechanisms required for the functioning of MAC. Define all the packet formats and message sequence charts.


Comment:
The list of features claimed in various parts of this draft and the requirements are very similar to those listed for 802.15.3. While 802.15.3 (LB12) has attempted to define the specific mechanisms required to achieve those goals and interoperability among the 802.15.3 devices, this draft does not any of them. Even if TG4 defines those mechanisms to complete the draft, the PAN industry will have to implement two MACs that have the similar set of features. Both being 802.15 standards, can't this be avoided and reuse the MAC to help the quick, global acceptance of the standard?If there is any argument that 802.15.3 MAC is complex here is my straightforward counter argument: There is absolutely no way any vendor can implement the requirements listed in this draft in a low cost fashion since the higher layer, whichever it is, performing those functions will cost atleast the same, if not more, compared to when they are done inside the MAC. BTW, don't forget that when specified to be done inside a MAC (and with all details described) all implementations are going to be uniform in nature making them interoperable.

SuggestedRemedy:
Reuse the work done in 802.15.3 MAC, albeit if some features have to be removed for LR-WPAN devices. This avoids PAN industry to implementing two different MACs with similar set of features and incur the cost that could slow down and even hinder mass acceptance of these standards.


Comment:
Interoperability: If this draft becomes a standard as it is, given that all the mechanisms are defined in an higher layer that is not even referenced in this draft, how is the interoperability among the LR-WPAN devices is thought to happen if the implementors chose their own mechanisms for these features? I am seriously concerned and appalled that a draft that is this incomplete even made it to the letter ballot stage.

SuggestedRemedy:
Define ALL the mechanisms required for ALL the claimed features and/or operational scenarios (used in clause 5). Better yet, reuse the work already done in 802.15.3 MAC.


Comment:
essentially this sentance claims the DEVs can obtain short addresses for operation in LR-WPAN. Nowhere in the draft the procedure required for this is defined, no frame exchange sequences defined? No such thing as association frame exists in the draft.

SuggestedRemedy:
Define the mechanism required for association. Include association response in which the NC provides the short address that the DEV can use during data transfer. Define all the required packet formats and message sequence charts.


Comment:
The first sentence in second complete para in 5.2 claim that DEVs can talk to each other without NC. How do they detect each other? How is the timing sync achieved for slotted-CSMA/CA that is claimed to have been used in this draft.

SuggestedRemedy:
Dedicate a sub-clause in under 7.5 and describe how DEVs detect each other, exchange data nd maintain timing sync in the absence of NC.


Comment:
Sentence here claims that a network ID is chosen that is not currently in use by any other network within the radio range. How? What mechanism is used to achieve this? nowhere in this draft, the frame formats used to acheive this are defined or described?

SuggestedRemedy:
Define the network ID selection procedure


Comment:
How is the network identifier obtained at a DEV? No where in this draft the mechanism needed for such a distribution nor the frame formats defined. Can a device change from one ID to another. if so, how? if not, why?

SuggestedRemedy:
Define the network ID distribution procedure for new (just bought from store) devicesDefine the network ID distribution procedure for a device that wants to join a LR-WPAN.Define all the required packet formats and message sequence charts.


Comment:
This sentence claims that task of joining a network occurs above the MAC layer. What does this mean in terms of frame format used and uniformity of the process? How much time can an NC take to allow the association of a DEV to its network? What happens if NC never responds? Which higher layer does the job of assocaition as required by this standard? where is it published? What is the complexity of implementing that higher layer protocol in this "low cost" device as opposed to implementing the requried mechanisms in the MAC?

SuggestedRemedy:
Describe the association procedure and clearly Define all the required packet formats and message sequence charts.


Comment:
The use of word "although" implies that peer-peer network can operate with or without NC. But there is no description of such an operation and the involved mechanisms anywhere in this draft.

SuggestedRemedy:
Define clearly the assoc. deassoc and data exchange processes required. Define all the required packet formats and message sequence charts in clause 7.


Comment:
This sentence claims that NC can be nominated. What if there are multiple DEVs with same network ID waking at the same time and starting scanning? If they eventually endup in the same channel, how do they nominate ONLY ONE of them as the current NC? If this is also assumed to be in the higher layers, which higher layer protocol caters to this requirement? Where is it published? What is the complexity of implementing that higher layer protocol in this "low cost" device as opposed to implementing the requried mechanisms in the MAC?

SuggestedRemedy:
Define clearly the NC nomination processes required.Define all the required packet formats and message sequence charts in clause 7.


Comment:
This sentence claims that NC can be nominated. What if there are multiple DEVs with same network ID waking at the same time, starting scanning ?and endup in different channels? Would there be two networks operating with the same network ID but in different channels?

SuggestedRemedy:
Define clearly the NC nomination processes required with the frame formats and frame exchange sequences in clause 7. take into account that multiple DEVs trying to establish their own networks with the same network ID within the same channel and in different channels.


Comment:
This sentence uses such things as "designated parent" and "child" nodes without first defining them.


Comment:
SPECIALLY ADDED COMMENT:

It has come to my attention that what TG4 calls a "packet" 802.11 calls a
frame.  This will be misleading to people who have read the 802.11 standard
and are now reading the 802.15.4 standard.  Addtitionally, what TG4 calls
frames are referred to as "super-frames" by 802.15.3.

SuggestedRemedy:
Change recomended: change packet to frame.  Change frame to super-frame.


Comment:
If in a cluster tree topology, the devices may  only communicate with theire designated parent and child nodes, how is the data forwarding done? How does a designated parent knows which other designated parent a given data frame must be forwarded so as to reach (or get further forwarded) the desired dest-DEV?

SuggestedRemedy:
Define unambiguously the mechanisms needed for data forwarding in multi-cluster-tree environment. Define all the required packet formats and message sequence charts.


Comment:
Can DDs using different network IDs form parts of the same cluster tree?

SuggestedRemedy:
Define unambiguously the mechanisms needed for data forwarding in multi-cluster-tree environment that uses different network ID. Define all the required packet formats and message sequence charts.


Comment:
This entire paragraph describes the DD nomination and cluster formation from a user/requirement point of view. But no where in the draft the MAC mechansims, frame formats and frame exchange sequences that are required to achive this are defined? If this is also in an higher layer, which higher layer is going to perform these duties as per the requirements specified by 802.15.4? where is it published? What is the complexity of implementing that higher layer protocol in this "low cost" device as opposed to implementing the requried mechanisms in the MAC?

SuggestedRemedy:
Define unambiguously the mechanisms needed for DD nomination and cluster-tree formation. Define all the required packet formats and message sequence charts.


Comment:
This picture states that each cluster of the same tree being in different channels? Is that a requirement?

SuggestedRemedy:
Clearly state the requirement of clusters of the same tree being in the same channel


Comment:
This picture states that each cluster of the same tree being in different channels? if so, how is the DD in one channel know that a DEV/DD from a nearby cluster, but another channel, sent a frame to it? How do they sync upto be in one channel to complete that transaction?


Comment:
Assuming that a mechanism for DDs to syncup to complete a data transaction is defined, how is that a particular path from a originating DEV to dest-DEV (that are in seperate clusters seperated by multiple clusters) is chosen? Are they supposed to be unique per pair of clusters? What is the mechanism used to achieve this?

SuggestedRemedy:
Cluster tree concept is a noble one, but it is extremely complex to implement in reality. Remove this from the draft.


Comment:
This entire draft is vague about "network ID". In 5.2.1.3 and frame format in Table-61 (pp 79) imply that data can be communicated over different network IDs without any inhbition. In otherwords only the source and dest addresses are important. Then what is the need for network ID?

SuggestedRemedy:
Clearly describe the use of network ID, both in intra-network and inter-network cases


Comment:
What happens when a DD wants to leave? How is the new one chosen and the information transferred to the new one? What happens if the current-DD went away before a new one is chosen? What happens the current-DD went away without even informing any other DEV/DD?


Comment:
What happens when a NC wants to leave? How is the new one chosen and the information transferred to the new one? What happens if the current-NC went away before a new one is chosen? What happens the current-NC went away without even informing any other DEV in the network? Clause 7 does not describe any of these.

SuggestedRemedy:
Define the nomination of new NC in the event the current one to disappear or express the intention of going away (in clause 7). Describe the mechanism required for transfer of all the info on the current network, like short address to IEEE address table, GTS allocations, requests pending, etc. Define all the required packet formats and message sequence charts for this to be done within the MAC.


Comment:
Stating that the required mechansisms are in an higher layer and it is out of scope for this draft, does not help in realizing an implementation that is uniform and interoperable with implementations by other vendors. This draft does not describe the mechanisms required for claimed features in the draft. Some examples are association, disassociation, GTS-request/allocate/deallocate, NC/DD nomination, change of NC/DD within LR_WPAN, cluster formation/tearing-down and power management. Defining MAC-SAPs for these is not at all sufficient. We need to clearly, unambiguously define and describe on the air frame transactions needed to achieve these noble goals. The very basic functions (beaconing, data frame tx and ack) does not constitute a MAC that claims all the good list of features claimed in clause 5.

SuggestedRemedy:
Define ALL the mechanisms required for the functioning of MAC. Define all the required packet formats and message sequence charts. Better yet, reuse the MAC work done in 802.15.3.


Comment:
The claim of "time slot maintenance" in the MAC is ambiguous. There are no mechanisms defined for GTS request, allocation and deallocation. 5.4.2 does some more mentioning of the expected behavior but no mechanisms or frame formats described. How do you expect the implementors to implement this feature in an uniform way if there is no spec on the mechanism? What is the need for a standard if implementors have to chose their own mechanism and frame formats for even basic features like channel-time-slot allocation?

SuggestedRemedy:
Define ALL the mechanisms required for the GTS management within MAC. Define all the required packet formats and message sequence charts.


Comment:
The claim of "Guaranteed packet delivery" in the MAC is ambiguous. There is no receovery mechanism if the max retry has reached. Isn't it?

SuggestedRemedy:
Modify this claim to "Packet retransmission"


Comment:
This claims list does not cover all that is claimed in clause 5. Where are others like power management, security, association/disassociation, NC nomination/de-nomination/re-nomination, DD nomination/de-nomination/re-nomination, data forwarding between clusters and within network, etc.Do not rely upon an "higher layer" to do the functions specified in this draft. There is no such protocol that is available, less complex to implement as opposed to be implementing inside the MAC and be uniform over all the implementations in products based on 802.15.4

SuggestedRemedy:
Define all the required mechanisms, Define all the required packet formats and message sequence charts for all the required functions to be done within the MAC.


Comment:
Use of "Handshake" instead of plain Ack. Why invent terms when implementors are already familiar with the same concept by a well-known name. Even the editor is not fully converted to the use of this term as shown in figure 15


Comment:
Use of "Segmentation" instead of plain Ack. Fragmentation is a better known term

SuggestedRemedy:
Change all use of "Segmentation" to "Fragmentation"and "reconstitution" to "Defragmentation"


Comment:
Use of abbreviations and different terms for the same field or concept is rampant in the draft. for example (a) use of FSB in 7.5.7.3. what does FSB stand for? (b) use of node, DEV, station

SuggestedRemedy:
Please edit the doc to make uniform usage of terms and abbreviations.


Comment:
Power management completely escapes the draft except the mention of its requirement in 5.4.1. For example there is absolutely nothing in the draft that describes how a DEV can go to sleep or inform others as how long it is going to be sleeping, how others (Atleast NC) buffer the data, how the sleeping DEV wakes up and requests for data.

SuggestedRemedy:
Define a power management scheme within MAC. Better yet, reuse the work done in either 802.11 or 802.15.3.Define all the required packet formats and message sequence charts.


SuggestedRemedy:
Define a security scheme within MAC. If security is not needed, justify it in clause 5.Define all the required packet formats and message sequence charts.


Comment:
Choose macBaseFrameDuration to be a power of 2. It eases the implementation of timers to be 'm' bit wide. Otherwise it depends on the 'macFrameOrder' that is chosen in the beacon of the network, hence the timer implementation should support arbitrary max value.

SuggestedRemedy:
Define TU to be 1024 microsec and choose macBaseFrameDuration to be 15TU instead of 0.015millisec


Comment:
If NCs chose the macFrameOrder, how is this made uniform in cluster-trees? how do DDs exchange this info across the clusters?


Comment:
How do DDs propagate info from NCs beacon, if one is present? Do they send pseudo beacons? or they just don't care.


Comment:
How do a DEV in a cluster-tree sync up for slotted CSMA/CA timings with other DEVs that are so far apart from itself but close enough to be heard by a DEV that can here the first DEV too?


Comment:
These lines are not clear enough. If beacon is needed for network connection purposes and if NC is currently not sending beacons because it somehow decided they are not needed, then how do newly associating devices know who NC is, what the network type for joining?

SuggestedRemedy:
Add mechanisms, Define all the required packet formats and message sequence charts required for joining a network that currently have no beacon-tx


Comment:
These lines are not clear enough. if beacons are absent doesn't the clock drift at DEVs make the slotted CSMA/CA timings to get misaligned at different DEVs? how do they sync-up the slot timings?

SuggestedRemedy:
Add mechanisms, Define all the required packet formats and message sequence charts required for synchronizing the slotted CSMA/CA sync procedure when there are no beacons.


Comment:
how does a node request data (after periodically listening) pending at the NC? (same is true for lines 22:26 on page 18). There is no description of this process anywhere in the draft

SuggestedRemedy:
Add mechanisms, Define all the required packet formats and message sequence charts required for devices to request the transmission of data frames pending for them at NC.


Comment:
how do devices sync up to slotted CSMA/CA timings without beacon? Who distributes the short addresses in the absence of NC?

SuggestedRemedy:
Add mechanisms, Define all the required packet formats and message sequence charts required for peer to peer communication.


Comment:
CAn a DEV have multiple network-ID? if so, how does it choose to pick one for current peer-peer communication?


Comment:
In peer-peer mode, how do devices discover each other?


Comment:
PHY-MAC layering is arbitrary? there are MAC types in PHY header!!

SuggestedRemedy:
Seperate out PHY components from those of MAC. Move SPD to MAC header.


Comment:
Thre is no CRC in PHY header. If length is wrong, how does the DEV know where the packet end is?

SuggestedRemedy:
Add a CRC for PHY header so that the frame can be thrown away if the PHY header is incorrect.


Comment:
Why seq-num in handshake pkt repeated. There is no description as how to process this packet format at the recipient. If there is an error in either of them, the packet must be thrown away? Why not just a CRC (like in DATA packet)? what if there is same error in both the seq-num? Since this packet must be rxd immly after the data packet (within the timeout), seq-num is implicit. isn't it? Why should MAC impelement different verification schemes depending on packet type? That is more complex than just performing CRC on ALL packets and deciding whether the packet is good/bad. I think trying to save one or two bytes in this frame has resulted in a confusing frame format that is of less use than an ack packet with dest-address.

SuggestedRemedy:
Change figure-13 to include Dest-addr (short address) and CRC.


Comment:
If applications above the MAC decide message verification scheme for themselves, how is this imagined to be implemented uniformly in all products? What this needs is another MAC above, not an higher layer protocol.

SuggestedRemedy:
Define proper verification scheme for ALL packet formats within MAC (currently Ack packet do not have any CRC in it. If new frames are added, add CRC to them also)


Comment:
This is the first place where a bit tx rule is mentioned. Why is this only for one field? Isn't this a common rule for all fields?

SuggestedRemedy:
Make the bit-sequence-tx rules as a common rule for all fields except the IEEE addresses and CRC. refer to clause 7.1.1 on page 93 of 802.15.3 draft D09 for standard 802 conventions (submitted for LB12). there is similar section in 802.11, for second reference.


Comment:
Is this field bit-0 or bit-7 of PHY-Header-octet? What is the use of this bit? nowhere in this doc, except for the mentioning of this bit in 6.4.1.3, is there a description of how to use this and the payload there after even if the devices are implemented to take advantage of this?

SuggestedRemedy:
Move this to bit-7 of PHY-Header-octet. Create a subclause in 6 and describe the process both at tx and rx DEV to use this bit and the payload thereof in that packet.


Comment:
If this has to be a low-cost implementation, there has to be one simple, reliable scheme for CCA. How can an high end system support five CCA schemes for interoperability sake and still be low cost. Just mandate the best one.

SuggestedRemedy:
Retain CCA mode 5 and remove the rest of CCA modes from the draft


Comment:
I haven't seen any supporting evidence that the 802.15.4 devices will take less than 1% duty cycle? How was this derived? Please add justification for that number. While it may be true that 802.15.4 devices have low power and hence may not seriously jeopardize the operation of products confiorming to other 802-wireless standards, how about the operation of 802.15.4 DEVs themselves in the presence of such other devices? The backoff scheme adopted by 802.15.4 does not take into account the medium busy conditions while decrementing the backoff counter. This makes room for 802.15.4 devices to sneak in during SIFS or DIFS durations of 802.11 (or SIFS and RIFS duration of 802.15.3) and unfairly gain the channel access.

SuggestedRemedy:
Adequately define the MAC mechanisms so as to absolutely assure that the coexistence is on fair basis.


Comment:
"Handles and maintains the GTS mechanism" is an overstatement for the description present in the draft

SuggestedRemedy:
Fully describe all the mechanisms, within the MAC, that are required for GTS request, alloc, dealloc, realloc


Comment:
msduLength: The term MSDU is used for the chunk of bytes rxd from higher layer which is fragmented into packets by the MAC (clause 3 and 4). If that is so, how come msduLength is mandated to be <= macMaxPacketSize? (Note that these terms are used in different parts of this clause with the same mistake)

SuggestedRemedy:
Define msduLength and macMaxPacketSize clearly. Connect them with max number of fragments allowed within an MSDU.


Comment:
Table 54/55: What is PCS? figures 11 and 12 used CRC in the same position.

SuggestedRemedy:
change crc to PCS and define PCS before its use in clause-5


Comment:
Table 55: show the relation between macMaxPacketSize and MAC payload in this table.

SuggestedRemedy:
Show the relation between macMaxPacketSize and MAC payload in this table.

Response:
ACCEPT. Changed "n is a nonnegative integer" to "0 <= n <= macMaxPacketSize".


Comment:
While this table is useful, it has to absolutely accompany text description of who uses which format. For example, a line "a non-NC DEV uses format in row-4 to send data packet. This frame contains only destination DEV's address. NC is supposed to receive for later forwarding this even though the packet does not have its address in it and send Ack packet to the sender"

SuggestedRemedy:
Add description of who uses these addressing possibilities and when. Pictures help.


Comment:
In star network, when a DEV rx packet a forwarded packet from NC, how does it know who the original sender was? Or is the data frame supposed to have all the IEEE addresses in some (802.3/Ethernet) format? If so, state it. if not, this limits the ability of a DEV to receive frames from atmost one another DEV in a network since it can not distinguish packets from two different sources that are forwarded through NC. Even with that restriction the dest-DEV somehow have to learn who the sender is or establish a connection with that DEV before that deV can send DATA.

SuggestedRemedy:
update frame format to include the original sender's address or state that 802.3/Ethernet addresses are present in the MAC payload


Comment:
Zone update requirement is mentioned, but not the mechanism needed to achieve it? similarly other componenets needed for power management like informing before going to sleep/snooze mode, coming out of it and requesting the pending data, and NC informing the zone index to the DEV are missing.

SuggestedRemedy:
Define power management scheme with all the required mechanisms, Define all the required packet formats and message sequence charts within the MAC.


Comment:
definition of macMaxPacketSize : 6.4.1.4 and 6.5 defines phyMaxPacketSize as the max length of PSDU. if so, it must be(macMaxPacketSize = phyMaxPacketSize - 26)NOT(macMaxPacketSize = phyMaxPacketSize + 26)

SuggestedRemedy:
changemacMaxPacketSize = phyMaxPacketSize + 26tomacMaxPacketSize = phyMaxPacketSize - 26


Comment:
units are missing from a lot of entries in the clause (example macBaseFrameDuration and macHandshakeWaitDuration)

Response:
ACCEPT. Units have been added to all entries.


Comment:
While clause-5 (especially the FRAME format in figure-5) claimed to have been using slotted CSMA/CA, there is no such mention of it in 7.5.1 or any consideration of that when timeouts and backoffs are defined.

SuggestedRemedy:
Update 7.5.1 and modify the mechanism, all timeouts and backoff values to suit slotted CSMA/CA scheme of channel access


Comment:
Since backoff scheme is already well understood in 802-wireless community, why not use the already familiar terms to define it?Why the use of macMaxCSMARetries? Is there a different retry-limit for GTS?

SuggestedRemedy:
Change "BE" to CW (contention window)Change macBEMin to macCwMinChange macBEMax to macCwMaxchange macMaxCSMARetries to macRetryLimit


Comment:
Why is backoff counter decrementing irrespective of channel conditions? Measuring CCA for a small time unit (phy-slot) and decrementing helps in multiple ways (a) easy to sync with slotted CSMA/CA timings (b) easy to establish a ground for interoperation with similar operating networks like dot11 or dot15.3 (c) most importantly the channel access is fair

SuggestedRemedy:
Change the back off counter to decrement only when the channel is idle and decrement in the units of phy-slots. define phy-slots dependent on the phy-type.


SuggestedRemedy:
change "If the maximum number of retries, Nr,...." to "If the number of retries, Nr, ..."


Comment:
if the backoff timer is arbitrary, how does the next transmission supposed to sync up with the slotted  CSMA/CA timings

SuggestedRemedy:
Change the back off counter to decrement only when the channel is idle and decrement in the units of phy-slots. define phy-slots dependent on the phy-type. and define CSMA/CA slot times to be interms of these phy-slots.


Comment:
These lines seem to provide a means to higher layers using which they can indicate tx-immediate or abort a packet. since this retry-limit is a PIB it is applicable for all packets. Is that what the committee intended this to be? Note that this is a totally useless feature since when channel is busy for the duration of a packet, MAC could check the channel several times in a row and discard several packets in the queue from higher layer. What is the justification for this?


Comment:
What does sending a data packet with broadcast network ID do to the snoozing NCs? It is not one of the stimulus listed in 7.5.2.2.1 anyway! Even if NC wakes upto this, what does it do if beacons are decided to be not sent? Is this data tx done on just one channel or all channels? since one tx of braodcast tx can get corrupted at an NC, how many times is it required to be sent? These questions must be able to convince that this draft is at best incomplete.

SuggestedRemedy:
Describe the wake up mechanism at NC with proper message sequence charts and timeouts defined in the PIB


Comment:
if NC is snoozing how do non-NC-capable DEVs detect the presence of NC

SuggestedRemedy:
Define and describe the association process properly


Comment:
figure 28: what is "master"? I can't beleive the number of synonymous terms used in this draft. there is difference between the caption and content of the figure!!!

Response:
ACCEPT. A master is an NC - this has been fixed.


Comment:
This means that the NC must be awake-enough to receive a packet, demodulate it, check CRC, decode the packet type. So what is remaining is transmission, right? Isn't transmission anyway turned off when there is no packet to send? What is the use of this scheme as it is defined here.

SuggestedRemedy:
Define and describe an efficient power management scheme within MAC with all the mechanisms, packet formats and message sequence charts.


Comment:
It is not clear as where this zone specification (8-bits wide) is present in the packet format. It seems like each entry in the AddressList in a beacon corresponding to the indicated "AddressType" value of "zone specification" have 8-bits of individual address followed/preceded by the soze-specification byte. But it is not clear anywhere?

SuggestedRemedy:
Define and describe beacon format with zone specification  and the zoning process itself.Define all the required packet formats and message sequence charts.


Comment:
Since AddressList is optional, it may not bepresent in beacons from an NC. then there is no way for a DEV to know its zone.


Comment:
this clause also assumes that there are no GTS-alloc/dealloc related transactions over the air initiated/terminated-at MAC. How do GTS re-allocation take into effect, like after how many beacons or millisec? how is that info exchanged? I know, higher layers :-)

SuggestedRemedy:
Define and describe mechanism required for GTS management within MAC. Add packet formats and message sequence charts


Comment:
DCS: How does the NC know the channel condition at DEVs to decide to change the channel? How does it communicate the decision to the associated DEVs?

SuggestedRemedy:
Define and describe mechanism required for dynamic channel selection within MAC. Add packet formats and message sequence charts


Comment:
DCS: What is the timeout for DEVs to start searching for the missing NC? How does a DEV distinguish the conditoins among (a) bad channel but NC still in the current channel and (b) good channel, but beacons are not rxd since NC is off and (c) NC moving to another channel?

SuggestedRemedy:
Define and describe mechanism required for dynamic channel selection within MAC. Add packet formats and message sequence charts. Add all required timeouts to the MAC-PIB


Comment:
How does the "macMAxHandshakeWaitDuration" work in GTS?

SuggestedRemedy:
Define and describe mechanism required for GTS-usage within MAC. Add the required packet formats and message sequence charts. Add all required timeouts to the MAC-PIB


Comment:
This clause does an attempt to describe the ack-timeout procedure. If what is needed already exists in an understood format, especially within 802, why not reuse it?

SuggestedRemedy:
Replace this text and the described mechanism with the "Ack procedure" mechanism described in clause 9.2.8 of IEEE-802.11-1999.


Comment:
When retries on a fragment (segment) is exhausted, all the remianing fragments of the same MSDU are thrown away, right?

SuggestedRemedy:
Add the text "When retries on a fragment (segment) is exhausted without an ack response, all the remianing fragments of the same MSDU are considered failed and hence are discarded by the MAC"


Comment:
In 7.5.7.1, "packet segment Bit" is not a bit. it is "Packet segment specifier" according to table-57. But the same is correctly used in 7.5.7.2 !!!

SuggestedRemedy:
change all "packet segment Bit" to "Packet segment specifier"


Comment:
"packet flags" is "Packet Control" according to table-57.

SuggestedRemedy:
change all "packet flags" to "Packet Control"


Comment:
How does this sequencing work in peer-peer scenario? Is the sequence number per link, that is a seperate counter for each pair of DEVs in the network? should the first packet of an MSDU always have "packet sequence bit" set to zero?

SuggestedRemedy:
Create a subcluase in 7 and describe the sequence number counter and its use in peer-peer scenario.Describe the use of packet sequence bit in peer-peer scenarioclearly state the setting of "packet sequence bit" across mulitple MSDUs


Comment:
With SDL I am sure one will be able to catch more issues than I have listed in this comments list. Without that I am not approving this doc.

SuggestedRemedy:
Add a complete SDL for all the mechanisms within the MAC

Response:
ACCEPT. 

David Cypher will help us do this Annex


Comment:
PICS helps a lot in defining the boundaries of the level of implementation and also helps in interoperability issues

Response:
ACCEPT. 

David Cypher will lead this effort


Comment:
Paragraph 1: Replace " but's " for " and's ""... limited power 'but' -> 'and'  relaxed throughput requirements."... while maintain a simple 'but' -> 'and' flexible protocol.

SuggestedRemedy:
Change for " and's ":"... limited power 'but' -> 'and'  relaxed throughput requirements."... while maintain a simple 'but' -> 'and' flexible protocol.


Comment:
Paragraph 2:I suggest several editorial changes in this paragraph

SuggestedRemedy:
Remove 'and' at the beginning of the second to last line.Swap Paragraph 2 with bulleted list (paragraph 3). (improves the flow)Last sentence in this paragraph should be removed since the concept of "star topology" has not been introduced


Comment:
Last Paragraph on Page 9: Editorial change suggested. See Remedy.

SuggestedRemedy:
Remove the word "simply", use another word or just remove.


Comment:
Paragraph 1:

The second to last sentence is incomplete.

SuggestedRemedy:
Append: "of the communications link" to the second to last sentence.

It will then read:

"... signal strength or quality of the communications link"

Response:
ACCEPT. Accepted and implemented the comment.


Comment:
Paragraph 3: 

Swap "agriculture" application with 'industrial control and monitoring'

Response:
ACCEPT. Accepted and implemented the comment. Still need to reply.


Comment:
Should this section be indented to a 5th level heading? 

We have been mentioning only two network topologies and cluster tree is a special class of peer-to-peer!.

Furthermore, this paragraph mentions the designated device without mentioning "network coordinators", then it explains that is has greater computational resources, but it does not mention FFDs (on line 39).

SuggestedRemedy:
In general, I proposed to improve the wording and aligned the explanation within the context of the section.

Make sure "it flows"

Response:
ACCEPT. Accepted and implemented the comment.  See also CommentID 503


Comment:
This clause talks about "blocks" instead of layers. I recommend replacing the word "blocks" around the whole section. The whole section talk about lots of blocks but there are only four!This section mentions that not all the blocks displayed are specified, but it should mention which ones, in this particular case is only the upper layers!Wording in general does not look clean (see lines 29-32). Make sure to include in the correction the rest of the section on Page 13.

SuggestedRemedy:
See above -> Improve wording, clarify the idea of blocks -> talk about layers


Comment:
Remove the word "may" from this line; the upper layers "DO" consist of ...


Comment:
The title used in figure 5 does not look consistent with the title used in figure 6. For example change to "Frame Structure without guaranteed time slots"


Comment:
Figures 5 and 6 should show 24 slots (right now shows 13 slots)


Comment:
Section 5.4.3.2 (and figure 10)What happens when the NC is polled by a network device and there is no data to send back. What is the answer from the NC? timeout?For this situation assume a non-beacon network.Furthermore on Figure 10, the packet named "Poll" should be change to "Data Request"!


Comment:
"... after the channel is sensed for activity". This idea is not clear. Use wording consistent with the rest of the draft and in technical terms.


Comment:
Page 19: Section 5.4.4

Figures 11, 12, 13 mentions: Beacon SPD, Data SPD and Handshake SPD, but the text mentions SPD1, SPD2 and SPD3! Need to fix this in order to make the explanation consistent.


Comment:
The whole section mentions several concepts not referenced (MPDUs, PSDUs, SPD, etc)


Comment:
The CRC field is called "Packed Check Sequence Field" on Page 80!. Fix for consistency. (see figures 11 and 12).


Comment:
Inconsistency in figures 19, 20 and 21 and section 7.2.1.4 (MSDU - MAC Sublayer Service data Unit Field):	MPDUbeacon     = MSDU +MFR
MPDUdata       = MHR + MSDU + MFR	MPDUack        = MHR +MFR
According to this (see figure 13 pp 21) the handshake packet does not have a MSDU.

In addition in figure 12, the MSDU includes a sequence number, while on figure 13, the MPDU includes the MHR!

Furthermore, the text below figure 12 on page 20, says that the MHR is composed by the "packet ctrl + address info + seq #"  while figure 12 states that the MHR is composed by "packet ctrl + address info"


Comment:
Remove the word "assuming" in the second line of the first paragraph! There is always an LLC!Improve wording of this paragraph


Comment:
Improve wording -> "If for any reason the receiving device is unable . . ."


Comment:
Improve wordingWhat  is a data packet form?Some bits are introduced for the first time with no explanation. avoid this and make the appropriate reference.Last paragraph references a non-existing section, it should be 7.5.7.3.


Comment:
The wording on the second paragraph looks informal. Change "idea" with "concept"


Comment:
The caption of figure 17 says Time Sequence Diagrams - Of what?


Comment:
Heading on section 6.2.1.1 should say "Channel Assignment..."


Comment:
What happens when a PD-Data.request is done with a MPDU whose length makes the overall phyPacketsize greater than the phyMaxPacketSize?	Is there a way to indicate a problem?Can we use the indication to show the error?


Comment:
The definition of PD-DATA.indication is using ppduStrength instead of 'Link Quality"


Comment:
What happens when the length of a received packet is greater thah phyMaxPacketSize?


Comment:
We should explain somewhere why we have the ED and CCA primitives (just a clarification).

This must be done in section 5


Comment:
Paragrapgh should say: "The PLME retrieves" instead of "attempts to retrieve"


Comment:
Title of Table 12 should say "PLME" instead of "PM"


Comment:
On table 14 there is an inconsistency between what this table states and the explanation in section 5.4.4. On 5.4.4 the sync header, beacon SPD and packet length is called PHR while here is not mentioned that way. This table mentions a sync bit, not mentioned in 5.4.4. Try to make consistent both explanations.


Comment:
Section 6.4.1.2 - Line 9: SPD are dependent on the data rate of the network?I think this is an error we are carrying from previous versions.


Comment:
[E} Idea mentioned in lines 12-14 is already stated in page 36, lines 31-32


Comment:
We need to add information related to the need of the sync burst packet. Nowhere in the whole document is mention the need of this functionality.

Probably add in section 5


Comment:
We have a phyNumChannelsSupported in the PIB but this may not be enough since we have 2 PHY's!


Comment:
Remove the sentence "For illustration purposes . . ." we do not have a gap anymore (in the PN explanation).


Comment:
Figure 21 does not look consistent with figure 19 (See PN block)


Comment:
Section 6.9 needs to be expanded. Not enough information


Comment:
The parameter "DISCARD_PACKET" is not mentioned in the enumeration table. Under what circumstances the LLC would like to discard a incoming (fragmented) packet?


Comment:
On line 10: Change word "conditional" to "optional"


Comment:
Table 33: Change 'Notification of a GTS reallocation" to "indication of a GTS reallocation".


Comment:
Page 62:- Line 26: [E]  Add a comma after "If it has"


Comment:
Line 44 and title in table 40 should say MLME-GTS-REALLOC instead of MLME-GTS.


Comment:
Page 65:	Section 7.1.2.9.2: The Zone concept is mentioned here but it has not been explained earlier. Recommend adding some text in the general section


Comment:
Section 7.1.2.10: This paragraph needs to be reworded or some introductory text added in section 5. Make a reference for the non-existing section that will show some scenarios of operation of "cluster-tree" related primitives.


Comment:
Table 41: The explanation of SrcFrameOrder needs to be make consistent with previous text explaining the same value.

Response:
ACCEPT. Changed to match the text in table 46 with a few ammendments.  Also changed table 50 accordingly.


Comment:
Page 67:Table 42: The valid range of this primitive should have a reference, the information supplied is not enough. We have a primitive that could do the same: MLME-RX-ENABLE, but operated from the upper layers. Can we remove MLME-NODE-NOTIFY.request?


Comment:
Table 44: In the explanation of "ScanPeriod" make a reference to the definition of Frame! Should this be frame slots?

Response:
ACCEPT. Changed so that the parameter represents a length of time to search based on the frame order.  This primitive, however, may need to be reworded to allow an active scanning mechanism which will be investigated further.


Comment:
Lines 41-42: The explanation in this paragraph is not clear. When the number of networks found equals an implementation specific limit? where is that limit?. What happens after scanning all channels?

Response:
ACCEPT. The implementation specified limit is just that.  The total number of network descriptors found requires storage space and so a device does not want to store too many.  However, as this primitive is also used by the coordinator to determine which networks are out there, it will, in general, need to be able to store far more network descriptors.  This is why it is implementation specific.  The description of what happens on completion of the scan has been improved.


Comment:
Page 70:
Section 7.1.2.15.1: How does the MAC knows where to search? the network ID in the PIB -> then state it.

On line 18: Where is the list of alternative channels?


Comment:
EXPAND! Make a reference. Should explain that only the NC does this!


Comment:
Table 51: What is the meaning of "Invalid Value" (under what conditions this situation happens?)


Comment:
Section 7.1.2.21: expand explanation of this primitiveIt would be nice if some introductory text were added in section 5 about the need for this.


Comment:
Table 52: Why do I need to track the beacon? I mean it is good to know you are in sync (and when you are not) but this can be a function implemented inside the MAC without control of the upper layers.

On the other hand I do not understand the need to track only once. Probably a sequence diagram somewhere showing the use of this primitive will clarify my doubts. (I know it made sense to me a few months ago...)

Response:
ACCEPT. The track mechanism is designed to allow devices to switch off the operation of the receiver if they so wish.  If the MAC tracked the beacon automatically then a device would have no way of preserving its battery power.  A device that tracks the beacon can respond to a pending message very quickly (e.g. application table lamp).  Conversely, a device that wakes up and syncs once can determine if messages are pending every so often (e.g. application thermostat).


Comment:
Table 53: DISCARD-PACKET missing. See page 54

Response:
ACCEPT. Added an entry into table 53 for DISCARD_PACKET: "Upper layers command the MAC to discard the packet due to resource limitations."


Comment:
Table 57: On section 5.4.5.4 (page 22) the data sequencing bit was defined as SB. Use the same name here for consistency. 

See also section 7.2.1.1.5 on page 77 -> Similar observation.

Response:
ACCEPT. Section 5 will be changed to match section 7.


Comment:
Table 57: On section 5.4.2.4 (page 22) a DataFollowing bit was defined, here we are using a different name!. 

Fix for consistency either here or in section 5 (I prefer the name in section 7). See also section 7.2.1.1.6 on page 78 -> Similar observation


Comment:
This section needs to be expanded. It mentions the LLC fragmentation capability when now the MAC is the one doing this function. It mentions a data transaction: is this a message fragment or the same sequence number for the whole message?. CLARIFY!What happens when there is a fragment lost?

Response:
ACCEPT. The reference to the LLC has been removed and the section has been expanded to explain the use of the data sequence number more fully.  The confusion with the term "sequence number" has also been resolved.


Comment:
The explanation on the PCS looks very confusing. Either make more clear or remove. In addition, the explanation on line 32 is inconsistent with previous definitions (LSB sent first). The paragraph in lines 34-36, looks as a expanded repetition of the previous one.

Response:
ACCEPT. This section has been clarified by giving an algorithm for transmission and reception of the PCS field.


Comment:
The text in this paragraph is not consistent with the fields mentioned in Table 63. Remove first line of that paragraph.


Comment:
It is not clear if the frame control field should be filled with zeros for a cluster tree or completely removed! I vote to keep it empty.	This section mentions short and long frames. Nowhere in the draft there is an explanation of this terminology.

Response:
ACCEPT. The frame control field has been expanded and renamed "topology control" as it is now defined for both topologies.  The bit representing short and long frames has been removed.


Comment:
I think this paragraph should say >22 instead of >=22, since with 22, there is still space for one GTS slot.This paragraph mentions "logical channel" without mentioning GTS slot. It should do so in order to make the explanation clearer.


Comment:
How a device get a Zone assigned?Does the AddressList contain only a single byte when using zoning?How the Network layer controls a zone?


Comment:
The last paragraph is not clear. "The GTSs shall be allocated starting from the end of the frame"????

Response:
ACCEPT. This sentence has been further clarified.


Comment:
Table 68 - macMaxframeSize		The name is confusing Packet vs. frame	The explanation mixes LLC fragmentation! This should be modified since fragmentation is now part of the MAC functionality.  	Review the range!


Comment:
Table 68 - macUniqueAddress	Is this an IEEE address? CLARIFY!

Response:
ACCEPT. This address has been clarified.


Comment:
Table 69: recommend to swap the last column with the first.


Response:
ACCEPT. Enlarged text box for improved readability.


Comment:
First paragraph -> Where is defined the broadcast network identifier?

Response:
ACCEPT. A definition of the broadcast network identifier has been added.


Comment:
Improve wording of paragraph located between line 34-37

Response:
ACCEPT. This paragraph has been merged with the previous and re-worded.


Comment:
Last paragraph on page 91: Table 28 cross-reference should be Figure 28.


Comment:
Recommend to add a flow diagram for Sections 7.5.2.1 and 7.5.2.2


Comment:
Figure 28 mentions "Master" 3 times, change to NC.


Comment:
Page 96:	Figure 30: Change conditional block "has the timer expired?" to "handshake Timer Expired?"

Response:
ACCEPT. Changed acknowledgment timer expired?


Comment:
In this explanation the Sequence Number of a Packet can be further explained. It is not clear from previous explanations!


Comment:
Figure 32: block (1) should say Packet?,  

What about using PIB terminology like: phyMaxPacketSize?. 

In addition, the title of the first block should be change to MD-DATA.something?

Response:
ACCEPT. Changed "max frame size" to "max packet size".


Comment:
The explanation of data sequencing is not clear. This whole section looks wrong. Check section 7.5.8 for Bit naming (FSB instead of PSB.


Comment:
It is not clear how the "data indication" works after all the segments are received! How the upper layers recognize a complete reception of a long message?


Comment:
Notice the use of abbreviations for these bits. Should this be reflected in Table 57 on page 76?

Response:
ACCEPT. The figures have been updated with the correct abbrieviations and table 57 has been augmented with the appropriate abbrieviations.


Comment:
Figure 37, should show the MD-DATA responses. There exist a data indication per segment, does the LLC provides a different buffer per data segments? This looks confusing!

Response:
ACCEPT. The figure has been changed to represent the intended behaviour in the specification.


Comment:
Need sequence diagrams showing some scenarios of operation of the cluster tree -> the Use of the MAC primitives specific for cluster tree.


Comment:
Table 26: In TxOptions: What is the meaning of "transmit in the current GTS"?


Comment:
Page 63 and 64: The GTS Reallocation looks like garbage collection. I would like to eliminate this functionality and leave it for the upper layer to handle it, since only the NC deals with this, it should not be a problem. I know GTS is optional but if implemented it has to have the reallocation functionality! Keep it simple.The GTS explanation in general is not clean


SuggestedRemedy:
Up to 254 network nodes in a given cell at a star configuration (We may need to define cell). option for extention by using Cluster-Tree configuration.

Response:
Waiting answer from Boz. E-mail sent on 01-30-02


Comment:
Cluster-tree seems to be a topology of its own. It has different settings and behaviors described along many sections in this standard. It seems inaccurate to state the following (line 7-8):LR-WPAN network may operate in either of two topologies: the star topology or the peer-to-peer topology.It is difficult to understand how a cluster-tree is just a topological restriction over peer-to-peer topology, as stated in section 5.2.1.2 (page 11 line 22-23).

SuggestedRemedy:
Make the cluster-tree a clear, well defined topology option in this standard.


Comment:
The following sentence is irrelevant and can be remove:

"The network coordinator does not need to be a host personal computer."


Comment:
The following sentance is more suitable to be under section 5.2.1:"The formation and network managment .... of this standard."

SuggestedRemedy:
Move the sentence under section 5.2.1:
"5.2.1 Network Formation
The formation and network managment .... of this standard.
this informative section ..... be formed"


Comment:
The description of the cluster tree topology is not clear. Can simple network node transmit a beacon? if so - is it a peer to peer communication or a star? if not, how other network nodes can make that node, their parant node as shown (for example) for nodes 12 and 11 at CID=0 in figure 2?

SuggestedRemedy:
Cluster-tree topology seems fundamental to this standard (and also somewhat a unique capability on the WPAN-WLAN family). We should describe in more details the network requirments, formation and operation for this topology.


Comment:
More then a single network node is possible:

.... between the network coordinator and the network node.

SuggestedRemedy:
... between the network coordinator and a network node.


Comment:
use of acronym:low-rate wireless personal area network


Comment:
Data request, or data poll from a network node to the network coordinator must receiver an answer. Hance - we should allow the network coordinator to answer to this poll request immediately after reciving it, and without compating again on the channel using the CSMA-CA protocol. This way network utilization can be improved. This sequence will look like a piggyback of data on the ack response. The last ack (line 17 at figure 9 and line 38 at figure 10) will be unnecessary in that case.If not allowing the above sequence, we must (at least) add the possibilty of sending ack as a response to the 'Data request' message in figure 9 (line 13) and to the 'Poll' message in figure 10 (line 34). This is because the data packet from the Network Coordinator can be delayed for a significant period of time.

SuggestedRemedy:
Implement a new sequance that allow response from Network Coordinator to be transmitted immediately after the request from the network node.


Comment:
SPD1, SPD2, SPD3 are not descriptive acronyms

SuggestedRemedy:
SFDB for Start Frame Delimiter of Beacon.SFDD for Start Frame Delimiter of Data.SFDH for Start Frame Delimiter of Handshake.This comment also implies that Start Frame Delemetrer is more suitable then Start Packdet Delimiter.

Response:
ACCEPT. Accepted comment. Resolved with #49 and associated comments.


Comment:
It is not clear from the standard what a device should do in case of failer to transnit a beacom when the channel is busy. Should it choose a random time to transmit again or should it transmit at the next beacon scheduled time? I assume here that network beacons should be transmitted at fixed known intervals. If this is not the case, it should be explicitly explained and described in a dedicated section.Same question also exist for GTS. If a device is failing to access the channel in his GTS what should it do? wait for the next superframe? use CSMA-CA? give up?  transmit anyhow?


Comment:
It state here that "All data transfers are handshaked. ..."

In other places in this standard (for example page 96 line22 Figure 30) it state that handshake is optional.


Comment:
The terms for the 'Packet Segment Flag' are not consistence throughout the standard.  The 'packet following flag' in this section is called Packet Segment Bit flag in section 7.5.7.1 page 99 line 6 (for example).There is also a lot of confusing using this terms in other sections (for example is this flag a bit or two bits?).

SuggestedRemedy:
Walk through the standard and make the terms for the Packet Segment field consistence.


Comment:
This Figure is not clear enough. It starts from C) and not from A) (line 6). there are no headers to the different sides of each time graph. It is not clear what the '~' sign is for in figurs 17 d,e,g.


Comment:
"Table 1 lists the primitives .. " should be "Table 2 lists the primitives .."


Comment:
"Start of Packet field" is not well defined in this standard

SuggestedRemedy:
Use Start Packet Delimiter field (or Start Frame Delimiter)


Comment:
"Conversely, the output state in unaltered when there is a ... "

SuggestedRemedy:
"Conversely, the output state is unaltered when there is a ... "


Comment:
"A compliant device shell have a sensitivity of -85dBM or better"

SuggestedRemedy:
"A compliant device shell have a sensitivity as specified in section 6.2.5.3  or better"


Comment:
The mapling between the integer and the energy level shell be defined.


Comment:
The mapling between the integer and the link cuality level shell be defined.


Comment:
... compliant with the 802.11 family of wireless ...

SuggestedRemedy:
.. compliant with other standards in the 802.15 family of wireless personal area network as well as the 802.11 family of wireless ...


Comment:
At the table header it says:

"MD-SAP Primitive"


SuggestedRemedy:
... on all channels in the ChannelList."

Response:
ACCEPT. Changed to "…on all channels specified in the ChannelList."


Comment:
What happen to pending message at the network coordinator that is never requested by the relevent network node. Is there a time-to-live timer assosiated with that message? How many times the destination Address for the relavant node will appear in the beacon. If discarding of that message is under LLC responsibility an indecation must be sent up to the LLC layer (it is somewhat like a fail on retry) - Is that out of this standard's scope?Also what happen in case where the node requests for message that doesn't exist (for some reason) at the network coordinator?


Comment:
Comment number (4) doesn't exist in the comment list.

Response:
REJECT. Comment (4) in figure 26 is described in the text which refers to figure 26.


Comment:
"These concepts are illustrated in table 28"

SuggestedRemedy:
"These concepts are illustrated in Figure 28"


Comment:
"... copies max bytes, indexed from dada[i] to data[max+1]..."

SuggestedRemedy:
"... copies max bytes, indexed from dada[i] to data[i+max+1]..."

Response:
ACCEPT.  Changed "data[max-1]" to "data[i + max - 1]"


Comment:
sdu is not defined as acronym and it should be in capital letter

Response:
ACCEPT. As used here "sdu" is intended as a variable containing the byte sequence that comprised the received packet.  To avoid confusion, "sdu" has been changed to "RxPacket".


Comment:
Why the phyMaxPacketSize is so small?is it really only 58 bytes for the 2.4 GHz phy?If so - why the 900 MHz phy has longer packet size (127)?


Comment:
What happen to packet with Destantion Address not equal to the Destanation Address of the receiving device (a 'not-for-me' packet). Which entity filters those packets out, and when? This is not stated anywhere. in that section it stated that the CRC is the only field that beenig checked upon packet receiving.


Comment:
The CCA mode 4 is not clear to me (sorry). What do we gain from listening to the channel for max PPDU size. it seems more important to wait for at least the turn around time (a shorter period of time - I guess) so we won't collide with a possible ack...

SuggestedRemedy:
Define a mode that insure that no collision will occur with an ack. For that to happen we must listen to the channel for at least a turn-around-time.


Comment:
What if there are more then 16 addresses pending? Are they transmitted in cyclic order?

SuggestedRemedy:
Can we restrict the number of DA in a beacon in order to control of network utilization. For that we need a maxDANumber field on the mac PIB.


Comment:
Can we support another addresses convention in which the network id will be a single byte long, and the device address will be of two bytes. This can give us more flexibility in crowded areas.


Comment:
Consistence usage is needed for the terms 'frame', 'superframe' and 'packet'. 'superframe' should be used across this standard to describe the time period between successive beacons. We need to decide whether the piece of information sends across the medium is a packet or a frame. We then need to use thes terms consistently across this standard.

Response:
REJECT. The IEEE 802.15.4 draft defines a "frame" as the time period between two successive beacons.  A "superframe" is generally defined as a collection of such frames.  As 15.4 does not have such a concept, the term "superframe" is not intended to be used.  Packets are transmitted with the frame, as defined in this draft.  Consistency, in respect of the terms "frame" and "packet" will be investigated.


Comment:
The section of coexistence for 802.15.4 does not address all other IEEE devices using 2.4 GHz band, such as 802.15.1, 802.15.3. Also it only addresses 802.15.4 devices as interferers, but does not cover what will be affected for 802.15.4 devices from other 2.4 GHz devices, and how 802.15.4 devices can tackle the interference from other 2.4 GHz devices.

SuggestedRemedy:
Please address the above coexistence issues.


Comment:
Should add PD(-SAP), MD(-SAP), MA(-SAP) in the acronym section for completeness' sake

Response:
ACCEPT.

Waiting for determination of the convergence layer so I can define:

MA-SAP and MD-SAP


Comment:
CCA mode 4: The timer is set to the max PPDU size.  What should happen if the PPDU length information is decoded?  Does the CCA keep reporting busy before the timer reachs max PPDU size?  It is not quite clear from the text.  Besides, what's the difference between CCA mode 3 and 5?  They looks the same in the draft.


Comment:
I find it confusing to state that OQPSK modulation is used and there are 4 bits per symbol.

SuggestedRemedy:
Include the fact that the bits are coded before modulation, e.g. CPM and OQPSK.


Comment:
The key to a standard is interoperability.  Interoperability requires unambiguous terminology and typically includes SDL.

SuggestedRemedy:
Add SDLs to validate the proper implementation of this standard

Response:
ACCEPT. 

David Cypher will do high level SDLs for us


Comment:
A sensitivity of -85 dBm is not good enough for the 868/928 PHY.  The major reason for this device over the 2.4 GHz device is range.  The extra range by frequency only is offset by antenna efficiency so the only other option is extra sensitivity by the narrow bandwidth.

SuggestedRemedy:
Review the modulation technique as per Eb/No required to improve sensitivity.


Comment:
relic from the past:  we still have ppdustrength in for PD-DATA.indication.


Comment:
The limits for transmit PSD are unclear as to whether they are averages or peak limits

SuggestedRemedy:
add verbage stating peak or average (if average over what time period?)


Comment:
what should be limits are stated as desired levels, eg adj chan rej = 0 dB

SuggestedRemedy:
change 0 dB and 30 dB to GE 0 dB and 30 dB


Comment:
The method proposed for 868/928 has not been validated with published analyses or test results for sensitivity, BER vs interference, multipath, etc.

SuggestedRemedy:
produce validation tests or analysis for the method proposed


Comment:
"Differential Encoding is a process whereby the output state is inverted when there is a logic state "1" in the binary input data stream. Conversely, the output state in unaltered when there is a logic state "0" in the binary input data stream." isn't the differential that I learned in school.  If the MAC layer sends this phy a string of "0"s there will be a long string of zeros at the RF, this is not differential

SuggestedRemedy:
Either change to true differential or change the name.


Comment:
The following verbage isn't strong enough:The 802.15.4 devices have several characteristics that improves its coexistence with other wireless devices operating in the 2.4 GHz band. 802.15.4 devices are intended for low duty cycle applications (typically less than 1%) using CSMA/CCA mechanism for collision avoidance. Furthermore, it is defined to operate in two possible frequency bands (868/915 MHZ and 2.4 GHz). Finally, the low transmit power will minimize their effect on other 802.11/802.15 compliant devices.

SuggestedRemedy:
Replace with:The 802.15.4 devices have several characteristics that provides coexistence with other wireless devices operating in the 2.4 GHz band. 802.15.4 devices are intended for very low duty cycle applications (typically less than 1%) using CSMA/CCA mechanism for collision avoidance. Furthermore, one of the  two possible frequency bands 868/915 MHZ has absolutely no coexistance issues with 2.4 GHz devices. Finally, the low transmit power will minimize their effect on other 802.11/802.15 compliant devices.


Comment:
FSB is a relic from the past "frame" days, this acronym refers to packet sequence bit


Comment:
The reallocation of GTSs is a good idea but I cannot understand how the mechanism's stated in this section will work.  Specifically how will the destination nodes know about a reassignment.

SuggestedRemedy:
detail a mechanism to effectly defragment the GTSs


Comment:
coordinator snoozing does not achieve any desireable quality that I can think of, typically it's used to save power but this implementation requires the snoozing coordinator to be in the receiving state and receiver current drain can be higher than transmitter drain.  Rather than helping this standard it complicates the implementation.

SuggestedRemedy:
kill this feature and remove all references to it


Comment:
Zones Specification is not well described.  How is a zone assigned?  how is it optimized for battery or other?

SuggestedRemedy:
Fill in the details, perhaps with a diagram


Comment:
I did not find any description of the mechanism for resolving duplicate network id's.  I understand the network search but it may not find a network or a network may "walk" into another coverage area.

SuggestedRemedy:
address the mechanism to resolve the issue of duplicate network IDs


Comment:
Dynamic Channel Selection is a good feature (very good for coexistence) but is not described in detail

SuggestedRemedy:
detail a mechanism to detect when to change channels, advise nodes of changing (sleeping nodes?), and seek out lost nodes after the change.


Comment:
In Network Synchronization, there really is no description of the procedure to attach and join a network.  Specifically I believe that logical addresses are a good idea but who assigns them?  Since I didn't find any text addressing this I assume that it must be in higher levels.  But what about simple networks , why not put this function into the MAC?

SuggestedRemedy:
Put short address assignment into the MAC


Comment:
In Network Synchronization, there really is no description of the procedure to attach and join a network.  Specifically, how is authorization completed?  I know that the upper layers are responsible for deciding what node can joing the network but what are the commands from the upper layer to achieve this?

SuggestedRemedy:
Describe procedures and primitives to implement authorization.


Comment:
Power shutback is required for this standard but is not addressed as to when it should be used or not used.  Spefically: "A compliant transmitter with a maximum transmit power of more than 16 dBm shall be capable of reducing its power to less than 4 dBm."  Why is this required if we don't specify a mechanism to use this aspect?

SuggestedRemedy:
Either kill the max spec or include procedures to use it


Comment:
This specification describes a physical layer that, at the RF interface, is not interoperable, and does not coexist with other IEEE adopted or proposed standards such as 802.11b, 802.15.1, and 802.15.3.  

The 868/915MHz PHY characteristics are not even described, but have TBD.  Having a system that has three different frequency bands as optional but doesn't require all devices to support all bands won't interoperate.  The 802.15.4 system needs to either be at 2.4GHz and describe coexistence with 802.15.1, 802.15.3, 802.11b, and microwave ovens, OR it needs to be a dual band 868/915MHz system that works automatically in any geography (is either 868 or 915 legal in Japan?).

SuggestedRemedy:
Pick a mandatory frequency or require dual/multi-band.  Define all the data rates and modulation types (NO TBDs).


SuggestedRemedy:
Line 12 should read "56 + 8n to 208 + 8n".
Line 16 should read "104 + 8n to 256 + 8n".


Comment:
Subclause 5.1.1 is an unnecessary heading, because it is not followed by 5.1.2.

SuggestedRemedy:
Remove the heading for 5.1.1, and merge the information with 5.1.


Comment:
Although the packet length field is always part of the PHY header, it is not valid for a handshake packet.

SuggestedRemedy:
Point this out here to avoid confusion with statements made later in the document.


Comment:
In general, the naming convention in the data sequencing description is inconsistent with the more detailed description in subclause 7.5.7.3. Also there is no mention of the device-stored sequence bits.

SuggestedRemedy:
Update the subclause to agree with 7.5.7.3.


Comment:
The diagrams are listed as c) through i).


Comment:
State that there is the option for a mains powered network coordinator.


Comment:
Why the upper layers have to do a confirmation of the GTS reallocation?Can we leave the reallocation for the upper layers?


Comment:
What is the protocol for a NC to setup a GTS? How does a node request a GTS?


Comment:
Figure 29 shows SuperFrame! change to Frame


Comment:
Page 94, Lines 9-11: What are these transmission options? (See TxInGTS, where is this defined?)

Response:
ACCEPT. Removed TxInGTS reference and related it back to the MD-DATA.request primitive.


Comment:
The first two items of this picture disapeared! ("a" and "b")

Response:
ACCEPT. Picture was removed from the draft


Comment:
This paragraph re3ferences Table 1 when it should be Table 2!


Comment:
The Phy and mac headers shuold be more uniform.

Also we should try that the whole structure will be as close as possible to the 802.15.3 draft (They have the MAC clause before the Phy clause (for example)

SuggestedRemedy:
6. Phy 
6.1 Overview
6.2 General 
7 Mac Sub.
7.1 Overview
7.2 General Requirement and Definitions
7.3 MAC Sublayere.…


Comment:
The definition is in a single form while the explanation is in plural.

SuggestedRemedy:
Logical Channel: One of a variety of channel types on a physical link.


SuggestedRemedy:
... directions and envelops the person or the object whether stationary or ....


Comment:
is ppm should realy be in lower letters?

Response:
ACCEPT IN PRINCIPLE.  Waiting for confirmation from J. Longman


SuggestedRemedy:
Remove it from here, or from the other clause (03), or make sure that other definitions also appear as acronyms when needed. (Consistency)


Comment:
"A Low-Rate WPAN is a simple, low cost communication device....."

comment: Low-Rate WPAN is not a device.

SuggestedRemedy:
A Low-Rate WPAN is a standard for wireless conectivity between simple, low cost communication devices allowing applications with ...


Comment:
.. in an LR-WPAN network. one is caled a full function device (FFD) and the other one is the reduced function device.Comment: LR-WPAN should prefix with 'a' and not with 'an' and the word network is redundant. The second sentence is asymmetric.

SuggestedRemedy:
.... in a LR-WPAN, a full function device (FFD) and a reduced function device (RFD).


Comment:
"reduced function device" should be changed to "RFD"


Comment:
This is a generic comment:More clear definitions are required for the terms in use. We need to decide where to use LR-WAPN and where to use 802.15.4. Is LR-WPAN a standard (line 49-50) a network (line 8) or a device (line 3)?.A clear definition is needed for RFD, FFD, Network Coordinator (Network Coordinator defined as NC in the acronyms section. this acronym is not being used), Designated device - DD, and cluster head (section 5.2.3.1), a DEV and a station (line 44).The discussion about RFD and FFD should be deferred for later sections.

Response:
ACCEPT. Accepted comment. Much of the concerns were addressed bu other comments.


SuggestedRemedy:
Two possible data rates: 250 kbps or 20 kbps.


Comment:
Remove the word "delay". Should read "message latency".


Comment:
The naming convention in the figure does not agree with 7.5.7.3.


Comment:
The referenced subclause number is incorrect.


Comment:
A Low-Rate WPAN is a network not a device.


Comment:
This statement is true for star networks but not for cluster trees.


Comment:
No units are specified for macBeaconTxTime.

Response:
ACCEPT. Added: ", in milliseconds" after the first paragraph of this row.


Comment:
The two paragraphs on star and peer-to-peer topology should be more symmetric. For instance, star paragraph does not discuss applications.


Comment:
The star topology is not the only topology to use unique IEEE addresses. This should be presented as a more general statement or repeated in the peer-to-peer paragraph.


SuggestedRemedy:
Change "default address" to "unique IEEE address".


Comment:
A cluster tree device may communicate with any neighboring node (i.e. any node in its radio sphere of influence) not just its parent and children nodes.


Comment:
Is it really necessary to have both figures? If so, figure 3 does not show the 802.2 LLC.


Comment:
Incorrect statement - all cluster tree devices transmit beacons.

SuggestedRemedy:
Change to "The network coordinator of a star network and all cluster tree devices can transmit a network beacon."


Comment:
It is not clear from this paragraph why the beacon start of packet delimiter is called SPD1.

SuggestedRemedy:
Explain that each packet type has its own unique SPD. Also the SPD is used to determine the packet type (rather than "to determine the content of the packet").


Comment:
The boundary drawn between MHR and MSDU is incorrect.

SuggestedRemedy:
Redraw the boundary such that the DSN is part of the MHR.


Comment:
This statement is not true for all topologies. A cluster tree device will not attempt retransmission after a random time. This would destroy the network synchronization.

SuggestedRemedy:
Add a sentence following "backoff for a random period of time before trying again." Add "However, the backoff period in a cluster tree network is quantized in multiples of the beacon period."


SuggestedRemedy:
Instead of "CRC-16", call it "16-bit CCITT CRC".


Comment:
The network coordinator is not the only device that transmits beacons.

SuggestedRemedy:
"Transmits network beacons if the device is either a network coordinator or a cluster tree device."


Comment:
The same verb tense should be used for all the listed tasks.

SuggestedRemedy:
"Provides a reliable link...""Segments data into packet..."

Response:
ACCEPT. Changed "Providing" to "Provides" and "Segmentation of" to "Segments".


Comment:
What if a device receives a primitive that it does not understand? How is this handled?


Comment:
Allocating one bit for topology type does not allow for future expansion.

SuggestedRemedy:
Rearrange the bit definitions such that the reserved bit is adjacent to the topology type bit.

Response:
ACCEPT. The bits of this field have been reordered.  The topology type has been moved to bit 6 and the reserved field to bit 7, giving expansion possibilities if necessary.


Comment:
Change the wording from "one byte in length" to "one bit in length".


Comment:
Change "CSMA/CA" to "CSMA-CA" for consistency.


Comment:
Change sentence to read "The MAC sublayer provides two services to higher layers, accessed...".


SuggestedRemedy:
Change "layers determines" to "layers determine".


Comment:
Change wording from "MAC attribute" to "MAC PIB attribute".


Comment:
Change "None" to "The effect on receipt of this primitive is not specified in this standard".


Comment:
Change "explantation on zone" to "explanation of zone".


Comment:
Change "The frequency at which the source transmits" to "The period at which the source transmits".


Comment:
Change "The receipt of" to "The effect on receipt of".


Comment:
What happens if a device receives a request to enable (disable) the receiver while it is already enabled (disabled)? This should be specified.

SuggestedRemedy:
Add "If the receiver is already in the desired state, no action shall be taken."


SuggestedRemedy:
It should be stated that all reserved bits are set equal to zero.

Response:
ACCEPT. Page 51, table 26, line 46, left unchanged as this is representing a range of values which are not specified.  Page 81, table 63, line 27: changed "Reserved" to "Reserved (set to zero)".  Page 83, table 66, line 50: left unchanged as this is representing a range of values which are not specified.


Comment:
Here the term short "packets" is used, but Table 64 refers to short "frames".

Response:
ACCEPT. Changed "frames" to "packets" in table 64.


Comment:
Units for macBaseFrameDuration and macBaseSlotDuration not specified.

Response:
ACCEPT. Added ", in seconds," to both entries.


SuggestedRemedy:
This should read "backoff exponent, to".


Comment:
Packet-specified sequence bit is called FSB. Why not PSB?Packet segment flag is called FS. Why not PS?

Response:
ACCEPT. Changed all references of "FSB" to "PSB" and "FS" to "PS".


Comment:
"Assuming the device has a logical link control layer..."It is not an option to have a LLC (802.2 must be there).Also "layer" should be changed to "sublayer".


Comment:
Delete "The service data unit is" and begin with "Information that is...".


Comment:
Change wording from "A portable device is one that may..." to "A device that may...".


Comment:
Change "...LR-WPAN network, one is called a full function device..." to "...LR-WPAN network, a full function device (FFD) and a reduced function device (RFD)."


SuggestedRemedy:
Change "...the network it can..." to "the network; it can...".


Comment:
Change "...and that do not require to send..." to "...and are not required to send...".


Comment:
Change "RFD only protocol" to "RFD-only protocol".


Comment:
Change "250 kbps and 20 kbps" to "250 kbps or 20 kbps".


Comment:
Change "This network is ad-hoc..." to "This network may be ad-hoc...".


Comment:
Missing punctuation. Add a period at the end for consistency.


SuggestedRemedy:
Change "representation not all" to "representation; not all".


Comment:
Change wording from "implemented as either an embedded" to "implemented either as embedded".

Response:
ACCEPT. Accepted and implemented the comment.  Same as commentID 216


SuggestedRemedy:
Change "is impractical therefore the power" to "is impractical; therefore, power".

Response:
ACCEPT. Accepted and implemented the comment. Same as #132


Comment:
Punctuation needed. Add a period at the end of sentence.


Comment:
Not all data packets require a handshake.Unclear wording - receiving device "is unable to deal with"

SuggestedRemedy:
Change to "Data transfers are handshaked...in Figure 14; handshaking is optional (see 7.1.1.1). A successful...is confirmed with a handshake packet; otherwise, no handshake is sent."


Comment:
From the table it is unclear how many bits are for Sync Burst Flag and how many are for Packet Length.


Comment:
Change "Response to the a" to "Response to a".


Comment:
Change "output state in unaltered" to "output state is unaltered".


SuggestedRemedy:
Change to "(after a macHandshakeWaitDuration period of time)".


Comment:
The phrase "until it is no longer heard" is unclear.

SuggestedRemedy:
Remove the phrase "until it is no longer heard".


Comment:
Should read "phyMaxPacketSize - 26" not "+ 26".


Comment:
For consistency reword as "The format of..." instead of "Format of...".


Comment:
This does not specify whether or not "another device currently transmitting on the channel" belongs to the same network as the device.


Comment:
The number of retry attempts is unspecified.

SuggestedRemedy:
Add a reference to macMaxPacketRetries in Table 68.

Response:
ACCEPT. Changed to "No handshake is received after macMaxPacketretries.".


Comment:
MLME-SEARCH.request causes the MAC to search for "an existing network". This is too vague, because it is really looking for a specific network.

SuggestedRemedy:
Change wording to "This primitive requests that the MAC sublayer search for the current network following a loss of synchronization".

Response:
ACCEPT. The use of this primitive is not necessarily used following the loss of sync.  Rather it is used when a device repeatedly cannot contact its network.  This clause has been improved.


Comment:
Would the heading "Uplink/downlink standard addressing" be more appropriate?

Response:
ACCEPT. Page 79, section 7.2.1.2.1: changed title to "Standard addressing for star topology".  Page 79, section 7.2.1.2.1, line 3: changed to "A packet using standard addressing for star topology shall specify…".  Page 79, table 59: changed title to "Format of standard addressing for star topology".  Page 79, section 7.2.1.2.1: removed "(uplink)" and "(downlink)" from 2nd paragraph. Page 78, table 58: changed "Short, uplink star" to "Short standard addressing to the network coordinator (star)", "Short, downlink star" to "Short standard addressing from the network coordinator (star)", "Short, peer-peer cluster tree" to "Short cluster tree addressing (peer-to-peer)", "Extended, uplink star" to "Extended standard addressing to the network coordinator (star)", "Extended, downlink star" to "Extended standard addressing from the network coordinator", "Extended, peer-peer" to "Extended standard addressing (peer-to-peer)", "Extended, peer-peer cluster tree" to "Extended cluster tree addressing (peer-to-peer)".  Page 91, section 7.5.2.2.1, line 34: changed first sentence to "If no messages are pending and no device activity is detected, the network...".  Page 79, section 7.2.1.2.2: changed the title to "Extended standard addressing for peer-to-peer topology" and its first sentence to "A packet using extended standard addressing for peer-to-peer topology shall specify...", changed table 60 title to "Format of extended standard addressing for peer-to-peer topology".  Page 79, section 7.2.1.2.3: changed title to "Cluster tree addressing for peer-to-peer topology", changed first sentence to "A packet using cluster tree addressing for peer-to-peer topology shall specify...", changed table 61 title to "Format of cluster tree addressing for peer-to-peer topology".


Comment:
Some of the MAC PIB objects are not referenced anywhere in the draft.

SuggestedRemedy:
Include some indication of their use in the draft.


Response:
ACCEPT. Text has been added to indicate how this is achieved.


Comment:
The broadcast network identifier value is not given in the document.

Response:
ACCEPT.  Added a definition into section 7.2.1.2.1 for the broadcast network identifier.


Comment:
Change AddressType type from integer to bitmap. Change valid range to 0000-1111.

Response:
ACCEPT. This field should be an integer.


Comment:
This is the only mention of multicast/broadcast frames.


Comment:
Misspelling - "one ore more" should read "one or more".


Comment:
Do we really want to use CSMA for beacons, since they are responsible for synchronizing the network (what if GTS is supported)?


Comment:
What happens if a network coordinator receives a GTS request while it has a previous request pending? How does it handle simultaneous requests?


Comment:
Does a network coordinator change its macFrameOrder to 15 when it enters snooze mode?


Comment:
What if two networks do somehow choose the same network ID? How would this conflict be resolved?


Comment:
One bit for Address Type does not allow for future expansion of the protocol.


Comment:
Should read "MLME-GTS-REALLOC.indication". Table 39 title must also be changed.


Comment:
Should read "MLME-GTS-REALLOC.response". Table 40 title must also be changed.


SuggestedRemedy:
Change sentence to read "Handshake packets acknowledge a previous transmission and will be sent without a ..."

Response:
ACCEPT. Accepted comment, so it has to be reworded once changing from Handshake to Acknowledge.


Comment:
The figure does not show the layer hierarchy described in the associated paragraph. Also the terminology "N-users" and "N-layers" is not clear. Can "user" be replaced by "device"?

Response:
ACCEPT. This text comes pretty much from 802.2 with some slight modifications. This concept is somewhat strange and I tried to make it a little easier to understand. N-user is not a device, it is just another layer/sub-layer that "uses" the services of a different layer (service provider).For instance the LLC is a user of the MAC sublayer but a service provider for the network layer.


Comment:
Start a new sentence with "Please refer to..."


Comment:
The subclause does not include an explanation of when TRANSMISSION_PENDING status would be issued.

Response:
ACCEPT. Added text in the MD-DATA.request primitive section to explain this value.


SuggestedRemedy:
Change to something like "Either the non-zero identifier of an existing GTS, if requesting a GTS deallocation, or 0, if requesting a new GTS allocation."


SuggestedRemedy:
Change to "The MAC sublayer shall then reallocate all other GTSs as necessary."


SuggestedRemedy:
Change to "The first GTS shall be allocated at the end of the frame, including slot 24. Subsequent GTSs shall be allocated slots immediately preceeding existing GTSs."

Response:
ACCEPT. Changed sentence to "The GTSs shall be allocated as close to the end of the frame as possible and shall not overlap any previously allcated GTSs."


Comment:
When does handshaking occur for GTS transmissions?


Comment:
Since the network coordinator is only used in the star topology, this should be pointed out in the definition.


Comment:
This is not a characteristic of all LR-WPAN networks (there is no network coordinator in peer-peer topologies).


SuggestedRemedy:
Change "dynamic" device addressing to "logical" device addressing.


Comment:
Below the heading "IEEE Std 802.15.4-2002", the description of standard should make clear that the "optional frame structure" is only available in some topologies.

SuggestedRemedy:
"...however with the optional frame structure available in some network topologies,..."


Comment:
Reword from "Once a cluster becomes large enough" to "Once predetermined application or network requirements are met, the DD may assign..."


SuggestedRemedy:
Change to "impractical; therefore, power consumption..."


Comment:
Change wording to "This primitive requests that the MAC sublayer scan for networks."


Comment:
Title should read MAC "Sublayer" not "layer".


Comment:
macFrameOrder not in alphabetical order within the table.


Comment:
The valid range for ScanDuration is not large enough for large macFrameOrder values.

Response:
ACCEPT. Changed so that thr parameter represents a length of time to search based on the frame order.  This primitive, however, may need to be reworded to allow an active scanning mechanism which will be investigated further.


Comment:
Table of Contents pages are numbered in arabic numbers, starting with 1; this is confusing with the text body, which is also numbered in arabic numbers, starting with 1.  The document now has two page 1s and two page 2s.

SuggestedRemedy:
SuggestedRemedy: Number Table of Contents with lower case roman numerals, ix and x.


Comment:
Sentence contains grammar error, and it should probably be re-written to say that there are two PHY's now.

SuggestedRemedy:
Replace with the following:""This clause specifies the two physical layer (PHY) options for IEEE 802.15.4.  In addition to targeting different frequency bands, the two PHY's use different modulation/spreading formats and yield different data rates (Table 1).""


Comment:
Improve format of Table 1 to show that there are two PHY's.

SuggestedRemedy:
Combine the rows for 868-868.6 MHz and 902-928 MHz into a single row.Add row headings ""868/915 MHz PHY"" and ""2.4 GHz PHY"".


Comment:
Subclause number appears to be incorrect.

SuggestedRemedy:
This subclause should probably be numbered 6.2.2.


Comment:
Add reference information for PIB attribute.

SuggestedRemedy:
Spell out PIB acronym since this is the first use in the chapter.Add ""(Section 6.5)"" following the phyMaxTransmitPower attribute.


Comment:
Re-defined ""receiver reference sensitivity"" to avoid having two numerical values in the text.

SuggestedRemedy:
Proposed definition:""The receiver reference sensitivity shall be the upper limit of the receiver sensitivity requirement in Section 6.8.6.""


Comment:
ppduStrength is old terminology.  Also change parameter name in Table 4.


Comment:
Clarify the phrase ""confirm the transmission"".

SuggestedRemedy:
Proposed phrase:""confirm the end of transmission""


Comment:
Add reference to energy detection section.

SuggestedRemedy:
Add ""(Section 6.8.8)"" to the end of the sentence.


Comment:
What is effect of receipt if the receiver is already on when enable is received, or if the receiver is already off when disable is received?

SuggestedRemedy:
Add text, ""If receiver is already in the desired state when the primative is received, no action shall be taken.""


SuggestedRemedy:
Add ""(Section 6.5)"" following phyMaxPacketSize.


Comment:
This subclause should be combined with 6.6.2.4.

SuggestedRemedy:
Remove subclause 6.6.2.1.  Change the heading of 6.6.2.4 to read: ""Code Position Modulation Encoding"".  The text of 6.6.2.4 should read:""In code position modulation (CPM) each transmitted data symbol is represented by a 32-chip PN sequence (Table 17) <footnote>.  The set of 16 PN sequences are related to each other through cyclic shifts and/or conjugation (inversion of odd-indexed chip values).""


SuggestedRemedy:
The box representing chip value c1 should be fixed, and the illustrated offset between I-phase and Q-phase chips should be adjusted to be one half of the chip duration.


Comment:
Wording of this paragraph could be improved. Also, we don't currently specify a time-averaging period (not proposed here).

SuggestedRemedy:
Change to:""The transmitted spectral products shall be less than the limits specified in Table 18.  For both relative and absolute limits, spectral power shall be measured using a 100-kHz resolution bandwidth.  For the relative limit, the reference level shall be the highest spectral power measured within +/- 1 MHz of the carrier frequency.""


Comment:
Tx-to-RX turnaround time and Rx-to-Tx turnaround time, as currently specified, do not guarantee handshake operation.

SuggestedRemedy:
Change Tx-to-Rx specification (6.8.1) to:""The transmit-to-receive (TX-to-RX) turnaround time shall be less than 200 us.""Change Rx-to-Tx specification (6.8.2) to:""The receive-to-transmit (RX-to-TX) turnaround time shall be greater than 200 us and less than 250 us.""


SuggestedRemedy:
Add the word ""functions"" after the phrase ""spreading and modulation"".  Also, change the order of ""spreading and modulation"" in the text so that it matches the block diagram - should be ""modulation and spreading"".


SuggestedRemedy:
It should read: ""Conversely, the output state is unaltered ...""


Comment:
Add reference for PLME-CCA.confirm primitive.

SuggestedRemedy:
Add ""(Section 6.3.2.2)"" after ""PLME-CCA.confirm"".


SuggestedRemedy:
Add ""(Section 6.5)"" after ""phyCCAMode"".


Comment:
The phrase CSMA/CCA is not consistent with other chapters.


SuggestedRemedy:
Remove ""PN (6.6.2.4)"" and the input arrow that goes with it.


Comment:
The new PN sequence is suboptimum for multipath performance.

SuggestedRemedy:
Change the basic PN sequence used to create the symbol mapping in Table 17.  Simulations are being run by Said and Paul to better understand the relationship between PN selection and multipath performance, and a new PN sequence will be selected.


Comment:
The PIB objects phyCurrentChannel and phyNumChannelsSupported are not referenced in any of the sections.

SuggestedRemedy:
Introduce these attributes in Section 6.2.1.1 by adding the following text to the end of the subclause:""PHY attributes phyCurrentChannel and phyNumChannelsSupported in the PAN Information Base (PIB, Section 6.5) are used to specify the channels used by a compliant device.""


Comment:
The spec lists no restrictions on phyNumChannelsSupported?  For example, must a compliant device support all channels within a given band?  If so, then phyNumChannelsSupported seems unnecessary.

SuggestedRemedy:
Add text to 6.2.1.1 stating that a compliant device must support all channels for a given PHY.  In other words, a 2.4 GHz device must support all 16 channels in the 2.4 GHz band, and a 868/915 MHz device must support all 11 channels across these two bands.  Remove phyNumChannelsSupported if not needed.


Comment:
This section says that the PLME-SET.request is generated by ""upper layers"".   Aren't all PLME primitives generated by the MAC layer (as indicated in 6.3.2)?  Some other PHY primitive sections use this same phrase, ""generated by upper layers"", while others say ""generated by MAC layer"".

SuggestedRemedy:
Change ""generated by upper layers"" to ""generated by the MAC Layer"".  This change is needed in other sections as well.


Comment:
The 2.4 GHz PHY specifies a Transmit PSD mask, but the 868/915 PHY does not.

SuggestedRemedy:
Specify a transmit PSD mask for the 915 MHz band.


SuggestedRemedy:
Add and adjective such as ""raw"" to clarify that these rates do not include inefficiencies, such as packet overhead, etc.


Comment:
Initial output state of differential encoder is not defined.

SuggestedRemedy:
Add text, such as:""When encoding the first input bit, the previous output state is assumed to be zero.""


Comment:
Suggest lower transmit power for compliance reasons.

SuggestedRemedy:
Proposed text,"" ..., however devices may transmit lower power when possible in order to reduce interference to other devices and systems.""


Comment:
Will also be sharing this band with 15.1 and 15.4 devices.

SuggestedRemedy:
proposed text:"" ...sharing this band with other 802.15 wireless PAN, 802.11 wireless LAN, and 802.16 wireless MAN devices.""


Comment:
General comment regarding PHY chapter. Is there a reference to a test document that describes how various spcefications are verified?  For example, Transmit PSD Mask(6.6.3.1) does not specify the averaging period or what data is transmitted when the PSD is measured.  Similar comments can be applied to receiver sensitivity testing.  Should we include a small section on compliance testing that refers to the separate test document?


Comment:
The chapter may read better if sections 6.3 through 6.5 were moved to the end of the chapter, with the order of 6.3 and 6.4 exchanged.  Sections 6.1 and 6.2 start out the chapter by describing radio parameters.  It seems more natural to continue with sections 6.6 through 6.9, which are also radio parameters.  Then we could talk about frame structure, and finally service specifications and PIB (right before the MAC chapter).


Comment:
Should the Data Start-of-Packet delimiter be changed such that there is a hamming distance of 4 between it and the preamble?

SuggestedRemedy:
Choose a new Data Start-of-Packet delimiter with greater hamming distance from preamble.


Comment:
The reference to Peterson (et. al.) within the PHY chapter was removed prior to D13.  Since this is the only reference in the bibliography, we can probably delete Annex D.

SuggestedRemedy:
Delete Annex D unless there are other references to be cited.


SuggestedRemedy:
Change to, ""The effect on receipt of this primitive is not specified within the standard.""


Comment:
Partioning of bits between sync burst flag and packet length is not shown.

SuggestedRemedy:
Subdivide PHY Header column of the table to show sync burst flag is 1 bit and packet length is 7 bits.


Comment:
The receiver jamming resistance is insufficient for some use cases.  Consider the case of a wireless keyboard/mouse.  In a crowded environment such as a classroom, there may be 20 or more networks, all in close proximity.  It is likely that signals from several networks would reach a receiver at about the same level.  For short periods, duty cycle on the networks may be as much as 10 to 20%.  In this situation, a 0 dB jamming spec would result in potential jamming of a signal by signals on 3  channels.

SuggestedRemedy:
Increase the jamming resistance at 5 MHz to 30 dB.  This amount of attenuation could be easily achieved with cheap hardware. The 30 dB attenuation would be sufficient for the keyboard/mouse case, because the desired signal can be assumed to be relatively strong due to the close proximity of receiver and transmitter.  For the case where the imageresponse of the receiver is a concern, an image-balanced mixer could be applied.


Comment:
Same comment as above.  Also, the published spec would be insuffient to meet rules for the European 868 band.   If meeting the standard implies that the unit can be certified anywhere, then the jamming resistance spec must be set to the ETSI requirement.

SuggestedRemedy:
Adjust the spec to the  ETSI requirement.


Comment:
Spec is too tight, making LO noise and phase modulator accuracy into difficult design tasks.  The spec could be relaxed to as much as 40% or more without creating a packet error limit.


Comment:
There is no specification in this section.  If it is informative, it should be moved out of section 6.


Comment:
The frame control field is defined for star networks only.  I would like to see this field defined for cluster tree networks.

SuggestedRemedy:
Change paragraph wording to the following:

Response:
ACCEPT. This field is now called "topology control" and is defined for star topologies and cluster tree topologies, as suggested.


Comment:
Change field name from "Frame Control" to "Frame/Network Control".  Remove "(Star networks only)".

Response:
ACCEPT. The description of this field has been changed to allow the cluster tree topology to use it.  The field has been called "topology control".


Comment:
It is my strong feeling that the TG4 MAC must and shall support at least an optional form of authentication so the netweork that is formed consists only of those devices intended.

SuggestedRemedy:
TG4 needs to look at the authentication mechanism being considered for TG3.  This includes MLME's and corresponding frames that allow a device, via a logical entity know as the Piconet Security Manager, to allow or deny access to a piconet.


Comment:
Clause headings do not follow IEEE Style Guide.

SuggestedRemedy:
Follow the IEEE Style Guide and only capitalize the first word in the clause heading.


Comment:
According to IEEE Style groups of text are referred to as a clause or subclause, not a section

SuggestedRemedy:
Replace the term, section(s), with clause(s) or subclause(s)


Comment:
Scope does not match the scope in the PAR (00/248r4)

Response:
ACCEPT. 

The scope is now the same, the only difference is the tense of the sentence.


Comment:
Purpose does not match purpose in PAR (00/248r4)

Response:
ACCEPT. 

The purpose is now the same, the only difference is the tense of the sentence and the final data rates (250kbps as opposed to 200 kbps and 20 kbps as opposed to 10 kbps).


SuggestedRemedy:
Reverse the listing, that is it should read:Specification and Description Language (SDL)


Comment:
Missing acronyms that appear in the document

SuggestedRemedy:
Add
CH  cluster head
DD  designated device
ED  energy detection
EVM error-vector magnitude
MFR MAC footer
MHR MAC header
PHR physical header
PSD power spectrum density
SPD start of packet delimiter


Response:
ACCEPT. Accepted. Word "Adjacent" used instead


SuggestedRemedy:
Delete the word, "an" before the words, "embedded devices"

Response:
ACCEPT. Accepted and implemented the comment. 

See also comment 216


Comment:
Use of the words, must and should, need to be used consistently and with the proper meanings (see IEEE Standards style manual clause 13.1 for definitions and proper use)

SuggestedRemedy:
The first questionable use occurs (four times) in clause 5.4.2 where I believe the musts really are shalls, otherwise the device is not following the protocol or the protocol will not work.  Change all musts to shalls.


Comment:
First sentence reads awkwards, what does the phase, "on downward" mean?

SuggestedRemedy:
Change "on downward" to "and below (i.e. PHY layer)"


Comment:
The term SPD1 is used, but not defiend until clause 7.

SuggestedRemedy:
Change "SPD1" to SPD orSPD, specifically SPD1


Comment:
The term SPD2 is used, but not defiend until clause 7.

SuggestedRemedy:
Change "SPD2" to SPD orSPD, specifically SPD2


Comment:
The term SPD3 is used, but not defiend until clause 7.

SuggestedRemedy:
Change "SPD3" to SPD or SPD, specifically SPD3


Comment:
Figure not following IEEE standard style manual (see 16.1)

SuggestedRemedy:
Change DATA PACKET and HANDSHAKE to Data Packet and Handshake


Comment:
Clause describes primitives, yet refers to an IEEE Std 802.2-1998, which is not listed in clause 2.  Also ITU-T X.210 is listed in clause 2 for layer service definition conventions.  Do these two documents refer to the same thing, are they the same, or do they contain different an necessary information.  If so...

SuggestedRemedy:
Optionsadd IEEE Std 802.2-1998 to clause 2remove ITU-T X.210 from clause 2 or add ITU-T X.210 to clause 5.5


Comment:
Where is items a) and b)?Either items a) and b) are cropped off the top of the figure, or the items should be re-lettered starting at a), not c)

SuggestedRemedy:
Based on the outcome of the answer to the above question, I hope you can correctly fix the problem.

Response:
ACCEPT. Editors decided to removed this figure out of the draft


Comment:
No text appears in clause 6, therefore not following IEEE standard style manual.

SuggestedRemedy:
At the least add some introductory text describing the clause.


Comment:
No text appears in clause 6.2, therefore not following IEEE standard style manual.

SuggestedRemedy:
At the least add some introductory text describing the subclause.


Comment:
No text appears in clause 6.2.5, therefore not following IEEE standard style manual.


SuggestedRemedy:
Replace reference to Table 1 with Table 2


Comment:
First column heading contains the wrong SAP type


SuggestedRemedy:
Change "to transmit" to "to be transmitted"


SuggestedRemedy:
Change TC to "T subscript C" to agree with term in figure 20


SuggestedRemedy:
Move ", 0<=t<=2Tc" to the right as to uncover the parenthesis


SuggestedRemedy:
At least add text to the clause or renumber subclauses appropriately


SuggestedRemedy:
At least add text for clause or renumber subclauses appropriately


SuggestedRemedy:
Move ", -Tc<=t<=Tc" to the right as to uncover the parenthesis


SuggestedRemedy:
At least add text for clause or renumber subclauses


Comment:
Equation does not follow IEEE Standards Style Manual


Comment:
Is CSMA/CCA mechanism different from CSMA/CA, CSMA-CA, or what is it?

SuggestedRemedy:
Until the answer is known, no suggested remedy can be made other than to have the term clarified to remove confusion.


Comment:
No action is described for the behavior when the status is DISCARD_PACKET, unless storing packet segments at a null memory address is okay.

SuggestedRemedy:
Add the expected behavior for receipt with status=DISCARD_PACKET


Comment:
Consistency in description column for MLME-GET.request


SuggestedRemedy:
Add comma for the if-then sentence after the word, case.


SuggestedRemedy:
Replace last sentence withThe MAC sublayer shall then reallocate any other GTSs, if necessary.


Comment:
An inconsistency with the value of the GTSlength description in table 38 of 7.1.2.6.1 and the text described here.

SuggestedRemedy:
Change the description in table 38 for GTSlength to include the case of the failed GTS allocation due to to large of a request and the response of the GTSlength indicating the maximum GTS slots remaining for allocation.


SuggestedRemedy:
Add packet sequence and packet segment specifier.


Comment:
Informative calculation method is wrong, whether informative or not it should be correct.

SuggestedRemedy:
Remove the extra "x" following the x to the kth power and before the left parenthesis.

Response:
ACCEPT. Changed the misleading "x" to an asterisk character to represent multiplication.


SuggestedRemedy:
Replace "network type" with "addressing mode, network support for GTSs, network topology type"

Response:
ACCEPT. This sentence is extraneous and has been removed.


Comment:
Label in first column is not appropriate


Comment:
There are no units attacked to the value.  A duration usually is in a unit of time (e.g. second)

SuggestedRemedy:
If the unit is time then add it, if not explain what 0.015 is (e.g a fraction of a frame, which could then be measured more appropriately in bits or bytes.)

Response:
ACCEPT. Added a clarification in the text indicating that this value is measured in seconds.


Comment:
Only one subclause is present. This is not allowed as per the IEEE standards style manual

SuggestedRemedy:
Either add another subclause at the same level or remove the subclause heading and make it part of the upper subclause.

Response:
ACCEPT. Changed to make 7.5.2.2.1 part of 7.5.2.2.


Comment:
Consitency among terms wbuff in this text but wBuff in figure 33


Comment:
The MSC is completely wrong.  The figure does not show a fragmented data transmission.  A fragmented data transmission occurs with one MD-DATA.request, followed by many Data/Handshakes.  The Recipicent MAC also does not follow the procedures describe as it is missing the MD-DATA.response indicating where to store the remaining segments.

SuggestedRemedy:
Create a new figure representing the correct behavior for a fragmented data transmission with handshakes or correct the procedures described in the other clauses to reflect the behavior shown in the figure 37

Response:
ACCEPT. The figure has been changed as suggested.


Comment:
If this draft is to be voted on to go to sponser ballot, then all clauses should have contents, or not be present.  Placeholders should only be used for drafts not part of any balloting process.

SuggestedRemedy:
Add the these attached behavior SDLs to fill in this empty Annex.

Response:
ACCEPT. 

David Cypher will help us to add this material in D14


Comment:
If this draft is to be voted on to go to sponser ballot, then all clauses should have contents, or not be present.  As this Annex is marked as normative, then where is the contents?

Response:
ACCEPT. 

David Cypher will help us to develop this Annex


Comment:
Statement states that "a network coordinator shall ensure that any network coordinators ... are awake ..." and only gives an option on how this might be accomplished.  If this is a requirement (shall) then the protocol shall define a standard way of doing this.

SuggestedRemedy:
Add and define a standard (i.e. required) way for doing this function.


Comment:
The fourth parameter is labelled "ppduStrength" while in Table 4, it is labelled "LinkQuality".  This parameter really looks very similar to the EnergyLevel parameter in the PLME-ED.xxx.

SuggestedRemedy:
If ppduStrength and LinkQuality are the same and not the same as EnergyLevel, then use only one term (e.g. LinkQuality).If ppduStrength, LinkQuality, and EnergyLevel are the same, then use only the term EnergyLevel.


Comment:
This clause states that, "The effect on receipt of this primitive by the MAC sublayer is unspecified."  Is this statement made because there is no way to determine whether the psdu returned is to be interpreted as a MA-UNITDATA_indication or a MD-DATA_indication, but rather left as an implementation decision?

SuggestedRemedy:
If this is true, then add a statement to this effect.  For example, "It is unspecified since there are no formal/standarized methods for differentiating the receieved psdu by the MAC as a MA or MD data." If this is not true, then add text either here or in the MAC clause that describes how these two types of data (MD and MA) are differentiated.


SuggestedRemedy:
Change "MD-SAP Primitive" to "PLME-SAP Primitive"


Comment:
There is currently no default or mimimum required number of channels that must be supported.  However, at least one channel must be supported or the protocol will not function.  Therefore I suggest that the value for the phyNumChannelsSupported be one (1) at a minimum.   This would also need to be reflected in the PICS, if one exists.

SuggestedRemedy:
Add text to Table 16 under the description column, that the initial/default/mimimum value is one (1).


Comment:
No default/initial/minimum value is given for the Clear Channel Assessment Mode.  Clause 6.8.10 states that the 802.15.4 Phy shall provide the capability to perform CCA according to at least one of the following five methods.  I would suggest that since the PLME-ED primitive uses Energy Detection (ED) that CCA Mode 1 is the default/fallback/minimum mode to be supported.

SuggestedRemedy:
Add text to Table 16 under the description column for phyCCAMode that the CCA Mode 1 is the default/fallback/minimum/initial value.


Comment:
The data sequence number is stated as being specified by LLC, yet there is no parameter associated with the MD-data.request or MA-Unitdata.request to indicate it.  The Data sequence number is more likely controlled/created by the MAC sublayer, yet no methods are defined for ensuring proper sequencing and interpretations.

SuggestedRemedy:
Either 1) add a parameter to both data request primitives for the data sequence numberor 2) remove this statement and replace it with something like that the data sequence number is maintained by the MAC sublayer and provide the procedures.

Response:
ACCEPT. Following suggestion (2), the statement has been removed and supporting text has been added to explain the use of the data sequence number.


Comment:
The column Beacon address indicates values 16-88 bits, yet the text in clause 7.2.2.2 indicates that it can only take on one of three values:16 bit, 32 bits or 88 bits.

SuggestedRemedy:
Change table to indicate these three values in place of the range.


SuggestedRemedy:
Change Kcps to kc/s and Kbps to kb/s (three changes for each)


Comment:
Extra values with no use explained in the text

SuggestedRemedy:
Remove TRANSACTION_PENDING and NO_BEACON from Valid Range column

Response:
ACCEPT. The use of the TRANSMISSION_PENDING value is now defined in the MD-DATA.request primitive clause.  The NO_BEACON value has been removed from this clause.


Response:
ACCEPT. The use of the TRANSMISSION_PENDING value is now defined in the MA-UNITDATA.request primitive clause.  The NO_BEACON value has been removed from this clause.


Comment:
The Capacity flag is used for short and long frames, yet there is no description of a differentiation or procedures.

SuggestedRemedy:
Remove the capacity flag and mark as reserved.


Comment:
The current draft for TG4 does not address the issue of coexistence with other systems operating in the same band.

SuggestedRemedy:
It is suggested that a clause is added to draft to address the issue of coexistence (including problem description, performance results, and solutions to mitigate interference).


Comment:
The range of the 2.4 PHY (around 10m) seems too short for applications like home automation. This will prevent the 2.4 GHz ( the only global frequency band) devices to enter the consumer market, where the installation is not made by specialists.

SuggestedRemedy:
SuggestedRemedy: Add a lower data rate (via coding) to increase the sensitivity, hence the range.


SuggestedRemedy:
"Table 1 lists the primitives supported..." should refer to Table 2


Comment:
parameters for PD-DATA.indication include ppduStrength


Response:
REJECT.  IEEE Style allows this situation to happen. The team would like to avoid ocurrences for table splitting anyway. The final edition of the draft is edited by the IEEE Standards Editor and they will deal with final manual changes if they think is necessary.


Comment:
What is the algorithm for deriving the value of ppduLinkQuality?

Is "0" good or bad?

SuggestedRemedy:
Some further explanation is needed. Add a reference to clause 6.8.9 which indicates the sense (lower = worse quality), OR move that statement from 6.8.9 to Table 4.


Comment:
What is the algorithm for defining the value of Energy Level?

Is "0" high or low?

How do this figure relate to the energy detection threshold (-75dBm)?

SuggestedRemedy:
Further explanation of the algorithm for defining this value and how this relates to the energy detection threshold is neededAdd a reference to clause 6.8.8 which indicates the sense (lower = lower energy), OR move that statement from 6.8.8 to Table 4.


Comment:
PLM-GET.confirm, along with several other primitives, has only two possible reports: Success, or a single value indicating a general failure (in this case, UNSUPPORTED_ATTRIBUTE). In these cases, the sentence "Otherwise, the status parameter indicates the error." would imply that there are several error report values.

SuggestedRemedy:
Replace "...the error" with "...an error" so that the sentence reads "Otherwise, the status parameter indicates an error."


Comment:
There are 2 error reports (plus a success) for this. "If the PIB attribute could not be set for any reason, the status value will indicate an error." implies that there is only one error report

SuggestedRemedy:
Change "an" to "the" so that the sentence reads "If the PIB attribute could not be set for any reason, the status value will indicate the error."


Comment:
phyNumChannelsSupported: the description for this is not complete. For instance, a value of 1 indicates that, presumably, the PHY can handle the 868 band only, a value of 10 that it can handle 915 band only, a value of 11 shows that the PHY is 868 and 915, 16 means 2.4GHz only, 17 means 2.4 and 868, 26 means 2.4 and 868, 27 means all bands...

Is it also possible to support just part of a band (eg the bottom 8 of 2.4GHz)?

SuggestedRemedy:
two alternatives:a)specify that a PHY covers all channels in a particular band. Then use a 3-bit field to indicate which bands the PHY supports,or:b) is this information really needed? Presumably, a user is not going to swap PHY's and the designer knows what PHY's he's designing for, in which case it doesn't need to be available (dynamically?) in a primitive.


Comment:
This needs a reference back to the relevant general requirements and definitions clause to indicate the conditions (eg PER) for measuring sensitivity.

SuggestedRemedy:
add ", subject to the conditions of clause 6.2.5." after "A compliant device shall have a sensitivity of -85dBm or better"


Comment:
This section is very complex for a lightweight implementation.

SuggestedRemedy:
The main use for this is to identify a free channel. While some of the modes require the (complex) detection of DSSS signals, this will not identify polluted channels (eg from Microwave Ovens and spurii from other transmitters) which would otherwise prevent reliable transmissions. A much simpler approach is to use energy detection only.


Comment:
Incorrect agreement of verb with subject: "... when the upper layers determines the packet to be..."

SuggestedRemedy:
remove the "s" from "determines": "... when the upper layers determine the packet to be..."


Comment:
There is only one error report here, so the use of "the error" is inappropriate

SuggestedRemedy:
Replace "the" by "an" so that the sentence reads: "Otherwise, the status parameter indicates an error."


Comment:
"If it has it shall respond with..." does not read well

SuggestedRemedy:
Improve reading with the addition of a comma after "has": "If it has, it shall respond with..."


Comment:
Incorrect use of participle: "The MAC sublayer shall then reallocating any other GTSs as necessary."

SuggestedRemedy:
Replace "reallocating" by "reallocate": "The MAC sublayer shall then reallocate any other GTSs as necessary."


Comment:
Unclear sentence: "This shall be a new identifier if the GTS has been allocated or the identifier of an existing GTS if it has been deallocated."

SuggestedRemedy:
Add a comma after "allocated": "This shall be a new identifier ifthe GTS has been allocated, or the identifier...."


Comment:
Many addresses (NumDstAddr) will be needed in a cluster tree and DstAddr only allows one address.

SuggestedRemedy:
DstAddr should be a list. This will change line 5 and lines 20-21.

Response:
ACCEPT. Changed as suggested.Changed "DstAddr" to "DstAddrList".


Comment:
Table 53 appears in section 7.2, rather than it the correct section 7.1.3 on the previous page.

SuggestedRemedy:
Control page break so that the Table occurs in it's correct clause.


Comment:
The explanation of the Data Sequence Number Field is wholly inadequate. When is this field incremented?

How is it initialised?

Who is responsible for incrementing the field?

What happens if a handshake is not returned?

Response:
ACCEPT. This section has been clarified as to how the data sequence number is maintained, as suggested.


Comment:
Extraneous comma in sentence "The CRC is calculated using the following standard, generator polynomial of degree 16:"


Comment:
This explains what data should be used for the addressing mode field (and related address) when using cluster tree networks.

What happens when NOT using a cluster tree? Should the data be set to zero, or what?

SuggestedRemedy:
Improve explanation to include what to do when not using a cluster tree.

Response:
ACCEPT. Added paragraph at the end: "If the beacon packet is not being used for cluster tree networks the addressing mode field shall be set to zero.".


Comment:
This clause provides an explanation of the Frame Control Field when using a star newtork. What happens when NOT using a star network?

SuggestedRemedy:
Improve explanation to show what is needed when NOT using a star network


Comment:
No values are specified for macBEMax and macBEMin

SuggestedRemedy:
Specify values for macBEMax and macBEMin


Comment:
macBeaconTxTime: What unit does this use, eg seconds?What time is returned? Absolute time from when? Who is responsible for keeping this time? How and when is it initialised? What tolerance is allowed? What resolution?


Comment:
Says "Master should be ready for the next beacon within macSuperFramePeriod"

Response:
ACCEPT. Changed "master" to "network coordinator" and "macSuperFramePeriod" to "2^n*macBaseFrameDuration".


Comment:
This explanation of allocating a GTS is not complete. Is it possible to allocate the complete frame to GTSs, leaving no contention period? Should there be a minimum contention period under all conditions?

SuggestedRemedy:
Improve explanation to indicate if any mimimum contention period is required (or explicitly state that there is no minimum).


Comment:
This clause specifies that a clear channel is detected by use of the MLME-ED Energy Detection method, in conflict with clause 6.8.10

SuggestedRemedy:
At the very least, make a reference back to clause 6.8.10 so that this clause ties up with the earlier clause.Ideally, decide on the energy detection method and stay with that in both clauses, as the object is to identify an unused or unpolluted channel.


Comment:
This sentence does not read well: "The MAC sublayer transmits the packet using the CSMA-CA algorithm and waits for a handshake from the recipient by starting a timer."

SuggestedRemedy:
"The MAC sublayer transmits the packet using the CSMA-CA algorithm, starts a timer and waits for a handshake from the recipient".


SuggestedRemedy:
Control page breaks so that Fig 53 appears a page earlier in it's correct section.


Comment:
No subject of verb "notes": "Since DSBr is also zero (explained in step 5), and notes that the Data Sequence..."

SuggestedRemedy:
add "the recipient" in place of "and": "Since DSBr is also zero (explained in step 5), the recipient notes that the Data Sequence..."


Comment:
strange word order "worldwide allocated."


SuggestedRemedy:
use lowercase "s" to  indicate time "...averaging time does not exceed 100 ms. The worst case 100 ms..."


SuggestedRemedy:
This should be "Pterp" (subscript terp) to agree with line 21.


SuggestedRemedy:
Force table to be on one page. This may also remove the split in Table 72 as well.

Response:
REJECT.    IEEE Style allows this situation to happen. The team would like to avoid ocurrences for table splitting anyway. The final edition of the draft is edited by the IEEE Standards Editor and they will deal with final manual changes if they think is necessary.


Comment:
the "-" has become disconnected to its "36"

SuggestedRemedy:
Force the "-" to the next line so that it reads "-36 dBm"


Comment:
Incorrect statement: "The MAC sublayer can guarantee the transmission and acknowledgement of data packets across its data service." The rest of the clause details what happens when transmission fails, ie the MAC sublayer cannot actually guarantee transmission and acknowledgement.

SuggestedRemedy:
The MAC sublayer can identify which data packets have not been correctly transmitted, received and handshaked. Therefore, a better sentence is:"The MAC sublayer can identify which data packets have not been successfully transmitted across its data service. Other data packets which are not so identified can be assumed to have been successfully delivered".

Response:
ACCEPT. The first sentence of this section has been reworded around the suggested two sentences.


Comment:
Section "IEEE Std 802.15.4-200x", paragraph 1.Sentence 3 talks about devices requiring time critical or low latency.  Aren't these the same?  Also in sentence 4 I think the words "central gateway or" are not necessary.

SuggestedRemedy:
Remove "or requiring low latencies" from sentence 3.  Remove "central gateway or" from sentence 4.


Comment:
Section "IEEE Std 802.15.4-200x", paragraph 2.

Sentence 2 grammar: "...an 868MHz/915MHz..." instead of "...a 868MHz/915MHz...".


Comment:
Section "IEEE Std 802.15.4-200x", paragraph 2, sentence 3.  I think it is necessary to re-iterate that the data-rates supported are over air and thus do not take into accound the mandatory protocol overhead.

SuggestedRemedy:
Change the sentence to: "The 2.4GHz PHY supports an over air data rate of 250kbps and the 868MHz/915MHz PHY supports an over air data rate of 20kbps."


Comment:
Something a little odd has gone wrong with the Annex entries.  The names of the clauses Annex A and B appear below the name of the Annex.  Also if they are "informative" or "normative" can this appear at the end of the title?

Annex C does not have a title at all.

As Annex D does not exist can we remove it?

The entries for Annex C have too much indentation (TOC entry C.3.1, C.3.2 and C.4.1) - I think the IEEE guidelines only specify level 2 indentation?

SuggestedRemedy:
Check what FrameMaker has done with Annex A and B.

Move the "(Informative)" (Annex A) and "(Normative)" (Annex B) to the end of the Annex title.

Give Annex C a title such as "IEEE 802.15.4 Regulatory Requirements" (and change the title of C.1 to just "Introduction").

Sort out the indentation in the Annex C entries.

Remove Annex D.


SuggestedRemedy:
Line 23: Replace the word "project" with "standard".
Line 23: Add the word "layer" before "(MAC)".
Line 25: change "...in the Personal..." to "...within a Personal..."


SuggestedRemedy:
Line 35/36: swap "low enough" with "power consumption".


SuggestedRemedy:
General: can all the subclauses be alphabetical?

Section 3.20: replace "a LR-WPAN" with "an LR-WPAN" for consitency with the rest of the document.


SuggestedRemedy:
PHY stands for "physical" not "physical layer".

SDL is already defined in clause 3.19.


SuggestedRemedy:
Line 13: replace "...do not require..." with "...do not have the need...".Line 18: Add "Over air" to the start of the bullet.


SuggestedRemedy:
Remove the word "the" from the sentence "A system conforming to the IEEE 802.15.4 consists...".


Comment:
The wording for the peer-peer topology is not quite accurate (line 22+):"This network is ad-hoc, self-organizing and self healing.  It allows multi-hops to route messages..."What is written suggests that an ad hoc, self healing, etc. nature is inherent in this specification when it is actually defined by the network layer.  This needs to be spelled out a little more.

SuggestedRemedy:
Replace the sentences with:"A peer-to-peer network can be ad-hoc, self-organizing and self-healing.  It may also allow multi-hops to route messages...on the network.  Such functionalities can be added at the network layer but are not part of this specification."


SuggestedRemedy:
Line 4: Add the word "However, " to the sentence beginning "The procedure..."

Bullet 4: Use the word "disassociate" rather than "disjoin".


Comment:
This section should be a subsection of 5.2.1.2.  If not it reads as if it is a third topology type when in fact it is a manifestiation of peer-peer.

SuggestedRemedy:
Increase the heading level of section 5.2.1.3 one level to level 5.

Response:
ACCEPT. Duplicate of commentID 404. Accepted and implemented the comment.


SuggestedRemedy:
Line 35: replace "...a physical layer (PHY)..." with "...a physical (PHY) layer...".

Line 36: replace "...the transceiver, a medium..." with "...the transceiver, and a medium...".

Line 42: replace "...implemented as either an embedded devices or as..." with "...implemented either as embedded devices or as...".


SuggestedRemedy:
Missed comma: replace "...physical layer management entity (PLME) accessed..." with "...physical layer management entity (PLME), accessed...".


Comment:
To be consistent with section 5.3.1 this section should also talk about the MLME.In the list of MAC features to support the cluster tree topology, the MAC should be responsible for beacons rather than network beacons (really a star topology concept).

SuggestedRemedy:
Line 23: replace "...MAC management service accessed..." with "...MAC management service interfacing to the MAC layer management entity (MLME), accessed...".Line 31: drop "Network" from the start of the bullet text.


Comment:
This section needs some work to aid its clarity.Also I don't think we need to mention frame durations in this section so they should be removed from the text and Figures 5 and 6.

SuggestedRemedy:
Line 24: replace "The frame is often used in star topology..." with "The frame is mainly used in a star topology...".Line 27: remove the sentence "A frame is 2^n*macBaseFrameDuration seconds...".To be consistent with figure 6, replace the caption with "Frame structure without guaranteed time slots" and remove the axis text "t" and "t+2^n*macBaseFrameDuration" from both figure 5 and 6.Replace the paragraph starting on line 43 with the following:"For low latency applications or applications requiring specific data bandwidth, the network coordinator may allocate portions of the frame that are dedicated to that application.  These portions of the frame are called guaranteed time slots (GTSs) and always appear at the end of the frame, as shown in Figure 6.  The network coordinator may allocate as many of these GTSs as can fit into a frame, at its discretion.  However, it is recommended to leave a sufficient portion of the frame for contention based access of other networked devices or new nodes wishing to join the network.  All contention based transactions must be complete before the first GTS begins.  Also each device transmitting in a GTS must ensure that its transaction is complete before the time of the next GTS or beacon.More information on the frame structure can be found in section 7.2."


Comment:
This section needs some work to aid its clarity.

SuggestedRemedy:
Paragraph 1: add the words "on the network" to the end of the paragraph.

Add the following paragraph after paragraph 1:

"With the exception of the handshake, all packets must be transmitted using a CSMA-CA mechanism to access the channel.  A device using CSMA-CA may only transmit on the channel if it is certain its transmission will not affect any other devices that may be transmitting in its radio sphere of influence."

Paragraph 2: replace the first sentence with:

"For the star topology, there are two types of transactions.  The first is the uplink data transfer in which a network node transmits data to the network coordinator.  The second is the downlink data transfer in which the network coordinator transmits data to a network node."

Remove paragraph 3.


SuggestedRemedy:
Replace paragraph 2 with:

"When a network node wishes to transfer data to the network coordinator in a beacon-enabled network, it first listens for the network beacon.  When the beacon is found, the network node decodes the frame structure information and determines at what point it may transmit its data within the frame.  At the appropriate point, the network node transmits its data packet, using CSMA-CA, to the network coordinator.  The network coordinator acknowledges the successful reception of the data by transmitting a handshake packet.  The transaction is now complete.

This sequence is summarized in Figure 7"

Replace paragraph 3 with:

"When a network node wishes to transfer data to the network coordinator in a non beacon-enabled network, it simply transmits its data packet, using CSMA-CA, to the network coordinator.  The network coordinator acknowledges the successful reception of the data by transmitting a handshake packet.  The transaction is now complete.

This sequence is summarized in Figure 8"


SuggestedRemedy:
Replace paragraph 2 with:
"When the network coordinator wishes to transfer data to a network node in a beacon-enabled network, the coordinator indicates that the data is pending in the network beacon.  The network node periodically listens to the network beacon and, if a message is pending, transmits an upper layer request for the data, using CSMA-CA, to the network coordinator.  The network coordinator acknowledges the successful reception of the data request by transmitting a handshake packet.  The network coordinator follows this by transmitting the pending data packet, using CSMA-CA, to the network node.  The network node acknowledges the successful reception of the data by transmitting a handshake packet.  The transaction is now complete.

This sequence is summarized in Figure 9."

Figure 9: A handshake transfer, "Handshake Packet", needs to be added from the network coordinator to the network node, between "Data Request" and "Data Packet".Replace paragraph 3 with:

"When the network coordinator wishes to transfer data to a network node in a non beacon-enabled network, the coordinator must keep the data until the appropriate network node makes contact and requests the data.  A network node may make contact by transmitting an upper layer poll for data, using CSMA-CA, to the network coordinator at an application defined rate.  The network coordinator acknowledges the successful reception of the poll by transmitting a handshake packet.  If data is pending, the network coordinator transmits the data packet, using CSMA-CA, to the network node, following the poll.  The network node acknowledges the successful reception of the data by transmitting a handshake packet.  The transaction is now complete."

Figure 10: A handshake transfer, "Handshake Packet", needs to be added from the network coordinator to the network node, between "Poll" and "Data Packet".


Comment:
Some slight re-wording of the first bullet point is needed.

SuggestedRemedy:
Replace bullet (1) with:

"A beacon packet, used by an FFD to transmit beacons."


SuggestedRemedy:
Line 20: Change "...beacon packet from the MAC sublayer on downward." to "...beacon packet, which originates from the MAC sublayer."Line 20: Change "Only the network coordinator or cluster head can..." to "Only the FFD can...".Figure 11: Change "MSDU" to "MHR".


Comment:
Some slight re-wording for clarity and necessary changes to figure 12.

SuggestedRemedy:
Change paragraph 1 to:"Figure 12 shows the structure of the data packet, which originates from the upper layers.  The data is contained in the upper layer data packet, here called the LLC layer Protocol Data Unit (LPDU), assuming the device has an LLC layer."Figure 12:  The MAC header (MHR) field should extend to the LPDU not the data sequence number.  The numbers above the MPDU box should be "56 + 8n to 208 + 8n" and those above the PPDU box should be "104 + 8n to 256 + 8n".Line 24: The sentence beginning "The MHR..." should read "The MHR field contains a set of MAC packet control flags, the addressing information for the packet and a packet data sequence number."


SuggestedRemedy:
Change sentence 1 to: "Figure 13 shows the structure of the handshake packet, which originates from the MAC sublayer."


SuggestedRemedy:
Line 29: "...uses a CSMA-CA channel..." rather than "...uses an CSMA-CA channel...".Line 30/31: "If so, the device..." rather than "If the channel is busy, the device...".Line 32: "...without using a CSMA-CA mechanism." rather than "...without a preceding clear channel assessment".


Comment:
Some re-wording of the handshake mechanism is needed.

SuggestedRemedy:
Paragraph 1: Re-word as: "For transfer reliability, a device can request the recipient confirms a successfully received data packet.  If the packet was received successfully, the recipient responds with a handshake packet.  Otherwise, the recipient discards the packet and does not respond at all.  This concept is shown in Figure 14."Figure 14: Use "Handshake Packet" rather than "Handshake".  Use "From Originator" rather than "From Sender".  Use the caption "Handshaking a data packet" rather than "Handshaking".Paragraph 2: Re-word as: If the originator does not receive a handshake after some period, it assumes that the transmission was unsuccessful and reties the packet transmission.  If a handshake is still not received after several retries, the originator can choose either to terminate the transaction or to try again."


Comment:
Some clarity is needed when using N-user and N-layer.

I don't think figure 17 adds anything.

SuggestedRemedy:
Figure 16: Use "Service User (N-user)" rather than "Service User".  Use "Service Provider (N-layer)" rather than "Service Provider".Remove the final paragraph beginning "Figure 17 below..." and figure 17 itself.


Comment:
Need to point out that the PLME-CCA.confirm primitive is not a prerequisite for HANDSHAKE packet types.

SuggestedRemedy:
Change the first sentence beginning "This primitive..." to "If the ppduType is BEACON or DATA, this primitive...".


SuggestedRemedy:
The 4th argument of the PD-DATA.indication primitive should be "ppduLinkQuality" rather than "ppduStrength".


SuggestedRemedy:
PLME-ED.confirm description: "Response to an energy detection request." rather than "Response to a energy detection request.".PLME-GET.confirm description: "Response to the PHY PIB attribute request" rather than "Response to the a PHY PIB attribute request.".PLME-SET.confirm description: "Confirmation of the request to set a PIB attribute." rather than "Confirmation of the set of a PIB parameter.".


Comment:
Clarification of the use of the primitive for different packet types.

SuggestedRemedy:
Change the sentence to "...before transmitting a BEACON or DATA MPDU...".


SuggestedRemedy:
The description of the "status" parameter: should be "The status of the attempt to set the requested PIB attribute.".


Comment:
This section says that the SPDs are "dependent on the data rate of the network".  Is this still true?  If so, where are the SPDs for the other data rates?

SuggestedRemedy:
I think this is an oversight and they are all the same.  The remedy would therefore be to remove ", and are dependent on the data rate of the network" at the end of the first paragraph.


Comment:
The packet length is now included for all packets, not just BEACON and DATA packets as this section suggests.

SuggestedRemedy:
Remove the final sentence: "This field is only valid for beacon and data packets.".


Comment:
Now that there are two interfaces to the LLC and above, how does the system distinguish between the MD-SAP and MA-SAP interfaces?  For example, if a data packet is received is it indicated by the MD-DATA.indication or MA-UNITDATA.indication primitive?

SuggestedRemedy:
As we are stuck with the 802.2 interface, can we utilise some of the fields that are not used for our own purposes?  This would mean less implementation code as long as it is specified correctly.


Comment:
The TxOption 0x04, reply expected is a little misleading as the MAC does not handle replies.

SuggestedRemedy:
Change "reply expected" to "activate receiver on transaction completion".


Comment:
The AddressType field should correctly be of type "bitmap".


Comment:
Final paragraph talks about the reply expected TxOptions.  This needs clarification.

SuggestedRemedy:
Change the paragraph to:"If specified in the TxOptions parameter, the MAC sublayer shall enable its receiver on the completion of the current transaction.  If the TxOptions parameter specifies that a handshake is required, the transaction is complete when a handshake is received.  If the TxOptions parameter specifies that a handshake is not required, the transaction is complete when the data packet is transmitted."


SuggestedRemedy:
Change the paragraph to:"The receipt of this primitive by the MAC sublayer entity shall cause the MLME to retrieve the requested PIB attribute from its database and respond with the MLME-GET.confirm primitive that gives the result.".


SuggestedRemedy:
The final sentence of the final paragraph, use: "reallocate" rather than "reallocating".


Comment:
The description of how to detect a message pending is slightly incorrect and it is best simply to say that the beacon indicates the presence of a message for a device and leave it at that.

SuggestedRemedy:
Remove the last sentence beginning "A message may be pending...".


Comment:
The DstAddr parameter is supposed to contain a list of addresses rather than just a single device address.

The description of the "BeaconType" is not clear.

SuggestedRemedy:
Change this entry to:Name="DstAddrList"Type="List of DstAddr values"Valid Range="N/A"Description="The list of addresses for which the source has data."Explain a little better what the BeaconType is.


Comment:
The descriptions of how the MLME-NODE-NOTIFY.indication and MLME-NODE-NOTIFY.request primitives are used is virually non existent.  Can some more detail be added?

SuggestedRemedy:
Add some more text in these sections, particularly the "When generated" and "Effect on receipt" sections.


Comment:
I'm not sure if this primitive is needed anymore.  It was originally added to enable the reply mechanism in the MAC/LLC.  As this is no longer there and the MAC can "activate the receiver on transaction completion" after an MD-DATA.request do we really need this?

SuggestedRemedy:
This needs to be checked but my feeling is that we can remove this. primitive.


Comment:
The ChannelList parameter talks about a list of channels from the list of available PHY channels.  How will this be done?  Do we refer to them as IDs or frequency offsets?  Where will they be stored?


SuggestedRemedy:
Sentence 1, change "...heard on all available channels." to "...heard on the specified list of channels."Sentence 3, change "...the next available channel..." to "...the next listed channel...".

Response:
ACCEPT. Changed sentence 1 as in comment 186, changed sentence 3 as suggested.


SuggestedRemedy:
Change the description of the NetworkDescriptorSet parameter to "A set of descriptors, one for each network found during the scan."


Comment:
If the MLME-SCAN.confirm primitive will be used for cluster tree networks as well as for stars, the nwid field probably aught to be a BeaconAddress rather than a network identifier, implying a star topology.

SuggestedRemedy:
Change the nwid field as follows:Name="bid"Type="BeaconAddress"Valid Range="Any valid beacon address"Description="The identifier of the detected beacon."


SuggestedRemedy:
Sentence 2, change: "...over the list of alternative channels..." to "...over the list of available channels...".


SuggestedRemedy:
Change the "nwid" parameter in 7.1.2.19.1 and table 50 to "bid".


Comment:
The description of the MAC PPDU may need to be changed for clarity - the BEACON and HANDSHAKE packets contain their configuration data in the MSDU - this information should really be in the header.

SuggestedRemedy:
Each MPDU packet consists of a combination of the following basic components:a) A MAC header (all packets) containing packet formatting, control and addressing information.b) A MAC payload (data packets only) containing the upper layer packet.c) A MAC footer (all packets) containing packet validation information.


Comment:
The BEACON packet is defined as having an MSDU containing all the beacon information.  This is better represented as a header and included in this section, table 54 (from table 62).  All subsections off this section should be changed to reflect this as well.

SuggestedRemedy:
Re-order section 7.2.1 to include the text from section 7.2.2.


Comment:
The HANDSHAKE packet should not have any payload.

SuggestedRemedy:
Change "MAC Payload" to "MAC Header".  Change "MSDU (Data Sequence Number)" to just "Data Sequence Number".


Comment:
Some clarifications needed for handshaking - see remedy.

SuggestedRemedy:
Change: "If this bit is not set, the...handshake from the recipient." to "If this bit is not set, the...handshake and, therefore, the recipient shall not generate or transmit one.Change: "If this bit is set, the...handshake from the recipient." to "If this bit is set, the...handshake and, therefore, the recipient shall generate and transmit a handshake packet on receipt of a valid packet."

Response:
ACCEPT. Essentially changed as suggested but reworded the section.


Comment:
The description may now need to change as a previous comment suggested having an MSDU only for the data packet.

SuggestedRemedy:
Change the first sentence to: "The MSDU carries the upper layer packet." and remove all other sentences.


Comment:
The description of how to compute the checksum appears to be a little hard to understand.  I think we need something pretty well defined in here as the CRC is rather crucial to the operation of the protocol from different vendors!  A slight difference will make interoperability impossible!

SuggestedRemedy:
I would look at Andrew Tanenbaum's book, "Computer Networks".  It has some details on computing CRCs.


Comment:
The address list field is not actually option it is rather dependent on the previous address pending specification field.


SuggestedRemedy:
Change the first sentence from "...sub-fields: network type..." to "sub-fields: addressing mode, network support for GTSs, network type...".


SuggestedRemedy:
Change from "This field is only valid..." to:"This field is used only for cluster tree networks.  If this bit is not set, the beacon address field shall contain a short, allocated 8-bit device address.  If this bit is set, the beacon address field shall contain an extemded (IEEE) 64-bit device address."


SuggestedRemedy:
Change the last two sentences to:"If this bit is not set, the network coordinator shall not support GTSs on its network.  If this bit is set, the network coordinator shall support GTSs on its network."


SuggestedRemedy:
Change "The frame order...shall be defined as follows." to "The frame order is four bits in length and specifies how often the beaconb shall be transmitted.  If n is the frame order, the beacon period, t, shall be defined as follows."

Response:
ACCEPT. This section has been reworded for clarity.


Comment:
I do not think that the capacity flag will ever be used.  Its purpose was to limit the amount of traffic on the network by not permitting a device to transmit longer than some small number of bytes.  The policing of this, however, would be very difficult and it would also require a MAC segmentation facility (see later comments).  I would propose therefore that we remove it.

SuggestedRemedy:
Remove the capacity flag from the first paragraph, table 64 (marking bit 7 as reserved) and section 7.2.2.3.1.


Comment:
The concept of extending a beacon for multicast transmissions has not really been persued a great deal but we should probably leave it for now.  The text needs some editorials, however.

SuggestedRemedy:
Change "...the current beacon packet has not been extended." to "...the current beacon packet shall not be extended.".Change "...shall remain in receive mode for the following..." to "shall remain in receive mode for a following...".


Comment:
The connection permit flag is set according to a value in the MAC PIB (that isn't defined).  Consequently, the text needs some ammendments.

SuggestedRemedy:
Change "...during the current frame." to "...during the current frame, according to the macConnectionPermit PIB entry.".Make the next two sentences beginning "The network coordinator..." a new paragraph.Change "If this bit is not set, a device may not..." to "If this bit is not set, a device shall not...".

Response:
ACCEPT. This frame control field has been changed to be more general and is called the topology control field.  This field is filled with the value of a corresponding MAC PIB attribute.  The suggestion on shalls vs. mays has been accepted.


SuggestedRemedy:
Change "If this value is >= 22, the contention period covers the entire frame." to "If this value is >= 22, the contention period shall cover the entire frame."Change "If this value is zero, a device may only transmit within the frame if it has previously been allocated a logical channel." to "If this value is zero, a device shall only transmit within the frame if it has previously been allocated a GTS."


SuggestedRemedy:
Paragraph 1: change "...appropriate bit of the zone's specification field..." to "...appropriate bit of the zone specification field...".Paragraph 3: change "...and being denied." to "...when no data is actually pending.".


SuggestedRemedy:
Paragraph 3: remove "base" from: "All GTSs are positioned at the end of the base frame.".Paragraph 4: remove "base" from: "Each base frame shall be divided...".Paragraph 4, final sentence: remove duplicate "of the".Section 7.3.1: change "...start of each frame." to "...start of each frame, providing the macFrameOrder PIB entry is <= 14.".


Comment:
Defaults, ranges, incorrect types and new entries required.

SuggestedRemedy:
Entry "macBeaconSearchSlots", type="unsigned integer constant", add "This value shall be 28.".Entry "macBeaconTrackSlots", type="unsigned integer constant", add "This value shall be 22.".Add entry: managed object="macConnectionPermit", identifier="mCP", type="Boolean", description="A flag representing the connection status of the network coordinator.  This value is TRUE to allow decices to join the network or FALSE to forbit devices to join the network.  This value defaults to FALSE.".Entry "macGTSLength": add "This value shall be in the range 0 to 23 and defaults to 0.".Entry "macGTSStartSlot": add "This value shall be in the range 0 to 23 and defaults to 0.".Entry "macMaxCSMARetries": type="unsignee integer constant".Entry "macHandshakeWaitDuration": type="real constant", remove the text "(measured in slot periods)".  Add "This value shall be 0.03s.".Remove entry "macMaxFrameSize".Entry "macMaxLostBeacons": type="unsigned integer constant", add "This value shall be 4.".Entry "macMaxPacketRetries": type="unsigned integer constant", change "The default value shall be 3." to "This value shall be 3.".Entry "macMaxPacketSize": type="unsigned integer constant", change the text "(phyMaxPacketSize + 26)" to "(phyMaxPacketSize - 26)".Entry "macNetworkID": add "The default value shall be 0x0000".Entry "macNumFramesBeforeSnooze": type="unsigned integer constant", change "The number of frames before the..." to "The number of frames of no activity before the...".Entry "macFrameOrder": type="unsigned integer".Entry "macUniqueAddress": Change "The address assigned to the device." to "The 64-bit (IEEE) address assigned to the device.".

Response:
ACCEPT. Where the fields remained from earlier comments, changed as suggested.


SuggestedRemedy:
Change "All devices must use the radio..." to "All devices shall use the radio...".Change "If activity is detected the device should back-off..." to "If activity is detected the device shall back-off...".Change "...number of times may not transmit its message regardless but should consider..." to "number of times shall not transmit its message regardless but shall consider...".Change "All transmission should abide..." to "All transmissions, except for handshakes, shall abide...".


SuggestedRemedy:
Step 1: change "...sublayer initializes a variable..." to "...sublayer shall initialize a variable...".Step 2: change "...sublayer will backoff..." to "...sublayer shall backoff...".Step 3: change "The MAC then issues a clear...idle then the MAC can transmit..." to "The MAC shall then issue a clear...idle then the MAC shall transmit...".Step 4: change "...the number of retry attempts, Nr, is incremented...exponent, BE, is also incremented...this case, the MAC sublayer must inform the higher...the MAC sublayer must delay..." to "...the number of retry attempts, Nr, shall be incremented...exponent, BE, shall also be incremented...this case, the MAC sublayer shall inform the higher...the MAC sublayer shall delay..."


SuggestedRemedy:
Step 2: change "The PHY layer shall respond...back-off period defined in previous section..." to "The PHY layer will respond...backoff period defined in the previous section...".


SuggestedRemedy:
Change "Master" to "Network coordinator" at all three points.Change "macSuperFramePeriod" to 2^n*macBaseFrameDuration".


SuggestedRemedy:
Paragraph 1: change "...synchronization is only permitted..." to "...synchronization shall only be permitted...".Paragraph 2: change "...search for a single frame duration." to "...search for at most macBeaconSearchSlots slots.".Paragraph 4: change "...enabling its receiver just before...next frame in order to receive the beacon." to "enabling its receiver macBeaconTrackSlots slots after the beacon was received, i.e. just before...next frame, in order to receive the beacon.".


Comment:
Editorials - see remedy.Paragraph 2, the synchronization "as described above" probably needs to be spelled out - synchronisation as defined cannot achieve searching as it is meant here.

SuggestedRemedy:
Change "Network searching is only permitted..." to "Network searching shall only be permitted...".Need to think a bit more how searching would be achieved.


SuggestedRemedy:
Final paragraph: change "...by setting the TxInGTS bit of..." to "...by setting the appropriate bit of...".


SuggestedRemedy:
Paragraph 2: change "...three allocated GTS, starting..." to "...three allocated GTSs, starting...".Figure 29: change "super-frame" to "frame".


SuggestedRemedy:
Paragraph 1: change "macMaxHandshakeWaitDuration" to "macHandshakeWaitDuration".Section 7.5.6.1, step 3, change "macMaxHandshakeWaitDuration" to "macHandshakeWaitDuration".Section 7.5.6.2, change "macMaxHandshakeWaitPeriod" to "macHandshakeWaitDuration" in all three scenarios.Scenario 1: change "...passes on the packet to upper layers." to "...passes on the packet to the upper layers.Figure 31, change "Recipient LLC" to "Originator LLC".

Response:
ACCEPT. Changed as suggested with exception of using the term "Ack" in place of "Handshake"


Comment:
I do not think that packet fragmentation should be part of this standard.  

The PHY can only transmit a finite amount of data (phyMaxPacketSize which is PHY dependent) and so the MAC will only give the PHY as much data as it can handle.  Similarly, the MAC will only accept macMaxPacketSize bytes (which, in turn, depends on phyMaxPacketSize) from the upper layers.  Why then would the MAC have a need to segment the data?

If an application wishes to send more data than allowed by the MAC, it will have to segment it itself BEFORE passing it to the MAC.  Consequently, the segmentation will have to be performed by the higher layers anyway.  Why implement it twice?  As segmentation is actually a transport layer task it does not seem logical to have it in the MAC at all.

This, of course, has impacts very nicely on the 15.4 spec as we can cut out quite a lot of stuff!!

SuggestedRemedy:
Do not allow fragmentation.  The following adjustments are required:Section 5.4.5.4, page 22: remove this section.Section 7, page 49: remove the final bullet beginning "Segmentation of the data...".Table 57, page 76: remove the text for bits 3, 2 and 1.Section 7.2.1.1.5, page 77: remove this section.Section 7.2.1.1.6, page 78: remove this section.Table 69, page 88: remove the final row.Section 7.5.6, page 95: remove the paragraph beginning "In the case of a multiple...".Section 7.5.7, page 97: remove this section.Section 7.5.7.1, page 98: remove this section.Section 7.5.7.2, page 99: remove this section.Section 7.5.7.3, page 100: remove this section.Figure 33, page 101: remove this figure.Figure 34, page 102: remove this figure.Section 7.5.8.3, page 104: remove this section.

Response:
REJECT.  The group decided that fragmentation was an essential part of the 15.4 MAC, despite the suggested argument against it.


Comment:
It would be extremely useful to have a "packet following" feature in the protocol.  This would be different from the rest in that for downlink transfers (from the coordinator) a device does not need to request every packet before receiving it.  The packet could simply be transmitted with a flag set indicating that once the handshake is sent, the device must re-enable its receiver for the next packet.This would also be essential to allow segmentation to be performed at the upper layers.

SuggestedRemedy:
The flag itself could replace some of the flags used for segmentation in the Packet Control field.  A data request would have an extra bit in its TxOptions to indicate the fact.


Comment:
We have done some analysis of timings in the system and have come to the conclusion that some transfers will require a good portion of time to complete.  One example would be the mechanism by which downlink data is requested before being sent.  Consequently, it would be nice to be able to have some packets defined in the standard that contained information only useful by the MAC itself.  That way the MAC could insigate the transmissions and react to the response without having to go right through the stack.

SuggestedRemedy:
We could have a bit in the Packet Control field to indicate a MAC packet and process it differently.The set of MAC packets would then have to be defined and their use specified.


Comment:
Currently the MAC PIB entry macMaxPacketSize is defined to be phyMaxPacketSize - 26.  This overhead (26) is computed from the worst case addressing mode (extended cluster tree).  Can we define this a little better so that the maximum packet size is computed dynamically based on the packet type.  For example, if a packet were transmitted using short star addressing, it should be able to handle more payload than an extended cluster tree.

SuggestedRemedy:
In its simplest form we could just define two macMaxPacketSize values: one for star worst case and the other for cluster tree worst case.  This would help but perhaps there is a more efficient way of doing this...?


Comment:
Some tables/figures are not referenced in the text.

SuggestedRemedy:
Table 2, page 28: change "Table 1" to "Table 2" - bad reference.
Table 3, page 28: add in preceding text "Table 3 specifies the parameters for the PD-DATA.request primitive.".
Table 4, page 29: add in preceding text "Table 4 specifies the parameters for the PD-DATA.indicate primitive.".
Table 6, page 31: add in preceding text "Table 6 specifies the parameters for the PLME-CCA.confirm primitive.".
Table 7, page 32: add in preceding text "Table 7 specifies the parameters for the PLME-ED.confirm primitive.".
Table 8, page 33: add in preceding text "Table 8 specifies the parameters for the PLME-GET.request primitive.".
Table 9, page 33: add in preceding text "Table 9 specifies the parameters for the PLME-GET.confirm primitive.".
Table 10, page 34: add in preceding text "Table 10 specifies the parameters for the PLME-RX-ENABLE.request primitive.".
Table 11, page 35: add in preceding text "Table 11 specifies the parameters for the PLME-SET.request primitive.".
Table 12, page 35: add in preceding text "Table 12 specifies the parameters for the PLME-SET.confirm primitive.".  Change the caption from "PM-SET.confirm..." to "PLME-SET.confirm...".
Table 13, page 36: add in preceding text "Table 13 shows a description of the PHY enumeration values.".
Figure 19, page 38: add in preceding text ", as illustrated in figure 19.".
Figure 20, page 40: change in preceding text "figure 21" to "figure 20" - bad reference.
Table 20, page 42: add a reference in preceding text.
Figure 23, page 45: add a reference in preceding text.
Table 34, page 60: add to preceding text "Table 34 specifies the parameters for the MLME-ED.confirm primitive.".
Table 41, page 66: add to preceding text "Table 41 specifies the parameters for the MLME-NODE-NOTIFY.indication primitive.".
Table 42, page 67: add to preceding text "Table 42 specifies the parameters for the MLME-NODE-NOTIFY.request primitive.".
Figure 28, page 92: change in the preceding text "Table 28" to "Figure 28".
Table 77, page 118: change in the preceding text "The Table..." to "Table 77...".


Comment:
There are a lot of period (.) characters missing in the text, especially in tables and bullet points.

SuggestedRemedy:
Section 3.10, page 5, line 28: add period.
Section 5.3.2, page 14, lines 31, 41 and 45: add period.
Table 2, page 28: add periods in all three rows.
Table 3, page 28: add period in first row.
Table 4, page 29/30: add periods in all four rows.
Table 5, page 30: add period in rows 3 and 5.
Table 6, page 31: add period in row 1.
Table 7, page 32: add period in row 1.
Table 8, page 33: add period in row 1.
Table 11, page 35: add period in row 1.
Table 25, page 51: add period in row 1.
Table 28, page 53: add period in row 1.
Table 31, page 56: add period in row 1.
Table 33, page 58/59: add period in rows 9-22.
Table 34, page 60: add period in row 1.
Table 48, page 71: add period in rows 1 and 2.
Table 49, page 72: add period in rows 1 and 2.
Table 70, page 109: add period in rows 2, 4 and 5.
Table 71, page 111: add period in all occupied rows.
Table 74, page 114: add period in rows 2, 3, 4 (twice), 5-7.


Comment:
Should we really be refering to "point-point" rather than "peer-peer" network topologies throughout?


Comment:
We currently are quite snug with the packet format and have no scope for expansion in the future.  If we decide to drop segmentation this will make things easier but if not we may need to consider extending the packet structure for future use.

SuggestedRemedy:
Split the packet control field into 2 bytes.  One for packet control the other for address control.  This should leave quite a lot of free bytes for the future.  We may also be able to merge the normalise some parts of the beacon packet in this way as well.


Comment:
The description of the PIB entry phyMaxPacketSize is not quite worded correctly and is also restrictive for a 2.4GHz PHY implementation that is able to support more than 58 bytes in the PSDU.

SuggestedRemedy:
Reword the description as:"The number of bytes the PHY shall be able to receive.This value shall be >= 58 and <= 127.".In this way a PHY implementation must be able to support the transfer of 58 byte PSDUs (and this can be part of the conformance test) but also has the option to support more if possible.We therefore no longer need any PHY specific text.


Comment:
The term "IEEE" is reserved for approved standards only.

SuggestedRemedy:
Remove "IEEE" from the designation "IEEE Draft P802.15.4/D13" in the runningheads and the title.  The title should also say "Draft Part 15.4: Wireless..."

Response:
ACCEPT. 

All the "IEEE" words from the running heads were removed
Title modified as suggested


Comment:
Why is the term "IEEE-SA Standards Board" used on the title page?


Comment:
The term "868MHz/915MHz" in the following sentences "The physical layer may be implemented in one of three alternate frequency bands depending on local regulations and user preference.  This standard specifies a 868MHz/915MHz direct sequence spread spectrum and a 2.4GHz direct sequence spread spectrum PHY." is unclear.

SuggestedRemedy:
Modify the term to "868 MHz or 915 MHz" (or something similar) to clearly delineate there are three (3) unique PHYs.  It reads like two (2) not three (3) PHYs.

Response:
>>>> Waiting information from Paul about "framing" the two PHYs
>>>> Waiting for reply from Ian em sent on 01-30


Comment:
The name of the IEEE-SA Project Editor is known and TG4 should be actively working with her (there are many edits in the FrontMatter); she can be reached at j.longman@ieee.org and/or +1 732 562 6355.

SuggestedRemedy:
Add and center the name to the title as follows:

Jennifer McClain Longman
IEEE Standards Project Editor


Comment:
The Table of Contents (TOC) is incorrectly added into 802.15.4/D13.

SuggestedRemedy:
The Editor-in-Chief needs to create the TOC and then cut-n-paste the TOC to the end of the FrontMatter.  The title "Contents" is added as a new page to the FrontMatter and is a permanent part of the draft.  Then during each successive draft the TOC detail is appended below the title.  Therefore, creating pages ix-x (D13 specific) vs pages 1-2.


Comment:
Note: The D13 has 2 sets of pages 1-2!

The TOC is created differently than 802.15.1-3 and I suggest that we try to keep the 802.15 drafts similar where possible.

SuggestedRemedy:
I recommend the following edits to the TOC:
-Title should be (s/b) "Contents" vs. "Content"
-The FM contents and the PDF Bookmarks need to match
-The H1 or 1. title s/b trailed by............ vs. nothing
-The Clauses s/b H1-H3 deep i.e., 1, 1.1, 1.1.1 vs. 1 & 1.1
-The Annex s/b AH1-AH3 deep i.e., A1, A1.1, A1.1.1 vs. A1

Note: I can help you do this; it is somewhat tricky working in FM6 and converting to PDF via Acrobat Distiller.

Response:
ACCEPT. 

Commenter defers to the opinion of J. Longman


Comment:
Note: The D13 has 2 sets of pages 1-2!

The Clause 1 title is incorrect.

SuggestedRemedy:
The Editor needs to copy the title page onto the Clause 1 as a title.  For example:

Draft Standard for Information technology
Telecommunications and information exchange between systems
Local and metropolitan area networks
Specific requirements
Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Low Rate Wireless Personal Area Networks (LR-WPANs)


Comment:
The symbol for kilobit per second is kb/s, not kbps.  The symbol for megabit per second is Mb/s, not Mbps.  The first usage is "250kbps" in sentence "The 2.4GHz PHY supports a data rate of 250kbps and 868/915MHz PHY supports a data rate of 20kbps."

Response:
>>>> Will do it after I gather all the files from the team

ACCEPT.


Comment:
The use of shall/should/may/can/will/must throughout the document needs to used in accordance with IEEE's style.

SuggestedRemedy:
Review the use of shall/should/may/can/will/must throughout the document to be sure they are used in accordance with IEEE's style.


Comment:
The use of Figure 1 brings up the question how will the 802.15 WG depict the 802 Family as they introduce a 2nd (and 3rd) MAC sublayer to the traditional figure (see 802.15.1/D1.0.1 Figure 1)?

 It is important that the WG communicate their Projects and their distinct identities, one solution per problem, etc. This frontmatter subclause should be short but concise such that the 802.15.xx designations are clear to the public. The titles are clear now the figure 1 and resultant description of Fig 1 should be modified to communicate our mutiplicity of projects.

SuggestedRemedy:
I suggest that the Editor submit a modified Figure 1 and some minimal text so that the WG can review and comment.

Response:
Marco reqd some info from Ian. See e-mail from Marco to Ian on 01-30


Comment:
The acronym "MLME MAC layer management entity" uses incorrect definition. The Medium Access Control refers to a sublayer of the Data Link Layer and is not a layer.

SuggestedRemedy:
I suggest the term "sublayer" be used or "MLME MAC sublayer management entity".


Comment:
The introductory list uses a non standard format.  The Editor should refer to the IEEE Standards Style Manual.

SuggestedRemedy:
The unordered list should be changed to a dashed list, etc. (see IEEE FM6 template).  

Also, I suggest the Clause 5 subclause numbering start right after the "5. General Description" on line 1 w/ an entry such as "5.1 Introduction".

Response:
>>>>Need to make the change to "dashed list" in the whole document.

ACCEPT. 



The 5.1 issues solved


Comment:
The text that describes the components of the IEEE 802.15.4 WPAN is clear but I was expecting a figure that depicted the components of the WPAN being described.

SuggestedRemedy:
I suggest a figure be created and added that depicts the components of the IEEE 802.15.4 WPAN.

Response:
>>>> Waiting for complete draft to make sure the picture numbers are Ok.
>>>> Waiting for Marco's answer on the addition of apps picture. See comments from Ian Gifford in D14 subdirectory

ACCEPT

I sent this comment to Ian:

Draft 13 contains Figure 1 (it should be Figure 2) on page 10 that describes the components of a LR-WPAN in two different components. Does this address your comment? If it does not, could you please give some guidance on the content of this figure?

Ian recomments reviewing the following document
Refer to IEEE Std 802.15.1/D1.0.1 subclause 6.3, page 25, Figure 6.  Up to you.


Comment:
The Editor has introduced a second Figure 1 (the first is in FrontMatter) which should be Figure 2 in D13.  There are multiple xref instances to this figure.

SuggestedRemedy:
Change FrameMaker paragraph tag figure numbering to correct this error.  The Editor is cautioned to verify that all clause Figures and Tables are sequentially updated and that there are no duplicates.


Comment:
Figure 2 is hard to read on the screen and printed it is likely to be no better.

SuggestedRemedy:
One solution is that the Editor can increase the figure size and rotate it 90 deg to the left and force it to be on a single page by itself.  Up to the Project.


Comment:
The term "Section" in sentence "Section 6 contains the specifications for the PHY layer." is incorrect.

SuggestedRemedy:
The sentence should read "Clause 6 contains the specifications for the PHY layer."


Comment:
The sentence "The radio shall operate at one of the following licence free bands:" and then the list of center frequencies is confusing in this context.  The bullet list should be changed to an IEEE Style e.g., ordered (alpha, numeric, etc.) or unordered (dashed, etc.)

SuggestedRemedy:
I suggest the Editor use 915 ± 13 MHz or 902-928 MHz, etc. and then correct the text to correspond to the change.  Finally, correct the list to comply to IEEE Standards Style Manual conventions.


Comment:
The term "Section" in sentence "Section 7 contains the specifications for the MAC sublayer." is incorrect.

SuggestedRemedy:
The sentence should read "Clause 7 contains the specifications for the MAC sublayer."  Note: Correct this incorrect word usage globally.


Comment:
The term "section" in sentence "This section provides a brief overview of..." is incorrect.

SuggestedRemedy:
The sentence should read "This clause [or use subclause] provides a brief overview of..."  Note: Correct this incorrect word usage globally.


Comment:
The clause title "5. General Description" is incorrect.

SuggestedRemedy:
The Editor should change the title to "5. General description".  The first word is capitalized (upper case) and the subsequent words are lower case.  Note: Correct this incorrect capitalization usage globally.


Comment:
The reference to Table 1 in sentence "Table 1 lists the primitives supported by..." is incorrect.

SuggestedRemedy:
I suggest the Editor change it to Table 2 via the /Special/Cross-Reference/ Paragraph Tag Format.


Comment:
The xref format "(See 6.3.1.1 on Page 28)" is non standard.

SuggestedRemedy:
I suggest the Editor change the xref to (See 6.3.1.1) via the /Special/Cross-Reference/ Paragraph Tag Format.  Deleting "on Page 28"; refer to the IEEE Standards Style Manual and the IEEE-SA Project Editor.  Note: Correct this incorrect xref usage globally.


Comment:
All things being the same the usage of footnotes is not recommended.  The issue is that "...footnotes are not officially a part of the standard."

SuggestedRemedy:
Optional comment this is just a suggestion.  The Editor could move the footnote to a "Note that..." entry.  E.g., Note that code position modulation has also been referred to in the literature as code-phase shift keying.


Comment:
In this subclause there are two (2) unordered lists but they are incorrectly used from an IEEE Standards Style Manual point of view.

SuggestedRemedy:
I suggest the Editor change the first unorded "bullet" list to the standard IEEE FM template DL, DashedList.  The second unordered "alphabetical" list be changed to the standard IEEE FM template L1,LetteredList.


Comment:
The xref format "(see Table 63 on Page 81)" is non standard.

SuggestedRemedy:
I suggest the Editor change the xref to (See Table 63) via the /Special/Cross-Reference/ Paragraph Tag Format.  Deleting "on Page 81"; refer to the IEEE Standards Style Manual and the IEEE-SA Project Editor.


SuggestedRemedy:
I suggest the Editor use the figure tag vs. the table tag; that should call up Figure 28 vs. Table 28.

Response:
ACCEPT.  Changed "Table 28" to "Figure 28".


Comment:
Are there any outstanding permission issues with the Zigbee SIG concerning figures, tables, text, trademarks, etc?

SuggestedRemedy:
The Project 802.15.4 and/or 802.15 Working Group will need to provide IEEE-SA clean reproducible-quality figures in electronic format (preferably TIFF or EPS format.) If figures were derived or obtained from sources other than the Working Group itself, please obtain and supply permission from the appropriate sources.

Response:
REJECT. 

This is out of the scope of this standard.  

However, the team communicated with the Zigbee leadership and there are no permissions issues with the actual material in the draft.


Comment:
The Editor has used a variety of font sizes e.g., on page iii from Introduction to just before unorderd list there is a small i.e., 8 or 9 pt font then the standard 10pt New Times Roman is used.

SuggestedRemedy:
I suggest you stick with one font size (as much as possible); I suggest the standard 10pt New Times Roman.


Comment:
The Editor can make chnages in FrameMaker and the empty pages can be eliminated and/or reduced significantly.

SuggestedRemedy:
I suggest the Editor look Format/Page Layout/Pagination/ choose Before Saving & Printing, Delete Empty Pages.  I can help if you need assistance.


Comment:
Is GTS/CFP really needed for the LR-WPAN?

Response:
ACCEPT. Yes, it is necessary, Read Clause 5 in detail


Comment:
IEEE802.15.4 does not look less complex than IEEE802.15.1. How can it be cheaper?


Comment:
The standard does not sufficiently address the issue of wireless coexistence.

SuggestedRemedy:
A clause on coexistence needs to be added to the 802.15.4 standard.  The clause should include, at a minimum, the following sub-clauses:1. A sub-clause listing which wireless 802 networks are approved for operation in the same location as an 802.15.4 WPAN, and which are not approved for operation in the same location as an 802.15.4 WPAN.2. A sub-clause quantifying the performance of an 802.15.4 WPAN that a user can expect, in the presence of the various approved wireless 802 networks.3. A sub-clause quantifying the performance of the various approved wireless 802 networks that a user can expect, in the presence of an 802.15.4 network.


Comment:
Only 2 topologies mentioned, but 3 are discussed in the following sections.

SuggestedRemedy:
Need to include Cluster-Tree Networks in the intro section.


Comment:
Figure should include LLC as separate (light gray) box to make an easier transition to figure 4.

Response:
ACCEPT. Accepted comment, was resolved by comment #47.


Comment:
Annex A Specification and Description Language (SDL) was not provided for voter comment and review.

SuggestedRemedy:
Povide Annex A content, SDL for voter comment and review

Response:
ACCEPT. 

David Cypher will help us add these sections


Comment:
Annex B Protocol Implementation Conformance Statement was not provided for voter comment and review.

SuggestedRemedy:
Povide Annex B content, PICS for voter comment and review

Response:
ACCEPT. 

David Cypher will help us add this material


SuggestedRemedy:
Response to the PHY PIB attribute request.


Comment:
In description of the phyNumChannelsSupported

SuggestedRemedy:
Seems that you'd need a range to support for example just the 2.4 GHz PHY.  Just putting in the number of channels doesn't indicate that the PHY only does 2.4 GHz. Channel    Freq0          868.3 MHz1 to 10    900 MHz11 to 26   2.4 GHz


# TypeList

TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In("C", "Z")


TypeList:
[CommentType] = "TR" AND [ResponseStatus] = "W"  AND [CommentStatus] In ("A","R")

Header:
Thank you for your participation in the recent IEEE 802.3ae ballot. We have received your ballot.
not yet received an email from you confirming your reaction to the committee's 
proposed responses to your comments. Please take the time to let us know, 
for each item, whether each response, in your judgement, satisfactorily 
resolves your comment(s). 

If you would like, you may simply insert the word APPROVE, or DISAPPROVE, 
next to each comment and return this file.  That is all that is required.

In those instances where you indicate that you APPROVE or DISAPPROVE the committee's 
proposed response, our records will be updated. In those instances where you 
do not indicate a response, your vote will stand as previously submitted.

Thank you for your assistance.

Sincerely,
Dr. Howard Johnson, 
Chief Technical Editor of IEEE P802.3z Gigabit Ethernet

----**<copy of proposed committee responses attached>**----
>
>


TypeList:
[CommentType] In ("T","E") AND [CommentStatus] In ("A","R") AND [ResponseStatus] In ("W")

Comment:
The report "close T and E" will change these response statuses to "C"


TypeList:
[CommentType] In("TR") AND [ResponseStatus] Not In ("C","Z")


