Integrated Femto WiFi Networks WP

Integrated Femto-WiFi (IFW) Networks
Published 28 February 2012
Small Cell Forum Ltd PO Box 23 GL11 5WA United Kingdom
Tel: +44 (0)845 644 5823 Fax: +44 (0)845 644 5824 Email: info@smallcellforum.org website: www.smallcellforum.org
Small Cell Forum Ltd (formerly Femto Forum Ltd). 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. 1.1 1.2 2. 2.1 2.2 2.3 3. 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.2.3 3.3 3.3.1 3.3.2 3.3.3 4. 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.4 5. 5.1 5.2 5.3 Introduction .................................................................... 1 Document Scope ................................................................ 1 Abbreviations ..................................................................... 1 Background ..................................................................... 2 3GPP Femto Networks ......................................................... 2 WiFi Networks .................................................................... 2 Enterprise WiFi Networks ..................................................... 4 Deployment & Operational Scenarios of IFW-Networks... 6 Residential IFW-Networks .................................................... 6 System View ...................................................................... 6 Operational Scenarios ......................................................... 7 Benefits, Challenges & Concerns ......................................... 10 Enterprise IFW-Networks ................................................... 11 System View .................................................................... 11 Operational Scenarios ....................................................... 11 Benefits, Challenges & Concerns ......................................... 11 Metro IFW-Networks ......................................................... 12 System View .................................................................... 12 Operational Scenarios ....................................................... 13 Benefits, Challenges & Concerns ......................................... 13 Service & Technology Aspects of IFW-Networks .......... 14 Provisioning & Management ............................................... 14 Integrated IFW Provisioning ............................................... 14 TR-069 Data Models for Femto Configuration ........................ 15 Ongoing Work in 3GPP ...................................................... 19 Data & Traffic Flow Management......................................... 19 Smart WiFi-Offloading ....................................................... 19 Seamless Femto-WiFi Handovers ........................................ 20 Simultaneous Femto-WiFi Flow Management ........................ 20 LIPA & SIPTO for Network Offloading ................................... 22 Control Plane Aspects ........................................................ 23 Architectural & Implementation Aspects ............................... 24 Standards ...................................................................... 27 Current and Ongoing 3GPP Standards Activity ...................... 27 Relevant BBF Standards .................................................... 30 Relevant IETF Standards.................................................... 30
6. Conclusions ................................................................... 32 References ............................................................................... 33

Tables
Table 1-1 Table 4-1 Abbreviations ................................................................................. 1 Relevant Data Models for Femto Configuration .................................. 16
Figures
Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 3-1 Figure 3-2 Figure 3-3 Figure 3-4 Figure 3-5 Figure 3-6 Figure 3-7 Figure 3-8 Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 Figure 4-5 Figure 4-6 Figure 4-7 Figure 4-8 Figure 4-9 FemtoCell Network Architecture ........................................................ 2 Internet Access via WiFi Networks..................................................... 3 Internet Access via Residential WiFi Networks..................................... 4 Enterprise WiFi Networks ................................................................. 4 Residential IFW-Networks ................................................................ 6 Provisioning Systems of Femto & WiFi Networks ................................. 7 Operational Scenario R1: MNO Triple Play .......................................... 8 Operational Scenario R2: MNO Double Play ........................................ 8 Operational Scenario R3: MNO Double Play (Variant) ........................... 9 Operational Scenario R4: MNO Single Play ......................................... 9 Enterprise IFW-Network ................................................................ 11 System view of an Exemplary Metro IFW Network ............................. 12 Separate Management Protocols for FAP and WiFi ............................. 14 Management Protocol Interworking TR-069 Based Provisioning ........ 15 Management Protocol Interworking SNMP Based Provisioning ........... 15 TR-196 Update after Issue 1 .......................................................... 17 DM Usage for TR-196 Issue1 and Issue 1 Amendment 1 .................... 17 DM Usage for TR-196 Issue 2 ......................................................... 18 Example DM Usage for Femto Configuration ..................................... 18 Seamless Handovers using HBM/NBM protocols ................................ 20 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 Figure 5-2 Figure 5-3 Figure 5-4 Figure 5-5 EPC Architecture with S2a & S2b (for PMIP) based protocols) ............. 27 EPC Architecture with S2c interface (for DSMIP based protocols) ......... 28 3GPP Work Items related to WiFi access .......................................... 28 Similarities and differences between MAPCON and IFOM .................... 29 Integrated Femto & Trusted WiFi with a common backhaul ................. 29
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. 2. 3. 4. 5. 6. Meet customer demand on low cost alternative internet access through WiFi technology Simplify installation/connection for the customer: only one box, one power supply, no extra cables, etc. Extend service continuity on 3G UMTS voice and data applications to WiFi Drive scale of economics of integrated Femto and WiFi devices and services 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. 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
Description Access Point Auto Configuration Server Access Network Discovery and Selection Function Broad Band Forum CPE WAN Management Protocol. Defined in TR-069 Amendment 2. Integrated Femto-WiFi Internet Service Provider Mobile Network Operator (WiFi) Network Management Device Operations Support System Service Set Identifier
Abbreviations
Abbreviation AP ACS ANDSF BBF CWMP IFW ISP MNO NMD OSS SSID
Table 1-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 FemtoAccess-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 Operators 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 operators 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.
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.
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.
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.
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) R2) R3) R4) MNO MNO MNO MNO Triple Play Scenario: Femto + WiFi + BB managed by MNO Double Play Scenario: Femto + WiFi managed by MNO & BB by ISP Double Play Scenario: Femto + BB managed by MNO & WiFi by Customer 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
3.1.1
Residential IFW-Networks
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
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 FemtoGateway. 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
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, Device, while leaving the WiFi provisioning include: (1) allowing the customer to have and (2) reduce operational cost associated
wherein the Operator would offer the integrated Femto/WiFi and management to customer. The reasons for the latter maximum flexibility of configuring the WiFi function & home LAN 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).
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 WiFiAP 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!
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.
10
3.2
3.2.1
Enterprise IFW-Networks
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
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
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
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. 2. 3. 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 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. 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
3.3.1
Metro IFW-Networks
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.
12
3.3.2
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
Integration of Femto & WiFi in the Metro case is potentially beneficial because: 1. 2. 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. 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. 2. 3. 4. 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. The tunneling protocols are different, namely IPsec for 3G Pico/Femto and GRE for WiFi. Again, design should consider the trade-offs involved. Since the backhaul transport is shared, design should consider which provisioning system defines the QoS policies, etc. 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.
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
4.1.1
Provisioning & Management

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.
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
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 TR-098
Title Internet Gateway Device Data Model for TR-069 Device Data Model for TR069 Device Data Model for TR069 Femto Access Point Service Data Model Femto Access Point Service Data Model
Latest version Issue 1, Amendment 3 (July 2011)
Description Old legacy data model for IGD (e.g. DSL GW type CPE devices) Supersedes TR098 Supersedes TR098 covers original UMTS FAP only adds LTE and CDMA2000 in addition to UMTS (RAT specific DM) Non-femtospecific common DM RAT independent femto-specific DM
Content IGD root DM
TR-181 issue 1
Issue 1, Amendment 1 (July, 2011) Issue 2, Amendment 3 (July. 2011) Issue 1, Amendment 1 (May 2011) TBD
Combines TR-098 and TR-106 as a Device DM Introduces the modular (stacked) interface model UMTS HNB DM
TR-181 issue 2
TR-196 issue 1
TR-196 issue 2
UMTS/LTE/CDMA2000 radio centric DM
TR-157
Component Objects for CWMP Femto Component Objects
Amendment 4 (July 2011) TBD
SW module mgmt,FM
TR-262
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 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.
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
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
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 MNOs 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 endto-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 preconfigured 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 users 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.
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
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).
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 MNOs 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, FemtoLIPA/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.
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 operators 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.
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
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 Internetbound, 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 FemtoForums 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.
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.
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)
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 IWLAN 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
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 IPaddressing, 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
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 PDNGW 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) :
30
RFC RFC RFC RFC RFC RFC RFC Etc.
2404 3602 3715 3948 4301 4393 4306
The use of HMAC-SHA-1-96 within ESP and AH The AES-CBC Cipher Algorithm and Its Use with IPsec IPsec Network Address Translation (NAT) compatibility Requirements UDP Encapsulation of IPsec ESP Packets Security Architecture for the Internet Protocol IP Encapsulating Security Payload Internet Key Exchange (IKEv2) Protocol
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.
32
References
Femto Forum White Papers, http://femtoforum.org/fem2/resources.php?id=194 S. Saunders et al, Femtocells: Opportunities and Challenges for Business and Technology, Wiley 2009. J. Zhang and G. de la Roche, Femtocells: Technologies and Deployment, Wiley 2010 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. 1 2 3 4
33

Integrated Femto WiFi Networks WP

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Integrated Femto WiFi Networks WP

Transféré par

Droits d'auteur :

Formats disponibles

Integrated Femto-WiFi (IFW) Networks

Published 28 February 2012

Small Cell Forum Ltd PO Box 23 GL11 5WA United Kingdom

6. Conclusions ................................................................... 32 References ............................................................................... 33

3GPP Femto Networks

FemtoCell Network Architecture

Internet Access via WiFi Networks

Internet Access via Residential WiFi Networks

Enterprise WiFi Networks

Enterprise WiFi Networks

3. Deployment & Operational Scenarios of IFW-Networks

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

Provisioning Systems of Femto & WiFi Networks

Operational Scenario R1: MNO Triple Play

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

Operational Scenario R2: MNO Double Play

Operational Scenario R3: MNO Double Play (Variant)

Operational Scenario R4: MNO Single Play

Benefits, Challenges & Concerns

Benefits, Challenges & Concerns

System view of an Exemplary Metro IFW Network

Benefits, Challenges & Concerns

4. Service & Technology Aspects of IFW-Networks

Provisioning & Management

Separate Management Protocols for FAP and WiFi

Management Protocol Interworking TR-069 Based Provisioning

Management Protocol Interworking SNMP Based Provisioning

TR-069 Data Models for Femto Configuration

Data Model TR-098

Latest version Issue 1, Amendment 3 (July 2011)

Content IGD root DM

UMTS/LTE/CDMA2000 radio centric DM

Component Objects for CWMP Femto Component Objects

Amendment 4 (July 2011) TBD

Femtozone application, GPS, Transport, PM

Relevant Data Models for Femto Configuration

TR-196 Update after Issue 1

DM Usage for TR-196 Issue1 and Issue 1 Amendment 1

DM Usage for TR-196 Issue 2

Example DM Usage for Femto Configuration

Ongoing Work in 3GPP

Data & Traffic Flow Management

Seamless Femto-WiFi Handovers

Seamless Handovers using HBM/NBM protocols

Simultaneous Femto-WiFi Flow Management

Flow Segregation across Cellular (Femto) & WiFi radio links

Simultaneous Cellular (Femto) & WiFi Flow Management using DSMIP

LIPA & SIPTO for Network Offloading

Illustration of LIPA & SIPTO Concepts

Control Plane Aspects

Inter-System Mobility Policy (ISMP)

Inter-System Routing Policy (ISRP):

Structure of ANDSF Policy Management Object

Dynamic Operator Policy Provisioning using ANDSF

Architectural & Implementation Aspects

Core Network based IFW-Function

Edge based IFW-Function

Gateway based IFW-Function

EPC Architecture with S2c interface (for DSMIP based protocols)

3GPP Work Items related to WiFi access

Similarities and differences between MAPCON and IFOM

Integrated Femto & Trusted WiFi with a common backhaul

Relevant BBF Standards