1. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: TG6 MAC comments resolution proposal
Date Submitted: 06 September, 2010
Source: Okundu Omeni
Company: Toumaz UK, Ltd
Address: 115 Milton Park, Abingdon, Oxfordshire, UK
Voice: , FAX: ,
Re: Proposed Resolution of D0 Comments S7-470, S7-482, S7-87, S7-483, S7-486, S7-484, S7-485, S , S7-471, S7-472, S7-474, S7-65, S7-475, S7-476, S7-478, S7-479, S7-481, S7-480
Abstract: This document addresses the following comments [S7-470, S7-482, S7-87, S7-483, S7-486, S , S7-485, S7-487, S7-471, S7-472, S7-474, S7-65, S7-475, S7-476, S7-478, S7-479, S7-481, S7-480] in the TG6 MAC draft D01 and proposes resolutions
Purpose: This document is for the MAC comment resolution discussion for TG6 draft D01
Notice: This document has been prepared to assist the IEEE P 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 P
O Omeni, Toumaz UK. Ltd.
<author>, <company>

2. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution of D0 Comments [S7-470, S7-482, S7-87, S7-483, S7-486, S7-484, S7-485, S7-487, S7-471, S7-472, S7-474, S7-65, S7-475, S7-476, S7-478, S7-479, S7-481, S7-480]
O Omeni, Toumaz UK. Ltd.
<author>, <company>

3. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-470
Original comment:
What happens when the guard time becomes greater than the allocation interval?
Proposed resolution
Suggest defining a maximum Synchronisation interval to avoid continual increment of Gta?
O Omeni, Toumaz UK. Ltd.
<author>, <company>

4. Proposed Resolution - S7-470
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-470
Add another paragraph between lines 22 and 23 and insert the following text.
The [total guard time + node/hub communication time] shall be less than the allocation for the node. This is especially important when using GTa where the guard time is dependent on how long the node sleeps.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

5. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-482
Original comment:
pChannelSwitchTime is 100 us (table 44). Where would this time come from?
Proposed resolution
needs to be taken at the end of the superframe for channel change. We might need to create a channel change slot for this.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

6. Proposed Resolution – S7-482
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution – S7-482
Beacon transmission should always occur 100us after the start of the 1st slot.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

7. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-87
Original comment:
Figure 89 missing input and output for channel hopping sequence generation
Proposed resolution
Update drawing and text describing operation
O Omeni, Toumaz UK. Ltd.
<author>, <company>

8. Proposed Resolution - S7-87
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-87
Reject comment
Page 111 lines 4 to 7 describe how this is done.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

9. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-483
Original comment:
This entire section is dislocated from the rest of the text.
Proposed resolution
I am not sure it is needed. So it should be taken out or completely rewritten to reference existing frames and terminology.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

10. Proposed Resolution - S7-483
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-483
Comment resolution reassigned to Ranjeet, who is the author of the sub-clauses in question.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

11. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-486
Original comment:
in the "active scan based" method, It appears the hub doesn't do any ED before transmitting the BAN enquiry frame? Wouldn’t it be a good idea to always do ED and then optionaly do any of the other methods? This would mitigate collision in active networks.
Proposed resolution
make ED mandatory for time sharing/load reduction enabled hubs. This should be the first stage before any other scanning method
O Omeni, Toumaz UK. Ltd.
<author>, <company>

12. Proposed Resolution - S7-486
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-486
make ED mandatory for time sharing/load reduction enabled hubs. This should be the first stage before any other scanning method. Text should be modified accordingly.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

13. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-484
Original comment:
what is a BAN enquiry frame? I don’t see it defined anywhere.
Proposed resolution
"BAN enquiry" should be changed to "Coexistence request"
O Omeni, Toumaz UK. Ltd.
<author>, <company>

14. Proposed Resolution - S7-484
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-484
Comment resolution reassigned to Ranjeet, who is the author of the sub-clauses in question.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

15. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-485
Original comment:
what is a BAN enquiry frame? I don’t see it defined anywhere.
Proposed resolution
"BAN enquiry" should be changed to "Coexistence request"
O Omeni, Toumaz UK. Ltd.
<author>, <company>

16. Proposed Resolution - S7-485
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution - S7-485
Comment resolution reassigned to Ranjeet, who is the author of the sub-clauses in question.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

17. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-487
Original comment:
This entire section is also dislocated from the rest of the text. What is the definition of severe interference? How would load control work in congested channel conditions if connection assignments do not get through? Isn't this best managed by higher layers?
Proposed resolution
I am not sure this clause is useful other than for information. So I suggest that it should be taken out or completely rewritten to reference existing frames and terminology and well defined behaviour that can be implemented without ambiguity.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

18. Proposed Resolution for S7-487
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-487
Comment resolution reassigned to Ranjeet, who is the author of the sub-clauses in question.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

19. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-471
Original comment:
this paragraph isnt very clear. Can a hub change it HID after nodes connect to it? If not what does reselect mean?
Proposed resolution
Clarify
O Omeni, Toumaz UK. Ltd.
<author>, <company>

20. Proposed Resolution for S7-471
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-471
Reject
When read together with the previous paragraph, it is clear.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

21. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-472
Original comment:
what happens for relay communications? The Senser ID would be the Node ID of the relay node.
Proposed resolution
should be changed to include relay support - for example "The Sender ID field of the MAC header of the frame is set to the HID of the desired hub or if the node is in relay communication, the NID of the relay node with which to exchange frames"
O Omeni, Toumaz UK. Ltd.
<author>, <company>

22. Proposed Resolution for S7-472
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-472
Reject
Proposed replacement text for two-hop star topology extension addresses this comment satisfactorily.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

23. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-474
Original comment:
the sentence "These frames should not be longer than the frame sent in the last block transmission" is redundant, because a device that supports B-Ack must be able to cope with frames that are also longer.
Proposed resolution
change the should to shall. This would make it easy for implementers of B-Ack on devices with limited memory to be able to better manage the payload sent according to their memory capabilities.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

24. Proposed Resolution for S7-474
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-474
change the should to shall. This would make it easier for implementers of B-Ack on devices with limited memory to be able to better manage the payload sent according to their memory capabilities.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

25. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-65
Original comment:
The N-Ack and G-Ack are the same, not different
Proposed resolution
Put () around G-Ack
O Omeni, Toumaz UK. Ltd.
<author>, <company>

26. Proposed Resolution for S7-65
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-65
Accept:
Put () around G-Ack
O Omeni, Toumaz UK. Ltd.
<author>, <company>

27. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-475
Original comment:
there is still the outstanding issue of how a recipient can know the last fragment has been received?
Proposed resolution
we could either use a countdown with the 1st frame bit in the MAC header indicating the first frame of the fragment and the fragment number decrementing from frame to frame and indicating how many more fragments are outstanding.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

28. Proposed Resolution for S7-475
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-475
Reject:
Resolution already agreed (see S6-466). Fragment number would be split into 2 fields with the single bit field used to indicate the last fragment.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

29. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-476
Original comment:
are these frames of fixed length? If they are, this must be specified. Otherwise, the implied medium access allocation is ambiguous and may lead to unintended collisions with other traffic
Proposed resolution
this needs to be much clearer. A node that is allowed to transmit 10 frames for instance can transmit 10 frames of payload 20 bytes each or of 255 bytes each. Which is a huge difference in terms of the allocated time. In a TDMA system this type of ambiguity can cause problems for other devices on the network and lead to instability.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

30. Alternative Resolutions for S7-476
<month year>
doc.: IEEE <doc# >
September, 2010
Alternative Resolutions for S7-476
During connection, nodes using type II polling may be given a data packet size by the hub. This would be used as the time reference when future type II polls are sent with the number of frames to transmit field.
This removes the ambiguity of the time allocated by the poll, since this fixed data packet size takes a fixed amount of time to be transmitted.
Remove type II poll
This poll does not have any additional functionality than that provided by the type I poll and adds unnecessary complexity to implementation.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

31. Proposed Resolution for S7-476
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-476
Remove type II poll
This poll does not have any additional functionality than that provided by the type I poll and adds unnecessary complexity to implementation.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

32. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-478
Original comment:
pMICSUnconnectedPollRxTime (as sepcified in table 24) is not long enough for a node to receive one of 2 adjacent T-Poll frames.
Proposed resolution
change entry in table 24; pMICSUnconnectedPollRxTime = pMICSUnconnectedPollSeparation + pMICSUnconnectedPollTxTime; except we change the wording from to received to starts to receive.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

33. Proposed Resolution for S7-478
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-478
Change the following text (on lines 8-10, page 93) from the following:
The unconnected node should cyclically tune to each MICS band channel for pMICSUnconnectedPollRxTime, until it receives an unconnected T-Poll frame and hence discovers a hub. The unconnected node should not further change the channel unless recommended otherwise.
To the following (text in blue is new text):
The unconnected node should cyclically tune to each MICS band channel for pMICSUnconnectedPollRxTime, until it receives an unconnected T-Poll frame and hence discovers a hub. Once it starts receiving a frame, it should stay on the receive mode until it receives the whole frame.  The unconnected node should not further change the channel unless recommended otherwise.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

34. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-479
Original comment:
the poll and wakeup frames appear to have the same functionality (see figures 73 & 75 and 76 & 77). Why do we need both of them?
Proposed resolution
I don’t see any functional advantage for having a separate wakeup frame, especially since it carries much more payload than a poll frame. Unless its advantage can be clarified, I suggest it be deleted from the spec.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

35. Proposed Resolution for S7-479
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-479
Remove unicast wakeup mechanisms, together with figures 74, 75 & 77 and the wakeup frame from the draft text.
A type I poll message provides a more efficient mechanism for achieving the same functionality
It has no payload compared to the potentially large payload for a wakeup frame (dependent on number of nodes)
Session start can also be conveyed using a future poll field of type I poll
Unicast or multicast poll can be indicated simply using the receive address field of the type I poll frame
O Omeni, Toumaz UK. Ltd.
<author>, <company>

36. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-481
Original comment:
For a sensor node to overhear an ACK from an RN, it needs to be able to receive this message, but according to because the address isn't correct, this frame cannot be received.
Proposed resolution
change to add optional reception of ACK frame with RN Sender address if Sensor node is a relayed Node
O Omeni, Toumaz UK. Ltd.
<author>, <company>

37. Proposed Resolution for S7-481
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-481
Reject
Proposed replacement text for two-hop star topology extension addresses this comment satisfactorily.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

38. doc.: IEEE 802.15-<doc#15-10-0665-00-0006>
<month year>
doc.: IEEE <doc# >
September, 2010
D0 Comment S7-480
Original comment:
how does a sensor node know that an ACK is from a relaying node?
Proposed resolution
we can use the relay field in the MAC header to indicate this in ACK frames from relaying nodes that are currently accepting new relay connections. This way a node doesn’t need to have a list of available relaying nodes beforehand. Also because it is for ACK frames only, this bit can be turned off if a relaying node is no longer accepting new relay connections.
O Omeni, Toumaz UK. Ltd.
<author>, <company>

39. Proposed Resolution for S7-480
<month year>
doc.: IEEE <doc# >
September, 2010
Proposed Resolution for S7-480
we can use the relay field in the MAC header to indicate this in ACK frames from relaying nodes that are currently accepting new relay connections. This way a node doesn’t need to have a list of available relaying nodes beforehand. Also because it is for ACK frames only, this bit can be turned off if a relaying node is no longer accepting new relay connections.
This means the text for the relay bit in the MAC header ( ) needs to be modified to indicate this.
Also the text for discovering a relay node needs to be modified to include this.
O Omeni, Toumaz UK. Ltd.
<author>, <company>