Over the course of the past 12 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 fibre) 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.

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 banner to work with various standardisation 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 standardise 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 organisations influencing femtocell standardisation 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 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 standardisation bodies.

Standards Body Focus Status
3GPP Standardisation 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).

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 tunnelling 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 (ie, Iub-over-IP) or between the MSC/SGSN and RNC (ie, 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 standardisation 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.

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 (ie, handover from macrocell to femtocell), the CN together with the User Equipment (UE) identifies the appropriate FAP (using an approved neighbour 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 (ie, 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.

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 signalling 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 standardised 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.

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.

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 standardisation perspective in this model. To ensure smooth femtocell-to-macrocell handover, the CN and IMS core would have to co-ordinate the MM and resource management control messages over disparate signaling transport while ensuring voice call continuity (VCC).

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 signalling 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 standardisation 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 standardisation (eg, 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.

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 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 standardisation and operator preferences evolve.

For more information, visit Continuous Computing