VIEWS: 734 PAGES: 37 CATEGORY: Emerging Technologies POSTED ON: 3/14/2012
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.
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: firstname.lastname@example.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 email@example.com Post Small Cell Forum, PO Box 23, GL11 5WA UK Member Services Lynne Price-Walker firstname.lastname@example.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 , popular books ,  and Standards . 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  and TR-196 data models   . 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)  o Original publication that covers UMTS HNB • TR-196 Issue 1 Amendment 1 (May 2011)  o Incremental update and change from Issue 1 • TR-196 Issue 2 (publication date TBD)  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  and TR-181)   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       . 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
"Integrated Femto-WiFi (IFW) Networks"