July 12, 2008 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

Increasing Broadcast Reliability July 12, 2008 Increasing Broadcast Reliability Yongjun Liu, Betty Zhao Huawei Technologies Co., Ltd. Huawei

doc.: IEEE 802.15-<doc#> <month year> July 12, 2008 doc.: IEEE 802.15-<doc#> Contents Reliable broadcast required Current broadcast limitation in 15.4 Towards reliable broadcast Spec impact & compatibility Conclusion Huawei <author>, <company>

Why Reliable Broadcast? July 12, 2008 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

Why Reliable Broadcast? July 12, 2008 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

Why Reliable Broadcast? July 12, 2008 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

Technical Requirements in 4e July 12, 2008 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

Broadcast Limitations in 15.4-2006 July 12, 2008 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 Current broadcast mechanism doesn’t meet the reliability requirement Huawei

Towards Reliable Broadcast July 12, 2008 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

Proposed Reliable Broadcast Method (Summary) July 12, 2008 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

Detail Method for Reliable Broadcast July 12, 2008 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

Detail Method for Reliable Broadcast July 12, 2008 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 broadcast sending Air delay: caused by transmission distance. Processing delay: caused by the processing time. Processing delay Air delay ACK received time time Huawei

Detail Method for Reliable Broadcast July 12, 2008 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

Detail Method for Reliable Broadcast July 12, 2008 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

Detail Method for Reliable Broadcast July 12, 2008 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

Impact & Compatibility July 12, 2008 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

Impact & Compatibility July 12, 2008 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

Conclusions Reliable broadcast is important for quite a few use cases July 12, 2008 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

Thank you for your attention! July 12, 2008 Thank you for your attention! Huawei