From the 2008 May 21 edition of European Engineering Live
Femtocell Network Architecture and Signaling Protocol Options
Authors: Srinivasa Rao, Architect and Ravi Raj Bhat, Director of Engineering
Issue Date: March 2008
Introduction
Over the course of the last twelve months, the wireless market has experienced a tremendous amount of excitement around femtocells, driven primarily by frustration over bad wireless call coverage within home and/or office environments. As a technology, a femtocell is a fairly simple concept of extending the 3G/2G wireless last mile into the indoor arena, through which current wireless infrastructure - base-stations and/or Node Bs - finds it difficult to penetrate. This coverage extension is achieved by putting a new device called a Femto Access Point (FAP) within consumers' proximity and leveraging their public internet connectivity (cable, DSL, or fiber) for backhaul. FAPs will be indoor, low-cost, and aesthetically-designed brethrens of the big, expensive, and ugly outdoor base-stations and/or Node Bs - but the devil lies in the details of how FAPs are engineered and managed.
Figure 1: High-level femtocell network architecture
Early pioneers like Ubiquisys, RadioFrame Networks, and ip.access have led the charge in femtocell technology, spurring interest from bigger Telecom Equipment Manufacturers (TEMs) to jockey for position in this nascent market. As expected, all of these players have approached femtocells from their respective positions of strength, resulting in fragmented and disparate approaches to the challenge. Continuing on this path would result in over-hyped technology solutions that would make it difficult to interoperate, thereby locking in consumers and service providers with specific vendors and in turn keeping the cost of FAPs at a level where the industry would only see a few takers.
To avoid such a fate, the industry is rallying together under the Femto Forum (www.femtoforum.org) banner to work with various standardization bodies and industry forums such as the International Telecommunication Union (ITU), European Telecommunication Standards Institute (ETSI), Internet Engineering Task Force (IETF), 3rd Generation Partnership Project (3GPP), and Digital Subscriber Line (DSL) Forum to standardize the architecture for femtocell networks and the protocols used by the network devices to communicate with each other. Table 1 lists the focus areas and status of the various organizations influencing femtocell standardization activities.
At a broad level, various approaches being proposed at recent Femto Forum meetings can be classified into three categories: Universal Mobile Telecommunications System (UMTS) based architecture, Unlicensed Mobile Access (UMA) or Generic Access Network (GAN) based architecture, and IP Multimedia Subsystem (IMS) based architecture. This whitepaper delves deeper into each of these approaches from the perspective of signaling protocols that need to run on each device and the work that is cut out for the Femto Forum and the various standardization bodies.
| Standards Body | Focus | Status |
|---|---|---|
| 3GPP | Standardization of the femtocell architecture for UMTS (W-CDMA) and 3G Long-Term Evolution (LTE). | Recently concluded Study Item within RAN3 (TR25.820) recommending Iu as reference deployment option for the HomeNodeB (HNB). Home Access Point is a Work Item under the 3G LTE standards activities. |
| 3GPP2 | Standardization of the femtocell architecture for CDMA2000 (EV-DO) and Ultra-Mobile Broadband (UMB). | 3GPP2 Femto Cell Workshop formulated within TGS-S Service and System Aspects (May 2007). Workshop delivered, 3GPP2 System Enhancements for Femto and Pico Cells System Requirements Document (S.P0126-0) in December 2007. |
| DSL Forum | Extension of the TR-069 management protocol to support femtocells. | Closely coordinating with the Femto Forum on the extension of TR-069 for managing femtocells. |
| Femto Forum | Inclusive organization dedicated to the promotion of femtocells. | Providing technical guidance to the various standards bodies regarding femtocell architecture, security, management, and radio aspects. Interfacing with regulators to educate concerning femtocell technology. Providing marketing deliverables to support consumer and operator education. |
Table 1 : Organizations influencing femtocell standardization activity
UMTS Based Architecture
The UMTS based architecture focuses on leveraging the existing core network (CN) behind the Radio Network Controller (RNC) and/or Mobile Service Controller (MSC), Serving GPRS Support Node (SGSN) and tunneling the traffic between CN and Node B over the subscriber's broadband IP network. At a high level, this approach is also referred to as Iu-over-IP. Here again, recommendations diverge on whether we need to tunnel traffic over IP between the RNC and Node-B (i.e., Iub-over-IP) or between the MSC/SGSN and RNC (i.e., Iu-over-IP). In either case, a new device loosely called an Iu Concentrator (also known as Femto Gateway and hereafter referred to as FGW) is introduced to scale the limited capacity CN to connect to millions of femtocells expected to spring up. One of the significant drawbacks of the Iub-over-IP approach, however, is the fact that the Iub interface is left largely undefined by 3GPP and therefore proprietary vendor implementations of the Iub interface have evolved over the years. To keep FAP price-points at palpable levels, multi-vendor interoperable solutions for femtocells using Iub-over-IP would require significant Iub interface standardization effort.
Iub-over-IP
In this 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.
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.
Figure 2: Protocol stacks for the Iub-over-IP approach
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 at the RNC sets up the radio link in the macrocell environment before transferring the call over to the macrocell 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.
Iu-over-IP
In this approach, 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.
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 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.
Figure 3 : Protocol stacks for the Iu-over-IP approach
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 is managed by the FAP, with RRC terminating at the UE and RANAP terminating at the MSC. Once the Iu 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, 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.
UMA/GAN Based Architecture
In early 2000, a few technology upstarts approached convergence between the fixed and mobile worlds by bridging two disparate wireless technologies - short-range, high-bandwidth, unlicensed 802.11 and long-range, relatively lower-bandwidth, licensed 2G/3G wireless - using an underlying public IP network and dual-mode-handsets. This was marketed as Unlicensed Mobile Access (UMA) technology and later standardized within 3GPP as Generic Access Network (GAN) technology. UMA/GAN identifies a new device called GAN controller (GANC), or commonly known as UMA Network Controller (UNC), to integrate mobile traffic over the public IP network. Wireless interfaces are bridged using Dual-Mode Handsets (DMH). GAN defines a new Up interface between the GANC and mobile devices and a standard A/Gb and Iu interface toward the CN.
In principle, UMA/GAN is similar to the femtocell approach except that femtocell attempts to extend the licensed 2G/3G wireless spectrum to the customer premises instead of bridging licensed and unlicensed wireless technologies. So, the underlying UMA/GAN architecture can likewise be extended to support the femtocell approach by overloading the GANC with Iu FGW functionality. This architecture is best suited for those service providers who have an existing GAN infrastructure but want to offer innovative high-value, high-bandwidth services using High Speed Packet Access (HSPA) capability requiring higher bandwidth than what current 802.11 deployments can offer.
Figure 4: Protocol stacks for the UMA/GAN based architecture
The FAP presents the Up interface toward the FGW, which also acts as the GANC. The FGW communicates with the CN using the Iu interface. 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 the ACS for the FGW. The FGW treats the femtocell as an IP based device and these nodes communicate using IP address and port numbers.
The FAP converts voice packets to RTP packets and forwards these to the FGW, which may have to convert the RTP packets back to voice based on the CN transport network. Multiple transcoding due to different transport networks may lead to loss of voice quality, which needs to be overcome by implementing strict QoS at the Up interface.
Handovers in this approach are typically Intra-RNC/Inter-RNC in nature. If the FAP and macrocell are managed by the same RNC (GANC) it is of the Intra-RNC type, otherwise it becomes the Inter-RNC type. During hand-in, the CN together with the UE identifies the appropriate FAP (using an approved neighbor list, managed at the GANC) and sets up an Iu signaling and bearer transport tunnel toward the GANC. The FAP sets up the Up signaling towards the GANC. The radio resource between the FAP and the UE is managed by interworking of the RRC, Generic Access - RRC (GA-RRC), and RANAP protocols. The interworking of RRC and GA-RRC protocols is managed by the FAP, whereas the interworking of GA-RRC and RANAP is managed by the GANC. RRC terminates at the UE, GA-RRC terminates at the FAP, and GANC and RANAP terminate at the MSC. Once the Iu 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, the RANAP protocol at the MSC and RRC protocol at the new RNC set 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 GANC 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/GA-RRC protocol interworking before transferring the call to the new FAP and terminating the radio link at the old FAP.
IMS Based Architecture
With improving QoS delivery on IP transport, UMTS 3GPP has been migrating both signaling and bearer transport from traditional Signaling System 7 (SS7) to IP. Improved quality of voice calls over pure Voice over IP (VoIP) applications such as Skype has definitely made a case for this migration. Session Initiation Protocol (SIP) and Real-time Transport Protocol (RTP) have been the key pillars of this migration for signaling and bearer transport, respectively. The IMS based architecture for femtocell looks to leverage the IMS core and completely offload the mobile core network, which enables building future-proof femtocell networks where innovative application-level services can be deployed easily and delivered all the way to consumers. This architecture works best for vertically-integrated network operators such as Verizon, Orange, etc., that offer bundled wireless, wireline, and broadband services.
In this approach, the FAP interworks the UMTS signaling plane with the SIP signaling protocol over the public IP network. On the IMS core side, the FAP may directly interface with softswitches providing Call Session Control Function (CSCF) functionality using SIP and interface directly with the Home Subscriber Server (HSS) using the Diameter protocol for Authentication, Authorization, and Accounting (AAA) functionality. Alternatively, the FAP may choose to interface with these devices through an aggregating packet data gateway. On the bearer plane, the FAP forwards voice traffic toward the IMS core as RTP packets. QoS depends on the connectivity offered by the public IP network, and as noted above IP delays and data/packet loss will impact service performance. TR-069 could again be used for zero-touch initial system configuration and service provisioning of the FAP.
Figure 5 : IMS based architecture
Handovers in this approach are always Inter-CN (MSC/SGSN) in nature. 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, which is a key issue to tackle from a standardization perspective in this model. To ensure smooth femtocell-to-macrocell handover, the CN and IMS core would have to coordinate the MM and resource management control messages over disparate signaling transport while ensuring voice call continuity (VCC). Figure 6 illustrates one possible scenario of signaling and bearer transport switchover from IMS to CS and vice-versa during handover. The illustration assumes the macrocell is in a CS network and the femtocell is in an IMS-based network.
Figure 6 : Signaling and bearer transport switchover for IMS to CS handover
Per the illustration in Figure 6, during hand-in the CN together with the UE identifies the appropriate FAP (using an approved neighbor list managed at the RNC). Once the FAP is identified, the MSC acts as the anchor for this call and initiates a signaling transport switchover through the IMS domain via the CSCF. In the IMS domain, the CSCF initiates SIP signaling to set up signaling and bearer (RTP) transport sessions and the RRC protocol at the FAP sets up the radio link with the UE. Interworking between SIP and the RRC/MM function is done at the FAP. Once the radio link at the FAP is set up, the MSC transfers the call over to the IMS domain before terminating the radio link in the macrocell. During hand-out, the MSC continues to anchor the call - however it is also possible that the CSCF anchors the call and initiates signaling and bearer transport through the CS domain. To support VCC, a logical Domain Transfer Function (DTF) as defined in 3GPP TS23.206 is implemented in anchoring the CSCF or MSC; this function ensures seamless transfer of signaling and bearer transport across domains.
Conclusion
In femtocell, service providers and TEMs have tremendous opportunity to address coverage and capacity issues to offer innovative high-quality service and reduce customer churn. However, the future success of femtocell technology fulfilling this opportunity will depend largely on the progress of standardization by the Femto Forum and other industry bodies in the near future. Each of the architectures described above has distinct advantages and specific issues to tackle. In all approaches, the FAP and FGW are common devices that need to be put in place. The approach that is least intrusive to operators' existing network infrastructure, enables quick standardization (e.g., requiring minimal new protocols), is most cost effective, is easy for consumers to use, and provides reasonable quality of service will likely make the cut. Table 2 attempts to compare these approaches on qualitative metrics.
| Feature | Iub over IP | Iu Over IP | UMA/GAN Based | SIP Based |
|---|---|---|---|---|
| Unique Femto Cell ID | Cell ID; (16 bits) | RNC-ID; (12 bits) | IP Address | IP Address |
| Load on the Network | Moderate; on RNC/CN; Most handovers handled at RNC | High; on CN Most handovers traverse across FGW to CN | High; on CN Significant UMTS to GAN network translation | High; Significant coordination between CN and IMS core for handover |
| Complexity and cost at FAP | Minimal; Few protocols on FAP | Moderate to High; RNC protocols at FAP | High; RNC and GAN protocols at FAP | High; RNC and IMS protocols at FAP |
| Number of Speech Transcodings at RAN before FGW | None | At least One; (in case MSC doesn't support Voice on RTP/UDP) | At least Two; (in case MSC doesn't support Voice on RTP/UDP) | At least One; (FAP will convert the voice packets to RTP/UDP) |
| Speech Quality | Good; compared to other 3 approaches | Inferior; compared to Iub over IP | Inferior; compared to others | Inferior; than Iub over IP but good compared to UMA/GAN |
| Configuration complexity | Less; (RNC will take care of radio resource management) | Relatively More; (Operator has to reserve some radio resources including RNC-ID space for Femto Cell Use) | Relatively More; (Operator has to reserve some radio resources for Femto Cell Use), but less than Iu over IP (RNC ID to IP Address mapping will be managed by FGW) | Relatively more; (Operator has to reserve some radio resources including CN-ID space for Femto Cell Use) |
| Aligned with Network Evolution | Less; Iub is not well standardized | Well; Aligns well with flat all-IP LTE architecture evolution | Well; Recent 3G - GAN standard gives good impetus | Well; Aligns well with flat all-IP LTE architecture evolution |
| Network Element Reuse | Less; FAP and FGW are new devices; RNC may need upgrade | Less; FAP and FGW are new devices; MSC may need upgrade | High; Assuming GANC is prevalent); FAP is a new device | Moderate; FAP is a new device; CSCF, HSS may need upgrade for handover |
Table 2 : Comparison of various femtocell network architectures
With a broad library of 3G, 2.5G, and 2G wireless protocol software (with LTE on the roadmap) and deep experience in system development and deployment, Continuous Computing is ideally positioned to meet faster time-to-market needs of femtocell device manufacturers to address the market opportunity. The company's Trillium Femtocell software suite supports all the varying approaches outlined in this white paper, thereby providing femtocell device vendors the flexibility to adapt as standardization and operator preferences evolve. For further information about Continuous Computing 's complete line of Trillium femtocell protocol software, please visit www.ccpu.com/products/trillium/femtocell.html or contact one of the company's Sales Directors.
About Continuous Computing
Continuous Computing provides integrated systems and services that enable telecom equipment manufacturers to rapidly deploy Next Generation Networks (NGN). Over 150 customers worldwide benefit from the company's unique blend of customized professional services, Trillium protocol software, AdvancedTCA and CompactPCI systems, and BladeCenter hardware. Continuous Computing helps customers reduce platform lifecycle costs, optimize data delivery, and accelerate deployments of NGN, 3G/4G Wireless, and IP Multimedia Subsystem (IMS) infrastructure. The company is ISO-9001 and CMMI certified and based in San Diego with development centers in China and India. For more information, visit www.ccpu.com.
Continuous Computing, the Continuous Computing logo, Create | Deploy | Converge, FlexTCA, Flex21, FlexChassis, FlexCompute, FlexCore, FlexDSP, FlexPacket, FlexStore, FlexSwitch, FlexTCA, Network Service-Ready Platform, Quick!Start, TAPA, Trillium, Trillium+plus, and the Trillium logo are trademarks or registered trademarks of Continuous Computing Corporation. Other names and brands may be claimed as the property of others.
