Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Increasing Broadcast Reliability] Date Submitted: [12 July, 2008] Source: [Yongjun Liu, Betty Zhao] Company [Huawei Technologies Co., Ltd] Address [No.9 Xinxi Road, Shangdi Information Industry Base, Haidian District, Beijing, P.R.China] Voice: [+86 10 82836430] Fax: [+86 10 82836920] E-Mail: [yongjunliu@huawei.com][betty.zhao@huawei.com] Abstract: [This document addresses the requirements of reliable broadcast and introduce a mechanism.] Purpose: [Response for CFP.] 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. Huawei

2. Increasing Broadcast Reliability Yongjun Liu, Betty Zhao Huawei Technologies Co., Ltd. Huawei

3. Contents • Reliable broadcast required • Current broadcast limitation in 15.4 • Towards reliable broadcast • Spec impact & compatibility • Conclusion Huawei

4. Why Reliable Broadcast? • Information Delivery: better user experience is required - Users may not feel happy if they often fail to receive the broadcast information, e.g. weather forecast, sport news etc. - Shops or enterprises would like to distribute their advertisement more successfully Huawei

5. Why Reliable Broadcast? • Industrial Scenarios: critical for urgent messages - e.g. in mining industry, it’s very important to distribute the urgent message in time when danger takes place, while multiple unicast is too slow in emergency. Run! Huawei

6. Why Reliable Broadcast? E.g. coordinator realignment command is broadcasted to notify all the devices changing channel. • MAC commands sent by broadcasting can gain better performance - Reliable broadcast helps saving energy, channel resource and time by decreasing the unnecessary operations. If the device missed the command, more energy and channel resource will be consumed later due to unnecessary retransmission. Huawei

7. Technical Requirements in 4e • Reliability/Fail detect/Fail recovery • Non-detected corrupt packets • Packet drop policy • Error reporting (route selection, next hop selection, etc.) • Broadcast and Multicast reliability • Device failure detection (e.g. coordinator, PAN coordinator, etc.) • Link quality and failure detection • Recovery time from link failure • Recovery time for coordinator failure • Logging mechanism • Packet error detection and correction (EDAC) • Tolerance to node failure Huawei

8. Current broadcast mechanism doesn’t meet the reliability requirement Broadcast Limitations in 15.4-2006 • Only defined in the beacon-enable network • Limited broadcast schedule: transmitted immediately following the beacon • Limited broadcast times: only one broadcast message shall be allowed to be sent indirectly per superframe • Broadcast without ACK: no reliability guaranteed Huawei

9. Towards Reliable Broadcast • ACK is a good method, but… • Broadcast is a one-to-all transmission -How to avoid ACK collisions? -How to avoid too many time slots occupied by ACKs? ACK collides! A B broadcast packet C broadcast ACK Too much time! Huawei

10. Proposed Reliable Broadcast Method (Summary) • ACK is required for reliable broadcast • Instead of avoiding ACK collisions, let them overlap on purpose (completely collision) • Estimate the broadcast receiving status by the overlapped ACK (RSSI/LQI). Rebroadcast if necessary All the ACKs can be overlapped as a single stronger ACK since every ACK frame format is same! Huawei

11. Detail Method for Reliable Broadcast • Set “Ack Request” subfield in broadcast frame to 1 for requesting ACK • Try to make all ACKs arrive at the broadcast sender simultaneously Huawei

12. Detail Method for Reliable Broadcast • How to make all ACKs arrive at the broadcast sender simultaneously? - Deal with different air delay and processing delay of each receiver broadcast sender broadcast receiver Air delay: caused by transmission distance. Processing delay: caused by the processing time. broadcast sending Processing delay Air delay ACK received time time Huawei

13. Detail Method for Reliable Broadcast • How to make all ACKs arrive at the broadcast sender simultaneously? (cont.) - Decrease the difference between turnaround times if necessary! Fix the processing time and compensate for air delay - Fix processing time: ACK shall be sent immediately T(μs) after receiving the broadcast packet by receivers - Compensate for air delay: estimate the turnaround time or distance in advance Huawei

14. Detail Method for Reliable Broadcast • Generally speaking, air delay compensation is not necessary. • For example, to gain the positive overlapped ACK, - 2.4GHz OQPSK: <1/2 chip, i.e. <75m distance difference - 868MHz BPSK: <1/4 chip, i.e. <250m distance difference • Actually many applications are within shorter communication range than those! C0 C2 C4 C1 C3 C5 C0 C2 C4 C1 C3 C5 permitted delay difference Huawei

15. Detail Method for Reliable Broadcast • Estimate the receiving status of broadcast packet by RSSI/LQI of the overlapped ACK - Higher the RSSI/LQI is, more receivers received it Huawei

16. Impact & Compatibility • Impact to current spec - ACK for broadcast is required - Two attributes: one is the duration between broadcast packet received and ACK sent by receivers, and one is sender’s max rebroadcast time - Description of the method of estimating the receiving status by ACKs Huawei

17. Impact & Compatibility • Keep compatible - Legacy device broadcasting: same as current mechanism, i.e. no ACK request - Legacy device receiving: don’t count on it returning ACK, just lower RSSI/LQI expected Huawei

18. Conclusions • Reliable broadcast is important for quite a few use cases • Current broadcast mechanism lacks reliability • A reliable broadcast mechanism is proposed - ACK required - Overlapped ACK - Estimate receiving status by LQI/RSSI of overlapped ACK • Little impact to current spec and good compatibility Huawei

19. Thank you for your attention! Huawei