FCG.03 3G Femto Solution Implementation Guidelines 1.

0 03 July 2008

This is a non-binding permanent reference document of the GSM Association.

Version Control Author: Rune-Harald Rakken, Telenor

Security Classification Category (see next page)

V1.0 rune-harald.rakken@telenor.com

Restricted to

Members Rapporteurs Associate Members

Security Classification - RESTRICTED Access to and distribution of this document is restricted to the persons listed under the heading Security Classification Category. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those listed under Security Classification Category without the prior written approval of the Association. The GSM Association (Association) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Copyright Notice Copyright 2008 GSM Association GSM and the GSM Logo are registered and the property of the GSM Association. Antitrust Notice The information contain herein is in full compliance with the GSM Associations Antitrust Compliance policy. Document History
Version Date Brief Description

0.8.5 0.8.6 0.9.0 0.9.1 0.9.3 0.9.4

16.05.08 05.06.2008 13.06.08 18.06.08 23.06.08 03.07.07

After feedback from Cairo meeting Feedback from ATT and VF Updated after drafting group phone conference Updated after phone conference. Minor updates after phone conference and received comments Minor updates after GSMA fcg 20 and reflecting Femto Forum WG3 June 2008 agreements.

Changes Since Last Version

Other Information
Type Description

Document Owner Revision Control Document editor/company Feedback This document is intended for use by the members of GSMA. It is our intention to provide a quality product for your use. If you find any errors or omissions, please contact us with your comments. You may notify us at mailto:prd@gsm.org. Your comments or suggestions are always welcome.

Table of Contents 1 EXECUTIVE SUMMARY .................................................................................................... - 4 2 INTRODUCTION .................................................................................................................. - 5 3 SCOPE .................................................................................................................................... - 5 3.1 3.2 In Scope .................................................................................................................................... - 5 Out of Scope.............................................................................................................................. - 6 -

Femto Gateway - Development of Implementation Guidelines ............................................. - 6 4.1 Operator requirements for femto architecture ............................................................................ - 6 4.2 3GPP work on femtocells and femto architecture ...................................................................... - 7 4.3 Architecture options ................................................................................................................... - 9 4.4 Femto architectures on the market ............................................................................................ - 9 4.4.1 Iu over IP based architecture........................................................................................... - 10 4.4.2 Iub over IP based architectures....................................................................................... - 10 4.4.3 UMA/GAN based architecture ......................................................................................... - 11 4.4.4 To IMS core..................................................................................................................... - 11 4.5 Interoperability ......................................................................................................................... - 13 4.5.1 Any FAP to any FGW ...................................................................................................... - 13 4.6 O&M of Femtocell and Gateway .............................................................................................. - 13 4.6.1 O&M of FAP .................................................................................................................... - 13 4.6.2 O&M of FGW................................................................................................................... - 14 4.7 Femto gateway guidelines ....................................................................................................... - 14 4.8 Femto Transport Security ........................................................................................................ - 14 4.8.1 Femtocell to Femto Gateway Connection through Internet.............................................. - 14 4.9 Femtocell Traffics QoS Treatment .......................................................................................... - 15 4.9.1 Femto Gateway Protection through Firewalls .................................................................. - 15 -

5 6 7

Conclusion and Recommendations....................................................................................... - 16 For Further Study .................................................................................................................. - 16 Appendix A: GLOSSARY.................................................................................................... - 17 -

EXECUTIVE SUMMARY

This document provides an overview of the Femtocell deployment solution implementation guidelines, as defined by the Femtocells Group in the GSMA. The aim of this document is to identify the future direction and requirements of the GSMA operator community for the Femtocells industry. . All of the requirements that are contained within this document have been submitted into the relevant standardisation bodies (Femto Forum, 3GPP). Femtocells are regarded as consumer products throughout this document. This means that the customer should have the choice to select from a selection of different types of operator approved femtocells from a variety of different vendors. To obtain sufficiently large volumes to achieve economies of scale, standardised solutions and interoperability is seen as crucial for the future development of the Femtocell market. GSMA strongly recommend that standardised protocols and interfaces are used, and that no extra application servers should be needed to introduce femtocells in the operators networks. To be more specific, GSMA recommends using the interface between the Femto Access Point (FAP) and the Femto Gateway (FGW) which is under discussion in 3GPP Rel 8. GSMA further recommends that there is full interoperability between femto access point and femto gateways from all vendors, to achieve economies of scale and make femtocells a sustainable business. GSMA urges the need for standardises femto solutions, and recommends choosing vendors fulfilling these basic requirements and complying with the standards.

INTRODUCTION The term femtocell is used widely in the industry, meaning in-house base station providing standard mobile communications over the air interface. Most commonly femtocells denote a 3G in-house base station which implements UMTS and HSPA technology. However it is also possible for the term femtocell to be extended to 2G, CDMA 2000, and WiMAX in home devices. The term femtocells also denotes a multi technology in-house home Gateway (or CPE: Customer Premises Equipment) including DSL, WiFi or 3G. In most cases it needs embedded functions such as QoS, resource control, policy enforcement function, internet traffic routing and various types of software clients to support the underlying technologies.

Standard cell (radius: several km)

Mobile phone network

Base Station Existing mobile phones can be used

Femtocell Gateway

ADSL/FTTH line Femtocell (radius: several to tens of Femtocell meters) Access Point

ISP IP network

Figure 1. Illustration of the femtocell concept. The femtocell is a small scale indoor cell providing standard mobile air interface, using DSL, cable or FTTH as backhaul.

3
3.1

SCOPE
In Scope

Until now the Femtocell marketplace has been strongly driven by the vendor community, leading to a lack of standardised architectures and interfaces. There is still the possibility to get 3G femtocell architectures included in 3GPP release 8 specifications, to support the MNOs requirement for standardisation. The recommendation from this document will help support the requirements in 3GPP release 8 and 9.

The situation is better for development of LTE femtocells, due to the close alignment in timescales with the overall standardization of LTE. LTE femtocell has been identified as an area for further work, and is not covered in detail in this document. This document focuses on 3G femtocells, and describes a number of Femtocell solution implementation guidelines, describing what solutions are recommended for network operators, and which proprietary solutions it is recommended to avoid. The development of enterprise femtocells have not yet gained the same maturity as femtocells for home usage, therefore further work needs to be carried out on enterprise femtocell solutions.

The view of the mobile operator community is to have standardised Femtocell solutions, with open interfaces, and to the fullest extent interoperability between equipment from different vendors to avoid networks being locked into particular vendors solutions. As femtocells are operator approved equipment that will be located in peoples homes, it is important to provide the end-user with a level of choice in the type of Femtocells that are available to them. The primary focus of this document is on 3G femtocells, which is the area with the most momentum within the vendor and operator communities.
3.2 Out of Scope

LTE femtocells, CDMA 2000 femtocells and WiMAX Femtocells, 2G femtocells are outside the scope of this document. The focus on the development of 2G and WiMAX femtocells is far less than the momentum within the industry for 3G femtocells. The development of LTE femtocells is more closely aligned with the 3GPP LTE standardisation than has been the case for 3G Femtocells. Due to this the need for LTE femtocell guidelines are less urgent than for 3G femtocells. LTE femtocells are still someway off being released into the market place, and the standardisation of the Femtocell LTE solution will be completed as part of delivery of the overall LTE standards. 4
4.1

Femto Gateway - Development of Implementation Guidelines

Operator requirements for femto architecture

GSMA supports the requirements put forward in 3GPP TS 22.011. In addition, from the operator perspective, the femto architecture shall fulfil the following requirements: R1. R2. Femto solution shall connect to mobile core network with the standard 3GPP interfaces, Iucs and Iups. To maximize the ADSL broadband upstream bandwidth usage efficiencies, femtocell upstreams VPN bandwidth shall not exceed 200 kbps for a combined 4 simultaneous voice calls, including signalling traffic and overhead. The uplink and downlink data traffic shall be optimised regarding overhead. Here different traffic scenarios like keep alive signals or streaming should be considered. The Voice quality shall not be lower than for 3G calls (e.g. latency, jitter KPI have to be considered). The number of interfaces towards the legacy network elements shall be limited (e.g. to limit the IOTs). This shall be considered also for the evolution towards IMS. There shall be no need for extra IMS or SIP application servers for the Femtocells only.

R3. R4. R5. R6.

R7.

R8.

R9.

R10. R11.

R12.

R13.

R14. R15. R16.

R18.

The FAP shall not connect directly to critical mobile network equipments (such as HLR, MSC) To limit impacts on network if attacks are from the FAP To limit dimensioning impacts on mobile network equipments To limit configuration needed in mobile network Femto solution shall be compatible with all services implemented in the macro mobile network like e.g. Compatible with IN solutions (for prepaid or value added services...) At least same charging possibilities as for the macro network, in addition to having possibility for specific charging policy for femto services Legal interception Emergency calls, including position information Supplementary voice services Video services No macro network re-configuration shall be necessary each time a new FAP is installed. The FAP together with the FGW shall be responsible to limit the impact on the macro network. The Cell ID and location areas shall be handled in an optimised way. To limit the amount of location updates towards the HLR the FGW shall support IuFlex Interface between FAP and mobile operator equipment (including O&M) shall evolve towards a standardised interface To allow introduction of new FAP without having to change the femto system The FAP shall be software update capable via e.g. TR069 based methods. Interface between FAP and mobile network shall be secured based on 3GPP standards. For more details, refer to FF WG3 and 3GPP SA3 security requirements documents and the GSMA white paper Security Issues in Femtocell Deployment. FAP shall support local traffic offload controlled by mobile operator to fulfil operator and regulatory requirements The local traffic offload shall be based on 3GPP standards as yet to be defined. Direct Tunnel capabilities shall be supported to optimise the traffic load on an SGSN. As this is based on available standards this shall be available from the beginning. Evolution/scalability, the femto solution shall be able to evolve to adapt to a possible boost of data traffic in a cost effective way. Femto solution shall provide industry standardized QoS treatment for different type of traffic across the broadband pipe to the extent possible. R17. Femto management system shall utilize industry standardized protocol. For further information look into the GSMA white paper Management of Femtocells. Femtocells shall support closed user groups as well as open access.

4.2

3GPP work on Femtocells and Femto architecture

3GPP uses the term Home NodeB (HNB) for 3G femtocells, whereas the term Home eNodeB is used for the LTE (3GPP Long Term Evolution) femtocells. In the Release 8 specification work, two items are work in process: a Technical Report (TR) on Home NodeB/ Home eNodeB, reported in 3GPP TR 25.820 a TR of self-organising networks (SON) related O&M Interfaces for Home NodeB, reported in 3GPP TR 32.821

The support of the 3G Home NodeB is ensured within the framework provided in the UTRAN architecture, with support of legacy UEs and legacy core networks. The UTRAN architecture discusses different deployment options, in particular an Iub deployment, a GAN based deployment and an Iu deployment option. The preferred deployment option that has been chosen is the Iu or Iuh-based termination on the 3G Home NB. At the moment there are three possible transport options for carrying RANAP over the Iuh interface are under discussion
1. RANAP over SCCP 2. RANAP over SCTP with UEs identified by use of PPI 3. RANAP over SCTP with lightweight adaptation layer (RUA)

Options 2 and 3 have been investigated, and due to the fact that option 2 requires changes within the RANAP to handle the large number of FAPs and connected UEs that will be deployed by the solution. Option 3 is currently the preferred solution, because it will allow use of a specific protocol layer to optimise the communication between FAP and FGW. Option 3 is supported by the Femtoforum WG3 which is looking at architecture, and is also the solution preferred by the June 2008 RAN3 ad hoc meeting. This however also has to be approved by the 3GPP RAN group to become a standard. As femtocell architecture has not been completely standardized in 3GPP, it is imperative that the operator community agree on the functional components of the FAP (HNB) and femto gateway (FGW). With the standardization of functional architecture and system interfaces, the interoperability of vendor equipment can then be expedited. The following figure shows the architecture being discussed within 3GPP:
UTRAN HNB Access Network
HNB Management System Iupc SAS

HNB-GW
Uu Iuh

Iu-BC

CN CBC

UE

HNB

SeGW Iu-CS MSC

Uu

Iub

UE

Node B

RNC

Iu-PS

SGSN Iur

RNC
HNB HNB-GW SeGW Home Node B Home Node B Gateway Security Gateway

Out of Scope (e.g. O&M aspects are shown to give a complete stage 2 overview but shall be defined by SA5)

Figure 2.

Femto architecture discussed within 3GPP

4.3

Architecture options

During the development of the femtocell concept, several versions of femto architecture have been proposed and are discussed in the following sections.
4.4 Femto architectures on the market

The following section contains a high level summary of the different possible solutions to connect a FAP to the MNO core network, with the intention to provide some background of the different solutions & how they can be implemented. It has become necessary to define a specific architecture due to the limits in the scalability of the RNC to allow the direct connection of the large number of Femtocells into it even if a standard solution like Iub over IP is used. Due to this lack of RNC scalability this architecture been abandoned by most vendors. Therefore the most viable solution seems to be the use of a femto gateway connected directly into the core network. This might also include some kind of Internet breakout functionality giving the possibility of routing the Internet bound traffic directly into the Internet instead of traversing through the mobile core network. This kind of breakout functionality however needs to fulfil the demands for legal intercept that is put onto operators when using equipment running in licensed spectrum. However beside the capability for internet breakout, there is also the requirement to support Direct Tunnel and IuFlex for handling large traffic volumes.
Femto Management System FAP-MS
F F FGW-MS HPLMN Core Network Fr FbFbFbSubscriber Databases CS core PS core IMS core

Femto GW
F Mobile device Radi o

Femto Access Point

FL

Home GW

Fixed Broadband SeGW

HPLMN RAN

Figure 3.

Proposed femto reference architecture. This might be subject to change. Source: Femto Forum, December 2007 meeting.

The femtocell access point (FAP) would typically contain functionality: 3GPP Signalling, User Plane, Radio Resource Management IP transport functions

QoS management functions Layer-3 Security functions TR-069 Management functions Firewall functions (for breaking Internet traffic off at the FAP) NAT, Security, Auto configuration

The femto gateway (FGW) would typically contain functions like 3GPP RANAP Network timing delivery and synchronisation Femtocell authentication and authorisation AP Topology hiding Network topology hiding IP Security functions Femtocell traffic aggregation and routing Auto configuration

4.4.1 Iu over IP based architecture

A solution having an Iu interface between the FAP and the FGW is denoted an Iu-based architecture. If there are some RAN and GGSN functionalities in the FAP, this is a collapsed or flat IP architecture. An Iu interface between FAP and FGW supports the user plane traffic. In addition to current open Iu interface procedures for registration, management should be defined on the interface between FAP and FGW. Standardized access control must also be defined between FAP and FGW. The FGW aggregates the FAPs and offers 3GPP based standard Iu interfaces (IP/ATM) towards the CN. Typical the first versions of the FGW can handle and control up to 20 000 femtocells simultaneously, whereas vendors have claimed that future versions of the femto gateway will be capable of handling up to 100 000 femtocells simultaneously.
4.4.2 Iub over IP based architectures

A number of vendors have proposed a type of a modified RNC (femto gateway) into the network and use Iub over IP between the femto gateway (FGW) and the FAP. There are however some clear drawbacks with this solution: 1. Since femtocells backhaul traffic has to traverse the broadband network and public internet, it is extremely difficult to control the errors induced by noises on the twisted DSL lines and the delays and jitters induced over such public networks. These impairments will cause errors to the timing sensitive signalling traffic (NBAP Node B Application Part) which can subsequently cause problems to the femto cell solutions call handling abilities.

2. Similarly, the radio resource management function in the RNC may not be responsive to the femtocell radio environment due to delays and jitters. It is recommended to avoid Iub over IP based femto architectures.
4.4.3 UMA/GAN based architecture

Architectures based on GAN (Generic Access Networks) have been proposed to 3GPP by some vendors. The HomeNodeB (HNB, also know as femtocell) functional architecture is then utilizing GAN Iu mode as a basis for the architecture. The key consideration for the proposed architecture is the functional split of the traditional RNC role between the HNB and HNB GW (i.e. Femto Gateway). In this architecture, it is proposed that HNB is responsible for the radio aspects and the HNB GW is responsible for CN connectivity. GAN Iu mode based architecture provides limited architecture changes from existing 3GPP standards. Operators do not recommend using the GAN protocol, but a distribution of functionality similar to this architecture might be a desirable solution.
4.4.4 To IMS core

Currently, most vendor solutions are based on standard 3GPP radio access technologies connected to the CS core network via Iucs for voice handling as discussed above. However there are also other solutions on the market using IMS signalling towards the core network. Within this type of architectures, the FAP communicates with the Core Network (CN) using IMS/SIP protocols. However the SIP based architecture has its pitfalls, as the SIP agent is not readily supported on legacy UEs and IMS is rarely implemented to date. In the solution described in this section the Femto CPE includes a SIP-client which will communicate with the IMS Core Network using SIP (3GPP IMS SIP) signalling and SRTP. The proposed node to access the MNO domain for this architecture will be the Packet Data Gateway (PDG), which interacts with the IMS Core. However the PDG has been designed to connect 3GPP I-WLAN solutions. Due to this an update on the PDG is needed to offer mobility. Furthermore the mobile UE based on 3GPP R99 standards expects to communicate with an MSC node. Due to this the IMS based Application Server (AS) for Femto needs to have several MSC functions e.g. VLR, HLR access, call control, Supplementary Services, SRNS, or IN support. Due to this a specific AS for Femto is required for legacy UE for the proposed architecture. As most MNOs will implement standard based solutions in the future like e.g. MMTel (3GPP standard for Multimedia Telephony), or TAS (Telephony Application Server) for voice control in the IMS domain, an additional third solution beside CS and MMTel has to be implemented for the proposed Femto architecture. This is not of interest to most MNO and therefore a different solution has been requested which does not need any specific AS for Femto. Obviously all this does not fulfil the requirement that a legacy device shall be handled in the IMS domain with no need of a specific Femto AS. Hence there is the need to investigate how this could be fulfilled. Currently there is a single proposal that uses the newly proposed 3GPP standard for IMS centralised services (ICS) in a modified way. The following section contains some basic background of the ICS architecture. The ICS architecture as defined in 3GPP TS 23.292is shown in the figure below:

Figure 4.

UE

ICS based architecture supporting both ICS and non-ICS terminals

This architecture has been designed to support so-called ICS and non ICS based UEs at the same time. Here the ICS function is part of the MSC Server and therefore the UE could get registered within the IMS and CS domain at the same time. Whether a device gets registered in parallel in the IMS domain and the CS domain is dependent on user specific settings in the HLR. As a result the call control of a specific legacy UE could be carried out in the IMS or CS domain. ICS also allows handling of specific services like e.g. emergency calls in the CS domain and other services like for e.g. voice calls could be handled in the IMS domain. Only for ICS extended UEs are the interfaces Gm, I1 and the ICS AS required, whereas for the non ICS UE (legacy devices) none of those interfaces are needed. The mandatory support for legacy devices is one requirement of the Femto technology. Therefore the architecture could be simplified and the ICS-AS and the additional interfaces (GM, I1) are not needed. This leads to three different solutions. In the case where an MNO has rolled out IMS and ICS, no changes on the Femto solution are required and the call control could be handled within the IMS domain. If an MNO does not want to roll out ICS then there are two additional solutions that are possible. First option is a kind of Femto-ICS Gateway which has the same logical functions as the standard ICS. The Femto GW decides to route the traffic towards the IMS or CS domain based on HLR settings as shown in the figure below.

Figure 5.

ICS like architecture using Femto ICS gateway

Another solution could be the integration of the Femto ICS Gateway into the FGW. This is not shown here.

All ICS solutions do not require any changes of the available Femto solutions deployed by the MNO. This seems to be one of the advantages of this solution, in addition to the fact that no specific AS for call control is needed. The discussion above is related to legacy devices. All IMS capable devices could be handled independently as they do not require legacy functions. Currently discussions in Femto Forum and 3GPP on IMS femto solutions have just started and therefore an update could be expected of these solutions.
4.5 Interoperability

Interoperability between equipment from different vendors is an important issue that needs to be addressed. The first Femto solutions were vendor specific, but the 3GPP aims to complete the Technical Report for Femtocells in release 8 , and there will be Technical Specification (TS) in release 9. However major steps have been made as the 3GPP community have already agreed on a framework. Standardisation of the femto architecture and the interfaces is a prerequisite for interoperability of femto solutions. With respect to femtocells for Enhanced Packet Based System (EPS, former LTE/SAE), 3GPP seems to be more on track with the work conducted to specify the home eNodeB which probably will be more integrated into EPS. This is also well aligned with the dominant thinking in the Next Generation Mobile Networks (NGMN) group (www.ngmn.org)

4.5.1 Any FAP to any FGW

As mentioned above, vendors have chosen different solutions in the deployment of femtocell. Some vendors are providing end to end femtocell solutions. Another approach is where one vendor is providing the FGW and then relying on a number of partnerships with one or several FAP vendors to provide an end to end solution. The benefits of the latter approach are that it could enforce the need for interoperability, which will support the push for standardisation. This will probably pave the way for connection of any vendors femtocells to any vendors femto gateway. The target of the network operators is to have a fully standardized femto solution. In the first implementations it should enable any operator certified 3G FAP to be connected through the FGW in the operators network. In the longer term the standards should evolved towards full interoperability between any FAP and any FGW. For this target standardization of O&M, registration and discovery process is also necessary.
4.6 O&M of Femtocell and Gateway

GSMA recommends the standardisation of the O&M for Femtocells.

4.6.1 O&M of FAP

Currently there is strong support for using DSL Forums specification TR-069 as a basis for management of femtocells. TR069 is the industry preference, and in general TR-069 could be seen as an umbrella standard for DSL router in customers premises. The standard is optimised to handle and mange a huge amount of customer premise equipment (CPE). The methods of implementation

and the use of this high layer protocol will need to be further studied and adapted to include parameters standardized in the Femto Forum and 3GPP in a specific Femto object model. For further information on this topic, please look into GSMA femtocell management white paper.
4.6.2 O&M of FGW

As the FGW will be a standard node within the MNO Core Network the same 3GPP O&M mechanisms available in an MNO network shall be used to manage the FGW.
4.7 Femto Gateway Guidelines

- Use standardised interfaces o Towards 3G CN: Iucs, Iups, SIP o Iuh between the FAP and FGW - no extras (except the FGW) should be added to the network due to femtos - Also in LTE femto solution standard interfaces and architectures should be enforced
4.8 Femto Transport Security

Since femto systems uses xDSL/cable/FTTH access network and Internet as the transport medium, security of the connection becomes a major concern for the femto system operators. The security of femto system will need to achieve two purposes: 1) Security of data and voice traffics contents, 2) Preventative of malicious attack from Internet. The first task can be achieved through secure tunnel establishment between the FAP and the femto gateway; the second via firewalls between femto gateway and internet peering access. Other security risks that should be considered are e.g. the location lock, register only of authorised FAP towards the FGW. For further information, see the GSMA white paper Security Issues in Femtocell Deployment.
4.8.1 Femtocell to Femto Gateway Connection through Internet

When switching on the FAP with the DSL link running, the femtocell creates an authenticated and secured connection with the femto gateway and Home Network Manager (HNM) or Femto Management System. The femtocell transmits its ID and authentication key to the HNM, which authenticates the femtocell and creates a new entry for the user data in its database. Contacting the HNM, and the authentication itself, both will depend on the hard-coded information in the Femtocell and database in femto gateway. For further information on this topic, please look into GSMA femtocell management white paper. There are two protocols that can be used to establish this secure connection between femtocell and femto gateway: 1. IPsec VPN and 2. TLS/SRTP using either transport or tunnel mode. Currently 3GPP SA3 prefer IPSec as it is a well known 3GPP protocol. At the Femto Forum Plenary in June 2008 WG3 agreed on the use of IPsec as the standard for the first release of Femtocells.

TLS and SRTP have been designed for handling VoIP on the Internet and it also has some advantages. A study of what SSL/SRTP can achieve and what is the route to community acceptance, i.e. IETF and 3GPP, would be feasible for future releases. Because of the limited upstream bandwidth of ADSL and ADSL2+ access technology, the bandwidth of femtocells secure connection must not exceeds 200kbps for four (4) simultaneous calls combined, regardless of the encryption technology selected. This 200 kbps bandwidth requirement does include the signalling traffic and data streaming traffic. Not only voice traffic should be optimised; data traffic should also be optimised for Femtocell and should have a limited overhead. It should be taken into consideration the QoS scoring for the femto backhaul traffic. It may make sense to have broadband residential gateway to perform QoS treatments of all traffic types regardless if it is femtocell traffic or from other connections in the home. Delay and jitter impose impairments for the Femto solution. Delay can causes handover problem between FAP and macro cells that causing packets fall outside of the handover window of the core network to cause handover failure. Jitter can result in poor voice quality in the CS and packet loss or reordering in the PS. Both impairments should be treated with care by optimize the system design and DSL line testing.

4.9

Femtocell Traffics QoS Treatment

There are various types of traffic that broadband access networks carry. Internet bound data traffic still dominates the volume of data traffic. Femtocell will need to compete with other data applications for the limited bandwidth of ADSL network. The upstream bandwidth of ADSL network especially represents a threat to the successful transport of femtocell traffic, where the maximum bandwidth will likely not exceed 832 kbps for the loop length of more than 1500 meters, it will often be much less. Therefore, it is desired that policy driven QoS mechanism over the broadband access network can provide transport priorities for the femtocell signalling and voice traffic to ensure the minimum delays while not causing significant degradations for the less delay sensitive data traffic. Broadband QoS treatment can be implemented in different parts of home networks such as within the femtocell and/or within a residential gateway, and in layer-3 (IP DiffServ Code Point) and/or layer-2 (Ethernet P-bits). It may also depend on if the mobile operators have service level agreement (SLA) with DSL or cable access providers who will need to make sure network QoS policy will be enabled to enforce the end-to-end QoS delivery. For further information, see the GSMA white paper Femtocell requirements to the DSL.
4.9.1 Femto Gateway Protection through Firewalls

Malicious attack over the internet into the femto system can not be overlooked. A firewall router between femto gateway and internet peering connection should provide protections against such malicious attacks. The firewall router shall provide features that include intrusion prevention, layer 3 stateful firewalls, antivirus/anti-spam and web filtering that stops worms, spyware and other attacks. For further information, see the GSMA white paper Security Issues in Femtocell Deployment.

Conclusion and Recommendations

Femtocells are intended for placement in peoples homes. It should hence the customer should be give a selection of different types of operator certified and configured femtocells from different vendors to choose from, that all connect into the operators FGW. To obtain sufficiently large volumes to achieve economies of scale, standardised solutions and interoperability this requirement is seen as crucial. GSMA strongly recommend that standardised protocols and interfaces are used both between the FAP and the FGW, and between the FGW and the mobile core network. No extra application servers should be needed to introduce femtocells in the operators networks. GSMA further recommends that in the longer term and to the extent possible there should be full interoperability between femto access point and femto gateways from all vendors, to achieve economies of scale and make the femto business a sustainable business for the future. In order to achieve this, there is a need to standardise: - Interface(s) FGW FAP - Security protocol - UICC or TPM (trusted platform module) - Common discovery and parameters for auto configuration - O&M (preferably based on TR-069, as agreed by Femto Forum WG3) and standard management objects GSMA recommends choosing vendors that are fulfilling these basic requirements and complying with the standards. 6 For Further Study

The following topics are identified by the GSMA femtocell group as being for further study: Local breakout of Internet traffic Home eNode B (LTE femtocells). IMS Femtocell solutions. Business/enterprise Femtocell deployment

Appendix A: GLOSSARY 3rd Generation Partnership Project Access Point Application Server Asynchronous Transfer Mode Core Network Customer Premises Equipment Circuit Switched Call Session Control Function Digital Subscriber Line Enhanced Packet System Femto Access Point Femto Gateway Fibre To The Home Generic Access Network GSM EDGE Radio Access Network Gateway GPRS Support Node Gateway Home Location Register Home NodeB Home Network Manager IMS Centralised Services IP Multimedia Subsystem Internet Engineering Task Force Intelligent Networks Interoperability Test Internet Protocol IP Security Internet Service Provider 3GPP Iu interface 3GPP Iub interface Routing functionality for intra domain connection of RAN nodes to multiple CN nodes 3GPP interface, proposed to use between FAP and FGW Interworking WLAN Key Performance Indicator 3GPP Long Term Evolution 3GPP standard for Multimedia Telephony Mobile Network Operator Mobile Switching Centre Network Address Translation Node B Application Part Operations and Maintenance Packet Data Gateway Payload Protocol Identifier Packet Switched Quality of Service

3GPP AP AS ATM CN CPE CS CSCF DSL EPS FAP FGW FTTH GAN GERAN GGSN GW HLR HNB HNM ICS IMS IETF IN IOT IP IPsec ISP Iu Iub Iuflex Iuh I-WLAN KPI LTE MMTel MNO MSC NAT NBAP O&M PDG PPI PS QoS

RAN RANAP RNC RUA SAE SCCP SCTP SGSN SIP SRNS SRTP TAS TPM UE UICC UMA UMTS UTRAN VLR VPN xDSL

Radio Access Network Radio Access Network Application Part Radio Network Controller RANAP User Adaptation System Architecture Evolution Signaling Connection Control Part Stream Control Transmission Protocol Serving GPRS Support Node Session Initiation Protocol Serving Radio Network Subsystem Secure Real-time Transport Protocol Telephony Application Server Trusted Platform Module User Equipment Universal Integrated Circuit Card Unlicensed Mobile Access Universal Mobile Telecommunication System UMTS Terrestrial Radio Access Network Visitor Location Register Virtual Private Network A suite of DSL technologies including ADSL, ADSL2, ADSL2+, VDSL and VDSL2