What is the most tricky part in device troubleshooting ? My experience says "If a problem happens in the middle of doing something, it is relatively easy to find the root cause and troubleshoot it (probably I might have over-simplified the situation -:), but if something happened before anything started, it would be a nightmare." For example, you set the all the parameters at the network emulator for a UE you want to test and then turned on the UE. In a several second UE start booting and then in a couple of second you see a couple of antenna bars somewhere at the top of UE screen.. and then in several seconds you see 'SOS' or 'Service Not Available' in stead of your network operator name displayed on your screen and normal Antenna bars. This is what I mean by "problem in the middle of doing something". In this case, if you collect UE log and equipment log, at least you can easily pin point out the location the problem happens and start from there for further details. But what if you are in this situation ? you set the all the parameters at the network emulator side and turn on the UE.. UE start booting up .. showing the message saying "Searching Network ...." and got stuck there.. with no Antenna bars .. not even 'SOS' .. just saying "No service". And I collected UE side log and Network Emulator side log, but no signalling message. This is where our headache starts.
As examples,
i) What if you don't see 'RRC Connection Request' when your turned on the WCDMA UE ?
ii) What if you don't see 'Channel Request' when your turned on the GSM UE ?
iii) What if you don't see 'RACH Preamble' when your turned on the LTE UE ?
First thing you have to do is to understand the every details of this procedure not only in the higher signaling layer, but also all the way down to the physical layers related to these first step. And also you have to use proper equipment which can show these detailed process. If you have an equipment that does not provide the logging or it provides log but only higher layer singnaling log, it will be extremly difficult to troubleshoot. Given that you have the proper tools, the next thing you have to be ready is to understand the detailed knowledge of these process. Without the knowledge, however good tools I have it doesn't mean anything to me. So ? I want to teach myself here about the first step of LTE signaling which is RACH process. (Somebody would say there are many of other steps even before the RACH, like frequency Sync, Time Sync, MIB/SIB decoding.. but it put these aside for now.. since it is more like baseband processing).
When RACH Process occurs ?
It would be helpful to understand if you think about when 'RRC Connection' happens (or when PRACH process happens if you are interested in lower layer stuffs) in WCDMA. It would also be helpful if you think about when 'Channel Request' happens in GSM UE.
My impression of LTE RACH process is like the combination of PRACH process (WCDMA) and Channel Request (GSM). It may not be 100% correct analogy.. but anyway I got this kind of impression. In LTE, RACH process happens (The following list came from the LTE training manual by Award Solution. Of course, this description is also based on 3GPP specification)
i) During initial access to register or RRC Connection Request
ii) When a radio link failure occurs during the initial access
iii) During the Handover to allocate the scheduling grant from the target eNB
iv) UL synchronisation is lost
v) When there are no dedicated resources (no PUCCH resources have been assinged to UE).
Two types of RACH process : Contention-based and Contention-free
When a UE transmit a PRACH Preamble, it transmits with a specific pattern and this specific pattern is called a "Signature". In each LTE cell, total 64 preamble signatures are available and UE select randomly one of these signatures.
UE select "Randomly" one of these signatures ?
Does this mean that there is some possibility that multiple UEs send PRACH with identical signatures ?
Yes.
There is such a possibility. It means the same PRACH preamble from multipe UE reaches the NW at the same time.. this kind of PRACH collision is called "Contention" and the RACH process that allows this type of "Contention" is called "Contention based" RACH Process. In this kind of contention based RACH process, Network would go through additional process at later step to resolve these contention and this process is called "Contention Resolution" step.
But there is some cases that these kind of contention is not acceptable due to some reason (e.g, timing restriction) and these contention can be prevented. Usually in this case, the Network informs each of the UE of exactly when and which preamble signature it has to use. Of course, in this case Network will allocate these preamble signature so that it would not collide. This kind of RACH process is called "Contention Free" RACH procedure. To initiate the "Contention Free" RACH process, UE should be in Connected Mode before the RACH process as in Handover case.
Typical 'Contention Based' RACH Procedure is as follows :
i) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)
ii) UE <-- NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message)
iii) UE --> NW : L2/L3 message iv) Message for early contention resolution
Now let's assume that a contention happened at step i). For example, two UEs sent PRACH. In this case, both of the UE will recieve the same T_C-RNTI and resource allocation at step ii). And as a result, both UE would send L2/L3 message through the same resource allocation(meaning with the same time/frequency location) to NW at step iii). What would happen when both UE transmit the exact same information on the exact same time/frequency location ? One possibility is that these two signal act as interference to each other and NW decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from NW and they all think that RACH process has failed and go back to step i). The other possibility would be that NW could successfully decode the message from only one UE and failed to decode it from the other UE. In this case, the UE with the successful L2/L3 decoding on NW side will get the HARQ ACK from Network. This HARQ ACK process for step iii) message is called "contention resolution" process.
Typical 'Contention Free' RACH Procedure is as follows :
i) UE <--NW : RACH Preamble Assignment
ii) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)
iii) UE <--NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)
Exactly when a UE transmit RACH ?
To answer to this question, you need to refer to 3GPP specification TS36.211 - Table 5.7.1-2.
Did you open the specification now ? It shows exactly when a UE is supposed to send RACH depending on a parameter called "PRACH Configuration Index".
For example, if the UE is using "PRACH Configuration Idex 0", it should transmit the RACH only in EVEN number SFN(System Frame Number). Is this good enough answer ? Does this mean that this UE can transmit the RACH in any time within the specified the SFN ? The answer to this question is in "Sub Frame Number" colulmn of the table. It says "1" for "PRACH Configuration Idex 0". It means the UE is allowed to transmit RACH only at sub frame number 1 of every even SFN.
Checking your understanding of the table, I will give you one question. With which "PRACH Configuration Idex", it would be the easiest for the Network to detect the RACH from UE ? and Why ?
The answer would be 14, because UE can send the RACH in any SFN and any slots within the frame.
How does Network knows exactly when UE will transmit the RACH ?
It is simple. Network knows when UE will send the RACH even before UE sends it because Network tells UE when the UE is supposed to transmit the RACH. (If UE fails to decode properly the network information about the RACH, Network will fail to detect it even though UE sends RACH).
Following section will describe network informaton on RACH.
Which RRC Message contains RACH Configuration ?
It is in SIB2 and you can find the details in 3GPP 36.331. (Click the image to enlarge it so that you read it clearly) 
Exactly when Network transmit RACH Response
We all knows that Network should transmit RACH Response after it recieved RACH Preamble from UE, but do we know exactly when, in exactly which subframe, the network should transmit the RACH Response ? The following is what 3GPP 36.321 (section 5.1.4) describes.
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes.
It means the earliest time when the network can transmit the RACH response is 3 subframe later from the end of RACH Preamble. Then what is the latest time when the network can transmit it ? It is determined by ra-ResponseWindowSize. This window size can be the number between 0 and 10 in the unit of subframes. This means that the maximum time difference between the end of RACH preamble and RACH Response is only 12 subframes (12 ms) which is pretty tight timing requirement.
RACH Procedure during Initial Registration - RACH Procedure Summary
Follwing is an example of RACH procedure which happens during the initiail registration. If you will be an engineer who is working on protocol stack development or test case development, you should be very familiar with all the details of this process.
Again, we have to know every details of every step without missing anything to be a developer, but of course it is not easy to understand everything at a single shot. So, let's start with something the most important part, which I think is the details of RACH response. Following diagram shows one example of RACH Response with 5 Mhz bandwidth. We don't have to memorize the detailed value itself but should be familiar with the data format and understand which part of this bit string means what. 
If you decode UL Grant part, you will get the following result. You will notice that the information it carries would be very similar to DCI format 0 which carries Resource Allocation for uplink data. This information in UL Grant in RACH Response message is the resource allocation for msg3 (e.g, RRC Connection Request).
Let me describe this procedure in verbal form again.
i) UE initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH).(The location of RACH in the frequency/time resource grid the RACH is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity)
ii) Network sends a Random Access Response Message(RARM) at a time and location on the Physical Downlink Shared Channel (PDSCH) (The time and location of RARM on PDSCH can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (T_C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment)
iii) The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network
Only the step i) uses physical-layer processing specifically designed for random access. The remaining steps utilizes the same physical layer processing as used for normal uplink and downlink data transmission
3GPP Standard for RACH Process
3GTS 36.300 (10.1.5) : Overall description of RACH Process. Read this first.
3GTS 36.211 (5.7) : RRC Messages and IE (Information Elements) which are involved in RACH process.
3GTS 36.213 (6) : MAC Layer Procedure related to RACH Process.
