Feedback Considerations for HR-MS Networks IEEE 802.16 Presentation Submission Template (Rev. 9) Document Number: IEEE C802.16n-11/0149 Date Submitted: 2011-09-12 Source: Eldad Zeira Voice: InterDigital E-mail: eldad.zeira@interdigital.com Anh Tuan Hoang, Haiguang Wang I2R Venue: IEEE 802.16n at session #75 responding to call for comments for AWD 802.16n-11/0015 Base Contribution: N/A Purpose: To be discussed and adopted by 802.16n Notice: This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16. Patent Policy: The contributor is familiar with the IEEE-SA Patent Policy and Procedures: <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>. Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >. 1

Feedback Considerations for HR-MS Networks Eldad Zeira, Anh Tuan Hoang, Haiguang Wang InterDigital & I2R

Feedback has been proposed – several times - and rejected. Why? Introduction Feedback has been proposed – several times - and rejected. Why? For e-MBS (or MBMS): High reliability not required, “TV” like model is inherently fault tolerant For M2M (16p discussion): Prohibitively high overhead? Is there a better way?

Current understandings re feedback Feedback is required for: Achieving required robustness without an undue number of retransmissions Network awareness of success of delivery AWD states that multicast feedback is provided for: Logical ACK, NAK or both Connected as well as idle states In some scenarios (e.g. smart grid) there is potentially a huge number of devices that may be required to provide feedback to application level commands send by multicast For these scenarios most HR-MS will be in idle, we should focus on this state

MAC messages, for example (as in LG proposal to 16p) Alternatives MAC messages, for example (as in LG proposal to 16p) Idle: AAI-RNG-REQ message (i.e., location update procedure) Connected: AAI-MRT-REQ Ranging – using Quick Access Message Ranging – code only

One code/T/F = one feedback channel Pre-allocated Code only feedback Ranging codes only One code/T/F = one feedback channel Pre-allocated Can be used for logical ACK or NAK Usage for ACK: Individual channel assignment Usage for NAK: Group (or “service”) based channel assignment Collisions are interpreted as single

Comparison of techniques MAC message: AAI-RNG-REQ Quick message access Code-only feedback Applicable states Idle (different message for connected) Connected, idle1 Connected, idle Applicable specs 16-2009, 16m 16m (new usage of existing message) Either - new Logical usage NAK (as proposed) ACK, NAK Load (in required channels): ACK ={expected number of accesses}X{margin} Load (in required channels): NAK << {expected number of accesses} 1 Assuming MS keeps its cell-ID Margin required only if common channel is used

Load of feedback (16m example) – a very crude analysis AAI-RNG-REQ Quick Access message Code only Process Preamble + (RNG-ACK) + (RNG-REQ) Preamble + (attached quick message) + RNG-ACK Preamble + RNG-ACK Resources: UL Preamble ~1 RB per RNG-REQ ~1/2 RB per message Resources: DL ~1/2 RB per RNG-ACK Accesses per channel, MA: ACK 1 Accesses per channel, MA: NAK Number depends on synchronization and mobility of HR-MS but ~10 is reasonable Load per user, ACK Load per user, NAK RNG-ACK assumed necessary to stop ramping – great savings for “code only” / NAK if not used Nc: Number of distinct codes that can be detected in one RB at one time, Nc >> 1 Number of resource blocks is an approximate as message size isn’t determined; Assuming 1 DL RB5B, 1UL RB  2B p = probability of sending feedback (assuming  1 for ACK, <<1 for NAK) MA: number of accesses per channel for code only method, MA >> 1

Rough calculation: resource blocks per 1000 users Load in RB AAI-RNG-REQ Quick Access message Code only With RNG-ACK: For ACK 1500 1000 500 For NAK 75 50 2.5 Without RNG-ACK: 100 25 0.5 Assuming: - p = .05 (initial transmission) MA = 10 Nc = 10 (this number depends on the ranging format as well as other factors that are yet to be determined. A conservative number selected)

Interpretation NAK reduces feedback requirements relative to ACK by a factor of 1/p. Removing RNG-ACK may be good tradeoff for “code only”/NAK, not other cases MAC messages (even using quick access) burden prohibitive for large number of users Code only feedback for NAK requires 2-3 orders of magnitude fewer resources than other methods

Correction of omission Contribution c802.16n-11/0106r1 has introduced feedback for multicast into the AWD The contribution proposed feedback for 16m (AAI) based amendment, omitting a parallel change for rev-3 based systems. We propose to adopt the same language for 17.2. See slide below. Blue text adds the code only feedback.

Text Proposal 1: 17.3 Modify 17.3.9.2.2 as follows: … Feedback operation is supported by multicast addressees in connected as well as in idle states. Code-only feedback may be used to provide feedback for multicast. The procedure for providing the feedback is TBD.

Text proposal 2: 17.2 Insert: 17.2.9.2.2 Feedback for multicast information To ensure robust multicast and provide the network operator with specific or statistical information of its reception a feedback operation is defined between an HR-MS that is an addressee of a multicast transmission and its serving HR-BS or HR-RS. The conditions for providing feedback are defined by the network per each multicast channel and include positive feedback only (logical ACK), negative feedback only (logical NAK) or both (logical ACK/NAK). It is expected that all intended recipients of a multicast channel obey the same rules but those can be changed by the network. UL resources for the feedback are also provided by the HR-BS. Feedback parameters may be unicast or multicast. Feedback operation is supported by multicast addressees in connected as well as in idle states. Code-only feedback may be used to provide feedback for multicast. The procedure for providing the feedback is TBD.