1. Feedback Considerations for HR-MS Networks
IEEE Presentation Submission Template (Rev. 9)
Document Number:
IEEE C802.16n-11/0149
Date Submitted:
Source:
Eldad Zeira Voice:
InterDigital
Anh Tuan Hoang, Haiguang Wang
I2R
Venue:
IEEE n at session #75 responding to call for comments for AWD n-11/0015
Base Contribution:
N/A
Purpose:
To be discussed and adopted by n
Notice:
This document does not represent the agreed views of the IEEE 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
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< and <
Further information is located at < and < >. 1

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

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

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

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

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

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

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

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

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

11. 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 See slide below. Blue text adds the code only feedback.

12. Text Proposal 1: 17.3
Modify 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.

13. Text proposal 2: 17.2 Insert:
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.