`
`3GPP TSG-RAN WG2#61bis
`Shenzhen, China, March 31-April 4, 2008
`
`Agenda item: 5.1.1.10
`Philips, NXP Semiconductors
`Source:
`Title:
`Control of HARQ for RACH message 3
`Document for: Discussion and Decision
`
`1. Introduction
`The current contention based RACH procedure is as shown in figure 1:
`
`Figure 1 RACH Procedure
`
`
`
`
`
`RACH message 1 comprises the transmission of a randomly selected signature (“preamble”). A “collision” is
`said to have occurred if more than one UE transmits the same preamble signature in the same time-
`frequency resource.
`
`In case of a collision, all the colliding UEs interpret message 2 (which is transmitted by the eNB in response
`to a preamble and contains an identifier of the preamble, an UL resource grant for the transmission of
`message 3, and a Temporary C-RNTI) as being for them, and all transmit a message 3 (conveying at least a
`NAS UE Identifier) in the same UL resources.
`
`The eNB will transmit “ACK” if it successfully decodes message 3, while if it fails to decode message 3 it will
`transmit “NACK” and the UE(s) will retransmit up to the configured maximum number of retransmissions.
`
`2. HARQ for Message 3
`If the eNB succeeds in decoding message 3, HARQ ACK is sent and any collision is resolved when message
`4 is received.
`
`
`
`ZTE/HTC
`Exhibit 1005-0001
`
`
`
`RA procedure initiated
`(upon request from higher layer, a PDCCH
`order or by MAC sublayer itself)
`
`Set PREAMBLE_TX_COUNTER to 1
`
`RA preamble
`explicitly signaled?
`
`No
`
`RA preamble selection
`
`Wait until next RA preamble
`transmission occasion
`
`Transmit RA preamble
`
`Overload indication
`received within TTI
`window ?
`
`RA response (including
`grant for UL-SCH
`received
`within TTI window ?
`No
`
`NO
`
`No
`
`Yes
`
`NO
`
`Transmit Message 3
`
`Max # re-
`transmissions
`reached?
`
`HARQ Failure
`
`NACK
`
`Wait for ACK/
`NACK
`
`ACK
`
`ACK
`
`HARQ Failure
`
`Start Contention
`Resolution Timer
`
`YES
`
`Store overload information
`
`Message 3
`
`Yes
`
`Transmit on UL-SCH
`
`PREAMBLE_TX_COUNTER <
`PREAMBLE_TX_MAX ?
`
`No
`
`RA procedure triggered
`by higher layer?
`
`Yes
`
`YES
`
`YES
`
`Report failure to higher
`layer
`
`NO
`
`Increment
`PREAMBLE_TX_COUNTER
`
`NO
`
`RA procedure triggered
`by higher layer?
`
`End RA procedure
`
`Success
`
`Failure/
`Timer Expiry
`
`Contention
`resolution result
`
`RA preamble
`selection needed?
`
`Yes
`
`Compute and apply back-off
`(based on the overload information)
`
`Figure 2 MAC Random Access Procedure
`
`
`
`
`
`Figure 2 shows how the HARQ procedure for Message 3 is included in the random access procedure. In this
`diagram we assume the contention resolution timer is not started until after an ACK has been received for
`message 3. HARQ failure in message 3 leads to the same result as contention resolution timer expiry.
`
`However, in practice if a collision occurs, the likelihood is that no number of retransmissions will succeed, as
`all the colliding UEs will retransmit at the same time.The maximum number of HARQ retransmissions of
`message 3 should therefore be tightly limited, as a high maximum number of retransmissions will simply
`increase the delay before the collided UEs can start again.
`
`Moreover, if the transmit power is set appropriately after the last power-ramped preamble transmission, a
`large number of retransmissions should be unnecessary.
`
`2.1 RRC_IDLE and Connection Re-establishment cases
`UEs which are RRC_CONNECTED already have a valid C-RNTI for transmission in message 3.
`
`For UEs which are repeatedly or regularly accessing the network, it is undesirable for them to have to start
`the RACH access procedure again from the beginning every time a collision occurs. Some delay can be
`avoided for these UEs by allowing a larger number of HARQ retransmissions for message 3 if the UE
`already has a C-RNTI. In this case the eNB could flush its message 3 reception buffer when it reaches the
`maximum number of retransmissions for UEs which do not have a C-RNTI, and then still receive the
`message 3 from the UE with a C-RNTI. This would mean that the Node B would in any case NACK the first
`retransmission, but UE’s with only a temporary C-RNTI would not be allowed to retransmit, while UEs with a
`C-RNTI would retransmit again.
`
`ZTE/HTC
`Exhibit 1005-0002
`
`
`
`
`
`UE With C-RNTI MAC Control Element
`
`UE With Contention Resolution Identity
`
`Message 3
`Message 3
`
`NACK
`
`Message 3
`Message 3
`
`NACK
`
`Message 3
`
`ACK
`
`Message 4
`
`
`
`Reached max # re-
`tranmsissions
`(configured for UEs
`using Contention
`Resolution Identity)
`
`Start Contention
`resolution timer
`
`Figure 3 HARQ control for UEs with and without C-RNTI
`
`Figure 3 shows a case of 2 collided UEs transmitting message 3, one including a C-RNTI MAC control
`element and one with RRC UE Contention resolution Identity. In this example, the eNB sends back NACK
`twice, then the maximum number of re-transmissions is reached for the UE using the Contention Resolution
`Identity (as it does not yet have a C-RNTI). The Message 3 from the UE using C-RNTI is then received
`successfully at the eNB and the eNB sends ACK to the UE. The UE then starts the contention resolution
`timer and, in this example, successfully receives message 4.
`
`Although setting a different maximum number of retransmissions would not help in the case of a collision
`between two UEs both with C-RNTIs, it would effectively give priority to the UE with a C-RNTI in the case of
`a collision with a UE without a C-RNTI.
`
`5. Conclusions
`In this contribution, we have presented our views on HARQ control for message 3.
`
`-
`
`-
`
`the maximum number of HARQ retransmissions should be kept reasonably low, in order to limit the
`delay in case of a collision;
`
`it should configure a higher maximum number of message-3 HARQ retransmissions for UEs which
`already have a C-RNTI than for UEs which do not already have a C-RNTI.
`
`6. References
`[1] TS36.321 3GPP TS 36.321 V8.1.0 (2008-03) MAC Protocol Specification
`
`ZTE/HTC
`Exhibit 1005-0003
`
`
`
`7. Text Proposal for 36.321
`
`
`
`
`HARQ process
`5.4.2.2
`Each HARQ process is associated with a HARQ buffer.
`
`Each HARQ process shall maintain a state variable CURRENT_TX_NB, which indicates the number of transmissions
`that have taken place for the MAC PDU currently in the buffer. When the HARQ process is established,
`CURRENT_TX_NB shall be initialized to 0.
`
`The UE is configured with a maximum number of transmissions that is identical across all HARQ Processes and all
`Logical Channels.
`
`If the HARQ entity provides a new PDU, the HARQ process shall:
`
`-
`
`-
`
`-
`
`set CURRENT_TX_NB to 0;
`
`set CURRENT_IRV to 0;
`
`store the MAC PDU in the associated HARQ buffer;
`
`- generate a transmission as described below.
`
`If the HARQ entity requests a re-transmission, the HARQ process shall:
`
`-
`
`if there is a measurement gap at the time of the re-transmission:
`
`-
`
`increment CURRENT_TX_NB by 1;
`
`- else:
`
`-
`
`if an uplink grant for this was received on [PDCCH]:
`
`-
`
`set CURRENT_IRV to the value indicated in the uplink grant;
`
`- generate a transmission as described below;
`
`-
`
`if no uplink grant for this was received on [PDCCH]:
`
`-
`
`if a HARQ ACK was received for the last preceding transmission of the same data:
`
`-
`
`increment CURRENT_TX_NB by 1.
`
`-
`
`if no HARQ ACK was received for the last preceding transmission of the same data:
`
`- generate a transmission as described below.
`
`To generate a transmission, the HARQ process shall:
`
`instruct the physical layer to generate a transmission with the redundancy version corresponding to the
`-
`CURRENT_IRV value and the transmission timing;
`
`-
`
`if CURRENT_IRV < [Y] [FFS]:
`
`-
`
`increment CURRENT_IRV by 1;
`
`-
`
`increment CURRENT_TX_NB by 1;
`
`The HARQ process shall:
`
`ZTE/HTC
`Exhibit 1005-0004
`
`
`
`-
`
`if CURRENT_TX_NB = maximum number of transmissions configured (where in the case of the uplink grant
`having been received in a Random Access Response, the maximum number of transmissions depends on
`whether the UE already has a C-RNTI):
`
`-
`
`-
`
`flush the HARQ buffer;
`
`if the transmission corresponds to a transmission of CCCH and no HARQ ACK is received for this process:
`
`- notify RRC that the transmission of the corresponding MAC SDU failed.
`
`The HARQ process may:
`
`-
`
`if CURRENT_TX_NB = maximum number of transmissions configured (where in the case of the uplink grant
`having been received in a Random Access Response, the maximum number of transmissions depends on
`whether the UE already has a C-RNTI) and no HARQ ACK is received for this process:
`
`- notify the relevant ARQ entities in the upper layer that the transmission of the corresponding RLC PDUs
`failed.
`
`Editor’s note: Demultiplexing of multiple positive or negative acknowledgements and the time of reception relative
`to the transmission of data in a HARQ process is handled by L1.
`
`
`
`
`
`ZTE/HTC
`Exhibit 1005-0005