Architecture, Mobility Management and Performance Issues ...dutta/research/thesis... ·...
37
Architecture, Mobility Management and Performance Issues for Wireless Internet Telephony and Multicast Streaming Thesis Proposal by Ashutosh Dutta [email protected] Advisor: Prof. Henning Schulzrinne Abstract Future mobile wireless Internet will need to support flexible interactive services such as wireless Internet telephony and other streaming services like delivery of multimedia content over wireless net- works. This thesis proposal focuses on application layer mobility management schemes for wireless Internet telephony and multicast content distribution in a mobile environment involving heteroge- neous access networks. We propose an application layer mobility management scheme for wireless Internet telephony and streaming services. We focus our analysis on certain aspects of the design such as terminal mobility supporting security, quality of service and fast-handoff mechanism over heterogeneous networks. Many of the functional components such as signaling, registration, hand- off, and session continuity associated with wireless Internet telephony have been prototyped. We have carried out the performance evaluation with other layer three mobility management protocols such as Mobile IP, MIP-LR, Mobile IPv6, IDMP and host-based routing such as MMP. As part of providing streaming services to the mobile users we have designed a multicast-based overlay con- tent distribution network called MarconiNet using extension of standard IETF based protocols such as SIP, RTP/RTCP, SAP and SDP. Several functionalcomponentsof MarconiNet such as local ad- vertisement, handoff and quality of service associated with a scalable content distribution network have been analyzed. A prototype system has been built using hierarchical scope based multicast and application layer triggering techniques. 1 Introduction Lately, streaming real-time multimedia content over the Internet is gaining momentum in the communi- cations, entertainment, music and interactive game industries. Real-time applications include interactive services such as IP telephony, multiplayer games and streaming services such as broadcasting multime- dia content, multi-party conferences and collaborations. Thus, it is most desirable to build a streaming infrastructure that can support flexible next generation Internet applications in a scalable way using various heterogeneous access technologies. This proposal is organized as follows. Section 2 describes the problem, background and the inno- vative claims associated with various parts of the thesis. Section 3 elaborates the issues and describes related work in the area of mobility management for the wireless Internet. Section 4 explains the initial results of application layer mobility management for wireless Internet. Section 5 provides a roadmap for completion of mobility management work. Section 6 introduces MarconiNet architecture and describes the issues and requirements in the area of content distribution. Section 7 discusses the related work for multicast streaming and content distribution. We describe initial prototype implementation and perfor- mance results of MarconiNet architecture in section 8. Section 9 provides a roadmap for completion of work in the MarconiNet area. Finally Section 10 concludes the thesis proposal. 1
Transcript of Architecture, Mobility Management and Performance Issues ...dutta/research/thesis... ·...
Architecture, Mobility Management and Performance Issues forWireless Internet Telephony and Multicast Streaming
Thesis Proposal by Ashutosh [email protected]
Advisor: Prof. Henning Schulzrinne
Abstract
Future mobile wireless Internet will need to support flexible interactive services such as wirelessInternet telephony and other streaming services like delivery of multimedia content over wireless net-works. This thesis proposal focuses on application layer mobility management schemes for wirelessInternet telephony and multicast content distribution in a mobile environment involving heteroge-neous access networks. We propose an application layer mobility management scheme for wirelessInternet telephony and streaming services. We focus our analysis on certain aspects of the designsuch as terminal mobility supporting security, quality of service and fast-handoff mechanism overheterogeneous networks. Many of the functional components such as signaling, registration, hand-off, and session continuity associated with wireless Internet telephony have been prototyped. Wehave carried out the performance evaluation with other layer three mobility management protocolssuch as Mobile IP, MIP-LR, Mobile IPv6, IDMP and host-based routing such as MMP. As part ofproviding streaming services to the mobile users we have designed a multicast-based overlay con-tent distribution network called MarconiNet using extension of standard IETF based protocols suchas SIP, RTP/RTCP, SAP and SDP. Several functional components of MarconiNet such as local ad-vertisement, handoff and quality of service associated with a scalable content distribution networkhave been analyzed. A prototype system has been built using hierarchical scope based multicast andapplication layer triggering techniques.
1 Introduction
Lately, streaming real-time multimedia content over the Internet is gaining momentum in the communi-cations, entertainment, music and interactive game industries. Real-time applications include interactiveservices such as IP telephony, multiplayer games and streaming services such as broadcasting multime-dia content, multi-party conferences and collaborations. Thus, it is most desirable to build a streaminginfrastructure that can support flexible next generation Internet applications in a scalable way usingvarious heterogeneous access technologies.
This proposal is organized as follows. Section 2 describes the problem, background and the inno-vative claims associated with various parts of the thesis. Section 3 elaborates the issues and describesrelated work in the area of mobility management for the wireless Internet. Section 4 explains the initialresults of application layer mobility management for wireless Internet. Section 5 provides a roadmap forcompletion of mobility management work. Section 6 introduces MarconiNet architecture and describesthe issues and requirements in the area of content distribution. Section 7 discusses the related work formulticast streaming and content distribution. We describe initial prototype implementation and perfor-mance results of MarconiNet architecture in section 8. Section 9 provides a roadmap for completion ofwork in the MarconiNet area. Finally Section 10 concludes the thesis proposal.
1
2 Problem Statement and Background
Multimedia streaming applications are far more demanding in terms of bandwidth and have stringentrequirements for latency and reliability than traditional TCP/IP based applications and are thus idealdrivers for the Internet. In addition, they may require multicast support to provide flexible streamingservices and take care of bandwidth bottleneck. With the advent of ubiquitous access and personalcommunication, it is necessary to design network technologies that can support flexible applicationssuch as mobile IP-telephony and multimedia streaming applications over a wireless IP network. Inorder to support multimedia applications over wireless links one has to consider several factors such assignaling, registration, configuration, quality of service, bandwidth management, mobility managementand authentication, among others.
Currently there are many mobility management protocols available to take care of mobility of theend hosts and support content distribution in the Internet. However many of the current solutions re-quire that changes be made to the end hosts and these solutions also depend on several other networkingcomponents in the middle of the network such as foreign agent and home agent. In order to alleviatethe drawbacks associated with the available solutions we have proposed a novel application layer mo-bility management scheme that takes care of Internet telephony and streaming services such as contentdistribution for the mobile Internet. The proposed mobility management scheme is network layer andphysical layer agnostic and does not depend upon the intermediate network layer components except forrouting functions. It also warrants no changes in end-clients.
This proposal consists of two main parts. The first part deals with application layer mobility man-agement for interactive services such as Internet telephony, its architecture, prototypes and performanceanalysis. We mainly focus on supporting secured SIP-based terminal mobility (both intra-domain andinter-domain), its co-existence with other mobility protocols and fast-handoff approaches. The secondpart of the thesis proposal deals with scalable mobile content distribution. An application layer multicastcontent distribution architecture called MarconiNet has been designed. Several basic features associatedwith MarconiNet are implemented in a multimedia test-bed including novel techniques to support QoSand fast-handoff.
2.1 Innovative Features
Following are some of the innovative claims categorized mainly by the two main parts of the thesis suchas wireless Internet telephony and mobile streaming multimedia (MarconiNet).
1. Innovative claims for Wireless Internet Telephony and Mobility Management
(a) A secure application layer mobility management scheme for both real-time (RTP/UDP) andnon-real-time (TCP/IP) traffic has been designed and implemented in IPv4 and IPv6 net-works. We have enhanced SIP-based terminal mobility to support wireless Internet roaming.An application layer approach for mobile IP with Location Register (MIP-LR) provides anenhanced mechanism to take care of mobility binding of TCP based application. SIP-basedmobility proxy and SIP-EYE approaches provide alternative solutions that take care of mo-bility for TCP-based application by using SIP signaling. In addition to providing networklayer and kernel layer independence these new mobility management approaches provide thefollowing performance improvement; 35 percent more bandwidth utilization, 50 percent la-tency improvement and 50 percent reduction in management overhead for large size packetscompared to standard mobile IP approach. Section 4.2 describes some of the initial resultsin this area.
(b) A comprehensive mobile multimedia testbed has been designed and implemented that pro-vides the proof-of-concept of different required functionalities of a mobile wireless Internet.These functionalities include signaling, registration, configuration, mobility binding, loca-tion management, security and quality of service. It involves variety of radio access tech-nologies such as Bluetooth, 802.11b, CDMA, GPRS and can demonstrate micro, macro and
2
domain mobility involving pedestrian and vehicular users. Such a comprehensive testbedis beneficial to any wireless operator who may like to experiment the above functionalitiesbefore these are actually deployed in a wide scale manner. Section 4.2 describes the design,implementation and results of secured SIP-based terminal mobility involving heterogeneousaccess technologies.
(c) Several fast-handoff approaches in the network and application layer are proposed to expe-dite IP address discovery process and redirection of the multimedia stream as the mobilemoves between subnets within a domain. These include network layer approach based onIDMP (Intra Domain Mobility Management Protocol), application layer approach based onSIP, proactive authentication and IP address discovery mechanism. These mechanisms of-fer better performance results of up to 50 percent compared to the existing handoff scheme.Section 4.3 describes the detailed mechanism of several fast-handoff approaches.
(d) A policy-based adaptive integrated mobility management scheme was developed to take careof real-time and non-real-time traffic both for intra-domain and inter-domain mobility for amilitary specific ad hoc type network. Based on the type of movement and kind of applica-tion being supported, this integrated mobility management technique can adapt accordingly.This scheme provides a layered mobility management approach such as, using SIP-basedmobility management for real-time traffic (RTP/UDP); use MIP-LR (Mobile IP with Loca-tion Register) to support non-real-time (TCP/IP traffic) for inter-domain mobility; use IDMPfor inter subnet mobility within a domain and use MMP during movement within a sub-net. Section 4.4 provides an overview of the design and initial results of integrated mobilitymanagement work.
2. Innovative claims for MarconiNet
(a) Application layer multicasting is exploited to provide scalable live and on-demand streamingcontent for wider and global reach. It leverages extensions of standard real-time protocolsdeveloped within the IETF to provide an application layer solution that can be programmedas per the user’s needs. Many of the applications are taken care of without depending muchon the existing network layer protocols. Section 8.1 describes the architecture and associatedcomponents. This section also highlights some of the features described below.
(b) A scope-based multicast mechanism has been used for selective content distribution. Scal-ability and local control are achieved by providing localized servers and hierarchical multi-cast. Local server-based control provides selective content distribution between local pro-gram and global program.
(c) A new mechanism has been developed that provides automatic localized advertisement orcommercial content insertion into a global program. As per a pre-determined schedule oron-demand basis, local commercial content can be inserted into a program for a specificduration. Thus it provides flexibility of switching between global and local programs withlarger variety of localized content.
(d) An application layer triggering mechanism reduces join/leave latency thus making channelsurfing more efficient than that is achieved through regular network layer triggering method-ology. It leverages on feedback control mechanism for real-time traffic.
(e) Real-time client (listener, viewer) index for global and local programs provides demographicinformation about the users. Real-time index of how many people are tuned into a particularchannel and how often people are surfing around provide a mechanism for developing anovel payment scheme.
(f) New fast-handoff techniques have been designed to provide smooth hand-off for multi-cast streaming in MarconiNet environment while conserving the bandwidth during mobile’smovement between local servers. Section 8.2 discusses various fast-handoff mechanism to
3
accommodate the mobile users. Section 8.5 shows the results of the initial prototype imple-mentation in the testbed.
(g) An application layer scheme has been designed that ensures quality of service of the multi-media stream as the mobile moves between the subnets within a domain. Feedback mech-anism associated with real-time traffic helps to provide adaptive QoS for the mobile users.Section 8.3 describes the QoS mechanism associated with MarconiNet.
3 Application Layer Mobility Management for Wireless Internet
This section concentrates on the innovative research proposed and conducted towards application layermobility management to support RTP- and TCP-based application for wireless Internet. Issues, relatedwork, architecture, testbed, performance analysis and future work are discussed in this section.
3.1 Mobility Management Issues and Requirement
Dutta et al [1] provide an analysis of the requirements associated with supporting wireless Internettelephony. Mobility management scheme of wireless Internet will need to support personal, serviceand terminal mobility for the roaming users independent of underlying wireless technology such asW-CDMA, 802.11b and TDMA. It supports both real-time and non-real-time services such as mobiletelephony and mobile web access. In order to support universal roaming involving multiple domains, themobility management scheme should interact effectively with DHCP [2] [3] or PPP [4] servers for IPaddress acquisition, SIP servers for registration and AAA servers to verify the user’s identity and profiles,as well as should ensure that the QoS requirements and applications are satisfied and maintained as usersroam around. It transparently supports both TCP and RTP/UDP based applications without requiringany changes to TCP or TCP-based application. It should take care of many important issues such asregistration, configuration, dynamic binding, and location management for inter-domain mobility.
3.2 Related Mobile Networking Technologies
Supporting mobility in the Internet is primarily intended to allow a mobile device to move betweendifferent cells, subnets, and domains while keeping an on-going multimedia session alive and beingable to be located irrespective of its point of attachment. Several protocols and mechanisms have beendeveloped to support intra-domain and inter-domain mobility in the Internet. Dutta et al [5] provide ashort survey of mobility management techniques available currently. Here we provide a brief descriptionof these protocols.
Current mobility management techniques can be implemented at several layers of the protocol stack,such as networking layer, transport layer and application layer. Depending upon the type of mobile’smovement it can be divided into micro and macro mobility. Mobile IP (MIP) is a mechanism developedfor the network layer to support mobility [6]. However Mobile IPv4 introduces network elements suchas home agent and foreign agent and suffers from triangular routing and extra IP-IP encapsulation [7],[8] of 8 or 20 bytes, thus causing performance degradation. Mobile IPv4 usually works in two differentmodes, foreign agent mode and co-located mode. In co-located mode new address in the foreign networkis obtained via services like DHCP (Dynamic Host Configuration Protocol) or its faster variants such asDHCP with rapid commit option [9], DRCP [10] in a Local Area Network (LAN) and PPP in wide areascenario. There are several proposals [11],[12] that help take care of the triangular routing problem,by means of direct binding update, regional registration and other smooth handoff techniques [56]. Butmany of these solutions require kernel modification thus making it difficult for deployment.
Cellular IP approach [13] and HAWAII (Handoff Aware Wireless Access Internet Infrastructure) [14]are network layer micro-mobility management protocol. These take care of Mobile IP’s inefficiency bysupporting intra-domain mobility and host based routing. Both of these approaches separate local and
4
wide area mobility (i.e., adopt a domain-based approach) and use Mobile IP for inter-domain (wide area)mobility.
Mobile IP with Location Registers (MIP-LR) is another network layer scheme developed to avoidencapsulation of packets [15] and to provide survivability in an ad-hoc network such as military net-works. It does so by replicating multiple location registers (LRs). Address management is done byDHCP servers and HLRs (Home Location Registers) provide the location updates to each correspondinghost wishing to communicate with any mobile user in the beginning. As part of this proposed work, anapplication layer MIP-LR has been investigated.
TeleMIP (Telecommunications-Enhanced Mobile IP), is an intra-domain mobility framework thatuses two layers of scoping within a domain and is based on IDMP [16]. By specifying an intra-domaintermination point called mobility agent (MA) it helps to reduce the signaling updates due to movementwithin a domain and thus reduces the loss of transient traffic due to frequent hand-offs within a domain.As part of this proposal fast-handoff techniques for IDMP have been designed.
Mobile IPv6 [17] provides network layer mobility framework for IPv6. Since address autoconfigu-ration is a standard part of MIPv6, MH will always obtain a COA that is routable to the foreign network.Thus there is no need to have an FA in MIPv6 framework. When the mobile node moves to a new foreignnetwork it acquires a temporary care-of-address using stateless auto-configuration [18] or DHCPv6 [3].
There are a few transport layer mobility solutions. TCP-Migrate approach [19] proposes a new setof migrate options for TCP which provide a pure end-system alternative to network layer solutions.With this extension, established TCP connections can be suspended by a TCP peer and be reactivatedfrom another IP address without a third party (except for the involvement of dynamic DNS updates).However this approach requires modifying the transport protocol at the end-terminals. MSOCKS [20] isanother transport layer solution that introduces proxy in the middle of a network and is built on the topof SOCKS protocol [21] for firewall traversal. Upon movement of the mobile and its address change, theintermediary proxy helps splice the TCP connection. The recently developed transport protocol SCTP(Stream Control Transport Protocol) [22] has a built-in ADDIP feature that helps support continuitywhen the mobile’s IP address changes.
Application layer mobility uses the Session Initiation Protocol (SIP) as the signaling mechanism[23]. This mechanism does not depend upon the home agent or foreign agent in the middle of thenetwork nor does it require changes in the end hosts. Thus, it will help easier deployment of mobilitymanagement solution for wireless Internet.
Table 1 shows a qualitative comparison of some of the available mobility management protocolsdescribed above. The mobility protocols with an “*” next to it have been developed or enhanced as partof this thesis proposal.
4 Initial results on Mobility Management
As part of the initial work related to mobility management we focus our work on architecture, models,mechanisms, prototypes and performance results based on simulation and experiments. My initial workin this area can further be categorized into the following sub-categories.
1. Mobility management architecture, test-bed implementation and performance analysis
(a) Functional Architecture for Wireless Internet
Section 4.1 describes the wireless Internet architecture that has been designed and imple-mented in the multi-media testbed.
(b) SIP-based Mobility Management Performance and Measurement
Section 4.2 discusses the design, implementation and performance measurement of severalfunctional components of SIP-based mobility management scheme. Following are some ofthe functional components that are prototyped in the multimedia testbed.
5
Table 1: Survey of Mobility Management Protocols
Mobility
Type
**
"O" - YES, "--" - NO
**
TeleMIP **
LR
Inter-domainEncapsulation
Changes toend Systems
Triangle
routing
Infrastructure
ChangeProtocolMobility
EncapsulationIntra-domain
Mobile IPV4
TCP-Migrate
HAWAII
MIP with
MIPv6
MIP-RO
MIP-RR
MIP with
FA assisted
SIP
Fast-Handoff Layer
Network
Network
Network
Network
Network
Network
Network
Network
Network
Transport
Transport
Application
Macro
Macro
Macro
Macro
Macro
Macro
Macro
Micro
Micro
Macro
Macro
LR
MSOCKS
O O O O -- --
-- -- O -- -- O
O O O -- -- --
O O -- O -- O
O O-- O O O
O O -- O O O
-- -- O -- -- O
-- O -- O O O
--O
O O O O
-- -- O -- O --
-- -- O -- O --
-- -- -- -- -- O
Cellular IP **
Macro
i. SIP-based terminal mobility (IPv4 and IPv6) for both real-time (RTP/UDP) and non-real-time (TCP application)
ii. Heterogeneous mobility involving both CDMA and 802.11 networks
iii. Multi-layered security framework using SIP-based architecture
2. Mobility management fast-handoff mechanism
Section 4.3 describes several fast-handoff techniques at different layers that will help reduce thetransient data loss during a mobile’s movement. Following are some of fast-handoff techniquesthat were designed.
(a) Application layer based on SIP components
Section 4.3.2 describes the fast-handoff techniques associated with SIP-based mobility man-agement.
(b) Network layer based on IDMP fast-handoff mechanism
Section 4.3.3 describes the techniques associated with the network layer IDMP.
(c) Pre-authentication and proactive IP address acquisition methods
Section 4.3.4 describes some of the related effort to speed up the handoff by providing pre-authentication and procative IP address acquisition methods for both IPv4 and IPv6 net-works.
3. Policy based Integrated Mobility Management for Ad hoc networks
Section 4.4 describes the details of how an integrated policy-based mobility management com-bines SIP-based mobility management, MIP-LR and micro-mobility management (MMP) tech-niques to support different types of application and variety of movement associated with the mo-bile.
4.1 Architecture for Mobile Wireless Internet Telephony
The proposed mobility management framework is based on the application layer signaling protocol SIP[24]. It uses a set of standard IETF protocols for supporting real-time and non-real-time multimedia ap-plications on mobile terminals of next generation wireless (3G/4G) networks. In order to build a wireless
6
Internet roaming architecture, several functional elements such as handoff, network detection, signaling,network configuration, registration, location management, mobility, dynamic binding and AAA featuresare needed. The framework described in this section provides an application layer approach for real-time (RTP/UDP) and non-real-time (TCP/IP) traffic for both IPv4- and IPv6-based network. Figure 1illustrates the Internet roaming architecture realized as part of this proposal. It shows how a mobile userkeeps moving from its home base in the Internet, and is subjected to different kinds of hand-off suchas micro (cell), macro (subnet), and domain handoff as it moves between heterogeneous networks. Italso shows various functional elements within a domain that interact with each other to support varioustypes of mobility mentioned above. Each domain is equipped with network elements such as mobilityservers, QoS servers, AAA servers, SIP servers, and DHCP servers that provide the desired functional-ities. These functional elements can also interact with similar entities within a public domain such aspublic SIP server or AAA server to support inter-domain mobility. Dutta et al [25] describe the detailsof the wireless Internet architecture.
There are various kinds of mobility that need to be supported in a wireless Internet. These are namelyservice mobility, personal mobility, session mobility and terminal mobility. While all of these mobilitytypes are essential, we have focused our work on the terminal mobility only.
Figure 1: Mobile wireless Internet roaming architecture
4.2 SIP-based Terminal mobility
Primarily, terminal mobility can be categorized as pre-session and mid-session. Pre-session mobilitygenerally does not contribute to the delay for the media delivery associated with the on-going session,but may add delay to any new session. Mid-session terminal mobility provides a means of cell, subnetand domain hand-off while the session is in progress. Traditionally, terminal mobility is taken care of bynetwork layer mechanisms such as Mobile IP and its variants. The proposed scheme enhances the SIP-based terminal mobility for RTP/UDP traffic [26] to support roaming users in the wireless Internet andhas implemented the additional features in a comprehensive multimedia testbed. We have also proposedfew methods to support non-real-time (TCP/IP) traffic using SIP-based signaling mechanism.
We have built the Internet multimedia testbed that is based on a framework discussed by Dutta etal in [1] and [27]. This test-bed illustrates a proof-of-concept of a next generation wireless network[28] that provides support for roaming across different carrier domains (e.g., micro, macro, and domainmobility). In the mobile multi-media testbed, we have prototyped several components of wireless In-ternet telephony such as signaling, registration, configuration, binding, authentication, and QoS. It alsoshows the integration with a PSTN network by means of interaction with other signaling protocols suchas MGCP [29] and telephony gateways based on SIP. Localized streaming services for the mobile usershave been demonstrated by using wireless multicast in the local domain as described in [30]. Table 2
7
Table 2: Multimedia testbed protocol suite
(IPv4/IPv6)
Details/Remarks
Quality of
Registration
Inter-DomainAuthentication
Local Authentication
Packet Encryption
Mobility Binding
Service
Configuration
Signaling
Location Management
Application Layer (RTP/RTCP)
ProtocolsFunctionality
Indoor/Outdoor mobility supporting audio/video/white board
Application Layer TriggeringIntra-domain Mobility with fast-handoffLocalized Multicast based application
Dynamically allocates QoS during subnet handoff
AAA is involved only after it changes it changes the domain
Re-registration after the move helps update the location
SIP for IP end-pointsMGCP for Non-IP end-Points
Faster registration protcol for wireless roaming users
Protocol for user to network authentication
SIP-AAA interaction before a successful SIP registration
Inter AAA interaction during domain handoff
SIP/MGCP/H-323
DRCP - Fast-DHCP, DHCPv6
PANA
IPSEC, SRTP
Diameter
SIP registration
Dynamic DNS for non SIP sessions
PIM/DVMRPMulticast
IDMP, MIPLR, MIPv6
SIP and DSNP
SIP -based Terminal Mobility
shows different protocol suite and their associated functionalities that are realized in the testbed. Forthe sake of brevity, description of each of the hardware and software components associated with thetestbed is not presented here. Below we describe how SIP-based terminal mobility can be supported forboth RTP/UDP and TCP/IP traffic in the wireless Internet and discuss some of the experimental resultscarried out in the testbed.
4.2.1 Terminal Mobility for Real-Time application
RTP/UDP based multimedia applications typically have stringent delay and loss budget (e.g., 500 msround trip delay, up to 3 percent packet loss) to support a reliable communication. Thus it is advis-able to avoid the triangular routing and any kind of encapsulation mechanism that contribute to perfor-mance degradation. SIP-based terminal mobility techniques were originally proposed by Wedlund andSchulzrinne [26], [23]. Dutta et al [1] extend the SIP-based terminal mobility and add roaming supportfor the wireless Internet. As part of this we have implemented the SIP-based terminal mobility in thecomprehensive wireless multimedia testbed and have added support for various types of mobility (e.g.,cell, subnet, domain), heterogeneous access, fast-handoff, QoS and security. SIP signaling can supportsubnet and domain handoff, while cell hand-off is taken care of completely by the link layer mechanism.SIP-based terminal mobility will however benefit from layer two triggering mechanism using cross-layeroptimization techniques.
We augment SIP-based terminal mobility with a complete hand-off process that is supported by acombination of network detection, registration, configuration, dynamic address binding, security andlocation management functions. Below we describe some of these functions briefly.
Hand-off is a process that allows an established call or session to continue when an MS (MobileStation) moves from one cell to another without interruptions in the call or session. This hand-offprocess can be either hard or soft [31]. For a real-time interactive communication the handoff timeshould be kept to a MAHT (Maximum Allowable Handoff Time) of 1 second. In end-to-end wireless IPenvironment, we have defined three logical levels of hand-off procedure such as cell, subnet and domainbased handoff. A handoff process is initiated by detection of network attachment (DNA). As the mobilemoves, detection of a new cell, subnet, domain can be realized in different layers. During a mobile’shandoff, first movement detection takes place in layer 2, where the client decides to switch over to a newbase station, based on the signal strength of the received beacon such as in 802.11 networks followed by
8
Table 3: Survey of IP discovery methods
Handoff TimeTriggering Methods
DHCP DHCPw/o ARPDelta2
DRCPDelta 2
DHCPv6Delta 2 PPP
MIP (Delta2)
FACOA
FAco-COA
Auto-IPL2 Switch
802.11 CDMASoft H/O
Static IP
OS
Delta2
Linux
ms160 ms 7-8
seconds
1-2seconds
Same asDHCP/DRCP
N/A 100-150ms(beaconinterval)
~27 ms 100-200ms
L3 (Server) L3 Server L2(Client)
L3(Server)
Server N/A SNRThreshold
PilotSignal
L2/L3L2
(Client)
L2
(Client)
300-400 ~100 ms~4-15
seconds
500 ms
Triggering
Method
HandoffTime
Advanced-IP
Stateless Stateful
TBD
Proactive
a layer 3 handoff. Several layer 3 triggering mechanisms such as router advertisement, application layerdetection mechanism using DRCP server advertisement [10] or geographically coordinate-based handoffmechanism [32] can be utilized to expedite the subnet level handoff. There are several layer 2 assistedfast-handoff mechanisms [33] to expedite the handoff as the client moves between cells belonging todifferent subnets.
As a MS moves between subnets, it re-configures itself by acquiring a new IP address, new defaultgateway, subnet mask and other server parameters such as DNS and SIP server. In case of subnethandoff MS interacts with DHCP or one of its fast variants [10] to reconfigure itself, this process takes around trip MS-DHCP-MS propagation delay. MS re-invites the corresponding host to its new temporaryaddress. MS also initiates a registration process that triggers local SIP server to update its locationinformation in the home registrar.
In case of subnet movement, typical time for acquiring an IP address will depend on the protocolbeing used. DHCPv4 takes of the order of 5-15 seconds [34]. There are other variants of DHCP [10]and [9] that propose faster IP address acquisition techniques. Table 3 provides a survey of IP addressdiscovery methods under Linux operating system. We are currently investigating advanced-IP addressconfiguration method to help expedite the IP address acquisition process.
Domain handoff involves movement between administrative domains and requires additional stepssuch as local authentication and profile verification and will thus contribute to the delay. In case ofdomain hand-off a complete registration takes place where there is an interaction between the AAAservers in each domain.
SIP’s URI scheme, registration mechanism [35] and dynamic DNS have been implemented to pro-vide the pre-session mobility and location management features. Registration process comprises ofsending a registration request from the MS to the SIP server with the new IP address after the mobile hasmoved. But before a registration is successful it will go through the local access authentication basedon PANA (Protocol for carrying Authentication to Network Access) and will be subjected to AAA (Ac-counting, Authorization, Auditing) verification process by the network. A successful registration updatesthe current location of the mobile for any new upcoming session.
4.2.2 SIP-based subnet mobility
Figure 2 shows latency comparison between SIP-based and MIP-based terminal mobility during thesubnet handoff. Curves show the relative performance improvement of SIP over Mobile IP for differentpacket size analyzed both from NS2 based simulation and laboratory experiment. By using SIP formobility management one can expect to have 50 percent latency improvement in real-time (RTP/UDP)traffic thus providing a reduction in latency from a baseline of 27 ms to 16 ms for large packets and a35 percent utilization increase 60 bytes/packet size compared with baseline of 80 bytes/packet size with
9
IP-in-IP encapsulation in Mobile IP.
Figure 2: Latency comparison of SIP/MIP based mobility
4.2.3 Inter-domain secured terminal mobility
A multi-layer security framework based on SIP-centric architecture has been designed and implementedto provide an end-to-end secured mobile multimedia communication. It provides access control to thenetwork using PANA [36], profile verification using Diameter [37], last-hop-over the air protection usingpacket based encryption such as IPSec. End-to-end security for multi-media traffic (e.g., audio, video) isprovided by SRTP (Secured RTP) [38]. SRTP avoids the setting up end-to-end IPSEC tunnels betweenthe end points during the mobile’s movement. SRTP key is distributed securely using INVITE exchangeand S/MIME [39]. We have implemented both Mobile IP and SIP-based mobility techniques to providedynamic binding of the session and have compared the results. Mobile multimedia communication withinter-domain mobility has been emulated by creating two different AAA domains. According to theSIP-AAA model defined in the testbed, when the SIP server receives a SIP REGISTER message fromthe MH, it consults with the home AAA server for authentication and authorization by using Diameteras the backend protocol. Several methods have been proposed such as [35] and [40] that describe theentire scenario of SIP-AAA interaction. We use PANA for distributing IKE (Internet Key Exchange)credentials to an authorized host. The credentials are then used for establishing an IPsec tunnel betweena host and the first hop access router, that provides a secure communication channel in the access networkincluding a wireless LAN segment. The dynamic distribution of the IKE credentials enables hosts toroam among different administrative domains since there is no need for a host to pre-configure thecredentials. Dutta et al [25], [41] provide the details the experimental results.
Domain handoff delay is comprised of several components such as delay due to 802.11b channelchange, subnet and domain discovery, IP address acquisition, local authentication by means of PANA,profile verification using AAA diameter, and delay due to SIP Re-INVITE or MIP registration. InSIP-based mobility experiment, a complete Re-INVITE, OK and ACK sequence took about 500 msincluding the processing time at the end hosts. In the specific laboratory environment it took about 100ms processing time between messages at the end host, and 70 ms for each message to traverse betweenthe end points. Address acquisition time due to message traversal of DRCP messages in a specific subnetis about 100 ms. However it does not include the extra time needed to check the layer 2 channel change(typically 100 ms for 802.11b access point ) or periodic DRCP server advertisement (tunable parameter).A typical SIP registration to update client’s new IP address in the SIP registrar takes about 150 ms. Itis noteworthy to mention that the delay parameters strongly depend on media used, number of routersin the path, background traffic, number of hops, authentication methods and processing speed of thecorrespondent and mobile hosts. Figure 3 shows a protocol sequence associated with domain hand-off
10
using SIP mobility and interaction of the protocols involved. Table 4 shows the timing associated withexecution of different protocols during handoff. Figures 4 shows the sequence of protocols includingRTP packets received on the mobile during inter-domain handoff using SIP-based mobility scheme. Themobile loses fewer packets compared to MIP-based mobility during the inter-domain mobility.
Figure 3: SIP-based secured interdomain mobility
Table 4: SIP-based handoff timing
HandoffType Values RTP1 RTP2 DRCP
Handoff
Average
StandardDeviation
Average
Standard
Deviation
DRCP+PANA+SIP
0.30662
After Handoff
Subnet
Domain
f Priot-to-handoff
(ms) (ms) (ms) PANA (ms) SIP (ms)
(ms)
322 1814 79 2 227 308
70 492 33 5 255 289
241 190 81 28945
70 14 2 254
415
271
Handoff
4.2.4 SIP-based mobility across heterogeneous networks
Secure and seamless universal roaming will require mobility support that will involve movement be-tween heterogeneous access networks. As part of this proposal we have experimented both mobile IPand SIP-based mobility schemes to provide secure and seamless universal roaming involving heteroge-neous access such as 802.11 and CDMA1XRTT. Dutta et al [42] provide an overview of how SIP-basedmobility management works over heterogeneous networks (e.g., 802.11b, W-CDMA, GPRS). It has alsolooked into various key issues such as network detection, active interface identification, registration,re-transmission of signaling in the event of rapid hand-off, SIP support with NATs [43], [44], sessioncontinuity, fast handoff and asymmetry of data delivery.
In the testbed, 3G connectivity was provided by Verizon Wireless’s CDMA1XRTT access network.During the experiment it was observed that time taken to obtain an IP address via CDPD/CDMA overPPP takes more time ( about 15 seconds) than the time taken to obtain the address using DHCP withoutARP option ( less than 1 s). It was found that the average throughput over CDPD network is about 8 kbpsand that over CDMA network is about 60 kbs. In order to reduce the packet loss due to delay in IP address
11
Figure 4: SIP-based secured interdomain protocol plot
Figure 5: SIP-based heterogeneous mobility
acquisition, we have implemented a make-before-break algorithm that sets up a PPP connection whilethe mobile is still communicating with 802.11 network. A policy-based approach is used to define thetrigger in the hotspot area that will determine the active interface that the client will use to communicatewith the corresponding host. This policy can be based on link condition, QoS of the received traffic orserver-based advertisement. Figure 5 shows the sequence of RTP packets when SIP-based mobility isused during a mobile’s movement between 802.11 network and 3G network. Although packet loss isminimized, few out of order packets were received on the mobile.
In addition we have also designed and experimented a secured multi-interface mobility managementscheme where a mobile with dual interface moves between an enterprise network (e.g., 802.11), cellularnetwork (e.g., CDMA, GPRS) and hotspot (e.g.,802.11). It provides secured seamless roaming supportwithout the need to tear down IPSec tunnels during each subnet move. Dutta et al [45] describe the detailsof the implementation using both mobile IP and SIP-based approaches. Both CBR traffic (audio) andVBR traffic (video) have been experimented and we have analyzed the packet loss, delay and inter-packetgap during the handoff. Figure 6 shows the results of an experiment involving secured mobility acrossheterogeneous networks. Low gradient in the graph implies the low speed within a cellular network. Themobile received few out of order packets during its movement from cellular network to 802.11 networkbecause of the transient packets in the path that arrived in the WAN interface at a later point.
4.2.5 SIP mobility over IPv6
We have experimented mobility binding for wireless telephony over IPv6 network using both MobileIPv6 and SIP-based terminal mobility. Linux kernel version 2.4.9 with patch from USAGI projects [46]was used in the routers and Linux hosts. MIPL Mobile IPv6 for Linux [47] was adopted to supportmobility in the testbed. Several experiments were carried out for real-time voice traffic to analyze theeffect of Duplicate Address Detection (DAD) [18] in the disruption of SIP-based multimedia calls. Anexperimental handoff analysis of SIP mobility with IPv6 and MIPv6 involving signaling and mediaredirection is shown in Table 5. Timing for SIP mobility was measured both for DAD and No-DAD
12
Figure 6: Secured mobility across heterogeneous networks
Table 5: Comparison of SIP mobility with MIPv6
CASE
H23
SIP with DAD
H12
SIP with DAD
HANDOFFMedia
SIP w/o DADSIP w/o DAD
(ms) {ms)
38290.9
1934.7 161.1
38546.3
4187.7
(Home - Visited)
(Visited - Visited)
(Visited - Home)
161.6
171.4
1.0 H31
2.0
1.5
1949.4 408.4
418.6
420.8 21.1
30.3
25.3
3932
MIPv6 w/o DAD MIPv6 w/o DAD
Signaling
cases where as only no-DAD case is shown for mobile IPv6. Aggressive router selection method was alsoadded to no-DAD case. Aggressive router selection procedure forces a mobile to bind to the new routerquickly enough without doing a Neighbor Unreachability Detection [48]. Agressive Router Selectionmodule has been implemented as part of the kernel module of MIPL. Details of the experiment can befound in [49]. From the experimental results we infer that by getting rid of DAD and adopting aggressiverouter selection process we were able to minimize the signaling delays to 200 ms and media delays toless than 500 ms.
4.2.6 Terminal mobility with quality of service
In order to make sure that the SIP-based media sessions such as audio, video streaming traffic maintainthe same level of quality of service during a mobile’s movement between two subnets we have integratedSIP-based terminal mobility with DSNP (Dynamic SLS Negotiation Protocols) [50]. Dutta et al [25]have described the detailed procedure. Figure 7 shows how quality of service for the multimedia trafficis taken care of during the subnet handoff. There is a slight fluctuation in bandwidth during the subnethandoff.
4.2.7 SIP-based terminal mobility for non-real-time application
As part of this proposal we have also investigated two different approaches that allow us to supportsession based TCP applications such as chat-tcp using SIP signaling procedure. In one approach amobility proxy [51] can be used in conjunction with SIP registrar and Linux’s IPTABLES utility to
13
Initial SLSnegotiation
Handoff(1)
Handoff(2)
Handoff(3)Handoff(4)
SLS change
Figure 7: QoS throughput results during handoff
provide mobility solution for TCP application. Figure 8 shows an approach where a SIP-based mobilityproxy is used to support TCP-based application. SIP-based mobility proxy works in conjunction with aSIP registrar to capture and mangle the outgoing packets. Another approach can use SIP’s INFO method[52] in conjunction with a
����������[53] to provide mobility solution. In this proposed approach the
mobile station is equipped with a����������
agent that maintains a record of its ongoing TCP connections,upon hand-off the MS sends information to the corresponding host using INFO method. Within thebody of the INFO method it sends the binding message, requesting binding of the MS’s old addressto its new one. MS and CH use IP encapsulation to maintain constant end-points for MS’s ongoingTCP connections. This takes advantage of the Network Address Translation techniques similar to thetechniques described by Su and Nieh [54] that uses virtual network address translation technique toprovide host mobility.
Mobile Host withOld IP address
CH
SIPRegistrar
MobilityProxy
Mobile Host withNew IP address
IP1 IP2
2. Change to a new IP address
3. Update IP address
4. Forward packets to the new IP address
1. ExistingTCP connection
SIP-CGI
New TCP connection
Figure 8: SIP with Mobility Proxy for TCP application
4.3 Mobility Management - Fast-handoff techniques
Several factors at different layers contribute to handoff delays contributing to transient data loss duringmid-session mobility. Figure 9 shows the latency factors associated at different layers during a handoff.These factors include layer 2 access point handoff, layer 3 triggering time, time taken to obtain an IPaddress using methods such as DHCP, PPP or MIP Care-of-Address and time taken for media redirection.Fast-handoff techniques can be deployed at different layers to help reduce the transient data loss due tothe delay associated latency with the macro handover. These are denoted by ( �� ), ( �� ), and ( �� )respectively.
14
Figure 9: Handoff latency factors
4.3.1 Related fast handoff approaches
The IETF is currently considering several alternative approaches [12] for supporting fast handoff withinthe Mobile IPv4 context. There are several layer 3 based intra-domain mobility management solutionssuch as HMIP [12], [55], [56], [57] to help reduce the transient data loss when a mobile host moves be-tween the subnets within a domain. Similar fast-handoff mechanism has also been proposed for MobileIPv6 [58] that introduces an agent called MAP (Mobility Anchor Point) to localize the intra-domain mo-bility management. Vakil et al [59] provide a virtual soft-handoff approach for CDMA based wirelessIP networks. It takes into account the fact that both the access points receive the stream during mo-bile’s movement. However this scheme does not provide a generalized solution suitable for other typeof access network such as 802.11. Thus it is important to design a generic framework that can providefast-handoff for both real-time and non-real-time sessions. Moore et al [60] and Han et al [61] describesome of the techniques needed to carry out DAD (Duplicate Address Detection) optimization for IPv6clients. Park et al [9] and McAuley et al [10] describe different ways of faster IP address acquisition forIPv4 clients respectively.
As part of generalized fast-handoff techniques to support optimized intra-domain mobility manage-ment, we propose three different approaches based on network layer and application layer. These arenamely, SIP-based fast-handoff and IDMP fast-handoff that help reduce the delay associated with me-dia re-direction; proactive IP address acquisition and pre-authentication mechanism that help speed upthe handover by acquiring an IP address quickly and provide the authentication ahead of time. In thefollowing sections we describe some of the fast-handoff methods we have proposed.
4.3.2 SIP-based fast-handoff scheme
Each visited domain may consist of several subnets. Every move to a new subnet causes the MH tosend a re-INVITE to the CH containing its new care-of address. If the re-INVITE request gets delayeddue to path length or congestion, transient media packets will continue to be directed to the old address.We assume that the visited network has an outbound proxy. We enhance this proxy with the abilityto temporarily register visitors [35]. The visitor obtains a temporary, random identity from the visitednetwork and uses it as its address-of-record to register with the registrar in the visited network. TheMH informs the home registrar of this temporary address. It then only updates that registration with itscurrent local IP address. This speeds up registration, but does not address the “delayed binding update”issue using SIP’s re-INVITE feature. As part of this proposal we describe several ways to achievefast handoff using SIP, namely, using a SIP registrar and RTP translator or NAT, using the outboundproxy and B2BUA as a mobility agent. In-transit packets can be redirected to a unicast or multicastaddress based on the movement pattern of the mobiles and usage scenario. These proposed methods
15
Figure 10: Protocol sequence for RTPTranslator-based fast-handoff
help alleviate transient data loss related to continuous hand-offs within a domain thus minimizing thedelay contributed by � shown in Figure 9. Dutta et al [62] provide more details about the fast-handoffmechanism. Below we briefly describe some of the fast-handoff mechanisms.
In the first approach, each subnet within a domain is equipped with an RTP translator [63] thatprovides application-layer forwarding of RTP packets for a given address and UDP port to a givennetwork destination. The visited-network registrar described earlier receives the registration updatesfrom the MH that has just moved, and immediately sends a request to the RTP translator in the networkthat the MH just left. The request causes the RTP translator to bind to the old IP address used by the MHand forward any incoming packets to the new address of the MH. After a set interval or after no mediapackets have been received by the RTP translator, the RTP translator relinquishes this old address andremoves the forwarding table entry, assuming that the re-INVITE has reached the CH.
The second approach uses a SIP outbound proxy. SIP requests typically traverse a SIP proxy in thevisited network, the outbound proxy. This outbound proxy can also support fast handoff, by using thedata in the MH-to-CH re-INVITE to configure the RTP translator or NAT. The advantage of this approachis that the outbound proxy usually has access to the Session Description Protocol (SDP) informationcontaining the MH media address and port, thus simplifying the configuration of the translator or NAT.On the other hand, this outbound proxy has to remember the INVITE information for an unboundedamount of time and become call stateful, since it needs the old information when a new re-INVITE isissued by the MH.
Another way of providing fast-handoff is by using a back-to-back SIP user agent (B2BUA). AB2BUA consists of two SIP user agents where one user agent receives a SIP request, possibly trans-forms it and then has the other part of the B2BUA re-issue the request. A B2BUA in each domain needsto be addressed by the MH in the visited domain. The B2BUA issues a new request to the CH containingits own address as the media destination and then forwards the packets, via RTP translation or NAT, tothe MH.
Locally scoped multicast may also help avoid packet losses if the MH can predict that it is aboutto move to a new subnet shortly. In that case, it informs the visited registrar or B2BUA of a temporarymulticast address as its contact or media address. Once the MH has arrived in its new subnet, it updatesthe registrar or B2BUA with its new unicast address, while continuing to listen to multicast address. Theuse of scoped multicast is only effective if the MH can quickly acquire a multicast address and there isan inherent multicast infrastructure.
Figure 10 shows protocol interaction between several entities to support fast-handoff mechanismdescribed in approach 1. As shown in the figure, RT1, RT2 and RT3 are RTP translators in the respectivesubnets. These RTP translators forward the traffic associated with one IP address/port number to anotherIP address/port number. RTP translator in each of these subnets intercepts the traffic meant for the mobilehost and sends it to the new address of the mobile host after capturing it. This message can be sent via
16
Figure 11: Packet gain for SIP optimized fast-handoff
SIP-CGI [64]. Signal re-INVITE was delayed to simulate the network congestion or distance betweenCH and MH. Both VIC and RAT tools [65] were used to measure the performance of audio and videostreaming traffic respectively. Two methods such as rtptrans and NAT-based iptables were used to directthe transient traffic from the previous subnet to the new one. We tried few experiments with re-INVITEsignals being delayed by 100 ms, 200 ms, 500 ms, 1 sec, 2 sec and 3 sec to show how RTP translatorhelps delivery of RTP packets and enhances smooth handoff mechanism during mobile’s movement.We measured the packet forwarding delay due to redirection at the registrar to be less than 1 ms whenthe iptables-based NAT approach was used, where the RTPtrans approach added 4 ms of delay. Welost about 15 packets due to delay associated with re-registration and packet forwarding during handoff.Number of packets lost also depend upon the codec rate that determines the spacing of packets. Figure11 shows the effect of SIP-optimized handoff compared to regular SIP-based handoff. We are currentlyimplementing the B2BUA assisted and multicast assisted handoff mechanisms.
4.3.3 IDMP based Fast-handoff
This section describes fast-handoff techniques associated with IDMP (Intra Domain Mobility Manage-ment) [16] that helps reduce the transient data loss during a client’s intra-domain mobility. Completedetails of IDMP fast-handoff techniques can be found in [66]. In a cellular network deploying IDMParchitecture where IP-based base station (IPBS) is used, the handoff delay essentially consists of threecomponents such as radio-channel Establishment Delay ( � ):, IP Subnet Configuration Delay ( � :,and intra-domain Update Delay ( � ):
Figure 12 shows an example of IDMP fast-handoff scenario. IDMP requires only one multicastgroup per a set of access points. Since a single BS can be a neighbor of multiple BSs, each BS canindeed be a member of multiple multicast groups. Each BS is thus permanently subscribed to one ormore multicast groups.
To minimize the service interruption during the handoff process, IDMP requires either the MN orthe old SA (SA-old) to generate a MovementImminent message to the MA (Multicast Agent) servingthe MN. On receiving a MovementImminent message, the MA encapsulates an in-flight packet and thentunnels it to the appropriate multicast address. On receiving such a tunnelled multicast packet, each SAwill first decapsulate the outermost header. It then buffers the decapsulated packet in a per-client buffer,using the destination address in the inner-header (which is unique to a specific MN) as an index. When anMN subsequently performs a subnet specific registration with an SA (e.g., SA-new) after the movementis over, the new SA can then forward any cached packets to the MN before the intra-domain locationupdate process is complete. This procedure reduces the in-transient data loss. From a simple calculationit is evident that a small user buffer is effective in reducing the loss of in-flight packets. For exampleif the intra-domain update latency (L) is 200 ms, and the incoming traffic rate (R) is 144 Kbps, then abuffer size of (L*R) 3.6Kbytes is able to protect against buffer overflow due to multicast packets during
17
the transient handoff. The fast-handoff mechanism described in reference [66] is being implemented aspart of the future work.
HAINTERNETCN
SA1
Subnet A
Local Registration
Transient DataMovement Imminent
PacketsMovement Imminent Buffered (3)
SA-OLD SA_NEW SA4
Router
Subnet B MA Subnet C Subnet D
Multicasting Begins
(2)
MN MN
(1)
Figure 12: IDMP fast-handoff scenario
4.3.4 Proactive IP address configuration and Pre-authentication
Previously described fast-handoff approaches help speed up the media redirection component ( � ) afterthe mobile has been configured with the new IP address. A mobile can also benefit from faster handoffif the IP address configuration and authentication mechanisms are done in an efficient manner. In thatregard we have looked into expediting the handoff process by proposing proactive IP address acquisitionmethodologies and pre-authenticating a mobile while it is still in the previous network. As part of thiseffort currently we are focusing our work on network discovery methods, where the client discovers theneighboring elements (e.g., routers, DHCP servers, SIP servers) and communicates with these entitiesbefore it actually moves into these networks. This will help expedite the authentication and IP addressacquisition part of the handoff process. We have also looked into geographic coordinate assisted fast-handoff mechanism as another alternative method of faster IP address acquisition. In order to avoiddelay associated with IP address acquisition during network transition such as from LAN to WAN wehave implemented an approach that uses combination of GPS coordinate, MAC address of the mobileand some other identification number such as VIN (Vehicle Identification Number) to ensure that a clientobtains a unique globally routable IP address during the transition [32].
4.4 Integrated mobility management for ad hoc networks
We have designed a multi-layer mobility management architecture and have prototyped several com-ponents in the testbed. It consists of three mobility protocols that work in conjunction with a policymanager and provide the desired functionality based on the type of application and mode of movement.SIP-based mobility management is used for real-time communication, and application layer MIP-LRis used for non-real-time traffic during a node’s movement between two different domains while MMP(Micro-Mobility Management) takes care of the movement within a domain.
In this section we present the preliminary design, implementation and integration scenario of the in-tegrated mobility management. We also evaluate its performance under a simulated ad hoc environmentwhile the mobility protocols interact with dynamic DNS [67], DRCP/DCDP protocol suite. Dutta etal [68] describe complete operation of how integrated mobility management scheme is realized in thetestbed.
Mobile IP with Location Register (MIP-LR) [15] is a network layer mobility approach that providessurvivability features suitable for ad hoc environment and provides an improvement over the traditionalmobile IP by avoiding triangular routing and encapsulation. We have designed an application layertechnique for Mobile IP with location register (MIP-LR) and have implemented it as part of the integratedmobility management prototype. This approach provides the inherent survivability features of MIP-LRwhile making it kernel independent for easy deployment.
18
Application layer MIP-LR augments the basic MIP-LR scheme with some application layer tech-niques such as libipq, mangler and NAT modules and thus provide kernel level independence. Figure13 shows how the packets are mangled and demangled within application layer MIP-LR. Results fromsimulation and MIP-LR laboratory prototype show that one can attain up to 50 percent reduction inmanagement overhead and up to 40 percent improvement on latency compared to standard mobile IP inco-located mode. Figure 14 shows delay comparison between application layer MIP-LR and Mobile IP.
Figure 13: Mangling technique for MIP-LR
MIP-LR vs. MIP Delay (Experiment)
4
6
8
10
12
14
16
18
20
0 100 200 300 400 500 600 700 800 900 1000 1100
Bytes per packet
Ro
un
d t
rip
tim
e in
Msec
MIP
MIP-LR
Figure 14: MIP-LR/Mobile IP comparison
MMP is a derivative of Cellular IP and shares certain benefits of forwarding-cache-based techniquesexploiting hierarchical structure of military networks. MMP is designed as a micro-mobility protocol tohandle intra-domain mobility and works in conjunction with SIP and MIP-LR, where SIP and MIP-LRhandle macro-mobility and take care of inter-domain movement. In addition MMP has been augmentedwith multiple paths, and multiple gateways, for robustness and reliability. Results of simulation andexperimental results for MMP are explained in [69].
In the integrated mobility management scheme, when MN moves to a new domain for the first time, itobtains a new IP address, registers with the SIP server or ground VLR (Visiting Location Register). Thisdatabase gets propagated to other SIP servers or HLRs spread across the network. Thus CH becomesaware of the new IP address of the MH from the SIP re-direct server or HLRs. To support real-timecommunication during the mobile’s movement between the domains, a Re-INVITE is sent to the CHto keep the session active, similarly a MIP-LR UPDATE message is sent to CH for the TCP/IP traffic.But for any subsequent move within the new domain Re-INVITE or update messages are not sent, sinceMMP takes care of routing the packets properly within that domain. Figure 15 shows the integratedmobility management scenario and interaction of all the three protocols. Figure 16 shows the packet drop
19
Figure 15: Integrated Mobility Management Scenario
0
50
100
150200
250
300
350
400
1 2 3 4 5 6 7 8 9 10 11handoff index
num
ber o
f pac
kets
dro
pped
low rate 1 wayhigh rate 1 wayhigh rate 2 way
Figure 16: SIP-based mobility within IMM scheme
at different traffic rates during a video application on the SIP client as it moves between the domains.We have given more details of this scheme in [70].
5 A roadmap for completion of research in Mobility Management
This section provides a roadmap for completion of research in the mobility management area and providea synopsis of additional work that needs to be performed beyond the initial set of results. Most of thefuture work will concentrate on enhancement of the prototypes and additional analytical work.
1. An optimized handoff scheme when both clients are mobile
In a highly mobile environment it is quite natural to assume that both the hosts are mobile. Letthe probability that any particular handoff suffers from simultaneous mobility problem be
� � , andthe probability that at least one out of N handoffs in a given session suffers from the simultaneousmobility problem be
���. Thus
���= 1 � ��� - � � ) ��� ��� P � = E[ � + � ]/ � . Where � and � are the
amount of time needed for a binding update to reach from A to B and vice-versa and � is theaverage inter-handoff time. As part of initial results, we have explored a preliminary analysis ofsimultaneous mobility of IP hosts using both SIP and MIP-LR based mobility and have presentedthe analysis in [71]. Figure 17 shows how the simultaneous mobility problem is affected bylatency and inter-handoff time using the above algorithm. As part of future work I will carry outexperiments to support simultaneous mobility using SIP-based mobility techniques.
Expected completion date is January 2005.20
Figure 17: Probability for handoff with simultaneous mobility
2. Comparison of SIP-based mobility and MIPv6
Mobility approaches adopted by Mobile IPv6 and SIP-based mobility have a lot of similaritiesin terms of binding update and SIP registration. As part of an initial set of results [49] both SIPbased mobility scheme for IPv6 and MIPv6 have been implemented in the test-bed and experi-ments have been carried out. I will carry out an analytical and performance comparison betweenboth the mobility approaches. I will measure and analyze both stateless and stateful (DHCPv6) au-toconfiguration methods. I will investigate applicability of SIP-based terminal mobility to supportmovement between IPv4 and IPv6 networks.
Expected completion date is December 2004.
3. Completion of implementation of fast-handoff scheme
As part of the initial work for SIP fast-handoff mechanism, RTPtranslator-based approach hasbeen investigated and prototyped. I plan to prototype two other fast-handoff approaches outlinedin the Section 4.3 and will compare the results with the current approach.
I will implement IDMP based fast-handoff mechanism in the multimedia testbed and will comparethe results with basic IDMP-based handoff.
Many of the operations such as pre-authentication, IP address acquisition including duplicate ad-dress detection are performed during a mobile’s movement between domains and between subnetswithin a domain. These operations which are usually done after the mobile has moved to the sub-net if done ahead of time will help provide the fast-handoff for an existing session. In order toperform these operations while in the previous domain or subnet the mobile will need to commu-nicate with the next hop routers and servers ahead of time. Thus a mobile will need to discover theneighborhood information including the access points, routers, DHCP servers and several authen-tication servers such as AAA, PANA and SIP servers before moving to the neighboring networks.This information gathering by means of network discovery will help a mobile to perform severaltypes of operation ahead of time such as pre-authentication and IP address acquisition. As part ofthis work I propose to implement a network discovery mechanism using a framework consistingof SOAP (Simple Object Access Protocol), RDF (Resource Description Framework). I will useresults of this discovery mechanism with the pre-authentication and faster IP address acquisitiontechniques to implement an integrated fast-handoff approach.
Expected completion date is February 2005.
21
6 MarconiNet: A Mobile Content Distribution Network
This part of the proposal concentrates on the research conducted and proposed towards MarconiNet [27]as a content distribution network for mobile hosts. MarconiNet [72] proposes an integrated stream-ing architecture to support multimedia applications such as broadcasting streaming content over theInternet using both wired and wireless access. Mobility and stream delivery in MarconiNet take advan-tages of localized IP multicast and uses application layer techniques to provide flexible services suchas localized advertisement; news broadcast; location specific information, QoS guarantee and optimizedintra-domain handoff for the mobile users.
Figure 18 shows a sample streaming architecture for mobile users. An end-user can be an IP-basedradio, a soldier in a military environment or a vehicular user. A streaming source can send its trafficusing a variety of core network technology over terrestrial or satellite network. The mobile user is thereceiver and can move between cells, subnets and domains while receiving multicast stream from thesource. MarconiNet is modeled after this specific type of streaming network.
Local Station A
LocalStation C
LocalStation B
Local Subnet Local Subnet Local Subnet
WirelessIP I/F
IP I/F
AM/FMTV
IP I/F
ContentServer
An Integrated Streaming NetworkISL Internet
in-theSky
ISL
Down Linkwithspot-beam
Up linkUp link
Broadband LEOs
TerrestrialINTERNET
Local Ad Server
Local Ad Server
IndividualBroadcaster
BattlefieldSoldier
Figure 18: A typical mobile content distribution network
7 Related Work on Content Distribution
Content distribution to end users may include both mobile and non-mobile clients over wired and wire-less medium. There are several proposed schemes to provide native IP multicast routing over a wide areanetwork such as PIM [73], MOSPF [74], DVMRP [75], CBT [76] and BGMP [77]. Diot et al [79] outlineseveral issues such as QoS, pricing, security that hinder the wide scale deployment of multicast in thecore network. Explicit multicast [80] and Source Specific Multicast [81] are some recently developedprotocols ideal for broadcast application. Explicit multicast is useful for maintaining many multicastgroups when the membership in each group is small unlike in traditional multicast that supports limitednumber of large multicast sessions. Source Specific Multicast (SSM) addresses some of the issues suchas multicast address allocation, destination unawareness, inter-domain routing, source advertisementand large number of connection states. SSM is ideal for Internet broadcast applications since a specificcontent can be identified as a pair of source address (S) and the multicast group address (G). Recently,techniques such as UMTP (UDP Multicast Tunneling Protocol) [82] and AMT [83] provide multicastsupport for the non-multicast enabled networks. Multicasting to the mobile users has primarily been di-vided into two categories, home subscription-based solutions and remote subscription-based solutions.Romdhani et al [84] have discussed some of the challenges associated with mutlicasting to the mobileusers. It has provided a comparison of available protocols that can support mobile multicast using boththe approaches. References [85], [86] and [87] describe many of the architectural issues associated withmobile hosts in a multicast environment. In order to provide fast-handoff of the mutlicast streams to a
22
mobile client moving between subnets, Wu [88] proposes a solution of handover with pre-registrationby deploying Mobility Support Agents. Mobile Multicast Proxy [89] has proposed a multicast proxyapproach to reduce the transient data loss of multicast communication during handoff. In this situationthe proxy’s clients do not themselves directly participate in the multicast tree.
Mobile-IP based bi-directional tunneling solution puts the multicasting burden on the Home Agent(HA) by creating tunnels between the HA and the mobile using IGMP. However, tunneling multiplemulticast packets to the foreign network is inefficient. Mobile Multicast (MoM) [90] proposes to reducethe explosion problem in bi-directional tunneling by electing one designated HA. Range-based MOM[91] takes MoM approach one step further and elects a multicast agent close to FA to tunnel multicastpackets to the foreign network.
Remote subscription approach takes the burden off the home agent and does eliminate tunneling byavoiding the duplication of multicast packets being tunneled to foreign networks. However this requiresthat after each handoff the user must rejoin a multicast group. In addition the multicast trees used toroute multicast packets will be updated after every handoff to track the multicast group members. Inorder to limit the tree updates or limit duplication of multicast packets, proxy or agent-based solutionshave been proposed [92], [93].
Basso et al [78] describe an overlay IP-based streaming network called PRISM that provides flex-ible program distribution over cable network but has not considered distributing to the mobile clients.Almeroth et al [94], [95] have described the multicast group behaviour in the Internet by looking atMbone’s temporal statistics. This study is very similar to a group management scenario in a mobileenvironment where the user leaves one group and rejoins the same group in the next cell.
There are already commercial content distribution networks that use multicasting as the core technol-ogy. Most recently, Packet Video in conjunction with DoCoMo has started providing wireless multicaststreaming services to the end users, but it has not taken into account the subnet mobility factor. AlsoiBEAM’s product Activecast was used to distribute streaming application over the Internet. However, itlacks in taking care of user mobility, uses the GEO satellites for content distribution, does not provideflexible methods of advertisement insertion and variety of local and global content. As an alternative towired core network, companies such as Inktomi and Coolcast are already providing multicast servicesthrough satellite to reach a wide range of users.
We propose a content distribution network called MarconiNet that offers rich set of multicast servicesto the mobile users. It uses SDP [96], SAP [97], SIP [24] and takes advantage of the real-time feedbackmechanism based on RTCP. In addition to prototyping several components of this flexible streamingarchitecture it has also investigated some of the issues related to multicasting streaming media to themobile users such as join/leave latency, quality of service, location specific information and movementbetween heterogeneous networks. Scalability, load balancing between servers, placement of proxies aresome other relevant issues with respect to mobile content distribution but have not been investigated aspart of this work.
8 MarconiNet Overview and Initial Results
Initial work for MarconiNet is focused on architecture, prototypes, models, and performance resultsbased on experiments for mobile multicast content distribution. Initial results can be divided into fol-lowing sub-categories.
1. MarconiNet Architecture supporting Mobile Content Distribution
Subsection 8.1 explains the architecture and introduces associated functional modules.
2. Application Layer Triggering techniques
Some of the key functionalities such as local advertisement insertion, local and global programmanagement, channel tuning using application layer triggering techniques are explained in sub-section 8.1.
23
3. Fast-handoff of multicast stream
Section 8.2 introduces some key fast-handoff techniques developed to take care of multicast streamdelivery in MarconiNet environment.
4. QoS guarantee for multicast stream
Section 8.3 describes a specific methodology that provides QoS guarantee to the mobile userswithin MarconiNet.
5. Movement between heterogeneous access networks
Section 8.4 discusses few techniques to support a mobile moving between a multicast and non-multicast enabled network.
6. Implementation and Test-bed Realization
Section 8.5 describes the testbed implementation and discusses experimental results of the proto-type.
8.1 MarconiNet functional architecture
The proposed MarconiNet broadcasting architecture consists of two tiered (hierarchically-scoped) IPmulticast sessions. The higher level of the two (global multicast) exists between the broadcasting radiostations (RSCs) and the Radio Antenna Servers (RASs) which are also called local stations or affiliates.At the lower level of the hierarchy, a local multicast session is created for each broadcasting stationbetween the server and the listening clients (IMC) which can be privately scoped.
As illustrated in the Figure 19, there are four basic functional components in the MarconiNet ar-chitecture, namely Global Station (Primary Station), Radio Antenna Server (RAS) which are the localstations, advertisement server and Internet Multimedia Clients (IMC). A Primary station acts like a mul-timedia streaming source. By inserting the local servers one can have full control over the program beingbroadcast, such as transmitting global program vs. local program and inserting local advertisement. Ineach cell (subnet) there is at least one local server (Radio Antenna Server) that converts globally scopedincoming multicast stream to a locally scoped multicast stream destined for the local clients. In order totake care of dynamic load balancing and handoffs, multiple local servers can be placed within the samesubnet or across the subnets in a domain. The commercial server is a streaming server and is usuallyco-located with the local affiliate. Local affiliate and commercial server can interact to provide streamcontrol using protocols such as SIP and RTSP [98].
The following sub-sections define some of the functional modules and features prototypes that arepart of this architecture.
Channel Database
Channelannouncement (local)
RTP/RTCP
Mi
Local station
SAP/SDP
ProgramManager RTSP Ad/
MediaServer
PS1 PSiPS2
SAP Mx
SAP Based announcementGLOBAL (encrypted)
M2Mi
(EncryptedAudio Stream)
Global Content Providers
Channel Monitor
lmi
PLAY
SETUP
Local Commercial lml (local program)
SAP lmxRTP/RTCP
MobileClients
M1
Figure 19: MarconiNet logical architecture
24
Channel Announcement: A global streaming station (e.g., Radio/TV station, an individual broad-caster) denoted as � ����� / � ��� broadcasts its programs potentially to the global audience live on a uniquemulticast address � � globally scoped and encrypted, using RTP/UDP. These global stations send theirsession announcement using a subset of SDP parameters to a global multicast address ��� that may notbe encrypted. This common global multicast address provides a list of the programs broadcast by theprimary stations (RSCs) all over the world. We have designed a java based interface called JSDR thatprovides more customized and hierarchical searching functionality compared to traditional SDR.
Channel Management: Channel management takes care of managing global program and localprogram. Each RAS or local station gets a global encryption key that it uses to tune to the globalcommon multicast address � � to get the listing of the channels, and its contents. It decides to broadcasta part of the list to the local domain based on the demography and user interest. It thus creates a localannouncement database. The subset of channel descriptions announced by each radio station providessufficient data for building a local channel database. This local announcement database contains thelist of the supported channels, each with their appropriate attributes such as the name of the program,duration, type of content, place of origin etc. Local station uses SAP to send this program-index to alocally scoped common multicast address ��� for announcement to the local clients. The announcementon � is not encrypted as the local stations like to have all of its clients to get access to what is beingrelayed by it. RAS also maintains a pair of multicast addresses for each channel. It keeps the mapping ofthe globally scoped multicast address on which the radio station sends its program and the locally scopedmulticast address where it gets relayed. RAS receives the audio stream on the global multicast address� � and redirects it onto the local multicast address � for the IMCs. Local programs are sent on aspecific locally scoped multicast address �� . Reports generated by RTCP packets from the participatingclients can be used for many statistical purposes such as billing, audio/video quality feedback and alsomembership information for a particular channel.
Channel Tuning: Internet Multimedia Clients (IMC) listen to the locally-scoped common multicastaddress �� using a tuner program based on protocols such as SAP and SDP. According to the SAPspecification, the local server updates the announcement information every several minutes or so. Eachspecific channel provides details of the program being broadcast also.
Local Advertisement Insertion: If a user is to be provided with location-specific information, theuser’s geographical location has to be known to the streaming source or to the multicast proxy that isfiltering the information to the user. Local information can be communicated to the media server thatwill insert the local news, traffic and advertisement information.
Localized advertisement or information insertion can be provisioned or it can be event driven as inthe case of an emergency situation. Each global radio station knows the starting time and duration forcommercial break ahead of time or has the control over the time for the commercial break. On receivingthe signal for commercial break via RTCP feedback, the management server at the local station requeststhe local media server via RTSP to play the local advertisement to a specific locally scoped multicastaddress �� corresponding to that station. It uses a set of RTSP commands like SETUP, PLAY andPAUSE to control stream delivery of the commercial break. During this time, management server stopsforwarding the RTP stream from � � to � in the local domain. The local advertisement runs for a spe-cific time conveyed to the server by means of RTCP reports. In case of overlapping of commercial breakby several radio stations, the RTSP server can play several different local advertisements on differentlocally scoped multicast addresses.
Channel Monitor: Channel monitor mechanism provides an online estimation of the audience sizetuning to a specific channel or listening to a particular advertisment at any instant. This is achieved byusing RTCP feedback technique and is similar to many of the techniques addressed in reference [99].For each channel being diverted by the local station, additional RTCP signaling channel is created withdifferent port. Each listener sends RTCP SDES packets to notify the local station (RAS) alongwith theclient’s demographic information and the respective channel it is subscribed to. RAS maps each listenerto the desired channel, which in turn increases the number of listeners for that particular channel. Thelistener-to-channel mapping is destroyed via RTCP BYE packets or via RTCP timeout feature. By doing
25
EdgeRouterBS
Multicast stream S1
Layer 2hand-off
Beacon from BS2
Binds to B2
CGMP (Leave/Join)
Stream S1 Server Adverstisement
Layer 3hand-offIP configuration
Stream deliveryin the samesubnet
RTCP JoinIGMP Join
New Stream S1
RTCP BYE IGMP Leave
DHCP Discover
DHCP Offer
StreamDeliveryin new subnet
IGMP snooping
Local Server1 Local Server2Mobile
Multicast L2 Switch
Figure 20: Handoff flow for multicast stream
this it also decreases the number of listeners for the associated channel at the local station.Security: The proposed MarconiNet system presently offers several levels of security association
between the global station, local affiliate and end-clients. Security model for global multicast streameffectively prevents the Internet Multimedia Clients, as well as the non-paid RASs (local affiliates) fromreceiving the broadcast content. Thus each radio/TV station (RSC) must maintain a secret key andencrypt all outgoing content so that only ciphertext stream is transmitted. Each local station generates itsown PubKey/PrivKey pair. Each global station generates a SEK (Secured Encryption Key) and beginstransmitting encrypted audio content. The local station submits its public key to the primary stationalongwith its payment or CAs (Certificate of Authority). The local station (affiliate) in turn receives aninteger ID from the global station which is later used to index the SEK distribution list. The PrimaryStation collects the public keys from the local stations and adds these to its SEK distribution list upontheir payment. Encryption can also be extended to a local section as a second level hierarchy and beused for the pay-per-listen program that are announced to the local multicast addresses. The securityscheme also helps to preserve the sensitive information such as the secret keys (of RSCs, and pay-per-listen channels), user accounts, and payment data. Advertising companies can be authenticated so thatun-authorized companies cannot gain access to the local advertisement insertion system.
Payment Model: The logging mechanism helps the advertisers to decide and determine as to whenand on which channels to place their commercials in order to maximize returns on investment. Thehigher level of advertising efficiency will drive more advertisers towards advertising on the local affiliate.This in turn will allow the local affiliate to pursue an increasing share of Internet Radio/TV advertisingmarket by charging different prices for different segments of air-time, based on demand. The RTCP-based reporting mechanism enables the affiliates to track user listening trends and can provide detailedreports with users’ listening statistics to potential or existing advertisers.
8.2 MarconiNet Fast-handoff Techniques
Latency associated with receiving continuous multicast stream from a single source while the clientmoves to the next cell consists of several components such as detection of a new cell/subnet/domain( � ), address acquisition and network configuration ( � ), triggering of multimedia stream to be deliv-ered in the new subnet ( � ) and actual delivery of multimedia stream ( �� ). Figure 20 shows a handoffflow for multicast stream and shows different latency factors associated with a mobile’s movement.
The very process of joining or leaving a specific multicast group while changing the cell or subnet issimilar to surfing a TV or Radio and flipping the channels [100]. Since the multicast communication isreceiver initiated, triggering techniques play an important role for multimedia stream delivery. In orderto maintain minimum loss and latency during the client’s movement it is desirable to minimize the hand-off time and to provide almost instantaneous flow of multicast stream by adopting some novel triggeringmechanism. Similarly, it may be required to avoid the waste of bandwidth in a wireless environment dueto continuity of the mutlicast traffic associated with the leave latency during a mobile’s movement.
26
In traditional layer 3 method, triggering delay associated with a mobile’s ability to join a multicasttree after a subnet move depends on Internet Group Management Protocol (IGMP) [101] query report. Atypical query interval for the IGMP is by default 125 seconds [102], although this value is configurable.Flament et al [103] show that by using IGMP, a host will wait for 65 seconds on average in order tocontinue to receive the multicast traffic after the hand-over. A typical leave latency once the host hasmoved to a new subnet is about 3 mins. Thus, IGMP in its current form is not suitable for real timecommunication in wireless environment where handoff latency and packet loss are important concerns.In case of a client’s movement between access points within a subnet, triggering of multimedia streamcan be taken care of by CGMP (Cisco Group Management Protocol) or IGMP snooping [102]. Wepropose here a combination of mechanism that includes the application layer triggering technique basedon RTCP.
Figure 21 shows a typical MarconiNet environment where���
,���
,���
are the globally routable subnetsconnected to the primary interfaces of the servers where as
� �,� �
,� �
are the local subnets connected tothe secondary interfaces of the servers and could be NAT-based addresses. In this particular picture, S1,S2 ... S5 are local stations (servers) connected to the upstream routers. Each server (with the exceptionof S2 and S3) is connected to a different subnet and has a separate interface. S2 and S3 are connected tothe same subnet via a multicast switch that provides layer 2 multicasting functionality.
R
R1 R2
S1 S2 S3 S4
Multicast Switch
S5
Ia Ib Ic Id
M1
m1
ia ib ic id
Mx
Lmx
ib
MulticastAgent
Mx
Msx
Sharing multicast address
Lmxn1
M1
m1Same subnetLocal
Ad
M1
LocalAdlm1
m1 lm1
Multicastproxy
Multicast Stream Server
Figure 21: MarconiNet fast-handoff scenario
In the following subsections, we describe several methods associated with faster stream deliveryunder MarconiNet environment.
Post-Registration: In a post-registration scenario, when a client moves to a new subnet, it obtainsthe new IP address and then sends the join query via IGMP method. In some cases as discussed in[104] IGMP could be modified to provide aggregate group report to expedite the join latency. Butin MarconiNet environment we propose a new mechanism where the client uses an application layertriggering mechanism based on RTCP to facilitate the join and leave. Triggering at the lower hierarchyis accomplished by RTCP feedback mechanism, but the local server may trigger the multicast flow fromthe upstream router using IGMP method. Using an RTCP based triggering technique offers a solution atthe user space and thus is best suitable in case the end-client’s kernel is not multicast enabled.
Pre-registration Method: Pre-registration method has the advantage over post-registration by re-ducing the join latency for an impending client at the expense of extra flow of stream in the adjacent cellfor certain time. Two kinds of pre-registration schemes have been designed that are described below.
For each of neighboring stations sharing an overlapping area with another station there is a multicastannouncement (address) associated that can be pre-provisioned. Each local station can point to find outthe program subscribed to (group address) by the impending mobile host. Just before a mobile nodeleaves (decides to leave) the cell, a local policy decision (e.g., signal-to-noise ratio) will trigger an RTCPmessage to the local announcement address, the server in turn announces that to the shared multicastaddresses which the neighboring stations listen to in the global space. The neighboring stations (servers)
27
look up to the multicast address and check it with their own databases to see the group association of thismulticast stream. In the absence of this association, the server sends an IGMP message to the upstreamrouter and passes the stream to the local cells using a locally scoped multicast address, even before theclient has moved to the new cell thus minimizing the interruption. Similarly, the client sends an RTCPBYE to the server as it moves away from the previous server.
Another approach is to deploy proxy agents in each subnet. These proxy agents join the upstreammulticast tree on behalf of the servers, even before the clients move into the cell. The neighboring proxyservers then listen to a common multicast address to figure out the impending host’s subscribed multicastaddress. In this case the multicast proxy sends the IGMP query messages beforehand on behalf of thelocal servers. Similary a multicast proxy agent within each upstream router can help forward the globalstream to the respective global multicast addresses (e.g., for areas where these clients are impending tomove) in each subnet for a specific period of time that is determined by the client’s entry to the cell.Thus each neighboring server can receive the stream irrespective of whether the mobile node is movinginto that cell or not. In either case as soon as the mobile node moves into the new cell it notifies theproxy agent to leave the tree and multicast proxy agent stops forwarding the traffic.
During Registration: Group membership information can also be passed during the client’s regis-tration to the new network. During a node’s movement between subnets it can send the request for theparticular multicast address in its DHCP Discover option or PPP server option message about the localmulticast address it has been listening to in the previous subnet. During the process of obtaining the IPaddress from the DHCP server, the client can send the unsolicited “JOIN” request for the desired locallyscoped multicast address to the server. Thus the server can join the desired group during the time theclient is in the process of getting configured. Pre-registration method helps reduce the join latency at thecost of bandwidth in the previous cell or subnet.
8.3 QoS Management
It is desirable that a mobile which is part of a multicast communication should be able to maintain thesame quality of service as it moves across subnets within a domain and connects to a different server.In order to minimize the disruption of the desired quality of service it is important that the local serveris made aware of the bandwidth requirement of the client’s current application proactively. We proposean approach that combines both IETF based Diffserv [105] and RSVP-based [106] techniques. Ourapproach uses diffserv based technique by instituting policy control [107], [108], [109] in the edgerouters or servers, but relies on the RTCP feedback report to maintain QoS parameters for the multicaststreaming traffic. As part of its RTCP feedback, each mobile keeps on advertising its QoS parameters(e.g., delay, jitter) on the locally scoped multicast address using SAP. This information gets advertisedin the globally scoped multicast address (M) where both the adjacent servers can determine the QoSparameters for each mobile impending to move. If a mobile listening to a specific multicast addresshappens to be the first client in the adjacent cell, then it needs to make a reservation apriori so that it canreceive the desired quality of service for the streaming traffic as soon as it moves in there. As part of theimplementation, Linux’s traffic control (tc) mechanism was used to set up the traffic priority destined fora particular multicast address in one of its interfaces. While within a cell the client can also negotiatewith the Linux server to control the traffic rate by making additional real-time request. A receiver basedadaptation scheme such as layered encoding scheme and multiple multicast groups for one session [110]can be used to take care of receivers with different QoS requirement.
8.4 Movement between heterogeneous access networks
Several user level solutions such as UMTP (UDP Multicast Tunneling Protocol), and AMT (AutomaticMulticast Tunneling) help connect the isolated multicast enabled islands. In order to support movementbetween a multicast enabled network and non-multicast enabled network, the tunnels have to be setupon the end clients proactively in cooperation with the proxies at the edges. Several techniques to supportmobile users between such diverse networks (e.g., multicast and non-multicast) have been proposed in
28
Figure 22: Protocol flow for IGMP handoff
[111]. In this case the proxy at the edge of the network helps setting up the tunnels between the contentservers and the end client as it prepares to move to a non-multicast enabled network.
8.5 Testbed prototype and results
As part of the initial experiment many of the multimedia streaming applications were demonstratedusing some of the Mbone tools such as sdr, rat, vic, [65] and MarconiNet software modules for RAS,RSC, and IMC. UMTP tunneling techniques have been used to demonstrate the streaming applicationin the event of non-availability of multicast routers in some parts of the network. Experiments wereconducted for cell, subnet and domain mobility. Several measurements were taken including the timefor layer 2 movement detection, IP address acquisition, and join/leave latency using network layer IGMPand application layer RTCP methods. CGMP (Cisco Group Management Protocol) implementation ofCisco’s layer 2 switch was used to control the multicast stream during mobile’s movement between thecells within an subnet. Other functional aspects of MarconiNet such as QoS management based onreal-time feedback, several location based services and localized advertisement insertion have also beenrealized in the tesbed. It was found that during subnet movement in a regular 802.11 network a clientdoes not send IGMP/RTCP leave message when it moves out of a subnet. This contributes to undesirableleave latency. Figure 22 shows the protocol sequence during the subnet handoff in 802.11 environmentand exposes the associated join and leave latency. It was found from the experiment that a proxy-basedexpedited join reduces the join latency to almost zero. Similarly a proxy can send group LEAVE messageon behalf of the client as soon as the client disappears from the current cell or subnet. Figure 23 showssome of the prototype components of MarconiNet, primarily local station manager, Internet client, radiostation client and channel monitor showing on-line statistics of the tuned-in audience.
9 Future Work in MarconiNet
This section provides a roadmap for completion of research by describing briefly the additional workthat needs to be performed beyond the initial results. Most of the future work will concentrate onenhancement of prototypes and development of analytical models.
1. Reduction of Join and Leave latency
As was observed from the experiment there is an inherent leave latency for 802.11 networks, sincemobile does not get a chance to send the leave report to the router during its movement. As partof the future work, I will develop a proxy-based mechanism to take care of inherent leave latencyin 802.11 environment during the subnet handoff. I will analyze handoff delay comparison ofdifferent fast-handoff mechanisms discussed under Section 8.2 in 802.11b environment.
29
Figure 23: MarconiNet Prototype Components
Expected completion date is March 2005.
2. Comparison of RTCP and IGMP Triggering Models
I will develop analytical and simulation models for both RTCP and IGMP based triggering ap-proaches. These models will analyze the effect of number of groups, mobility pattern and popu-lation density on the join and leave latencies due to a mobile’s movement. I will figure out howRTCP based triggering approach helps expediting multicast stream delivery during a mobile’smovement compared to standard IGMP based layer 3 approach. This analysis will help determinean optimal timer for a specific scenario involving number of multicast groups.
Expected completion date is April 2005.
3. QoS integration with mobility for MarconiNet
I will integrate the QoS mechanism discussed in Section 8.3 with the existing MarconiNet proto-type. It is desirable that as the mobile moves from one subnet to another and connects to a differentserver, the mobile will continue to receive the audio or video stream with the same quality of ser-vice (i.e., bandwidth). Diffserv-based Linux traffic control mechanism will be used in conjunctionwith RTCP and SAP to provide the desired QoS guarantee. I will conduct performance analysisfor different media traffic as the mobile moves between the subnets and is subjected to join andleave latency.
Expected completion date is June 2005
10 Conclusion
This thesis proposal has described new architectures to support wireless Internet telephony and mobilecontent distribution. It has provided a synopsis of the initial results obtained so far that includes de-sign, system prototypes, multimedia testbed implementation, results and analysis from simulation andexperiments. Some of the key contribution in mobility management area are secure SIP-based personaland terminal mobility involving heterogeneous networks, policy-based integrated mobility management,several fast-handoff techniques for 802.11 and cellular networks including prototypes and performance.Some of the key contribution in mobile content distribution parts of the thesis are hierarchical scope-based multicast architecture, location-based advertisement insertion, application layer triggering meth-ods, intra-domain fast-handoff techniques for multicast streaming and QoS management. Roadmap andtimeline to completion of research in the respective area have been laid out for each part that will includeanalytical models, optimization techniques and more prototyping results.
30
References
[1] A. Dutta, F. Vakil, J. Chen, M. Tauil, S. Baba, and H. Schulzrinne, “Application layer mobilitymanagement scheme for wireless Internet,” in 3Gwireless, (San Francisco), p. 7, May 2001.
[2] R. E. Droms, “Dynamic host configuration protocol,” RFC 2131, Internet Engineering Task Force,Mar. 1997.
[3] R. E. Droms, I. W. Ed., J. Bound, B. Volz, T. Lemon, C. E. Perkins, and M. Carney, “Dynamichost configuration protocol for IPv6 (dhcpv6),” RFC 3315, Internet Engineering Task Force, July2003.
[4] “The point-to-point protocol (PPP),” RFC 1661, Internet Engineering Task Force, July 1994.
[5] A. Dutta, O. Altintas, W. Chen, and H. Schulzrinne, “Mobility approaches for all IP wirelessnetworks,” in SCI, (Orlando, Florida), July 2002.
[6] C. E. Perkins, “IP mobility support for IPv4,” RFC 3344, Internet Engineering Task Force, Aug.2002.
[7] C. E. Perkins, “IP encapsulation within IP,” RFC 2003, Internet Engineering Task Force, Oct.1996.
[8] C. E. Perkins, “Minimal encapsulation within IP,” RFC 2004, Internet Engineering Task Force,Oct. 1996.
[9] S. K. Park, “Rapid commit option for DHCPv4,” Internet Draft draft-ietf-dhc-rapid-commit-opt-00, Internet Engineering Task Force, Dec. 2003. Work in progress.
[10] A. McAuley, S. Das, S. Madhani, S. Baba, and Y. Shobatake, “Dynamic registration and config-uration protocol (DRCP),” internet draft, Internet Engineering Task Force, July 2000. Work inprogress.
[11] “IP mobility support,” RFC 2002, Internet Engineering Task Force, Oct. 1996.
[12] P. Calhoun, G. Montenegro, and C. E. Perkins, “Mobile IPv4 regional registration,” Internet Draftdraft-ietf-mobileip-reg-tunnel-08, Internet Engineering Task Force, Nov. 2003. Work in progress.
[13] A. Campbell, J. Gomez, S. Kim, A. G. Valk, C.-Y. Wan, and Z. R. Turnyi, “Design, implementa-tion, and evaluation of cellular IP,” IEEE Personal Communications Magazine, vol. 7, pp. 42–49,Aug. 2000.
[14] R. Ramjee, T. F. LaPorta, L. Salgarelli, S. Thuel, K. Varadhan, and L. Li, “IP-based accessnetwork infrastructure for next-generation wireless networks,” IEEE Personal CommunicationsMagazine, vol. 7, pp. 34–41, Aug. 2000.
[15] R. Jain, T. Raleigh, D. Yang, L. F. Chang, C. J. Graff, M. Bereschinsky, and M. Patel, “Enhancingsurvivability of mobile Internet access using mobile IP with location registers,” in Proceedings ofthe Conference on Computer Communications (IEEE Infocom), (New York), Mar. 1999.
[16] S. Das, A. Dutta, A. McAuley, A. Misra, and S. Das, “IDMP: an intra-domain mobility manage-ment protocol for next generation, wireless networks,” IEEE Personal Communications Maga-zine, June 2002.
[17] D. B. Johnson, C. E. Perkins, and J. Arkko, “Mobility support in IPv6,” RFC 3775, InternetEngineering Task Force, June 2004.
31
[18] S. Thomson and T. Narten, “IPv6 stateless address autoconfiguration,” RFC 2462, Internet Engi-neering Task Force, Dec. 1998.
[19] A. C. Snoeren and H. Balakrishnan, “An end-to-end approach to host mobility,” in ACM/IEEEInternational Conference on Mobile Computing and Networking (MobiCom), (Boston, Mas-sachusetts, USA), pp. 155–166, Aug. 2000.
[20] D. A. Maltz and P. Bhagwat, “MSOCKS: an architecture for transport layer mobility,” in Pro-ceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, Cal-ifornia), p. 1037, March/April 1998.
[21] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, “SOCKS protocol version 5,”RFC 1928, Internet Engineering Task Force, Mar. 1996.
[22] S. N. Koh et al., “Use of SCTP for seamless handover,” internet draft, Internet Engineering TaskForce, Feb. 2003. Work in progress.
[23] H. Schulzrinne and E. Wedlund, “Application-layer mobility using SIP,” Mobile Computing andCommunications Review (MC2R), vol. 4, pp. 47–57, July 2000.
[24] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley,and E. Schooler, “SIP: session initiation protocol,” RFC 3261, Internet Engineering Task Force,June 2002.
[25] A. Dutta, P. Agrawal, J.-C. Chen, S. Das, D. Famolari, S. Baba, Y. Ohba, and A. McAuley, “Real-izing steaming wireless Internet telephony and streaming multimedia testbed,” Elsevier, Computerand Communication, Oct. 2003.
[26] E. Wedlund and H. Schulzrinne, “Mobility support using SIP,” in 2nd ACM/IEEE InternationalConference on Wireless and Mobile Multimedia (WoWMoM), (Seattle, Washington), Aug. 1999.
[27] A. Dutta and H. Schulzrinne, “A streaming architecture for next generation Internet,” in Confer-ence Record of the International Conference on Communications (ICC), (Helsinki), p. 7, June2001.
[28] MWIF, “Mobile wireless internet forum.” www.mwif.org.
[29] M. Arango, A. Dugan, I. Elliott, C. Huitema, and S. Pickett, “Media gateway control protocol(MGCP) version 1.0,” RFC 2705, Internet Engineering Task Force, Oct. 1999.
[30] A. Dutta, H. Schulzrinne, W. Chen, and O. Altintas, “Mobility support for wireless streamingmultimedia in marconinet,” in IEEE Broadband Wireless Summit, Interop, (Las Vegas), p. 7, May2001.
[31] D. Wong and T. J. Lim, “Soft handoffs in CDMA mobile systems,” IEEE Personal Communica-tions Magazine, vol. 4, Dec. 1997.
[32] A. Dutta, S. Madhani, W. Chen, and O. Altintas, “GPS-IP based fast-handoff for mobiles,” inNYMAN 2003 Conference, Sept. 2003.
[33] A. Yegin and M. B. et. al., “Link-layer hints for detecting network attachments,” Internet Draftdraft-yegin-dna-l2-hints-00, Internet Engineering Task Force, Oct. 2003. Work in progress.
[34] J.-O. Vatn and G. C. Maguire, “The effect of using co-located care-of addresses on macro han-dover latency,” in 14th Nordic Tele-traffic Seminar, (Technical University of Denmark, Lyngby,Denmark), Aug. 1998.
32
[35] H. Schulzrinne, “SIP registration,” internet draft, Internet Engineering Task Force, Apr. 2001.Work in progress.
[36] D. Forsberg, “Protocol for carrying authentication for network access (PANA),” Internet Draftdraft-ietf-pana-pana-03, Internet Engineering Task Force, Feb. 2004. Work in progress.
[37] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “Diameter base protocol,” RFC3588, Internet Engineering Task Force, Sept. 2003.
[38] M. Baugher et al., “The secure real-time transport protocol,” internet draft, Internet EngineeringTask Force, July 2003. Work in progress.
[39] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, and L. Repka, “S/MIME version 2 messagespecification,” RFC 2311, Internet Engineering Task Force, Mar. 1998.
[40] H. Basilier, P. Calhoun, M. Holdrege, T. Johansson, J. Kempf, and J. Rajaniemi, “AAA require-ments for IP telephony/multimedia,” internet draft, Internet Engineering Task Force, Mar. 2002.Work in progress.
[41] A. Dutta, S. K. Das, P. Li, A. McAuley, Y. Ohba, S. Baba, and H. Schulzrinne, “Secured mo-bile multimedia communication for wireless Internet,” in International Conference on NetworkSensing and Control, (Taipei, Taiwan), IEEE, IEEE, Mar. 2004.
[42] A. Dutta, O. Altintas, H. Schulzrinne, and W. Chen, “Multimedia SIP sessions in a heterogeneousaccess environment,” in 3G Wireless, (San Francisco, CA), May 2002.
[43] J. Rosenberg, D. Drew, and H. Schulzrinne, “Getting SIP through firewalls and NATs,” internetdraft, Internet Engineering Task Force, Feb. 2000. Work in progress.
[44] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN - simple traversal of UDP throughNATs,” internet draft, Internet Engineering Task Force, Mar. 2002. Work in progress.
[45] A. Dutta, T. Zhang, S. Madhani, K. Taniuchi, K. Fujimoto, Y. Katsube, Y. Ohba, andH. Schulzrinne, “Secure universal mobility for wireless Internet,” in WMASH, ACM, ACM, Oct.2004.
[46] www.linux-ipv6.org.
[47] A. J. Tuominen and H. L. Petander, “MIPL mobile IPv6 for linux in HUT campus network medi-apoli,” in Proceedings of Ottawa Linux Symposium, 2001, (Ottawa, Canda), June 2001.
[48] T. Narten, E. Nordmark, and W. Simpson, “Neighbor discovery for IP version 6 (ipv6),” RFC2461, Internet Engineering Task Force, Dec. 1998.
[49] N. Nakajima, A. Dutta, S. Das, and H. Schulzrinne, “Handoff delay analysis and measurementfor SIP based mobility in IPv6,” in International Conference on Computers and Communications,IEEE, IEEE, May 2003.
[50] J. Chen et al., “Dynamic service negotiation protocol (DSNP),” internet draft, Internet Engineer-ing Task Force, June 2002. Work in progress.
[51] P.-Y. Hsieh, A. Dutta, and H. Schulzrinne, “Application layer mobility proxy for real-time com-munication,” in World Wireless Congress, 3G Wireless, (San Francisco), Delson, Delson, May2003.
[52] S. Donovan, “The SIP INFO method,” RFC 2976, Internet Engineering Task Force, Oct. 2000.
33
[53] F. Vakil et al., “Supporting mobility for TCP with SIP,” internet draft, Internet Engineering TaskForce, Nov. 2000. Work in progress.
[54] G. Su and J. Nieh, Mobile Communication with Virtual Network Address Translation. Departmentof Computer Science, Columbia University, New York, NY, cucs-003-02 ed., Feb. 2002.
[55] K. Malki, “Low latency handoffs in mobile IPv4,” Internet Draft draft-ietf-mobileip-lowlatency-handoffs-v4-08, Internet Engineering Task Force, Jan. 2004. Work in progress.
[56] C. Perkins and K.-Y. Wang, “Optimized smooth handoffs in mobile IP,” in Fourth IEEE Sym-posium on Computers and Communications (ISCC ’99), (Red Sea, Egypt), pp. 340–346, July1999.
[57] P. Calhoun, T. Hiller, J. Kempf, P. McCann, C. Pairla, A. Singh, and S. Thalanany, “Foreign agentassisted hand-off,” internet draft, Internet Engineering Task Force, Nov. 2000. Work in progress.
[58] H. Soliman, C. Castelluccia, K. Malki, and L. Bellier, “Hierarchical mobile IPv6 mobility man-agement (hmipv6),” internet draft, Internet Engineering Task Force, July 2003. Work in progress.
[59] F. Vakil, D. Famolari, S. Baba, and D. Famolari, “Virtual soft hand-off in IP-Centric wirelessCDMA networks,” in 3G Wireless 2001, (San Francisco), Delson, Delson, May 2001.
[60] S. K. Park and Y. W. Han, “IPv6 DAD optimization goals and requirements,” Internet Draftdraft-park-dna-ipv6dadopt-requirement-02, Internet Engineering Task Force, Dec. 2003. Workin progress.
[61] Y. Han et al., “Advance duplicate address detection,” internet draft, Internet Engineering TaskForce, July 2003. Work in progress.
[62] A. Dutta, H. Schulzrinne, S. Madhani, O. Altintas, and W. Chen, “Optimized fast-handoffschemes for application layer mobility management,” Mobile Computing and CommunicationsReview (MC2R), vol. Volume 6, Nov. 2002.
[63] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: a transport protocol for real-timeapplications,” RFC 3550, Internet Engineering Task Force, July 2003.
[64] J. Lennox and H. Schulzrinne, “Transporting user control information in SIP REGISTER pay-loads,” internet draft, Internet Engineering Task Force, Mar. 1999. Work in progress.
[65] A. Sasse, V. J. Hardman, I. Kouvelas, C. E. Perkins, O. Hodson, A. I. Watson, M. Handley, andJ. Crowcroft, “RAT (robust-audio tool),” 1995.
[66] A. Misra, S. Das, A. Dutta, A. McAuley, and S. Das, “IDMP-based fast handoffs and paging inip-based cellular networks,” in 3Gwireless, (San Francisco), p. 6, May 2001.
[67] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, “Dynamic updates in the domain name system(DNS UPDATE),” RFC 2136, Internet Engineering Task Force, Apr. 1997.
[68] A. Dutta, D. Wong, J. Burns, R. Jain, K. Young, A. McAuley, and H. Schulzrinne, “Realization ofintegrated mobility management for ad-hoc networks,” in IEEE Milcom, (Annaheim, California),Oct. 2002.
[69] K. Wong, H. yu Wei, A. Dutta, K. Young, and H. Schulzrinne, “IP micro-mobility managementusing host-based routing,” in Wireless IP and building the Mobile Internet (S. Dixit and R. Prasad,eds.), Artech House, 2002.
[70] D. Wong, A. Dutta, J. Burns, K. Young, and H. Schulzrinne, “A multilayered mobility manage-ment scheme for auto-configured wireless IP networks,” IEEE Wireless Magazine, Oct. 2003.
34
[71] D. Wong, A. Dutta, H. Schulzrinne, and K. Young, “Managing simultaneous mobility of IP hosts,”in IEEE International Military Communications Conference (MILCOM), (Boston, MA, USA),IEEE, IEEE, Oct. 2003.
[72] A. Dutta and H. Schulzrinne, “Marconinet - an architecture for Internet radio and TV networks,”in Proc. International Workshop on Network and Operating System Support for Digital Audio andVideo (NOSSDAV), (Basking Ridge, New Jersey), pp. 241–245, June 1999.
[73] S. E. Deering, D. Estrin, D. Farinacci, V. Jacobson, C.-M. Liu, and L. Wei, “An architecture forwide-area multicast routing,” in SIGCOMM Symposium on Communications Architectures andProtocols, (London, UK), pp. 126–135, Sept. 1994.
[74] J. Moy, “Multicast routing extensions for OSPF,” in International Networking Conference (INET),(San Francisco, California), pp. BCC–1 – BCC–7, Internet Society, Aug. 1993.
[75] D. Waitzman, C. Partridge, and S. E. Deering, “Distance vector multicast routing protocol,” RFC1075, Internet Engineering Task Force, Nov. 1988.
[76] T. Ballardie, P. Francis, and J. Crowcroft, “Core based trees (CBT),” in SIGCOMM Symposiumon Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California),pp. 85–95, ACM, Sept. 1993. also in Computer Communication Review 23 (4), Oct. 1992.
[77] D. Thaler, “Border gateway multicast protocol (BGMP): protocol specification,” Internet Draftdraft-ietf-bgmp-spec-06, Internet Engineering Task Force, Jan. 2004. Work in progress.
[78] A.Basso, C.D. Cranor et al, ”PRISM an IP-based architecture for broadband access to TV andother streaming architecture”, in Proceedings of International Worksh op on Network and Oper-ating Systems Support for Digital Audio and Video (NOSSDAV ), (Chapel Hill, North Carolina,USA), pp. 11-17, June 2000
[79] C. Diot, B. N. Levine, B. Lyles, H. Kassem, and D. Balensiefen, “Deployment issues for the IPmulticast service and architecture,” IEEE Network, vol. 14, Jan. 2000.
[80] R. Boivie et al., “Explicit multicast (xcast) basic specification,” Internet Draft draft-ooms-xcast-basic-spec-05, Internet Engineering Task Force, Sept. 2003. Work in progress.
[81] H. W. Holbrook and B. Cain, “Source-specific multicast for IP,” internet draft, Internet Engineer-ing Task Force, Mar. 2000. Work in progress.
[82] R. Finlayson, “The UDP multicast tunneling protocol,” Internet Draft draft-finlayson-umtp-09,Internet Engineering Task Force, Nov. 2003. Work in progress.
[83] D. Thaler, L. Vicisano, et al., “IPv4 automatic multicast without explicit tunnels (AMT),” internetdraft, Internet Engineering Task Force, Apr. 2002. Work in progress.
[84] I. Romdhani, M. Kellil, H.-Y. Lach, A. Bouabdallah, and H. Bettaher, “IP mobile multicast:Chalenges, solutions and open issues,” motorola technical report, Motorola Labs, Paris, France,July 2002.
[85] G. Xylomenos and G. C. Polyzos, “IP multicast for mobile hosts,” IEEE Communications Maga-zine, vol. 35, Jan. 1997.
[86] U. Varshney and S. Chatterji, “Architectural issues in IP multicasting over wireless networks,”in IEEE conference on Wireless Communication and Networking Conference, IEEE, IEEE, June1999.
35
[87] A. Acharya, A. Bakre, and B. R. Badrinath, “IP multicast extensions for mobile internetworking,”Technical Report LCSR-TR-243, Department of Computer Science, Rutgers University, NewBrunswick, New Jersey, Apr. 1995.
[88] J.-L. C. Wu, “An IP mobiity support architecture for 4GW wireless infrastructure,” in PCC, Nov.1999.
[89] A. McAuley, E. Bommaiah, A. Misra, R. R. Talpade, S. Thomson, and K. C. Young, “Mobilemulticast proxy,” in IEEE Milcom, (Atlantic City, New Jersey), Nov. 1999.
[90] C. Williamson, T. Harrison, W. L. Mackrell, and R. B. Bunt, “Performance evaluation of the MoMmobile multicast protocol,” ACM Mobile Networks and Applications (MONET) Journal, vol. 3,pp. 189–201, Aug. 1998.
[91] C. Lin and K.-M. Wang, “Mobile multicast support in IP networks,” in Proceedings of the Con-ference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000.
[92] C. L. Tan and S. Pink, “Mobicast: A multicast scheme for wireless networks,” Mobile Networksand Applications, vol. 5, pp. 259–271, Jan. 2000.
[93] J. Mysore and V. Bharghavan, “A new multicasting-based architecture for Internet host mobil-ity,” in ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom),(Hungary), Sept. 1997.
[94] K. Almeroth and M. Ammar, “Multicast group behavior in the internet’s multicast backbone(mbone),” IEEE Communications Magazine, vol. 35, June 1997.
[95] K. Almeroth, “A long-term analysis of growth and usage patterns in the multicast backbone(mbone),” in Proceedings of the Conference on Computer Communications (IEEE Infocom), (TelAviv, Israel), Mar. 2000.
[96] M. Handley and V. Jacobson, “SDP: session description protocol,” RFC 2327, Internet Engineer-ing Task Force, Apr. 1998.
[97] M. Handley, C. E. Perkins, and E. Whelan, “Session announcement protocol,” RFC 2974, InternetEngineering Task Force, Oct. 2000.
[98] H. Schulzrinne, A. Rao, and R. Lanphier, “Real time streaming protocol (RTSP),” RFC 2326,Internet Engineering Task Force, Apr. 1998.
[99] T. Friedman and D. F. Towsley, “Multicast session membership size estimation,” in Proceedingsof the Conference on Computer Communications (IEEE Infocom), (New York), Mar. 1999.
[100] D. A. Ferguson, “Measurement of mundane TV behaviors: Remote control device flipping fre-quency,” Journal of Broadcasting and Electronic Media, Jan. 1994.
[101] W. Fenner, “Internet group management protocol, version 2,” RFC 2236, Internet EngineeringTask Force, Nov. 1997.
[102] B. Williamson, Developing IP Multicast Networks: The definitive Guide to Designing and De-ploying CISCO IP Multicast Networks, vol. Volume 1. San Francisco: Cisco Press, Jan. 2000.
[103] M. Flament, F. Gessler, F. Lagergren, O. Queseth, R. Stridh, M. Unbehaun, J.-L. C. Wu, andJ. Zander, “An approach to 4th generation wireless infrastructures, scenarios and research issues,”in VTC, (Houston, Texas), May 1999.
[104] S. Kaur, B. Madan, and S. Ganeshan, “Multicast support for mobile IP using modified IGMP,” inIEEE WCNC, pp. 948–952, Mar. 1999.
36
[105] S. Blake, D. L. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An architecture fordifferentiated service,” RFC 2475, Internet Engineering Task Force, Dec. 1998.
[106] “Resource reservation protocol (RSVP) – version 1 applicability statement some guidelines ondeployment,” RFC 2208, Internet Engineering Task Force, Sept. 1997.
[107] E. Magna, E. Izkue, and J. Villadangos, “Review of traffic scheduler features on general purposeplatforms,” ACM SIGCOMM Computer Communication Review, vol. 31, pp. 50–79, Apr. 2001.
[108] S. Radhakrishnan, “Linux - advanced networking overview,” technical report, The University ofKansas, Information and Telecommunication, Aug. 1999.
[109] W. Almesberger, J. H. Salim, and A. Kuznetsov, “Differentiated services on linux,” internet draft,Internet Engineering Task Force, June 1999. Work in progress.
[110] S. McCanne, V. Jacobson, and M. Vetterli, “Receiver-driven layered multicast,” in SIGCOMMSymposium on Communications Architectures and Protocols, (Palo Alto, California), pp. 117–130, Aug. 1996.
[111] J. Chennikara, W. Chen, A. Dutta, and O. Altintas, “Application layer multicast for mobile users indiverse networks,” in Proceedings of the IEEE Conference on Global Communications (GLOBE-COM), (Taipe, Taiwan), Nov. 2002.
37
