[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
Is there an archive for this list ?
Look for DLB to see my comments.
DLB: It's great to see these requirements all in one document. I agree
with and understand most of the requirements. Where applicable I have
identied IP standards which support the requirements.
Internet Draft P. Reynolds
Document: draft-reynolds-mobile-isp- Orange
requirements-00.txt
Expires: Dec 2001 May 2001
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF)
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
The growth in mobile terminal access to the Internet has been one of
the greatest growth areas in the past year. Indeed the so-called 3rd
generation mobile networks being designed are premised upon Internet
services and protocols. Both mobility and wireless access bring with
them unique requirements that needs to be addressed within the
Internet community such as address space and limited access
bandwidth. This document is a synthesis of a yearlong study of
mobile operators and mobile ISPs to crystallise these unique
requirements. These are provided for guidance and are not intended
to be prescriptive on the current Internet Architectural Framework.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Overview...........................................................3
Current Mobile Wireless Telephone Networks.........................3
Wireless Internet Access...........................................4
Fundamental Technical Challenges...................................5
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Wireless Internet Access Frameworks................................5
Mobile Internet Service Provider (MISP) Requirements...............6
References........................................................23
Author's Address..................................................23
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Overview
The mobile wireless industry is undertaking a major infrastructure
change. Its current network was built with only one application in
mind: telephony. The industry is developing new network
infrastructure that would allow its users to handle many
applications. The guiding model is to bring to the industry the same
application richness that has benefited Internet users via fixed
access networks. The goal of the industry is to transform the
current cellular mobile network from an application-dependent into
an application-independent wireless access network to the Internet.
Fixed telephony systems initiated a move towards IP infrastructure
because:
* development of intelligent terminals enabled their handling of the
session control functions. This implied a new framework. It became
possible to have a softswitch architecture supported by an open IP
access infrastructure. This means that the provider of the
softswitch doesn't need to be the same as that of the access
network.
* intelligent terminals make it easier to implement end-to-end
systems
DLB: I believe there are 3 strong points for why any application, voice
included, moves to IP infrastructure.
1. Productivity.
Not much differentiation in productivity between using legacy
telephony and IP Telephony.
2. Cost - infrastructure, deployment, and management
Why purchase, deploy and manage two networks when you
can run all applications over a single IP network ?
IP Telephony for Toll Bypass applications has been a big
influence in dropping the cost per minute.
3. Rapid feature development through open
Open Protocols, API's, and development platforms. Legacy
telephony severly lacked in this catagory.
A wireless Internet framework adopts the distributed nature of the
Internet. The Internet Architecture is based on the end-to-end
principle where application and control functionality is located at
the periphery of the network. The network serves only as a transport
infrastructure with no applications and control functions embedded
in it. The network becomes application-independent and dumb.
DLB: Intelligent entities are needed in the network to control access and
provide QoS capabilities, and route packets but there should be no
application elements
within the network as part of the forwarding path.
The fundamental contribution of the wireless-internet efforts are to
create a wireless access infrastructure that makes possible end-to-
end IP transport between wireless devices, and, between a wireless
device and any other device or application connected to the
Internet.
Wireless Internet access will support any application that can use
the Internet for transmission of information and one of these
applications is telephony. This infrastructure change presents a
fundamental change in the service provider business models. It
represents a shift from being the provider of access to one service
owned by the ISP (plus low bandwidth access to Internet) to
providing access to the Internet, where end-users may find many
services which are not owned by the access provider. Indeed, some of
the telephony services traditionally offered by the access provider,
could be offered by a third party provider.
Current Mobile Wireless Telephone Networks
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
The current mobile wireless telephone networks have been designed to
optimally handle telephony. Mobile wireless networks are circuit-
switched and therefore one of its key components the Mobile
Switching Centre (MSC), which is the equivalent of a Central Office
switch in a fixed telephone network. The other components in this
architecture handle functions exclusive of mobile cellular networks.
These functions are:
* registration (or location updating) and de-registration of a user
terminal as it moves from one point of attachment to another (this
involves AAA functions)
* seamless reconfiguration (re-routeing) of voice circuits from one
point of attachment to another
* routeing & authorisation of signalling messages to and from mobile
stations.
These functions are provided by the combination of Home Location
Register (HLR), Visiting Location Register (VLR), MSC, base station
(BS), base station controller (BSC) and Authentication Centre (AuC).
Wireless Internet Access
The motivation for a wireless access to the Internet is to have an
infrastructure that is independent of applications, whose function
is to provide transport for IP packets going from one end device to
the other. The fundamental difference with fixed Internet access
networks is that the attachment point of end devices to the Internet
changes as users of devices are in motion.
Moving to a wireless Internet access framework, involves making
radical changes to the wireless infrastructure. Some of these
changes will take place in the Radio Access Network (RAN) and some
in the access control infrastructure (commonly referred as the core
network).
The ideal IP access infrastructure is one where the RAN is an IP
network where base stations, base station controllers, and mobile
terminals communicate via IP protocols. There is considerable
ongoing work in this area (e.g., the Open RAN work within the MWIF).
Initially, the RAN will be implemented as a link layer between
mobile terminals and the core access network; as a second stage the
RAN will become an IP-routed network. The RAN is a very complex
system handling mobility within the multiple base stations in an
access network, this involves complex mechanisms and protocols
between the mobile station and its various elements. The RAN handles
micro-mobility (through soft and hard handoff mechanisms), load
control, admission control, relocation, etc., and also provides
synchronisation mechanisms for node synchronisation.
The ideal situation is that all mobility management is performed via
IP protocols. However, RANs require massive investments and it is
necessary to have a gradual transition process. Some of these RANs
have their own mobility management techniques, which are transparent
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
to IP protocols. Mobility management functions at layer 3 utilising
IP in the core and a non-IETF protocol (e.g. Radio Resource Control
- RRC) in the access network.
Fundamental Technical Challenges
There has been considerable work in designing all-IP frameworks for
fixed access networks. What makes wireless systems special, are they
not just another kind of Internet access technology? The answer is
yes, but they have special requirements over the fixed access
technologies. The requirements stem from solving problems associated
with wireless access:
* mobile IP routeing - rapid handoff between access points
DLB: Mobile IP fast handoff drafts should accomplish this.
* fast registration and de-registration on handoff between disparate
technologies (micro v macro mobility)
DLB: Caching registration information needs work in the IETF. RADIUS
proxy does not currently allow caching of registration info from
the Home Radius server.
* maintaining context and QoS in handoff.
DLB: Needs work in the IETF.
* supporting session handoff between terminal technologies.
DLB: If using Mobile IP protocols, sessions don't need to handoff
since the session aware IP address remains the same.
* supporting transport (i.e. seamless data flow) handoff between
technologies _ macrodiversity combining.
DLB: Mobile IP protocols do this. rfc2002 allows seamless handover
between access technologies. Mobile IP fast handoff drafts allow
can support seamless handover within an access technology.
* determining how link loss is detected _ in advance or after the
event?
DLB: This is a layer 2 issue. Timeouts in the session and application
layers detect link down conditions. Faster recognition relies on
layer 2 alerts such as Carrier UP or Carrier Down.
* determining what are the measurement reporting requirements.
* determining how all-IP hard/soft hand off can be achieved in
required time limits.
DLB: IP hard handoff is achievable with mobile IP. Not sure that
IP should do soft-handoff since it is really a access link function.
* assess the extent to which mobility can/should be hierarchical.
DLB: From the point of view of IP, mobility should have minimum
heariarchy as defined in Mobile IP rfc2002.
MN --- FA (access router)--- HA --- CN
Home Agent is optional.
* defining how location management would be achieved, and how a
`location/routing area' would be defined, e.g. paging at layer 3
DLB: IP Paging is not needed for always on IP connection. Layer 2
paging should be used when routable IP address of MN is unknown.
* defining the communication required between the network
measurement function, the policy broker and the subscriber and
equipment databases.
DLB: Needs more explaination.
* defining how the mobility decision will be handled and executed.
DLB: Mobile IP allows Mobile Controlled and Mobile Assisted handoff.
Wireless Internet Access Frameworks
Multiple organisations are working on defining wireless all-IP
access frameworks. They include 3GPP, 3GPP2, and MWIF. 3GPP is
chartered with providing a migration path for GSM. 3GPP2 is
chartered with providing a migration path for IS41. MWIF is
chartered with providing a developing an architecture for cellular
mobile networks based upon IETF protocols. 3GPP does not embrace
Mobile IP for support of Mobile IP routeing, it uses an enhanced
version of the HLR/VLR mechanism from cellular telephony. However,
both 3GPP2 and MWIF have embraced Mobile IP for handling IP
routeing, plus AAA and IPv6 for the handling of registration & de-
registration.
Wireless Internet Framework Requirements
When defining a wireless Internet framework it is necessary to
recognise that:
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* it is compliant with the architectural principles of the Internet
[RFC1958]
* radio spectrum is a scarce and limited resource and that use of IP
based signalling and transport in the RAN and over the radio
interface should respect the needs for efficient use of radio
spectrum
* it is necessary to take measures to ensure spectral efficiency
over the radio interface and that ways of reducing IP overhead, for
example by introducing robust header compression are considered
* IPv6 will become the dominant protocol, although framework must be
capable of inter-working with IPv4 networks and devices.
Mobile Internet Service Provider (MISP) Requirements
Mobility Management
The three aspects of mobility that needs to be supported within a
wireless Internet framework are terminal, session, and personal.
These in turn need to be supported by a logical mobility manger. In
detail:
Terminal Mobility
The wireless Internet framework needs to support the ability of a
terminal to move within and across network domains while continuing
to receive access to services. Terminal mobility needs to be of four
types:
* Inter-administrative Domain Terminal Mobility: this refers to the
ability of the terminal to move across administrative domain
boundaries. The terminal may be within any wireless or fixed network
* Inter-technology Terminal mobility: this refers to the ability of
the terminal to move across technology domain boundaries.
* Macro Terminal Mobility: this refers to the ability of the
terminal to move across subnet boundaries within the same
administrative domain.
* Micro Terminal Mobility: this refers to the ability of the
terminal to move across internal boundaries of an access network.
DLB: AAA and Mobile IP support roaming. Mobile IP protocols support
handoff
for Terminal Mobility as defined above.
Session Mobility
The wireless Internet framework needs to support the ability of the
user to maintain sessions, including continuity of Internet sessions
(e.g., http, ssl, tcp, telnet, ftp), during any discontinuity in the
access network and while changing between terminal devices and/or
access technologies. For example,
* the user of a mobile terminal needs to be able to transfer a
session to a laptop with DSL connection without losing a specific
session;
* as a session transfers from an IMT-IS-2000 RAN to an 802.11 LAN
via handoff from one access network to another, the wireless
Internet framework needs to support session continuity both within
the core and in interfaces to other networks.
DLB: If using Mobile IP, IP applications are unaware of changes in the
access link.
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Personal Mobility
The wireless Internet framework needs to support the ability of a
end-user to obtain services in a transparent manner within any
network and on any terminal (subject to the limitations of the
network and terminal) on the basis of, either personal
identification, or the capability of the network to provide those
services according to the end-user's service profile. This mobility
includes the ability of a service provider to control the services
it provides to the end-user in a roamed MISP. (This is also known as
end-user Mobility, SIM Roaming or end-user Service Mobility in
3GPP/3GPP2.)
DLB: SIP Registration supports personal mobility for realtime applications
and SMS.
HTTP also support personal Mobility.
personal Mobility is an application layer thing in my opinion.
Mobility Management
The wireless Internet framework needs to support a core network
mobility management function that enables terminal, session and
personal mobility across all access technologies. That is, mobility
needs to be supported across heterogeneous networks in addition to
homogeneous networks. The mobility management function must be
flexible, supporting deployment of new access technologies and
upgrading of access networks independent of core network
enhancements. The mobility management functionality within the
wireless Internet framework shall be hierarchical and independent of
other functions within the framework.
DLB: Agreed, and use Mobile IP along with SIP and HTTP.
AAA
The wireless Internet framework needs to support the traditional
'triple A' services, with the additional burden of both mobility and
roaming. In detail:
DLB: AAA already supports roaming. What part of Mobility is not possible
with existing AAA capabilities ?
Authentication
The wireless Internet framework needs to support:
* independent authentication of both a user's identity and a
terminal's identity
DLB: If you have USER authentication, why do you need to authenticate the
terminal ?
* authentication algorithms from GSM & ANSI-41 networks
DLB: Why ? GSM and ANSI-41 authentication can be converted to
Radius by a gateway.
* the capability to allow un-authenticated calls (e.g. to emergency
services)
DLB: No problem. This is really a policy of the service provider.
* the capability to access user/terminal authentication processes,
for e-commerce and other services by way of applications (including
3rd party applications).
DLB: Done. e-commerce is already possible with credit card transactions over
the web.
* separate authentication for access network and service network
DLB: Needs more explaination.
* authentication with entities (e.g. gateways or intranets) in other
administrative domains (inter-administrative domain authentication).
DLB: Need an example to understnad this requirement.
Authorisation
The wireless Internet framework needs to support authorisation for
service access independently of authentication. Capabilities are
required to support authorisation at the application level.
Authorisation needs to be supported to control use of multiple
access networks, i.e. once authenticated and authorised on one
access network (e.g. GSM), no additional authorisation is required
to move to alternative access networks (e.g. IEEE 802.11).
DLB: Done. Circuit switched data on GSM uses Radius. IEEE uses Radius.
PPP context on GPRS uses Radius.
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Accounting
Accounting is the process, within the wireless Internet framework,
by which use of network resources are recorded. An accounting system
needs to record network resources used (e.g. packet count), QoS
provided (e.g. bandwidth, bearer capabilities) and time and duration
of provision of network resources.
The wireless Internet framework needs to provide an accounting
function that allows MISPs to perform billing and auditing functions
on individual sessions. The capability needs to exist for a multi-
tiered, flexible accounting process (recording of resources used by
packet/octet/byte count, content, session length, level of QoS
provided) that is capable of handling intra-domain and inter-domain
accounting. For example, the MISP may adopt multi-tiered billing
which may be used to provide revenue sharing among network (or
multiple network) providers, content providers, etc., and it is
necessary that the accounting records provide sufficient capability
for this to be undertaken. Such information needs to be provided via
an open interface, e.g. SNMP, to the network and service management
functions.
DLB: Not sure what you mean be session and content, but packet/octet/byte
count can be done with AAA. QoS accounting can be done with
AAA QoS extensions or COPS.
It is not possible, nor prudent, to identify charging models that
MISPs will use for services as part of the provision of the wireless
Internet - indeed such information is likely to be commercially
confidential. It can, however, be readily acknowledged that MISPs
will wish to adapt charging systems as the market evolves, being
free to introduce innovative schemes to reflect the deployment of
new services. Equally well, while traditional interconnect charges
continue to exist for calls connected over the public switched
telephone network, it will be necessary to support destination and
time dependent charging.
DLB: Radius and COPS support a variety of billing models.
In detail, MISPs will require basic units of data to support
flexibility in the generation of accounting information for example
to account:
* on the basis of usage of network resources (e.g. QoS, packet count
in both directions, duration of connection)
DLB: Radius and/or COPS
* on a non-usage basis (e.g. subscription for a given time)
DLB: Radius and/or COPS
* on the basis of a sessions duration and destination
DLB: what is a session ?
* on a fixed charge basis, (e.g. fixed charge for an SMS message)
DLB: I don't understand this. If I have an always on IP connection that
I am paying for which uses yahoo instant messaging, why does the
service provider need know about this.
If the service provider, supports an instant messaging service, then
they can bill based on the application accounting info.
* on the basis of access to the end service or content (e.g. micro-
charging)
DLB: Not sure I understand this. Whoever owns the application server
bill for the application usage. Again if the service provider, provides
applications then they bill for them at the application level.
* for both mobile originated and mobile terminated sessions;
DLB: From the IP point of view, Mobile originated or terminated is simply
matter of which device MN or access router initiated the QoS request.
So this can be done through a RADIUS or COPS server.
* separately for certain sessions for which a pre-paid user may have
a contract subscription (e.g. WAP services);
DLB: What is a session ?
* for changes in quality of service that may occur during a session;
and allow:
DLB: RSVP with RADIUS or COPS.
* mobile terminated sessions where there is no charge to the called
party
DLB: Good question. How is this accomplished with legacy telephony ?
* mobile originated sessions where there is no charge to the calling
party
DLB: Good question. How is this accomplished with legacy telephony ?
...