1
`
` R2-084387
`
`3GPP TSG-RAN WG2 #63
`Jeju, South Korea
`18 – 22, August, 2008
`
`: 6.1.1.4
`Agenda Item
`: LG Electronics Inc.
`Source
`: Handling of Received UL Grant in RA procedure
`Title
`Document for : Discussion and Decision
`
`Discussion
`1
`Regarding handling of a received UL grant during a random access procedure, a couple of notes in the current
`specification [1] are inserted as follows.
`
`
`
`
`
`NOTE: When an uplink transmission is required, e.g., for contention resolution, the eNB should not provide a
`grant smaller than 80 bits in the Random Access Response.
`
`NOTE:
`
`If within a Random Access procedure, an uplink grant provided in the Random Access Response for the
`same group of Random Access Preambles has a different size than the first uplink grant allocated during
`that Random Access procedure, the UE behavior is not defined.
`
`NOTE:
`
`If the UE receives both a grant for its RA-RNTI and a grant for its C-RNTI, the UE may choose to
`continue with either the grant for its RA-RNTI or the grant for its C-RNTI.
`
`And following text in [1] states the current UL HARQ operation.
`
`At the given TTI, the HARQ entity shall:
`
`-
`
`if an uplink grant indicating that the NDI has been incremented compared to the value in the previous
`transmission of this HARQ process is indicated for this TTI or if this is the very first transmission for this
`HARQ process (i.e. a new transmission takes place for this HARQ process):
`
`-
`
`if there is an ongoing Random Access procedure and there is a MAC PDU in the [Message3] buffer:
`
`- obtain the MAC PDU to transmit from the [Message3] buffer.
`
`- else, if the "uplink prioritisation" entity indicates the need for a new transmission:
`
`- obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity;
`
`-
`
`instruct the HARQ process corresponding to this TTI to trigger a new transmission using the identified
`parameters.
`
`- else:
`
`-
`
`flush the HARQ buffer.
`
`- else, if an uplink grant, indicating that the NDI is identical to the value in the previous transmission of this
`HARQ process (i.e. a retransmission takes place for this HARQ process), is indicated for this TTI:
`
`-
`
`instruct the HARQ process to generate an adaptive retransmission.
`
`3GPP
`
`SAMSUNG 1010-0001
`
`

`
`
`
`2
`
`- else, if the HARQ buffer of the HARQ process corresponding to this TTI is not empty:
`
`-
`
`instruct the HARQ process to generate a non-adaptive retransmission.
`
`Selection between a grant for C-RNTI and a grant for RA-RNTI
`1.1
`It is our understanding that the above third note highlighted in yellow is relevant only before generating a MAC PDU
`for message 3 because the building the MAC PDU can be based on either a grant for a RA-RNTI or a grant for a C-
`RNTI. That is, the MAC PDU including BSR can be handled with either the grant for the RA-RNTI or the grant for the
`C-RNTI. However, once the MAC PDU is built and stored in [Message 3] buffer, it is not clear whether or not the UE
`can still choose between them when the UE is having the both grants. That is, while there is a MAC PDU in [Message
`3] buffer, if a UE has a grant for its C-RNTI and a grant for its RA-RNTI, the current specification says that the UE can
`take one of them as the note highlighted in yellow. If the UE takes the grant for its C-RNTI, the current specification
`also says that the HARQ entity obtains the MAC PDU from the [Message 3] buffer and instructs the HARQ process to
`store it in HARQ buffer as the text highlighted in green. However, it is unlikely that the MAC PDU transmission is
`properly handled with the grant for the C-RNTI because the MAC PDU already was generated by not the grant for the
`C-RNTI but the grant for the RA-RNTI. Therefore, the selection should be allowed only before the building the MAC
`PDU for the message 3. Also, the MAC PDU in the [Message 3] buffer should be handled with only the grant for the
`RA-RNTI.
`
`Proposal 1: It is proposed to modify the note like “if the UE receives both a grant for its RA-RNTI and a grant for its
`C-RNTI , and [Message 3] buffer is empty, the UE may choose to continue with either the grant for its RA-RNTI or the
`grant for its C-RNTI”.
`
`Proposal 2: It is also proposed that only when an UL grant is indicated in a Random Access Response, the HARQ
`entity instructs the HARQ process to store a MAC PDU stored in [Message 3] buffer in HARQ buffer.
`
`Handling of an UL grant addressed to a C-RNTI during RA
`1.2
`With proposal 1 and 2, during a RA procedure, when the UE receives a grant for its C-RNTI except for a purpose of
`contention resolution, we assume that the HARQ entity obtains a new MAC PDU from “Multiplexing and assembly”
`entity and the HARQ process starts to transmit it. However, the concern is whether or not we can allow to take an UL
`HARQ not related to the ongoing RA procedure and a Random Access procedure in parallel.
`
`If taking both in parallel, there is a possibility that the time of the transmission upon the received grant is collided with
`the time of RA preamble transmission as depicted in figure 1. Although it is a rare case, we should not allow to happen
`it because such happening breaks a single carrier property of an uplink transmission. Then, we end up with falling in
`selection between the UL HARQ transmission and a RA preamble transmission. It would be complicated to implement
`it in MAC.
`
`UE
`
`eNB
`
`Random Access Preamble
`
`Message 3
`
`Time that CR is
`considered not successful
`
`Colliding the UL
`transmission with RA
`preamble
`
`UL HARQ transmission ?
`Random Access Preamble ?
`
`Due to no knowledge on
`the UE’s ongoing RA
`procedure
`
`
`
`Figure 1
`
`3GPP
`
`SAMSUNG 1010-0002
`
`

`
`
`
`3
`
`If we take only UL HARQ, it would mean that the ongoing RA procedure is cancelled. Then, the BSR in the MAC PDU
`in the [Message 3] buffer is lost. So, as long as a new BSR is not triggered, the UE would be stalling. Furthermore,
`currently, an endless RA attempt is supervised by RRC. So, if the ongoing RA procedure is cancelled by MAC itself, it
`would be complicated to implement it in both MAC and RRC.
`
`Therefore, for simplicity, it is proposed to keep the ongoing RA procedure and ignore the received uplink grant for the
`C-RNTI. That is,
`
`- If there is an ongoing RA procedure and there is a MAC PDU in [Message 3 buffer]; and
`
`- If the Contention Resolution Timer is not running
`
` When receiving a grant for its C-RNTI, the UE ignores the received UL grant for its C-RNTI.
`
`Proposal 3: It is proposed that if there is an ongoing RA procedure, there is a MAC PDU in [Message 3 buffer] and the
`Contention Resolution Timer is not running, when receiving a grant for its C-RNTI, the UE ignores the received UL
`grant for its C-RNTI.
`
`Conclusion
`2
`Proposal 1: It is proposed to modify the note like “if the UE receives both a grant for its RA-RNTI and a grant for its
`C-RNTI , and [Message 3] buffer is empty, the UE may choose to continue with either the grant for its RA-RNTI or the
`grant for its C-RNTI”.
`
`Proposal 2: It is proposed to that only when a new UL grant is indicated in a Random Access Response, the HARQ
`entity instructs the HARQ process to store a MAC PDU stored in [Message 3] buffer in HARQ buffer.
`
`Proposal 3: It is proposed that if there is an ongoing RA procedure, there is a MAC PDU in [Message 3 buffer] and the
`Contention Resolution Timer is not running, when receiving a grant for its C-RNTI, the UE ignores the received UL
`grant for its C-RNTI.
`
`The associated CR is provided in [2].
`
`Reference
`3
`[1] 3GPP TS 36.321 V8.2.0
`
`[2] R2-084388 Handling of Received UL Grant in RA procedure, LG Electronics Inc.
`
`3GPP
`
`SAMSUNG 1010-0003