Integrated Femto-WiFi (IFW) Networks

Document Sample
Integrated Femto-WiFi (IFW) Networks Powered By Docstoc
					Integrated Femto-WiFi
(IFW) Networks




Published 28 February 2012




Small Cell Forum Ltd   Tel: +44 (0)845 644 5823
PO Box 23              Fax: +44 (0)845 644 5824          © Small Cell Forum Ltd
GL11 5WA               Email: info@smallcellforum.org    (formerly Femto Forum Ltd).
United Kingdom         website: www.smallcellforum.org   Registered in the UK no. 6295097
The Small Cell Forum, formerly known as the Femto Forum, supports
the wide-scale adoption of small cells.

Small cells are low-power wireless access points that operate in licensed
spectrum, are operator-managed and feature edge-based intelligence. They
provide improved cellular coverage, capacity and applications for homes and
enterprises as well as metropolitan and rural public spaces. They include
technologies variously described as femtocells, picocells, microcells and
metrocells.

The Small Cell Forum is a not-for-profit, international membership
organisation, with membership open to providers of small cell technology and
to operators with spectrum licences for providing mobile services.

The Forum has 137 members including 63 operators representing more than
1.71 billion mobile subscribers – 33 per cent of the global total – as well as
telecoms hardware and software vendors, content providers and innovative
start-ups.

The Forum has three main aims:

      •     To promote adoption of small cells by making available information to
            the industry and the general public;
      •     To promote the rapid creation of appropriate open standards and
            interoperability for small cells;
      •     To encourage the development of an active ecosystem of small cell
            providers to deliver ongoing innovation of commercially and
            technically efficient solutions.

The Forum is technology agnostic and independent. It is not a standards
setting body, but works with standards organisations and regulators worldwide
to provide an aggregated view of the small cell market.




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

Email info@smallcellforum.org

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

Member Services Lynne Price-Walker lynne@smallcellforum.org

For a full list of members and further information visit our website
www.smallcellforum.org




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published
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 .................................................................... 2
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 ......................................................... 7
3.1.3       Benefits, Challenges & Concerns ......................................... 10
3.2         Enterprise IFW-Networks ................................................... 11
3.2.1       System View .................................................................... 11
3.2.2       Operational Scenarios ....................................................... 11
3.2.3       Benefits, Challenges & Concerns ......................................... 11
3.3         Metro IFW-Networks ......................................................... 12
3.3.1       System View .................................................................... 12
3.3.2       Operational Scenarios ....................................................... 13
3.3.3       Benefits, Challenges & Concerns ......................................... 13
4.          Service & Technology Aspects of IFW-Networks .......... 14
4.1         Provisioning & Management ............................................... 14
4.1.1       Integrated IFW Provisioning ............................................... 14
4.1.2       TR-069 Data Models for Femto Configuration ........................ 15
4.1.3       Ongoing Work in 3GPP ...................................................... 19
4.2         Data & Traffic Flow Management......................................... 19
4.2.1       Smart WiFi-Offloading ....................................................... 19
4.2.2       Seamless Femto-WiFi Handovers ........................................ 20
4.2.3       Simultaneous Femto-WiFi Flow Management ........................ 20
4.2.4       LIPA & SIPTO for Network Offloading ................................... 22
4.3         Control Plane Aspects ........................................................ 23
4.4         Architectural & Implementation Aspects ............................... 24
5.          Standards ...................................................................... 27
5.1         Current and Ongoing 3GPP Standards Activity ...................... 27
5.2         Relevant BBF Standards .................................................... 30
5.3         Relevant IETF Standards.................................................... 30

Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published
6.    Conclusions ................................................................... 32
References ............................................................................... 33


Tables
Table 1-1         Abbreviations ................................................................................. 1
Table 4-1         Relevant Data Models for Femto Configuration .................................. 16

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 ................................................................ 6
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 ........................................ 8
Figure 3-5        Operational Scenario R3: MNO Double Play (Variant) ........................... 9
Figure 3-6        Operational Scenario R4: MNO Single Play ......................................... 9
Figure 3-7        Enterprise IFW-Network ................................................................ 11
Figure 3-8        System view of an Exemplary Metro IFW Network ............................. 12
Figure 4-1        Separate Management Protocols for FAP and WiFi ............................. 14
Figure 4-2        Management Protocol Interworking – TR-069 Based Provisioning ........ 15
Figure 4-3        Management Protocol Interworking – SNMP Based Provisioning ........... 15
Figure 4-4        TR-196 Update after Issue 1 .......................................................... 17
Figure 4-5        DM Usage for TR-196 Issue1 and Issue 1 Amendment 1 .................... 17
Figure 4-6        DM Usage for TR-196 Issue 2 ......................................................... 18
Figure 4-7        Example DM Usage for Femto Configuration ..................................... 18
Figure 4-8        Seamless Handovers using HBM/NBM protocols ................................ 20
Figure 4-9        Flow Segregation across Cellular (Femto) & WiFi radio links ................ 21
Figure 4-10 Simultaneous Cellular (Femto) & WiFi Flow Management using DSMIP . 21
Figure 4-11 Illustration of LIPA & SIPTO Concepts .............................................. 22
Figure 4-12 Structure of ANDSF Policy Management Object ................................. 24
Figure 4-13 Dynamic Operator Policy Provisioning using ANDSF .......................... 24
Figure 4-14 Core Network based IFW-Function .................................................. 25
Figure 4-15 Edge based IFW-Function .............................................................. 26
Figure 4-16 Gateway based IFW-Function ......................................................... 26
Figure 5-1        EPC Architecture with S2a & S2b (for PMIP) based protocols) ............. 27
Figure 5-2        EPC Architecture with S2c interface (for DSMIP based protocols) ......... 28
Figure 5-3        3GPP Work Items related to WiFi access .......................................... 28
Figure 5-4        Similarities and differences between MAPCON and IFOM .................... 29
Figure 5-5        Integrated Femto & Trusted WiFi with a common backhaul ................. 29




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published
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 integrated Femto and WiFi products strategy, in order to provide dual air-interface
support for smart 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 technology
      2.    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 WiFi
      4.    Drive scale of economics of integrated Femto and WiFi devices and services
      5.    Lower cost of installation and ease of deployments for mobile operators to have single
            installation process and savings of installation materials. This is especially true on enterprise
            network and public hotspot services.
      6.    Set the foundation for traffic load management over multiple air interface technologies 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 in residential, 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 and requirements.

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-WiFi
ISP                     Internet Service Provider
MNO                     Mobile Network Operator
NMD                     (WiFi) Network Management Device
OSS                     Operations Support System
SSID                    Service Set Identifier
Table 1-1         Abbreviations




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          1
2. Background

In this section, we shall briefly describe the technologies on which IFW-Networks and Services 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 is powered by a Femto-
Access-Point (FAP, also referred to as HNB or HeNB in 3GPP literature) and provides Operator provided
voice & data services as well as public Internet 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 the Mobile
Operator’s Core Network and Service Cloud via the Internet. The broadband access is typically provided by
an ISP, who may or may not be the same as the Mobile Network Operator. The FemtoCells are managed by
special FemtoCell Management systems, which are integrated into the overall Network Management System
of the Mobile Network Operators, as shown in Figure-1.

As is well known, there are several advantages of FemtoCells, which can be broadly classified 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 enable higher average data rates compared to MacroCells. They also offload user traffic from
wide coverage area macrocells to smaller coverage area FemtoCells, thereby potentially leading to better
utilization of the operator’s spectrum. Furthermore, they also allow offloading of Internet bound traffic
directly to the Internet without traversing 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 the FemtoForum [1], popular
books [2], [3] and Standards [4].

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 the various players in this value chain and their
inter-relationships.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                        2
Figure 2-2        Internet Access via WiFi Networks

Internet Service Provider (ISP) is the main player in this ecosystem, who has the commercial relationship
(usually a long term contract) with end customer. The ISP provides 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 can provide 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 WiFi service providers. They
also manage roaming relationships.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                         3
Figure 2-3        Internet Access via Residential WiFi Networks

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

ISPs can unbundle at the exchange or use wholesaler to provide connectivity between exchange and ISP
networks. ISPs also have service LANs that provide additional Internet services (e.g. email, IPTV), legal
intercept services etc. ISP policy is also applied 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 system architecture and procedures,
in the WiFi world, IEEE 802.11 and WFA do not specify an end-to-end architecture. However, through
common industry practices, vendors have 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 Up to 300 Mbps are enabled.

Outdoor Access Points are typically deployed to provide 802.11b/g client access, while 802.11a links are
used for backhaul. The Access points are either Standalone or configured 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 for connecting peripheral devices.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                            4
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 various protocols such as SNMPv3, Syslog, IPSec, AAA, etc.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                    5
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 Services provided by the Mobile Network Operator. Although at first sight, these
appeared to be competing technologies, it was soon realized that both technologies could actually co-exist,
resulting in potential benefits to the end-users, operators, service providers as well 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 well as “ WiFi-cells” were
soon being considered for Enterprise as well as Metro deployments. Accordingly, the space of Integrated
Femto-WiFi Networks can be analyzed within the three categories of Residential, Enterprise and Metro
deployment scenarios.

Integrated Femto-WiFi Networks involve multiple components, which may be managed by the same or
different players. Specifically, IFW-Networks involve the Femto part, the WiFi part and the Broadband
backhaul part, whereas the various players include the MNO, ISP and the Customer (or end-user).
Depending on who manages which part of 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 MNO
R2)   MNO   Double Play Scenario: Femto + WiFi managed by MNO & BB by ISP
R3)   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 Enterprise
E2) Enterprise Femto Network (EFN) & Enterprise WiFi Network managed by MNO

Operational Scenarios for Metro IFW-Networks

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

In the following sections, these deployment and operational scenarios will be described 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 a Residential environment.




Figure 3-1        Residential IFW-Networks

The Residential IFW-Cells are connected to the Exchange (DSLAM) via a common backhaul provided by the
Access Network Provider. The Exchanges themselves are connected via the Wholesale Network to the ISP


Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           6
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 Enhanced Packet
Core Network) via the Femto-Gateway.

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




Figure 3-2        Provisioning Systems of Femto & WiFi Networks

At the bottom end of the figure is the 3G-IFW-Cell, which is realized by an integrated 3G-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 to the 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 the Internet. The Femto
data flows from the IFW-AP to the SeGW over the Iuh via an IPSec tunnel, and terminates at the Femto-
Gateway. The Femto Gateway communicates with the Mobile Core Network via the Iu-PS and Iu-CS
interfaces for Packet-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. The Femto and WiFi parts of the IFW-AP are
provisioned using TR-069 over SSL/TLS or IPSec and TR-069 protocols respectively. Note that the
provisioning systems for the Femto & 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 of Residential IFW-Networks.
They are:

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                             7
R3) 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




Of these, Scenario R4 is a more likely one,   wherein the Operator would offer the integrated Femto/WiFi
Device, while leaving the WiFi provisioning   and management to customer. The reasons for the latter
include: (1) allowing the customer to have    maximum flexibility of configuring the WiFi function & home LAN
and (2) reduce operational 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 by
MNO)




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 Service LAN, and the Macro Core
Network are all managed by the Mobile Network Operator.

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 Femto voice over WiFi data etc. It is likely that such integration will require
client support in handsets.

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

Interworking scenarios can be deployed very efficiently if MNO has significant broadband presence.
Examples of MNOs that have significant market share in broadband 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 customer premises is deployed
and managed by the Mobile Network Operator (green color coding), whereas the ISP is an independent
business entity (shown in brown color).


Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                                  8
As in the Operational Scenario R1, the integration of Femto and WiFi can be implemented at the radio
interface level. However, network components required for WiFi interworking will have to reside in the
macro core network, or even in the customer premises.

Since the user traffic (non LIPA type) traverses the ISP network, all traffic is subjected to 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 are subject to quality of access line and ISP network. For example,
some ISPs may have the Internet peering point in a different country, which may result in increased latency
for voice.

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 supplied by 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 broadband network (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 via client support in
devices.

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




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 customer owns the WiFi router (shown by three
different colors). Any interworking scenarios need to be implemented via network and client support.

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

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                             9
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 aggregation of 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 following challenges (technical
& business) need to be addressed:

      •     Integration of BB modem (Residential GW) and Femto provisioning system requires separate
            provisioning profiles, policies and procedures (e.g. start up procedures 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 but can 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 by ISPs 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 the backhaul and therefore may not bring
            significant benefits.
      •     MNOs have little control over ISP policy enforcement (e.g. prioritization of certain ISP services).
            So, value of interworking may be limited.
      •     Most residential customer configure and manage their own WiFi devices, most of which are off
            shelf units. In other cases, WiFi functions are integrated into some DSL and Cable modems,
            which are typically managed by ISP. Successful leveraging of such devices by the MNO may be a
            concern.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          10
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. The Enterprise 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 for the sake of simplicity. The backend networks, such as Access Network, Broadband
Network 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 scenarios are possible, as
discussed at the beginning of Section 4. They are:

E1) Enterprise Femto Network (EFN) managed by MNO & Enterprise WiFi Network managed 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 Mobile Network Operator may
offer integrated Femto/WiFi Device for enterprise customer.

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

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

3.2.3             Benefits, Challenges & Concerns

As more and more Enterprise users use SmartPhones, Tablets etc, which have both Cellular and WiFi
capability, Enterprise IFW-Networks have the potential benefit of enabling the users to optimally use both


Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                         11
radio services for voice, email, messaging, database access and other data communication. In addition,
LIPA services may be of particular benefit of IFW-Networks.

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

      1.    3G Femto and WiFi may not provide same overlapping coverage due to link budget differences.
            This may be more evident for specific services, such as 3G voice vs. VoIP over WiFi
      2.    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 business challenge.
      3.    Enterprise customers prefer to manage the WiFi network by internal IT personnel. For example,
            Customer managed WiFi Network provides the freedom for the customer to administer call
            admission control. Similarly, WiFi device configurations are performed within the Enterprise over
            the Ethernet port via a web browser. Therefore, either remote configuration through a Network
            Management Device (located in customer premises) or local configuration via dual Ethernet ports
            may be required.


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-cell provides 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 not elaborated in this discussion. The hotspot services 3G only or WiFi only
or dual radio devices (not shown in the figure). The WiFi controller is situated within the Broadband network
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 the backhaul traffic traverses unsecured public access networks, secure tunnels are
often used to bring the control and data traffic to the Mobile Core Network, although typically Femtos use
IPSec tunnels, whereas WiFi APs use GRE tunnels.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                        12
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 or more SSIDs) and likely
provided by a Neutral Host

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

3.3.3             Benefits, Challenges & Concerns

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.
      2.    Femto/Pico cell may be turned down deliberately to control interference, whereas the WiFi range
            may be higher. So, staggered deployment of Femto/Pico & WiFi may be advantageous in terms
            of coverage.

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

      1.    3G Femto/Pico and WiFi networks have different geographical deployment topologies.
            Specifically, 3G Pico/Femto Cells use regional aggregated gateways, whereas WiFi networks use
            municipal aggregated WiFi NMDs.
      2.    The tunneling protocols are different, namely IPsec for 3G Pico/Femto and GRE for WiFi. Again,
            design should consider the trade-offs involved.
      3.    Since the backhaul transport is shared, design should consider which provisioning system defines
            the QoS policies, etc.
      4.    Similarly, provisioning protocols are different. 3G Pico/Femtos are based on TR-069 protocols,
            whereas WiFi networks are based on SNMP or proprietary protocols. An integrated provisioning
            platform would be desired for the long term.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          13
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 category includes the setting up, configuring, and operational management
aspects. The second category addresses managing of data flows between the Femto and WiFi radio
accesses, such as offloading, handover, etc. Finally, the last category deals with policies and control
mechanisms needed for managing of the data flows.

We shall describe these in a manner that is applicable to all the deployment and operational 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, the provisioning 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 be
desirable to have a single provisioning process, at least in the long term. In such a case, it will also be
desirable to have a single network management entity to manage the CM/AM/PM (Configuration
Management/Alarm Management/Performance Management) data for both technologies.

Currently, most enterprise and metro (public access) WiFi systems are managed by SNMP, whereas
residential WiFi systems are managed by TR-069. Similar to residential WiFi, Femto systems are also
managed by TR-069, although using different data models for Femtos, namely, the combination of TR-098
IGD [5] and TR-196 data models [6] [7] [8].

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




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 interworking of SNMP and TR-069
involves creating mappings between SNMP MIB and TR-069 DM in order to carry necessary provisioning
parameters over the other protocol. It is essentially a form of translation of one protocol parameter to
another. Note that this is an implementation dependent matter outside of the standardized mechanism.

One possible scheme is to proxy the WiFi provisioning over TR-069 by mapping SNMP MIB 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 step further, the WiFi provisioning can also be converted to TR-069 based DM. In this case,
the WiFi portion supports the TR-069 DM natively. The following figure illustrates this mechanism.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          14
Figure 4-2        Management Protocol Interworking – TR-069 Based Provisioning

Another possible scheme is to do the other way around; proxy the FAP provisioning over 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 one step further, the FAP provisioning can also be
converted to SNMP based MIB. In this case, the FAP portion supports the SNMP natively. The following
figure illustrates this mechanism.




Figure 4-3        Management Protocol Interworking – SNMP Based Provisioning

If either of the above schemes is adopted, then clearly the necessary parameter definition 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 of TR-196, first two of which have been published
already by BBF, and the last is to be released in the near future.

      •     TR-196 Issue 1 (Apr. 2009) [6]
              o  Original publication that covers UMTS HNB
      •     TR-196 Issue 1 Amendment 1 (May 2011) [7]
              o  Incremental update and change from Issue 1
      •     TR-196 Issue 2 (publication date TBD) [8]
              o  Same update and change in Amendment 1
              o  Additional coverage of 2 new radio technologies (LTE HeNB and CDMA2000 FAP)
              o  Re-organization of the original TR-196 issue 1 structure


Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                       15
There are also other relevant DMs necessary for femto configuration. These DMs are complementary 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 include extensive 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 additional capabilities
and functionalities are required above and beyond what is already defined in these base DMs, the suitable
extensions can be defined. The following table shows the relevant DMs.

Data Model           Title                  Latest version   Description          Content
TR-098               “Internet              Issue 1,         Old legacy data      IGD root DM
                     Gateway Device         Amendment 3      model for IGD
                     Data Model for         (July 2011)      (e.g. DSL GW
                     TR-069”                                 type CPE
                                                             devices)
TR-181 issue 1       “Device Data            Issue 1,        Supersedes TR-       Combines TR-098
                     Model for TR-          Amendment 1      098                  and TR-106 as a
                     069”                   (July, 2011)                          “Device” DM
TR-181 issue 2       “Device Data           Issue 2,         Supersedes TR-       Introduces the
                     Model for TR-          Amendment 3      098                  modular (stacked)
                     069”                   (July. 2011)                          interface model
TR-196 issue 1       “Femto Access          Issue 1,         covers original      UMTS HNB DM
                     Point Service          Amendment 1      UMTS FAP only
                     Data Model”            (May 2011)
TR-196 issue 2       “Femto Access          TBD              adds LTE and         UMTS/LTE/CDMA2000
                     Point Service                           CDMA2000 in          radio centric DM
                     Data Model”                             addition to
                                                             UMTS (RAT
                                                             specific DM)
TR-157               “Component             Amendment 4      Non-femto-           SW module mgmt,FM
                     Objects for            (July 2011)      specific common
                     CWMP”                                   DM
TR-262               “Femto                 TBD              RAT                  Femtozone
                     Component                               independent          application, GPS,
                     Objects”                                femto-specific       Transport, PM
                                                             DM
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 latter focuses 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 from TR-196 Issue 1 version DM. This means that set of appropriate DMs need to be
utilized depending on the version of TR-196 being used.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                     16
Figure 4-4        TR-196 Update after Issue 1

The following two figures show the possible DM combinations when using: 1) TR-196 Issue 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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                      17
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 is equally applicable to
IFW type devices as well as non-IFW type devices as well.




Figure 4-7        Example DM Usage for Femto Configuration



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                       18
We conclude this section by mentioning that some amount of harmonization between Femto and WiFi data
models as well as possible additional coverage of the WiFi aspects (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, which targets BBF and 3GPP
interactions. Similarly, 3GPP-SA5 also is looking at Federated Network Management for FMC, which may be
relevant. Additional details on these items 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 are made possible by the
integration of Femto and WiFi networks. These are organized as follows:-

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

Then we shall describe handover of ongoing sessions from Femto to WiFi and possibly vice versa, with
session continuity and IP-address preservation. Next, we shall discuss a finer granular version of the
previous case, wherein individual IP-Flows may be moved 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 data
communications 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 dynamically routed across either of the two constituent radio links.

Finally, we describe a related traffic offloading solution, wherein the offloading occurs within 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 the Mobile Core Network first. Similarly, SIPTO refers to traffic meant
for public Internet being 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 and techniques, 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 Radio Interface and is
powerful technique available to Mobile Network Operators to alleviate the capacity crunch problem that
many Mobile Networks are currently experiencing. It is 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
signal coverage, higher data rates and improved macro-cellular performance.

One of the user advantages of WiFi offloading is the potentially higher data rate over the Radio Interface
(although the broadband backhaul may not always support such rates, 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 be balanced against the greater control of handover and interference within a cellular network.

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 criteria consist 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 ANDSF procedures. 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’s credentials with the Mobile Network Operator (which would be seamless using
the EAP-SIM protocol, for example).

The criteria for offloading may range from a simple availability of a WiFi hot spot to a sophisticated
dependence on several other factors such as user type, usage profile, traffic type, protocol type etc. For
example, offloading policy may depend upon whether 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 WiFi Network, such as congestion, throughput, etc.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           19
The relevant 3GPP Standards are the IWLAN standards (TS 23.234) & EPC standards (TS 23.402). Dynamic
provisioning of the discovery and selection information is standardized 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 to communicate in during idle
mode, handovers refer to moving an active session from Femto to WiFi radio and possibly vice versa. It is
important that the IP address of the UE 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 handover and such a procedure
generally involves buffering of packets and sending them from source to target network during handover.
This is often an implementation issue and not necessarily part of the handover protocol.

Broadly speaking, there are two types of handover protocols at the IP level. They are Host-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 Logical Interface. MIP, MIPv6, DSMIPv6 are examples of HBM protocols, whereas PMIP, PMIPv6,
GTP are NBM protocols. (in Network) , LIF-Logical Interface (in UE). DSMIP allows mobility across networks
while maintaining IP address continuity and provides seamless data handover between 3G/4G and WLAN, by
providing Make-before-break mobility. DSMIP based solutions also support for legacy IPv4 network, since
UE and Home Agent (HA) support IPv4 and IPv6. Figure below shows the various options.




Figure 4-8        Seamless Handovers using HBM/NBM protocols

Basic Handover procedures are standardized by 3GPP in the IWLAN specifications (TS 23.327) & EPC
specifications (TS 23.402). WiFi mobility with DSMIP is supported in 3GPP Release 8 and was specified for
EPC &UMTS/GPRS core networks. Corresponding policies are standardized in the ANDSF specifications as
ISMP (TS 23.402). These are further 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, either Femto 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 are possible.

One such functionality may be called ‘Flow Segregation’, which consists of sending different types of
application flows across the most appropriate radio access networks, where the appropriateness can be
defined in terms of bandwidth, cost etc. For example, the figure below shows a case where http traffic and




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                        20
3rd party application flows 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

Another functionality is referred to as ‘Flow Mobility’, which consists of moving individual application flows
from one radio link to the other, while keeping the rest of the flows where they are. In the above example,
suppose that the WiFi radio link is experiencing increased interference and hence reduced throughput. The
‘http traffic flow’ 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 both Femto and WiFi radio
links simultaneously, resulting in what may be called as ‘Flow Aggregation’. Such a scheme has multiple
benefits, such as increasing the overall bandwidth for demanding applications such as HD Video, balancing
the load across two radio links dynamically and providing fail-safe radio connections (since communication
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 to aggregating 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 on registration of multiple CoAs
for a given HoA and binding different IP flows to different CoAs or directly to HoA. Other mobility scenarios
based on PMIP are also defined in 3GPP (S2a, S2b).

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

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



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          21
4.2.4             LIPA & SIPTO for Network Offloading

The discussions in the previous sub-sections dealt with management of traffic over the Femto and WiFi radio
links. Network congestion can also happen due to traffic in the backhaul and core networks, and LIPA and
SIPTO are two offloading solutions for the network traffic. They are based on the observation that not all
traffic needs to traverse the MNO’s core Network.

First example is a UE communicating with a Device within the local IP network, to which 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 3GPP standardized 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 the femtocell 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), with the first two cases being Femto-SIPTO and the final case being Macro-SIPTO.

Clearly, Femto-SIPTO requires that the broadband backhaul network is either also managed by MNO or that
there is a business relationship between the MNO and the broadband 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 if LIPA/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. Some examples are provided below:

      •     Residential-IFW scenarios: Handovers between Femto-LIPA/SIPTO and WiFi-LIPA/SIPTO could
            make sense, for example, to counter WiFi interference or for power savings. Secondly, Femto-
            LIPA/SIPTO and WiFi-LIPA/SIPTO can be integrated 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 LIPA connections.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           22
4.3         Control Plane Aspects

Traditional approaches to control the usage of the radio interface (such as QoS parameters, handovers etc)
are entirely network based, which work well in fully planned networks such as macro cellular networks. A
natural approach for unplanned networks such as WiFi networks is to place the control in the hands of the
user (since the UE is best aware of its network neighbourhood). Yet, if operators are to use WiFi as part of
their service offering, it is necessary that operators are in control of how the radio 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 dynamic fashion. Secondly, the user device must have algorithms to detect characteristics
of the 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 = Inter System Routing
            Policy)

Discovery Information:
Discovery information can be used to assist the UE in efficient discovery of access networks around the
validity area. For Wi-Fi, the access network information includes Wi-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) and keys.

Inter-System Mobility Policy (ISMP)
ISMP allows operators to configure multiple rules on the UE to make a decision on which access technology
(e.g., cellular or Wi-Fi), and access network to prioritize for access in a validity area. The validity area is
defined by (i) the PLMN, TAC/LAC, or CELL_ID of the cellular network, (ii) Wireless LAN SSID, or (iii) the
geolocation of the UE. 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 three types of ISRP rules:

      •     Seamless Offload rules – there are two types of rules in this category
              o   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 and destination IP addresses and ports. The
                  criteria for routing the packets may also be based on time of day, validity area and also
                  the Access Point Name (APN) of the current network.
              o   Multi Access PDN Connectivity (MAPCON) rules – these rules are similar to IFOM but the
                  traffic flow is routed based on the APN being used instead.
      •     Non-seamless Offload rules – these rules are similar to IFOM except that these rules are applied
            when there are no IP session continuity support.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           23
Figure 4-12       Structure of ANDSF Policy Management Object

Figure below shows the ANDSF architecture and how policies are pushed to the UE by the 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 dynamically modified 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 are not necessarily
collocated. In the IFW-Networks, the APs are generally located in the same 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 and cellular 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 trigger to 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, Discovery & ISRP policies. This eliminates the need and
complexity for per-cell configuration 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 specific deployment and
operational scenario. However, there are some key aspects that are common 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 the Network. Smart
offloading guided by Operator policies would imply that the UE should support some form of Connection
Manager that orchestrates the WiFi offloading and possibly LIPA processes, whereas some form of a Policy



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                         24
Client would be needed for Operator policies. The latter could be an ANDSF client. Advanced functionalities,
such as Seamless Handovers and Simultaneous Femto-WiFi Flow Management would require some form of
DSMIP client for Host-Based-Mobility approach or Logical Interface for Network-Based-Mobility approach.

The impact on the network is somewhat more involved, because multiple options could exist, especially for
Seamless Handovers and Simultaneous Femto-WiFi Flow Management. Such IFW functionality would reside
in one of the network nodes. A natural choice is the GGSN in the UMTS Core Network or PGW in the EPC
Core Network, as suggested by the 3GPP standards. The figure below shows a simplified functional
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 are collocated in an IFW-environment, possibly in the same
physical form factor. This IFW-AP connects to a Broadband Modem and further into the Mobile Core Network
in parallel 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 and the 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.

Similarly, the WiFi-path consists of a Tunnel Terminating Gateway (TTG) which basically allows a secure
IPSec tunnel to be established between the UE and the TTG over 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 GGSN and 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 Internet directly.

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 local IP 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 being developed by the FemtoForum’s Service Special Interest Group (SSIG).

The key element for the IFW-Networks is the GGSN, which is the network node where the Femto and WiFi
network paths converge. Accordingly, GGSN is the network node where 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-WiFi integration
function includes Local Mobility Agent (LMA) functionality. In this case, the additional functionalities, namely
Mobility Anchor Gateways (MAGs) need to be also implemented 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 in the figure.

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




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                          25
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 for macro-cellular and WiFi integration, when
the Cellular Base Station and WiFi AP are geographically separated and not collocated. Indeed, this is the
typical configuration assumed 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, so that the IFW
functionality could potentially be located in or near the collocated IFW-AP itself. 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 Core Network! This variant architecture is shown below, where the IFW-GW
functionality is located in the IFW-premises.




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. (In the case of EPC, this would be ePDG node).
This architecture is depicted in the figure below.




Figure 4-16       Gateway based IFW-Function

Implementation Aspects: Finally, we consider the implementation of an IFW-AP. It is important to identify
what information needs to be available from each AP to the other AP, 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 is suggested that such a study be taken up as a follow-on to the current IFW-activity.



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                        26
5. Standards

5.1         Current and Ongoing 3GPP Standards Activity

The basic standards describing the interworking of 3GPP cellular (macro) networks and WLANs are TS
23.234, whereas handover procedures based on DSMIP protocols were standardized in TS 23.327. Finally,
IP Flow Mobility across simultaneous cellular and WLAN connections was standardized in TS 23.261, again
based on extensions of DSMIP protocols. This set of standards assumed a UMTS Core Network and are
collectively 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 procedures for accessing EPC via WLAN access networks,
which were originally treated as Untrusted Networks. Both DSMIP and PMIP were addressed, and seamless
handovers as 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 above standards as well as some
new work items that are further advancing the WiFi access to 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)




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                      27
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 was modified to enable establishment and
disconnection of multiple PDN connections to the same APN uniformly across the EPS from any access as
well as handover of multiple PDN 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 was the first attempt to
really handle multiple access UEs (3GPP and non-3GPP). It started in 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 to support: (1) accessing a PDN simultaneously via a 3GPP and a non 3GPP access
system; (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 systems; and (4) 3GPP-Non3GPP
handovers when UE is connected to different PDNs via different accesses (EPC only). The MAPIM effort
produced TR 23.861 but later abandoned 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 between PCC and ANDSF architectures. It came up



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                      28
with solutions based on extensions to S2c and 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, it could register these
addresses with the HA as CoAs using multiple bindings as specified 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 this work item was that a
(Rel-9) UE can connect to one PDN over a 3GPP access and a second 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. It resulted 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 WLAN access 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 based on GTP and mobility between GTP-S5/S8 and GTP-S2a.

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




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


Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           29
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, to accommodate 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-11 Work/Study Item,
resulting in TR 23.853. It defines operator policies for selecting an IP interface in the UE. It also examines
the system architecture to get those policies to the 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 based on 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 sends
traffic to; (3) The destination port number the UE connects to; or (4) A combination of the three elements
above. However, recent years have seen a trend where different types 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 traffic should be routed. For example, the operator with the current framework is not able to
discriminate 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 to convey these additional ways over S14.

LOBSTER stands for “Location Based selection of gateways for WLAN” and is a Release 11 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 then extended in Release 10 with IFOM and MAPCON. However, the
current ePDG selection in TS 23.402 has not considered the UE location as well as the proximity to the PDN
GW, 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 is therefore a need to improve the ePDG and PDN-
GW selections based on the location of the UE for the WLAN Access to EPC in S2b and S2c cases. This work
item aims to specify enhancements to the ePDG and PDN GW selection functions for S2b and S2c based on
UE location.

BBAI is an ongoing Release 11 work item and it stands for Broadband Access Interworking. Currently, the
Broadband Network through which the Iuh and S1 interfaces 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
work item seeks to develop interworking standards between the Broadband Network and the 3GPP Core
Network for the purposes of QoS, Policy Control, Authentication, Billing etc. This work has a number of
contributory Building Blocks at varying levels of completion; Building Block I focuses on BBF Interworking
with Home routed traffic for WLAN and H(e)NB, Building Block II focuses on interworking with offload in the
access network for WLAN and H(e)NB, whilst Building Block III is targeted at convergence and network
based mobility. The work includes collaboration workshops with the Broadband 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 from operator interest in supporting voice service
interworking between 3GPP networks and Enterprise environments and was started in May, 2010. The
initial study conducted a thorough analysis of related standardization (e.g., TISPAN, ECMA) and proposed
requirements. A Reference Model generated, and the architecture studies are underway 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 data model which contains necessary RF
parameters, Device Parameter, Time and location parameters, 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, the applicability is mainly for Residential scenarios,
where the WiFi functions and provisioning is believed to be managed by customers. However, Enterprise
and Metro IFW scenarios may require data model extensions to current TR-98 in order to enable remote
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 of packet and IKE exchanges) :



Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                           30
RFC    2404        The use of HMAC-SHA-1-96 within ESP and AH
RFC    3602        The AES-CBC Cipher Algorithm and Its Use with IPsec
RFC    3715        IPsec Network Address Translation (NAT) compatibility Requirements
RFC    3948        UDP Encapsulation of IPsec ESP Packets
RFC    4301        Security Architecture for the Internet Protocol
RFC    4393        IP Encapsulating Security Payload
RFC    4306        Internet Key Exchange (IKEv2) Protocol
Etc.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                      31
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 is recommended that future
investigations should focus on specific areas, such as Joint Provisioning methods, Policy matters that take
into account integrated Femto-WiFi products, edge-based Femto-WiFi integration techniques etc., possibly
resulting in specific requirements for IFW-products and services.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                        32
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 and Technology”, Wiley 2009.
3  J. Zhang and G. de la Roche, “Femtocells: Technologies and Deployment”, Wiley 2010
4  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 Data Model 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 Service Data Model”, May 2011.
8 Broadband Forum, TR-196 Issue 2, Revision 06 (Straw Ballot), “Femto Access Point 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 for CWMP”, Nov. 2010.




Report title: Integrated Femto-WiFi (IFW) Networks
Issue date: 28 February 2012
Version: Published                                                                                    33

				
DOCUMENT INFO
Shared By:
Tags: femtocells
Stats:
views:734
posted:3/14/2012
language:English
pages:37
Description: phones with both 3G UMTS, 4G LTE and WiFi technology support become prevalent, mobile operators are driven to formulating an integrated Femto and WiFi products strategy, in order to provide dual air-interface support for smart phones at the same cell coverage location.