If you are in this area (Wireless communication) for at least about a year, you would be familiar with the ping-pongs of the messages between the two parties in the communication(e.g, messages between a mobile phone and Network). You can even do some troubleshootings based on the ping-pong rule. For example, if you see 'RRC Connection Setup' being sent from Network log and you haven't seen 'RRC Connection Complete' in the network log, you would say "This may be UE issue because it doesn't seem to send proper reply'.
Then you would go to UE log and found 'RRC Connection Complete' message were sent from RRC layer. Then there going to be long argument between the two party, just memorizing the message sequence would not help much. To handle this kind of situation, you should know exactly what is supposed to happen when a Network or UE received a message and what is supposed to happened before they send any specific message.
One of the key things to do after receiving a message or before sending a message is to establish a specific channel (signal path or data path). These data path or signaling path is called 'Radio Bearer' and the process of setting up thse data path is called 'Radio Bearer Setup'.
This is one of the most critical part and tricky part to understand in any kind of communication mainly because you have to know the very details from physical layer to higher layer.
From your experience you would realize that understanding a little bit of everything would be relatively easy, obtaining in-depth knowledge in a specific/narrow area would be a little tough, but not impossible to achieve. However, mastering the whole area to a very detailed level and getting a clear picture both on high level and in detail would be very, very difficult.
This is why it is difficult to have complete understanding of Radio Bearer Setup. This page and several other pages are for trying to help you have better picture on this process.
The critical part of Radio Bearer Setup procedure is to establish the signaling/data path as shown below. You don't have to set up all the possible path at once,but you have to make it sure that the data path for a specific message/data has already established before they are getting transmitted. For example, you have to make it sure that CCCH - RACH - PRACH channel has been established before receiving RRC Connection Request and CCCH - FACH - SCCPCH before sending RRC Connection Setup.
Try marking the path for each signaling message and user data. Get your self familiar so that your finger draw the path on its own as soon as hear the name of the signaling message.
Following is the overall steps of Radio Bearer Establishment during the registration and call setup.
i) Establish BCCH - BCH - PCCPCH
ii) MIB/SIB Transmission/Reception
iii) Establish CCCH-RACH-PRACH (Configured in SIB5)
iv) Establish CCCH-FACH-S-SCCPCH (Configured in SIB5)
v) RRC Connection Request
vi) RRC Connection Setup
vii) Establish DCCH-DCH-DPDCH/DPCCH (Configured in RRC Connection Setup)
viii) Go through to the end of registration
ix) < Idle >
x) Make a call
xi) Establish CCCH-RACH-PRACH (Configured in SIB5)
xii) Establish CCCH-FACH-S-SCCPCH (Configured in SIB5)
xiii) RRC Connection Request
xiv) RRC Connection Setup
xv) Establish DCCH-DCH-DPDCH/DPCCH (Configured in RRC Connection Setup)
xvi) Go through signaling for call connection
xvii) Radio Bearer Setup
xviii) Establish DTCH-DCH-DPDCH/DPCCH (Configured in Radio Bearer Setup)
xix) Data Transmission/Reception
Follwing diagram would help you visualize which channel path is establish by which RRC messages.
When I started looking into Radio Bearer Setup (RRC Connection Setup, SIB5) and try to create some test cases, the most confusing thing was about this.
As you may noticed, the most confusing things about UMTS radio bearer setup is too big difference between how 3GPP Radio Bearer Specification document (34.108) represents and how RRC messages(e.g, RRC Connection Setup,Radio Bearer Setup, SIB5) represents. Among those confusing things, the most confusing thing to me was to represent the TFCS table in 3GPP document into ctfc information elements in RRC messages.
Let me give you one example case and show you how the TFCS table in 3GPP document is converted into ctfc information elements. I will illustrate this conversion process into multiple steps. (In real protocol stack implementation, they would not use these multiple steps, but I think the multi-step representation would be easier and clearer to most of readers).
< Step 1 >
First step is to constructs TFS table for each subflow from the 3GPP TFCS table as illustrated below. In this illustration, you would see an intermediate steps to rearrange the TFCS list into a tabular format. In reality, nobody would really draw this intermediate procedure, but I introduced the procedure just for clarity.
< Step 2 >
Once you get the table that shows all the possible TF for each subflow, next step is to figure out all the permutations of TFC(Transport Format Combination) out of the table as shown below.
< Step 3 >
Once you get the permutation table, the next step is to find the number of row (index of TFC) to which each item in TFCS table corresponds. These corresponding row number (the row number starts from 0) is the TFCI (Transport Format Combination Index) which will be specified in RRC message in next step.
< Step 4 >
Once you got the TFCI that matches each of the items inTFCS table. The last step is just to specify those index number in ctfc information elements as shown below.