Iub-over-IP. As shown in Figure 2 below, in the lub-over-IP approach, the FAP takes on the role of the NodeB and the FGW sits between the FAP and RNC. This configuration specifically suits Small Office/Home Office (SOHO) or single home environments where only a few subscribers would access service through the FAP. Depending on the number of FAPs connected to the FGW, in practice the RNC and FGW could be collapsed into one device " but for the sake of clarity we will consider them as two separate devices.

Figure 2: Protocol stacks for the Iub-over-IP approach

The FAP communicates with the FGW using a 16-bit cell ID which uniquely identifies a femtocell. The FGW multiplexes the traffic coming from different FAPs and forwards it to the RNC using Framing Protocol (FP); the FGW does not modify any of the FP packets, especially the FAP identifier. At startup, the FAP establishes a security association with the FGW to avoid compromising subscriber information over the public IP network; TR-069 or some other similar mechanism could be used by the FAP to discover/obtain IP address from an Auto Configuration Server (ACS).

The RNC would handle all the resource management (bearer and control) functionality; the RNC and FGW together would take care of delay jitter for the bearer traffic and control signaling (specifically forced/hard handover mobility management) caused by the underlying public IP network. In order to communicate with the pre-R4 CN " which does not support IP transport " the RNC will have to do IP-to-ATM and vice-versa transport conversion.

Mobility Management (MM) and Call Control (CC) is handled by the CN. Handovers in this approach are typically Intra-RNC/Inter-RNC in nature. If the FAP and macrocell are managed by the same RNC, the handover is of the Intra-RNC type " otherwise it is of the Inter-RNC type.

During hand-in (i.e., handover from macrocell to femtocell), the CN together with the User Equipment (UE) identifies the appropriate FAP (using an approved neighbor list, managed at the RNC) and sets up an Iub signaling and bearer transport tunnel over the broadband IP network connecting the FAP and FGW. The radio resource between the FAP and UE is managed by the Radio Resource Control (RRC) protocol at the RNC.

Once the Iub tunnel is set up, the CN transfers the call over to the femtocell environment using MM and CC protocols at the MSC and UE. During hand-out (i.e., handover from femtocell to macrocell), the RRC protocol and terminating the Iub tunnel. For femtocell-to-femtocell handover, the RNC mostly acts as an anchor to set up the Iub tunnel over the new FAP and set up the radio link at the new FAP using the RRC protocol before transferring the call to the new FAP and terminating the radio link at the old FAP.

lu-over-IP. In this approach, as illustrated in Figure 3, below, the FAP takes on the role of the RNC and the FGW sits between the RNC and CN (MSC/SGSN). This configuration specifically suits Small and Medium Business (SMB) or Multiple Dwelling Unit (MDU) environments where numerous customers can access service through the FAP, mobility management/resource management within the femtocell is frequent, and Quality-of-Service demand is premium.

Figure 3: Protocol stacks for the Iu-over-IP approach

The FAP communicates with the FGW using a 12-bit RNC-ID. The FGW tunnels Radio Access Network Application Part (RANAP) signaling from the FAP to the CN; it may also convert the IP transport from/to ATM transport using SIGTRAN (Signal Transport) functionality if the CN does not support IP transport functionality.

At startup, the FAP establishes a security association with the FGW to avoid compromising subscriber information over the public IP network; TR-069 or some other similar mechanism could be used by the FAP to discover/obtain IP address from an ACS for the FGW. In addition, the FAP would use the ACS to obtain resource management parameter and algorithms to be exercised in the femtocell environment.

The FAP would handle most resource management (bearer and control) functionality within the femtocell environment and would defer it to the CN during femtocell-to-macrocell handover. QoS depends on the connectivity offered by the public IP network; obviously IP delays and data/packet loss will impact service performance. The FAP transports voice traffic to the FGW using RTP over UDP and the FGW converts it to the appropriate bearer (ATM, IP or TDM) based on the CN transport.

Handovers in this approach are typically Inter-RNC/Inter-CN (MSC/SGSN) in nature. If the FAP and macrocell are managed by the same MSC/SGSN, it is of the Inter-RNC type, otherwise it becomes the Inter-CN (MSC/SGSN) type. During hand-in, the CN together with the UE identifies the appropriate FAP (using an approved neighbor list, managed at the MSC) and sets up an Iu signaling and bearer transport tunnel over the broadband IP network connecting the FAP and FGW.

The radio resource between the FAP and UE is managed by interworking of the RRC and RANAP protocols. The interworking of these protocols the CN transfers the call over to the femtocell environment using MM and CC protocols at the MSC and UE.

During hand-out, the RANAP protocol at the MSC and RRC protocol at the new RNC sets up the radio link in the macrocell environment before transferring the call over to the macrocell and terminating the Iu tunnel. For femtocell-to-femtocell handover, the MSC mostly acts as an anchor to set up the Iu tunnel over the new FAP and set up the radio link at the new FAP using RRC/RANAP protocol interworking before transferring the call to the new FAP and terminating the radio link at the old FAP.