[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:
Very helpful comments. Regards John
"Dana L. Blair" wrote:
> 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 ?
>
> ...