One document matched: draft-yang-mif-connection-manager-impl-req-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:16 |