`R2-060905
`
` R2-060905
`
`3GPP RAN1/RAN2 joint meeting on LTE
`Athens, Greece, 27th–31th March, 2006
`
`
`Agenda Item:
`Source:
`
`Title:
`
`Document for:
`
`3.2
`CATT, RITT
`Access procedure for TDD
`Discussion and decision
`
`
`
`Introduction
`
` 1
`
`Currently, the access process and the UE id have been presented in the RAN2 meeting. In this document the
`access procedure is analyzed under different application scenes and the information carried on RACH is
`discussed.
`
` 2
`
` Discussion
`2.1 Access Procedure
`The access procedure performed in the uplink is not synchronised in most scenes. It is usually a contention-based
`random procedure. Firstly, UE listens to system broadcast, reads the system information, from which the UE can
`get necessary information for random access.
`
`To reduce the collision probability and detect possible collisions fast, a number of sequences, namely signatures
`are needed. By correlating with different signatures, the eNB can detect one particular UE or collisions. The UE is
`assumed to identify itself in a random access procedure autonomously by choosing a signature randomly from a
`set of signatures. The randomly selected signature by UE’s physical layer is referred to as Signature ID. In one
`cell of 1.25 MHz, the number of signatures may be more than ten (e.g. 4bits). During the random access procedure,
`UE selects a signature (preamble) randomly, estimates the transmission timing advance due to the
`non-synchronization of uplink and transmits it. Then the UE listens to the preamble response.
`
`If UE doesn’t receive the preamble response within the pre-defined period, it will select a new signature randomly
`and transmit it again after a random time until the UE has received a expected response or the maximal number of
`retransmit has been reached.
`
`When eNodeB received the preamble signal, its physical layer deals with the signal by correlation, gets the uplink
`timing advance and uplink transmit power precisely, reads the signature id of UE, and report to MAC. The MAC
`of eNodeB allocates a C-RNTI, selects a response channel of preamble and transfers the C-RNTI to physical layer.
`The physical layer transmits the C-RNTI, timing and power information to the UE on response channel of
`preamble corresponding to the Signature ID. When two or more UEs transmit preamble signal at the same time
`with different signature ID, eNodeB should have the capability to distinguish different UE’s preamble, and gives
`different UE different C-RNTI and other information on different preamble response channels.
`
`When two or more UEs transmit preamble signal at the same time with same signature ID, the collision will
`happen. In this case, eNodeB may detect collision, and doesn't give the response of preamble. If eNodeB doesn’t
`detect the collision(namely only one signature is obtained ), it thinks only one UE sent the access request. Then
`eNodeB provides one C-RNTI and other information on the preamble response channel. The undetected collision
`
`
`
`1
`
`Ericsson v. IV II LLC
`Ex. 1007 / Page 1 of 4
`
`

`

`
`R2-060905
`
`will happen since multiple UEs will get and utilise the same response information. Of course, the probability of
`such collision is usually very low and it can be found during the following operation, as described below.
`
`After UE received the C-RNTI together with timing and power information, it can transmit the L2 control
`message on the physical random access channel (e.g. PRACH) corresponding to preamble response channel. The
`relationship of PRACH with preamble response channel is broadcasted in the system information. To reduce the
`delay of access request, the data on RACH will be limited. The data should be transmitted within a sub-frame
`(FDD) or timeslot(TDD). The RACH may include Random ID, C-RNTI, access cause etc. The Random ID is
`selected randomly by UE. Due to the RACH includes a Random ID that can be designed long enough (e.g. 8bits),
`the residual possible collisions can be resolved in this step.
`
`UE listens to a downlink share control channel (DL-SCCH) corresponding to preamble response channel or
`PRACH. The relationship of the DL-SCCH with preamble response channel or PRACH is broadcasted in the
`system information. Scheduling information for the access UE (signed by the C-RNTI) is carried on the
`DL-SCCH.
`
`The system can predefine some types of radio resource configurations for access causes. When eNodeB received
`the UE’s RACH data, it will check the random ID to see if two or more UEs using same C-RNTI. If yes, the
`eNodeB will not schedule this C-RNTI. If these UEs do not find the scheduling information on the related
`DL-SCCH after a period of time, they will consider that the access procedure is failure and reinitiate the access
`requests according to their requirements respectively. If eNodeB receives RACH successfully, it will select a type
`of configuration of radio resource on UL-SCH according to the access cause, and notify the UE on the DL-SCCH.
`The Random ID can be transferred to UE on DL-SCCH or a RACH response channel or a L3 message. Which
`channel transfers the Random ID to UE is FFS. Using the Random ID, the UE can know the schedule information
`for the C-RNTI is for which UE within collision UEs in first access step.
`
`Then, the UE can communicate with NW on UL-SCH/DL-SCH normally. It will transfer IMSI or TMSI in the L3
`message on UL-SCH to setup RRC connection and other message. The random access procedure can be seen as in
`figure 1.
`
`Figure 1: The general random access procedure
`2.2 Access scenarios and UE ID
`The initial access is used in the fellow scenes:
`
`1) When UE in power on, the UE would access NW to take registration;
`2) The UE moves to a new trace area, it will access NW to update location;
`3) The UE requires the NW to provide service, it will access NW;
`
`
`
`2
`
`
`
`Ex. 1007 / Page 2 of 4
`
`

`

`
`R2-060905
`
`4) After UE is paged by NW, it will access NW;
`5) The UE has connected with eNodeB, but uplink is non-synchronized and UE having data to transmit;
`6) During handover, but the uplink is non-synchronized, UE will random access in new cell or in old cell.
`7) The UE has connected with eNodeB, in the DRX state, the uplink is synchronized, but it needs radio
`resource immediately;
`
`In scene 1), the NW hasn’t any information about the UE. The UE has static ID of IMSI or IMEI only. The access
`procedure is same as figure1 in the step 1 to step 5. But in the step 6, the L3 message will carry the IMSI to
`eNodeB. Then the NW will setup RRC connection and do authentication and encrypt, give the UE a TMSI, and
`encrypt key. After the UE has registered on the NW, the RRC connection will be released together with C-RNTI.
`The UE will enter the LTE-IDLE state.
`
`In scene 2), 3), 4), the UE has the temporary identity (TMSI) and the last encrypt key. The NW has the UE’s
`capability information, encrypt information and so on. The access procedure is same as figure1 in the step 1 to
`step 5. But in the step 6, the L3 message will carry the TMSI to eNodeB. The eNodeB transfers the information to
`aGW. The aGW gets information above, it can give the UE new encrypt key. In addition, in scene 4), the
`necessary information should be carried on the PCH when the NW paging UE to speed up access procedure.
`
`In scene 5), 6), the NW has all information about the UE, and UE can initiate access on RACH with its C-RNTI
`after preamble and ignores allocated new C-RNTI. Then UE transmits user data on the UL-SCH/DL-SCH
`according to the scheduling information on the DL-SCCH corresponding to PRACH. The eNodeB could know
`that the UE has a RRC connection already via the C-RNTI, it will ignore the random ID. After a period of time,
`eNodeB doesn’t receive the PRACH of new allocated C-RNTI, it will see that access is failure, and frees the
`C-RNTI. The random access procedure can be seen as in figure 2.
`
`Error! Objects cannot be created from editing field codes.
`Figure 2: The random access procedure in case 5) and 6)
`
`In scene 7), the NW has all information about the UE, and UE is synchronized in uplink. The UE can initiate
`access on RACH with C-RNTI directly. The eNodeB could know that the UE has a RRC connection already via
`the C-RNTI, it will ignore the random ID. Then UE transmits user data on the UL-SCH/DL-SCH according to the
`scheduling information on the DL-SCCH corresponding to PRACH. The random access procedure can be seen as
`in figure 3.
`
`Sum up the above depicted, the data on the RACH should be include following types:
`
`Figure 3: The random access procedure in case 7)
`
`Random ID(e.g.8bits) C-RNTI (xbits) Access Cause(xbits) Resource Indicator(xbits)
`The resource indicator is used for UE to request radio resource or report the buffer information.
`
`
`
`
`
`
`
`3
`
`Ex. 1007 / Page 3 of 4
`
`

`

`
`R2-060905
`
`3 Conclusion
`In this document we have discussed the random access procedure and the use of RACH in every scene. The access
`procedure is put forward that firstly UE transmits a preamble to synchronize with eNodeB, reduce the probability
`of collision, and fast detection in eNodeB; and then transmits RACH with Random ID, C-RNTI, access cause and
`Resource Indicator. Since active UE is synchronized in uplink, it can initiate access procedure using C-RNTI
`directly.
`4 References
`[1]
`TR25.813 “Radio interface protocol aspects”, 2005.
`[2]
`
`TR25.814 “Physical Layer Aspects for Evolved UTRA”, 2005.
`
`[3] R1-060520, EUTRA TDD Random Access Procedure, CATT, RITT, TD-Tech
`
`
`
`
`
`4
`
`Ex. 1007 / Page 4 of 4
`
`