Internet Engineering Task Force J. Yang Internet Draft Huawei Intended status: Informational T. Sun Expires: September 2009 China Mobile S. Fan March 4, 2009 Multi-interface Connection Manager Implementation and Requirements draft-yang-mif-connection-manager-impl-req-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 4, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Yang, Sun & Fan Expires September 4, 2009 [Page 1] Internet-Draft Connection Manager in Arena Platform March 2009 This document presents the current implementation and problems encountered in practice of the "Connection Manager." The problems to be addressed exist within an operating system (OS) and platforms above OS. This document focuses on levels above OS and presents the solutions, especially for terminals with multiple interfaces. The scenarios of interface selections are described. Table of Contents 1. Introduction................................................2 2. Scenarios of multiple interfaces.............................2 3. Implementation of Connection Manager.........................3 3.1. Connection Handle.......................................3 3.2. Interface based connection handle.......................3 3.3. Interface and Access Node based connection handle........4 4. Problems Encountered In Practice.............................4 4.1. Pre-configuration of connection handle in UE............4 4.2. Automatic selections based on OS........................5 4.3. Automatic selections based on applications.............5 5. Conclusions.................................................5 6. Informative References.......................................5 Author's Addresses.............................................6 1. Introduction Along with the development of variant access technologies, terminals are capable of being connected with different networks through multiple interfaces. These interfaces may belong to one or multiple network domains. Applications on terminals need to connect with appropriate network domains through interfaces for the requirement of services, or on behalf of users' preference. This document describes an implementation of interface selection by terminal applications, especially for accessing different network domains. A connection management approach is presented. In addition, the document also identifies the problems caused by different implementations among variant vendors. This will lead to difficulties on customization and development of terminal software. 2. Scenarios of multiple interfaces A terminal may have multiple interfaces for network connection, e.g. interfaces for connection with GRPS, WiFi, and BlueTooth. An Zhang, Sun & Chen Expires September 4, 2009 [Page 2] Internet-Draft Connection Manager in Arena Platform March 2009 application sets up a network connection through one of these interfaces. In fact, different network connections may correspond to different network domains, in which different services are provided. Therefore, an application needs to select the right interface for network access. 3. Implementation of Connection Manager 3.1. Connection Handle In terminal, applications use "connection handle" to dial-up or setup connections. This connection handle can be defined in two ways: o Interface based connection handle. o Interface and access node based connection handle. Application may select the appropriate connection handle to setup connections according to configured policy. 3.2. Interface based connection handle As illustrated in Figure 1, a UE have three types of interfaces, i.e., GRPS, WiFi and Bluetooth. Each interface has one corresponding connection handle as Connect 1, Connect 2 and Connect 3. When an application on the terminal starts to connect with the networks, the system selects the connection handle and configures parameters (e.g., SSID, default Proxy, APN parameter) based on the specific requirement of the application. +----+ +------------------------------+ | | GPRS |Connect1->GPRS internet GPRS | | UE |------------| | | | +------------------------------+ | | | | +------------------------------+ | | WiFi |Connect2->WLAN internet WLAN | | |------------| | | | +------------------------------+ | | | | +------------------------------+ | | BlueTooth |Connect3->Bluetooth_internet | | |------------| | | | +------------------------------+ +----+ Figure 1 Interface based connection handle. Zhang, Sun & Chen Expires September 4, 2009 [Page 3] Internet-Draft Connection Manager in Arena Platform March 2009 3.3. Interface and Access Node based connection handle As illustrated in Figure 2, a UE have three network interfaces, i.e., GRPS, WiFi and Bluetooth for network access. As for these interface, each has more than one connection handles. Therefore, a connection handle is determined by the network interface type and access parameters. When an application starts to connect with the network, it may implement based on local policy to select the appropriate connection handle for this specific application. +----+ Connect1->APN= CMWAP:GRPS | | GPRS / | |--------| Connect2->APN=CMNET:GPRS | | \ | | Connect1->APN= CMWAP:GRPS | | | | Connect4->SSID=AP1:WLAN | UE | WiFi / | |--------| Connect5->SSID=AP2:WLAN | | \ | | Connect6->SSID=AP3:WLAN | | | | Connect7->deviceID = B1:BlueTooth | |BlueTooth / | |---------| | | \Connect8->deviceID = B2:BlueTooth +----+ Figure 2 Interface and Node based connection handle. 4. Problems Encountered In Practice As described in 3.2 and 3.3, a terminal may have multiple interfaces and each interface may have multiple connection handles for different access nodes. This section presents three implementation approaches and the corresponding problems encountered. 4.1. Pre-configuration of connection handle in UE Currently, connection handle of the applications have been pre- configured on the OS. When UE connects to a network, it uses the pre- configured parameters automatically. The problem is that the pre-configured parameters are different among different vendors. Therefore, the applications should be designed into different versions for the variant parameter settings. Moreover, when an application is downloaded or updated, UE should check whether Zhang, Sun & Chen Expires September 4, 2009 [Page 4] Internet-Draft Connection Manager in Arena Platform March 2009 the application is applicable. These increase the complexities and restricts the development of UE applicaitons. 4.2. Automatic selections based on OS An application may rely on OS for the selection of a connection handle which is one of the default connection handles maintained by the OS. The problem is that an OS may define one or several default connection handles while, they may not suitable for all applications. 4.3. Automatic selections based on applications All connection handles may be tried one by one by an application until a connection is established. The problem is this will cause a long time waiting and bad user experience. Usually, successful connection may be identified in two steps, i.e., network access success and service startup success. Generally, one attempts to connect to a network may take about 3 second before time out. If every connect handle try 3 times, then it may take about 9 second in all for network connection. After the link is established, the application tries services according to application layer protocol, such as registration etc. This may take about 4-12 seconds before time out. Therefore, it takes about 7-21 second for an application getting connected with network. This will not be a good experience for a user. 5. Conclusions The suggestions for standardization are summarized as follows. o Manager for multiple interfaces to achieve better user experiences. o The connection manager is implemented through both network side and terminal side. o Reduces the complexity of new application installation for diverse terminals. 6. Informative References [I-D.hui-ip-multiple-connections-ps] Hui, M. and H. Deng, "Problem Statement and Requirement of Simple IP Multi-homing of the Host", draft-hui-ip-multiple-connections-ps-01 (work in progress), November 2008. Zhang, Sun & Chen Expires September 4, 2009 [Page 5] Internet-Draft Connection Manager in Arena Platform March 2009 [I-D.blanchet-mif-problem-statement] Blanchet, M., "Multiple Interfaces Problem Statement", draft-blanchet-mif-problem- statement-00 (work in progress), December 2008. Author's Addresses Jian Yang Huawei Technology Mobile department, Huawei Building Haidian District, Beijing 100086 China Email: jian.yang@huawei.com Tao Sun China Moible 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: suntao@chinamobile.com Shunan Fan Huawei Technology Mobile department, Huawei Building Haidian District, Beijing 100086 China Email: fanshunan@huawei.com Zhang, Sun & Chen Expires September 4, 2009 [Page 6]