[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Preliminary attempt for mapping
Hi.
I attempted to put WG names on the releted requirements.
Please give your comments and suggestions for modification.
------------------------------------------
TAKESHITA, Atsushi
DoCoMo Communications Laboratories USA, Inc.
takeshita@dcl.docomo-usa.com
Tel: 408-451-4705 / Fax: 408-573-1090
------------------------------------------
I put WG names on the related requirements and give comments.
The following is the notation I used.
Atsushi Takeshita
* My comments:
<AT> My comments </AT>
*Acronyms for WG names
<acap> Application Configuration Access Protocol
<cnrp> Common Name Resolution Protocol
<geopriv> Geographic Location/Privacy
<ldapbis> LDAP (v3) Revision
<ldapext> LDAP Extension
<urn> Uniform Resource Names
<aaa> Authentication, Authorization and Accounting
<eos> Evolution of SNMP
<policy> Policy Framework
<rap> Resource Allocation Protocol
<rmonmib> Remote Network Monitoring
<sming> Next Generation Structure of Management Informatio
<snmpconf> Configuration Management with SNMP
<snmpv3> SNMP Version 3
<bgmp> Border Gateway Multicast Protocol
<idmr> Inter-Domain Multicast Routing
<mobileip> IP Routing for Wireless/Mobile Hosts
<msdp> Multicast Source Discovery Protocol
<pim> Protocol Independent Multicast
<ssm> Source-Specific Multicast
<cat> Common Authentication Technology
<idwg> Intrusion Detection Exchange Format
<ipsec> IP Security Protocol
<ipsp> IP Security Policy
<kink> Kerberized Internet Negotiation of Keys
<krb-wg> Kerberos WG
<pkix> Public-Key Infrastructure (X.509)
<tls> Transport Layer Security
<diffserv> Differentiated Services
<iptel> IP Telephony
<issll> Integrated Services over Specific Link Layers
<rmt> Reliable Multicast Transport
<seamoby> Context and Micro-mobility Routing
<sip> Session Initiation Protocol
<enum> Telephone Number Mapping
<pilc> Performance Implications of Link Characteristics
<rohc> Robust Header Compression
<ipngwg> IPNG
<ngtrans> Next Generation Transition
<avt> Audio/Video Transport
<ippm> IP Performance Metrics
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
<AT> Since this section is very general, we don't need mapping. </AT>
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
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.
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
<AT> We don't need mapping because this section describes general view
of wireless Internet access. </AT>
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
<mobileip>
* fast registration and de-registration on handoff between disparate
technologies (micro v macro mobility)
<mobileip>
* maintaining context and QoS in handoff.
<seamoby>
* supporting session handoff between terminal technologies.
<sip>
* supporting transport (i.e. seamless data flow) handoff between
technologies _ macrodiversity combining.
<mobileip> <seamoby>
* determining how link loss is detected _ in advance or after the
event?
<AT> Irelevant to IETF? Of course, Layer 2 requirements are important.</AT>
* determining what are the measurement reporting requirements.
<AT> Need more explanation. </AT>
* determining how all-IP hard/soft hand off can be achieved in
required time limits.
<mobileip> <seamoby>
* assess the extent to which mobility can/should be hierarchical.
<mobileip>
* defining how location management would be achieved, and how a
`location/routing area' would be defined, e.g. paging at layer 3
<seamoby>
* defining the communication required between the network
measurement function, the policy broker and the subscriber and
equipment databases.
<AT> Need more explanation. </AT>
* defining how the mobility decision will be handled and executed.
<seamoby>
Wireless Internet Access Frameworks
<AT> We don't need mapping for this section. </AT>
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
<pilc> <rohc> <ipngwg> <ngtrans>
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
<mobileip> <seamoby>
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.
Session Mobility
<sip> <AT> Needs more work in IETF. </AT>
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.
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Personal Mobility
<acap>????? <aaa>????
<AT> I'm not sure how this relate to IETF. </AT>
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.)
Mobility Management
<mobileip> <seamoby>
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.
AAA
The wireless Internet framework needs to support the traditional
'triple A' services, with the additional burden of both mobility and
roaming. In detail:
Authentication
<aaa>
The wireless Internet framework needs to support:
* independent authentication of both a user's identity and a
terminal's identity
* authentication algorithms from GSM & ANSI-41 networks
<AT> According to Dana, GSM and ANSI-41 authentication can be Radius
by a gateway. If so, this requirement is covered by <aaa> </AT>
* the capability to allow un-authenticated calls (e.g. to emergency
services)
* the capability to access user/terminal authentication processes,
for e-commerce and other services by way of applications (including
3rd party applications).
* separate authentication for access network and service network
* authentication with entities (e.g. gateways or intranets) in other
administrative domains (inter-administrative domain authentication).
Authorisation
<aaa>
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).
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Accounting
<aaa> <rap> <snmpv3>????
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.
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.
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)
* on a non-usage basis (e.g. subscription for a given time)
* on the basis of a sessions duration and destination
* on a fixed charge basis, (e.g. fixed charge for an SMS message)
* on the basis of access to the end service or content (e.g. micro-
charging)
* for both mobile originated and mobile terminated sessions;
* separately for certain sessions for which a pre-paid user may have
a contract subscription (e.g. WAP services);
* for changes in quality of service that may occur during a session;
and allow:
* mobile terminated sessions where there is no charge to the called
party
* mobile originated sessions where there is no charge to the calling
party
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* sessions to certain destinations (e.g. emergency services
irrespective of the status of the end-user subscription level)
* a change in the accounting rate after a given resource usage (e.g.
first 50 minutes per day free, thereafter a charge, or first 20
Mbytes at $0.05/ Mbyte, after which it is $0.03/ Mbyte)
* collection of accounting information as the end-user roams between
network domains
* the provision of accounting information, in near real-time,
detailing all network resources used, necessary for the support of
advice of charge services.
There are a number of special accounting requirements that are a
direct result of the developments in mobile cellular operations.
These include:
* support of both Pre & Post Paid Services: Given that the support
of pre-paid end-users is expected to be a significant part of most
MISPs business, it is essential that the wireless Internet framework
supports pre-paid end-users; in additional to post-paid contract or
subscription charging. That is, the wireless Internet framework
needs to provide the capability for real-time control of end-user
access to network resources dependent on the current level of the
individual end-user's subscription. For the end-user accounting
information needs to be made available such that the user can access
account balance at any time.
* prevention of fraud: The generation of accounting information
needs to be such as to prevent fraudulent abuse of the accounting
system by end-users, hackers or any other party. The framework needs
to support the capability to always accurately assign accounting
information against the relevant end-user and a particular QoS,
irrespective of any attempts that the end-user might make to: hide
the identity of the source or destination; pass off the packets as
being from another source; disguise the assigned QoS; or otherwise
attempt to defraud the MISP.
* accuracy, reliability and resilience: In all accounting and
charging entities, especially in usage-dependent charging, it is
necessary that the records are accurate, are reliably produced and
stored, and that the accounting system is resilient to network
failures. Emphasis needs to placed upon the accuracy of packet
counting, especially in handoff and re-location situations where
"duplicate packet counts" have been deducted from the total packet
count. Additionally, acknowledging packet loss is inevitable,
accounting systems need to ensure that the performance of accounting
systems with respect to packet loss is clearly understood.
Naming, Numbering & Addressing
<cnrp>?? <sip>?? <enum>???
The wireless Internet framework must provide the capability to
separate IP address (i.e. IPv6) from end-user names (e.g. URL),
cellular numbers (e.g. E164 number). The name or number is used to
uniquely identify the call parties whereas addresses are used solely
to determine routeing of the session.
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Addressing is the link between different network technologies whilst
naming and numbering may evolve towards higher level common
identification mechanisms covering all communication systems (IP,
mobile, fixed). The wireless Internet framework should support such
evolution. For example, the wireless Internet framework needs to
support: static and dynamic IP addresses for mobile terminals;
associating public IP addresses with mobile terminals; associating
private IP addresses with mobile terminals; mapping Network Access
Identifiers (NAI) to mobile terminals; connection of end-users to
private IP networks; and, mapping between end-user number (e.g.
E.164) and names (e.g. URLs) with IP addresses.
Although a called party may be identifiable via different means, the
wireless Internet framework should allow the user to be reachable
through a given name, independent of their location.
Policy and Profile Services
<rap> <aaa> <mobileip>
The wireless Internet framework needs to support the capability to
implement business, network and service policy in accordance with
the MISPs specified policy rules. As such, the wireless Internet
framework needs to support the storage and provisioning of the data
necessary for the implementation of these, policies, together with
capability to implement the specified network policies. The scope of
the network policies should include, provision and support of QoS,
interconnection with other networks, provision of, and access to,
services and provision of service under varying network load
conditions.
The wireless Internet framework needs to support the capability to
store and manage end-user/user profile information. Such profile
information may include, but is not limited to:
* end-user identity (e.g. names, addresses)
* end-user service preferences (e.g. presentation, diversions,
barring)
* end-user preferences (e.g. language, alerts)
* end-user terminal capabilities (e.g. display capabilities, access
capabilities)
* authorised services
* authorised bearer and access capabilities (including QoS)
* authorised roaming service capabilities
Service Control
<AT> I'm not sure what IETF WGs are related to this. </AT>
In the wireless Internet framework, all service logic (e.g.,
providing value-added voice and data services and classical
telephony supplementary services) needs to be separated from the
session management function. Interaction between service functional
entities (e.g. service logic, service creation and service
management) and control functional entities (e.g. session
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
management, mobility management, resource management) needs to be
supported by open interfaces.
Directories/Databases
<ldapbis> <ldapext>
Any implementation of the wireless Internet framework should use
several parameters including user and device identity, service
authorisation, inter-administration business profiles, service
profile, location information and policy data. These data needs to
operate on database systems that are scaleable to network and end-
user growth and operate with open interfaces to other functional
entities that interact with such data.
The wireless Internet framework needs to support open interfaces to
the various directories and databases, including policy data in
order to allow the management by the MISP of:
* the end-user and service profiles
* management by the end-user of the end-user and service profile
(subject to the necessary authentication and authorisation).
The wireless Internet framework needs to support open interfaces
from the applications layer to allow applications controlled read
and write access to network directories or databases (e.g. end-user
identities, service preferences, terminal capabilities, authorised
services and capabilities) subject to appropriate authorisation and
authentication in line with MISP policies.
Open Interface Requirements
<AT> This is a kind of design policy. It seems that no specific WG is
related to this. </AT>
The wireless Internet framework needs to use open interfaces between
any network entities that may be implemented by MISPs/ISPs and
manufacturers as separate systems, sub-systems, or network entities.
To ensure compatibility with existing cellular mobile networks, the
wireless Internet framework needs to provide direct support for open
'A' and 'Abis' interfaces within the 3GPP2-RAN and 'Iu', 'Iur' and
'Iub' interfaces within the 3GPP-RAN.
The wireless Internet is likely to be populated with many functional
entities and needs to support the separation and independence of
logical functions. The separation of these functional entities will
allow for an implementation of the wireless Internet framework that
maintains the most flexibility and scalability of network entities.
To the maximum extent possible the wireless Internet framework needs
to require that the following functions be logically separate and
independent, both within a logical layer and across logical layers:
* session management
* mobility management
* service control
* gateway control
* gateways (e.g. access, media and signalling)
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* authorisation, authentication and accounting - i.e., the
traditional AAA function should be separated into their component
parts and distributed across the logical layers as appropriate
* database systems or Unified Directory System
* policy management
* resource manager
* address management
For example, session management should be independent of mobility
specific information. This allows communication sessions to be
transparently maintained irrespective of the movement, location and
network connectivity of the terminal or user. The implementation of
mobility management within the wireless Internet framework needs to
allow the MISP to provide a set of common features across the
various access networks.
The wireless Internet framework needs to support the development and
provision of services in a service execution environment, through
the support of open interfaces, e.g. APIs, to network resources and
databases.
Common Access Protocol Set (CAPS)
<AT> IP protocols meet this It seems that no specific WG is related
to this. </AT>
The wireless Internet framework needs to be designed to ensure that
common protocols can be used with various wireless access
technologies (e.g. cdma2000, W-CDMA, wireless LAN, etc.) and
wireline access technologies (e.g. xDSL, Cable, Digital Broadcast,
etc.). The protocols are required to be independent of access
technology. Access technology specific entities in the core network
should be discouraged. The wireless Internet framework needs to
support:
* a unified set of IP centric protocols that can serve as a single,
common network framework for all wireless Internet air interface
technologies
* an access-independent set of protocols that can serve different
access network technologies, both wireline and wireless.
Independence allows harmonisation of protocols throughout various
networks. This is a key design goal as MISP networks expand within,
and across, regional boundaries.
Global Alignment
<AT> ??? </AT>
The wireless Internet framework needs to support global access to
services regardless of access type and location. In order to ensure
the widest level of services for end-users, the wireless Internet
framework should support globally accessible services within the
capabilities of the terminal, access technology and the MISP, via:
* the support of common protocols and open APIs
* the support of concepts such as virtual home environment (VHE)
* a common representation of user service profiles (e.g., XML)
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* access to services from any network or server utilising service
brokering (i.e. the user can negotiate access to services from home
or 3rd party service providers).
Interoperability with non-IP Networks
<AT> I think this is out of IETF's scope. </AT>
The wireless Internet framework needs to provide the capability to
receive sessions from, and terminate sessions to, circuit switched
networks that include public switched and existing cellular mobile
networks. The wireless Internet framework needs to provide support
for roaming users and roaming terminals (with appropriate multi-mode
and multi-band functions). This needs to include roaming between IP
based and non-IP based networks. In detail the wireless Internet
framework needs to support inter-working with GSM MAP and ANSI-41
MAP signalling.
Quality and Reliability
<diffserv> <issll>
The wireless Internet framework should support management and
control of QoS for a wide variety of services at the appropriate
places within its framework - recognising that QoS is implemented in
many places within both the core and access networks. The wireless
Internet framework needs to support QoS bearer capabilities for the
following classes: conversational class, streaming class,
interactive class, and background class, as defined in ITU-R M.1079.
The wireless Internet framework needs to be capable of
simultaneously providing multiple QoS levels to different
applications within the same terminal.
The wireless Internet framework needs to provide the means to
support end-to-end QoS. That is, it needs to support protocols for
the control and negotiation of QoS when interacting with a third
party provided service platform (the MISP and application provider
are both required to ensure that the network entities under their
respective control provide the necessary component of QoS). QoS
across administrative boundaries should be enforced by both network
techniques and business policy enforcement agreements.
The wireless Internet framework needs to provide a scaleable QoS.
That is, the process used to implement QoS within the framework
needs to be capable of the flexible support of additional QoS bearer
attributes and the assignment of specific (preferred) values to
these attributes in order to address evolving capabilities within
the core and access networks.
The wireless Internet framework should be capable of supporting
multiple levels of static QoS (negotiation of parameters before the
session set-up) as well as dynamic QoS (negotiation of parameters
while the session is in progress).
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
Reliability
<AT> I think this is out of IETF's scope. </AT>
Platform, element and system (or sub-system) reliability is driven
by a combination of MISP, end-user, and regulatory needs (e.g.,
support of emergency services). The wireless Internet framework
should support the necessary functionality to ensure that the
necessary reliability can be achieved. That is, the wireless
Internet framework needs to provide the capabilities to support a
deployment of network entities such that in the event of the failure
of a single entity, the performance of the network is not seriously
degraded.
Security
<ipsec> <tls> <cat> <aaa> <pkix>
The wireless Internet framework needs to counter security threats
including:
* Unauthorised access to sensitive data (violation of
confidentiality)
* Eavesdropping: An intruder intercepts messages without detection.
* Masquerading: An intruder hoaxes an authorised user into believing
that they are the legitimate system to obtain confidential
information from the user; or an intruder hoaxes a legitimate system
into believing that they are an authorised user to obtain system
service or confidential information.
* Traffic analysis: An intruder observes the time, rate, length,
source, and destination of messages to determine a user's location
or to learn whether an important business transaction is taking
place.
* Browsing: An intruder searches data storage for sensitive
information.
* Leakage: An intruder obtains sensitive information by exploiting
processes with legitimate access to the data.
* Inference: An intruder observes a reaction from a system by
sending a query or signal to the system. For example, an intruder
may actively initiate communications sessions and then obtain access
to information through observation of the time, rate, length,
sources or destinations of associated messages on the radio
interface.
* Unauthorised manipulation of sensitive data (Violation of
integrity)
* Manipulation of messages: Messages may be deliberately modified,
inserted, replayed, or deleted by an intruder
* Manipulation of databases: Databases may be deliberately modified,
or records deleted by an intruder
* Disturbing or misusing services (leading to denial of service or
reduced availability)
* Intervention: An intruder may prevent an authorised user from
using a service by jamming the user's traffic, signalling, or
control data.
* Resource exhaustion: An intruder may prevent an authorised user
from using a service by overloading the service.
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* Misuse of privileges: A user may exploit their privileges to
obtain unauthorised services or information.
* Abuse of services: An intruder may abuse some special service or
facility to gain an advantage or to cause disruption to the network.
* Repudiation: A user or a network denies actions that have taken
place.
* Unauthorised access to services
* Intruders can access services by masquerading as users or network
entities.
* Users or network entities can get unauthorised access to services
by misusing their access rights
* Defrauding of accounting system (e.g., Users can pass themselves
off as someone else, or hide their identity, in order to avoid
billing charges to there account (and pass charges on to other
accounts. Users can make the accounting system believe that they are
using a quality of service different from the actual one they are
using. Users may steal Subscriber Identity Modules (SIMs) or
terminals)
The wireless Internet framework needs to be designed to meet the
following security objectives:
* ensure that information generated by or relating to a user is
adequately protected against misuse or misappropriation;
* ensure that the resources and services provided by MISPs and
application environments are adequately protected against misuse or
misappropriation;
* ensure that the security features standardised are compatible with
world-wide availability. (There needs to be at least one ciphering
algorithm that can be exported on a world-wide basis
* ensure that the security features are adequately formulated and
standardised to provide effective world-wide interoperability and
roaming between different MISPs, as well as preventing misuse or
misappropriation of network resources by roaming end-users;
* ensure that the level of protection afforded to users and
providers of services is better than that provided in contemporary
fixed and mobile networks;
* ensure that the implementation of current security features and
mechanisms can be extended and enhanced as required by new threats
and services.
The wireless Internet framework needs to be designed to support the
following security features:
* end-user identity confidentiality;
* end-user identity authentication;
* user data confidentiality on physical connections;
* connectionless user data confidentiality;
* signalling information element confidentiality
* user location confidentiality (unless authorised by the user).
Use of these security features is at the discretion of the MISP for
its own end-users while on the home network. For roaming end-users,
use of these security features is mandatory unless otherwise agreed
by all the affected cellular mobile operators
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
The wireless Internet framework needs to support:
* mutual authentication (end-users, 3rd party services, etc.)
* confidentiality
* integrity
* non-repudiation
* encryption (This should be sufficiently flexible to support
different algorithms at an appropriate level to satisfy end-user and
3rd party needs)
* data protection (rights of access, privacy)
* fraud information gathering
The wireless Internet framework needs to support the capability to
generate a security log containing information sufficient for after-
the-fact investigation of loss or impropriety. The security log
should, as a minimum, be capable of recording events such as:
* all sessions established,
* invalid user authentication attempts,
* unauthorised attempts to access resources (including data and
transactions),
* changes in users' security profiles and attributes,
* changes in access rights to resources,
* changes in the network element security configuration,
* modification of network element software.
For each such event, the record should, as a minimum, include date
and time of event, initiator of the event such as: user-ID,
terminal, port, network address, etc., names of resources accessed,
and success or failure of the event.
Privicy
<geopriv>
<AT> Need more work in IETF. </AT>
The wireless Internet framework should provide for the protection of
the privacy of all information provided by end-users. In particular
any information collected in the process of providing service to
end-users should not be reveal to any third party without their
permission.
Network Service & Session Management
<rmonmib> <sming> <smnpconf> <smnpv3> <policy> <aaa>
The high level requirements for the network and service management
of a wireless Internet framework are that it should:
* provide the means by which the behaviour and status of the
network, or its services, can be known at an acceptable practical
level;
* be capable of realising network-wide management policies through
appropriate translation of policies into device-level abstractions
and vice-versa,
* be a highly automated network and service management platform with
well defined human interfaces, processes, functions, data, and
necessary flow through for automation,
* be secure and provide means of protecting the network and end-user
resources, and data against unauthorised modification by end-users
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
or unauthorised personnel, i.e., it should both provide a means of
secure communications with and among management entities, and
provide a means of access control to management system objects,
etc.,
* provide a comprehensive network and service management platform
for supporting necessary configuration, performance, fault,
security, and accounting/billing management functions over multiple
temporal scales (e.g., real-time response, long term maintenance) in
accordance with the business practices of MISPs,
* strive to remain as "technology independent" as possible,
* utilise a common information model for defining the objects,
modules, etc., across different management functions as well as
different technology platforms, and maintain common databases for
managed objects,
* be scaleable and allow that the growth of network and service
management parallels the expansion of the underlying network and
service infrastructure as necessary with minimal disruption in
current end-users' services,
* be built upon relevant IETF network management protocols (e.g.,
SNMP, COPS, etc.) within both the core and access networks, and re-
use relevant ongoing work in other forums to the extent possible,
* be interoperable with the network and service management of the
Internet as well as those of the cellular mobile networks.
The functions of a network and service management system can be
broadly divided into six specific categories:
* Fault Management: including fault detection, reporting and
recovery procedures.
* Configuration Management: including remote configuration
capabilities
* Billing Management / Accounting Management: accounting is the
process, within the wireless Internet framework, by which use of
network resources is recorded and the applicable session detail
records (SDRs) passed to the billing system. (The process of
charging and billing for use of these network resources is under the
control of individual MISPs and is outside the scope of this
Internet Draft)
* Performance Management: including traffic measurement, congestion
detection and reporting
* Security Management: whilst security is important within the
context of network and service management, security is not specific
to this area and is relevant to many areas within the wireless
Internet framework.
* Session Management: to support the function of session management
including the ability to provide session state for both real-time
and non real-time associations between two or more entities.
An important issue that relates to all these tasks is that the
wireless Internet framework should support means of network and
service management over multiple temporal scales. In principle, a
network and service management should support dynamic real-time
actions such as reconfiguration through protection switching),
quasi-dynamic actions (e.g., several hour time span) such as
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
updating the subscription profiles, and "static" actions such as
periodic preparation of end-users' bills. In general, multiple time
scales are supported through different applications (i.e., policies)
using different subsets of the available information/data. These
applications are MISP-specific (probably proprietary too) and are
not subject to standardisation, though the network and service
management data should contain sufficient information for supporting
such applications. In detail the requiremts of each six are:
Fault Management
<snmpv3>??? <rmonmib>????
This is responsible for detection, isolation and recovery of the
network from failures. It also collects information about and
manages the errors/faults occurred in and alarms raised by the
network and/or its elements. More specifically, the fault management
tasks include: Service, network, and element outage reporting
* Alarm surveillance, namely, status monitoring, fault detection,
correlation and reporting
* Fault isolation or localisation through alarm analysis, and their
correlation with reported outages and performance degradations
* Fault recovery through either requesting the configuration
management to reconfigure the network (e.g., re-routeing around the
point of failure) or one of its elements (e.g. activating a
standby), or, scheduling and dispatching of the repair force
* Testing, e.g., performing periodic audits
* Trouble administration, i.e. reception of trouble reports from
end-users, and responding to them appropriately
* Event Monitoring, notifications of events, such as incoming
session, or session abandoned.
Configuration Management
<snmpconf>
This is responsible for network provisioning, end-user profile
management and configuration of network elements (e.g., routers,
network servers) as well as the relations among them. In a wireless
Internet, this module should perform network as well as end-user
configuration management tasks. The network configuration management
should support:
* Reconfiguration and update of network transport, control and
service layer elements (e.g., servers, gateways, routers, etc.) in
the network as necessary
* Management of the address space and the IP address manager
* Provision, translation, and enforcement of network wide
configuration management policies in co-ordination with other
network and service management modules
* Network provisioning, including, radio network planning including
frequency allocation, cell configurations, "optimal" placement of
BTS for maximum coverage, power control, etc., forecasting the
traffic growth, and planning and network sizing for growth and
upgrading of the RAN and as well as the core, reconfiguration of the
RAN or core network topology in response to events and triggers from
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
other network and service management (e.g., fault management, and
performance management) modules.
* Auto-discovery and inventory of network elements in detail,
* Auto-mapping of the network topology,
* Automatic configuration and initialisation of the network and its
services including the configuration and initialisation of
transport, control, and service layer elements,
The end-user configuration management tasks include but not
necessarily limited to
* Configuration of end-user terminals upon subscription, including
assignment of the terminal ID, end-user ID, IP address, etc.
* Preparing the end-user profile and storing it in the profile
server
* Auto-configuration of end-user terminal as necessary
* Updating the end-user profile by the authorised personnel or end-
user as necessary.
Billing Management
<AT> I'm not sure what WGs are related to this. No WGs??? </AT>
This is responsible for collection, storage, and processing of all
necessary data for billing network services according to the value
chain. Specifically billing management performs the following tasks:
* Retrieves (or receives), stores, and processes the accounting
records from the an accounting service to sort, determine and
consolidate each end-user's usage of each subscribed service
* Prepares end-users' bills, and collects them
* Sets the MISP pricing and charging policies taking into account
laws, regulations, MISPs investments and market place conditions,
etc.
* Handles delinquent accounts through periodic reminders or
requesting the configuration manager to suspend subscriptions.
Billing management, beyond the potential definition of the interface
between the accounting service and the billing management system is
outside the scope of the work of this memo.
Performance Management
<rmonmib>?? <ippm>???
This comprises of all functions - data collection, analysis,
comparison and reporting - necessary to ensure QoS and efficient use
of resources in the network. The performance management module
provides means of:
* Performance quality assurance to set and assess the network QoS
policies
* Performance monitoring for event correlation and filtering, and
threshold crossing alerts
* Setting, assessing, and updating of the network traffic management
policies, and
* Performance analysis to make recommendations on performance
improvement, traffic demand forecasting for network expansion,
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
obtain end-user's service and traffic summary, and traffic exception
and capacity analysis, and network performance characterisation
* Setting network wide quality assurance policies
* Translating the quality assurance policies into end-to-end
reliability, availability and survivability (RAS) criteria for the
network, as well as RAS criteria for network elements;
Security Management
<ipsp> <idwg> <pkix> <kink> <krb-wg>
<AT> Need more work in IETF??? </AT>
This is responsible for maintaining the network security
infrastructure (e.g., passwords, security credentials). The
functions of the security management module include but not limited
to
* Setting network-wide security policies and data
* Preventing security breaches through restricting access of
unauthorised users to management information and capabilities
* Detecting security breaches such as unauthorised access,
corruption of data, end-user fraud, and unauthorised actions through
security alarm surveillance, traffic monitoring, and monitoring of
end-users usage patterns
* Containing the damage to the network and users through isolating
viruses that corrupt the data as well as revoking unruly end-users'
privileges to prevent them from performing certain activities
* Managing, establishing, and updating security infrastructure,
credentials and privileges, e.g., key management, frequent password
updates, and maintaining password files
* Performing regular audits to detect breaches, contain them,
restore the services and re-instate integrity of the network.
Over-the-Air Service Provisioning (OTASP)
<AT> This is not directly related to IETF. However, SDR might adopt
IETF protocols for downloading and its security. </AT>
The wireless Internet framework needs to support 'over the air'
activation and provisioning of services, such as terminal code
download of preferred roaming lists, configuration of software
defined radio (SDR), etc. The wireless Internet framework needs to
support over the air parameter administration (e.g. mobile
identity).
Services
<AT> Since this section include a variety of requirements, I put
the WG names on each requirement. </AT>
The wireless Internet framework needs to support the capability for
a wide range of services, including real-time, non-real-time, multi-
media services. In detail, the wireless Internet framework needs to
support:
* Real-time speech of a quality no worse than 2G cellular mobile
networks (e.g. GSM EFR codec).
<diffserv> <issll> <iptel> <avt> <sip>
* Point-to-Multipoint
* IP Broadcast, IP Multicast
<bgmp> <idmr> <msdp> <pim> <ssm> <rmt>
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* Multiple concurrent bearer services to the mobile end-user as well
as fixed end-user
* SMS compatible with current network i.e. point-to-point and cell
broadcast
* Enhanced SMS, supporting simple text formatting, user-defined
pictures, predefined and user defined sounds and animation
* Location services (geographic position information)
<geopriv>
* Acquisition of geographical position information via a variety of
techniques, e.g. network position determination equipment, Cell-ID,
GPS assisted, depending on the positional accuracy required and the
capabilities of the mobile terminal
* The transfer of geographical position information to applications
to enable provision by the MISP of location-based services
<geopriv>
* The transfer of geographical position information to emergency
services
<geopriv>
* Personalised Services based on Network Provided Identity
* The provision of the network authenticated identity to
applications to enable support of personalised services
* Calling Line Identification (CLI) services, including CLIP, CLIR
The requirements of the service interface are:
* To provide a common interface between the applications and the
underlying network that: is independent of the core network and
access network technology; is independent of the specific network
configuration; is agnostic to changes in the network configuration;
is independent of specific protocols used within the network, and is
readily extensible by the MISP to meet specific requirements;
* To provide controlled and/or restricted access (via authentication
and authorisation) to network resources in line with policies
defined by the MISP;
<aaa> <rap>
* To support the transfer of accounting and billing records between
the network and the application in respect of network resources used
by that application;
<aaa>
* To allow applications to be ported across different networks and
to operate consistently across those networks;
* To support service registration and discovery procedures, so that
an application determine the service interfaces that are available;
* To provide a standard, widely understood, interface that
encourages the provision of services by different parties.
In practice there may be several levels or types of service
interfaces supported by the network to allow various types of
service to be developed. The wireless Internet framework needs to
support open interfaces from between the services and transport
layers as well as between the control and transport.
Roaming
<aaa> <mobileip>
Given that the objective of the wireless Internet framework is to
support service provision to roaming end-users from their home MISP,
it needs to be possible for the home MISP to:
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
* Control access to services depending on the location of the user,
and roamed MISP
* Control access to services on a per user basis e.g. subject to
subscription
* Control access to services depending on available service
capabilities both in the roamed MISP and in the terminals
* Manage service delivery based on for example end-to-end
capabilities and user preferences
* Request version of specific services supported in roamed MISP and
terminal
* Request details (e.g. protocol versions and API versions) of
available service capabilities supported in the roamed MISP, and
terminals;
* Define the scope for management of services by the user, for
services provided by the home MISP
* Inform the roamed MISP of the type of charging (i.e. prepaid
or/and post-paid) for any required service
* Inform the roamed MISP of the threshold set for a given service
required by the user and charged on a prepaid account
* Inform the roamed MISP how to manage a service for which the
threshold has been reached
* Manage the prepaid accounts (e.g. increase, decrease the credit,
or pass the information to any application which manages the
credit);
* Deploy services to users or groups of users
* Manage provision of services to users or groups of users.
In supporting service provision via the home MISP, it needs to be
possible for the visited MISP to perform the following:
* Provide the necessary service capabilities to support the services
from the home environment as far as possible
* Dynamically provides information on the available service
capabilities in the visited network
* Provide transparent communication between clients and servers in
terminals and networks
* Request the charging information (type of charging, threshold for
prepaid services and behaviour if the threshold is reached) for any
service possibly required by the user
* Handle the session according to the instructions received by the
home environment regarding charging activities
* Inform the home environment of the chargeable events (e.g. send
SDRs).
Mobile Internet Service Provider (MISP) Requirements for a Wireless
Internet Framework (WIF) May 2001
References
Author's Address
Paul Reynolds
Orange
Bradley Stoke
Bristol Phone: +44 7 973 746 050