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
InterDigital
Voice:
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
IEEE C802.16n-11/0149
Feedback Considerations for HR-MS Networks
Eldad Zeira, Anh Tuan Hoang, Haiguang Wang
InterDigital & I2R
IEEE C802.16n-11/0149
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?
IEEE C802.16n-11/0149
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
IEEE C802.16n-11/0149
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
IEEE C802.16n-11/0149
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
IEEE C802.16n-11/0149
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
ACK, NAK
Load (in required
channels): ACK
={expected number of
accesses}X{margin}
={expected number of
accesses}X{margin}
={expected number of
accesses}X{margin}
Load (in required
channels): NAK
={expected number of
accesses}X{margin}
={expected number of
accesses}X{margin}
<< {expected number of accesses}
1 Assuming
MS keeps its cell-ID
Margin required only if common channel is used
IEEE C802.16n-11/0149
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
Preamble
~1/2 RB per message
Preamble
Resources: DL
~1/2 RB per RNG-ACK
~1/2 RB per RNG-ACK
~1/2 RB per RNG-ACK
Accesses per channel,
MA: ACK
1
1
1
Accesses per channel,
MA: NAK
1
1
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
IEEE C802.16n-11/0149
Rough calculation: resource blocks per 1000 users
Load in RB
AAI-RNG-REQ
Quick Access
message
Code only
For ACK
1500
1000
500
For NAK
75
50
2.5
For ACK
1000
500
100
For NAK
50
25
0.5
With RNG-ACK:
Without RNG-ACK:
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)
IEEE C802.16n-11/0149
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
IEEE C802.16n-11/0149
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.
IEEE C802.16n-11/0149
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.
IEEE C802.16n-11/0149
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 HRBS 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.