1. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of TG6 comments: S7 XXX: RTT related, comments listed in slide 3] Date Submitted: [xx September,2010] Source: [Hind Chebbo] Company [Fujitsu] Address [Hayes Park Central, Hayes, UB4 8FE, Middlesex, UK] Voice:[+44 (0) 20 8606 4809], FAX: [+44 (0) 20 8606 4539], E-Mail:[Hind.Chebbo@uk.fujitsu.com] Re: [Proposed Resolution of D0 Comment S7-###] [If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.] [Note: Contributions that are not responsive to this section of the template, and contributions which do not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.] Abstract:[Comment resolution for letter ballot 55] Purpose:[Comment resolution for letter ballot 55] 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.

2. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 2 Proposed Resolution of D0 Comments S7-###(listed in next slide), Based On Two-hop star Topology Extension (RTT/EST) Hind Chebbo

3. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 3 D0 Comments Addressed S7-469David Tracey S7-466Makoto Noda S7-397 David Tracey S7-467David Tracey S7-503 Hind Chebbo S528 Guido Dolmans S7-468David Tracey S7-408Sverre Brubæk S 7-527 Guido Dolmans S7-445David Davenport S7-446David Davenport S7-413David Cypher S7-158Didier Sagan S7-426Srinath Hosur S7-432Jin-Meng Ho S7-470 David Tracey S7-401 David Tracey S7 481 Omeni S-480 Omeni S7-250 David Davenport S7-252 David Davenport S7-249 David Davenport S7-402 David Tracey RTT based - Assigned to me RTT based- but not assigned to me

4. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 4 Basis For Comments Resolution IEEE P802.15-10-0544-02-0006 –Replacement of sub clause 7.9 of D0 draft

5. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 5 S7-469 Page 99-100, sub clause 7.9, figure 79-80 Comment: Can only data frame types be relayed (or can commands also be relayed)? Proposed change: Add commands to figure 79/80 if allowed Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02- 0006. –Relayed node and target hub can exchange unicast management or data but not control

6. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 6 S7-466 Page 98, sub clause 7.9, line 7 Comment: I could not find out how the two-hop star topology links can be secured Proposed change: Describe how the security services work in two-hop start topology scenario Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (See Sub clause 7.9.1) –The relayed node and the target hub, the relaying node and the target hub, and the relaying node and the relayed node shall follow the state diagram specified in 5.5 for a one-hop star network in exchange of frames as if they were in direct communication, applying the appropriate security level for both transmission and reception of the encapsulated frames. –Exception for the case of relaying and relayed node relationship: they shall not exchange with each other Connection Request and Connection Assignment frames not encapsulating another frame.

7. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 7 S7-397 (1) Page 101-102, sub clause 7.9.3.1 & 7.9.3.2, figure 81- 82 Comment: It is unclear what state the node is in after RTT session ends – is it back to orphan or does it remain in connected if it was previously connected. If it remains connected, should Connection assignment 2 not be R=0 modification? More generally, does this mean that RTT mode is seen as being a transient state? Proposed change: Need to clarify whether Figures 81 and 82 refer to previously connected and unconnected nodes (is a disconnect used in this case?) and how the data shown in the figures is sent.

8. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 8 S7-397 (2) Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (See section 7.9.9 ) –The relayed node may select between the following two options: Relayed node reclaim the equivalent one-hop scheduled allocations and remain connected  the relayed node sends a connection request directly to the hub specifying the one hop scheduled allocation using the allocation IDs of the two hop scheduled allocations. The relayed node sent the request in the scheduled allocation between the relaying node and the relayed node. In response to the request the target hub shall send the relaying node an encapsulated connection assignment frame formatted to end the two-hop scheduled allocations as specified in 7.7.5. The target hub send directly an assignment frame to the relayed node formatted to specify the granted one-hop scheduled allocations. Relayed node do not regain equivalent one-hop scheduled allocations and becomes unconnected.  the relayed node sends a connection request directly to the hub formatted to end the allocation as specified in 7.7.5. In response to the request the target hub shall send the relaying node an encapsulated assignment frame formatted to end the two – hop schduled allocation as specified in 7.7.5. The relaying node shall subsequently send the encapsulated assignment frame to the relayed node as specified in 7.9.1.3

9. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 9 S7-467 Page 98, sub clause 7.9, figure 79-80 Comment: It needs to be stated that RTT is provided for scheduled allocation only. Presumably this is the case so as to avoid complicating the relay with having to handle the other access techniques? Proposed change: NA Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (See sub clause 7.9.4 (improvised access ) ) –Scheduled and improvised access are both provided in RTT. The target hub and the relaying node may obtain improvised access according to 7.6.2 as if they were hub and node in one-hop star network to exchange data and management frames The relaying and relayed nodes may obtain improvised access in the scheduled uplink allocation applicable between the target hub and the relaying node to exchange data and management frames

10. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 10 S7-503 Page 99-101, sub clause 7.9.1 & 7.9.2, Line 6-12 in Page 99-101 Line 21-23 & 1-4, Page 100-101 Comment: To replace the text highlighted in the comment Proposed change: " A relay node in emergency recognises whether other nodes are in emergency. The relay node may refuse to act as a relay for other new nodes and may drop connections with existing nodes not in emergency. Existing nodes in emergency may continue relaying through the relay node in emergency. The nodes not in emergency may be blocked by the relay node in emergency when they request to go through it to reach the hub, depending on a count of relay connections maintained by the relay node in emergency. The relay node in emergency may take account of a QoS, congestion level or availability of power to determine whether to drop or maintain connections with other nodes. The existing nodes relaying through the emergency relay node may attempt to relay through an alternative non-emergency relay node to reduce load on the emergency relay node Proposed resolution: Drop

11. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 11 S7-468 same as S7-466 Page 99-100, sub clause 7.9, figure 79/80 Comment: Text in 7.9.2 suggests that the state machine for leaf node to relay is as per original fig 4a/4b (for setup phase only) according to if secure or not. Fig 79 does not really show this with its association/authentication arrow and is there a subsequent association phase from relay to hub if the leaf node to hub is secured? Proposed change: Add a state diagram to complement the signalling shown for node to relay link in RTT Proposed resolution: Same as S7-466

12. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 12 S7-408 Page 98, sub clause 7.9, Line 7 Comment: This sub clause has yet to define the frame structures used to support the relay functionality, and to specify the access methods and the functional behaviours of all the parties involved (hub, relaying node, and relayed node). Proposed change: Rewrite the whole subclause to address the outstanding issues. Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006.

13. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 13 S7-396 Page 102, sub clause 7.9.3.2, figure 81/82 Comment: When a device is connected to a hub (with allocations) and then initiates the relay procedure what happens to its old slot(s) allocated by the hub? Does the hub cancel the allocation on reception of the new Connection Request or is the allocation left unmodified and eventually expires as per 7.7.4? Proposed change: text Add clarifying Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (See sub clause 7.9.5.1 and 7.9.5.2 for connection request for two hop extension sent by relayed node and the connection assignment for the two-hop extension sent by the hub to replace the existing allocations between the hub and the relayed node).

14. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 14 S7-527 Page 106 sub clause 7x, Line 7 Comment: Section 7.9 "Two-hop star topology extension" is not linked with security. Is the standard going to provide security for "two - hop star" or not? Proposed change: clarify Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (See sub clause 7.9.1 of IEEE P802.15-10-0544-02-0006 for security provision in two-hop star extension)

15. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 15 Comments not assigned to me but related to sub clause 7.9

16. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 16 S7-445 & 446 Editorial S7 – 445 –Page 98, sub clause 7.9, line 10 –Proposed change : change "have been already" to "has already been –Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 S7 – 445 –Page 98, sub clause 7.9, line 11 –Proposed change : change "have" to "has" –Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006

17. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 17 S7-413 Editorial Page 98, sub clause 7.9, line 9 Comment: The use of below is not descriptive. Proposed change : Insert cross reference Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006

18. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 18 S7-158 Page 98, sub clause 7.9, line 7 Comment: There are many limitations and requirements on transactions when using a 2-Hop Star Topology that are not defined Proposed change : Access types should be limited to Contention, and Scheduled Bilink. The "Relaying" Node must listen during RAP/CAP for messages from existing and potential "Relayed" nodes. The "Relaying" Node must also perform poll & post transactions to the "Relayed" node. Scheduled access between the "Relaying" Node and the "Relayed" node needs to be allocated by the Hub, such that sufficient time is given for retransmission of unacknowledged frames within the scheduled allocation period. There shall be no Improvised Bilink or Delayed Bilink between the "Relaying" node and the "Relayed" node. There also needs to be further definition of the Relay bit in the header such that, if the Relay bit is set, it indicate that the Frame Payload contain an Encapsulated frame, and it is zero otherwise. Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006. Relay bit defined as follows: –uplink, down link and bilink access may exist between the relaying node and relayed node (sub clause 7.9.5 ) –1 in data frames and management frame to indicate encapsulated frames, 0 other wise –1 in control frame to indicate feasibility of relaying or relayed capbility, o otherwise

19. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 19 S7-426 & S7-432 same as S7-408 same as S7- 408

20. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 20 S7-470 Page 103, sub clause 7.9, line 16 Comment: What happens when the guard time becomes greater than the allocation interval? Proposed change : Suggest defining a maximum Synchronisation interval to avoid continual increment of Gta? Proposed resolution: Rejected. The relayed node has a say in requesting each of its allocation interval to be larger than its anticipated guard time. Should its overall clock drift exceed its predetermined threshold, it would resynchronize with the hub (through the T-Poll frames from the relaying node). The replacement text has specifically stated how a relayed node does the synchronization.

21. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 21 S7-401 Page 100, sub clause 7.9 Comment: Use of SN Proposed change : Would be clearer to refer to it as leaf node Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02- 0006 –SN is now referred as relayed node instead

22. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 22 S7-481 Page 98, sub clause 7.9.1, line 18 Comment: For a sensor node to overhear an ACK from an RN, it needs to be able to receive this message, but according to 7.2.4 because the address isnt correct, this frame cannot be received. Proposed change: change 7.2.4 to add optional reception of ACK frame with RN Sender address if Sensor node is a relayed Node Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 (see 7.9.2, specifically the following sentence: The relayed node may receive such acknowledgment frames based on the frame reception rules specified in 7.2.4, with appropriate exceptions given to the values of the Recipient ID and Sender ID fields of the MAC header of the frames.)

23. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 23 S7-480 Page 98, sub clause 7.9.1, line 18 Comment: how does a sensor node know that an ACK is from a relaying node? Proposed change : 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. Proposed resolution: Accepted in principle. The comment is addressed in IEEE P802.15-10-0544-02-0006 –Relay bit in ACK frame is used to indicate capability of being a relaying node

24. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 24 S7-250 Page 99, sub clause 7.9.2, line 13 Comment: A node must not be able to join a BAN by connecting through a relay. This would introduce risks with respect to security and lead to condition where relay is used by the new nodes as the nominal route to hub, rather than the exception. Proposed change: Clarify this sub clause to ensure that connection to a BAN cannot occur via a Relay Node Proposed resolution: Accepted in principle. The comment is addressed IEEE P802.15-10-0544-02-0006. The new replacement text carefully addresses the raised security issue, requiring any relayed node to conform with the same security state diagram as for a one-hop star network in its relationship with the target hub.

25. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 25 S7-252 Editorial Page 99, sub clause 7.9.2, line 7 Proposed change: Change to "they become orphaned. Therefore, if a SN experiences a bad connection or becomes orphaned, knowing the“ Proposed resolution: Reject as the whole sub clause 7.9 is replaced.

26. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 26 S7-249 Page 100, sub clause 7.9.2, line 21 Comment: Reference is made to the reception of an "emergency data frame". Is this a specific frame type? If so, it has not been defined. Is this a data frame with user priority set to medical emergency as in Table 17? Proposed: Clarify the definition of emergency frame as used in this context. Proposed resolution: Accepted in principle. –Emergency frames are defined in Table 3. Throughout Clauses 6 and 7, frame subtype names defined in Table 3 are used to name the corresponding frames -- Poll frames, B2 frames,..., and hence Emergency frames. –For consistency and for clarification, on page 54, line 13, after "A data type frame of Emergency subtype", add ", i.e., an Emergency frame,". –Note that "Emergency frame" is also referenced in the MICS band sub clause 7.8.

27. doc.: IEEE 802.15-10-0652-00-0006 Submission September 2010 Hind Chebbo, FujitsuSlide 27 S7-402 Editorial Page 100, sub clause 7.9.2.0, line 5,7,16 Proposed: “this broadcast messages” to “these broadcast messages”, “SN experience” to “SN experiences” and ”looses” to “loses” Proposed resolution: Reject as the whole sub clause 7.9 is replaced