HARQ Processing Time (AWD ) Document Number: IEEE C802.16m-09/1459 Date Submitted: Source: Aran Intel Corporation Re:Category: AWD-Comments / Area: Chapter (A-MAP relevance and HARQ timing) “Comments on AWD (A-MAP relevance and HARQ timing) ” Venue:IEEE Session#62, San Francisco Base Contribution: C802.16m-09_1460.doc (or later versions) Purpose: Discussion and Adoption by TGm 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.

Introduction In the following slides we will show the breakdown of the UL timeline and explain: – Why a minimum number of 3 subframes for UL MAP relevance may not be sufficient – Why we think UL MAP relevance and retransmission delay (which affects HARQ RTT) should be specified separately

Current AWD Text In the current text, section specifies a single T proc parameter that is used to accommodate for MS / BS processing delay – T proc is assumed to be 3 subframes both for 1 st transmission and for retransmission

UL MAP Relevance vs. ReTX Retransmission requires – Decoding the HARQ NACK in the A-MAP (or MAP IE which indicates retransmission) – Preparing the bursts retransmission Possibly includes encrypting the burst again (an implementation choice) – Encoding the burst (might not be required if MCS does not change) New transmissions require – Decoding and parsing the UL MAP IEs – Making scheduling decisions (prioritize SDUs), BW Requests, other signaling headers, Packing, Fragmentation and possibly Multiplexing SDUs/PDUs – Encrypting the burst – Encoding the burst In RED are parts of the flow that MUST be done in a new burst transmission, but not necessarily in retransmissions (implementation choice/tradeoffs)

Our Claim Implementation complexity – Potentially need to process more than 100 SDUs for an UL transmission (see next slide) – Reducing processing delay of new transmissions is much more complex than reducing processing delay for retransmissions  affects cost and TTM Performance – System latency is not affected (assuming MAP relevance and BW Request  Grant delay is not part of the requirement)

SDUs per Frame Scenario Definition – DL TCP flow with a very large window (or multiple DL TCP flow) – Good link conditions (rate = 7/8,,modulation = 64QAM) – 3 DL streams, 20 MHz – DL:UL = 5:3  DL throughput = ~145 Mbps Assumptions – BS processing (BW request  grant) delay is ~6 subframes – Allocations on the UL use long TTI Interval between grants – 3 frames (which include 15 DL subframes) – see backup slides for steady-state analysis TCP generates a TCP-ACK (40 bytes) for every 2 received DL SDUs There are ~ byte SDUs in each DL subframe  Need to send ~ 98 TCP-ACKs in each UL allocation

FDD UL HARQ Retransmission

FDD UL HARQ New Transmission This flow does not account for the current AWD text on HARQ timing and UL MAP relevance

Suggested FDD UL HARQ Timing (Example) Using the current AWD text on HARQ timing, considering the different Tproc for new transmissions

TDD UL HARQ Retransmission

TDD UL HARQ New Transmission This flow does not account for the current AWD text on HARQ timing and UL MAP relevance

Suggested TDD UL HARQ Timing (Example) Using the current AWD text on HARQ timing, considering the different Tproc for new transmissions

Variations UL Allocations with long TTI (over all UL subframes) – More UL capacity  more bytes in the allocations and more SDUs/PDUs and bytes to process before the beginning of the UL transmission – Encryption might take longer (assuming encryption is at done at air-speed) – Encoding might take longer (assuming a single encoder and encoding is done at air-speed)

Possible Tradeoffs At a cost of increased UL memory we could avoid – Encryption of a retransmitted burst (medium cost) – Encoding of a retransmitted burst (high cost) Both options increase the difference between processing delays in case of a new UL transmission and a retransmitted UL burst

Conclusions Separate T proc to 2 cases: – UL HARQ retransmission and DL HARQ transmissions (T proc ) – UL HARQ new transmissions (T proc,new ) Recommended values: – T proc = 1.8 ms (3 subframes) – T proc,new = 3 ms (5 subframes) Possibly - negotiate T proc,new as part of AMS capability or AMS’s device class

BACKUP

FDD DL HARQ

TDD DL HARQ

Interval Between Grants Long TTI Short TTI