Assessing Femtocell Network Architecture and Signaling Protocol alternatives - Embedded.com

Assessing Femtocell Network Architecture and Signaling Protocol alternatives

Over the course of the last twelve months, the wireless market hasexperienced a tremendous amount of excitement about femtocells, drivenprimarily by frustration over bad wireless call coverage within homeand/or office environments.

As a technology, a femtocell is a fairly simple concept of extendingthe 3G/2G wireless “lastmile” into the indoor arena (Figure 1,below ), 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 aFemto Access Point (FAP)within consumers' proximity and leveraging their public internetconnectivity (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 inthe details of how FAPs are engineered and managed.

Figure1: High-level femtocell network architecture

Early pioneers like Ubiquisys, RadioFrame Networks, and ip.accesshave led the charge in femtocell technology, spurring interest frombigger Telecom Equipment Manufacturers (TEMs) to jockey for position inthis nascent market. As expected, all of these players have approachedfemtocells from their respective positions of strength, resulting infragmented and disparate approaches to the challenge.

Continuing on this path would result in over-hyped technologysolutions that would make it difficult to interoperate, thereby lockingin consumers and service providers with specific vendors and in turnkeeping the cost of FAPs at a level where the industry would only see afew takers.

To avoid such a fate, the industry is rallying together under the FemtoForum  banner to work with various standardization bodies andindustry forums such as the International Telecommunication Union (ITU),EuropeanTelecommunication Standards Institute (ETSI), InternetEngineering Task Force (IETF), 3rd Generation Partnership Project (3GPP),and DigitalSubscriber Line (DSL) Forum to standardize the architecture forfemtocell networks and the protocols used by the network devices tocommunicate with each other.

Table 1 below lists thefocus areas and status of the various organizations influencingfemtocell standardization activities.

At a broad level, various approaches being proposed at recent FemtoForum meetings can be classified into three categories: UniversalMobile Telecommunications System (UMTS) based architecture, UnlicensedMobile Access (UMA) or GenericAccess Network (GAN) based architecture, and IPMultimedia Subsystem (IMS) based architecture.

The purpose in this article is to take a closer look at each ofthese approaches from the perspective of signaling protocols that needto run on each device and the what work will be need to be done by theFemto Forum and the various standardization bodies.

Table1: Organizations influencing femtocell standardization activity

UMTS Based Architecture
The UMTS based architecture focuses on leveraging the existing corenetwork (CN) behind the Radio Network Controller (RNC) and/or MobileService Controller (MSC), Serving GPRS Support Node (SGSN) andtunneling the traffic between CN and Node B over the subscriber'sbroadband IP network. At a high level, this approach is also referredto as Iu-over-IP. Here again, recommendations diverge on whether weneed 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 (alsoknown as Femto Gateway and hereafter referred to as FGW) is introducedto scale the limited capacity CN to connect to millions of femtocellsexpected to spring up. One of the significant drawbacks of theIub-over-IP approach, however, is the fact that the Iub interface isleft largely undefined by 3GPP and therefore proprietary vendorimplementations of the Iub solutions for femtocells using Iub-over-IPwould require significant Iub interface standardization effort.

Iub-over-IP. As shown in Figure 2 below , inthe lub-over-IP approach, the FAP takes on the role of the NodeB andthe FGW sits between the FAP and RNC. This configuration specificallysuits Small Office/Home Office (SOHO) or single home environments whereonly a few subscribers would access service through the FAP. Dependingon the number of FAPs connected to the FGW, in practice the RNC and FGWcould be collapsed into one device ” but for the sake of clarity wewill consider them as two separate devices.

Figure2: Protocol stacks for the Iub-over-IP approach

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

The RNC would handle all the resource management (bearer andcontrol) functionality; the RNC and FGW together would take care ofdelay jitter for the bearer traffic and control signaling (specificallyforced/hard handover mobility management) caused by the underlyingpublic IP network. In order to communicate with the pre-R4 CN ” whichdoes not support IP transport ” the RNC will have to do IP-to-ATM andvice-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 isof the Intra-RNC type ” otherwise it is of the Inter-RNC type.

During hand-in (i.e., handover from macrocell to femtocell), the CNtogether with the User Equipment (UE) identifies the appropriate FAP(using an approved neighbor list, managed at the RNC) and sets up anIub signaling and bearer transport tunnel over the broadband IP networkconnecting the FAP and FGW. The radio resource between the FAP and UEis 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 thefemtocell environment using MM and CC protocols at the MSC and UE.During hand-out (i.e., handover from femtocell to macrocell), the RRCprotocol and terminating the Iub tunnel. For femtocell-to-femtocellhandover, the RNC mostly acts as an anchor to set up the Iub tunnelover the new FAP and set up the radio link at the new FAP using the RRCprotocol before transferring the call to the new FAP and terminatingthe radio link at the old FAP.

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

Figure3: Protocol stacks for the Iu-over-IP approach

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

At startup, the FAP establishes a security association with the FGWto avoid compromising subscriber information over the public IPnetwork; TR-069 or some other similar mechanism could be used by theFAP to discover/obtain IP address from an ACS for the FGW. In addition,the FAP would use the ACS to obtain resource management parameter andalgorithms 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 tothe CN during femtocell-to-macrocell handover. QoS depends on theconnectivity offered by the public IP network; obviously IP delays anddata/packet loss will impact service performance. The FAP transportsvoice traffic to the FGW using RTP over UDP and the FGW converts it tothe 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 sameMSC/SGSN, it is of the Inter-RNC type, otherwise it becomes theInter-CN (MSC/SGSN) type. During hand-in, the CN together with the UEidentifies the appropriate FAP (using an approved neighbor list,managed at the MSC) and sets up an Iu signaling and bearer transporttunnel over the broadband IP network connecting the FAP and FGW.

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

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

UMA/GAN Based Architecture
In early 2000, a few technology upstarts approached convergence betweenthe fixed and mobile worlds by bridging two disparate wirelesstechnologies ” short-range, high-bandwidth, unlicensed 802.11 and longrange, relatively lower-bandwidth, licensed 2G/3G wireless ” using anunderlying public IP network and dualmode- handsets.

This was marketed as Unlicensed Mobile Access (UMA) technology andlater 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 integratemobile traffic over the public IP network. As shown in Figure 4 below wireless interfacesare bridged using Dual-Mode Handsets (DMH). GAN defines a new Upinterface between the GANC and mobile devices and a standard A/Gb andIu interface toward the CN.

Figure4: Protocol stacks for the UMA/GAN based architecture

In principle, UMA/GAN is similar to the femtocell approach exceptthat femtocell attempts to extend the licensed 2G/3G wireless spectrumto the customer premises instead of bridging licensed and unlicensedwireless technologies.

So, the underlying UMA/GAN architecture can likewise be extended tosupport the femtocell approach by overloading the GANC with Iu FGWfunctionality. This architecture is best suited for those serviceproviders who have an existing GAN infrastructure but want to offerinnovative high-value, high bandwidth services using High Speed PacketAccess (HSPA) capability requiring higher bandwidth than what current802.11 deployments can offer.

The FAP presents the Up interface toward the FGW, which also acts asthe GANC. The FGW communicates with the CN using the Iu interface. Atstartup, the FAP establishes a security association with the FGW toavoid compromising subscriber information over the public IP network;TR-069 or some other similar mechanism femtocell as an IP based deviceand these nodes communicate using IP address and port numbers.

The FAP converts voice packets to RTP packets and forwards these tothe FGW, which may have to convert the RTP packets back to voice basedon the CN transport network. Multiple transcoding due to differenttransport networks may lead to loss of voice quality, which needs to beovercome by implementing strict QoS at the Up interface.

Handovers in this approach are typically Intra-RNC/Inter-RNC innature. If the FAP and macrocell are managed by the same RNC (GANC) itis of the Intra-RNC type, otherwise it becomes the Inter-RNC type.During hand-in, the CN together with the UE identifies the appropriateFAP (using an approved neighbor list, managed at the GANC) and sets upan Iu signaling and bearer transport tunnel toward the GANC.

The FAP sets up the Up signaling towards the GANC. The radioresource between the FAP and the UE is managed by interworking of theRRC, Generic Access ” RRC (GA-RRC), and RANAP protocols. Theinterworking of RRC and GA-RRC protocols is managed by the FAP, whereasthe interworking of GA-RRC and RANAP is managed by the GANC. RRCterminates at the UE, GA-RRC terminates at the FAP, and GANC and RANAPterminate at the MSC.

Once the Iu tunnel is set up, the CN transfers the call over to thefemtocell environment using MM and CC protocols at the MSC and UE.During hand-out, the RANAP protocol at the MSC and RRC protocol at thenew RNC set up the radio link in the macrocell environment beforetransferring the call over to the macrocell and terminating the Iutunnel.

For femtocell-to-femtocell handover, the GANC mostly acts as ananchor to set up the Iu tunnel over the new FAP and set up the radiolink at the new FAP using RRC/GA-RRC protocol interworking beforetransferring the call to the new FAP and terminating the radio link atthe old FAP.

IMS Based Architecture
With improving QoS delivery on IP transport, UMTS 3GPP has beenmigrating both signaling and bearer transport from traditionalSignaling System 7 (SS7) to IP. Improved quality of voice calls overpure Voice over IP (VoIP) applications such as Skype has definitelymade a case for this migration. Session Initiation Protocol (SIP) andReal-time Transport Protocol (RTP) have been the key pillars of thismigration for signaling and bearer transport, respectively.

As shown Figure 5 below ,the IMS based architecture for femtocell looks to leverage the IMS coreand completely offload the mobile core network, which enables buildingfuture-proof femtocell networks where innovative application-levelservices can be deployed easily and delivered all the way to consumers.This architecture works best for vertically-integrated networkoperators such as Verizon, Orange, etc., that offer bundled wireless,wireline, and broadband services.

Figure5: IMS based architecture

In this approach, the FAP interworks the UMTS signaling plane withthe SIP signaling protocol over the public IP network. On the IMS coreside, the FAP may directly interface with softswitches providing CallSession Control Function (CSCF) functionality using SIP and interfacedirectly with the Home Subscriber Server (HSS) using the Diameterprotocol for Authentication, Authorization, and Accounting (AAA)functionality.

Alternatively, the FAP may choose to interface with these devicesthrough an aggregating packet data gateway. On the bearer plane, theFAP forwards voice traffic toward the IMS core as RTP packets. QoSdepends on the connectivity offered by the public IP network, and asnoted above IP delays and data/packet loss will impact serviceperformance. TR-069 could again be used for zero-touch initial systemconfiguration 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 tothe CN during femtocell-to-macrocell handover, which is a key issue totackle from a standardization perspective in this model. To ensuresmooth femtocell-to-macrocell handover, the CN and IMS core would haveto coordinate the MM and resource management control messages overdisparate signaling transport while ensuring voice call continuity(VCC).

Figure 6 below illustratesone possible scenario of signaling and bearer transport switchover fromIMS to CS and vice-versa during handover. The illustration assumes themacrocell is in a CS network and the femtocell is in an IMS-basednetwork.

Figure6: 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 appropriateFAP (using an approved neighbor list managed at the RNC). Once the FAPis identified, the MSC acts as the anchor for this call and initiates asignaling transport switchover through the IMS domain via the CSCF. Inthe IMS domain, the CSCF initiates SIP signaling to set up signalingand bearer (RTP) transport sessions and the RRC protocol at the FAPsets 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 callover to the IMS domain before terminating the radio link in themacrocell. During hand-out, the MSC continues to anchor the call “however it is also possible that the CSCF anchors the call andinitiates signaling and bearer transport through the CS domain. Tosupport VCC, a logical Domain Transfer Function (DTF) as defined in3GPP TS23.206 is implemented in anchoring the CSCF or MSC; thisfunction ensures seamless transfer of signaling and bearer transportacross domains.

Table2: Comparison of various femtocell network architectures

Conclusion
In femtocell, service providers and TEMs have tremendous opportunity toaddress coverage and capacity issues to offer innovative high-qualityservice and reduce customer churn. However, the future success offemtocell technology fulfilling this opportunity will depend largely onthe progress of standardization by the Femto Forum and other industrybodies in the near future.

Each of the architectures described above has distinct advantagesand specific issues to tackle. In all approaches, the FAP and FGW arecommon devices that need to be put in place.

The approach that is least intrusive to operators' existing networkinfrastructure, enables quick standardization (e.g., requiring minimalnew protocols), is most cost effective, is easy for consumers to use,and provides reasonable quality of service will likely make the cut. Table 2 above attempts to comparethese approaches on qualitative metrics.

Srinivasa Rao is network architectand and Ravi Raj Bhat is director of engineering at Continuous Computing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.