1. July 12, 2008
Project: IEEE P 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: [ ] Fax: [ ]
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 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
Huawei

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

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

4. 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

5. 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

6. 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

7. 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

8. Broadcast Limitations in 15.4-2006
July 12, 2008
Broadcast Limitations in
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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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