IEEE P802.15
Wireless Personal Area Networks
Project	IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)	
Title	TG3 Draft Standard d04 MAC Amendments	
Date Submitted	[14 May, 2001]	
Source	[Allen D. Heberling]
[XtremeSpectrum, Inc.]
[8133 Leesburg Pike, Suite 700
Vienna, Virginia 22182]	Voice:	[703-269-3022]
Fax:	[
E-mail:[adheberling@ieee.org ]	
Re:	[Draft 00000d04P802.3_Draft-Standard.pdf]	
Abstract	[Amendments to the MAC layer of 00000d04P802.15.3__Draft-Standard.pdf]	
Purpose	[To record the amendments to the MAC layer for the purpose of modifying the baseline draft standard.]	
Notice	This document has been prepared to assist the IEEE P802.15.  It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.	
Release	The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.	

Draft Version Number	Clause number e.g., 8.10.2	Page number e.g., 1-1130, etc.	Line number e.g., 1-54	Type of comments (E/e/T/t)	Class of Problem	Comment/Rationale (Issue and reasoning behind it.)	Recommended change (What change(s) it would take to make this clause acceptable.)	Disposition/Rebuttal (Do not write here during ballot phase; this is for comment resolution phase.)	
2	3.28	6	20	 	Definitions	Time slot is incorrectly defined as 625 uS long.  	Please provide correct definition.	Insert the correct definition.	
2	6.3.2.1	17	24	t	Scan	Since ScanType is Passive	Remove ProbeDelay	Remove ProbeDelay	

2	6.3.2.1	17	36	e	Scan	To which frame exchange sequence are you referring.	Please Clarify. 	(Rick Roberts Will provide clarifying text)	

2	6.3.2.2	17	40	e	Scan	MLME-Scan.confirm paragraph description needs to be rewritten.	Recommend:  This primitive and its parameters, which were collected during the scan process, is returned upon completion of the scan process.	Add:  This primitive and its parameters, which were collected during the scan process, is returned upon completion of the scan process.	

2	6.3.3.1	19	46	T	Synch	MLME-Join.request as defined here is not consistent with the way it is defined in C8.1.1.	Change MLME-Join.request to MLME-Synch.request.  Also need to do the same for MLME-Join.confirm. Change join failure timeout to synch failure timeout. Eliminate probe delay.	Change MLME-Join.request to MLME-Synch.request.  Also do the same for MLME-Join.confirm. Change JoinFailureTimeout to SynchFailureTimeout. Eliminate Probe Delay. Change text regarding PiconetDescriptionSet 	

2	6.3.3.1	19	51	e	Synch	Change BSSDescription to PSSDescription	Please make the change since we need to make a distinction between LANs and PANs. Change to PSSDescription	Change to PicoNetDescription	

2	6.3.3.x	19	51	T	Assoc.	Need to add these MLME signals :  MLME-Join-Network.request, MLME-Join-Nework.indication, MLME-Unjoin-Network.request, MLME-Unjoin-Network.indication, 	The MLME-Join-Network.request/confirm/indication signals correspond in function to the MLME-Associate.request/confirm/indication signals. So continue to use MLME-Associate… .  The MLME-Unjoin-Network.request/confirm/indication signals correspond to the MLME-Disassociate.request/confirm/indication signals.  So continue to use MLME-Disassociate... .	Rather than join and unjoin, use associate and disassociate consistent with frame format 7.3..4 and 8.1.4.in Draft 04.Change peer address to Device ID. Add allocated device address field; retain capability information;  Association Failure Timeout needs to be made consistent with Association timeout period {Rick Roberts)	

2	6.3.3.x	19	54	t	Assoc./Estab	Do we really need  MLME-Join-or-EstablishPicoNet.request and a MLME-Join-or-EstablishPicoNet.indication? Why not MLME-scan and then MLME-Start?  Let the SME take care of the sequence.	Do not adopt a combo signal name.	Eliminate combo commands and use the existing commands for associate and MLME-start.	

2	6.3.6.1	25	44	t	Assoc	PeerSTAAddress is inconsistent with Device ID parm in 7.2.4	Change PeerSTAAddress to DeviceID	Change PeerSTAAddress to DeviceID	

2	6.3.6.1	25	44-46	e	Assoc	Assoc.req Parms are not in the same order as those in 7.2.4	Switch parm positions Capability Info field with the Assocciation Timeout field.  Add an AD-AD field between Capability field and Assoc. Timeout Period	Switch parm positions Capability Info field with the Assocciation Timeout field.  Add an AD-AD field between Capability field and Assoc. Timeout Period	

2	6.3.6.3	27	8	e	Assoc	Parm name is inconsistent with the frame format parameter name	Replace PeerSTAAddresss with DeviceID	Replace PeerSTAAddresss with DeviceID	

2	6.3.8.3	33	40	 	DisAssoc	Parameter name is inconsistent with the frame format parameter name.	Change Parmeter name to the frame format name	Peer station address is the wrong parameter name.	

2	7.1.3.1.3	49	20-40	 	Frame Types	No coherent poloicy of what is a frame and what is a command	XSI has a recommendation	Adopt WMSs FrameType table in doc: 01250r0	
2	7.1.3.1.3, 7.2, 7.4	 	 	 	FrameType	It is not clear why some things have unique frames and others are commands. 	XSI has a proposal for an alternative arrangement of frames and commands	Adopt WMSs FrameType table in doc: 01250r0	

2	7.1.3.1.4	49	44+	 	Frame Fields	Is Frame Position obsolete, or do we want to use this to allow a transmitter to tell a receiver that it has no more frames to send for that GTS slot?  Receiving STA would have to wait a defined interval after ACK to ensure no retransmission due to lost ACK.  	Remove frame position.	Remove frame position sub clause.	
2	7.1.3.1.6	51	50+	 	Frame Fields	Is Duration field needed anymore?	Eliminate Duration Field	Eliminate duration field in MAC header and the clause text.	

2	7.1.3.1.8	 	 	 	Repeater	This name should be changed to “Repeater Service”.  Any station should be able to serve in the capacity of a repeater at the request of an initiator station.  The requested station is not obligated to serve in that capacity unless it is the current Coordinator, but it should be allowed to use this field if it accepted the request of a station and is serving in this capacity.  This capability is required to support some protocol’s at layers that are above the MAC layers.	Please change Coordinator Repeater Service to Repeater Service.	Change name to Repeater Service and the text to reflect that member stations could serve as repeaters.	

2	7.1.3.3	50	42	t	Assoc	Are the addresses sequentially assigned to each associating device by the coordinator?  Is it similar to the method used by 802.15.1?  Does the coordinator keep a data base of device MAC addresses and assigned device addresses?	 	The coordinator will assign addresses in sequence except when assigning addresses from stations that have disassociated.	

2	7.1.3.3	50	52	 	multicast	Use FD instead of FF for multicast.  Then only stations with multicast enabled will pass up multicast.  	Use FD instead of FF for multicast.  Then only stations with multicast enabled will pass up multicast.  	Use FD instead of FF for multicast.  Then only stations with multicast enabled will pass up multicast.  	

2	7.1.3.5	 	 	 	Frag	 D03 Add to the explanation the following three examples showing the number sequencing for the following three cases: 1. Single fragment sequence of error-free frames; 2. Multiple fragment sequence of error-free frames; 3. Multiple fragment sequence with errors and retries.	Please provide additional detail.	Suggest message sequence diagram to illustrate each of the 3 cases.	

2
2	7.2, 7.4	 	 	 	Commands	It is hnot clear why some things are commands and others are unique frames.	We have two alternatives -  all frames vs. management and control frames.	Adopt WMSs FrameType table in doc: 01250r0	

2	7.2.1	53	26	e	InfoElements	Information elements are alluded too,  but not referenced.	Please add cross references to appropriate Information element clauses	Please add cross references to appropriate Information element clauses	

2	7.2.4	56	25-35	 	Assoc.  	Should we remove the reserved field in the association request frame? It looks like it is just there to keep request and response the same size.	Remove it.	Remove it.	

2	7.2.5	57	7	?	Assoc	The response is the ACK. Why send unnecessary information?	Please clarify.  Do we ack or not?	No ACK.	

2	7.2.5	57	28	E	Assoc	Shouldn't this be an Association Response command format?	Change Label of Figure 8 to correctly identify the Frame type	We still need an association response frame format.  D04 does not have a reason ode.	

2	7.2.6	58	18	e	Assoc	Reason "0" seems more appropriate for the Association Response Reason Code Field.	Separate the Assoc response reasons from the disassociate request reasons.	Change table in D04	

2	7.2.6	58	20	e	Assoc	Reason "1" seems more appropriate for the Association Response Reason Code Field.	Separate the Assoc response reasons from the disassociate request reasons.	Change table in D04	

2	7.2.6	58	31	e	Assoc	Reason "2" seems more appropriate for the Association Response Reason Code Field.	Separate the Assoc response reasons from the disassociate request reasons.	Change table in D04	

2	7.3.2	62	5-6	t	Synch	This paragraph defines Min-Slot Duration	Do we need it? If not, remove.	Remove minimum slot duration and maximum slot duration.	

2	7.3.2	61	15	e	Synch	WPANs are piconets not LANS	Please change Network Synch to PicoNet Synch.	Change the title of clause 7.3.2	

2	7.3.3	62	 	t	 	 	Add a MAX GTS field to capabilty Info frame	Add MAX GTS field to capabilty info frame.	

2	7.3.5	63	28	T	Assoc	These MLME signals(MLME-Join-Network.request, MLME-Establish-Network.request, and MLME-Join-or-Establish-Network.request) need to be defined in the MLME clause.  See c6.3.6.1, c6.3.10.1 and c6.3.3.xxx.	The MLME-Join-Network.request/confirm/indication signals correspond in function to the MLME-Associate.request/confirm/indication signals. So continue to use MLME-Associate… .  The MLME-Establish-Network.request/confirm signals correspond to the MLME-Start.request/confirm signals.  So continue to use MLME-Start... .  The MLME-Join-or-Establish-Network.request signal needs to be evaluated as to whether it is worthwhile specifying.	Use MLME-Associate instead of MLME JoinNetwork. Use MLME Start Request and Start Confirm instead of MLME-Establish-Network.req/confirm. Delete reference to MLME-join-or-establish-network as unnecessary to have combo command. Use instead a sequence of associate & start.	

2	7.3.9	64	39-49	 	CTA	Is STA Address source STA address.  	Please clarify.	The device address is the source address..	

2	7.3.9	64	39-49	 	CTA	Destination STA address should be added	Please add.	Destination address field should be added.	

2	7.3.9	64	39-49	 	CTA	Max slot duration field is redundant and should be3 removed.  The start of the next GTS slot is the end of the pervious one.  	Eliminate Max Slot Duration field	Eliminate Max Slot Duration field. The start time of the next frame defines the end of the previous frame. WMS will explain this.	

2	7.3.9	64	39-49	 	CTA 	Device ID field should be removed	Please remove	Remove device ID.	

2	7.4.1	67	48+ 	 	CFP	How long is a cfp request good for?  One superframe, or until the next request?	Add text to say that your slot assignment is in effect until changed or disassociated	Add text to say that your slot assignment is in effect until changed or disassociated.  (Bill Shvodian)	

2	7.4.1.1	68	15	E	CTA	 VTS (aka SC-TDMA) is no longer being supported.	Consequently get rid of the Request Type field 	Consequently get rid of the Request Type field 	

2	7.4.1.1	68	36-38	E	CTA	These three lines are no longer needed given that VTS is no longer part of the baseline.	Please remove the indicated lines of text.	Please remove the indicated lines of text.	

2	7.4.2	71	50-51	t	Synch	Description of  ave. time allocated for GTS's not needed.	Remove description of  ave. time allocated for GTS's.	Remove description of  ave. time allocated for GTS's.	

2	7.4.2	72	14	t	Synch	Need to get rid of ave. time allocated for GTS's	Remove Ave. time allocated for GTS's	Remove Ave. time allocated for GTS's	

2	7.4.3	71	1-2	e	Repeater	So the coordianator is terminating the repeater service between the destination device and the destination device?  Shouldn't this say that the service is being terminated between the source transmission device and the destination device?	Please provide clarification.	Change to: Service is being terminated between the source transmission device and the destination device indicated in the destination device ID field.	

2	7.4.3.3	70	41	t	Repeater	Which station?  source or destination?	Please provide clarification.	Add that either the coordinator or the destination station can send the repeater service reject command.	

2	8.1	79	49-54	T	Assoc	Define MLME.Join.Network.request,MLME-Establish-Network.request ,etc…	The MLME-Join-Network.request/confirm/indication signals correspond in function to the MLME-Associate.request/confirm/indication signals. So continue to use MLME-Associate… .  The MLME-Establish-Network.request/confirm signals correspond to the MLME-Start.request/confirm signals.  So continue to use MLME-Start... .  The MLME-Join-or-Establish-Network.request signal needs to be evaluated as to whether it is worthwhile specifying.	Join -> Associate, Establish -> Start piconet.  Eliminate references to join network.  Eliminate reference to MLME-join-or-establish-network.	

2	8.1.4	82	15-27	E	Assoc	This diagram would be much clearer if it was redone as a Message Sequence Chart (MSC).	Redo Figure 2 as a message sequence chart.	Figure 41 shoul be redone as a message sequence chart.	

2	8.1.4	81	49-54	 	Assoc.	What DA does the coordinator use to send the Association Response? Broadcast?  FE?	Recommend a broadcast so that all stations could update their association tables	Recommend a broadcast so that all stations could update their association tables	

2	8.1.5	82	38-40	e	Assoc	This paragraph should include a reference to the Frame Format Clause 7.2.6 regarding these signal types.	Please provide a reference in the text to Frame Format Clause 7.2.6.	Provide references to frame formats and/or MLME messages.	

2	8.2.1	84	21-22	E	IFS	The concept of VTS has been discontinued. Consequently, we no longer need to support the MIFS duration.	Remove References to MIFS since VTS is no longer supported.	Remove References to MIFS since VTS is no longer supported.	

2	8.2.1	84	31	t	RTS/CTS	With the elimination of VTS do we still need NAV?  I hope not.  It seems an unnecessary complication.	Remove NAV from the specification	Remove NAV from the specification	

2	8.2.2	84	47-54	E	NAV	Since VTS has ben removed, why do we need NAV?	Get rid of the NAV since VTS is no longer an issue.  Plus the CAP will not need it either.	Get rid of the NAV since VTS is no longer an issue.  Plus the CAP will not need it either.	

2	8.2.3	85	17-30	T	RTS/CTS	This section needs to reworked because, I don't anticipate messages during the CAP to be multi fragment messages.  Consequently, there will be no need for an RTS/CTS sequence at the beginning of the fragment sequence.	Remove RTS and CTS  from the CAP since the CAP will not support fragmented messages.	Remove RTS and CTS  from the CAP since the CAP will not support fragmented messages.	

2	8.2.3.1	85	51	E	NAV	Why is NAV being defined for a MAC that no-longer supports VTS?	Get rid of the NAV since VTS is no longer an issue.  Plus the CAP will not need it either.	Get rid of the NAV since VTS is no longer an issue.  Plus the CAP will not need it either.	

2	8.2.3.2	86	6-12	E	RTS/CTS	Hidden nodes are a problem for CSMA based systems not GTS TDD systems.	Remove this section on hidden node since VTS has been dropped.	Remove this section on hidden node since VTS has been dropped.	

2	8.2.3.2	86	6-12	 	RTS/CTS	IF only short frames are sent in the CAP, there is no need for RTS/CTS	Remove RTS and CTS completely from the CAP and CFP	Remove this section on hidden node since VTS has been dropped.	

2	8.2.4.2	87	2-46	E	CFP	Explicit token passing was voted out of the specification during the HH meeting.	Remove all reference to explicit token passing as a means of giving a follow on GTS Packet Transmission an earlier start time.	Th GTS portion should not have been removed.  Add it back in with diagram.	

2	8.2.4.4	90	22	E	CFP	VTs has been eliminated as an access method.	Remove reference to SCP 	Please add back in channel time allocation and guaranteed time slot.	
3	8.2.4.4	90	22	E	CFP	VTs has been eliminated as an access method.	Remove reference to SCP 	Please add back in channel time allocation.	
3	8.2.7	90	44	E	NAV	If VTS is no longer an issue, then why do we need NAV rules of access?	Remove the reference to NAV and replace with reference to Contention based channel access and Backoff Procedure.	Please add back in clause 8.2.7.   Remove the referece to NAV.	
3	8.2.7	91	1-6	E	CFP	VTS has been eliminated as an access algorithm.	Remove these two paragraphs 	Please add back in time limitations on transmissions.	
4	7.2.1.1.3	59	10	t	Frame Type	Folding commands into frame types requires using 6 bits to the Frame Type Field	Change text to "The frame type field is six bits in length."	Change text to "The frame type field is six bits in length."	
4	7.2.1.1.3	59	16-33	t	Frame Type	The division between frame types and commands is not clear	Modify the frame type table as specified in document 01250r1P802.15_TG3-MAC-Changes.ppt slide 5 and slide 6.	Modify the frame type table as specified in document 01250r1P802.15_TG3-MAC-Changes.ppt slide 5 and slide 6.	
4	7.3.1	62	49	t	Frame Type	New Frame types added	Change text to "There are twenty-eight defined frame types.	Change text to "There are twenty-eight defined frame types.	
4	7.3.1	63	2-18	t	Frame Type	New Frame types added	Modify Table 56 as follows: change "Commands" to "Other Management and Control frames"	Modify Table 56 as follows: change "Commands" to "Other Management and Control frames"	
4	7.3	 	 	 	Frame Type	New Frame types added	Add new sections corresponding to the new frame types as specified in document 01250r0P802.15_TG3-MAC-Changes.ppt slide 5 and slide 6.  Frame descriptions should be imported from the appropriate command sections in 7.5	Add new sections corresponding to the new frame types as specified in document 01250r0P802.15_TG3-MAC-Changes.ppt slide 5 and slide 6.  Frame descriptions should be imported from the appropriate command sections in 7.5	
4	7.5	 	 	 	Commands	Commands changed to frame types	Remove Section 7.5 and all of its sub clauses	Remove Section 7.5 and all of its sub clauses	
4	8	 	 	 	Commands	Commands changed to frames	do a global replace of references to specific "commands" with  references to the corresponding "frames"	do a global replace of references to specific "commands" with  references to the corresponding "frames"	
4	7.2.1.1.2	59	6	 	ACK Policy	Add Implied Ack Policy	Change "3: Reserved" to "3: Implied ACK.  Implied ACK policy allows the receiving stations to send either an immediate ACK frame, or any other frame where the destination address is the same as the source address of the frame with the implied ACK set. The stream index and sequence control field are set based on the frame that is being transmitted, not the one that is being ACKed"	Change "3: Reserved" to "3: Implied ACK.  Implied ACK policy allows the receiving stations to send either an immediate ACK frame, or any other frame where the destination address is the same as the source address of the frame with the implied ACK set. The stream index and sequence control field are set based on the frame that is being transmitted, not the one that is being ACKed"	
4	7.2.1.3	60	25	 	Coordinator	The device serving as the coordinator should have two addresses, 0 for the coordinator function and a separate station address for non coordinator traffic.  This will simplify coordinator handoff because non-coordinator traffic bound for the station will not have to change addresses when it hands off the coordinator function. 	Add the following text:  The device serving as the coordinator shall have two addresses associated with it.  The address 0 will be assigned to the coordinator fuction within the station.  The device will have a separate address assigned to it for non-coordinator traffic.	Add the following text:  The device serving as the coordinator shall have two addresses associated with it.  The address 0 will be assigned to the coordinator fuction within the station.  The device will have a separate address assigned to it for non-coordinator traffic.	
4	8.1.8	89	41	 	Coordinator	Text required to support two addresses in the coordinator	Add the following text: The new coordinator shall begin receiving traffic sent to the coordinator address 0,  but it shall continue to use its assigned station address for all non-coordiator traffic.	Add the following text: The new coordinator shall begin receiving traffic sent to the coordinator address 0,  but it shall continue to use its assigned station address for all non-coordiator traffic.