033-integrated femto-wifi networks white paper

8/16/2019 033-Integrated Femto-WiFi Networks White Paper

1/42

www.scf.io/ www.smallcellforum.org

DOCUMENT

Integrated Femto-Wi-Fi (IFW) networks

December 2013

033.06.01

SMALL CELL FORUM

RELEASE 6.0

Solving the HetNet puzzle

17 : 2 5

R U R A L & R E M O T E

U R B AN

E N T E R P R I S E

V I R T U AL I Z AT I O N

H O M E

scf.io


2/42

SMALL CELL FORUM

RELEASE 6.0 scf.io

If you would like more information about Small Cell Forum or wouldlike to be included on our mailing list, please contact:

Email [email protected]

Post Small Cell Forum, PO Box 23, GL11 5WA UK

Member Services [email protected]

Small Cell Forum accelerates small cell adoption to drive the wide-scale adoption of small cells and accelerate the delivery of integratedHetNets.

We are not a standards organization but partner with organizations that informand determine standards development. We are a carrier-led organization. Thismeans our operator members establish requirements that drive the activitiesand outputs of our technical groups.

We have driven the standardization of key elements of small cell technologyincluding Iuh, FAPI/SCAPI, SON, the small cell services API, TR-069 evolutionand the enhancement of the X2 interface.

Today our members are driving solutions that include small cell/Wi-Fiintegration, SON evolution, virtualization of the small cell layer, driving massadoption via multi-operator neutral host, ensuring a common approach toservice APIs to drive commercialisation and the integration of small cells into5G standards evolution.

The Small Cell Forum Release Program has now established business casesand market drivers for all the main use cases, clarifying market needs andaddressing barriers to deployment for residential, enterprise and urban small

cells. The theme of Release 6 is Enterprise, with particular emphasis on realworld and vertical market deployments, and the role of neutral host solutionsto drive the mass adoption of small cells in business environments.

Small Cell Forum Release website can be found here: www.scf.io


3/42

Report title: Integrated Femto-Wi-Fi (IFW) networks Issue date: 01 December 2013

Version: 033.06.01

Contents

1. Introduction .....................................................................1

1.1 Document Scope ................................................................. 1

1.2 Abbreviations ...................................................................... 1

2. Background ......................................................................2

2.1 3GPP Femto Networks .......................................................... 2

2.2 WiFi Networks ..................................................................... 3

2.3 Enterprise WiFi Networks ...................................................... 4

3. Deployment & Operational Scenarios of IFW-Networks....6

3.1 Residential IFW-Networks ..................................................... 6

3.1.1 System View ....................................................................... 6 3.1.2 Operational Scenarios .......................................................... 8

3.1.3 Benefits, Challenges & Concerns.......................................... 11

3.2 Enterprise IFW-Networks .................................................... 12

3.2.1 System View ..................................................................... 12

3.2.2 Operational Scenarios ........................................................ 12


3.3 Metro IFW-Networks .......................................................... 14

3.3.1 System View ..................................................................... 14

3.3.2 Operational Scenarios ........................................................ 14


4. Service & Technology Aspects of IFW-Networks ........... 16

4.1 Provisioning & Management ................................................ 16

4.1.1 Integrated IFW Provisioning ................................................ 16

4.1.2 TR-069 Data Models for Femto Configuration ........................ 18

4.1.3 Ongoing Work in 3GPP ....................................................... 22

4.2 Data & Traffic Flow Management ......................................... 22

4.2.1 Smart WiFi-Offloading ........................................................ 22 4.2.2 Seamless Femto-WiFi Handovers ......................................... 23

4.2.3 Simultaneous Femto-WiFi Flow Management ......................... 24

4.2.4 LIPA & SIPTO for Network Offloading ................................... 25

4.3 Control Plane Aspects ........................................................ 27

4.4 Architectural & Implementation Aspects ............................... 29

5. Standards ....................................................................... 32

5.1 Current and Ongoing 3GPP Standards Activity ....................... 32

5.2 Relevant BBF Standards ..................................................... 36

5.3 Relevant IETF Standards .................................................... 36


4/42


Version: 033.06.01

6. Conclusions .................................................................... 37

References ................................................................................ 38

TablesTable 1-1 Abbreviations ................................................................................. 1

Table 4-1 Relevant Data Models for Femto Configuration................................... 19

Figures

Figure 2-1 FemtoCell Network Architecture ........................................................ 2

Figure 2-2 Internet Access via WiFi Networks .................................................... 3

Figure 2-3 Internet Access via Residential WiFi Networks .................................... 4

Figure 2-4 Enterprise WiFi Networks ................................................................. 4

Figure 3-1 Residential IFW-Networks ................................................................ 7

Figure 3-2 Provisioning Systems of Femto & WiFi Networks ................................. 7

Figure 3-3 Operational Scenario R1: MNO Triple Play .......................................... 8

Figure 3-4 Operational Scenario R2: MNO Double Play ........................................ 9

Figure 3-5 Operational Scenario R3: MNO Double Play (Variant) ......................... 10

Figure 3-6 Operational Scenario R4: MNO Single Play ........................................ 10

Figure 3-7 Enterprise IFW-Network.................................................................. 12

Figure 3-8 System view of an Exemplary Metro IFW Network .............................. 14

Figure 4-1 Separate Management Protocols for FAP and WiFi .............................. 16

Figure 4-2 Management Protocol Interworking – TR-069 Based Provisioning ......... 17

Figure 4-3 Management Protocol Interworking – SNMP Based Provisioning ........... 18

Figure 4-4 TR-196 Update after Issue 1 ........................................................... 20

Figure 4-5 DM Usage for TR-196 Issue1 and Issue 1 Amendment 1 ..................... 20

Figure 4-6 DM Usage for TR-196 Issue 2 .......................................................... 21

Figure 4-7 Example DM Usage for Femto Configuration ...................................... 21

Figure 4-8 Seamless Handovers using HBM/NBM protocols ................................. 24

Figure 4-9 Flow Segregation across Cellular (Femto) & WiFi radio links ................ 24

Figure 4-10 Simultaneous Cellular (Femto) & WiFi Flow Management using DSMIP .. 25

Figure 4-11 Illustration of LIPA & SIPTO Concepts ............................................... 26

Figure 4-12 Structure of ANDSF Policy Management Object .................................. 28

Figure 4-13 Dynamic Operator Policy Provisioning using ANDSF ........................... 28 Figure 4-14 Core Network based IFW-Function ................................................... 29

Figure 4-15 Edge based IFW-Function ............................................................... 31

Figure 4-16 Gateway based IFW-Function .......................................................... 31

Figure 5-1 EPC Architecture with S2a & S2b (for PMIP) based protocols) .............. 32

Figure 5-2 EPC Architecture with S2c interface (for DSMIP based protocols) ......... 33

Figure 5-3 3GPP Work Items related to WiFi access ........................................... 33

Figure 5-4 Similarities and differences between MAPCON and IFOM ..................... 34

Figure 5-5 Integrated Femto & Trusted WiFi with a common backhaul ................. 35


5/42


Version: 033.06.01 1

1. Introduction

As Femtocell technology starts to have better penetration of the worldwide wireless

markets, and as smart phones with both 3G UMTS, 4G LTE and WiFi technology

support become prevalent, mobile operators are driven to formulating an integratedFemto and WiFi products strategy, in order to provide dual air-interface support forsmart phones at the same cell coverage location.

The apparent advantages of offering integrated 3G Femto and WiFi products are:

1.

Meet customer demand on low cost alternative internet access through WiFi

technology2. Simplify installation/connection for the customer: only one box, one power

supply, no extra cables, etc.3. Extend service continuity on 3G UMTS voice and data applications to WiFi4.

Drive scale of economics of integrated Femto and WiFi devices and services5. Lower cost of installation and ease of deployments for mobile operators to

have single installation process and savings of installation materials. This isespecially true on enterprise network and public hotspot services.

6. Set the foundation for traffic load management over multiple air interfacetechnologies per 3GPP standard functions such as ANDSF (TS 24.312)

1.1 Document Scope

The intention of this document is to provide comprehensive view of the use cases,scenarios and challenges that the IFW devices and networks are, or may be facing inresidential, enterprise and metro deployment.

It also is intended to address some technical background around IFW architectures,

IFW mobility, and related technical details as well as standard development andrequirements.

1.2 Abbreviations

Abbreviation Description

AP Access Point

ACS Auto Configuration Server

ANDSF Access Network Discovery and Selection Function

BBF Broad Band Forum

CWMP CPE WAN Management Protocol. Defined in TR-069 Amendment 2.

IFW Integrated Femto-WiFiISP Internet Service Provider

MNO Mobile Network Operator

NMD (WiFi) Network Management Device

OSS Operations Support System

SSID Service Set Identifier

Table 1-1 Abbreviations


6/42


Version: 033.06.01 2

2. Background

In this section, we shall briefly describe the technologies on which IFW-Networks andServices would be built on. They include basic Femto, WiFi and Enterprise Networks.

2.1 3GPP Femto Networks

Figure 2-1 FemtoCell Network Architecture

Shown above is a typical FemtoCell Network architecture, where in the FemtoCell ispowered by a Femto-Access-Point (FAP, also referred to as HNB or HeNB in 3GPPliterature) and provides Operator provided voice & data services as well as publicInternet access to cellular devices within the FemtoCell coverage area. The FAP is

connected to a Broadband Router, which in turn is connected via DSL or cable to theMobile Operator’s Core Network and Service Cloud via the Internet. The broadbandaccess is typically provided by an ISP, who may or may not be the same as the MobileNetwork Operator. The FemtoCells are managed by special FemtoCell Managementsystems, which are integrated into the overall Network Management System of theMobile Network Operators, as shown in Figure-1.

As is well known, there are several advantages of FemtoCells, which can be broadlyclassified under the areas of Coverage, Capacity, Offload and Services. Indeed,

FemtoCells provide improved coverage in areas, such as residential basements etc,compared to Macro-Cells. Due to the proximity of the Access Point, FemtoCells enablehigher average data rates compared to MacroCells. They also offload user traffic fromwide coverage area macrocells to smaller coverage area FemtoCells, thereby

potentially leading to better utilization of the operator’s spectrum. Furthermore, theyalso allow offloading of Internet bound traffic directly to the Internet withouttraversing the Operator Core Networks. Finally, FemtoCells also enable FemtoServices,such as Presence services etc.

Basic material on FemtoCells is available in various White Papers produced by theFemtoForum [1], popular books [2], [3] and Standards [4].


7/42


Version: 033.06.01 3

2.2 WiFi Networks

Internet access provided by WiFi networks involves a sophisticated set of network &

service providers, which defines the WiFi Service Value Chain. Figure below shows thevarious players in this value chain and their inter-relationships.

Figure 2-2 Internet Access via WiFi Networks

Internet Service Provider (ISP) is the main player in this ecosystem, who has thecommercial relationship (usually a long term contract) with end customer. The ISPprovides broadband connectivity to end user and additional services, such as email.

Some ISPs may also provide residential WiFi service along with broadband.

Wholesale broadband service providers provide interconnectivity between exchanges

and have commercial relationships with ISPs. They also manage ISP policy and canprovide end user policy.

WiFi premium service providers provide connectivity in hotpots, hotels, airports etc.

Enterprise network providers provide WiFi connectivity to large offices, campuses.ISPs may also have divisions that provide enterprise services.

Finally, WiFi aggregators provide interconnectivity between large number of WiFiservice providers. They also manage roaming relationships.


8/42


Version: 033.06.01 4

In the case of Residential-WiFi Service provisioning, the value chain simplifies to theone shown below.

Figure 2-3 Internet Access via Residential WiFi Networks

Access networks providers are based on either via copper, fibre or coax. This is usuallya highly contented network.

ISPs can unbundle at the exchange or use wholesaler to provide connectivity betweenexchange and ISP networks. ISPs also have service LANs that provide additionalInternet services (e.g. email, IPTV), legal intercept services etc. ISP policy is alsoapplied here (e.g. prioritisation of some ISP services).

Wholesalers can provide differentiated traffic flow based on ISP and service.

2.3 Enterprise WiFi Networks

Unlike in the case of Cellular systems, where 3GPP specifies the overall systemarchitecture and procedures, in the WiFi world, IEEE 802.11 and WFA do not specify

an end-to-end architecture. However, through common industry practices, vendorshave converged on a typical architecture, which is shown below.

Figure 2-4 Enterprise WiFi Networks

The Indoor Access Points provide 802.11 a/b/g/n client access and support MIMO with

typically 2,3 Spatial Streams. With support for Beamforming and MRC, data rates Upto 300 Mbps are enabled.


9/42


Version: 033.06.01 5

Outdoor Access Points are typically deployed to provide 802.11b/g client access, while802.11a links are used for backhaul. The Access points are either Standalone orconfigured for Mesh Operation. They can be powered with AC or DC and have Cable

Strand Mount. The Access Points are also PoE capable and offer Ethernet ports forconnecting peripheral devices.

The WLAN Controller typically handles algorithms for RF optimization and ensureSeamless L3 Mobility management. In addition, they also provide Security control andperform Image Management.

The Wireless Control System (WCS) is the heart of the Enterprise WiFi Network

Management system and enables the management of Wireless Mesh Network,network-wide policy configuration and device management. It supports variousprotocols such as SNMPv3, Syslog, IPSec, AAA, etc.

The Back Office Systems enable Bandwidth Monitoring and Management, PolicyDefinitions, Subscriber Database Management. In addition, they also maintain Billing

and OSS Systems.


10/42


Version: 033.06.01 6

3. Deployment & Operational Scenarios of IFW-Networks

Femto and WiFi technologies were both originally developed for indoor and small

coverage areas. While WiFi Access Points provided general Internet Access, Femto

Access Points provided both general Internet Access as well as access to Servicesprovided by the Mobile Network Operator. Although at first sight, these appeared to becompeting technologies, it was soon realized that both technologies could actually co-exist, resulting in potential benefits to the end-users, operators, service providers aswell as technology providers. This is a primary motivation for the Integrated-Femto-WiFi Networks.

Since the initial focus on indoor residential deployment cases, both Femto-cells as wellas “ WiFi-cells” were soon being considered for Enterprise as well as Metro

deployments. Accordingly, the space of Integrated Femto-WiFi Networks can beanalyzed within the three categories of Residential, Enterprise and Metro deploymentscenarios.

Integrated Femto-WiFi Networks involve multiple components, which may be managedby the same or different players. Specifically, IFW-Networks involve the Femto part,the WiFi part and the Broadband backhaul part, whereas the various players includethe MNO, ISP and the Customer (or end-user). Depending on who manages which partof the IFW-Networks, there emerge a number of operational scenarios for the IFW-Networks. These are listed below.

Operational Scenarios for Residential IFW-Networks

R1) MNO Triple Play Scenario: Femto + WiFi + BB managed by MNOR2) MNO Double Play Scenario: Femto + WiFi managed by MNO & BB by ISPR3) MNO Double Play Scenario: Femto + BB managed by MNO & WiFi by Customer

R4) MNO Single Play Scenario: Femto by MNO & BB by ISP & WiFi by Customer

Operational Scenarios for Enterprise IFW-Networks

E1) Enterprise Femto Network (EFN) managed by MNO & Enterprise WiFi Network

managed by EnterpriseE2) Enterprise Femto Network (EFN) & Enterprise WiFi Network managed by MNO

Operational Scenarios for Metro IFW-Networks

M1) Femto & WiFi managed by a Single MNOM2) Femtos of Multiple MNOs with a shared WiFi (e.g. single radio with one or moreSSIDs) and likely provided by a Neutral Host

In the following sections, these deployment and operational scenarios will bedescribed and analyzed.

3.1 Residential IFW-Networks

3.1.1 System View

The figure below shows an overview of an Integrated-Femto-WiFi Network in aResidential environment.


11/42


Version: 033.06.01 7

Figure 3-1 Residential IFW-Networks

The Residential IFW-Cells are connected to the Exchange (DSLAM) via a commonbackhaul provided by the Access Network Provider. The Exchanges themselves areconnected via the Wholesale Network to the ISP LAN, which provides services such as

Email, IPTV, Legal Interception etc. Traversing the public Internet, the residential IFW-Cells connect to the Mobile Core Network (e.g. 3G Core Network or LTE EnhancedPacket Core Network) via the Femto-Gateway.

While the above figure shows the path taken by the user traffic, it does not depict theprovisioning and management aspects. The figure below highlights the present-dayprovisioning sub-systems as well as the various interfaces for residential Femto andWiFi networks, based on 3GPP UMTS standards.

Figure 3-2 Provisioning Systems of Femto & WiFi Networks


12/42


Version: 033.06.01 8

At the bottom end of the figure is the 3G-IFW-Cell, which is realized by an integrated3G-Femto and WiFi Access Points. These are connected to a Residential Gateway (e.g.broadband modem and router), which in turn connects to a POP in the ISP Network

and Security Gateway (SeGW) in the Mobile Operator Network. The SeGW connects tothe Femto-Gateway, and Mobile Operator Core Network in sequence.

The WiFi data flows from the IFW-AP to the POP in the ISP network and onward to theInternet. The Femto data flows from the IFW-AP to the SeGW over the Iuh via anIPSec tunnel, and terminates at the Femto-Gateway. The Femto Gateway

communicates with the Mobile Core Network via the Iu-PS and Iu-CS interfaces forPacket-switched and Circuit-switched data respectively.

The figure also shows the Femto and WiFi (i.e. Residential GW) Provisioning Servers,which are presently different subsystems in the Operator and ISP networks. TheFemto and WiFi parts of the IFW-AP are provisioned using TR-069 over SSL/TLS orIPSec and TR-069 protocols respectively. Note that the provisioning systems for theFemto & WiFi are currently distinct and there may be some value in harmonizing or

integrating these systems also.

3.1.2

Operational Scenarios

As identified earlier, four possible operational scenarios exist in the context ofResidential IFW-Networks. They are:

R1) MNO Triple Play Scenario: Femto + WiFi + BB managed by MNOR2) MNO Double Play Scenario: Femto + WiFi managed by MNO & BB by ISP

R3) MNO Double Play Scenario: Femto + BB managed by MNO & WiFi by CustomerR4) MNO Single Play Scenario: Femto by MNO & BB by ISP & WiFi by Customer

Of these, Scenario R4 is a more likely one, wherein the Operator would offer theintegrated Femto/WiFi Device, while leaving the WiFi provisioning and management tocustomer. The reasons for the latter include: (1) allowing the customer to havemaximum flexibility of configuring the WiFi function & home LAN and (2) reduceoperational cost associated with WiFi customer support.

We shall now describe in greater detail each of the above Operational Scenarios.

Operational Scenario R1: MNO Triple play (Femto + WiFi + BB supplied byMNO)

Figure 3-3 Operational Scenario R1: MNO Triple Play

Shown above is the Residential IFW-Network framework, where the green color coding

indicates that the IFW-AP at the customer premises, the ISP network including the ISP


13/42


Version: 033.06.01 9

Service LAN, and the Macro Core Network are all managed by the Mobile NetworkOperator.

The integration of Femto and WiFi can be implemented at the radio interface level.Some of the benefits of such integration are: (1) Transfer of sessions from Femto to

WiFi and vice-versa; (2) LIPA using Femto & WiFi links; (3) Prioritisation of Femtovoice over WiFi data etc. It is likely that such integration will require client support inhandsets.

Network components required for WiFi interworking may reside in either ISP or macrocore network or even the customer premises. There may be direct connectivity via ISPLAN to macro core network, instead of being via the Internet.

Interworking scenarios can be deployed very efficiently if MNO has significantbroadband presence. Examples of MNOs that have significant market share inbroadband include O2 in UK, France Telecom – Orange in several countries etc.

Operational Scenario R2: MNO Double play (Femto+WiFi by MNO, BB by ISP)

Figure 3-4 Operational Scenario R2: MNO Double Play

In the Residential IFW-Network framework shown above, the IFW-AP at the customerpremises is deployed and managed by the Mobile Network Operator (green colorcoding), whereas the ISP is an independent business entity (shown in brown color).

As in the Operational Scenario R1, the integration of Femto and WiFi can beimplemented at the radio interface level. However, network components required forWiFi interworking will have to reside in the macro core network, or even in thecustomer premises.

Since the user traffic (non LIPA type) traverses the ISP network, all traffic is subjectedto ISP policy control. As it is assumed in this Operational Scenario that the MNO has

no service level agreement with ISP, interworking features and performance aresubject to quality of access line and ISP network. For example, some ISPs may havethe Internet peering point in a different country, which may result in increased latencyfor voice.


14/42


Version: 033.06.01 10

Operational Scenario R3: MNO Double play (Femto by MNO, WiFi by ISP)

Figure 3-5 Operational Scenario R3: MNO Double Play (Variant)

In the Residential IFW-Network framework shown above, the WiFi service is suppliedby ISP, and the WiFi-AP is part of the DSL router (shown in brown color). WiFi service

management, software upgrades and customer support are provided by ISP. On the

other hand, Femto service is provided by MNO and runs over the top of the broadbandnetwork (shown in green color).

In such a scenario, WiFi access is likely to get prioritised by ISP at the DSL router and

Femto may have lower priority, contending with other home broadband services (e.g.IPTV).

Interworking scenarios will not involve ISP LAN and are likely to be implemented viaclient support in devices.

Operational Scenario R4: MNO Single play (Femto by MNO, BB by ISP, WiFi byCustomer)

Figure 3-6 Operational Scenario R4: MNO Single Play

The Operational Scenario shown above is one of the most commonly available options.Here, the ISP provides DSL router, MNO provides the Femtocell and the customerowns the WiFi router (shown by three different colors). Any interworking scenariosneed to be implemented via network and client support.

WiFi and Femto data are not given priority over ISP LAN and are subjected to ISPnetwork policy management.

Finally, the MNO has to manage issues on a wide range of models and makes of WiFiAPs, so that customer care can be very difficult!


15/42


Version: 033.06.01 11

3.1.3 Benefits, Challenges & Concerns

The benefits of integrating Femto and WiFi in the Residential scenarios, in general,include:

•

Addresses all terminals (WiFi only, 3G only, WiFi+3G) within the residence• Compared to WiFi only scenario, Femto & WiFi integration brings all MNO

services and inexpensive plain internet access to all 3G & WiFi devices.•

May simplify the LIPA for WiFi+3G devices, by using WiFi for LIPA and 3G for

MNO services.• Reduce interference between Femto and Macro-Cellular networks by

offloading to unlicensed WiFi radio access, whenever possible.•

Enable bandwidth management (e.g. handover, segregation and aggregationof IP flows) across the Femto and WiFi radio links

• Enable integrated services across the 3G Devices and WiFi devices (e.g.media, appliances, security devices).

For the successful deployment of Residential IFW-Networks and services, the followingchallenges (technical & business) need to be addressed:

• Integration of BB modem (Residential GW) and Femto provisioning systemrequires separate provisioning profiles, policies and procedures (e.g. start upprocedures are different, device ID, data models, QoS Policies, DSL rate plan,etc.)

• A common ACS for provisioning of both BB modem and Femto is possible butcan be costly, since fixed network and Femto topologies are different.

•

Integration of Femto & WiFi may pose some security challenges.•

Billing between Femto and WiFi must be consistent and understandable by

the client.•

For successful integration of WiFi and Femto, investment will be required byISPs and MNOs, which will need to be justified.

Finally, the following are some concerns for the business success of Residential IFW-Networks and Services.

•

The likelihood of saturation in the Femto radio interface may be low, so that

integration of Femto & WiFi may not be warranted.• Both Femto cells and WiFi share the same backhaul, so that transferring of

sessions between Femto & WiFi will not change the congestion on thebackhaul and therefore may not bring significant benefits.

•

MNOs have little control over ISP policy enforcement (e.g. prioritization ofcertain ISP services). So, value of interworking may be limited.

•

Most residential customer configure and manage their own WiFi devices, mostof which are off shelf units. In other cases, WiFi functions are integrated intosome DSL and Cable modems, which are typically managed by ISP.Successful leveraging of such devices by the MNO may be a concern.


16/42


Version: 033.06.01 12

3.2 Enterprise IFW-Networks

3.2.1 System View

Figure 3-7 Enterprise IFW-Network

Shown above is an abstracted system view of an Enterprise IFW-Network. TheEnterprise is covered by a network of IFW-Cells (as well as only Femto and/or only

WiFi cells, not shown in the figure). Typically, the Enterprise also has a WiFi Controller,as well as other entities mentioned in Section 3.3, which have been omitted here forthe sake of simplicity. The backend networks, such as Access Network, BroadbandNetwork etc, are similar to those discussed in Section 4.1.

3.2.2 Operational Scenarios

Depending on the size and nature of the Enterprise, two distinct deployment scenariosare possible, as discussed at the beginning of Section 4. They are:

E1) Enterprise Femto Network (EFN) managed by MNO & Enterprise WiFi Networkmanaged by Enterprise

E2) Enterprise Femto Network (EFN) & Enterprise WiFi Network managed by MNO

Of these, Scenario E1 may be a more likely operational scenario, although the MobileNetwork Operator may offer integrated Femto/WiFi Device for enterprise customer.

While there is a great variety in the needs and requirements of wirelesscommunication networks of various Enterprises, it is common for many Enterprises tohave their own IT Departments, who need to monitor the performance of theirwireless networks and potentially respond to minor failures etc. Therefore, it issuggested that the Enterprise Femto Networks provide some extent of visibility intotheir provisioning and management aspects. It is also suggested that the provisioningand management of the WiFi Network be left to the customer.


17/42


Version: 033.06.01 13

An important aspect of Enterprise IFW-Networks is the complementary radio coverageprovided by the Femto and WiFi Cells. It is suggested that Femto/WiFi link budgets beoptimized for coverage and service purposes.


As more and more Enterprise users use SmartPhones, Tablets etc, which have bothCellular and WiFi capability, Enterprise IFW-Networks have the potential benefit ofenabling the users to optimally use both radio services for voice, email, messaging,

database access and other data communication. In addition, LIPA services may be ofparticular benefit of IFW-Networks.

However, there are several challenges involved in such an integration process, someof which are listed below.

1. 3G Femto and WiFi may not provide same overlapping coverage due to linkbudget differences. This may be more evident for specific services, such as

3G voice vs. VoIP over WiFi2. Enterprise customers may have specific security requirements that can be

difficult for MNO to control. In particular, how the MNO Network works

together with the Enterprise Firewalls may be a technical and businesschallenge.

3. Enterprise customers prefer to manage the WiFi network by internal ITpersonnel. For example, Customer managed WiFi Network provides the

freedom for the customer to administer call admission control. Similarly, WiFidevice configurations are performed within the Enterprise over the Ethernetport via a web browser. Therefore, either remote configuration through aNetwork Management Device (located in customer premises) or localconfiguration via dual Ethernet ports may be required.


18/42


Version: 033.06.01 14

3.3 Metro IFW-Networks

3.3.1 System View

Figure 3-8 System view of an Exemplary Metro IFW Network

Shown above is an example of a Metro IFW-Network, where the metro-IFW-cellprovides Cellular and WiFi service in public environments, such as hotspots, cafes etc.Outdoor metro-IFW-cells are also possible, as indicated in the figure, although notelaborated in this discussion. The hotspot services 3G only or WiFi only or dual radiodevices (not shown in the figure). The WiFi controller is situated within the Broadbandnetwork beyond the Access Network, whereas the Femtos are managed by the Femto

Provisioning Server. Typically, the Femtos are managed by the 3GPP standardized TR-069 protocols, whereas the WiFi APs are managed by SNMP protocols. Since thebackhaul traffic traverses unsecured public access networks, secure tunnels are oftenused to bring the control and data traffic to the Mobile Core Network, althoughtypically Femtos use IPSec tunnels, whereas WiFi APs use GRE tunnels.

3.3.2

Operational Scenarios

As discussed in the beginning of Section 4, two operational scenarios were identified.They are:

M1) Femto/Pico & WiFi managed by a Single MNO

M2) Femto/Pico of Multiple MNOs with a shared WiFi (e.g. single radio with one ormore SSIDs) and likely provided by a Neutral Host

Some operators share the view that Operational Scenario M1 is the more likelyscenario.


19/42


Version: 033.06.01 15


Integration of Femto & WiFi in the Metro case is potentially beneficial because:

1. Metro Femto cells operate in open mode, so that the likelihood of saturation

in small cells is high, which in turn requires transfer of sessions to WiFi.4. Femto/Pico cell may be turned down deliberately to control interference,

whereas the WiFi range may be higher. So, staggered deployment ofFemto/Pico & WiFi may be advantageous in terms of coverage.

On the other hand, some challenges would need to be addressed for successfuldeployment of Metro IFW networks. They include:

1. 3G Femto/Pico and WiFi networks have different geographical deploymenttopologies. Specifically, 3G Pico/Femto Cells use regional aggregatedgateways, whereas WiFi networks use municipal aggregated WiFi NMDs.

5.

The tunneling protocols are different, namely IPsec for 3G Pico/Femto and

GRE for WiFi. Again, design should consider the trade-offs involved.6. Since the backhaul transport is shared, design should consider which

provisioning system defines the QoS policies, etc.

7. Similarly, provisioning protocols are different. 3G Pico/Femtos are based onTR-069 protocols, whereas WiFi networks are based on SNMP or proprietaryprotocols. An integrated provisioning platform would be desired for the longterm.


20/42


Version: 033.06.01 16

4. Service & Technology Aspects of IFW-Networks

In this section, we will address various Service and Technology aspects of IFW-

Networks, organized into three categories, which are the Provisioning & Management

aspects, Data & Traffic Flow aspects and Control & Policy aspects. The first categoryincludes the setting up, configuring, and operational management aspects. The secondcategory addresses managing of data flows between the Femto and WiFi radioaccesses, such as offloading, handover, etc. Finally, the last category deals withpolicies and control mechanisms needed for managing of the data flows.

We shall describe these in a manner that is applicable to all the deployment andoperational scenarios in general, making specific distinctions when necessary.

4.1 Provisioning & Management

4.1.1 Integrated IFW Provisioning

Because both Femto and WiFi technologies reside in the same IFW product,

provisioning process of the product can be a challenge and an opportunity. Typically,the two technologies are managed separately in residential and enterprise cases, theprovisioning could possibly be performed separately in this case. However, in a Metro

IFW product, the operator typically manages both Femto and WiFi, so that it may bedesirable to have a single provisioning process, at least in the long term. In such acase, it will also be desirable to have a single network management entity to managethe CM/AM/PM (Configuration Management/Alarm Management/PerformanceManagement) data for both technologies.

Currently, most enterprise and metro (public access) WiFi systems are managed bySNMP, whereas residential WiFi systems are managed by TR-069. Similar to

residential WiFi, Femto systems are also managed by TR-069, although using differentdata models for Femtos, namely, the combination of TR-098 IGD [5] and TR-196 datamodels [6] [7] [8].

Shown below is the current scheme, where the FAP and the WiFi AP are managedseparately.

Figure 4-1 Separate Management Protocols for FAP and WiFi

In a converged provisioning system, there are two possible schemes in terms of

interworking two management protocols depending on which protocol is preferred. The


21/42


Version: 033.06.01 17

interworking of SNMP and TR-069 involves creating mappings between SNMP MIB andTR-069 DM in order to carry necessary provisioning parameters over the otherprotocol. It is essentially a form of translation of one protocol parameter to another.

Note that this is an implementation dependent matter outside of the standardizedmechanism.

One possible scheme is to proxy the WiFi provisioning over TR-069 by mapping SNMPMIB to TR-069 DM. Figure on the left shows that the entire IFW device, including WiFi,is provisioned by the ACS over TR-069. The mapping function within the IFW device

translates the WiFi related parameters to the equivalent WiFi MIB. As one stepfurther, the WiFi provisioning can also be converted to TR-069 based DM. In thiscase, the WiFi portion supports the TR-069 DM natively. The following figureillustrates this mechanism.

Figure 4-2 Management Protocol Interworking – TR-069 Based Provisioning

Another possible scheme is to do the other way around; proxy the FAP provisioningover SNMP by

mapping TR-069 DM to SNMP MIB. In this case, the mapping function within the IFW

device translates the FAP related parameters to the equivalent TR-069 DM. As onestep further, the FAP provisioning can also be converted to SNMP based MIB. In thiscase, the FAP portion supports the SNMP natively. The following figure illustrates thismechanism.


22/42


Version: 033.06.01 18

Figure 4-3 Management Protocol Interworking – SNMP Based Provisioning

If either of the above schemes is adopted, then clearly the necessary parameterdefinition and mapping need to be established. It will be an implementation-dependent based definition.

4.1.2 TR-069 Data Models for Femto Configuration

TR-069 based IFW device configuration requires multiple Data Models (DMs). The

combination depends on the version of TR-196 being used. There are 3 versions ofTR-196, first two of which have been published already by BBF, and the last is to bereleased in the near future.

• TR-196 Issue 1 (Apr. 2009) [6]

•

Original publication that covers UMTS HNB•

TR-196 Issue 1 Amendment 1 (May 2011) [7] • Incremental update and change from Issue 1

• TR-196 Issue 2 (publication date TBD) [8] • Same update and change in Amendment 1•

Additional coverage of 2 new radio technologies (LTE HeNB andCDMA2000 FAP)

• Re-organization of the original TR-196 issue 1 structure

There are also other relevant DMs necessary for femto configuration. These DMs arecomplementary to one another and cover different areas (except TR-098 and TR-181).The summary of the relevant DMs are shown in the table below.

Specifically, it is worth noting that the “base” data models (i.e. TR-098 [5] and TR-181) [9] [10] already define WiFi related objects and parameters. They also includeextensive QoS mechanisms, such as traffic class, DSCP marking and handling, and

queuing definitions by using the appropriate objects and parameters defined in them.These existing QoS mechanisms can be utilized for IFW devices. If additionalcapabilities and functionalities are required above and beyond what is already definedin these base DMs, the suitable extensions can be defined. The following table showsthe relevant DMs.


23/42


Version: 033.06.01 19

Data Model Title Latest version Description Content

TR-098 “InternetGateway Device

Data Model forTR-069”

Issue 1,Amendment 3

(July 2011)

Old legacy datamodel for IGD

(e.g. DSL GWtype CPE

devices)

IGD root DM

TR-181 issue 1 “Device Data

Model for TR-069”

Issue 1,

Amendment 1(July, 2011)

Supersedes TR-

098

Combines TR-098

and TR-106 as a “Device” DM

TR-181 issue 2 “Device DataModel for TR-069”

Issue 2,Amendment 3(July. 2011)

Supersedes TR-098

Introduces themodular (stacked)interface model

TR-196 issue 1 “Femto Access

Point ServiceData Model”

Issue 1,

Amendment 1(May 2011)

covers original

UMTS FAP only

UMTS HNB DM

TR-196 issue 2 “Femto Access

Point ServiceData Model”

TBD adds LTE and

CDMA2000 inaddition toUMTS (RATspecific DM)

UMTS/LTE/CDMA2000

radio centric DM

TR-157 “ComponentObjects forCWMP”

Amendment 4(July 2011)

Non-femto-specific commonDM

SW module mgmt,FM

TR-262 “Femto

ComponentObjects”

TBD RAT

independentfemto-specificDM

Femtozone

application, GPS,Transport, PM

Table 4-1 Relevant Data Models for Femto Configuration

In TR-196 Issue 2, changes in the DM organization are introduced. Figure below

illustrates the changes made as TR-196 migrates from Issue 1 to Issue 2. The latterfocuses on the radio specific aspects, and other DMs (including newly introduced TR-262) cover non-radio aspects by taking over the relevant objects and parameters fromTR-196 Issue 1 version DM. This means that set of appropriate DMs need to beutilized depending on the version of TR-196 being used.


24/42


Version: 033.06.01 20

Figure 4-4 TR-196 Update after Issue 1

The following two figures show the possible DM combinations when using: 1) TR-196Issue 1 or Issue 1 Amendment 1, and 2) TR-196 Issue 2, respectively [5] [6] [7] [8] [9] [10] [11]. Note that there are multiple possible combinations for both cases.Which one to use is an implementation decision matter.

Figure 4-5 DM Usage for TR-196 Issue1 and Issue 1 Amendment 1


25/42


Version: 033.06.01 21

Figure 4-6 DM Usage for TR-196 Issue 2

The figure below are some of the examples of DM usage to configure a femtocell. It isequally applicable to IFW type devices as well as non-IFW type devices as well.

Figure 4-7 Example DM Usage for Femto Configuration


26/42


Version: 033.06.01 22

We conclude this section by mentioning that some amount of harmonization betweenFemto and WiFi data models as well as possible additional coverage of the WiFiaspects (e.g. CM/FM/PM), may be possible and useful in the long term.

4.1.3 Ongoing Work in 3GPP

Finally, we remark that 3GPP-SA2 has an ongoing work item called BBAI, whichtargets BBF and 3GPP interactions. Similarly, 3GPP-SA5 also is looking at FederatedNetwork Management for FMC, which may be relevant. Additional details on theseitems are included in a later section on IFW-Standards.

4.2 Data & Traffic Flow Management

In this section, we shall address various data flow management operations, that aremade possible by the integration of Femto and WiFi networks. These are organized asfollows:-

First, we shall describe Offloading, which is essentially using the WiFi networkwhenever available and/or based on certain criteria.

Then we shall describe handover of ongoing sessions from Femto to WiFi and possiblyvice versa, with session continuity and IP-address preservation. Next, we shall discussa finer granular version of the previous case, wherein individual IP-Flows may bemoved from one radio to the other, while keeping the remaining IP-flows intact.Clearly, such Flow-Mobility requires that both radios be on and are used for datacommunications simultaneously.

Next, we discuss the concept of Radio Link Aggregation, where the Femto and WiFi

links are essentially bonded together. In such a case, a single IP flow may be

communicated on such an integrated radio link, with IP-Packets being dynamicallyrouted across either of the two constituent radio links.

Finally, we describe a related traffic offloading solution, wherein the offloading occurswithin the network rather than on the radio interfaces. For example, LIPA refers to the

traffic meant for local IP-devices being routed locally instead of being sent to theMobile Core Network first. Similarly, SIPTO refers to traffic meant for public Internetbeing routed directly to the Internet instead of being sent to the Mobile Core Network

first. These may be viewed as network traffic routing optimization services andtechniques, that relieve the MNO’s networks of excessive loading.

4.2.1

Smart WiFi-Offloading

WiFi-Offloading refers to moving traffic from Femto Radio Interface to the WiFi RadioInterface and is powerful technique available to Mobile Network Operators to alleviatethe capacity crunch problem that many Mobile Networks are currently experiencing. Itis to be noted that WiFi offloading is different from Femto-Offloading, which refers to

moving traffic from Macro-Cells to Femto-Cells, in order to provide better signalcoverage, higher data rates and improved macro-cellular performance.

One of the user advantages of WiFi offloading is the potentially higher data rate overthe Radio Interface (although the broadband backhaul may not always support suchrates, thereby essentially limiting the end-to-end throughput). Secondly, not using the

licensed spectrum of the Femto cells reduces the overall interference to the macro-cellular network and can potentially improve the overall cell performance. This has to


27/42


Version: 033.06.01 23

be balanced against the greater control of handover and interference within a cellularnetwork.

Three important elements of WiFi-offloading are the discovery of the WiFi-APs,selection of the appropriate WiFi-AP and accessing the WiFi network. Discovery

information consists of the WiFi APs in the vicinity of the UE and Selection criteriaconsist of prioritized list of preferred radio accesses. Both these can be either pre-configured in the UE or be dynamically provisioned by the MNO, using the ANDSFprocedures. Finally, access to the WiFi network may be password-based (which

requires user intervention – at least for the first time) or based on the user’scredentials with the Mobile Network Operator (which would be seamless using theEAP-SIM protocol, for example).

The criteria for offloading may range from a simple availability of a WiFi hot spot to asophisticated dependence on several other factors such as user type, usage profile,traffic type, protocol type etc. For example, offloading policy may depend uponwhether the user has a Gold, Silver or Bronze subscription, or the user is nearing his

spending limit etc. Similarly, it may also depend upon whether the traffic is Video,Web Browsing, VoIP etc, or upon whether the protocol type is TCP, FTP, etc. Finally,the offloading decision may also depend upon the real time condition of the WiFiNetwork, such as congestion, throughput, etc.

The relevant 3GPP Standards are the IWLAN standards (TS 23.234) & EPC standards(TS 23.402). Dynamic provisioning of the discovery and selection information isstandardized in the ANDSF specification (TS 23.402 & 24.312).

4.2.2 Seamless Femto-WiFi Handovers

While the previous section on offloading focused on choosing WiFi networks tocommunicate in during idle mode, handovers refer to moving an active session fromFemto to WiFi radio and possibly vice versa. It is important that the IP address of theUE is preserved as the UE changes its point of attachment from one radio to the other,so that the session continuity can be achieved.

If no packets are lost during the handover, it is often referred to as lossless handoverand such a procedure generally involves buffering of packets and sending them from

source to target network during handover. This is often an implementation issue andnot necessarily part of the handover protocol.

Broadly speaking, there are two types of handover protocols at the IP level. They areHost-Based-Mobility (HBM) protocols and Network-Based-Mobility (NBM) protocols. As

the names suggest, HBM protocols are implemented in both the UE (i.e. host) and the

Network. NBM protocols, on the other hand, are implemented entirely in the Network,with only nominal support from the UE, which is usually a software layer called LogicalInterface. MIP, MIPv6, DSMIPv6 are examples of HBM protocols, whereas PMIP,

PMIPv6, GTP are NBM protocols. (in Network) , LIF-Logical Interface (in UE). DSMIPallows mobility across networks while maintaining IP address continuity and providesseamless data handover between 3G/4G and WLAN, by providing Make-before-breakmobility. DSMIP based solutions also support for legacy IPv4 network, since UE andHome Agent (HA) support IPv4 and IPv6. Figure below shows the various options.


28/42


Version: 033.06.01 24

Figure 4-8 Seamless Handovers using HBM/NBM protocols

Basic Handover procedures are standardized by 3GPP in the IWLAN specifications (TS23.327) & EPC specifications (TS 23.402). WiFi mobility with DSMIP is supported in3GPP Release 8 and was specified for EPC &UMTS/GPRS core networks. Correspondingpolicies are standardized in the ANDSF specifications as ISMP (TS 23.402). These arefurther described in a later section on standards.

4.2.3 Simultaneous Femto-WiFi Flow Management

The previous sections required that the UE has connection with a single radio, eitherFemto or WiFi, at any given time. If the UE can support simultaneous connections

across both Femto and WiFi links at the same time, additional functionalities arepossible.

One such functionality may be called ‘Flow Segregation’, which consists of sendingdifferent types of application flows across the most appropriate radio access networks,

where the appropriateness can be defined in terms of bandwidth, cost etc. Forexample, the figure below shows a case where http traffic and 3rd party applicationflows are sent across the WiFi link, whereas VOIP traffic is sent over 3G/LTE network(which may also be a Femto network).

Figure 4-9 Flow Segregation across Cellular (Femto) & WiFi radio links


29/42


Version: 033.06.01 25

Another functionality is referred to as ‘Flow Mobility’, which consists of movingindividual application flows from one radio link to the other, while keeping the rest ofthe flows where they are. In the above example, suppose that the WiFi radio link is

experiencing increased interference and hence reduced throughput. The ‘http trafficflow’ can, for example be moved across to the 3G/LTE radio link, while keeping the

3rd party application flow still on the WiFi link.

Finally, a single application flows may be split into two sub-flows and sent across bothFemto and WiFi radio links simultaneously, resulting in what may be called as ‘Flow

Aggregation’. Such a scheme has multiple benefits, such as increasing the overallbandwidth for demanding applications such as HD Video, balancing the load acrosstwo radio links dynamically and providing fail-safe radio connections (sincecommunication can continue on the surviving radio link even if one link fails). This

may also be viewed as an aggregation of multiple radio links, as opposed toaggregating multiple sub-flows.

As in the case of Seamless Handovers, these functionalities can also be implemented

by either Host Based Mobility (HBM) protocols or Network Based Mobility (NBM)protocols, with suitable extensions. For example, the extensions needed for DSMIP(i.e. HBM) protocol are: (1) ability to register with dual care-of-addresses; and (2)binding a flow with a certain care-of-address.

Figure 4-10 Simultaneous Cellular (Femto) & WiFi Flow Management using DSMIP

IP flow mobility with DSMIP is supported in 3GPP Release 10, which is based onregistration of multiple CoAs for a given HoA and binding different IP flows to differentCoAs or directly to HoA. Other mobility scenarios based on PMIP are also defined in3GPP (S2a, S2b).

Corresponding extensions to the Policy aspects are captured as PCC Extensions in3GPP TS 23.261 and ANDSF extensions (namely ISRP) in 3GPP TS 23.402.

Flow splitting and aggregation is a more recent activity in various standardizationbodies, including 3GPP (standards contribution S2-105592), IETF (MPTCP RFC 6182)and ITU-T (SG13/Q9 on Multi Connections).

4.2.4 LIPA & SIPTO for Network Offloading

The discussions in the previous sub-sections dealt with management of traffic over theFemto and WiFi radio links. Network congestion can also happen due to traffic in thebackhaul and core networks, and LIPA and SIPTO are two offloading solutions for the


30/42


Version: 033.06.01 26

network traffic. They are based on the observation that not all traffic needs to traversethe MNO’s core Network.

First example is a UE communicating with a Device within the local IP network, towhich the Femto AP is also connected to. Clearly such traffic need not go to the MCN

and return to the local IP network, and a direct connection would be efficient. A 3GPPstandardized mechanism to facilitate this is called LIPA (Local IP Access).

The second example is traffic originating or terminating within the public Internet.Again, such traffic need not traverse the MCN and can be offloaded either at thefemtocell or within the broadband backhaul network or at the entrance to the MCN.

These schemes are standardized by 3GPP as SIPTO (Selective IP Traffic Offload), withthe first two cases being Femto-SIPTO and the final case being Macro-SIPTO.

Clearly, Femto-SIPTO requires that the broadband backhaul network is either alsomanaged by MNO or that there is a business relationship between the MNO and thebroadband network operator. The figure below depicts the case of LIPA and Femto-

SIPTO.

Figure 4-11 Illustration of LIPA & SIPTO Concepts

It can be foreseen LIPA/SIPTO will play a significant role in IFW devices, especially ifLIPA/SIPTO data traffic becomes free of charge just like WiFi because LIPA/SIPTO use

little 3G core network resources. For example, one can think of WiFi-based LIPA &SIPTO and various ways of integrating with the Femto-based LIPA & SIPTO. Someexamples are provided below:

• Residential-IFW scenarios: Handovers between Femto-LIPA/SIPTO and WiFi-LIPA/SIPTO could make sense, for example, to counter WiFi interference orfor power savings. Secondly, Femto-LIPA/SIPTO and WiFi-LIPA/SIPTO can beintegrated for Bandwidth Aggregation and WiFi Interference mitigation.

• Metro-IFW scenarios: An interesting possibility in this scenario is local

communication between a Femto-UE and WiFi-UE, using Femto & WiFi LIPAconnections.


31/42


Version: 033.06.01 27

It is encouraged that such innovative solutions be explored for development as well asfor standardization.

4.3 Control Plane Aspects

Traditional approaches to control the usage of the radio interface (such as QoSparameters, handovers etc) are entirely network based, which work well in fullyplanned networks such as macro cellular networks. A natural approach for unplannednetworks such as WiFi networks is to place the control in the hands of the user (sincethe UE is best aware of its network neighbourhood). Yet, if operators are to use WiFias part of their service offering, it is necessary that operators are in control of how theradio resources are managed also. In order to do this, a mechanism is needed to

provide operator’s policy for unplanned networks to the user devices in a dynamicfashion. Secondly, the user device must have algorithms to detect characteristics ofthe unplanned WiFi networks and use the WiFi service as per the Operator policy.

3GPP has standardized such a policy framework via the ANDSF, which allows the

Operator to define and modify policies for the following steps:

• WiFi discovery (i.e. Information for assisting discovery of access networks

available in the vicinity of the UE)• Policies for WiFi Offload (ISMP = Inter System Mobility Policy)

•

Policies for Simultaneous Femto/Cellular & WiFi Management (ISRP = InterSystem Routing Policy)

Discovery Information:Discovery information can be used to assist the UE in efficient discovery of accessnetworks around the validity area. For Wi-Fi, the access network information includesWi-Fi SSID, whether the access point is hidden, whether the Wi-Fi operation is in

infrastructure or adhoc mode, and the security modes (e.g., 802.1x or WPA2) andkeys.

Inter-System Mobility Policy (ISMP)ISMP allows operators to configure multiple rules on the UE to make a decision onwhich access technology (e.g., cellular or Wi-Fi), and access network to prioritize foraccess in a validity area. The validity area is defined by (i) the PLMN, TAC/LAC, orCELL_ID of the cellular network, (ii) Wireless LAN SSID, or (iii) the geolocation of theUE. The operator may also assign the time of the day where a rule may take effect.The operators may also prevent selection of an access technology by the UE.

Inter-System Routing Policy (ISRP):

ISRP allows operators to configure multiple rules on the UE to make a decision on

which access technology should be used for transporting each packet. There are threetypes of ISRP rules:

• Seamless Offload rules – there are two types of rules in this category• IP Flow Mobility (IFOM) rules – these rules can be used to specify the

interface to be used when a traffic flow is classified using source anddestination IP addresses and ports. The criteria for routing the packetsmay also be based on time of day, validity area and also the Access Point

Name (APN) of the current network.• Multi Access PDN Connectivity (MAPCON) rules – these rules are similar

to IFOM but the traffic flow is routed based on the APN being usedinstead.


32/42


Version: 033.06.01 28

• Non-seamless Offload rules – these rules are similar to IFOM except thatthese rules are applied when there are no IP session continuity support.

These policies are contained in an ANDSF Management Object, whose structure isshown below.

Figure 4-12 Structure of ANDSF Policy Management Object

Figure below shows the ANDSF architecture and how policies are pushed to the UE bythe Network. Briefly, the policies are stored in the ANDSF Management Objects (MOs)which are stored in an ANDSF Server and the UE. The MOs can be dynamicallymodified and synchronized using OMA-DM protocols.

Figure 4-13 Dynamic Operator Policy Provisioning using ANDSF

The above discussion generally applies to the case where the Cellular and WiFi APs arenot necessarily collocated. In the IFW-Networks, the APs are generally located in thesame physical entity, which can be used advantageously in the policy procedures.

Recommendation:In the IFW framework, it is reasonable to assume that the Wi-Fi coverage area andcellular coverage area of IFW will be mostly overlapping. Therefore, the operators

should be able to use the discovery of cellular mode on femtocell as a reliable triggerto discover Wi-Fi (using Discovery Information in ANDSF) and start offload.

For Metrocells (with integrated WiFi), operators could be assigned a dedicated

TAC/LAC to these small cells to minimize “ValidityArea” configuration for ISMP,


33/42


Version: 033.06.01 29

Discovery & ISRP policies. This eliminates the need and complexity for per-cellconfiguration and standby time impact of using geographical information.

4.4 Architectural & Implementation Aspects

The actual architectures for IFW-Networks will no doubt depend upon the specificdeployment and operational scenario. However, there are some key aspects that arecommon to all scenarios. We shall discuss those in this section.

To varying degrees, the integration of Femto and WiFi will impact both the UE and theNetwork. Smart offloading guided by Operator policies would imply that the UE should

support some form of Connection Manager that orchestrates the WiFi offloading andpossibly LIPA processes, whereas some form of a Policy Client would be needed forOperator policies. The latter could be an ANDSF client. Advanced functionalities, such

as Seamless Handovers and Simultaneous Femto-WiFi Flow Management wouldrequire some form of DSMIP client for Host-Based-Mobility approach or LogicalInterface for Network-Based-Mobility approach.

The impact on the network is somewhat more involved, because multiple options couldexist, especially for Seamless Handovers and Simultaneous Femto-WiFi Flow

Management. Such IFW functionality would reside in one of the network nodes. Anatural choice is the GGSN in the UMTS Core Network or PGW in the EPC CoreNetwork, as suggested by the 3GPP standards. The figure below shows a simplifiedfunctional architecture.

Figure 4-14 Core Network based IFW-Function

The Femto & WiFi capable UE connects to Femto-AP and WiFi-AP (either

simultaneously or one at a time, depending upon the capability). The two APs arecollocated in an IFW-environment, possibly in the same physical form factor. ThisIFW-AP connects to a Broadband Modem and further into the Mobile Core Network inparallel via the Femto path and the WiFi-path.

The Femto-path consists of a Femto Gateway (FGW), an SGSN and a GGSN (for a

UMTS Core Network). A Traffic Offload Function may be present between the FGW andthe SGSN, in order to offload Internet-bound traffic from traversing the Core Network.Similarly, Internet-bound traffic may also be offloaded directly from the Broadband IP

Network (BBIPN), along the Femto-SIPTO path.


34/42


Version: 033.06.01 30

Similarly, the WiFi-path consists of a Tunnel Terminating Gateway (TTG) whichbasically allows a secure IPSec tunnel to be established between the UE and the TTGover the un-trusted (from the MNO perspective) Broadband IP Network. The traffic

emanating from the TTG towards the Core Network can be routed towards the GGSNand onwards to the Operator Services network. If this traffic turns out to be Internet-

bound, then it can be diverted at a Traffic Offload Function and offloaded to Internetdirectly.

For the sake of completeness, the figure also shows the LIPA configuration, where a

Local Gateway (LGW) at the IFW-AP premises diverts the local traffic towards the localIP Network. In addition, the IFW-AP may also be configured for local Femto (or IFW)Services. Such services frameworks as well as necessary APIs are currently beingdeveloped by the FemtoForum’s Service Special Interest Group (SSIG).

The key element for the IFW-Networks is the GGSN, which is the network node wherethe Femto and WiFi network paths converge. Accordingly, GGSN is the network nodewhere the Femto-WiFi integration functions would reside. These include Home Agent

Functionality in case of DSMIP-based Seamless Handovers as well as Flow-Management. Alternately, in case of PMIP based implementation, the Femto-WiFiintegration function includes Local Mobility Agent (LMA) functionality. In this case, theadditional functionalities, namely Mobility Anchor Gateways (MAGs) need to be alsoimplemented in the network (e.g. in the FGW and TTG). In any case, we shall refer to

such functionalities resident in the GGSN as IFW-Function, and are marked as such inthe figure.

While the figure is based on UMTS Core Network, similar architectures are possible forEPC Core Network as well.

AP-based IFW-Functionality:The architecture depicted in the previous figure, wherein the IFW-GW functions reside

deep in the mobile core network is a natural and probably the only feasible choice formacro-cellular and WiFi integration, when the Cellular Base Station and WiFi AP aregeographically separated and not collocated. Indeed, this is the typical configurationassumed when the IWLAN or the EPC standards for Non-3GPP access were written.However, in the case of an IFW-Network, the Femto and WiFi APs are collocated, sothat the IFW functionality could potentially be located in or near the collocated IFW-APitself. This may be viewed as an edge-based IFW-architecture and could be attractive

to the Operators, since the IFW-related signalling no longer has to travel to the CoreNetwork! This variant architecture is shown below, where the IFW-GW functionality islocated in the IFW-premises.


35/42


Version: 033.06.01 31

Figure 4-15 Edge based IFW-Function

FGW-Based IFW-Functionality:Finally, a third architectural alternative is when the IFW-GW functionality can reside in

the Femto-GW, which is also integrated with WiFi-Gatweays, namely TTG & PDG. (Inthe case of EPC, this would be ePDG node). This architecture is depicted in the figurebelow.

Figure 4-16 Gateway based IFW-Function

Implementation Aspects: Finally, we consider the implementation of an IFW-AP. It isimportant to identify what information needs to be available from each AP to the otherAP, in order for efficient and intelligent implementations to be possible. Subsequently,it will be also important to define APIs for exchange of such information, and so that

interoperability may be achieved between different individual AP implementations. It issuggested that such a study be taken up as a follow-on to the current IFW-activity.


36/42


Version: 033.06.01 32

5. Standards

5.1 Current and Ongoing 3GPP Standards Activity

The basic standards describing the interworking of 3GPP cellular (macro) networks andWLANs are TS 23.234, whereas handover procedures based on DSMIP protocols were

standardized in TS 23.327. Finally, IP Flow Mobility across simultaneous cellular andWLAN connections was standardized in TS 23.261, again based on extensions ofDSMIP protocols. This set of standards assumed a UMTS Core Network and arecollectively referred to as I-WLAN standards.

The definition of the Evolved Packet Core (EPC) included non-3GPP access as an

integral part of the EPC specification, namely TS 23.402. This specifies the proceduresfor accessing EPC via WLAN access networks, which were originally treated asUntrusted Networks. Both DSMIP and PMIP were addressed, and seamless handoversas well as IP Flow Mobility were also described. Subsequently, GTP-based procedures

were also included.

We shall now detail the various work items and how they resulted in the abovestandards as well as some new work items that are further advancing the WiFi accessto EPC core networks. We first recollect the EPC architectures, based on S2a & S2b(for PMIP) and S2c (for DSMIP) interfaces.

Figure 5-1 EPC Architecture with S2a & S2b (for PMIP) based protocols)


37/42


Version: 033.06.01 33

Figure 5-2 EPC Architecture with S2c interface (for DSMIP based protocols)

The figure below shows the rather involved set of work items related to WiFi access.

Figure 5-3 3GPP Work Items related to WiFi access

MUPSAP stands for “Multiple Connections to the Same PDN for PMIP based Interfaces(i.e. S2a, b)” and was a Release 9 work item. The original SAE architecture wasmodified to enable establishment and disconnection of multiple PDN connections to thesame APN uniformly across the EPS from any access as well as handover of multiplePDN connections to the same APN across the EPS between two accesses.

MAPIM was a study on “Multi Access PDN connectivity and IP flow mobility”, which wasthe first attempt to really handle multiple access UEs (3GPP and non-3GPP). It startedin Rel-9 and led to the spin-off of two separate work items, MAPCON and IFOM. The

work item studied the means to enhance the EPC and I-WLAN Mobility systems tosupport: (1) accessing a PDN simultaneously via a 3GPP and a non 3GPP accesssystem; (2) operator policies for guiding and configuring the UE IP flow routing via

different access systems; (3) dynamic movement of PDN IP flows between access


38/42


Version: 033.06.01 34

systems; and (4) 3GPP-Non3GPP handovers when UE is connected to different PDNsvia different accesses (EPC only). The MAPIM effort produced TR 23.861 but laterabandoned after MAPCON and IFOM spun-off.

IFOM work item dealt with “IP Flow Mobility and seamless WLAN Offload” and was a

Rel-10 Work Item. It looked at seamless WLAN offload as well as interactions betweenPCC and ANDSF architectures. It came up with solutions based on extensions to S2cand H1 interface and using DSMIPv6 protocol. To achieve IP flow mobility the inter-system mobility signalling is enhanced in order to carry the routing filter. In terms of

IP-addressing, when a UE configures different IP addresses on multiple accesses, itcould register these addresses with the HA as CoAs using multiple bindings asspecified in IETF RFC 5648. The work item produced specifications 23.261 (Stage 2),and changes to others (22.234, 24.302, 23.402, 24.234, 24.327,…).

MAPCON was a Rel-10 work item and resulted in TS 22.278. The motivation for thiswork item was that a (Rel-9) UE can connect to one PDN over a 3GPP access and asecond PDN over a non-3GPP access, but handovers between the accesses in are not

described in Rel-9. A restriction was that the work would only address a single non-3GPP access.

The figure below shows the similarities and differences between MAPCON & IFOM.

Figure 5-4 Similarities and differences between MAPCON and IFOM

SMOG was a Release 10 work item that investigated S2b Mobility based on GTP. Itresulted in some modifications to 23.402.

SaMOG was a continuation of the SMOG work item and is currently being studied in

3GPP SA2. It represented a study on S2a Mobility based On GTP & Trusted WLANaccess to EPC. (Note that currently S2a is based on GRE Tunnels and PMIPv6.)Specifically, the Study Item will develop stage 2 message flows to support S2a basedon GTP and mobility between GTP-S5/S8 and GTP-S2a.

This work item could be potentially very relevant to IFW since it could move toallowing a common tunnel backhaul, as shown in Figure below.


39/42


Version: 033.06.01 35

Figure 5-5 Integrated Femto & Trusted WiFi with a common backhaul

ANDSF (Access Network Discovery & Selection Function) framework has been

enhanced in Rel-10 with the introduction of Inter System Routing Policies (ISRP),allowing the operator to provide policies based on the traffic exchanged by the UE, toaccommodate MAPCON and IFOM. Presently, a new work item eANDSF is in progress,with potential impacts to TS 23.402.

OPIIS stands for “Operator Policies for IP Interface selection” and is a Release-11Work/Study Item, resulting in TR 23.853. It defines operator policies for selecting anIP interface in the UE. It also examines the system architecture to get those policies tothe UE, with the intent to use the ANDSF architecture wherever possible.

DIDA stands for “Data Identification in ANDSF” and is a Release-11 work item. To take

account of MAPCON, IFOM etc, ANDSF has been enhanced with the introduction of

Inter System Routing Policies (ISRP), allowing the operator to provide policies basedon the traffic exchanged by the UE. An ISRP can be based on, (1) PDN identifier (i.e.APN) the UE uses for a given connection; (2) The destination IP address the UE sendstraffic to; (3) The destination port number the UE connects to; or (4) A combination ofthe three elements above. However, recent years have seen a trend where differenttypes of traffic are often aggregated into few transport ports. This impacts the

applicability of ANDSF policies and the ability for the operator to specify how trafficshould be routed. For example, the operator with the current framework is not able todiscriminate between video streaming (e.g. www.youtube.com) and web browsing(e.g. www.google.com). As such, the work will look at additional ways to identify

classes of traffic a ISRP applies to. Extensions to the ANDSF MO will be developed toconvey these additional ways over S14.

LOBSTER stands for “Location Based selection of gateways for WLAN” and is a Release11 Work Item. The rationale for this work item is the following. Note that the WLAN

Access to EPC with IP address continuity has been defined in Release 8 and thenextended in Release 10 with IFOM and MAPCON. However, the current ePDG selectionin TS 23.402 has not considered the UE location as well as the proximity to the PDNGW, so the routing from the UE to the ePDG may not be optimized. Similarly, the PDN

GW selection in S2b and S2c cases has not considered the UE location. There istherefore a need to improve the ePDG and PDN-GW selections based on the location ofthe UE for the WLAN Access to EPC in S2b and S2c cases. This work item aims tospecify enhancements to the ePDG and PDN GW selection functions for S2b and S2cbased on UE location.


40/42


Version: 033.06.01 36

BBAI is an ongoing Release 11 work item and it stands for Broadband AccessInterworking. Currently, the Broadband Network through which the Iuh and S1interfaces are carried is considered essentially as a black box, so that there are no

QoS and policy controls for the transport through the Broadband Network. This workitem seeks to develop interworking standards between the Broadband Network and

the 3GPP Core Network for the purposes of QoS, Policy Control, Authentication, Billingetc. This work has a number of contributory Building Blocks at varying levels ofcompletion; Building Block I focuses on BBF Interworking with Home routed traffic forWLAN and H(e)NB, Building Block II focuses on interworking with offload in the accessnetwork for WLAN and H(e)NB, whilst Building Block III is targeted at convergence

and network based mobility. The work includes collaboration workshops with theBroadband Forum, and of necessity any modifications to both organisations’specifications will need to result in a ‘win-win’ situation.

VINE is a 3GPP Work Item that deals with “Voice Interworking with Enterprise IP-PBX”and as such may be relevant to Enterprise IFW-Networks. The work resulted fromoperator interest in supporting voice service interworking between 3GPP networks and

Enterprise environments and was started in May, 2010. The initial study conducted athorough analysis of related standardization (e.g., TISPAN, ECMA) and proposedrequirements. A Reference Model generated, and the architecture studies areunderway in SA2.

5.2 Relevant BBF Standards

BBF standards are the foundation of IFW device provisioning system. TR-069 is the de

facto protocol for the provisioning system and TR-196 defines 3G and LTE Femto datamodel which contains necessary RF parameters, Device Parameter, Time and locationparameters, QoS and Policy parameters and transport (IPsec) parameters.

TR-98 defines Device Component Objects for CWMP which can apply to WiFi functions.While TR-98 defines WiFi objects in a reasonably comprehensive manner, theapplicability is mainly for Residential scenarios, where the WiFi functions andprovisioning is believed to be managed by customers. However, Enterprise and MetroIFW scenarios may require data model extensions to current TR-98 in order to enableremote provisioning process for IFW devices in these scenarios.

5.3 Relevant IETF Standards

IPSec is the security protocol suite for Femto cell Iuh interface. Following list provides

a few of IPsec protocols (Encryption, Authentication and Integrity, Encapsulation ofpacket and IKE exchanges) :

RFC 2404 The use of HMAC-SHA-1-96 within ESP and AHRFC 3602 The AES-CBC Cipher Algorithm and Its Use with IPsecRFC 3715 IPsec Network Address Translation (NAT) compatibility Requirements

RFC 3948 UDP Encapsulation of IPsec ESP PacketsRFC 4301 Security Architecture for the Internet ProtocolRFC 4393 IP Encapsulating Security PayloadRFC 4306 Internet Key Exchange (IKEv2) ProtocolEtc.


41/42


Version: 033.06.01 37

6. Conclusions

This white paper provided a comprehensive overview of various aspects of Integrated

Femto-WiFi Networks, including Business and Technical aspects. It also discussed

relevant standards activities.

While the document provided an overall framework of IFW-Networks, it isrecommended that future investigations should focus on specific areas, such as JointProvisioning methods, Policy matters that take into account integrated Femto-WiFi

products, edge-based Femto-WiFi integration techniques etc., possibly resulting inspecific requirements for IFW-products and services.


42/42

References

1 Femto Forum White Papers, http://femtoforum.org/fem2/resources.php?id=194

2 S. Saunders et al, “Femtocells: Opportunities and Challenges for Business andTechnology”, Wiley 2009.3 J. Zhang and G. de la Roche, “Femtocells: Technologies and Deployment”, Wiley

20104 3GPP Standards on HNB and HeNB: TS 22.220 (Service Requirements for Home

NodeBs and eNBodeBs); TS 25.467 (UTRAN Architecture for 3G Home Node B),TS 25.367 (Mobility Procedures for Home Node B); etc.

5 Broadband Forum, TR-098 Issue 1 amendment 2, “Internet Gateway Device DataModel for TR-069” Sept. 2008.

6 Broadband Forum, TR-196 Issue 1, “Femto Access Point Service Data Model”, Apr.2009.

7 Broadband Forum, TR-196 Issue 1 Amendment 1, “Femto Access Point ServiceData Model”, May 2011.

8 Broadband Forum, TR-196 Issue 2, Revision 06 (Straw Ballot), “Femto AccessPoint Service Data Model”, June 2011

9 Broadband Forum, TR-181 Issue 1, “Device Data Model for TR-069”, Feb. 2010.10 Broadband Forum, TR-181 Issue 2 Amendment 2, “Device Data Model for TR-

069”, Feb. 2011.

11 Broadband Forum, TR-157 Issue 1 Amendment 3, “Component Objects forCWMP”, Nov. 2010.
http://femtoforum.org/fem2/resources.php?id=194http://femtoforum.org/fem2/resources.php?id=194http://femtoforum.org/fem2/resources.php?id=194http://femtoforum.org/fem2/resources.php?id=194

033-integrated femto-wifi networks white paper

Documents