throbber
Tdoc R2-081764
`
`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.
`
`
`
`SAMSUNG 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.
`
`SAMSUNG 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
`
`SAMSUNG 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:
`
`SAMSUNG 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.
`
`
`
`
`
`SAMSUNG 1005-0005

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket