UTRAN RNC Types

November 16, 2007 by arvindpadmanabhan The Radio Network Controller (RNC) is a key element within UTRAN for it controls all the radio resources of UTRAN. However, each RNC controls only resources under its control. There are multiple RNCs in UTRAN and as such, control of radio resources is done with a distributed architecture. In this article, we will focus on the different types of RNCs that are defined in the standards. As a preliminary let us start with the UTRAN architecture and the interfaces relating to an RNC (Figure 1).

Iub Interface: connects to a Node-B. An RNC controls one or more Node-Bs. Iur Interface: connects to other RNCs. This interface is not necessarily a point-to-point link. Iu Interface: interfaces to the Core Network (CN). This is usually broken down into IuCS and Iu-PS for the respective domains. There is also the Iu-BC component that connects to the Broadcast Domain. Iur-g Interface: connects to GERAN BSS which is possible from Release 5 onwards when GERAN can operate in Iu mode. Iupc Interface: connects to Stand-Alone SMLC (Serving Mobile Location Center) to enable location-based services. Figure 1: UTRAN Architecture

The specifications frequently mention the following logical separation: CRNC: Controlling RNC SRNC: Serving RNC DRNC: Drift RNC

The CRNC is responsible for the controlling the resources of a Node-B. It is responsible for load and congestion control. If new radio links (RLs) are to be established CRNC does the job.

On the other hand, SRNC and DRNC are concepts that are tied to a UE-UTRAN connection on the Uu interface. In other words, an SRNC serves a particular UE and manages the connections towards that UE. Likewise, DRNC fulfils a similar role to the SRNC except that it is involved only in the case of a soft handover. Thus the UE initially starts a connection with an RNC that becomes its SRNC. If the UE moves towards a cell edge, SRNC may decide to put the UE in soft handover state. If the new RLs added to UEs Active Set are under the control of a different RNC, that RNC becomes the DRNC. The important thing here is that CRNC is logically tied to Node-Bs, not connections. On the contrary, SRNC and DRNC are tied to connections to the UE. This implies that CRNC manages common and shared resources while SRNC and DRNC manage dedicated resources. This does not imply that SRNC will be involved only when UE RRC is in CELL_DCH state. Even in CELL_FACH state, the UE being allocated Signalling Radio Bearers (SRBs), dedicated logical channels (DCCH and even DTCH) would have been established between UE and SRNC. DRNC cannot be involved in this state because the principle of soft handover applies only to dedicated physical channels. Once this is understood it becomes easy to make sense of many UTRAN procedures and protocol termination points within UTRAN. As an example, let us look at the case of FACH (Figure 2).

Figure 2: FACH Protocol Architecture

Figure 2(a) is a case in which the CRNC and SRNC are physically on the same RNC. So all that FACH FP (Framing Protocol) does is to transfer Mac Pdus from the RNC to Node-B. In the Node-B, an interworking function translates the FACH frames to PHY frames on the Uu. Figure 2(b) is a case in which CRNC and SRNC are separate and connected by Iur. A FACH FP on Iur carries the Mac-d Pdus. In the CRNC, this is interworked with Mac-c/sh/m. Subsequently, FACH FP on the Iub carries it to the Node-B. In general, Mac-c/sh/m will reside on the CRNC since they relate to the common resources of the cell. Mac-d (and Mac-es in the case of E-DCH) resides on the SRNC.

To understand the difference between SRNC and DRNC, we take the example of a SRNS Relocation procedure (Figure 3). Figure 3: SRNC Relocation

In Figure 3(a), the UE is in SHO in which 2 RLs are under the SRNC and one under the DRNC. As the UE continues to move away from its original cells, all RLs in its Active Set are now under the DRNC (Figure 3(b)). Since the SRNC no longer manages any of its own radio resources for the UE, at some point it decides to transfer the complete UE context to the DRNC. At this point, the original DRNC becomes the SRNC. The new SRNC establishes connection on the Iu interface to the CN. It is always the SRNC that manages the RANAP signalling towards the CN. The RRC layer in UTRAN resides in the SRNC which takes care of mapping Radio Access Bearer parameters to air interface transport channel parameters. The SRNS Relocation procedure is invoked within the SRNC RRC. Ultimately, it is the SRNC that has an RRC connection with the UE. While the UE is in Inter-RNC SHO, Iur is invoked to transfer data between the SRNC and DRNC. The DRNC routes data transparently between the Iub and Iur interfaces. The DRNC may optionally (if configured by the SRNC) combine or split data when relaying data between Iub and Iur interfaces. This has the advantage of reducing load on the Iur. It also distributes the processing load between the SRNC and the DRNC. In fact, these may be considerations on which the SRNC decides if combining/splitting is to be performed at the DRNC. Naturally, combining is done on the UL and splitting is done on the DL. Two types of data combining is possible: maximum ratio combining or selection combining based on quality information associated with each TBS (Transport Block Set). One important exception to this rule is E-DCH data handling at the DRNC. DRNC does not do combining. Combining is done in the Node-Bs under the DRNC. This makes sense for E-DCH for which PHY layer terminates at Node-B. The E-DCH FP carries only Mac-es PDUs across the Iub. This means that the SRNC can receive duplicates of Mac-es PDUs. Thus one of the functions of the Mac-es layer in the SRNC is to perform reordering for in-sequence delivery. This is not done at the DRNC which transparently relays the E-DCH FP from Iub to Iur (Figure 4). This is not the case with DCH for which PHY is distributed between Node-B and RNC. Figure 4: E-DCH Protocol Architecture

In conclusion, the terms CRNC, SRNC and DRNC are only logical definitions based on functionality. Physically, an RNC may be a CRNC+SRNC or CRNC+DRNC. CRNC manages common transport resources, code allocation, load and congestion control. SRNC manages the

connection to the UE and maintains the UE context within UTRAN. (For this purpose, S-RNTI allocated to the UE identifies the UE uniquely within the SRNC. This identity is managed by the SRNC and will be reallocated during SRNC Relocation.) Thus, outer loop power control, handover and RANAP signalling are managed from the SRNC. DRNC manages resources under its control but relies on SRNC for most decisions and commands. Figure 2(b) is an example of what you are looking for. In this case, CRNC is responsible for controlling all common resources on the cell such as FACH. SRNC contains the dedicated context. In this example, SRNC carries the dedicated logical channels DTCH and DCCH. CRNC is unaware of these logical channels since they are transparently passed via FACH-FP. Finally, it is Node-B that maps these logical channels to the FACH. In one network implementation, we could have one CRNC for a one or more Node-Bs and fewer or less powerful SRNCs. Network designed this way would be more robust (no single point of failure) than a network with just SRNC entities. It also makes sense for load sharing. Having said that, HSPA R7 and LTE networks are evolving in such a way that RNC functionality is going to become part of Node-B.