# Main

Comment:
We need to define a FCSL-DME SAP (or PAL-DME SAP).

SuggestedRemedy:
Define the primitives required to implement a DME.

Response:
ACCEPT IN PRINCIPLE. Push the DME into the MAC, expose only the MLME interface between the MAC and the PAL, i.e. it will be the MLME-PAL interface.  This will simplify the MLME clause as well as all of the MSCs.  Because the MLME is optional, this simply clarifies the description of the protocol.


Comment:
Some applications, for example, the transport and rendering of audio or video streams, require synchronized timers shared among different DEVs. An additional requirement might be greater accuracy (in terms of jitter bounds) or finer timer granularity than that provided by DEVs' local clocks synchronized to the beacon's Time Token.

SuggestedRemedy:
I propose a MAC service that enables layers above the MAC to accurately synchronize application-dependent timers shared among DEVs. The service is usable by more than one application within a DEV at a time.##See 15-03-0444-01-0030 for proposed text.

Response:
ACCEPT IN PRINCIPLE. Accept, but change to be a DME-PAL SAP.


Comment:
Is minimum and desired TU for a superrate counted per CTA or per superframe?

SuggestedRemedy:
Define as per CTA. See also 15-04-0456-00-003b-channel-time-ambiguities.doc, Issue 2.


Comment:
The standard is very unclear as to what libertues the PNC has to fit a super-rate request by changing the requested rate factor or to distribute TU unevenly among CTAs.

SuggestedRemedy:
Define stringent rules. Is the PNC allowed to change the rate factor or distribute TU unevenly? See also 15-04-0456-00-003b-channel-time-ambiguities.doc, Issue 3.


Comment:
7.4.1 says that CTA shall be allocated in the beacon with the smallest value in the location field first.Compare with 8.5.1.3: A Null CTA has the location set to zero. This means that all null CTA must come first in the beacon. This leads to inefficient parsing.

SuggestedRemedy:
Make an exception in 7.4.1: "The exception is null CTA (8.5.1.3), which shall be put as the last CTAB in the CTA IE." See also 15-04-0456-00-003b-channel-time-ambiguities.doc, Issue 4.


Comment:
The sentence "If a child or 802.15.3 neighbor piconet has the same superframe duration as the parent, then it shall use the value of the Change Beacon Number field in the Piconet Parameter Change IE from the parent's beacon in the Piconet Parameter Change IE in its own beacon." has a problems. The child or 802.15.3 piconet does not necessarily use the same beacon number as the parent piconet.

Response:
ACCEPT. (this is in section 3.3 of the document)


Comment:
There is some confusion regarding the potential for replay attacks and the security implementation in 802.15.3

SuggestedRemedy:
Provide an analysis that describes how the 802.15.3 protocol works.

Response:
ACCEPT IN PRINCIPLE.  Commenter needs to provide text for informative annex.


Comment:
The CTA Rate Factor field  in the CTA Status IE has the same name as a similar field in the Channel Time Request command.  However, these fields do not have exactly the same meaning (see 8.5.1.1).

SuggestedRemedy:
In Figure 37, change "CTA rate factor" to be "CTA Sub-Rate" (see 15-04-0131-03)


Comment:
What does the PNC respond with when you ask for the CTA Status IE of a terminated stream?

SuggestedRemedy:
The PNC should respond with a CTA Status IE that uses the UnassocID for SrcID and DestID with the requested stream index and the rest of the fields zero and ignored on reception. (see 15-04-0131-03)


Comment:
The phrase "A value of vendor OUI not understood by a receiving DEV causes the remainder of this IE to be ignored." is not well written.


Comment:
The MAC clause doesn't explicitly reference the channel change time.

Response:
ACCEPT IN PRINCIPLE. Change as indicated in 15-04-0131-04


Comment:
If a DEV takes over as PNC of a piconet, but does not support as many SPS sets as were supported by the previous PNC, how does this PNC reduce the number of SPS sets:

SuggestedRemedy:
Use the PCTM IE to wake up DEVs in that set and send the SPS Set Configuration response command to the DEV with error code 5: Set deleted by PNC. (see 15-04-0131-03)


Comment:
The standard currently indicates that the PNC will use the disassociation process to stop a neighbor PNC.  However, it is possible that a neighbor will have more than one CTA (it isn't expressly forbidden in the standard).  The PNC may want to terminate only one of the allocations and not both.

SuggestedRemedy:
Give the PNC the option to terminate the CTA without disassociating the neighbor. 

(May be an informative clarification, the PNC can terminate neighbor CTAs without disassociating.)


Comment:
In Table 77, the CAZAC sequence has an error that gives it a DC offset


Comment:
What does the PNC do in this case if a DEV associates with the Piconett Services Inquiry bit set? 
 1. Nothing. 
 2. Sends Piconet Services IEs for each associated DEV with a DEVID only (length 1). 
 3. Sends Piconet Services IEs for each associated DEV with a zero Vendor OUI and zero length Piconet Services field.

What does the PNC do in this case if it receives a Probe Request requesting Piconet Services IE?
 1. Nothing (and requestor may repeat the request) 
 2. Sends Piconet Services IEs for each associated DEV with a DEVID only (length 1). 
 3. Sends Piconet Services IEs for each associated DEV with a zero Vendor OUI and zero length Piconet Services field.

Response:
ACCEPT IN PRINCIPLE. Add a note to the piconet services IE that if the DEVID is 0, then this IE carries a reason code in the following octet (use a extra figure to show this). The reason codes are
0 - Reserved
1 - Broadcast of IE not allowed
2 - Piconet services IE not supported
3-254 - Reserved
255 - Other failure


Comment:
The MLME-CREATE-STREAM.request primitive shouldn't carry the stream index as parameter since that is a return value from the PNC in the following confirm.


Comment:
See 15-04-0216-03-003b-misc-mac-enhancements.doc, Multicast, page 10-11
Objective: Support for TCP/IP multicast.

SuggestedRemedy:
We need to support more than one multicast group which DEVs can join and leave and address data to. The document doesn't have a complete solution but some ideas about what we need to do.

Response:
ACCEPT IN PRINCIPLE. Resolve as indicted in the minutes and in 15-04-0384-00


Comment:
An Imm-ACK frame is used in the place of Response command frames for certain message exchange sequences. This was done when the Response command would not contain any payload data or when the scenario was considered "fire and forget".
The problem with this logic is a Response command frame, even if it has no command payload data, indicates to the source device that the Request command was received AND processed. An Imm-ACK frame can only ever indicate that the Request command was received because it is unlikely the Request command could ever be processed fast enough to generate the Imm-ACK 10 microseconds after the Request command was received. If a scenario is a "fire and forget" situation, then no confirmation is needed.

Response:
ACCEPT IN PRINCIPLE. Resolve as indicated in 015-04-0297-00 with the changes noted in the minutes.  Also changes to Clauses 6, 7 and 8 to match the new MSCs.


Comment:
See 15-04-0216-03-003b-misc-mac-enhancements.doc, MCTA, page 2-3
Objective: allow peer to peer MCTA

SuggestedRemedy:
Current: "MCTAs are a type of CTA that is used for communications between the DEVs and the PNC." Change: "MCTAs are a type of CTA that is allocated to a DEV after association. It is mainly used for sending commands"


Comment:
See 15-04-0216-03-003b-misc-mac-enhancements.doc, Scanning, Problem 2, page 7
Objective: Enable selection of best PNC based on signal rating.

SuggestedRemedy:
In Table 6, page 31, PiconetDescription, add a new parameter SignalRating. The field shall be a numeric value representing the receiver's measured SNR of the beacon of the PNC. The method of measuring SNR shall be Phy specific. For the 2.4 G Phy one could use a method similar to 802.11k which measures dBm at different levels at CCA active and CCA off and leave the SNR computation to the user. SNR can of course also be measured directly with different techniques.

Response:
ACCEPT IN PRINCIPLE. Add a parameter, named "SignalQuality", type "integer", vaild range "0-15", definition "Indicates quality of the received frame or beacon for this piconet.  The value is implementation depedent with 1 indicating the lowest quality and 15 the highest quality"


Comment:
See 15-04-0216-03-003b-misc-mac-enhancements.doc, Scanning, Problem 2, page 7-8
Objective: Enable selection of PNC to scan for and asscoiate with based either PNID or BSID or both.

SuggestedRemedy:
Replace the boolean "Open Scan" Parameter in the MLME-SCAN.request with a ScanForBSID boolean and also a ScanForPNID bit.  Parameter type and uses are booleans or enumeration of {open, bsid, pnid, both}

Response:
ACCEPT IN PRINCIPLE. Change the OpenScan parameter to be ScanType as indicated in 15-04-0384-00-003b.


Comment:
The standard should clarify that the ACKPolicy field in a MAC-ISOCH-DATA.request for a stream overrides the ACKPolicy specified in a MLME-CREATE-STREAM.request for the stream.

SuggestedRemedy:
Add the following sentence to the paragraph in this section: "The ACKPolicy value passed with this primitive overrides the ACKPolicy value set when the stream was created using the MLME-CREATE-STREAM.request primitive. "


Comment:
All MLME requests that result in the generation of a command sent over the air require a SrcId along with a DestId to handle the fact that the PNC actually has two different DEVIDs from which a command can be sourced. In some cases DEVs respond to commands differently based on whether the command was source from the PNC or a standard DEVID (for example, Channel Status Response).

Response:
ACCEPT IN PRINCIPLE. Add the OrigID as appropriate (for example association request).


Comment:
The use of a particular contention access scheme should be understood by higher layers that have a common design that could service any of the three PHY types in existence or in process. The PHYPIB_Type of clause 11.7 serves this purpose. Clause 6 (or elsewhere) should provide the parameter in clause 6 since it is common to all alternate PHY layers.

SuggestedRemedy:
Extract the PHYPIB-Type PIB entry from clause 11 and place it in clause 6. The PHY clause would then contain only the value for that PHY. zero is for 2.4GHz, and then we don't know the order of availability of alternate PHYs.


Comment:
A transmitting device's view of link performance currently relies on the transmitting device observing the number of retransmissions required.  No mechanism exists for reporting the receiver's view of link status back to the transmitter.  Link adaptation mechanisms such as rate fallback and fragment size control, which are performed by the transmitter, would benefit from an up-to-date view of receive status, ideally before retransmissions become necessary.   The actual receive status information available at the receiver will depend on the particular PHY.  Example parameters that may provide an indication of receive status are:·	Number of errors corrected by FEC·	RSSIThe ability to adapt transmit parameters based on a report of receive status would be of particular benefit for streams with high QoS requirements.

SuggestedRemedy:
A MAC mechanism should be defined that allows Immediate-ACK and Delayed-ACK frames to be used to report PHY specific recieve status to the transmitting DEV.  A number of fields in the MAC header are not used in the context of ACK frames (see 7.3.2.1 and 7.3.2.2), creating the opportunity to report receive status in ACK frames. See: 15-04-0304-00-003b-rx-status-feedback.doc

Response:
ACCEPT IN PRINCIPLE. Will allow the fragmentation field in the Imm-ACK and Dly-ACK frame to send PHY dependent data determined by MAC that relates to the previously sent frame.  Text will be generated to implement this in 7.2 and 7.3.


Comment:
Dly-ACK Frame length can be reduced using delayed negative acknowledgement frame format.

SuggestedRemedy:
We propose a Combined Dly-ACK Mechanism that uses  Dly-NACK or Dly-ACK frames properly according to the cases. Dly-NACK consists of MPDU ID blocks of lost frames. In combined Dly-ACK mechanism, Dly-NACK frame will be used when the number of well-received frames is more than the number of lost ones. Combined Dly-ACK Mechanism's frame length is always shorter than or equal to Dly-ACK mechanism's.

Response:
REJECT. There was questions regarding if the method could conclusively say that an MSDU was missed.  Also the efficiency gained was small for the complexity that would be added.


Comment:
Changes related to denial of new CTRq while PNC handover is in progress

SuggestedRemedy:
Reason code for Channel Time Response command should be modified to include clarifications of PNC Handover.

13 -> PNC handover in progress.
14-255 -> Reserved.


Comment:
Changes related to denial of new SPS Configuration Request while PNC handover is in progress.

SuggestedRemedy:
Reason code for SPS Configuration Response command should be modified to include clarifications of PNC Handover.

5 -> PNC handover in progress.
6-255 -> Reserved.


SuggestedRemedy:
"willbe" should be replaced by "will be".

Response:
REJECT.  This was an error in D17 that was removed before publication


SuggestedRemedy:
Current: "In the case where the DEV is requesting a specific MCTA interval, 8.4.3.3, the stream index shall be set to the MCTA stream value, 7.2.5." Add: "The DEV may use the target Id list to specify if it desires MCTA directed to BcstId or to PNCId"


SuggestedRemedy:
Current: "If the CTRqB is for an MCTA interval, only the CTA Rate Factor field and stream index shall be interpreted by the PNC. All other fields except the stream index and num targets fields shall be set to zero." Change: "If the CTRqB is for an MCTA interval, only the CTA Rate Factor field, stream index Num Targets and Target Id list shall be interpreted by the PNC. All other fields except the stream index and num targets fields shall be set to zero. If Num Targets is set to 0, the destId shall be interpreted as the PNCId. If Num Targets is set to 1, the PNC may use the Target Id as the destId of the MCTA. No other values of Num Targets shall be legal"


Comment:
See 15-04-0216-03-003b-misc-mac-enhancements.doc, Piconet announcements, page 5-6
Objective: Enable a new more efficient method of piconet announcements.

SuggestedRemedy:
Combine the octet wide field DEV status in table 31 of association IE and the octet wide field DEV info utility in table 62 of PNC information IE into one octet wide field called DEV membership status. The recommended fromat is 6 reserved bits, followed by one bit each for Authnetication status and Association status. Use this new field in the place of both DEV status and DEV info utility.

Response:
REJECT. The current scheme provides timely information and allows a DEV to conclusively know the current status of the piconet.  The sending of the PNC info command also allows a newly associated DEV to immediately find out all of the DEVs that are a member of the current piconet.


Comment:
The standard should clarify that the PNC must support all 256 possible stream indexes.  This is necessary because one manufacture may do so and a PNC from another vendor must be able to accept a handover from this first PNC, including active stream information.

SuggestedRemedy:
Add the following sentence to the last paragraph in section 7.2.5: "A DEV shall support each possible stream index value."


Comment:
Currently, stream indexes 0x01 through 0xFC plus stream 0xFF are available to the PNC for assignment to isochronous streams. Stream indexes, 0x00, 0xFD and 0xFE are currently special stream indexes reserved for special purposes.  In an implementation, it would be more practical to have a single contiguous range of stream indexes of 0x01-0xFC available for allocation to isochronous streams.

SuggestedRemedy:
Add the following Stream Index definition:
"- 0xFF reserved for future use."

Response:
ACCEPT. See 15-04-0138-01 for formatted text. (item 2.7)


Comment:
The minimum length value is listed as 2. This does not match the fields in the IE or the fact that Clause 8.3.2 discusses sending Piconet Services IEs with a length of both 0 and 1.

SuggestedRemedy:
Replace "Length (=2 to 131)" with "Length (=0 to 131)"

Response:
ACCEPT.  See 15-04-0138-01 for formatted text. (item 2.11)


Comment:
The standard should clarify what the first MSDU number is when a new stream is started. This has an impact on the requirements for duplicate detection. Is the MSDU number always reset to zero, or does the MSDU number continue from the last time the stream index was assigned?

SuggestedRemedy:
Add the following sentence to the last paragraph in the section: "The MSDU number counter for an isochronous stream shall be set to zero when the stream index for the isochronous stream is set as described in <.8.5.1.1>."

Response:
ACCEPT. See formatted text in 15-04-0138-01 (item 2.9).


Comment:
There seems be a major flaw with Probe in that the Request Index field is for the CTA Status IE, yet a DEV is not allowed to request this IE.

SuggestedRemedy:
Table 51:
In the "CTA status" row, under the column "Dev allowed to request?", change "Shall not request" to  "May request". 
Table 52:
Change table title to "Rules for responding to IE requests in a Probe Request command". In the "CTA status" row, under the column "PNC receives request from DEV" change "Shall ignore" to  "Shall respond".

Response:
ACCEPT. See 15-04-0138-01 for formatted text (item 2.12)


Comment:
In many situations, channel time allocations from superframe to superframe will remain unchanged. However, currently, a DEV is required to decode and process all channel time allocation IEs for each beacon frame received. 
An amendment is proposed where a new bit is defined in the MAC header for beacon frames that indicates when the IEs for a particular beacon frame are unchanged from the previous beacon transmitted. If a DEV receives a beacon frame with this bit set, and the DEV correctly received the previous beacon frame, the DEV can skip decode and processing of the IEs in the current beacon.

SuggestedRemedy:
Repair as specified in document 04/138r2.


Comment:
The current definition of a Channel Time Allocation IE requires multiple Channel Time Allocation Blocks per Async Group. 
See also CID 42.


Comment:
A clear real example of FCS calculation should be added to the standard.

Response:
ACCEPT IN PRINCIPLE. The commenter needs to provide the informative annex.


Comment:
For each Response command that contains a Reason Code, a "catch all" reason code value should be defined so that a developer has a clear choice as to the reason code to use if a situation occurs where none of the existing reason codes apply. The standard developers can not be expected to think of every possible scenario in which the command may be issued. Perhaps the code 0xFF should be defined as a "unknown" reason code for all commands with a reason code.

Response:
ACCEPT IN PRINCIPLE. Change as indicated in 15-04-0384-00.


Comment:
Part of the multi-CAP (eCAP) proposal. It is requested that a single bit be added that indicates the presence of eCAP in the piconet.

SuggestedRemedy:
For piconet mode field figure, change reserved bit 5 to be ECAP used bit. Reserved bits will change to b6 and b7. Following the paragraph, If a bit for the CAP data, ….. If ECAPs are present, then they will follow the same rules as above. This shall apply to all ECAPs within the current superframe. Following SEC mode field encodings table, The ECAP used bit shall be set to one if the PNC will be using Extended CAP in the superframe.


Comment:
Part of the multi-CAP (eCAP) proposal. This defines the use of BcstID for extended CAP.

SuggestedRemedy:
Following the paragraph, If the CTA is for a neighbor …… If the CTA is for Extended CAP (ECAP), 8.4.3.y, the DestID and SrcID shall both be the BcstID.


Comment:
Part of multi-CAP (eCAP) proposal. The current channel time request has provision for requesting additional management time slots in superframes to "hint" to the PNC that the DEVs feel starved. A similar feature should be for DEVs to request additional eCAP opportunities. Suggest that the current structure applies to the contention method currently in use (that is PHY specific).

SuggestedRemedy:
Add the text to indicate that the request for additional management CTAs also applies to eCAPs.


Comment:
Part of the multi-CAP proposal. This provides the details for how the eCAP operates.

SuggestedRemedy:
8.4.3.y Extended CAP (ECAP) Extended CAP provides additional opportunities, within the CTAP, for the PNC and DEVs to use for commands or data. ECAP allocations shall take on the same CAP control bits of the Piconet Mode field of the Piconet Synchronization Parameters field, 7.3.1. {it may be better to have additional bits defined that could differentiate between the CAP and ECAP use}. The PNC controls use of ECAP and distribution. The CAP control bits field, 7.3.1, includes the ECAP use bit. ECAP allocations are determined by the PNC, although DEVs may request the distribution, capacity, and number via the channel time allocation request command, 7.5.6.1. The PNC is not required to grant the ECAP request. ECAP follows the rules of backoff that extend between superframes, 8.4.2, for CAP.


Comment:
Part of the multi-CAP (eCAP) proposal. This deals with the peer to peer MCTA and provides suggested text.

SuggestedRemedy:
8.4.3.z Peer-to-Peer MCTA Peer-to-peer operations are allowed for control and data frames. All operations in this contention based operation shall use Imm-ACK and follow the backoff rules, 8.4.3.4, of Management CTAs. Peer-to-Peer control frames may be used as an alternative to open and association MCTAs. Peer-to-peer MCTAs allocations are determined by the PNC, although DEVs may request the distribution, capacity, and number of MCTAs in a superframe via the channel time allocation request command, 7.5.6.1. The PNC is not required to grant the MCTA request.


Comment:
Part of the multi-CAP (eCAP) proposal. This clause requires extensive edits to allow for the use of peer to peer; having non-contention MCTAs present without contention MCTAs, to make it read clearer.

SuggestedRemedy:
Make the changes mentioned in the comment to update this subclause.


Comment:
Part of multi-CAP (eCAP) proposal. Minor edits are required in the various sub-subclauses of this subclause to align the text with the changes in MCTA and eCAP.

SuggestedRemedy:
Edit the subclauses in 8.4 as necessary to account for the MCTA and eCAP changes.


Comment:
Current association procedure is longer and centralized. New node (trying to join) does not have information about associated nodes in the piconet and their DEVIDs.

SuggestedRemedy:
Document: 04/0144 Submission Title: [Associated Devices Information Element and Faster Association]	 Date Submitted: [17 March, 2004]	 Source: [Sunil Jogi, Prashant Wason, Balaji Holur, Manoj Choudhary (presenter), Wonyong Yoon, Yongsuk Kim] Company [Samsung India Software Operations/Samsung Advanced Institute of Technology]

Response:
REJECT. The proposal has unresovled flaws.


Comment:
The use of unidirectional directed CTAs for carrying acknowledged higher layer traffic often results in poor channel time utilization when higher layer transport protocols such as TCP stop and wait for acknowledgement.  Throughput can in practice be limited by the transport layer acknowledgement window size.

SuggestedRemedy:
A mechanism should be defined that allows the sender to relinquish ownership of a CTA to allow the receiver to send.  The mechanism should be restricted to directed CTA.  CTA reversal can be achieved using the following procedure. See: 15-04-0303-00-003b-fast-cta-reversal.doc


Comment:
Home network standard specifies TCP streaming  as a basic service TCP application. The sender can proceed its transmission after receiving ACK of TCP/IP from the receiver. In current spec., only Src DEV can send data during the CTA. TCP ACK Latency with one way CTAs will severely impact the speed of opening up the TCP window.

SuggestedRemedy:
We propose the new type of CTA named 'two-way CTA'.  In existing CTA, only src DEV can send data to the other devices.  In two-way CTA, even the dest DEV of the CTA can send data to src DEV of the CTA when the src DEV doesn°Øt have data to send anymore.   Two-way CTA is efficient for TCP streaming applications


Comment:
We suggest the clarification in IEEE Standard 802.15.3 with the goal that new isochronous streams allocations (using Channel Time Request) and power saving changes (using SPS Configuration Request) should not be accepted by the current PNC while "PNC handover procedure" is in progress. During the PNC handover procedure, IEEE Standard 802.15.3 should include the provision that current PNC shall not accept (by negative response) any new Channel Time Requests and SPS Configuration Request commands.

SuggestedRemedy:
Following paragraphs should be added in description of "PNC Handover" for clarifications.The current PNC shall not accept any new CTRq, during the PNC handover procedure, after it has sent the PNC Handover Information command.  It shall respond with the reason code "Handover in Progress" in the Channel Time Response command. The current PNC shall not accept any new SPS Configuration Request command, during the PNC handover procedure, after it has sent the PS Set Information Response command.  It shall respond with the reason code "Handover in Progress" in the SPS Configuration Response command.

Response:
ACCEPT IN PRINCIPLE. Resolve as in CID 8, this only needs to be defined in one location.


SuggestedRemedy:
Following paragraphs should be added in description of "Dependant PNC Handover" for clarification.The current PNC shall not accept any new CTRq, during the PNC handover procedure, after it has sent the PNC Handover Information command.  It shall respond with the reason code "Handover in Progress" in the Channel Time Response command. The current PNC shall not accept any new SPS Configuration Request command, during the PNC handover procedure, after it has sent the PS Set Information Response command. It shall respond with the reason code "Handover in Progress" in the SPS Configuration Response command.

Response:
ACCEPT IN PRINCIPLE. Add the following paragraph to 8.2.3 following "... except in the preceeding beacons." 

'The current PNC shall not accept any new commands that would change any of the information that will transferred to the new PNC once the PNC handover process has been initiated.  The PNC shall refuse these requests with the Reason Code field set to "Handover in progress" for commands that have this reason code defined.'


SuggestedRemedy:
"PS Information Response command" should be replaced with "PS Set Information Response command".

Response:
ACCEPT IN PRINCIPLE. The new MSC uses an oval to implicate all of these commands without explicitly indicating them.


SuggestedRemedy:
"transmsision" should be replaced by "transmission".

Response:
REJECT. This was an error in D17 that was fixed before publication.


SuggestedRemedy:
Current: "Management CTAs (MCTAs) are identical to CTAs except that the PNCID is either the SrcID or the DestID in the CTA and the stream index is set to the MCTA stream index, 7.2.5." Change: "Management CTAs (MCTAs) are identical to CTAs except that the stream index is set to the MCTA stream index, 7.2.5."


SuggestedRemedy:
Current: "A DEV may request the frequency of MCTA allocations by sending a Channel Time Request command, 7.5.6.1, to the PNC with the stream index set to the MCTA stream index, 7.2.5, and the CTA Rate Factor, 7.5.6.1, set to the DEV's desired interval for uplink MCTAs, the Num Targets field set to one and the Target ID field set to the PNCID." Change: "A DEV may request the frequency of MCTA allocations by sending a Channel Time Request command, 7.5.6.1, to the PNC with the stream index set to the MCTA stream index, 7.2.5, and the CTA Rate Factor, 7.5.6.1, set to the DEV's desired interval for uplink MCTAs. The Num Targets and Target Id fields may be set to 0 for MCTA directed to the PNC or the Num Target may be set to 1 and the Target Id field to BcstId for broadcast MCTA."


Comment:
New clause. See 15-04-0216-03-003b-misc-mac-enhancements.doc, Open Asynchronous Timeslot, page 4
Objective: new reservation less option for asynchronous data slots. Should be merged and harmonized with corresponding proposal from Jay Bain.

SuggestedRemedy:
"The PNC may reserve channel time for asynchronous data to be shared among DEVs. This is done by assigning CTA blocks with SrcId=BcstId, DestId=BcstId and StreamIndex=0xFF. Access to an Open Asynchronous CTA shell be done by using Slotted Aloha, see 8.4.3.4."
"A DEV may request that the PNC assigns Open Asynchronous Channel Time with certain intervals by sending a Channel Time Request command, 7.5.6.1, with DestId set to BcstId and Stream Index set to 0xFF"
"The PNC shall respond with a CT response command indicating its OACT policy. The policy may change based on the DEV's request. The PNC may also reject the request if OACT is not supported by setting the reason code to 'request denied'. A request is considered successful if any OACT interval is allocated"
"A DEV should indicate that is no longer needs OACT by sending a CT request with the Stream Index set to oxFF and all time fields set to 0. The PNC may use all requests and terminations to determin when OACT allocation is needed"
"The PNC shall with certain intervals announce its OACT policy by using the CTA status IE. DestId and SrcId shall be set to BcstId and StreamIndex shall be set to the OACT Stream Index"
"A DEV may ask the PNC for the current OACT policy by sending a probe with the Information Request field set to CTA Status IE and the Request Index set to 0xFF"
Change Table 51, CTA status request in probe shall be allowed for a DEV.
For clause 7.2.5: add Stream Index 0xFF, Open Asynchronous Channel Time


SuggestedRemedy:
Change to: The PNC shall may broadcast the piconet information using the PNC Information command, 7.5.4.2, after a DEV becomes a member of the piconet. "The PNC shall announce all members by sending one or more association IEs in the beacon. The association IE for every member shall be issued periodically throughout the DEV's membership in the piconet. The period between two announcements shall not exceed mBroadcastDEVInfoDuration. The exact scheme of association IE rotation is implementation specific"


Comment:
The standard currently indicates that a DEV can send a frame to any destination DEV in any CTA assigned to it. The standard should clarify that, in the case of isochronous stream data, a stream between the source and destination DEV must exist. Or, in other words, clarify that a DEV cannot send a frame to a destination DEV using a stream index that the destination DEV is not aware of.

SuggestedRemedy:
In the 3rd paragraph of the section, change "DEV is different that that indicated" to "DEV is different than that indicated"
Add the following sentence to the same paragraph: "All data transmitted by a source DEV in a CTA shall use a stream index for an established stream from the source DEV to the destination DEV."

Response:
ACCEPT IN PRINCIPLE. In the 3rd paragraph of the section, change "DEV is different that that indicated" to "DEV is different than that indicated"
Add the following sentence to the end of the same paragraph:
The stream index in a transmitted frame shall be one of
 - the asynchronous stream index, xref 7.2.5
 - the MCTA stream index, xref 7.2.5
 - an establishd stream from the source DEV to the destination DEV.


Comment:
The standard should clarify that the transmit power used between two devs in a CTA is not restricted by the Max Tx Power broadcast in the beacon.

SuggestedRemedy:
In the first paragraph of this section change "Two forms" to "Two independent forms". 
Add the following sentence to te same paragraph: "The transmit power used in a CTA is not limited by the transmit power used in the CAP."


Comment:
The standard should clarify when a specified inter-frame spacing is to be considered a "minimum" value and when a specified inter-frame spacing is to be considered an exact value. For example, the SIFS between a data frame and a corresponding ack frame needs to be 10us in order to prevent the sender of the data from resending the data. However, the SIFS between the ack frame and the next data frame sent is a minimum value. For example, the source of the data may not have another data frame to send until 20us after the ack was received. Clarify MIFS is a minimum value (with limits within an extended beacon) and that RIFS is a minimum value.


Comment:
The standard should clarify the definition of the Max Frames field in the Dly-ACK frame because it could be interpreted in two different ways.   Interpretation #1:  The maximum number of frames a source DEV can send before it requests a Dly-ACK from the destination DEV. For example, if Max Frames is six, the source DEV can always send six frames in each Dly-ACK burst, including both retransmitted frames and new frames.   Interpretation #2:  The maximum number of frames the destination DEV can store, implying that the source DEV can never attempt to send more frames than the destination DEV can store considering the fact that the destination DEV must send received frames to higher layers in order. In other words, after sending the first six frames, the next transmission will be one to six frames depending on which frames were received correctly at the destination. For example, if the first of the original six frames was not received correctly, the next transmission could only contain one frame, because 5 receive buffers are occupied with frames 2 through 6. If the 3rd frame of the original six was not received correctly, the next transmission could contain at most four frames (a retransmission of the original 3rd frame plus 3 new frames).

SuggestedRemedy:
In second to last sentence of second paragraph, change "The destination DEV may change the Max Burst values in each Dly-ACK frame." to "The destination DEV may change the Max Burst and Max Frames values in each Dly-ACK frame."

Response:
ACCEPT. See 15-04-0138-01 for formatted text (item 2.15)


Comment:
The PNC allocates a unique stream index value for each isochronous stream in the piconet. The current requirement is that the PNC assign an unused value other than the asynchronous stream index to a new stream. There is no other requirement on how a stream index should be assigned. For example, if the PNC has assigned stream indexes 0x01, 0x02 and 0x03, and stream 0x01 is terminated, the PNC may use stream index 0x01 for the next stream created.
Because this is a radio system, commands between devices can be lost for various reasons. Therefore, it is reasonable to expect that at times DEVs is the system may not have consistent information about which streams are currently active in the system. If the PNC is allowed to immediately reuse a stream index, it is possible that the stream index could be used before all DEVs in the piconet are aware that the previous stream with that same stream index has been terminated. This could lead to many unforeseen problems.
An amendment is proposed where the PNC would be required to "cycle through" all available unused stream indexes before re-assigning a stream index that was already assigned. Once all stream indexes have been used, the PNC would then use the least recently used stream index. 
Although not fullproof for a piconet where the maximum number of streams are allowed at one time, this is a significant improvement over the current situation and it does not complicate the implementation of the protocol.

SuggestedRemedy:
Clause 8.5.1.1:
Change: 
"The PNC may update the beacon with the newly assigned isochronous stream CTAs before it receives an ACK to the Channel Time Response command from the originating DEV."
To:
"The PNC shall assign all possible stream index values before reusing a stream index value that was previously assigned. Once all possible stream indexes have been assigned, the PNC shall assign the stream index value that has been least recently assigned to a stream.
The PNC may update the beacon with the newly assigned isochronous stream CTAs before it receives an ACK to the Channel Time Response command from the originating DEV."

Response:
ACCEPT IN PRINCIPLE. Below the second paragraph 
in 8.5.1.1 be replaced in the itemized list with the following: 

--- The Stream Index field is set to an unassigned nonzero value; this 
indicates that the isochronous stream has been allocated channel time. The 
PNC should assign the least recently used Stream Index available.


Comment:
The PNC allocates a unique DEVID value for each associated DEV in the piconet. The current restictions in the standard are:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet."
and:
"the PNC shall not reuse the same DEVID of that DEV until at least two times the ATP duration for that DEV has passed."
An amendment is proposed where once all DEVIDs been assigned once, the PNC would then use the least recently used DEVID for which the two times ATP duration has expired. 
See also 17

SuggestedRemedy:
Change:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet."
To:
"The PNC shall assign all possible DEVID values before reusing a DEVID value that was previously assigned. Once all possible DEVIDs have been assigned, the PNC shall assign the available DEVID value that has been least recently assigned to a device."

Response:
ACCEPT IN PRINCIPLE. See 15-04-0384-00 for text.


Comment:
To reduce the likelihood of overlapping piconets having the same PNID, the standard should indicate the the selection of a PNID should be randomized if some fashion.

Response:
ACCEPT IN PRINCIPLE. Change as indicated in 15-04-0384-00


Comment:
To reduce the likelihood of overlapping piconets having the same DEVIDs assigned, the standard should indicate the the selection of the first DEVID assigned should be randomized if some fashion. (The standard already indicates that DEVIDs should be assigned in increasing order). See also 15.

SuggestedRemedy:
Change:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet."
To:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet. The first DEVID assigned shall be randomly selected by the PNC."

Response:
ACCEPT IN PRINCIPLE. Change:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet."
To:
"The device IDs (DEVIDs) shall be assigned in sequence (increasing order) by the PNC except when PNC wishes to use a DEVID that was freed up after a DEV has left the piconet. The first DEVID assigned should be randomly selected by the PNC."


Comment:
The standard contains the following requirement from clause 8.6.2:
"The PNC shall send CTA IEs, BSID IE, and the Parent Piconet IE, if present, only in the beacon frame and not in any of the broadcast Announce commands."
In an implementation it will be complicated and difficult for a PNC to know, when it is considering whether or not to grant a DEVs stream creation request, whether or not granting that request would cause the above requirement to be violated. This limitation is unnecessary and should be removed.
See also 21.


Comment:
Multiple Multicast addresses are needed along with a means of allocation and association.


Comment:
How is "maximum number of allowed retries" determined? Is it set per stream? Per frame?

Response:
ACCEPT IN PRINCIPLE. Add "RetryLimit" to the MAC-ISOCH-DATA.request and MAC-ASYNCH-DATA.request, and add to the table "RetryLimit" type "Integer", valid range "0-255", description "The maximum number of times the transmission of a frame is attemped."


Comment:
The standard should state somewhere that if a DEV receives a PNC Information command indicating that it is no longer associated to the piconet, it should consider itself disassociated.

SuggestedRemedy:
Add this text to 8.3.4 and also add that a DEV that sees an Association IE in the beacon that indicates that it is disassociated, should consider itself disassociated as well.

Response:
ACCEPT IN PRINCIPLE. Add text to 8.3.4 to indicate that the DEV shall use the information in the PNC Information command to determine if it has been disassociated.


Comment:
Part of the multi-CAP (eCAP) proposal. This is part of the attempt to clean up the contention text in clause 8 with an introduction paragraph.

SuggestedRemedy:
8.4.x.x Introduction to contention channel access (could fit into 8.4, Channel Access) {see 04/023r0 for format of table} Media access using contention methods are CSMA/CA, 8.4.2, and slotted Aloha, 8.4.3.4.  CSMA/CA shall be used in the CAP, 8.4.2, and in extended CAP (ECAP), 8.4.3.y. Slotted aloha shall be used for contention MCTA, 8.4.3.3 and multi-use MCTA for contention peer to peer CTA ({need a good TLA}), 8.4.3.z. The PHY type in use determines the access method. Only a single contention scheme shall be used in a DEV. The contention access schemes defined are shown in Table yyyy. For information, the non-contention MCTAs are shown in the table. Function	Access type	SrcID	DestID	Stream index Open MCTA 	Slotted aloha	BcstID	PNCID	Management stream index Association MCTA	Slotted aloha	UnassocID 	PNCID	Management stream index Mgmt down	directed	PNCID	Reg. DEVID 	Management stream index Mgmt up	directed	Reg. DEVID	PNCID	Management stream index Multi-use MCTA 	Slotted aloha	BcstID	BcstID	Management stream index Extended CAP 	CSMA/CA	BcstID	BcstID	Async stream index  Table yyyy - Summary Table access types used for piconet management


Comment:
The security specification in 802.15.3 (10) currently requires frame retransmissions to be re-encrypted and a new integrity code generated for each retransmission. This means that the MAC is required to perform rapid encryption and integrity code generation between retries.  This will add cost to the MAC hardware/software due to the need for increased processing power and buffering.  A similar situation is avoided in 802.11i where retransmitted secure frames are not re-encrypted, allowing encryption and integrity code generation to be performed in advance and only once per frame.
Section 10.2.4 mandates that a new nonce is used for each transmitted frame in order to avoid re-use of the same nonce for different frame data.  Frame data changes between frame retransmissions because of mutable bits in the MAC header (The Retry and More Data bits in the Frame Control field).  This requirement can be relaxed if:
1.  Mutable bits are excluded from the integrity code calculation by masking. 2.  Bits can be constrained from changing between initial transmission and retransmission.
Either approach allows retransmissions to use the same nonce because the inputs to the encryption/integrity code generation process will be the same for the initial and any retransmitted frames.

SuggestedRemedy:
Two possible solutions are proposed:
1.  Both Retry and More Data bits are masked when generating the integrity code.  This creates a vulnerability to a frame being replayed with either bit modified.  Modification of the Retry bit will not cause a problem at the receiver as sufficient state is contained in the Fragmentation Control field to allow such an attack to be safely ignored.  Modification of the More Data bit in a replayed frame could cause a receiver to ignore further frames up to the end of a CTA.  The risk of such an attack should be balanced against reduced cost of implementation.
2.  The Retry bit is masked and the rules on setting the More Data bit are tightened to restrict changes on retransmissions.
With either solution, retransmissions that occur within the same superframe as the initial transmission need only be processed once.  Retransmissions that slip into the following superframe will still need reprocessing due to the requirement to use a fresh time token.

Response:
ACCEPT IN PRINCIPLE. Mask both bits, John Barr to provide text that follows the 802.11i.


Comment:
The value of PHYPIB_NumPMLevels should be limited to a practical upper limit.

Response:
ACCEPT IN PRINCIPLE. Change "Number of power management levels supported. The range is 1 to 255 and the value is implementation dependent. " to be "Number of power management levels supported. The range is 1 to 8 and the value is implementation dependent. "


Comment:
A clear real example of HCS calculation should be added to the standard.

Response:
ACCEPT IN PRINCIPLE. The commenter needs to supply the informative annex.


Comment:
Editorial corrections as indicated in 15-04-0131-03


Comment:
Suggest an annex to suggest uses of the contention schemes giving a few cases for each.

Response:
ACCEPT IN PRINCIPLE. Commenter needs to supply an informative annex for review.


Comment:
Testing for interoperability will require protocol compatibility at all layers, not just the MAC.  No standardized mechanism currently exists for performing MAC only interoperability testing.  The ability to test the MAC and PHY layers in isolation via the air interface would have the following benefits:·	Allows basic MAC and PHY interoperability to be established more efficiently by excluding higher layers·	Provides a baseline for MAC/PHY interoperability, encouraging MAC/PHY interoperability, even when higher layers are incompatible·	Enables test equipment vendors to produce testers that communicate with devices via a standardized set of air interface test messages

SuggestedRemedy:
Define a test mode for the MAC to enable control via a new Test Message frame. See: 15-04-0305-00-003b-mac-test-mode.doc

Response:
REJECT. However, this would be a good idea to start a PAR for a conformance methodology standard for 802.15.3.


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


