# Main

Comment:
The sentence 'The standard uses carrier sense multiple access with collision avoidance medium access mechanism and supports star as well as peer-to-peer topologies.' is grammatically incorrect.

SuggestedRemedy:
I suggest you change to 'The standard uses carrier sense multiple access with a collision avoidance medium access mechanism and supports star as well as peer-to-peer topologies.' adding 'a' after with.


Comment:
The FrontMatter page numbers are missing from i-ix.

SuggestedRemedy:
I suggest you add the page numbers i-ix.

Response:
ACCEPT. 

Draft changed as proposed by the comment


Comment:
The running footer 'Copyright © 2002 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change' is incorrect.

SuggestedRemedy:
I suggest you edit the footer to be all the same size font point.


Comment:
The text 'Satish K. Aggarwal, NRC Representative...' is not centered.


Comment:
It is easy for anybody to see the need for low power devices supported by this standard. But what is not clear is why a simplified version of work done by an already progressing TG could not be adopted. It is fair to mention the work of 802.15.3 of the same WG in this context. The concepts involved, like association, authentication, security, GTS etc. are more or less same in both the TGs. If the argument is going to be that the 802.15.3 is not ready it is simply because of the following reason. Even though when 802.15.4 started within 802.15 WG, 802.15.3 in the same WG had already decided the MAC-PHY and had also decided the direction for its refinements, the design in 802.15.3 is being done rigorously while the same in 802.15.4 is not. A proof to this is that, the draft subimitted for LB13 did not even have elementary concepts like association defined within the standard, but instead relied on standard enforcing group to define them. When it was commented during LB13 those conepts were borrowed from 802.15.3 but in a mangled fashion. The same story goes with the security. Another proof is the number of comments submitted by the 802.15 WG to letter ballots of 802.15.3 and 802.15.4 drafts. While 802.15.3 received lot of constructive comments from vast majority of 802.15 voters in multiple, succesful letter ballots resulting in betterment of the draft, comments for 802.15.4 were by a handful of voters. Rest of the voters either abstained or simply voted yes as if to avoid losing voting rights, without even looking at the rampant disconnects and missing definitions in the draft. It is worth mentioning that there is already enough confusion in the market caused due to the multiple IEEE wireless standards. One might argue that the reason for multiple wireless standards has the noble intention of supporting different sets of applications and/or scenarios. That is true, but the confusion in the minds of end user today is definite and non-arguable. And it is also a well known fact that the same confusion is leading to slowing down of the adaptation of wireless devices and hence solowing the  take-off of wireless market. To add to that, if IEEE publishes yet another new wireless standard it is only going to cause further confusion and frustration at the end user, causes further delay in the adaptation. Hence will be an embarrassment to IEEE standards body. This confusion, frustration and the resulting market effects can not be ignored by the IEEE standards body. Hence I recommend that this draft be NOT allowed to become a standard. Instead, if the standard is absolutely desired, given the very close similarity between the goals of 802.15.3 and 802.15.4, a stripped down, but interoperable, version of the 802.15.3's work be adopted for 802.15.4 purposes with possible enhancements to power save policies. I once again urge the IEEE body and SEC to abandon this yet another new standard and save the wireless community from embarrassment.

SuggestedRemedy:
A stripped down, but interoperable, version of the 802.15.3's work be adopted for 802.15.4 purposes with possible enhancements to power save policies

Response:
REJECT.  

<Letter Created by the Technical Editing Team and Sent to commenter>

(Too long for this database)


Comment:
[PAR, 1] Introductory Text, Soon before the list of participants.  The introductory text talks of 'however using the optional frame structure for star networks'.  This is misleading as 1: 'Frame' is defined to mean something different, and 2: the superframe structure is used by all beacon enabled networks, not just stars.

SuggestedRemedy:
Perhaps replace this text with 'however, by using the optional superframe structure,'.   Also 'Connectivity to higher performance networks is provided through a PAN Coordinator' is misleading.  Connectivity to other networks may be via any device, and talk of 'higher performance networks' suggests some insufficiency of 802.15.4 - an idea perhaps to be omitted from our own introduction?!


Comment:
Title - Is the word "wireless" needed before Medium Access Control?  (it implies that there are or may be wired types of MAC for 802.15.4 compliant devices. - Suggest deleting that word

Response:
REJECT. 

The title we are using complies with IEEE 802 nomenclature


Comment:
title page (1 of 564)  -  add ref to 802 in descriptors to reduce potential confusion of Part 15.xxx to the FCC regulations (e.g. Sec. 15.401  Scope.  This subpart sets out the regulations for unlicensed National Information Infrastructure (U-NII) devices operating in the 5.15-5.35 GHz and 5.725-5.825 GHz bands.)

Response:
REJECT. 

The actual way is presented complies with IEEE standard style procedures


Comment:
No reference to 802.15.3 until Annex E - pg 523!


Comment:
pg 1 Abstract: This standard defines the protocol and compatible interconnection 'specifications for' data communication devices using low data rate, low power and low complexity, short-range RF transmissions in a Wireless Personal Area Network (WPAN). Keywords: Wireless, Personal Area Network, PAN, WPAN, ad hoc network, mobility, radio frequency, low power, low data rate, short-range, LR-WPAN.

Response:
ACCEPT. 

Changed performed as suggested


Comment:
Please make sure all figures and tables have the appropriate permissions and identifications if any have been taken from another source.

Response:
ACCEPT. 

All Figures used in this draft were created by the technical editing team -> They are original


Comment:
Please be prepared to submit all the figures as separate electronic files. They should be submitted as *.tif or *.eps files.

Response:
ACCEPT. 

All figures will be submitted to IEEE in the indicated formats.


Comment:
At the time of submission to the Board, or just prior to publication, you will need to supply a mailing address for each member of the working group that worked on the document.  This will ensure that all members of the working group receive a complimentary copy of the standard.

Response:
ACCEPT. 

The chairmain and technical editor of 802.15.4 already have this information collected.


Comment:
I really missed some information on how this standard relates to the  802.15.1 standard. Can they inter-operate with each other? Do they co-exist? When should one choose one and not the other etc.

SuggestedRemedy:
Add a couple of sentences on the subject in the general decription, in the inrtroduction or the scope.


Comment:
The scope should be the scope of the standard and not the scope of the project. The fact that the project intends to work with a level of coexistence with other wirless devices is not relevant to the user of the standards.


Comment:
Page (3 of 564) If this background is just for the reviewers, it belongs in a separate document and not much editing is warranted.  If the intent is that it will be bound with the standard, then I would suggest a number of changes.

Response:
ACCEPT. 

Please submit comments mentioned. That paragraph is bound to be in the standard


Comment:
page (4 of 564) Here is a proposed wording for the paragraph at mid page: This standard defines the protocol and interconnection requirements for devices communicating via radio frequencies in a wireless personal area network (WPAN).  Connectivity to higher performance networks is provided through a PAN coordinator.  The standard specifies use of a carrier sense multiple access with collision avoidance mechanism for medium access and supports star as well as peer-to-peer topologies.  Medium access is contention based, but, for applications using the optional frame structure for star networks, a provision is made for the PAN coordinator to allocate time slots  to devices with time critical data.

Response:
REJECT. 

The scope and purpose was approved by the working group and can not be modified at this stage


Comment:
add section in intro and def'ns referring to IEEE 802.15.3 High Rate WPAN to help set context of LR-WPAN

Response:
ACCEPT. 

References are being added in the document.


Comment:
Pg 3 - The graphic of the 802 family is missing 802.15.3

Response:
REJECT. 

TG3 is not an IEEE standard yet. According to IEEE receommendations we should not add TG3 in the family of IEEE standards (at this stage). In any case, references have been made in the draft about "a new draft call IEEE 802.15.3 being developed"


Comment:
page 3 list of stds defining  the access tech's typo - space missing - IEEE Std 802 Overview and Architecture.This standard


Comment:
The Clause 2.4 'Regulatory documents' subclause and references are confusing.
(1) All the documents should have URLs to make them readily available.
(2) ETSI is not a regulatory body but rather a Standards Development Organization (SDO).
(3) The ERC (European Radiocommunications Committee) reference may be confusing as the 'ERC' has merged into the newer ECC (see note 2).
(4) There are regulatory documents called out in D17 e.g., FCC but they are they not called out in this normative clause. 
Note 1: Documents to which reference is made only for information or background and documents that served merely as references in the preparation of the standard are not normative references. Such documents may, however, be included in a bibliography. 
Note 2: ERC (European Radiocommunications Committee) and ECTRA (European Committee for Telecommunications Regulatory Affairs) have now been combined to form the Electronic Communications Committee (ECC).  Also, CEPT has reorganised, the two offices, ERO and ETO, have merged.

SuggestedRemedy:
I suggest that the subclause title should be changed and/or ALL the 'Regulatory documents' need to be identified and all acronyms and abbreviations added to Clause 4.  Remember that the role and relationship of each normative referenced document shall be explained in the body of the standard.  Xrefing the doc ref to the clause in FrameMaker is a good first step.  Additionally, I suggest that the Editor verify and add ALL normative reference URLs and provide as much information as possible e.g., ERC is now ECC, etc.  As a starting point here is the verified ERC doc URL: http://www.ero.dk/doc98/Official/Pdf/Rec7003e.pdf 
Finally, the subclause 2.4 and Annex F need to be synchronized.  The Editor should consider adding a Bibliography. 
Note: The IEEE 802.18 is also tracking these docs.  Here is the CEPT/ERC/REC 70-03 ref: http://ieee802.org/Regulatory/Existing_Regulations/index.html#CEPT


Comment:
The sentence ending '...Part 2: Logical Link Control' is missing a period.


Comment:
The sentence ending '...Part 1: General Concepts' is missing a period.


Comment:
The sentence ending '...Part 7: Implementation Conformance Statements' is missing a period.


Comment:
In footnote 2 the sentence ending '...USA http://www.ansi.org' is missing a period.


Comment:
page 4 section 2.4 - inconsistent capitalization of 1st and second usage of Electromagnetic compatibility and Radio spectrum Matters (ERM);

Response:
ACCEPT. 

Change made as proposed by commenter


Comment:
The definition '3.11 device: any...' is gramatically inconsistent.

SuggestedRemedy:
I suggest you change to '3.11 device: Any...' capitalize the first word after the colon.


Comment:
[PAR, 3] A PAN Coordinator creates and manages a superframe. Other, lesser, coordinators can send beacons but do not determine the timing of a superframe.

SuggestedRemedy:
Remove the text 'and creation of a superframe structure'.  See also section 7.5.2.4 page 144 line 32, which would cause beacons to collide every time! Further, see section 7.5.4.1 page 148, line 8 where the 'next superframe' is referred to, but the beacon that is being tracked may not be a PAN Coordinator beacon, and as such will not generally be at the same time (as it would collide with the PAN Coordinator beacon).  Perhaps amend the text here to read 'ie: just before the next beacon', or some other text to solve the problem. (If 'non-PAN Coordinators' do actually have a separate 'superframe' then state this clearly, and determine whether or not a coordinator tracks its PAN Coordinator's beacon, and determine some mechanism to make GTSs work - I think this is very much more difficult).


Comment:
[PAR, 2] A coordinator is a device which is currently sending beacons, and not all devices which are capable of being a coordinator are currently acting as coordinators.  For instance, in a star network an FFD may associate to a PAN Coordinator and not send beacons of its own.  This device is coordinator capable but is not a coordinator.  This is important later when discussing the actions carried out by a 'coordinator'.

SuggestedRemedy:
Replace the text 'An FFD with device functionality that is capable of providing …' with 'An FFD which is configured to …'.


Comment:
page 5 definitions line 3-4  replace 'IEEE 100, The Authoritative Dictionary of Standards Terms' should be referenced for terms not defined in this clause. With   Terms not defined in this clause may be found in IEEE 100, The Authoritative Dictionary of Standards Terms.


Response:
REJECT. 

The definition used is widely used in other IEEE standards.


Comment:
def 3.10 assurance? or is it the condition of data being received as it was sent?

Response:
ACCEPT. 

The term is being used in the context of 'security'  not in terms of data being send or receibed.


Response:
REJECT. 

This definition is used in "the context of security"


Comment:
PG 206 - last paragraph level test until pg 523 ff


Comment:
LPDU' missing in Acronyms and Abbreviations


Comment:
AWGN missing in Acronyms and Abbreviations


Comment:
The acroynm 'MCPS-SAP MAC Common Part Sublayer - Service access point' needs to be corrected; ala the prior 'MCPS MAC common part sublayer' for consistency.

SuggestedRemedy:
I suggest you change to 'MCPS-SAP MAC common part sublayer - service access point'.


Comment:
Pages 7 & 8, SO, BO, SD and BI are missing.


Comment:
'These subclauses seem to have multiple phrases which seem to attempt a textbook-definition concept of the particular feature. The other subclauses of General Description (5) do not feel the need for defining technical terms, as such. Either 'informative' clauses should be presented if such a need is felt or definitions should be reworded or deleted to adhere to the style of the draft'


Comment:
[AS] Freshness is only provided by some security suites.

SuggestedRemedy:
Change 'Key management, device authentication and freshness' to 'Key management and device authentication'.


Comment:
[AS] Replace 'provide only encryption and integrity services' with 'are symmetric-key based'.


Comment:
[AS] Data encryption does not require a symmetric cypher in general.

SuggestedRemedy:
Add 'In this standard' at the beginning of the paragraph.


Comment:
[AS] This standard is providing integrity using symmetric key, but this is not the general case.


Comment:
The sentence 'Consequently, the RFD-only protocol can be implemented using minimal resources and memory capacity.' is inconsistent in the subclause.

SuggestedRemedy:
I suggest 'Consequently, the RFD-only device can be implemented using minimal resources and memory capacity.'; change protocol to 'device'.


Comment:
The sentence 'A peer-to-peer network can be ad hoc, self-organizing and self-healing.' introduces two (2) new terms which are not defined in Clause 3, however, the third term is defined in subclause 3.2.  This is inconsistent and should be changed.

SuggestedRemedy:
I suggest that the terms 'self-organizing and self-healing' be defined in Clause 3 especially since ad hoc is defined (see 3.2).


Comment:
The term 'cluster head' has been defined earlier in the subclause (sc).

SuggestedRemedy:
I suggest you replace 'cluster head' with 'CLH'.  The comment/edit repeats for the balance of the sc; i.e., ln 21, 22, and 26.


Comment:
The reference to 01189r0P802-15_TG4-CLUSTER-TREE-NETWORK.pdf is incomplete.

SuggestedRemedy:
I suggest you add this doc refernece to a new Annex E Bibliography and create a footnote on page 12 providing the following URL: http://ieee802.org/15/pub/2001/May01/01189r0P802-15_TG4-Cluster-Tree-Network.pdf


Comment:
The reference to 'OSI seven layer model.' should be xref to subclause 2.2.

SuggestedRemedy:
I suggest the Editor xref to subclause 2.2, ISO/IEC 7498-1:1994, Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Model.


Comment:
The reference to 'An IEEE 802.2 type I LLC...' needs a xref and I believe is incorrect.

SuggestedRemedy:
I suggest the Editor add a xref to the applicable subclause 2.1 doc and then modify the sentence introduction to 'An IEEE 802.2 Type 1 LLC...'; changing from 'type I' to 'Type 1'.


Comment:
The sentence 'Refer to annex E for an informative summary of regulatory requirements.' is incorrect.

SuggestedRemedy:
I suggest you change to 'Refer to Annex F for an informative summary of regulatory requirements.' which corrects the incorrect annex reference and then add an xref to Annex F.


Comment:
The reference to band '2.4 - 2.4835 GHz (worldwide).' is technically correct but you might want to standardize on the dashed list use of electrical terms.

SuggestedRemedy:
I suggest you use '2400 - 2483.5 MHz (worldwide).' to be consistent with the 868 - 868.6 and 915 MHz references.  Please make the change globally.


Comment:
The sentence ending '...power consumption considerations, security.' is gramatically incorrect.

SuggestedRemedy:
I suggest '...power consumption considerations, and security.'; adding 'and'.


Comment:
I may of missed something but should Figure 4 and the text be accurate?  The sentence '...(See Figure 4) and is divided into 16 equally sized slots.' suggest that the Figure 4 should have sixteen (16) slots...I count 15.

SuggestedRemedy:
Update Figure 4 if I am right; if I am wrong ignore :). 
Note: Make the word 'See' lowercase or 'see'.


Comment:
The use of numbers in the text e.g., 'seven' is inconsistent.  Sometimes the Editor uses 'seven' and sometimes '7' or specifically '16', pg14, ln 17.

SuggestedRemedy:
I suggest standardizing on and/or verifying word and number usages in D17 vs. the IEEE Standards Style Manual.


Comment:
The sentence 'Such measures are beyond the scope of this specification.' is incorrect.

SuggestedRemedy:
I suggest you use 'Such measures are beyond the scope of this standard.'; changing 'specification' to 'standard'.  Please make the change globally. 
Note: Does the Editor want to refer the reader to more infomation e.g., ZigBee Alliance, etc.?


Comment:
The sentence '4) A MAC command frame, used to handling all MAC peer entity control transfers.' is incorrect.

SuggestedRemedy:
I suggest '4) A MAC command frame, used for handling all MAC peer entity control transfers.'; change 'to' to 'for'.


Comment:
It is hard to read embedded text in Figure 10.

SuggestedRemedy:
I suggest the Editor make the graphic larger or edit the font point size in the original *.EPS.  Please make the change globally. 
Note: The use of Arial font in this and other graphics is different than the draft text New Times Roman.  I suggest the Editor use New Times Roman when creating future graphics with embedded text.


Comment:
The sentence 'A brief introduction of some security terms are provided below; for more detailed information refer to clause 7.' is gramatically incorrect.

SuggestedRemedy:
I suggest 'A brief introduction of some security terms are provided in the subclauses below; for more detailed information refer to Clause 7.'.


Comment:
The sentence 'Recommended practices established by recognized industry organizations should be used.' could use a reference.

SuggestedRemedy:
I suggest more information be provided such as a footnote with a URL to a recognized industry organization(s), etc.


Comment:
The sentence 'This subclauses provides a brief overview of the concept of service primitives.' is incorrect.

SuggestedRemedy:
I suggest 'This subclause provides a brief overview of the concept of service primitives.'; change 'subclauses' to 'subclause'.


Comment:
The sentence 'Please refer to IEEE Std 802.2 1998 edition for more detailed information.' needs to xref'ed.


Comment:
The sentence 'The ability to perform this security functionality does not imply, however, that security must be used at any given time by any given device.' is the first (besides the Frontmatter page i) use of the word 'must', is this intentional?

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.  Refer to the May00, IEEE Standards Style Manual, Cl 13.1, pg. 15.  Please make the change globally.
Note: 'The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.'


Comment:
The first use of 'CFP' requires spelling out the abbreviation.

SuggestedRemedy:
I suggest 'contention free period (CFP)'.


Comment:
Remove reference to a pdf file. Too much cluster tree material, this looks as too much advertisement.

SuggestedRemedy:
Note: Simply remove the last line of the l;ast paragraph of 5.2.1.2.1


Comment:
Figures 10 to 13 need some work. The text in the headings does not have enough spacing and it looks that there are more than one font in use.

SuggestedRemedy:
Try to have constant spacing in the text, use a single size font and a single-type of font in all of the text in these figures


Comment:
There is a vertical line in figure 10 and 13 (see rightmost part of the figure) that is not shown in Figures 11 and 12


Comment:
I do not understand the expression. 'All data transfers' are acknowledged in one of two forms' Which forms?


Comment:
ACL acronym used without definition. Define it after it first time use.


Comment:
The first sentence, 'All data transfers are acknowledged in one of two forms,' doesn't reflect the fact that ACK's are optional.

SuggestedRemedy:
Possibly change to, 'Data transfers can be optionally acknowledged in one of two forms.'


Comment:
FFD and RFD -> Coordinator is required to include unnecessary functions -> Reference: 3.8, 3.14, 5, 5.1. Introduction: The specification defines two classes of device, a fully functioned Device, and a reduced function device. The specification requires that a network coordinator is a fully functioned device. Concern to raise: Many networks will operate successfully with a device that does not implement all the features of an FFD.

SuggestedRemedy:
Proposed solution: The differences between an FFD and an RFD should be gathered together in a table, and explanation added to clarify which features are a) needed in a coordinator or b) must be handled by a coordinator, but may not necessarily be implemented. An example of this is the allocation of guaranteed timeslots. The MAC in a coordinator must implement the primitives, and handle messages, but should be permitted to reject every GTS request from a device on the PAN.


Comment:
This text, along with Figure 1, states that RFDs are not permitted in a peer-to-peer topology. Is this still actually the case? Given that the entire MCPS-SAP and the MLME-RX-ENABLE.request primitive are included in RFD MACs, it seems that an RFD is perfectly capable of participating in a peer-to-peer network. All of the additional functionality contained in an FFD relates to beacons, association and superframes (e.g. GTSs), and this functionality is not needed by a device in a peer-to-peer topology. Of course the advantage of allowing RFDs in peer-to-peer networks is that they require less memory resources, and this is something that Adcon would like to take advantage of.

Response:
REJECT. 

The statement in the draft is still true as is. The RFD is defined this way to allow for devices with lesser memory requirements (most expensive part) to participate on the network. Because of this they can not participate in peer-to-peer communication.


Comment:
This line states that a PAN coordinator is still required in a peer-to-peer topology. The MAC itself does not seem to impose this as a requirement, so is this statement true? For example, why couldn’t a peer-to-peer network be initialized as follows: MLME-SET.request( macBeaconOrder = 15 ), MLME-SET.request( macShortAddress = x ), MLME-SET.request( macPANId = y ) and then use the MCPS-SAP and the MLME-RX-ENABLE.request primitive to send and receive data at your leisure? Isn’t this a typical operational paradigm for this MAC? No coordinator required. In this instance the MAC would be still be supporting basic services such as addressing, packet retries/reliability, error detection, and CSMA-CA, but the user could build virtually any sort of network layer on top. And an RFD MAC would be sufficient.

Response:
REJECT. 

A PAN coordinator is required in order to start a network. Even in peer-to-peer links with just 2 devices a PAN coordinator is required to start the network though its work load may be very low.


Comment:
The Table 1 should be reformatted to be clearer e.g., column 2 mixes MHz and GHz and to conform to the IEEE Standards Style Manual.

SuggestedRemedy:
Specifically, I suggest column 2 'Frequency Band' should be changed to 'Frequency Band (MHz)' and the next three rows in colunm 2 should be 868.0-868.6, 902.0-928.0, and 2400.0-2483.5 and the same for columns 3, 5, and 6.  Also, the table header ruling (top line of table) is not the same as the other 3 sides.  Refer to the May00, IEEE Standards Style Manual, 15. Tables, pg. 18.  Please make the change globally. 
Note: 'To save space, abbreviations and letter symbols shall be used in column and line headings wherever possible. See ANSI 260.1-1993 and other standards in Clause 2 for the appropriate abbreviations and symbols for use in standards.' Style Manual, Cl 15.3.1, pg20.


Comment:
Again, the regulatory documents need to be added to a bibliography.

SuggestedRemedy:
I suggest that the Editor create a new Bibliography annex e.g., Annex G for adding these regulatory documents to.


Comment:
The sentence 'Approval authority: Ministry of Post and Telecommunications (MPT)' is outdated.

SuggestedRemedy:
I suggest you use the latest authority title 'Ministry of Public Management, Home Affairs, Posts and Telecommunications (MPHPT)'.  Please make the change globally.  More info: http://www.soumu.go.jp/english/


Comment:
The sentence 'Sixteen channels are available in the 2.4 GHz band, ten in the 915 MHz band and one in the 868 MHz band.' is inconsistent.  The Editor should standardize the numeric word usage in D17; is it 'Sixteen' or '16' (refer to prior sentence '27 channels' or Clause 5.0, pg 9, ln 21-22) also the usage of GHz should be changed globally to MHz (or at least when used with MHz in the same sentence).  Finally, is there a space between the frequency and the hertz parameter e.g. '868 MHz' or not?  The D17 uses both '868 MHz' and '868MHz'.

SuggestedRemedy:
I suggest '16 channels are available in the 2450 MHz band, 10 in the 915 MHz band and 1 in the 868 MHz band.' or 'Sixteen channels are available in the 2450 MHz band, ten in the 915 MHz band and one in the 868 MHz band.' Please confer with the Project Editor and then based on IEEE guidance make the change globally for accuracy and consistency.


Comment:
There are no xrefs to Annex F in Clause 6. Pg 26, ln 42, 48, etc.

SuggestedRemedy:
I suggest adding the xrefs to Annex F.  Please make the change globally.


Comment:
'Subclause does not address rollover or sudden change in sequence number (due to  restart) of sequence number - Clarification requested, if any.'


Comment:
The status value 'SUCCESS' is missing from this table, as well as from Table 44.


Comment:
The valid range of sduLength includes 'aMaxBeaconMSDULength'. This name is in conflict with Table 69, which uses 'aMaxBeaconPayloadSize'.

SuggestedRemedy:
Make the naming consistent throughout the draft. 'payload' is a better description, since the MSDU includes other things.


Comment:
The valid range should be in hex for consistency.

SuggestedRemedy:
Change from '0-3' to '0x00-0x11'. Make this consistent throughout the draft.


Comment:
The primitive tells the receiver a turn on time but no relative turn off time. Because this primitive originates from a layer that has no concept of time, it would be useful to specify a relative turn off time.

SuggestedRemedy:
Replace the current two parameters with 'Rx_On' and 'Rx_Off'.


Comment:
There is no collision avoidance associated with the commencement of beacon transmissions. A device can unknowingly interfere with another device's beacon transmissions.

SuggestedRemedy:
The device will already have information regarding the beacon transmission times of other devices in the neighborhood from the PAN descriptor list it received following the scan. The device can use this info to choose an appropriate time for its own beacon transmissions. Add a parameter called 'StartTime' to specify.


Comment:
This text is repeated from the paragraph above.


Comment:
There is a naming conflict between 'macBeaconMSDU' and 'macBeaconPayload'.

SuggestedRemedy:
Make naming consistent throughout the draft. Use 'payload'.


SuggestedRemedy:
Reword as '...after having performed a MAC...primitive, completed a passive channel scan (See...) and used the channel scan results to make a suitable PAN selection. The algorithm for...'


Comment:
Remove the word 'shall' from the primitives subclauses of both the MAC and PHY.


Comment:
What happens if the broadcast short address (0xff) is included in the address list of the beacon frame? It could be used as a way to synchronize devices to receive broadcast data.

SuggestedRemedy:
Consider adding text to describe this condition. Note that devices should not send data request commands in response to the pending broadcast address.


Comment:
A device has no way of knowing if the PAN coordinator has the capacity to allocate a GTS. If there is no capacity, sending a GTS request is a waste of time. Also, should a PAN coordinator be allowed to have more than seven GTSs (consider longer beacon orders with larger slots)?

SuggestedRemedy:
Add a bit to the superframe specification field of the beacon frame to say whether a PAN coordinator is currently allocating new GTSs. Consider allowing more than seven GTSs on a single PAN.


Comment:
Once a device selects an appropriate PAN to join, the DME has no way to communicate the desired channel number to the MAC.

SuggestedRemedy:
Add a 'LogicalChannel' parameter to the MLME-ASSOCIATE.request primitive. In the effect on receipt (7.1.3.1.3), add text to say 'if the associate request fails, the MAC shall set macPANId to the default value (0xffff)'. Note the default macPANId is currently 0x0000 and should be changed to 0xffff.


Comment:
[AS] Tables 70,71,72 are physically located in the wrong subclause.


Comment:
[AS] Change first sentence to read 'The MAC PIB security attributes (See Table 71) contain...'.

SuggestedRemedy:
In general, change 'MAC PIB ACL' to 'MAC PIB security attributes' throughout the draft for clarity.


Comment:
[AS] Use italics for attributes of the ACL entry descriptor (for example, ACLExtendedAddress).


Comment:
[AS] Should not read 'ACLExtendedAddress and ACLShortAddress'.

SuggestedRemedy:
Change to 'the ACLPANId and the ACLExtendedAddress or ACLShortAddress fields...'. Make the same change in 7.5.9.4.2 line 15.


Comment:
[AS] Add a reference to the definition of beacon payload, command payload, data payload. Do the same for 7.5.9.4.2.


Comment:
[AS] Change 'placed after the payload field' to 'placed in the payload field'.


Comment:
[AS] Reword text in the same manner as 7.6.1.4 lines 45-47. Do this also for 7.6.1.6 lines 24-25.


Comment:
[AS] Change 'mechanisms' to 'mechanism'.


Comment:
[AS] Change 'security suite' to 'standard'.


Comment:
[AS] Add text. Change to 'key is issued or if the key sequence counter is updated.'


Comment:
[AS] Remove the extra parenthesis. Look also on line 37.


Comment:
[AS] Change title to 'AES-CCM MAC payload field'.


Comment:
[AS] The length of the authentication field M depends on the security suite used.

SuggestedRemedy:
Change to '...M shall be 4,8 or 16 as required and the nonce...'.


Comment:
[AS] Replace '(optional)' with 'If the optional external frame counter and key sequence counter are included in the corresponding macDefaultSecurityMaterial or ACLSecurityMaterial field, ensure sequencial freshness by...'. Do this also in 7.6.3.3.2.


Comment:
[AS] Replace 'last known key sequence counter' with 'optional external key sequence counter'. Replace 'last known frame counter' with 'optional external frame counter'. Make these same changes in 7.6.3.3.2.


Comment:
[AS] A device indicates beacons with payloads to the higher layer and processes beacons with no payloads without indicating them to the higher layer. The device may want to ignore insecure beacons which may have no payloads.


Comment:
[AS] When a device processes a secure beacon (or any secure frame), it should reference the received PANId and source address to determine what keys and security suite to use.  If the full 64-bit extended MAC address is needed, the sending device may need to include it in the frame.  However, the device should not assume for any given frame that the macCoordExtendedAddress should be used.  The reference to the macCoordExtendedAddress for determining the security suite in 7.2.2.1.5, 7.3.2.2.1 and 7.3.3.1.1 should be removed.  It is true that the sending device uses its entry for macCoordExtendedAddress to determine what key to send it with, but the receiving device needs to use a different process.


Comment:
Clarify usage of this primitive throughout the draft. 7.5.9.4.1 is an instance where more explanation is needed.


Comment:
The draft should specify that it is necessary to store at least one PAN descriptor. The scan should allow you to limit the number of PAN descriptors you find (must store).


Comment:
How can the device receive the association response command when at this point it is not tracking the beacon?


Comment:
[AS] How does one change an entry within an ACLEntryDescriptor?  It seems that we need to add a handle to each entry so that they can be specifically referenced.  Perhaps we need to add a new MLME-SET-ACLEntry or something that changes a field in a particular ACL entry.


Comment:
[AS] It is not necessarily clear looking at the figures describing each command (e.g. figure 45) what the secure command looks like.  Perhaps figures should be added showing what that command sent securely looks like.


Comment:
[AS] Insert the word 'data' in 'MAC sublayer receives a frame' to specify that it is a data frame. Do the same in 7.5.9.3.


Comment:
[AS] If the device receives a beacon with the security field set to one, it may still want to check whether the device is in the ACL or not.  It may be better to say that if the source address and PANID in the beacon correspond to a ACLPANId and corresponding ACLExtendedAddress or ACLShortAddress, the ACLEntry subfield in the PAN descriptor shall be set to 1.  This may not be a necessary requirement since we already have a security error, but it is extra information that probably should be provided.


Comment:
[AS] Should all frames that fail the security check be passed to the higher layer to give the device a better idea of what caused the failure?


Comment:
If no security is used on an incoming frame, should a device that is in secured mode still check the ACL?


Comment:
The GTS procedure is inefficient, especially in the case of realloacating slots.

SuggestedRemedy:
Add a GTS usage map to the beacon frame to indicate changes in the GTS assignment. For each affected GTS, the map will contain the start slot, length, direction and device address. The overhead added to each beacon will depend on the number of changes due to allocation, deallocation and reallocation since the last beacon frame.


Comment:
A device allocated a receive GTS must enable its receiver for the entirety of the GTS. This would consume a lot of power for a larger beacon order. Is there some way to reduce this?


Comment:
When the coordinator realignment command is broadcast, most devices will be asleep and will not receive it.

SuggestedRemedy:
Set the frame pending field in the beacon to one and then broadcast the command immediately following the beacon. (See earlier comment about using the broadcast short address in the beacon address pending field)


Comment:
The parenthetical '(See subclause 6.2).' is incorrect.

SuggestedRemedy:
I suggest '(see 6.2).'; delete 'subclause' (only the word 'clause' is used in a std) and use lowercase for the first word.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
In Table 28, Column 3, row 8, ln 33 the character '-' is incorrect.

SuggestedRemedy:
replace  '-'  with an en-dash '-' (it is a wider hyphen character) using the IEEE FM6 template.  Please review the IEEE Standards Style Manual.  Please make the change globally.


SuggestedRemedy:
I suggest replacing 'commend' with 'command'.


Comment:
The sentence 'Selected from the available logical channels supported by the PHY' is missing a period.


Comment:
The sentence 'See Table 70 and Table 71' is missing the paranthetical.


Comment:
The sentence ending '...with a status of NO_DATA' is missing a period.


Comment:
Alignment - Timer aMaxResponseTime is aReponseWaitTime in Table 69 and 7.1.3.1.3


Comment:
Incomplete - Timer aMaxFrameResponseTime is not shown to be started after the receipt of Acknowledgement to the Data request.


Comment:
Incomplete - frame needs to be modified with 'GTS Allocation command'.


Comment:
Incomplete - NO_SHORT_ADDRESS needs to be added, since 7.3.3.1 indicates that only devices with a short address can send the GTS request command which is generated only by a MLME-GTS-request.  Therefore the MLME-GTS-confirm needs to be able to indicate this.


Comment:
Incomplete - this primitive is also generated when the MLME-GTS-request contained INVALID_PARAMETERs and no GTS allocation command was received.


Comment:
Alignment - Timer aMaxResponseTime is aReponseWaitTime in Table 69 and 7.1.7.1.3.

SuggestedRemedy:
I suggest you review the figure and correct if this is an error.


Comment:
Alignment - SINGLE and TRACK are FALSE and TRUE in 7.1.15.1.1 Table 57.

SuggestedRemedy:
I suggest you review the table and figure and correct if this is an error.


Comment:
Inconsistency - There are two (2) 'SUCCESS: 0x00 and 0xf0'.

SuggestedRemedy:
I suggest you review the table and correct if this is an error.


Comment:
Question - All fields '...shall be set to 0...', does this include the GTS direction bit?

SuggestedRemedy:
I suggest you review the text and correct if this is an error.


Comment:
The sentence 'However if the device...' is gramatically incorrect.

SuggestedRemedy:
I suggest 'However, if the device...'; adding the comma.


Comment:
The third column 'Valid Range' is inconsistent.  On the second and third row the Editor refers to 'See Table 40' and '(See subclause 7.2.2.1.3)'; w/ and w/o parentheses.  Which is correct?

SuggestedRemedy:
Please review the IEEE Standards Style Manual and/or verify with the PE to determine whcih of these styles is correct.  Please make the change globally.


Comment:
At the place between MLME-SCAN.confirm and MLME-START.request, there is one very important MLME command missing.  It is the MLME-SET.request which sets the macShortAddress to something other than 0x00ff.  If this is not done at this time then the MLME-START.request will fail as per the text in 7.5.2.3 and 7.1.14.1.3.

SuggestedRemedy:
I suggest adding this MLME to the figure.


Comment:
It is not clear whether or not the DSN is incremented in the beacon request command sent during an Active scan.  According the definition of DSN, this is incremented for each beacon request command sent.  However, if the received DSN is use by the receiver as a starting point for communications (i.e. inorder to determine duplication) with that device, there will be problems.  This problem may also occur if a scan is done when an active PAN exists.

SuggestedRemedy:
I suggest that text needs to be added to clarify this incrementing DSN in this situation and whether it is on a per channel, or per device, or per command.


Comment:
Reference is to Table 33, which is wrong.  It should be to Figure 33 on page 107.

SuggestedRemedy:
I suggest the Editor review and then make the change if he concurs.


Comment:
The sentence '...with a status of NO_DATA' is missing a period.


Comment:
The table entry '(See Table 70 and Table 71)' is using a smaller font point size than the rest of the table.

SuggestedRemedy:
I suggest changing the font point size back to normal size.


SuggestedRemedy:
I suggest 'specifies'.  Please make the change globally.


Comment:
The sentence 'Similarly if a PAN...' is gramatically incorrect.


Comment:
The sentence 'Table 57 specifies the parameter for the MLME-POLL.request primitive.' is incorrect, it should be moved to page 102 and refer to Table 59.

SuggestedRemedy:
I suggest moving the sentence and changing it to 'Table 59 specifies the parameter for the MLME-POLL.request primitive.'.


Comment:
The sentence 'Table 44 specifies...', is incorrect.

SuggestedRemedy:
I suggest changing it to 'Table 60 specifies...


Comment:
The reference to '...Table 33.' is incorrect.  This error repeats.

SuggestedRemedy:
I suggest '...Figure 33.' and fixing the xref.  This error repeats on sc 7.2.2.2, pg 113, ln 47,  sc 7.2.2.3, pg 114, ln 53, sc 7.2.2.4, pg 115, ln 31, etc.  Please make the change globally.


Comment:
The title '7.2.2.4 MAC Command Frame Format' is incorrect.

SuggestedRemedy:
I suggest '7.2.2.4 MAC command frame format'.  Please review the IEEE Standards Style Manual.  Please make the change globally.


SuggestedRemedy:
I suggest moving Table 64 to the end of 7.2.2.4.2 on pg 115.


Comment:
The caption position for Figure 33 (and the rest of sc 7.2) is incorrect.  This error repeats for the rest of this sc.

SuggestedRemedy:
I suggest moving the caption under the graphic, which is consistent with IEEE Style and the rest of D17.  Please review the IEEE Standards Style Manual.  Please make the change globally.


SuggestedRemedy:
I suggest moving Figure 51 to the end of 7.3.3.1 on pg 115.


Comment:
The references to Tables 69-72 are out of sequence and the use of asterix (*) as an optional flag in Table 70 is unclear as there are '*' characters used to denote multiplication in Table 69 - the asterix comment is before Table 69 and 70.

SuggestedRemedy:
I suggest moving Table 69 to the end of sc 7.4.1.  I suggest the sentence 'The attributes contained in the MAC PIB are presented in Table 70; those attributes marked with an asterisk (*) are optional for an RFD.' be moved to be a table note vs. an introductory sentence. Also, Table 69 and 70 flows break across multiple pages; the Editor needs to add the text '(continued)' to the second, third, fourth, etc. pages.


Comment:
The term 'snoozing' is vague.  I like it but it might be confusing to readers of this standard.

SuggestedRemedy:
I suggest defining and/or qualifying the term 'snoozing' in Clause 3 and/or Clause 4, respectively.


Comment:
The title 'Table 71: MAC PIB security attributes' is using a two (2) font types.

SuggestedRemedy:
Please review the IEEE Standards Style Manual.  Please make the change globally


Comment:
The sentence 'The IEEE 802.15.4 protocol...' is confusing this introduction is used in multiple ways i.e., protocol, standard, system, PAN, and specification, etc.

SuggestedRemedy:
I suggest standardizing on the internal reference to this IEEE document e.g., 'The IEEE 802.15.4 standard...'.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
The sentence 'The CSMA-CA algorithm shall not be used for the transmission of beacon frames, acknowledgement frames, data frames transmitted in the CFP or data or MAC command frames that can be quickly transmitted in response to a data request command, immediately following the acknowledgement (See subclause 7.5.6.3).' is a run on sentence and is gramatically incorrect.

SuggestedRemedy:
I suggest the Editor rewrite the sentence or at the very least delete the first use of 'or' and replace with a comma ','.


Comment:
The figure is hard to read please increase the font point size.

SuggestedRemedy:
Please review the IEEE Standards Style Manual i.e.,'6 POINT IS THE SMALLEST FONT ACCEPTABLE'.  Please make the change globally.


Comment:
Can the word fragment '...radio sphere of influence.' be replaced by 'personal operating space (POS)'?

SuggestedRemedy:
If it can be replaced I suggest the Editor replace the word fragment to reduce the terms.  Please make the change globally.


Comment:
Is SPDU the same as SDU?  Other places use SDU (for example, Table 39), and the acronym SPDU does not appear in clause 4.  SPDU is also used in 7.1.1.3.

SuggestedRemedy:
Add SPDU to clause 4, or change to SDU if they are the same thing.


Comment:
7.5.1.2 specifies interframe spacing in general.  We should probably add some text saying that interframe spacing between a data frame and subsequent acknowledgement is a special case which is specified in 7.5.6.4.2.


Comment:
Shouldn't the wording include the phrase 'at least' when talking about the spacing.  In other words, the interframe spacing following a short packet should be 'at least' aSIFSPeriod symbols, and the interframe spacing following a long packet should be 'at least' aLIFSPeriod symbols?  A device could use longer spacing if desired, but the minimum spec is there for interoperability.


Comment:
What is the meaning of 'extracting' the association response? The meaning can be understood after reading the following pages. I recommend making an explanation at this point since is the first time this 'expression' was used.


Comment:
MLME-RX-ENABLE was changed and now is 'superframe' centric. Originally the intention of this primitive was for mesh networks. Can we try to put it back to its original form? Or at least make it generic enough so it conveys the information that can be used in conjuction with superframes and peer-peer transfers.


Comment:
I have two comments about Figure 29:* It is superframe 'centric'. Does not conveys the complete 'picture' of possible usage of this primitive, since is not considering peer-peer topology.* It shows the PLME-SET-TRX-STATE without mentioning the particular state requested (I think it can be shown, since this MSC is very specific.


Comment:
Figure 33: In some Peer-peer topologies it would be really nice to be able to use one PAN ID address, Destination Address and Source Address. The way the frame is structure, if a Src/Dest address is present, the corresponding PAN ID is also present. This poses a problem becuase it forces several applications to repeat the PAN ID twice within the frame.Using some of the reserved bits in the Frame Control Field, it is possible to create: Src PAN Present Bit and Dest. PAN ID Present bit.


Comment:
Figure 33 and 34: The caption of all the figures should be located at the bottom of the figure, not at the top. Check the entire document for consistency.


Comment:
The bullet list should be changed to match the rest of D17 and comply to the IEEE Standards Style Manual e.g., ordered or unordered (dashed) list.

SuggestedRemedy:
Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
This paragraph is using 2 font sizes. Change to standard font size


Comment:
Figure 56: Please add to the figure the 'Beacon Interval' (BI) and Superframe Duration (SD) to help improve the text explanation.


Comment:
Look at this expression: '...or data or MAC command frames that can be quickly transmitted…'2 observations: 1) Improve wording -> double 'or', 2) 'uickly transmitted?, how quick is quick? This is not well defined.Probably some more text will help clarify it.


Comment:
Figure 73: I have a problem understanding this diagram:A) Why several PLME-ED.requests for the same channel? Do we do an undetermined amount of ED's consuming all of my micro's processing power? Should we specify a repetition rate? (may be not).B) The figure shows the first and the last, but it can be improved in order to show that the block of actions from PLME-SET request up to the last PLME-ED.confirm (in a given channel), belong to the set of action within one channel. The before the 'last channel' block we can put some text like 'other channels EDs'


Comment:
Figure 74: All of the Message Charts have the DME on the leftmost column and the PHY to the rightmost side. This chart is exactly the opposite. I recommend swapping the 1st and 3rd columns


Comment:
Figure 77: Why 'Perform CCA' appears 2 times in this chart?


Comment:
Starting a Network -> Scan for Channel and PAN id is slow -> Reference: 7.5.2.3. Introduction: Before a network can be started by a co-ordinator, the coordinator must pick a channel and PAN id. Concern to raise: The mechanism described for selecting the channel and PAN may be very slow, or may miss other 802.15.4 compliant devices using the channel.

SuggestedRemedy:
Proposed solution: A PAN coordinator wishing to start a PAN transmits a coordinator-identify command using CSMA. A coordinator on the channel will respond using CSMA with a coordinator-identification message. The device wishing to start the network shall wait for sixty four backoff slot periods, receiving any co-ordinator identification messages transmitted. This procedure shall be repeated on the appropriate number of channels. This solution will allow a device operating in the 915 MHz band to start a network in 0.032 seconds, compared to potentially nearly 400 seconds using the method described.


Comment:
Starting a Network -> The co-ordinator can pick an illegal channel -> Reference: 7.5.2.3. Introduction: The section describes how an active channel scan is used to select a PAN id.  Concern to raise: It is not clear how a channel should be chosen from the list of channels scanned. It is not explained that the MAC may select any of the scanned channels for the network.

SuggestedRemedy:
Proposed solution: The section should include  'The algorithm for selecting a channel is outside the scope of this document. Any network layer using 802.15.4 should only request scanning of channels permitted by the geographic region in which the device is operating since the MAC may select any scanned channel on which to start the PAN'


Comment:
Synchronisation Mode -> Method requires same value stored in network and MAC layers -> Reference: 7.1.15.1. Introduction: A network layer may request the MAC to search for a single beacon to synchronise with the coordinator, or may request that the MAC continues to track each beacon transmitted by the coordinator. Concern to raise: The network layer must also keep a record of the sync mode that is set in the MAC. There are two copies of the same information which can lead to poor implementation and the values becoming out of step.

SuggestedRemedy:
Proposed solution: A PIB attribute 'Beacon Sync Mode' should be added to the MAC PIB. The MLME-SYNC.request would then not require any parameters.


Comment:
Snooze Mode -> Moving a network into snooze mode can create a lot of traffic -> Reference: 7.5.2.4. Introduction: In order to limit traffic on the channel, when not needed the coordinator may enter snooze mode, and stop transmitting beacon frames. Concern to raise: When a coordinator enters snooze mode, a device on the network which is tracking beacons will generate a sync loss indication from the MAC to the network layer. The network layer of the device is currently unable to determine if the loss of the Beacon frame is due to snoozing or another issue. Devices on the network may start issuing beacon requests in an attempt to rediscover the network.

SuggestedRemedy:
Proposed solution: The MAC PIB entry 'Snooze permit' should be used in the coordinator to determine if the network may snooze, and used in other devices on the PAN to indicate that the coordinator may enter snooze mode. It is proposed that the Association commands include a field from the coordinator indicating that it may snooze, and a field in the device capabilities from the PAN devices indicating if they wish to prevent snoozing.


Comment:
Snooze Mode -> Network devices will not keep accurate time during Snooze Mode -> Reference: 7.5.2.4. Introduction: In order to limit traffic on the channel, when not needed the coordinator may enter snooze mode, and stop transmitting beacon frames. The coordinator enables the receiver during the active portion of the superframe. Concern to raise: When a coordinator enters snooze mode, the beacons indicating the superframe boundaries are no longer transmitted. The reference point in network devices will start to drift. The standard describes that the coordinator receiver is only listening for messages in the active portion of the superframe. If the active portion of the superframe is a small fraction of the superframe, network devices will become unable to communicate with the coordinator.

SuggestedRemedy:
Proposed solution: One of the following changes is proposed to be adopted. (1) Snoozing is disallowed in networks where there is an inactive portion of the superframe. (2) The coordinator of a snoozing network is required to listen for messages during the entire superframe


Comment:
Receiver Operation -> The operation of MLME-RX-ENABLE.request is unclear -> Reference: 7.1.10.1. Introduction: It is possible for the network layer to schedule a transceiver enable command (RX mode) a predetermined number of symbols after the beginning of the Superframe. Concern to raise: (1) It is unclear if the scheduled receive slot persists between superframes. (2) It is unclear how to schedule that the receiver will be disabled other than at the end of the superframe (3) It is unclear if a request issued more than the defer time after the beacon is acted upon immediately, or delayed until the following superframe.

SuggestedRemedy:
Proposed solution: It is proposed that two optional attributes be added to the MAC PIB: RX_ENABLE start and RX-ENABLE end. The MAC shall enable the receiver during the portion of the superframe between the start and end values.


Comment:
Receiver Operation -> The receiver cannot remain enabled in a device which is not a coordinator -> Reference: 7.1.14.1. Introduction: The MAC command MLME-START.request will cause the device to start transmitting beacons, with the receiver enabled during the active portion of the superframe. Concern to raise: It is not possible to instruct the MAC of a device on a PAN to switch into receive mode whilst idle.

SuggestedRemedy:
Proposed solution: It is proposed that an attribute be added to the MAC PIB: RX_ENABLE while idle. If this value is set to TRUE the MAC will enable the receiver when not transmitting. If FALSE, the receiver will only be enabled when required.


Comment:
Orphan Scan -> Orphan scan may take an unnecessarily long time -> Reference: 7.5.2.1.4 Introduction: An orphan scan is executed by a network device when  requested by the network layer.Concern to Raise: The scan may take aBaseSuperframeDuration * (2n+1) symbols on each channel, yet a coordinator is required to respond within aResponseWaiteTime symbols.

SuggestedRemedy:
Proposed Solution: It is proposed that by changing the receiver enable duration on the device performing the scan to aResponseWaiteTime symbols. This will reduce the time needed to scan each channel.


Comment:
[AF, 5] As the protocol stands all communications include the DSN byte. This overhead is incurred irrespective of whether or not the particular application requires duplicate message suppression. As the 8 bit DSN does not provide 'guaranteed' duplicate detection, devices requiring this will have to apply application level measures. Removing the requirement for duplicate suppression from the MAC would prevent the unnecessary protocol overhead and significantly simplify the implementation of the MAC.  Also mentioned in D.3.1.7.3, p. 309, lines 1-54 and 7.5, p. 136, lines 5-7 and also anywhere where the DSN is mentioned.

SuggestedRemedy:
Remove duplicate detection from the MAC and leave it up to individual applications or provide a more satisfactory mechanism for performing duplicate detection in the MAC.


Comment:
[MD, 3] Also 7.1.8, p. 82.  On a Coordinator, an ASSOCIATE.response or ORPHAN.response from the NWK to the MLME causes a MAC Command packet to be sent over air. If the packet transmission fails, there is no Coordinator-side Confirm primitive to inform the Coordinator NWK. See figure 24 (page 68) and figure 28 (page 84).

SuggestedRemedy:
The ASSOCIATE.confirm primitive must be used on the Coordinator side as well as on the Slave side. The primitive will be slightly different on the Coordinator side (e.g. allow a status of TRANSACTION_OVERFLOW). It should be defined that if the Associate Response MAC Command packet fails, the association shall be deemed a failure on the Coordinator and the NWK informed. For the ORPHAN primitive, the NWK may need to know that 'Slave X is orphaned, and I haven't been able to get the Coordinator Realignment to it'. This would need adding an ORPHAN.confirm primitive. NOTE: Section 7.5.5 Transaction Handling (page 148) refers to this non-existent Coordinator-side ASSOCIATE.Confirm: 'The coordinator shall begin handling a transaction on receipt of an indirect transmission request either via the MCPS-DATA.request primitive or via a request from the MLME to send a MAC command instigated by a request primitive from the DME, such as the MLME-ASSOCIATE.response primitive (see subclause 7.1.3.3). The information contained in these requests forms a transaction and the coordinator shall be capable of storing at least one transaction. On receipt of this primitive, if there is no capacity to store another transaction, the MAC sublayer shall issue the confirm primitive, corresponding to the original request, with a status value of TRANSACTION_OVERFLOW.'


Comment:
[MD] Is there any purpose to having a BSN in the beacon, other than uniform packet format? It seems to be a useless artefact!


Comment:
[MD, 1] When the Coordinator Realignment Command is sent to a particular slave (as a result of an Orphan  Notification), the Short address field contains the orphaned device's short address. This assumes that no slaves are using IEEE addresses!

SuggestedRemedy:
If we're only going to allow 16bit addressing, leave as is. If we're going to allow IEEE addressing, define 'Short address field' as some special value (e.g. 0x00FE) for orphaned devices that were using IEEE addressing.


Comment:
[MD, 3] Primitive doesn't define what to do if a SYNC.request is made once a slave is already tracking the beacon.

SuggestedRemedy:
State explicitly that SYNC.requests shall be ignored if the device is currently tracking the beacon.


Comment:
[MD, 1] Table 51: Each bit in the bitmap of unscannedChannels has the value 1 if 'scan incomplete', or 0 if 'scanned or not requested'. The definition of 'incomplete' scan is not explicit. It states: 'The MLME shall then enable the receiver and record all beacons heard, until either the number of beacons found equals an implementation specified limit or until (aBaseSuperframeDuration * (2n + 1)) symbols, where n is the value of the ScanDuration parameter, have elapsed.'

SuggestedRemedy:
Add text to state: The MLME shall then enable the receiver and record all beacons heard, until either the number of beacons found equals an implementation specified limit or until (aBaseSuperframeDuration * (2n + 1)) symbols, where n is the value of the ScanDuration parameter, have elapsed. When either of these two events happens, the scan shall be considered 'complete' for that channel.


Comment:
[MD, 1] Table 69: aMaxLostBeacons has the value 4 and is defined as  'The maximum number of consecutive beacons the MAC sublayer can miss without declaring a loss of synchronization.' This implies that 4 beacons can be lost without any problem, and when the 5th consecutive one is lost a sync loss will occur. However section 7.5.4.1, page 147 states that  'Once the number of missed beacons reaches aMaxLostBeacons, the MLME shall notify the DME by issuing the MLMESYNC-LOSS.indication',  indicating that the sync loss occurs when the 4th consecutive beacon is lost.

SuggestedRemedy:
Change the definition of aMaxLostBeacons to: 'The number of consecutive beacons the MAC sublayer must miss to declare a loss of synchronization.'


Comment:
[TA, 2] Currently, the spec as written will only allow one active transmission at a time.  This means that a device which defers a transmission in the CAP to the next superframe will not be able to transmit in these GTSs (the requests will return TRANSMISSION_IN_PROGRESS) until that CAP transaction has completed.  This is rather limiting.  Likewise, if a GTS transmission is requested in the CAP, no more transmissions will be allowed in the CAP (will again return TRANSMISSION_IN_PROGRESS).

SuggestedRemedy:
If a transmission has not been completed (the confirm not returned) in the CAP, no other transmission may be started in the CAP until this has completed, otherwise it will return TRANSMISSION_IN_PROGRESS.  Likewise for each transmit GTS slot the device has.  However, the device shall be allowed one active transmission in the CAP and one active transmission for each of its GTS slots.


Comment:
[TA, 2] If the MAC performs its reevaluation in the next CAP,it will perform this immediately.  If more than one device does this, there will be a collision.

SuggestedRemedy:
Change the time when the evaluation of the remaining time is calculated to be at every backoff slot.  This will split the random backoff time to be partly in the current superframe and also carry on in the next - which should reduce the chance of collisions.


Comment:
[TA, 1] Please clarify what happens if the retransmission will not fit into the CAP.

SuggestedRemedy:
It has been assumed that this will be deferred until the next superframe.


Comment:
[TA, 1] Please clarify what happens if the retransmission will not fit into the current GTS slot, as it has merely been assumed that this will be deferred until the next superframe.


Comment:
[TA, 1] This paragraph is implementation specific and might not be the most effective way of guaranting no duplicates (In fact, it does not guarantee no duplicates!)

SuggestedRemedy:
Remove this paragraph and merely say 'The MAC sublayer shall not pass up duplicate packets'.  How this is achieved is up to the implementation.  Note that an investigation should be undertaken as to whether this is feasible using the current or an adjusted specification.  A proposal will be sent to the MAC editors.


Comment:
The sentence '...PLME: this interface is identical to the PLME-SAP interface.' is gramatically incorrect.

SuggestedRemedy:
I suggest '...PLME; this interface is identical to the PLME-SAP interface.'.


Comment:
The sentence 'The transceiver shall have three main states: transceiver disabled (TRX_OFF), transmitter enabled (TX_ON) and receiver enabled (RX_ON).' is incorrectly formatted.

SuggestedRemedy:
I suggest making a numbered list 'The transceiver shall have three main states:
1) transceiver disabled (TRX_OFF)
2) transmitter enabled (TX_ON)
3) receiver enabled (RX_ON)'


SuggestedRemedy:
I suggest 'MAC sublayer'.  Please make the change globally.


Comment:
The Table 21 extends over more than one page but the title says 'Table 21'.

SuggestedRemedy:
I suggest changing the title to 'Table 21 (continued)' on line 1 of page 44.  Please make the change globally.


Comment:
The sentence 'The chip rate is 300Kchips/s for the 868 MHz band and 600 kchips/s in the 902-928 MHz band.' seems incorrect.  The use of '300Kchips/s' and then '600 kchips/s' is inconsistent, which is correct?  Also, the '868 MHz' and then '902-928 MHz' is inconsistent.

SuggestedRemedy:
I suggest 'The chip rate is 300 kchips/s for the 868 MHz band and 600 kchips/s in the 915 MHz band.'


Comment:
The sentence 'The use of acknowledgment is discussed in detail in subclause 7.5.6.4' is missing a period.


Comment:
In column 3 'Conditions' row 2, line 2 the sentence '- PER < 1%' is missing a period.


Comment:
In Table 7 please verify the font size i.e., point size.  It appears that the last 2 rows are using larger font point sizes than the upper rows.

SuggestedRemedy:
I suggest you verify this table font usage.  Please make the change globally.


Comment:
The sentence 'The half-sine pulse shape used to represent each baseband chip is described by the following equation' is missing a colon

SuggestedRemedy:
I suggest 'The half-sine pulse shape used to represent each baseband chip is described by the following equation:'.


Comment:
The sentence '...20 Kb/s when operating in the 868MHz band and 40 Kb/s...' is incorrect.

SuggestedRemedy:
The symbol for kilobit per second is kb/s, not Kb/s or kbps.  Please make the change globally.  I suggest '...20 kb/s when operating in the 868MHz band and 40 kb/s...'


Comment:
The sentence 'The EVM for this standard is defined as' is missing a colon.

SuggestedRemedy:
I suggest 'The EVM for this standard is defined as:'.  Also, add a colon after 'where' or 'where:' which is on the same page, line 11.


Comment:
Change '(6.7.7)' to ', as defined in subclause 6.7.7'


Comment:
Some parts of the Clause 6 use 'octet' and others use 'byte'.  Should we only use one term?  I believe Clause 7 uses 'octet'.


Comment:
How is 'valid range' defined for the PIB parameters?  Is it the same as 'Range' in Table 20?  If so, what happens when the hardware does not support the full 'Range'.  For example, what if you attempt to set the Tx power to +10 dBm, but the device only operates at 0 dBm?

SuggestedRemedy:
Clarify 'valid range' and add text to address situation where hardware does not support the desired PIBAttributeValue.


Comment:
Add text or figure to clarify the pulse shaping operation (per comment from John Notor).

SuggestedRemedy:
See comment.  Possibly add example figure of symbol 0, similar to Figure 19, but with each chip represented by a half-sine shape.


Comment:
Change 'at least' to 'greater than or equal to'.


Comment:
Possibly add reference or text indicating that the MAC layer imposes constraints on the actual transmission times.


Comment:
[TA, 1] No retries are listed in this diagram.

SuggestedRemedy:
Update the diagram to include 3 retries before the confirm is sent.


Comment:
[TA, 3] 'If the security enabled subfield in the frame control field is set to 0, the device shall not perform security operations on the frame and shall process the frame as if it were in ACL mode (See subclause 7.5.9.3).'  This means that a device in secured mode will happily accept any MAC command without security!

SuggestedRemedy:
Fix this problem only for MAC commands, as the NWK layer may wish to accept unsecured frames (it is its responsibility to decide what to do in this case).  But we must protect the MLME, so change the paragraph to something like 'If the security enabled subfield in the frame control field is set to 0, and the message is a MAC command then the message will be rejected.  If it is a data frame, the device shall not perform security operations on the frame and shall process the frame as if it were in ACL mode (See subclause 7.5.9.3).'


Comment:
[TA, 1] Don't really understand what the frame counter does.

SuggestedRemedy:
Please include some additional information on what this is, what it does and how it works.  Also, what the significance of the counter reaching its maximum?


Comment:
[PAR, 3] Having two types of short address means that hardware must be relatively complex.  This complexity is reduced if we abandon one of the two modes of short address.

SuggestedRemedy:
Remove 8 bit short addresses from this and all other parts of the spec.


Comment:
[PAR, 3] When sending a message from one PAN Coordinator to another PAN Coordinator (or any other inter-PAN message), the target device may be on a different physical channel.  Changing using the SET.request primitive is dangerous (what if it's sending a beacon at the time!) and a better defined mechanism is required.

SuggestedRemedy:
Either: Add a field for the channel number, which is ignored if either of the GTS or indirection flags are set Or: Add an entry in the MAC PIB, called macDirectDataChannel.  When sending a message directly in the CAP the MPCS should set the PHY channel PIB entry to this value for the time of the transmission (and any acknowledgement) only, and should then set it back to the original channel in time for sending any beacons, or to listen on its own PAN again. This change is simple and required for orderly inter-PAN communications.  Consider adding a further MAC PIB attribute macPANChannel, which is the channel the PAN is operational on.  This would avoid the higher layers having to go via the DME to set values all the way down in the PHY.


Comment:
[PAR, 1] In the case that the destination addressing mode is 0, the security parameters of the PAN Coordinator should be used.  This is not clear.

SuggestedRemedy:
Change the text 'corresponding to the DstAddr parameter' to 'corresponding to the DstAddrMode and DstAddr parameters'.  Also consider changing '0 = no address (ignore addressing fields)' to '0 = no address (addressing fields omitted)' throughout the specification.


Comment:
[PAR, 1] PLME-SET-TRX-STATE cannot return SUCCESS.

SuggestedRemedy:
Remove the text 'either SUCCESS or'.  Also elsewhere, eg: page 63 line 50.


Comment:
[PAR, 3] Does anyone ever intend to use an IEEE addresses as the source address of a beacon?  It will be wasteful of bandwidth and  battery power, and also adds complexity to the system.

SuggestedRemedy:
Decide that a device without a short address cannot send beacons.  This seems reasonable as 1. a PAN Coordinator can always select its own short address, and 2. other coordinators are in contact with the PAN Coordinator, and no-one is proposing a system in which they are not allocated a short address within a short period of time following start up. (As far as I am aware?).  (There is a small risk that IEEE addresses in beacons may be required in the future, but I can't think of any good reason for this to occur).   (This resolution assumes that 8 bit short addresses have been removed from the standard). Remove CoordAddrMode from ASSOCIATE.request, and make CoordAddress a 16 bit short address only.  Similarly with Table 40 (PAN descriptor).  Also figure 46, Data request is simplified. See also 7.1.14.1.3 on page 95 line 44.


Comment:
[PAR, 3] The information available tells us whether the associate request has security, and whether the associating device is capable of security, but not whether or not security is to be used in this instance.  In the case that security is to be used, all MAC commands should have security.  This would include the association response.  However, as (typically) no keys have been set up at this point, this response cannot use security!

SuggestedRemedy:
Specify that a new device defaults to having no security.  Leave the higher layers to determine whether or not to use security for a device.  Communications via the data service will allow the devices to transfer keys, after which they may both move to secured mode.  This must be controlled by higher layers. I assume that a device in secured mode cannot associate with a coordinator for which is does not have security keys, but that it may move into unsecured mode, then associated (in an unsecured manner), after which some higher layer communication may cause the association to become secured. If this is correct then please make this assumption explicit.  If not, please clarify the sequence of secured and unsecured operations.


Comment:
[PAR, 1] Discussion of the detail of how to turn the receiver on, send data, etc. is misleading here, given that it will go indirectly.

SuggestedRemedy:
Remove this discussion of how a message is sent.  The text above saying that it is sent indirectly is sufficient.  This also applies elsewhere, such as page 69 line 48 and page 84 line 17.


Comment:
[PAR, 1] An indirect message can typically be retrieved any time it is pended.  It is not clear if this is allowed in this case. (Associate response)

SuggestedRemedy:
Add text saying that a device may retrieve a message before aResponseWaitTime by syncing to the beacon.  Perhaps also indicate that this is preferred behaviour.  (Consider also if this is not a sufficient behaviour - the exceptional mechanism is added to cater for 4 minute beacons, but in a 4 minute beacon system the system latency is 4 minutes thereafter, so there is little point having association any faster than this).


Comment:
[PAR, 1] A coordinator wishing to disassociate from a PAN Coordinator (as may happen in a Cluster Tree style network?) should not send this indirectly (I think).  Also, in this style of network, would the DeviceAddress for a slave be that of the PAN Coordinator or the device's local coordinator?  Worse, there is no easy way of telling whether this means 'disassociate this slave' or 'disassociate from this PAN Coordinator' (or even from another 'non-PAN' coordinator), although this might be clarified if the MAC stores its coordinators address.  Note that the higher layer seems to need to know this as well.

SuggestedRemedy:
Determine what the normal method of communication between a PAN Coordinator and an associated coordinator is, and clarify this here if necessary.   Specify that when a slave device requests to disassociate the disassociate address is that of its local coordinator.  Clarify the assumptions made.


Comment:
[PAR, 5] With the specification as it is written I understand that an attacker could send a disassociate message with the SEC bit set to 0 and from a false address, and the spoofed device would be disassociated, even though it usually uses secure operations.  This applies to all use of security in the system, and makes the security as it stands extremely vulnerable to numerable plausible methods of attack. (This was previously my comment (501) on D15, which has been rejected, which I believe is a mistake).

SuggestedRemedy:
Only secure messages shall be accepted from a device which is operating in secured mode. Other messages may be spoofed and must be rejected.


Comment:
[PAR, 1] I assume that if a Beacon Notify indication is sent but macAutoRequst is set (perhaps because sduLength > 0), then no data request is automatically sent.  Also, is a beacon notify indication sent when the PAN Coordinator bit is zero?

SuggestedRemedy:
Verify and clarify my assumption.  Determine and specify whether 'non-PAN'coordinator beacons are all sent up using this primitive.


Comment:
[PAR, 1] I assume that a GTS allocation may, in some cases, be pended on a beacon before aResponseWaitTime, and that it would acceptable for a device to retrieve this.  The text implies that this is not allowed.

SuggestedRemedy:
Either clarify the text to allow for this possibility, or remove the option of waiting for aResponseWaitTime and simply send the response indirectly.


Comment:
[PAR, 1] What are DevAddrMode and DevAddress set to on a slave device.

SuggestedRemedy:
Hopefully 8 bit short addresses will be removed.  DevAddress may either be unspecified (is it necessary to say this?) or the device's own short address, or the PAN Coordinator's short address.  Leaving it unspecified reduces effort in implementation and so is probably best.


Comment:
[PAR, 2] The PAN Coordinator's higher layers may like to know how long the GTS is.  Finding out by trial and error is not a good solution!

SuggestedRemedy:
Consider if this is likely to be required.  If so then add a GTSLength field.


Comment:
[PAR, 1] The text 'all associated GTSs have been deallocated' suggests that either all transmit GTSs or all GTSs to a single device (RX and TX) have been deallocated.  I think that this is not what is meant.

SuggestedRemedy:
Reword to 'GTS_DEALLOC, all specified GTSs have been deallocated', and change line 38 to spell out whether or not for instance a device's RX GTS is deallocated when its TX GTS has been. Alternatively, change this indication mechanism to provide figures for the length and Id of both RX and TX slots.  This may make it easier to keep GTS allocations up to date.


Comment:
[PAR, 5] If a slave allocates a number of GTSs and then either goes out of range, loses power or crashes, then the system will be crippled.  A mechanism is required for GTSs to expire.

SuggestedRemedy:
I understand that a proposal is being made to update the GTS mechanism.  Can the MAC team satisfy itself that the requirements given here are either invalid or supported. proposed resolution is given below in case it is helpful: A possible mechanism is given in my comment 422 in draft 15, repeated here: Require that a GTS slot should either be ''in use'' or ''confirmed'' within macGTSExpiryTime.  A TX slot is considered to be ''in use'' when a frame is sent to the PAN Co-ordinator during the GTS slot time. An RX only slot is considered to be ''in use'' when an acknowledgement is received at the PAN Co-ordinator within this time.  A GTS may be  ''confirmed'' using the GTS confirmation mechanism.  macGTSExpiryTime is defined in the PIB as the number of Superframes of no activity in a GTS, default 255 (or other, somewhat arbitrarily), after which an unused GTS shall be deallocated.  Specify that a PAN Co-ordinator deallocating a slot in this manner should issue a GTS allocation command indicating deallocation.  Also, specify that slot confirmation shall be the responsibility of the MLME of the network device. Further, decide and specify whether 0, 1 or 2 GTS.indication primitives should also be issued at the network device in the case that a SYNC-LOSS.indication primitive is issued when 1 or 2 GTSs are allocated to that device. This mechanism was previously rejected as it relied on GTSs being automatically deallocated on loss of synchronisation from the PAN Coordinator.  This automatic deallocation has now been removed (from almost all of the specification), which leaves a risk of attempting to send in a GTS without actually being synchronised, or even without being in range of the coordinator any more!


Comment:
[PAR, 1] If SetDefaultPIB is FALSE, then by not resetting some PIB parameters the system is left in a undefined state, for instance, by not setting macShortAddress to 0xFF the system may think that it is still associated, despite having just been reset!

SuggestedRemedy:
Make full reset (SetDefaultPIB = TRUE) the only option.  If there is some reason why this is not appropriate then specify the parameters which will be reset by all reset requests, which should include at least macCoordExtendedAddress, macCoordShortAddress, macDSN, macPANId, macShortAddress and macTxGTSId.


SuggestedRemedy:
Correct diagram to include a delay of almost a whole superframe.  I assume that a device transmitting or receiving a message at the time the timeout expired would defer for yet a further superframe.  Please clarify if this assumption is correct?


Comment:
[PAR, 1] An orphan scan is an attempt to find a PAN on which the device is associated.  The PAN Id may well have changed since the association first occurred.

SuggestedRemedy:
Rephrase 'or an orphan scan to locate a beacon frame containing a specific PAN identifier' to 'or an orphan scan to locate a PAN to which the device is currently associated'.  Consider a similar change to page 87 line 40, perhaps rephrasing 'a coordinator transmitting beacon frames containing a specific PAN identifier' to 'a coordinator to which the device is currently associated'.


Comment:
[PAR, 1] When scanning can the MAC handle data or general command frames?

SuggestedRemedy:
Clarify that when scanning the MAC will ignore all frames except beacon frames (for scan types 0-1), and coordinator realignment frames (for scan type 3), and perhaps that the MAC need not respond to other requests during this period.


Comment:
[PAR, 1] I read in D15 resolution comments that security errors are now returned in DATA.confirm primitives, and that in such cases a SECURITY-ERROR.indication is not issued.

SuggestedRemedy:
Clarify this in the text here.  Does this apply to many MAC commands as well?  Also applies to clause 7.5.9.4.1, page 162, line 49.


Comment:
[PAR, 1] This text says if SO = 15 the superframe will not be active after the beacon.  Is this what is intended?  What if BO = 15?

SuggestedRemedy:
Check that an inactive superframe is what is intended.  If so, add text 'If BO = 15 then the PAN will be a beaconless network and the value of SO will be ignored'.


Comment:
[PAR, 1] How does a higher layer know if any beacons were located at all before this indication?  Should it keep a timer?

SuggestedRemedy:
Consider adding a further loss reason of 'NO_BEACON', which means that no beacons were located.  This would be different from BEACON_LOST, which would mean that beacons were located but have since been lost.


Comment:
[PAR, 1] No SYNC-LOSS indication is issued if an Orphan Scan is in progress.  Note also that a device receiving a broadcast realignment command must check that the coordinator is its own before switching to the new channel and PAN Id!

SuggestedRemedy:
Revise this text to: 'If a device has received the coordinator realignment command (See sub-clause 7.3.2.5), and was not carrying out an orphan scan, and the source address is the IEEE address of the coordinator to which the device is associated, then the MLME shall issue this primitive with a loss reason of REALIGNMENT.'  (However, be careful as a non-broadcast coordinator realignment command may be sent by a backup coordinator, which may be a different device to that to which the device initially associated).


Comment:
[PAR, 1] Having sent this indication the MLME must decide whether or not to continue to track beacons.  How is this done?

SuggestedRemedy:
Specify that when this indication is sent the MLME does not continue to track beacons.  This allows higher layers to request it to recommence doing so where necessary.


Comment:
[PAR, 1] Opps! - Two values for SUCCESS!  Please also specify that 0xf6-0xff are reserved (if they are), and sort out the table borders.

SuggestedRemedy:
Remove the second value for SUCCESS, and make the other modifications suggested above.


SuggestedRemedy:
Change 'Table' to 'Figure'.  Also elsewhere in the document, eg; 7.2.2.1.


Comment:
[PAR, 2] Would it be easier to process the whole MAC payload for security rather than just the Command Payload field?  Note that such commands as 'data request' may be completed so late that the receiver may not be listening any more, but that this may be the case at the moment too (section 7.3.2.1, page 122 line 1).

SuggestedRemedy:
Consider what is intended.  Amend if that is written is not what is intended.


Comment:
[PAR, 1] Opps - 0x01 means two different things!

SuggestedRemedy:
Change the second 0x01 to 0x02, and the reserved codes to 0x03-0x07f.


Comment:
[PAR, 4] When sent to a coordinator that is not a PAN Coordinator, in  the presence of other coordinators (that are also not PAN Coordinators), which one should 1. send an ACK, 2. send a response?  (ie: what happens when the destination address is omitted and there are multiple 'coordinators' in range?)

SuggestedRemedy:
Specify that the Data Request command must have an address unless the coordinator is a PAN Coordinator.  Consider if there are other implications elsewhere, eg: section 7.5.6.2 page 150, line 42.


Comment:
[PAR, 4] If a MAC command addressed with the destination being an extended address (eg: Disassociation Notification command) then the requirement that the Data Request command only go from a short address if one is allocated means that the coordinator's MAC must be able to instantly map the short address to the extended address, so as to be able to send the correct message.  This requirement of mapping one to the other imposes a requirement on the MAC which is not necessary for almost all other parts of the specification, and may cause implementation to be unnecessarily complicated.

SuggestedRemedy:
Perhaps specify that a Data Request command to retrieve data from a beacon should go with the same address type as appeared on the beacon.  However, this doesn't work for non-beacon enabled networks.  This problem may be best solved by removing extended addressing as I understand is proposed in another comment.  Note also that POLL has no target address - a single coordinator is implied, but is it what is intended for a peer-peer structure? (If extended addressing is not removed then consider also section 7.5.5, page 149 line 5, which should be modified to avoid the MAC having to cross-reference every address it sees with the other sort of address, perhaps by specifying that information to a given destination address should always be sent in order).


Comment:
[PAR, 1] Is the little '+' at the start of the line intentional?


Comment:
[PAR, 1] PAN Id conflict notification is important - without it an RFD finding that it can now hear a different coordinator will be able to do nothing about the problem.  Worse, if another device identifies the problem and the coordinator moves to a new PAN Id, the RFD will remain talking to the wrong coordinator, (getting ACKs, and probably hearing beacons) and there is no mechanism to inform higher layers that there is a problem so that they can initiate an orphan scan.  Conflict notification should not be difficult to implement.

SuggestedRemedy:
Consider making PAN Id conflict notification mandatory for RFDs.


Comment:
[PAR, 1] How does the MLME know whether or not to include security on this command?

SuggestedRemedy:
Specify that SEC=1 for this command if the PIB attribute macSecurityMode is set to secured mode, and SEC=0 otherwise.  Likewise for PAN Id conflict notification.  Specify a mechanism by which GTS allocation commands sent spontaneously by the PAN Coordinator determine the value of  the SEC bit, perhaps 'by reference to the security mode of the target device', or similar.


Comment:
[PAR, 1] Under what conditions would code 0x04 ('have been successfully confirmed') be used, rather than 0x00 (SUCCESS)?  Do we need both?


Comment:
[PAR, 1] The number of aMaxMACFrameSize here conflicts with that in 7.1.12.1.2, page 93 line 9.  One seems to include the MAC header and the other doesn't.

SuggestedRemedy:
Change this line from 'in the MAC frame payload field' to 'in the MAC data frame payload field', and change page 93 line 9 to aMaxPHYPacketSize.  Or similar change.


Comment:
[PAR, 1] In the case of a coordinator which is able to hear beacons from the PAN Coordinator, does this number represent the last BSN received from the PAN Coordinator, or the next BSN to be sent by this device?

SuggestedRemedy:
Amend the Description to read 'The sequence number of the next beacon to be transmitted by this device, or the current beacon if transmission is currently in progress'.


Comment:
[PAR, 1] Elsewhere the DSN is described as being incremented immediately following the completion of a transaction.  The stored DSN will often be the next one.

SuggestedRemedy:
Amend the Description to read 'The current sequence number for data or MAC command frame where a transmission is in progress, or the next where none is in progress'.   Alternatively something simpler but less descriptive, such as 'The current sequence number for data or MAC command frames'.


Comment:
[PAR, 1] Making macMaxCSMABackoffs variable means that the time before a retry will not be repeated again is unknown.  Pick a number and stick with it.

SuggestedRemedy:
Consider removing from Attributes table and moving to constants table, with a value of 4.


Comment:
[PAR, 3] Promiscuous mode can clearly be used to snoop on other 802.15.4 PANs operating in the area (where security is not being used), and so serves to make 802.15.4 an easy target for malicious attacks, even if only of fairly trivial information. Accepting that it is useful for testing, can we find a compromise which achieves all the required objectives, but does not carry the increased risk of snooping?  (It's like being able to snoop someone else's Ethernet line [all too easy, and rather upsetting to watch], except that they don't have to be in your house to do it!) Note also that as it stands this functionality provides no way of snooping MAC commands or ACKs.  Also it complicates the MCPS-DATA.indication primitive, and doesn't necessarily provide a way of testing RFDs.

SuggestedRemedy:
Specify instead a parameter in the PHY such that PD-DATA.indication primitives are transferred to the DME instead of to the MAC, but that this functionality be unavailable (or at least well hidden/protected) in production items.


Comment:
[PAR, 1] macACLEntryDescriptorSet is not in a form where it may be accessed via SET and GET primitives.  This will make testing and/or conformance testing difficult, and will require some proprietary method for configuring values.

SuggestedRemedy:
Add a field macACLEntryDescriptorSetSize, as for other large items in the MAC PIB.  This should count the number of descriptors, each of the form in table 72.


Comment:
[PAR, 1] The field ACLSecurityMaterialLength in table 72 has no equivalent in table 71.

SuggestedRemedy:
Add a field macDefaultSecurityMaterialLength, with functionality similar to that of ACLSecurityMaterialLength in table 72.


Comment:
[PAR, 1] The field macDefaultSecuritySuite has a range of 0..0xff, whilst that for ACLSecuritySuite in table 72 has a range of 0..0x07.  These should be the same limits.

SuggestedRemedy:
Change macDefaultSecuritySuite's range to be 0..0x07.


Comment:
[PAR, 4] The receiver of a large frame must wait a LIFS period before sending an acknowledgement.  A LIFS period is a delay lasting greater than one backoff slot.  Consequently there is time for the CSMA mechanism to perform two consecutive CCA assessments and get CLEAR results, before the acknowledgement is sent.  This makes it likely that the acknowledgement will be trampled.

SuggestedRemedy:
Remove LIFS periods.  SIFS periods are the longest that can be accommodated without increased risk of the CSMA mechanism failing.  Note also that waiting a LIFS period would mean exceeding the aAckWaitDuration timeout for all long frames.


Comment:
[PAR, 3] As each backoff slot typically comprises only a few symbols it is important to be clear precisely the instant in the beacon frame from which we determine our timing.  ie: aUnitBackoffPeriod is 20 symbols, so whether the timing starts at the start of the beacon pre-amble (implied by the PHY spec) or at the start or end of the SFD is important, as these total 10 symbols between them!

SuggestedRemedy:
Clarify that the zero time is at precisely the instant that the PAN Coordinator beacon pre-amble (8 symbols) commenced, and that to avoid confusion as to the precise moment that the receiver identified the preamble, the instant of the start of the SFD (or some other point) should be used to accurately determine the timing.  This ensures that everybody interprets the specification in the same way. See also section 7.4.2, page 132, line 32, but note that this timing is primarily used with the MLME-RX-ENABLE.request primitive, and typically the number is never used by any other devices.  Note that in the case of CSMA backoff slots other devices are involved.


Comment:
[PAR, 2] With macMaxCSMABackoffs defined as it is in table 70 (MAC PIB Attributes), and given that NB is incremented before this comparison, I think that the equality is in the wrong place, and will currently result in one fewer back-offs being performed than is intended.

SuggestedRemedy:
Assess if this is the case.  If so, change the text 'less than' to read 'less than or equal to' and the text 'greater than or equal to' to read 'greater than'.  Note also that in table 70 the value of 0 for macMaxCSMABackoffs appears to have no meaning, so consider making it invalid, and if this is done, consider removing any specification of what should happen if NB is greater than macMaxCSMABackoffs, as this can never occur.  Change figure 57 to reflect any such changes.


Comment:
[PAR, 2] A definition of what is meant by a 'unique' beacon is required, as it is currently not clear.  Are all beacons unique because they have different BSNs, or different payloads?

SuggestedRemedy:
Specify that only up to one beacon from any single source address shall be reported, and any further beacons received from the same source address (operating on the same logical channel) shall be discarded.  This optimises the use of the limited resources which a device may have available for storing these large PAN descriptors.  Similarly page 142 line 12.


Comment:
[PAR, 1] Under what conditions would a device wish to track anything other than a beacon on its own PAN?  This sounds dangerous!

SuggestedRemedy:
Remove the text 'If macPANId specifies the broadcast PAN identifier (0xffff), a device shall be able to acquire beacon synchronisation with any beacon'.


Comment:
[PAR, 1] There is a implication here that an MLME-BEACON-NOTIFY.indication primitive may be sent even if the PAN Id does not match.  I think that this is not what is intended.

SuggestedRemedy:
Move this comment 'source PAN identifier does not match macPANId' to the start of this paragraph, thus clarifying the meaning.


Comment:
[PAR, 1] These beacons must be lost consecutively for it to be a problem.

SuggestedRemedy:
Change to 'number of consecutive beacons missed', or similar.


Comment:
[PAR, 1] Also transmissions will use CSMA, not just 'transmit GTS's.


Comment:
[PAR, 1] This text implies that devices must support all of the channels, ie: 868, 915 and 2G4.  This is not the case.


Comment:
[PAR, 3] This text specifies that when moving to another channel a PAN Coordinator shall first carry out a scan, then send a realignment command, then move to the new channel.  Both scanning and selection of a new channel (and indeed a reliable determination of what constitutes the communication requirements not being satisfied) must be carried out by the next higher layer, but there is no mechanism to allow the next higher layer to inform that MLME that it should send out a broadcast coordinator realignment, so currently it can never be sent.

SuggestedRemedy:
Either: specify that if a PAN Coordinator is currently sending beacons when an ED SCAN is requested then on completion of the ED SCAN the MLME will automatically send a coordinator realignment command, and then automatically change to the best channel, (or not change if they are all equally bad).  The MLME may then resume operation on the new channel.  (Higher layers not wanting this should stop sending beacons before issuing the ED SCAN). Or, as 1: most devices will typically have their receiver powered down when the realignment is broadcast, and 2: the channel quality is so poor that the system is, at this very instant, deciding to move to a new channel, we might conclude that this broadcast has an extremely low probability of getting through.  Adding a complex mechanism to initiate it then seems a bad idea, and the broadcast coordinator realignment command might be best removed.


Comment:
[PAR, 2] This mechanism for varying the number or size of GTSs based on the length of the beacon frame itself will be difficult to implement (especially if there are a lot of addresses suddenly pending!), and it seems to gain us very little.

SuggestedRemedy:
Replace it with a suitable requirement based on the maximum possible beacon length.  This at least is not going to change dynamically, and if it means that we get a bit more CAP time than we would have done (not sure if it does?) then that will probably be well used for sending messages in anyway.  There is little value in allocating a GTS which might not be there a moment later, so this should not be allowed.


Comment:
[PAR, 1] I assume that 'PAN Coordinator' is meant here.

SuggestedRemedy:
Verify that this is what was intended, and change as recommended, or remove the sentence if it is simply repeating the previous one.


Comment:
[PAR, 1] If the acknowledgement frame is not received (perhaps due to adverse channel conditions) then the CAP length will never change.

SuggestedRemedy:
Perhaps the PAN Coordinator should change the CAP length as soon as the GTS allocation command has been sent and has completed, whether or not an acknowledgement was received.  Even this doesn't help if the target missed the original message.  I understand that a major review of the GTS mechanism is in progress, which will hopefully solve this problem as well.


Comment:
[PAR, 1] This text rules out pending an indirect message to a target device whilst also sending it a message in a GTS.  I don't think it intends to do so, and this seems unnecessarily restrictive, and may not be easy to implement.

SuggestedRemedy:
Replace the text 'The addresses of those devices with messages…' with the text 'The destination addresses in those messages…'


Comment:
[PAR, 1] A default short address of 0x00ff has previously meant that the device is not associated. or that no valid value is available.  Referring to it as the default 'associated address' is confusing.

SuggestedRemedy:
What is meant by this?  Should it read 0x00fe, or does this represent a condition where the short address is not know?  Assuming the later, replace the text ', which may include the default associated address 0x00ff' with the text '(or 0x00ff if the target device's short address is not known)'.  Also consider replacing the word 'associated' which is reused later in the sentence with something that doesn't imply anything about the device's presence on the PAN - perhaps 'related'.


Comment:
[PAR, 5] It is important that the DSN field of the MAC Header NOT be used for integrity computation, as for indirectly transmitted frames the value that this field will contain is only known at the instant that the target device requests that it be transmitted (by sending a data request command). This means that there is very little time for the integrity code for be computed before it must be sent, which would place unreasonable demands on the implementation, and would either increase the device cost (in many instances), reduce the data throughput, or both.

SuggestedRemedy:
Either: specify that the DSN/BSN field shall take the value 0 for integrity calculations.  (I think this is easy and simple). Or: Specify that the DSN/BSN field shall be ignored for integrity calculations (and explain how - I think this is more difficult).


SuggestedRemedy:
Rephrase to 'security suite to the frame, using the security material', or similar.


Comment:
[RP] 802.15.4 needs to provide a mechanism for removing packets from the MAQ queue before they are transmitted or time out.  The reason is simple: in multi-hop networks (or any architecture that uses preemptive and/or passive ACK schemes), this mechanism can be used to significantly reduce network traffic. This clearly isn't an issue in mediated networks (e.g. star topology), but it's very important for others.

SuggestedRemedy:
Investigate and add a mechanism to remove frames from the MAC queue.


Comment:
[PAR, 1] In the case that the default security suite is used these flags might be set to TRUE, FALSE and TRUE respectively, rather an TRUE, TRUE and TRUE.

SuggestedRemedy:
Change the text to something similar to the text in line 7.


Comment:
[PAR, 3] From the formula A = … on line 21 I think that the first octet (octet 0) corresponds to the LEAST significant octet, and not the MOST significant octet as stated.

SuggestedRemedy:
Check my maths, and check if this is what is meant.  Perhaps replace 'most' with 'least'.   Also, this system in which bits which represent binary numbers separated only by a factor of 2 at different ends of a multiple byte stream conflicts with the simple description of 'A = …' given in line 21.  Suggested resolution is that 11146 should be turned into a 'STRING' in the same way that bits are turned into a string in a byte - ie: least significant is left. So 11146 is 0x2b8a which is written as an 'octet string' as 0x8a 0x2b, which makes the bit string 0101 0001 1101 0100, which makes much more sense as the multipliers for 128 and that for 256 are now adjacent, as described in line 21.  According to line 21, and to be consistent with the rest of the standard, the integer 1 should be represented as an octet string of 0x01 0x00 0x00 0x00, and as a bit string by 1000 0000 0000 0000 0000 0000 0000 0000.  Alternatively change line 21.


Comment:
[PAR, 1] Is this data really optional?  It appears that it is always used. (Section 7.6.3.3.1, steps 2 and 3).

SuggestedRemedy:
Remove the text '(optional)' in both cases.


Comment:
Table 61, This is a second instance of the SUCCESS enumeration and should be deleted.


Comment:
Table 66, Two different disassociation reason codes have the same value of 0x01. The “device wishes to leave” reason should presumably be 0x02.


Comment:
Table 70, macBeaconTxTime is required to be measured at the same symbol boundary within every transmitted beacon frame, the location of which is implementation specific. If we define this moment in our implementation as being the first symbol of the preamble (and this makes sense to us), then beaconTxTime is always zero. Likewise, the timestamp returned in MLME-BEACON-NOTIFY would always zero. Consequently there doesn’t seem to be any value in even having this timestamp.


Comment:
Clause 7.5.2.1.2 & Clause 7.5.2.1.3, Both of these scans require that the device accept beacon frames from PANs whose PAN IDs are unknown when the scan commences. Consequently, macPANId needs to be set to 0xffff for the duration of these scans. For the sake of clarity, it would be useful if these clauses specified this.


Comment:
This states that, in the case of there being no destination address field, the packet is only accepted if the source PAN ID matches the PAN ID of the PAN coordinator. Shouldn’t it be if it matches the PAN ID of the device (macPANId) rather than that of the coordinator?


Comment:
A destination-less packet should also be accepted if macPANId is 0xffff, as indicated by clause 7.5.4.1, page 147, lines 28-30.


Comment:
The title 'Annex A Service Specific Convergence Sublayer' is incorrect.

SuggestedRemedy:
I suggest 'Annex A Service specific convergence sublayer'.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
The reference to '...IEEE 802.2 type I LLC' is incorrect.  I scanned 802.2 for 'type I' and there are no hits, however, 'Type 1' exists.

SuggestedRemedy:
I suggest changing 'type I' to 'Type 1'.


Comment:
The table is using a double line on the first row.

SuggestedRemedy:
I suggest you change from a double line to a single line.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
The term 'E()' is vague; it looks like EO or E0 vs. 'E()'.

SuggestedRemedy:
I suggest you define or provide more detail.


Comment:
The sentence ending '...We first define the key stream blocks by' is incorrect.

SuggestedRemedy:
I suggest '...We first define the key stream blocks by:'; adding a colon.  This error repeats on pg 190, ln 5, ln 18.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
The title 'Annex C Protocol Implementation Conformance Statement (PICS) Proforma' is incorrect.

SuggestedRemedy:
I suggest 'Annex C Protocol implementation conformance statement (PICS) proforma'.  Please review the IEEE Standards Style Manual.  Please make the change globally.


Comment:
The use of an asterix '*Implementation Under Test (IUT) Identification' is unclear.  I looked for a asterixed notation for a full minute.

SuggestedRemedy:
I suggest the Editor review the IEEE Standards Style Manual and see if there is something better.  Please make the change globally.


Comment:
[PAR, 1] A device cannot be both an RFD and an FFD.

SuggestedRemedy:
Amend O.1 for FD1 and FD2 to read O.2.   (A possible alternative would be to amend FD1 = O, FD2 = M, but I think O.2 is more accurate).


Comment:
[PAR, 1] An FFD MAC should be able to operate with any higher layers, and so must be able to support all addressing modes.

SuggestedRemedy:
Hopefully 8 bit addressing will be removed, solving the problem.  If not then amend both FD4.1 and FD4.2 to M.


Comment:
[PAR, 1] A requirement is given for a device that is an FFD (FD1) but can't manage GTSs (-MLF3.1).  This device would not meet the requirements of an FFD, and so would be illegal.

SuggestedRemedy:
Amend this status to 'FD1: M' or 'FD1:M, FD2:O' as found elsewhere.


Comment:
The reference to '...referenced in Subclause 2.3.' is incorrect and needs a FM xref.

SuggestedRemedy:
I suggest changing to '...referenced in 2.3.'; deleting the word subclause (only use the word clause e.g., Clause 2) and create an xref to 2.3.  Please review the IEEE Standards Style Manual.  Please make the change globally.


SuggestedRemedy:
I suggest deleting the '-' in the FM xref table.


Comment:
Several editorial comments:Pg 383, line 3 change '... an PAN...' to '...a PAN...', Pg 384, line 3 change '... an PAN...' to '...a PAN...', Pg 385, line 3 change '... an PAN...' to '...a PAN...', Pg 386, line 3 change '... an PAN...' to '...a PAN...', Pg 340 line 3 change 'of procedure's' to 'of the MAC initialization procedure's', Pg 341 line 3 change 'of procedure's' to 'of the MAC initialization procedure's' Pg 342 line 3 change 'of procedure's' ...check all these charts for similar insertion of specific descriptors ... to 'of the MAC initialization procedure's' Pg 415, line 3  ?? '...the behavior 'for' parsing a MAC Protocol Data Unit (MPDU).


Comment:
Just a small note: please look over the figures in Annex D. In my copy of the PDF, the text flowed outside of the boxes, which made it a little difficult to read.


Comment:
Sentence beginning with, 'When performing dynamic ...' should probably be the start of a second paragraph.


Comment:
Change 'GST slots specifically for other systems to run' to 'GTS slots specifically for use by other systems'.


Comment:
Remove the word 'extensions' from the last sentence in this section.


Comment:
Change 'shall be lower' to 'will be lower'.  The word 'shall' is used for requirements in standards context.


Comment:
Change 'The BER calculations were calculated' to 'The BER results were obtained'.


Comment:
Change 'estimate the channel occupancy' to 'detect channel occupancy'


Comment:
Remove 'and variable frequency offset was located d meters away'.  Also, remove comma from this sentence.


Comment:
Possilby add '(Draft Standard)' after 802.15.3 to indicate that it is not yet released.


Comment:
The reference to '802.15.3 (2.4GHz DSSS)' in the Standards section is incorrect.

SuggestedRemedy:
I suggest deleting ALL references to '802.15.3 (2.4GHz DSSS)' in D17 and this annex or until such time that it is an approved standard vs. a draft.  This also applies to 802.15.2 and any other drafts that are referenced in D17.  Please make the change globally.

Response:
ACCEPT. 

Commenter accpted resolution (done in a different way)


Comment:
The sentence ending '...summary of international regulations that apply to the deployment of IEEE 802.15.4 devices.' needs a qualifier because the standard is full use (5-year life cycle).

SuggestedRemedy:
I suggest the sentence ending be changed to '...summary of international regulations that apply to the deployment of IEEE 802.15.4 devices at the time of publication.'; or something similar.


Comment:
Need to expand/update regulatory annex with material about Japanese and Canadian rules. This material is adding a lot of value to the draft.


Comment:
Check pg 550, line  9ff  F.5.2 Frequency spreading and averaging effects specific to IEEE 802.15.4


Comment:
pg 538 line 38 ref to FCC part 15 is... 'http://www.access.gpo.gov/nara/cfr/waisidx_01/47cfr15_01.html'


Comment:
At the time of writing 802.16 have already published a PHY and MAC standard, and should be mentioned as such in the diagram and in the list.802.15.1 should be mentioned in the list of standards in page iv

SuggestedRemedy:
Enter a box for 802.16 in the diagram. Move 802.16 to the list of standards defining the access technologies. Add 802.15.1 to that list.


SuggestedRemedy:
Change from 'Draft Standard for Part 15.4: Wireless...' to 'Draft Part 15.4: Wireless...'.


Comment:
Most PHY implementations will include some type of reset capability, however we may want to include a PLME-Reset primitive (as in 802.15.3) for completeness.


Comment:
Typo ' PLME-SYNC-BURST.confirm.confirm primitive with a...'


Comment:
Add '(see subclause 6.7.8)' to the description column of ppduLinkQuality.


Comment:
change '(6.7.9)' to ', as defined in subclause 6.7.9'.


Comment:
PHY layer Timing issues -> Missing Attributes in PHY PIB -> Reference: Table 20 Introduction: The MAC sublayer manages the timing of operations e.g. when a Beacon should be transmitted; at what point a Guaranteed Timeslot Commences. -> Concern to raise: The MAC must issue the PLME-SET-TRX-STATE command such that the transmitter will be settled and operating when the PD-Data.Request service primitive is issued. For the MAC to do this, a number of timing values are required. (1) The time taken by the PHY from the issuing of the PLME-SET-TRX-STATE command to the point where the transmitter is settled. (2) The time from the PD-Data.Request service primitive being issued to the PHY  to the point at which the first symbol of the preamble is transmitted.

SuggestedRemedy:
Proposed solution: It is proposed that two further read only attributes be added to the PHY PIB table: 1) Transmitter Enable delay and 2) Data Request Service Delay. The MAC will request these values at a suitable time, and may then issue the PLME-set.trx state commands with the correct timing.


Comment:
PHY layer Timing issues -> Missing Transceiver Enable Time -> Reference: Table 19 Introduction: This table in PHY specification gives a maximum TX to RX and RX to TX turn around time, Concern to raise: In addition to the transmit to receive switching time, MAC also relies on a maximum idle-to-TX and idle-to-RX switching time.

SuggestedRemedy:
Proposed solution: It is proposed that a value of 12 symbols is chosen.


Comment:
PHY layer Timing issues -> PLME-SET-TRX-STATE.confirm timing unclear -> Reference: Section 6.2.2.8.1 Introduction: Following the issuing of a PLME-SET-TRX-STATE.request to the PHY, the PHY is required to generate a PLME-SET-TRX-STATE.confirm for the MLME. Concern to raise: The timing of this confirm primitive is unclear. The text describes that the primitive will be issued with SUCCESS when the state 'has been changed' If the PHY delays the issuing of the primitive until the transceiver state change is complete, and the control loops have settled, when transmitting, the MAC will have little time in which to generate and issue the PD.data request primitive.

SuggestedRemedy:
Proposed solution: It is proposed that the primitive should be issued by the PHY when either 'the change of state of the transceiver is in progress' or 'the state change cannot take place' or 'the transceiver is already in the requested state'


Comment:
Software layer interaction -> Over Reliance on the DME -> References: 6.2, 6.2.2.5.2, 6.2.2.6.2, 6.2.2.6.3, 6.2.2.9.2, 6.2.2.10.2, 6.2.2.11.2 and others. Introduction: The DME is described as 'a layer independent entity', where the exact functions are not specified. It appears that the standard allows messages to be passed from the higher layers through the DME to the PHY. Concern to raise: A number of primitives are required to be issued to the PHY through the DME, and the confirmations, and indications returned to the DME. While the DME function is not specified, and the DME timing is not defined, this path should not be permitted. The DME appears to add no benefit to the standard, since primitives are now required to be passed through two software blocks before action can take place. A specific example of the issue can be seen in section 6.2.2.11.1 where the SyncBurst request is generated by the DME and issued to the PHY. It is unclear if the MAC or the DME in this situation is responsible for issuing the TRX state change primitive. If it is the DME then both the DME and the MAC would need to have visibility of the superframe structure, timing and the PHY state. This appears to be unnecessary.

SuggestedRemedy:
Proposed solution: Three possible solutions are proposed: (1) reword the sections where it is specified that commands are 'generated in', 'issued by' or 'received by' the DME to indicate a layer from the list (PHY, MAC, NWK, Application). Add text to explain that the primitive may be passed through the DME if a particular implementation is unable to use the standard service access points. (2) Fully specify the maximum and minimum timing delays allowed as primitives are passed through the DME (3) remove all references to the DME. This entity is not required, over complicates the standard, and can lead to poor implementations.


Comment:
Synchronisation burst -> Requesting Sync Bursts to be used -> Reference: 6.2.2.11, 7.1. Introduction: The Synchronisation burst is a packet allowing two devices to align clock frequencies where supported. Concern to raise: In a network requiring sync bursts, it is unclear how the network layer (or application) can cause the transmission of the bursts, and how the receiving device can ensure that they are received.

SuggestedRemedy:
Proposed solution: Either (1) An optional MAC PIB entry is used, and the values in the entry describe when Sync-Burst.request primitives are issued to the PHY.   OR, (2) A command MLME SYNG_GEN is defined. This would be similar to MLME-RX-ENABLE, but specify when a Sync Burst should be transmitted


Comment:
Synchronisation burst -> SYNC Burst Reception -> Reference: 6.2.2.11. Introduction: The Synchronisation burst is a packet allowing two devices to align clock frequencies where supported. Concern to raise: The Synchronisation burst can only be received by a device where the transceiver is in receive mode. The transceiver can only be switched into receive mode through the MAC layer. The draft proposes that there is no indication to the MAC layer that a synchronisation burst has been received. For the synchronisation burst to be used, the MAC layer must request that the receiver is turned on, but there is no indication that the burst has been received, and the transceiver may be returned to idle mode.

SuggestedRemedy:
Proposed solution: An indication should be passed from the PHY to the higher layers when a synchronisation burst has been received.


Comment:
[TA, 1] Not referenced anywhere in the spec.

SuggestedRemedy:
Remove this primitive from the spec, or define where it should be used in the MAC.


Comment:
[PAR, 1] The MAC description never specifies when this should be used, if ever.

SuggestedRemedy:
If it is never used then remove PLME-SYNC-BURST.request.  Alternatively specify when and why the MAC sends it or leave it as a place holder for later.


Comment:
No test modes have been defined for PHY.

SuggestedRemedy:
Define the following test modes:- Loopback mode, where the device under test sends back the decoded packet back to the test equipment. This simplifies the sensitivity measurements.- Continuous transmission mode. The transmitter continuously transmit a pseudo-random sequence of symbols. This is useful for transmit spectrum mask measurements.


Comment:
Can each PIB attribute be read AND written? For example, isn’t the value of phySymbolsPerOctet determined by the setting of phyCurrentChannel? And isn’t phyChannelsSupported a read-only constant? PIB attributes could be marked, in Table 20, as read-only or read-write. In this case, PLME-SET.request would return UNSUPPORTED_ATTRIBUTE if an attempt is made to write to a read-only attribute.


Comment:
Page 46 Line 50, Page 47 Line 7, Subtract operator is missing from the subscript.


Comment:
'The phrase 'This encryption algorithm is parameterized by the use of 128-bit keys and 128-bit block size.' is not perfectly correct. The cipher key in FIPS 197 can be 128, 192, or 256 bits. This draft chooses 128 bits. '

SuggestedRemedy:
Rephrase to indicate that 15.4 selects 128 from the possible FIPS choices.


Comment:
'Clarification requested for what happens when one of the GTS reallocation requests is not acknowledged. Current description says after attempts new CAP size is transmitted in beacon. What happens after  repeated tries for a reallocation receives no ACK, and the device never sends a GTS request to validate its allocations. '


Comment:
[PAR, 2] In the case that both the last known key sequence counter and last known frame counter are both equal to those being received, this would appear to be a duplicate, and should be rejected.

SuggestedRemedy:
Specify that if the last known frame counter is also equal to the received frame counter then the frame should be rejected.  Should this be indicated as a security error, or might it be caused by a problem in the underlying duplicate rejection mechanism?


Comment:
[PAJ, 1] Currently the primitive descriptions are using the word 'shall' indicating mandatory conformance.  This is not correct (other standards do not use shall in describing primitives).

SuggestedRemedy:
Remove all uses of the word 'shall' form the primitive descriptions.


Comment:
[PAJ, 2] The constant aMaxCommunicationsFailures refers to devices working out when they have become orphans.  Equally, the coordinators should also keep such tallies to help to determine when adverse conditions on the channel occur.

SuggestedRemedy:
Investigate and add a mechanism for a coordinator to keep track of the number of failures it makes to each device.


Comment:
[PAJ, 1] The number of pending addresses in a beacon is limited to 7.  There is no restriction on a coordinator being able to handle more than 7 pending transactions (it needs to handle at least 1).  Therefore, if it supports >7 pending transactions which 7 should the coordinator choose.

SuggestedRemedy:
Add clarification.  E.g. the first 7 received.


Comment:
[PAJ, 2] It would be useful to be able to store the maximum overhead required by the security suite on each device as this will affect the amout of data that can be sent directly to a device.

SuggestedRemedy:
Investigate and add an extra field in the ACL entry table.  If we do this we must also define how and when this information will be used.


Comment:
[PAJ, 1] Should we allow a PAN coordinator to request the allocation of a GTS for itself?  This would allow coordinators to talk peer-peer in a GTS.

SuggestedRemedy:
Investigate and adjust the text as necessary.


Comment:
[PAJ, 2] Before association can commence, a device must set the channel it wishes to associate on before sending the association request command.

SuggestedRemedy:
Add suitable text to call PLME-SET.request on phyCurrentChannel.


Comment:
[PAJ, 2] How do we notify transmission failures following .response primitives (e.g. MLME-ASSOCIATE.response)?

SuggestedRemedy:
Add a general MLME-TX-ERROR.indication primitive to notify the DME of any problems during the transmission.  In most cases, this could probably be merged with the MLME-SECURITY-ERROR.indication primitive.


Comment:
[PAJ, 2] In the descriptions of the command frames, the text is inconsistent as to whether it is describing outgoing or incoming frames.  Especially problematic is the descriptions of adding security.


Comment:
[PAJ, 2] The default of macPanId is incorrect.

SuggestedRemedy:
Change the default to 0xffff.  This makes it consistent with the short address.


Comment:
[PAJ, 5] The GTS mechanism as a whole is very difficult to implement and provides an unsatisfactory solution to the problem of GTS management as a whole.  The GTS mechanism essentially needs to be overhauled.

SuggestedRemedy:
A proposal for this will be submitted to the MAC editors.


Comment:
[MD, 4] It is felt that the current Acknowledgement packet contents are insufficient to avoid false Acknowledgements: ACKs are currently broadcast, with the ACK payload being the DSN of the packet being acknowledged. This means that if two devices within range of eachother send a packet with the same DSN at the same time,  they will be expecting the same ACK payload, so an ACK for one of the two devices will cause the other to incorrectly conclude its transmission was successful. It is difficult to quantify the likelihood of this scenario occurring, but it can be particularly bad for some Applications.

SuggestedRemedy:
The following solutions have been considered to improve the Acknowledgement mechanism (other solutions may be possible): 1- Include the CRC of the packet being ACKed as part of the ACK (replacing or alongside the DSN)Pros: - error probability in the order of 1/(2^16) (CRC only) or 1/(2^24) (DSN+CRC) - CRC provides more randomised error probability (no worst-case Applications) Cons: - ACK packet size increases by 1 or 2 bytes (does this cause a problem?) 2- Include the PID and shortAddress of the sender in the ACK (instead of the DSN) Pros: - ACK uniquely corresponds to sent packet - tidy solution if coupled with 'no IEEE addressing transmissions' amendment Cons: - packet size increases by 3 bytes - not a complete solution if IEEE-addressed transmissions are allowed 3- Increase the DSN size to 16bit Pros: - error probability in the order of 1/(2^16) Cons: - all packets 1 byte longer


Comment:
[TA, 2] In the CSMA testing performed with 3 boards, I decided that the easiest way to try this test was to set up two slaves on a network and pend a message for each of them in the beacon.  This would test the CSMA for the two data requests that would be sent for collisions. Currently, if the channel is deemed to be busy, 'the MAC sublayer shall discard the MSDU and issue the MCPS-DATA.confirm primitive with a status of CHANNEL_ACCESS_FAILURE.'  This results in the CSMA mechanism of one of the two slaves halting the sending of a data request after the beacon, and not sending it again until it sees the pended message again in the next superframe.  This is likely to mean that only one data request will ever be processed per superframe as the others will all fail, due to a CSMA failure. It is possible to see that this will have some negative implications on our proposed throughput.

SuggestedRemedy:
There are two possible suggestions to fix this. Treat a CSMA failure as one retry of the transmission 2.	Increase the backoff duration.  Note that this also affects all of the MAC commands and the text will need to be updated.


Comment:
[PAR, 1] The description suggests that the short address is used only by a device after association.  This is actually also used by a coordinator as its own short address.

SuggestedRemedy:
Adjust the text to take into account the usage of this by the coordinator.


Comment:
[PAJ, 2] General MAC observation.  We should attempt to simplify this specification wherever possible in order to meet the market requirements with a viable product.  Ther a lots of instances in MAC which are present to provide a 'potentially useful' feature and hence not absolutely necessary.

SuggestedRemedy:
Simplifications could include: 1) Not allowing frames to be transmitted using an IEEE address. 2) Removing the 8-bit short address and fixing one type of address throughout.


Comment:
Figure 24, Page 68, Figure 26, Page 81, Figure 74, Page 177, These figures, along with some Appendix D, refer to aMaxResponseTime. This PIB constant no longer exists, and these references should be replaced by aMaxResponseWaitTime.


Comment:
With the DeferTime parameter now defined as an appointment within the super-frame, it is clear that this primitive is intended to be used in beacon-driven networks as well as beaconless networks. In beacon-driven networks, the MAC is required to automatically turn on the receiver at certain moments during a superframe. However, this primitive can potentially over-rule this automatic behaviour. Some text should be added to clarify whether the MAC should make its automatic receiver enabling/disabling the priority or whether it should respect MLME-RX-ENABLE.request even if this primitive is contradicting the automatic states.


# 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.15 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")


