Integrating Quality of Service and Mobility Support into Wireless Communication Networks
by Jonathan Chan-Lon Chan
A thesis submitted in fulfilment of the requirements for the degree of Doctor of Philosophy
School of Electrical Engineering and Telecommunications The University of New South Wales August, 2001 U i i w ] 2 9 MAY 2002 LIBRARY CERTIFICATE OF ORIGINALITY
I hereby declare that this submission is my own work and to the best of my knowledge it contains no materials previously published or written by another person, nor material which to a substantial extent has been accepted for the award of any other degree or diploma at UNSW or any other educational institution, except where due acknowledgement is made in the thesis. Any contribution made to the research by others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in the thesis.
I also declare that the intellectual content of this thesis is the product of my own work, except to the extent that assistance from others in the project’s design and conception or in style, presentation and linguistic expression is acknowledged. Acknowledgements
My deep gratitude must go out to God for His guidance and love for me throughout my life, and it was such a blessing to meet so many wonderful people throughout the period of my doctoral studies.
First of all, I must thank my supervisor Professor Aruna Seneviratne for his constant encouragement, insightful comments and invaluable suggestions. He has taught me what research is and how it is performed. Besides Aruna himself, my thanks should be extended to the Seneviratne’s family, who have gone through all the troubles of organising countless “Aussie BBQs” and sport events at their place. My gratitude also goes out to Dr. Terry Percival, my external supervisor, for his guidance and kindness of letting me to conduct my experimental work at CSIRO Telecommunications and Industrial Physics (TIP).
I am also grateful to my fellow researchers in the MOBQOS group at UNSW (formerly at UTS) and the Telecommunication group at CSIRO TIP. Special thanks go to Bjorn Landfeldt, Sebastien Ardon, Binh Thai, Marius Portmann, Robert Hsieh, Pipat Sookavatana, Woraphon Lilakiatsakun, Ren Liu, Muneyb Minhazuddin, Glynn Rogers, Jim Argyros, John Deane, Hajime Suzuki, Graham Daniels, Carol Wilson, Jayasri Joseph and Sue Zhou for their friendship, stimulating discussions and helpful assistance during my research.
Thanks also go to Dr. Arthur Hung, my brother in Christ, who encouraged me to initiate my PhD study and directed me to my thesis supervisor.
I would also like to acknowledge that CSIRO TIP and the Australian Commonwealth Government have funded my research from the beginning, thus making this thesis possible.
My special thanks should go to my parents, mother-in-law, brother, sister, brother- in-law, and sister-in-law for their understanding and support. iii
My final acknowledgements go to my wife Vivian for her love and support. Her partnership is a special blessing for me. I am also grateful to my baby daughter Victoria, who often encourages me to wake up early in the morning to continue my work. iv
Publication List
1. J. Chan, B. Landfeldt, R. Liu and A. Seneviratne, “A Home-Proxy Based Wireless Internet Framework in Supporting Mobility and Roaming of Real-Time Services,” IEICE Transactions on Communications (Special Issue on Mobile Multimedia Communications), E84-B (4), Apr. 2001.
2. J. Chan, B. Landfeldt and A. Seneviratne, “The Challenges of Provisioning Real- Time Services in Wireless Internet,” Telecommunication Journal of Australia, 50(3), Spring 2000.
3. J. Chan, B. Landfeldt, A. Seneviratne and P. Sookavatana, “Integrating Mobility Prediction and Resource Pre-allocation into a Home-Proxy Based Wireless Internet Framework,” in Proc. IEEE ICON’2000, Sep. 2000.
4. J. Chan and A. Seneviratne, “A Practical User Mobility Prediction Algorithm for Supporting Adaptive QoS in Wireless Networks,” in Proc. IEEE ICON’99, Sep. 1999.
5. S. Zhou, J. Chan, A. Seneviratne and T. Percival, “A Mobility-Enabled Hybrid Wireless Network with Standard ATM Back bone Switches: Architecture, Implementation and Performance,” in Proc. IEEE WCNC’99, Sep. 1999.
6. J. Chan, S. Zhou and A. Seneviratne, “A QoS Adaptive Mobility Prediction Scheme for Wireless Networks,” in Proc. IEEE GLOBECOM’98, Nov. 1998.
7. J. Chan, R. De Silva, S. Zhou and A. Seneviratne, “A Framework for Mobile Wireless Networks with an Adaptive QoS Capability,” in Proc. MoMuC’98, Oct. 1998.
8. J. Chan, S. Zhou and A. Seneviratne, “A Hybrid Handoff Scheme with Prediction Enhancement for Wireless ATM Network,” in Proc. APCC’97, Dec. 1997. Preface
This thesis describes the research undertaken in fulfilment of the requirements for the Degree of Doctor of Philosophy, at The University of New South Wales, Australia. This work was undertaken during the period January 1997 to February 2001.
“I devoted myself to study and to explore by wisdom all that is done under heaven. What a heavy burden God has laid on men!”
(Ecclesiastes 1:13) vi
Table of Contents
Certificate of Originality...... i
Acknowledgements...... ii
Publication List...... iv
Preface...... v
Table of Contents...... vi
Abstract...... xii
CHAPTER 1. Introduction...... 1
1.1. Major Findings in This Thesis...... 4
1.2. Outline of This Thesis...... 6
CHAPTER 2. Background...... 10
2.1. The Evolving Network Technologies...... 10
2.1.1. Circuit Switching...... 10
2.1.2. Packet Switching...... 11
2.1.3. Mobile Networking...... 13
2.1.4. Circuit or Packet Switching?...... 14
2.2. Asynchronous Transfer Mode...... 15
2.2.1. Overview of Asynchronous Transfer Mode...... 15
2.2.2. Discussion of Asynchronous Transfer Mode Issues...... 17
2.3. Internet Protocol...... 18
2.3.1. Overview of the Internet Protocol...... 18
2.3.2. Discussion of Internet Protocol Issues 19 vii
2.4. A Brief Comparison of the Design Philosophy behind ATM and IP Protocols...... 19
2.5. Challenges of Provisioning Multimedia Services in Mobile Wireless Networks...... 21
2.6. Summary...... 23
CHAPTER 3. Quality of Service Support in the Network...... 25
3.1. Problem Statement...... 25
3.2. ATM QoS Support with Wireless Extensions...... 27
3.2.1. Wireless ATM...... 27
3.2.2. QoS Control in Wireless ATM...... 29
3.2.3. Discussion of Soft QoS Issues...... 29
3.3. IP Networks QoS Support...... 30
3.3.1. Integrated Services (IntServ)...... 30
3.3.1.1. Overview of IntServ...... 31
3.3.1.2. Discussion of IntServ Issues...... 33
3.3.2. Differentiated Services (DiffServ)...... 34
3.3.2.1. Overview of DiffServ...... 34
3.3.2.2. Discussion of DiffServ Issues...... 37
3.4. Relationship between Mobility Support and Current QoS Architecture...... 38
3.5. Summary...... 39
CHAPTER 4. Mobility Support in the Network...... 42
4.1. Problem Statement...... 42
4.2. Mobility Management for Wireless ATM Networks...... 44
4.2.1. Location Management for Wireless ATM...... 44 viii
4.2.1.1. Location Update...... 45
4.2.1.2. Terminal Paging...... 47
4.2.1.3. Management of User Location Information...... 48
4.2.1.4. Discussion of Location Management Issues...... 51
4.2.2. Handover Management for Wireless ATM...... 53
4.2.2.1. Typical Connection Rerouting Schemes...... 53
4.2.2.2. Maintenance of QoS Agreements...... 57
4.2.2.3. Discussion of Handover Management Issues...... 58
4.3. Mobility Management for IP Networks...... 61
4.3.1. Personal Mobility...... 61
4.3.2. Device Mobility...... 63
4.3.3. Mobile IP...... 64
4.3.3.1. Location Registration...... 65
4.3.3.2. Packet Forwarding...... 65
4.3.3.3. Handover Detection...... 66
4.4. Relationships between QoS support and Current Mobility Management Techniques...... 67
4.4.1. Location Management and QoS Support...... 67
4.4.2. Handover Management and QoS Support...... 68
4.4.3. Personal Mobility and QoS Support...... 69
4.5. Summary...... 69
CHAPTER 5. QoS-Aware Device Mobility...... 73
5.1. Current Pitfalls and Enhancements of Mobile IP...... 73
5.1.1. Route Optimisation...... 74
5.1.2. Frequent Handover and Fast Location Updates...... 75
5.1.3. Tunnelling across QoS Domains...... 79 ix
5.1.4. Link-Layer Assisted Handover Detection...... 81
5.1.5. Discussion of Mobility Management Issues...... 82
5.1.6. Charging and Accounting for Mobile Multimedia Services...... 83
5.1.6.1. Authentication and Reconciliation of Roaming Services...... 83
5.1.6.2. Pricing and Charging for QoS...... 84
5.2. A Novel Home-Proxy Based Solution...... 85
5.2.1. Advantages of Split-Connection Approach...... 86
5.2.2. Realisation of Split-Connection Approach...... 88
5.2.3. Support of Macro- and Micro-Mobility...... 91
5.2.4. Support of Macro- and Micro-Reservation...... 94
5.2.5. Overall Architecture of the Home-Proxy Based Solution...... 95
5.2.6. Value Added Services...... 96
5.3. Summary...... 97
CHAPTER 6. Mobility-Aware Network QoS...... 100
6.1. Current Approaches of Advance Reservation...... 101
6.1.1. How to Configure Resources in Advance when Mobile...... 102
6.1.2. Where to Pre-allocate Network Resources for Mobile Devices...... 104
6.1.3. Discussion of Advance Reservation Issues...... 106
6.2. User Mobility Prediction...... 107
6.2.1. Traces of Realistic Movements...... 108
6.2.1.1. Indoor Movement Traces...... 108
6.2.1.2. Outdoor Movement Traces...... 110
6.2.2. Conventional Prediction Algorithms for User Mobility...... 112
6.2.2.1. Performance of Conventional Prediction Algorithms against Realistic Movement Traces...... 115
6.2.2.2. Discrepancy between Commonly Used Mobility Models and Realistic Measurements...... 117 6.2.3. A New Prediction Confidence Parameter for Predicting User Mobility ..119
6.3. Advance Resource Reservation...... 123
6.3.1. Integration of Advance Resource Reservation into the Home-Proxy Based Framework...... 123
6.3.2. Integration of Advance Resource Reservation into the Wireless ATM Framework...... 127
6.4. Summary...... 130
CHAPTER 7. Realisation of QoS and Mobility Support...... 133
7.1. A Prototype Implementation of the Home-Proxy Based Solution with Mobile DiffServ Support...... 134
7.1.1. Simplification in the Implementation...... 135
7.1.2. Components of Prototype Implementation...... 137
7.1.2.1. Mobile Host...... 139
7.1.2.2. Home Register...... 141
7.1.2.3. Home Proxy...... 142
7.1.2.4. Wireless Subnet Router (WSR)...... 143
7.1.2.5. Wireless Internet Gateway...... 144
7.1.2.6. Control Protocols...... 144
7.1.3. Network Characteristics...... 145
7.1.4. Testing Scenarios...... 146
7.1.5. Results...... 148
7.1.5.1. Performance of Mobility Management...... 148
7.1.5.2. Performance of Resource Reservation...... 150
7.1.6. Improvement of Advance Resource Reservation...... 152
7.1.7. Lessons Learnt from theImplementation ...... 153
7.2. A Prototype Implementation of a Wireless ATM Network with Advance Resource Reservation...... 154 xi
7.2.1. Simplifications in the Implementation...... 155
7.2.2. Components of Prototype Implementation...... 157
7.2.2.1. Mobile Host...... 157
7.2.2.2. Mobility-Aware Switch (MAS)...... 159
7.2.23. Corresponding Host...... 160
7.2.2.4. Control Protocols...... 160
7.2.3. Testing Scenarios...... 161
7.2.4. Results...... 162
7.2.5. Improvement of Advance Resource Reservation...... 163
7.2.6. Lessons Learnt from Implementation...... 164
7.3. Summary...... 165
CHAPTER 8. Conclusion and Future Work...... 167
8.1. Overview and Conclusion of the Research...... 167
8.2. Future Research Opportunities...... 172
References...... 175
List of Tables...... 187
List of Figures...... 188
List of Abbreviations 191 xii
Abstract
The evolving design of current fixed and mobile networks suggests that packet switching will become the primary technology to serve mobile multimedia applications.
In order to operate satisfactorily, these applications require two distinct functions from the communication networks, namely mobility management and Quality of Service
(QoS) support.
Asynchronous Transfer Mode (ATM) and Internet Protocols (IP) are the two main packet switching technologies in use today, but neither of them can support mobile multimedia services. Considerable work has been done in recent years to advance these technologies, but many developments consider mobility management and QoS support as unrelated issues. Consequently, their proposed frameworks still cannot serve mobile multimedia applications.
To provide solutions to the above issues, this thesis describes detailed methods of integrating these functions. To reduce complexity, this integration process can be divided into two tasks, namely how to make mobility management more QoS-aware; and how to make QoS support more mobility-aware.
The first task has not been thoroughly explored in IP environments. To counter this, the thesis introduces a novel Home-Proxy based framework that handles mobility management across the Internet at the session layer. Thereby user mobility becomes transparent to the underlying QoS framework. Moreover, this framework offers other advantages such as adaptation services, centralised accounting and access control. To cope with frequent handovers in QoS-aware environments, we introduce a dual-level approach in both mobility management and resource allocation. xiii
The second task is needed in both ATM and IP environments. As a proactive solution, this thesis proposes the use of an advance reservation scheme to ensure continuous QoS support in the presence of user mobility. This scheme is based on insights gained by investigating real-life situations and requires minimal changes to the existing QoS infrastructure.
To prove the viability of our design, we have built two experimental prototype systems based on ATM and IP protocols. By analysing the performance of these prototypes, we have been able to verify that the Home-Proxy based framework can support multimedia applications under the influence of network congestion and frequent handovers. We have also verified that the advance reservation scheme can minimise traffic interruptions caused by user mobility. 1
CHAPTER 1.
Introduction
The concept of mobile telecommunication is familiar to many of us living in the modern society. For instance, we can initiate or receive a voice call via our cellular phone as long as we are moving within the coverage area of our mobile phone carrier.
In addition, if roaming is enabled, we may be able to use it while we are in the coverage area of other carriers in a different city or in a foreign country. With the recent technical advances in portable computer and cellular modem technology, we can even browse the
Web and check our email while we are on the move.
Today's cellular network perhaps gives us an early taste of future mobile multimedia services. However, their functionality and performance are far from satisfactory. Since cellular networks have evolved from the traditional telephone networks, they are primarily for voice traffic and are based on circuit switching technology. We may use cellular modem in our laptop to connect to the Internet, but they are slow (e.g. 9.6 kbit s'1 maximum) and expensive due to the limitations and costs of the underlying technology. Hence, we believe that current cellular systems are not suitable candidates for delivering mobile multimedia services. Introduction 2
Packet switching has been considered as a more cost-effective approach to this
problem, mainly due to its flexible bandwidth allocation and efficient resource
utilisation from link-sharing. Nowadays, the majority of computer networks are running
on packet or cell switched technology using Internet Protocol (IP) or Asynchronous
Transfer Mode (ATM). Driven by the forces of market competition and technological advancement, the cellular telecommunication industry is now evolving its core network to be packet switching, and new architectures based on General Packet Radio Service
(GPRS) or Mobile IP-based solutions have been proposed [SARI00]. In the future, the third-generation wireless (3G wireless) system based on the International Mobile
Telecommunications 2000 (IMT-2000) standard [CHAU99] is expected to offer high bandwidth (up to two megabits per second) for delivering high quality multimedia services to all mobile users.
Although much effort has been devoted to the evolution of today's cellular network, the mobility management of these forthcoming mobile systems is done only on a technology specific basis. As a result, it is difficult for mobile devices to be used seamlessly in more than one wireless access system. Furthermore, the mechanisms of supporting quality of service (QoS) in these cellular mobile systems may not be compatible with those currently being proposed in computer data networks. Recently, the research community has started to investigate another wireless infrastructure known as the forth-generation mobile system (4G mobile) [LU00]. The proposed 4G mobile will be completely packet switched and provide seamless, high bandwidth services (up to 20 Mbit s’1) across a wide range of wireless systems and networks (i.e. from private to public, from indoor to wide area). In these heterogeneous environments, the study of Introduction 3
QoS and mobility support at the network layer (and above) becomes increasingly
important for ensuring a smooth integration of a multitude of access technologies.
Unfortunately, the protocol suites being deployed today (e.g. ATM or IP) do not
align themselves with the above vision. For instance, they do not support user mobility and their QoS support mechanisms (if available) do not cater for mobile wireless environments. In the past few years, these issues have begun to be addressed in the research community and some of the resulting developments are beginning to be standardised. However, these developments in the majority of cases have been done in isolation and as a result are incompatible with each other. In addition to these technical issues, the future infrastructure for charging and accounting mobile multimedia services based on these developments is expected to become increasingly complicated.
Nevertheless, we believe that the above issues can be overcome by dealing with mobility support and QoS management in an integrated fashion. Thus, the goal of this thesis is to investigate the methods of integrating user mobility and QoS support in future networks. Our study is intended to be a generic solution of the above problems, and therefore does not follow a specific mobile system infrastructure. Instead, it concentrates on the basic functionality of a mobile wireless network as viewed from the network and higher layers of the OSI reference model [DAY83].
There are many issues related to the provision of adequate QoS across the wireless link between a mobile host (MH) and its basestation (BS). Specifically, we need appropriate medium access control (MAC) protocols that can support multiple service classes, and co-ordinate the uplink and downlink traffic among mobile devices connecting to the same BS. Another challenge in this area is the problem of how to combat multi-path fading and suppress interference, such that a highly reliable radio Introduction 4
link can be achieved. These issues are normally addressed by the MAC and physical
layers of the OSI reference model. These, despite being important, are orthogonal to the
issues addressed in this thesis, which are associated with the higher layers. Therefore,
they will not be covered extensively in this thesis, and we assume the wireless access points and their controllers, or the entire radio access system to be just a basestation.
With the above assumption on lower layer QoS issues and simplification in wireless access network, we are able to design, build and verify our ideas through prototype implementations.
1.1. Major Findings in This Thesis
The main theme of this thesis is the integration of QoS and mobility support into the networks of the future. In the previous section, we briefly mentioned the inability of existing protocols to support multimedia services in mobile wireless environments. We believe that although this problem is relatively complex, it can be sub-divided into two major tasks:
(1) Making mobility support in the network more QoS-aware.
(2) Making QoS support in the network more mobility-aware.
Our research contributes to the knowledge of supporting mobile multimedia services in the following areas. First, to make mobility support more QoS-aware, it is possible to de-couple mobility management from the underlying QoS architecture, but still maintains an integrated framework for serving mobile multimedia applications. We achieve this by means of a Home-Proxy based solution, which effectively lifts mobility Introduction 5
management from the network-layer to the session-layer. This approach provides
several distinct advantages:
• The traffic generated by a proxy is indistinguishable from other traffic generated by
stationary hosts. Therefore, user mobility support can be gracefully incorporated
into a global communication backbone while its underlying QoS architecture
remains unchanged.
• The Home-Proxy can request network services on behalf of the user while this
person is away in a foreign domain. Such an arrangement can be considered as a
feature of reverse charging for roaming users. In doing so, the user's trust and
accountability requirements can be minimised in the visited domain, thus
eliminating the need for complex authentication and reconciliation.
• Because our mobility management is done at the session layer, it can easily
incorporate many of the proposed regional mobility management schemes, mostly
performing at the network layer, for regional location updates and fast handovers.
• The incorporation of a proxy in our approach allows other value-added services to
be implemented for user mobility, such as vertical handover, content transcoding,
and protocol conversion.
Second, to make QoS support more mobility-aware, it is possible to reserve network resources in advance according to the mobility patterns of mobile users.
However, we have the following important findings:
• To pre-allocate resources in mobile networks, it is necessary to predict the
basestation to which the user will next connect, rather than the physical location to
which the user is entering. Introduction 6
• To practically pre-allocate network resources, a subnet of surrounding basestations
can be included according to user movement history and QoS requirements. The
designation of these basestations can be governed by a probability parameter called
the Prediction Confidence Ratio (PCR).
• To cope with frequent regional user movements, network resource reservations can
be divided into two levels (i.e. inter- and intra-domain), such that the reallocation of
resources within a domain does not affect those across the global backbone network.
This task can be further simplified by assuming abundant fixed network resources at
the regional access network. In this case, only resources at the wireless link and the
global network backbone need to be considered.
1.2. Outline of This Thesis
This thesis uses a bottom-up approach to describe the integration of QoS and mobility support into the wireless communication networks of the future (see Figure 1).
In essence, Chapters 2 to 4 are an up-to-date literature review of current networking technologies, and their associated QoS support and mobility management.
Chapter 5 is a proposal of the Home-Proxy based framework for making device mobility management more QoS-aware. Chapter 6 is a study of the use of mobility patterns in advance resource reservation, such that the resultant network QoS can be more mobility-aware. Chapter 7 is the realisation of above-mentioned concepts using some prototype implementations. Finally, Chapter 8 concludes this thesis and describes future research opportunities. For the remainder of this section, we will give an overview of each chapter in the thesis. Introduction 7
Chapter 2 provides a brief overview of evolving network technologies, and
explains how packet switching became the preferred technology of today’s network.
Two of its major varieties are the ATM and IP protocols. After giving an outline of their
basic capabilities, we compare the design philosophy behind ATM and IP networks.
Finally, we illustrate why these protocols, as they were originally designed, cannot meet
the challenges of providing multimedia services in future mobile networks.
In Chapter 3, we elaborate the first half of the problem in supporting mobile multimedia services, that is, why the ATM and IP protocols cannot support QoS in the future wireless network. ATM has a well-established QoS framework but it is too rigid for applying to wireless environments. Then we introduce the basic architecture of
Wireless ATM and some of its proposals for trying to relax the QoS constraints.
Compared to ATM, IP protocol simply does not provide any QoS guarantees. We present an overview of the Integrated and Differentiated Services, which are the current
„ ;; ' ' * ** 8. Conclusion and Future Work
7. Realisation of Mobility and QoS Support
5. QoS-Aware 6. Mobility-Aware Device Mobility nwuNetwork QoS
3. QoS Support 4. Mobility Support in the Network in the Network
2.5 BackgroundRarknmimri __...... _...... „ 1. Introduction 111
Figure 1. Layout of the thesis Introduction 8
frameworks of supporting QoS in IP networks. Finally, we analyse the potential benefits
and pitfalls of the ATM and IP QoS frameworks when applied to mobile environments.
Chapter 4 expands the second half of the problem of supporting mobile
multimedia services, that is, why the ATM and IP protocols cannot handle user
mobility. The root of this problem comes from the hierarchical addressing of these protocols, and they come up with solutions having different scope and complexity.
Wireless ATM has some sophisticated location management schemes for handling a large number of users. Moreover, its handover management can cater for connection rerouting with QoS consistency. In contrast, Mobile IP has a simpler architecture for mobility management but it is not compatible with the existing IP QoS frameworks.
After reviewing the state-of-the-art frameworks for QoS and mobility management, we find that some of these developments have been made in isolation and become incompatible with each other. It is particularly problematic between Mobile IP and the existing IP QoS frameworks. Chapter 5 mainly deals with the issues raised in
Chapter 4 and we develop a solution based on the Home-Proxy based framework. This framework de-couples IP mobility from the underlying QoS frameworks, and offers centralised accounting that simplifies the cost recovery processes of roaming services.
To improve the performance of serving multimedia applications, this framework employs a dual-level approach in mobility management and resource reservation.
Chapter 6 deals with the issue of mobility-awareness in the QoS frameworks described at the end of Chapter 3. In particular, we attempt to resolve the problems of traffic interruption and resource shortage during and after a handover event, and advance resource reservation scheme based on user mobility patterns is a proactive solution to such problems. To make our study more applicable to real-life situations, we Introduction 9
examine this issue by investigating some realistic movement traces. We propose the use of a probability parameter called the Prediction Confidence Ratio (PCR) to determine the utility of performing advance resource reservation. Finally, we illustrate the ease of implementation by incorporating this scheme into the Home-Proxy based framework and the Wireless ATM architecture.
In Chapter 7, we realise the new concepts described in Chapter 5 and 6 as a proof of viability. The first prototype is an implementation of the Home-Proxy based framework, which consists of a home network at the University of New South Wales, and a foreign administrative domain at CSIRO Telecommunications and Industrial
Physics. This prototype system is mainly used for validating the functions of mobility and resource reservation under a DiffServ environment. In addition, the performance of advance resource reservation is demonstrated. The second prototype is an implementation of the Wireless ATM network, which is mainly used for showing the integration of advance resource reservation and the improvement in handover latency under a connection-oriented networking environment.
Lastly, we conclude the thesis in Chapter 8 by highlighting the main features of our work. In addition, we review our design philosophy and compare it with the current trends in the networking world. Then we describe the opportunities for future research in this area. 10
CHAPTER 2.
Background
This chapter looks at some recent changes in the communication industry and how packet switching has become the preferred technology to support multimedia services for both wired and wireless networks. We then study and compare two major protocols in packet switching, namely the ATM and IP protocol. Finally, we illustrate why these protocols cannot fully satisfy the requirements of mobile multimedia applications.
2.1. The Evolving Network Technologies
Historically telecommunication and data communication networks have been designed to carry different types of user traffic.
2.1.1. Circuit Switching
Traditional telephone networks use circuit switching technology to carry voice traffic. Because a voice call has exclusive use of a specified amount of bandwidth for the call duration, it can provide constant throughput and minimal delay. Although telephone networks are ideal for constant rate traffic like voice, circuit switching is Background 11
unsuitable for bursty data traffic because it cannot deal with dynamic bandwidth
requirements and is inefficient in the use of transmission resources.
2.1.2. Packet Switching
In contrast to the telecommunication networks, today’s data communication
networks employ packet switching technology to carry user data. Due to their statistically multiplexing capability, packet switched networks can cope with bursty data traffic from many different sources, and thereby reduces wasted bandwidth and network resources. There are various approaches to realise packet switching technology, but internally their switching method can be either virtual circuit (VC) or datagram
[TANE96].
The idea behind virtual circuit switching is to avoid having to choose a new route for every packet belonging to a VC. Instead, a signalling protocol is used to decide a path between the source and its destination, such that all packets of this VC can follow the same path without making further routing decisions. In datagram switching, data packets are routed independently because each of them contains the full destination address for routing purposes. Therefore, network routers do not need to maintain state information about every logical connection passing through it.
Today, most public switched data networks are based on virtual circuit switching. Some older ones follow a standard called X.25 [TANE96], which can provide reliable data delivery but are very slow. Some networks employ a more modern technique called Frame Relay [TANE96], which can switch packets end to end much faster but there is no guarantee of data integrity. Although X.25 and frame relay networks satisfy the requirements of the original application (e.g. transferring data Background 12
among computers), they cannot guarantee packet delay and jitters. Consequently, they
are inappropriate for supporting constant rate and multimedia traffic. Foreseeing the
need of multimedia services (i.e. the integrated services of voice, data, video, etc.), the
telecommunication industry began to work on the Asynchronous Transfer Mode (ATM)
standards in the mid 1980s. Like its predecessors, ATM is a virtual circuit switching technology that supports both permanent and switched virtual circuits. But the highlight of ATM networks is their diverse service categories to support constant bit rate, variable bit rate, real-time, and non-real-time traffic. Unfortunately, due to the lack of ATM applications and the complexity of its QoS management, ATM still remains as a link- layer technology for the backbone networks.
Based on datagram switching technology, the Internet' is the largest communication network which has been deployed in the past decade. As the network layer protocol, Internet protocol (IP) provides connectionless services to the upper layer of the OSI model. IP networks are simple and robust, but support neither reliable nor real-time data transfer. Therefore, they do not satisfy the requirements of modern multimedia applications. In recent years, the Internet community has begun to investigate the possibility of providing QoS support in IP, and various QoS frameworks based on Integrated Services (IntServ) and Differentiated Services (DiffServ) have been proposed.
1 For simplicity in this thesis, we assume that the Internet is solely based on IP protocol, regardless the underlying technology being supported by Ethernet, frame relay, ATM, etc. Background 13
2.1.3. Mobile Networking
Besides the rapid growth in Internet penetration, cellular mobile networks have
also enjoyed enormous success in the past decade. The first generation of cellular systems was analogue and based on circuit switching technology (e.g. Advanced Mobile
Phone System and Total Access Communication System). These analogue systems were originally targeted for a relatively select group of users who mostly had the mobile phones installed in their vehicles. However, as hand-held mobile phones have come popular, these systems became harder to accommodate the forecasted demand for mobile services using the analogue approach.
In recent years, the second-generation (2G) cellular technology (e.g. GSM -
Global System for Mobile Communications) has been deployed in many mobile systems world-wide. The 2G cellular systems are also based on circuit switching, but they are mostly digital and can accommodate a larger number of mobile users. Besides voice communication, the 2G wireless technology can handle limited data capabilities such as fax and short message service at low data rate, but it is still unsuitable for web browsing and multimedia applications.
To meet the challenge of providing multimedia services, the 2G cellular systems are now evolving their core network to be packet switching, and new 2G plus architectures such as General Packet Radio Service (GPRS) have been proposed. In essence, GPRS can emulate packet switching on top of GSM circuits and provides variable data rates of up to 384 kbit s'1 if combined with Enhanced Data rate for GSM
Evolution (EDGE) [FURU99], Background 14
The third-generation wireless systems (3G wireless) will use a new network
architecture (i.e. all packet switching) to deliver data services with a maximum rate of
two megabits per second locally and at least 384 kbit s‘! anywhere. The fourth- generation mobile systems (4G mobile) will be the emerging combination of a faster 3G wireless network with other access technologies such as 2G cellular, cordless and
Wireless LAN systems. These access systems should be connected to a common and seamless IP-based core network, but tailoring these technologies to one usable system will be the biggest challenge for 4G mobile.
2.1.4. Circuit or Packet Switching?
From the evolving paths of both fixed and mobile networking technologies, it is reasonable to believe that packet switching would become the primary technology to deliver future multimedia applications. Moreover, we believe that without major breakthrough in transmission, digital switching and wireless access technologies, circuit switching cannot be an economical means of supporting mobile multimedia services.
Unfortunately, none of the packet switching networks deployed so far is ready to transport multimedia applications across a fixed network environment, let alone the introduction of user mobility, which adds another level of complexity into the requirements of these technologies. Therefore, for the remaining of this thesis we will focus on the study of packet switching technology, in particular, on the ATM and IP protocols, in delivering mobile multimedia applications. Background 15
2.2. Asynchronous Transfer Mode
2.2.1. Overview of Asynchronous Transfer Mode
The basic idea behind ATM is to transmit all information in small, fixed length packets called cells. Small cells have the advantage of increasing the granularity of packet scheduling, and hence provide better control over queuing delays. Moreover, as the packet size is fixed, cell switching requires less computational overhead and data can be forwarded at higher speed.
For the management of VCs, two signalling protocols are used in ATM networks, namely User-Network Interface (UNI) and Network-Network Interface
(NNI). These protocols are mainly concerned with the establishment, maintenance and release of VCs. The UNI protocol is used between an ATM endpoint to the ATM network, whereas the NNI protocol is used among network nodes or ATM networks.
The key benefit of ATM networks is their built-in support of QoS. Because
ATM cells within a VC follow the same path, it becomes relatively easy to reserve network resources in advance when the connection is established. However, with VCs it is still a challenge to obtain efficient network utilisation while meeting the user QoS requirements. ATM networks try to achieve this goal via a set of traffic control mechanisms. During a connection setup, connection admission control is used to ensure that sufficient resources are available end-to-end for the required QoS. During user data transfer, traffic shaping and policing are used to alter the traffic characteristics of a VC to meet its QoS agreement. To date, the ATM Forum has defined five different service categories [TANE96]. They can be briefly described as follow: Background 16
• Constant Bit Rate (CBR) - The CBR service is intended for real-time applications
that request a fixed (static) amount of bandwidth. CBR provides reserved bandwidth
up to a Peak Cell Rate specified for the connection with minimal delay and jitter.
• Real-Time Variable Bit Rate (rt-VBR) - The rt-VBR service is designed for
applications which transmit at a rate varying with time but still require a tightly
constrained delay and jitter. Rt-VBR connections are characterised in terms of Peak
Cell Rate, Sustainable Cell Rate and Maximum Burst Size.
• Non-Real-Time Variable Bit Rite (nrt-VBR) - Similar to rt-VBR, the nrt-VBR
service can support bursty traffic but it does not guarantee any delay bounds. This
service is mainly used to obtain the function of statistical multiplexing.
• Available Bit Rate (ABR) - The ABR is designed for highly bursty non-real-time
applications that are able to dynamically modify their data transfer rate according to
congestion feedback from the ATM network. The ABR service provides a minimum
bandwidth guarantee characterised by Minimum Cell Rate, but will also attempt to
transfer data as fast as possible, based on the flow control mechanism. This service
allows the network to operate at high utilisation while keeping the risk of congestion
to a minimum.
• Unspecified Bit Rate (UBR) - The UBR service provides best-effort delivery and
offers no traffic-related service guarantees except in-order delivery of cells. This
service is typically used by non-interactive applications to exploit excess capacity
across the ATM network.
In addition to these service categories, an ATM adaptation layer (AAL) is used at the ATM end points. The purpose of the AAL is to allow other protocols and Background 17
applications to run on top of ATM. There are four major AAL schemes [TANE96]
being standardised by the International Telecommunication Union (ITU) and the ATM
Forum.
• AAL1 supports CBR and circuit emulation.
• AAL2 is designed for VBR services.
• AAL3/4 can be used for multiplexing data sessions into a single VC.
• AAL5 is used for simple data transfer.
Among these protocols, AAL5 is the simplest and the most commonly used in practice for transporting IP datagrams over ATM networks. It is noticeable that none of the AAL protocols provide a reliable end-to-end connectivity for the upper layers, probably this is influenced by the emphasis on highly reliable transport links and real time traffic for multimedia applications.
2.2.2. Discussion of Asynchronous Transfer Mode Issues
Despite the availability of this rich feature set, the trend of the past few years has shown that the deployment of an end-to-end ATM infrastructure will not happen in the near future. This is primarily due to the complexity of its QoS management systems and the substantially lower cost of competing technology such as Fast Ethernet, Switched
Ethernet and Gigabit Ethernet. In addition, there is a lack of applications using native
ATM as their communication protocol. Therefore, today the main usage of ATM is only to set up permanent virtual circuits (PVC) in Internet backbones and serves as a link- layer technology. Background 18
2.3. Internet Protocol
2.3.1. Overview of the Internet Protocol
Internet Protocol (IP) is a connectionless datagram-based protocol at the network layer of the ISO model. This means that IP connections do not need explicit setting up before data transfer, and each packet is routed to its destination solely based on information in its packet header. IP networks do not provide reliable data transfer or keep any per-flow states in their routers for resource reservation. Therefore, today’s
Internet offers only a single service model that makes the best effort to deliver data packets to their destinations. However, despite such primitive service model, IP networks have gained widespread acceptance.
The Internet can provide both stream-oriented and datagram-oriented services to user applications. These services are based on two distinct transport layer protocols:
• Transmission Control Protocol (TCP) - The stream-oriented service is provided by
TCP [STEV94], which is a relatively complex protocol and has additional
functionality such as reliable transport, flow control and congestion control. Because
of these rich features, TCP is the most widely used transport protocol in today’s IP
networks. However, its connection-oriented nature also means that there can be only
two participants in a TCP session and therefore it excludes multicast and broadcast
services. Moreover, due to its usage of retransmissions and timeouts in congestion
control, TCP connections can have large delays when losses occur.
• User Datagram Protocol (UDP) - UDP provides an unreliable, connectionless
service to the invoking application. In fact, the only two services UDP provides are Background 19
the multiplexing/demultiplexing function and some light error checking. However,
sometimes application developers prefer to use UDP instead of TCP because it has
no connection establishment, no connection state, low overhead, and an unregulated
send rate. These features are suitable for short message exchanges, streaming traffic,
and multicast applications. To provide some basic mechanisms needed by
multimedia applications, Real-Time Transport Protocol (RTP) [SCHU96] is a
popular UDP-based protocol to carry streaming traffic across the IP networks.
2.3.2. Discussion of Internet Protocol Issues
The major obstacle of IP to the carriage of multimedia traffic is its lack of QoS support, i.e. it cannot guarantee the delay and jitter of packets arriving at their destination. In the IP header, there is a Type of Service (TOS) field that can potentially be used to express the requirements of reliability and priority of this packet. However, this field is not frequently used in practice in today’s Internet. The Internet Engineering
Task Force (IETF) and the Internet community are actively investigating the support of
QoS, and frameworks such as Integrated Services (IntServ) and Differentiated Services
(DiffServ) are currently being proposed. We will discuss these IP QoS architectures in the next chapter.
2.4. A Brief Comparison of the Design Philosophy behind ATM and IP Protocols
After a brief review of ATM and IP technologies, it would be worthwhile to compare their respective design philosophies. This frequently discussed topic in the networking community, sometimes is described as a debate of “Bell-heads versus Net- Background 20
heads” [STEI96]. In a very coarse view, Bell-heads represent the collective of
telecommunication (Bell Lab) engineers who grew up in the electrical engineering
culture and established the telephone network. Net-heads, on the other hand, are those
network engineers with strong computer science background, and they connected the world’s computers to form the Internet.
While ATM is a packet switching technology designed for voice, video and data traffic, it is quite often being referred to as a Bell-head technology. Perhaps this view comes from the connection-oriented and network-centric nature of ATM, which resemble the traditional characteristics of a telephone network. Given the VC architecture and a strong focus on supporting multimedia traffic with QoS guarantees, the network layer of ATM is significantly more complex than the best-effort IP
Protocol. Hence, Net-heads often criticise ATM as being less reliable because per- connection state information needs to be kept inside the network. In addition, it is argued that the process of setting up and clearing VC imposes significant delay and overhead for applications if they only interest in exchanging short messages. In contrast,
Bell-heads believe that the VC architecture is important in providing service guarantees and traffic engineering because network resources and routing paths can be carefully selected when connections are being set up. As a result of this, we can find a significant amount of intelligence, such as connection admission control, traffic shaping and policing, being put inside the core of ATM networks.
The design of IP was based on a very different perspective. Net-heads prefer to keep the communication network as simple as possible while complex issues such as flow control and congestion control are left to the higher layers (e.g. TCP) at the end system [SALT84]. Based on this philosophy, IP networks are simpler, more robust and Background 21
capable of interconnecting each other with very different transmission rates and loss
characteristics. Despite the concerns of Bell-heads regarding service guarantees and
charging issues, Net-heads believe that the whole notion of QoS via resource reservation is undesirable because a combination of cheap network bandwidth and over engineering will satisfy most of the requirements of multimedia applications. In particular, they disagree with the idea of strict QoS guarantees since the end systems should be intelligent enough to adapt to changing network conditions.
This debate of whether ATM or IP should be adopted as the network-layer architecture of future networks has been going for many years. At the meantime, Net- heads seem to be winning the battle. However, as the popularity of multimedia applications rises rapidly in the Internet and mobile networks, it may be worthwhile to rethink those ideals held by the Net-heads to see if they can meet the actual needs.
2.5. Challenges of Provisioning Multimedia Services in Mobile Wireless Networks
Following the vision of future mobile systems, we can assume that a mobile wireless system* consists of a set of basestations interconnected via a wireless backbone network, and packet switching is the primary means of delivering multimedia services.
So far, the discussion of ATM and IP protocols is only concerned with supporting multimedia services to fixed end systems, but mobile wireless networks pose a more demanding set of challenges than in fixed-wire networks. Even if ATM could become
4 To limit the scope of this thesis, we do not consider mobile ad-hoc networking. Background 22 an end-to-end networking technology, or IP-based networks were able to provide adequate QoS support today, existing ATM and IP protocols still cannot deliver multimedia services in a wireless, mobile environment.
The primary reason is that mobile wireless networking breaks a few assumptions on which the designs of ATM and IP rely on. For instance, the wireless links are prone to errors and the shared medium results in variable bandwidth being available. These conflict with the original design of ATM which runs on low loss optical fibres with plentiful and constant bandwidth. Moreover, the bandwidth of wireless links is not cheap or abundant due to their physical limitations. Therefore, the need for IP QoS support becomes even stronger since over-dimensioning of network resources is no longer a feasible solution. Furthermore, because users are free to move around from one wireless cell to another, this demands additional support of user mobility management which neither ATM or IP provide.
To cater for these new requirements, both the academic research and industrial communities have been working intensively over the past few years designing new approaches and developing standards. We will elaborate on these points further in the remaining chapters of this thesis. In the meantime, the challenges are highlighted below:
• The ATM and IP protocols were originally designed for a fixed network
infrastructure. Therefore, new mechanisms for handling end mobility and wireless
link characteristics need to be developed and integrated.
• The QoS framework considered so far only deal with resource management between
stationary hosts. Consequently, such QoS support will not be usable as soon as the
end host leaves its initial location. Background 23
• Unlike the simple scenario of voice calls in cellular networks, the launching of
mobile multimedia services requires more sophisticated charging and accounting
infrastructure for roaming access and multiple service classes.
2.6. Summary
Network technologies have been going through a rapid evolution to cope with new user demands in both fixed-wire and mobile environments. Because of its statistical multiplexing capability, packet switching provides the best support for future multimedia services.
ATM and IP protocols are the two main packet switching technologies in use today. In their brief reviews, we highlighted the basic principles of these two technologies and the different network service models they currently provide. ATM has a set of sophisticated service categories with stringent QoS support, whereas IP only provides best-effort service with no delivery or QoS guarantee. Although ATM can support QoS guarantees to network users, IP has gained its popularity in today’s computer networks because it can easily interconnect network systems with very different characteristics and reliability, and its application program interface (API) sockets are well-understood by the application developers.
Besides the fixed-wire networks, mobile wireless systems have been evolving rapidly in the past years. As a better alternative to traditional circuit switching approach, packet switching is being considered for the delivery of multimedia services to future mobile users. However, this goal adds another level of complexity into the requirements of ATM and IP protocols. In particular, it is necessary to provide the function of mobility management and a controllable QoS environment in the presence of user Background 24
Mobility
Highly Mobile^-
^ Mobile Multimedia support
Best Strict Guarantee Stationary Effort
Fixed ATM
Wireless
Connectivity
Figure 2. The existing capabilities of ATM and IP networks versus the requirements of supporting mobile multimedia services
movement. In this thesis, we are particularly interested in addressing these issues at the network layer and above. As an illustration of the necessary enhancements to these protocols, we can use a 3-D chart (see Figure 2) to show the existing capabilities of
ATM and IP networks versus the requirements of supporting mobile multimedia services. For the remainder of this thesis we will illustrate how ATM and IP technologies can be evolved to fulfil the needs of mobile multimedia services. 25
CHAPTER 3.
Quality of Service Support in the Network
It has been shown in the previous chapter that ATM and IP protocols were designed using very different philosophies. However, neither of them can be directly used to support mobile multimedia services due to inappropriate service models and the lack of user mobility management. In this chapter, we investigate the first problem, i.e. why ATM and IP technologies cannot provide QoS support in a wireless environment.
Then in Chapter 4 we will discuss the second problem regarding the support of mobility management.
In this chapter, we first mention some fundamental problems associated with
QoS provisioning in native ATM and IP networks. We then study some of the state-of- the-art QoS frameworks in Wireless ATM and the Internet that have been proposed.
Finally, we discuss the readiness and limitation of these frameworks to support mobile
QoS.
3.1. Problem Statement
ATM and IP networks face different challenges in supporting QoS for wireless end systems. ATM networks are well known for their support of QoS guarantees. This service guarantee for VCs is achieved through the combined effects of connection Quality of Service Support in the Network 26
admission control, resource reservation, scheduling, and policing inside the ATM network. In a wireless ATM environment, the basestation (BS), acting as the first or last link in the connection, needs to participate in the QoS negotiation based on the traffic loading of the wireless link. Unfortunately, the inherent features of the wireless link are at odds with this view of ATM, where QoS is assured or guaranteed [CHEN97]. The main issues are as follow:
• The characteristics of a wireless link may undergo dramatic changes due to fading,
multipath reflections and interference. Even with proper link layer protocol and
error correction functionality, these effects can still translate into fluctuations in
available bandwidth and delay. Consequently, the admission control function cannot
make accurate decisions based on unforeseen changes in the operating conditions.
• When a VC is admitted during connection setup, its QoS parameters cannot be
altered during the lifetime of connection. This inflexibility further complicates the
support of QoS guarantees when the wireless link deteriorates to a point that the
original QoS requirements can no longer be sustained.
Unlike ATM QoS, the inclusion of wireless link in IP networks does not impose special requirements on the proposed IP QoS architectures. In fact, today’s Internet makes no assumptions about the characteristics and reliability of network links.
However, such simplistic service model cannot satisfy the increasing demands of user applications, in particular,
• Current IP technology is technically not suitable for serving multimedia
applications, let alone multimedia support in wireless environments. Quality of Service Support in the Network 27
• IP is a connectionless datagram protocol. This makes it harder to determine the
exact routing path of a connection in IP networks. Nevertheless, such knowledge is
helpful in providing resource reservation and traffic engineering.
3.2. ATM QoS Support with Wireless Extensions
3.2.1. Wireless ATM
In the early 1990s, ATM was the only technology capable of supporting a wide range of services with QoS guarantees. As a logical step towards mobile multimedia communication, some researchers began to work on extending ATM technology into the wireless systems. Based on the vision of widely deployed ATM technology in both wide and local area networks, researchers and standardisation bodies started to promote the concept of Wireless ATM (WATM). In essence, Wireless ATM enables mobile wireless computer systems to connect to ATM infrastructure via VC connections, just like their counterparts in the fixed network. The goal of Wireless ATM is to provide
QoS support and seamless end-to-end connectivity to mobile users in a cost-effective and efficient manner.
A typical Wireless ATM network consists of an ATM radio access network and a Mobile ATM core network [ATMF00] (see Figure 3). In essence, such a network contains mobility specific components such as mobile host (MH), basestation (BS) and mobility-enabled ATM switch, which is also known as the End-user Mobility supporting ATM Switch (EMAS). Quality of Service Support in the Network 28
There are many research issues in this new paradigm, including (but not limited to) QoS provisioning, mobility management, and wireless medium access techniques to carry ATM traffic. In the next section, we will focus on the issue of QoS support. Then later in Chapter 4 we will cover the issue of mobility management. Because this thesis only deals with network layer and above, we are not going to cover those problems related to wireless medium access techniques.
ATM Radio Acess Network Mobile ATM Core Network
ATM EMAS EMAS Switch
User Appl User Plane
AAL
ATM ATM
ATM-CL ATM-CL
RAL RAL PHY PHY PHY
Control Plane
M-UNI/ M-UNI/UNI M-PNNI M-UNI M-PNNI UNI PNNI UNI
SAAL SAAL SAAL SAAL
ATM ATM ATM ATM ATM ATM-CL ATM-CL
RAL RAL PHY PHY PHY PHY PHY PHY PHY
SAAL = AAL for signalling protocols ATM-CL = ATM Convergence Layer RAL = Radio Access Layer M-UNI = UNI with supplemental control signaling to support mobility M-PNNI = PNNI with supplemental signaling information to support mobility
Figure 3. Protocol stack of the proposed WATM network Quality of Service Support in the Network 29
3.2.2. QoS Control in Wireless ATM
Due to the time-varying characteristics of wireless links, it is unlikely that
Wireless ATM can support the same deterministic level of QoS guarantees as the wired network. To overcome this issue, some researchers propose to use a less rigid service model to deliver multimedia applications in Wireless ATM [CHEN97, REIN99]. In this adaptive or soft QoS model, user applications specify their QoS parameters in a bounded range instead of a specific value to the admission control function during call setup. If there are not enough resources for accepting the call at its nominal configuration, the admission control mechanism will try to satisfy the call at its minimum service level. If such a reduction is still not sufficient, additional resources can be reallocated from some of the existing connections to this new call, as long as these donor connections can remain above their minimum satisfaction levels. By sharing resources in this manner, it is possible to achieve high bandwidth efficiency and accommodate the maximum number of active connections. In addition, this renegotiation of QoS parameters can be useful in adapting to the variations in bandwidth and delay when the wireless link becomes less stable.
3.2.3. Discussion of Soft QoS Issues
Unfortunately, the present ATM specifications have no mechanism for changing the QoS parameters during the course of a connection. To address this issue, new signalling extensions are proposed in [S098], these permit dynamic bandwidth renegotiation of ongoing connections. This renegotiating process can be initiated either by user applications at the end system, or by admission control functions inside network entities. Quality of Service Support in the Network 30
So far our discussion of soft QoS has only considered a fixed wireless environment. It is worth noting that host mobility can further increase the dynamic range of bandwidth variations because a user may leave one basestation and enter another with very different traffic loads. For supporting QoS in mobile environments, the dynamic bandwidth management system needs to collaborate with the mobility management system to ensure sufficient resources are allocated after the rerouting of virtual connections [S098]. We will discuss these issues further in Chapter 6.
3.3. IP Networks QoS Support
In parallel with the development of the ATM standards, the Internet community also began to investigate the possibility of providing QoS support in IP networks. This work has led to two types of QoS architectures for the Internet, namely Integrated
Services and Differentiated Services.
3.3.1. Integrated Services (IntServ)
The basic philosophy of the IntServ architecture is that network resources (e.g. buffers, link bandwidth) should be reserved in order to meet QoS requirements of individual application sessions [BRAD94], The IntServ model is based on the concept of flow, which is defined as a stream of packets sharing the same source/destination addresses and port numbers. When a session requires QoS supports, it needs to specify and submit its requirements to the network. If the network has sufficient resources, it accepts the request and allocates necessary resources to satisfy the requirements of this flow. Otherwise, the network may either reject the request, or suggest a lower QoS requirement that it can satisfy. This call setup process requires the participation of each Quality of Service Support in the Network 31
router along the data path. In particular, each router has to decide if it has sufficient
local resources to satisfy the request without violating QoS guarantees made to previously admitted data flows.
3.3.1.1. Overview of IntServ
Based on this operational model, the following components are required in an
IntServ capable network:
• QoS Specification Mechanism - The IntServ architecture defines the so-called
Rspec and Tspec for application to specify their requirements to the network
[WROC97a]. The Rspec defines the operating parameters required to reserve
specific QoS services. The Tspec characterises the traffic the sender will be
generating into the network, or the receiver will be receiving from the network.
• Call Admission and Traffic Shaping/Policing - After receiving the Tspec and Rspec
of a session from the receiver, the router has to decide whether to admit the call
depending on its traffic specification, the requested type of service, and the existing
resource commitments to other ongoing traffic flows. Once a session is admitted, the
router needs to continuously monitor, regulate and schedule the traffic such that it
will conform to some negotiated characteristics. For any excessive traffic, the router
should either discard the packets, or mark them as low priority.
• Resource Reservation Protocol - In the IntServ model, a resource reservation
protocol is needed to transfer information about resource requirements and to
negotiate QoS parameters between an application and the network. The signalling
protocol adopted by the IETF is called the Resource Reservation Protocol (RSVP).
RSVP is a receiver-oriented reservation protocol in which the receiver of a flow Quality of Service Support in the Network 32
initiates and maintains the resource reservation used for that flow. The operation of
RSVP is illustrated in Figure 4. The primary use of the PATH message is to inform
the routers the links on which they should forward the reservation (RESV) message.
In addition, the PATH message contains a sender Tspec and an optional Adspec
[WROC97a]. The Tspec specifies the traffic characteristics that the sender will
generate, and the Adspec summarises information about the properties of the data
path before presenting to the receiver. Such summary information may include the
available services, the delay and bandwidth estimates, and the QoS operating
parameters of intermediate routers. After knowing the requirements of the
connection and the capabilities of the network from the PATH message, the receiver
sends out a RESV message. The RESV message contains the Tspec and Rspec of
receiver, which provides the necessary operating parameters for resources to be
reserved in the routers. It is noted that because the router has established a reverse
path forwarding entry for this flow, the RESV message is able to follow the same
route as the PATH message.
To date, the IntServ model defines two major service classes in addition to best- effort service class. They are:
• Guaranteed Service [SHEN97] - The guaranteed service is intended for applications
that request a fixed bandwidth and delay bound. Although this service does not
attempt to minimise the delay jitter, it guarantees that all conforming packets will
arrive within agreed delivery times and will not be discarded due to queue
overflows.
• Controlled-load Service [WROC97b] - The controlled-load service is aimed at
adaptive real-time applications which are sensitive to overloaded network Quality of Service Support in the Network 33
Receiver Tspec + Adspec
Tspec + Rspec Sender
Figure 4. Operation of RSVP signalling in the IntServ architecture
conditions. Thus, this service can provide packet loss rate and delay characteristics
resembling that of a best-effort service under unloaded network conditions.
3.3.I.2. Discussion of IntServ Issues
Although the IntServ model provides fine-gained QoS support, the amount of per-flow state and the overheads of handling refresh messages increase proportionally with the number of flows at each router. Hence, some researchers argue that IntServ does not scale [XIA099].
Currently, RSVP is under revision to become a general-purpose signalling protocol for IP networks. Possible functions are the establishment of aggregated traffic control within DiffServ domains [BERNOO] and label switch-paths inside Multiple
Protocol Label Switching (MPLS) networks [AWDU01]. Quality of Service Support in the Network 34
3.3.2. Differentiated Services (DiffServ)
Because of the scalability issues in IntServ, the DiffServ architecture was
introduced [BLAK98]. There are two significant differences between IntServ and
DiffServ architectures:
• Location of QoS Metric - In IntServ per-flow state information is stored at each
router along data path, but in DiffServ the treatment of packet forwarding is
explicitly indicated at the DS Field of an IP header. This DS Field is a re-definition
of the rarely used TOS type in IP header, and its first six bits are known as the
DiffServ Code Point (DSCP).
• Treatment of Packets - In IntServ data packets receive the same treatment at each
router as they traverse the data path. However, in DiffServ data packets are treated
differently at the edge and core of the network.
A DiffServ network can be considered as a collection of many administrative regions called DiffServ domains. At the edge of a DiffServ domain, there are boundary routers connecting to customers or other DiffServ domains. Depending on the direction of data flow, these routers can be referred to as either ingress or egress routers. There are core routers inside each DiffServ domain. Since these core routers handle aggregated flows with similar DSCP (known as behaviour aggregates) rather than dealing with individual data flows, the DiffServ model trends to be more scalable than IntServ.
3.3.2.I. Overview of DiffServ
The operations of a DiffServ framework can be illustrated in Figure 5. When data packets enter a DiffServ domain, the ingress router needs to classify, mark and regulate these packets. Quality of Service Support in the Network 35
• Flow Classification - The service classification is normally based on the content of
IP header, such as protocol field, source and destination addresses. Provided there is
no fragmentation occurred at the TCP or UDP payload, service classification can
also be done according to multiple fields (MF) at higher layers, such as type of
higher layer protocol, source and destination port numbers.
Receiver
DiffServ Domain 2
BB T Egress router
l Ingress i router
DiffServ Domain 1
Egress router
/
Core router function Ingress aggregate router Queuing classifier
Boundary router function Traffic meter Sender
MF Traffic Marker classifier conditioner
Figure 5. Architecture of DiffServ model with the support of Bandwidth Broker Quality of Service Support in the Network 36
• Flow Marking - Depending on the result of service classification, these packets are
marked with a certain DSCPs. Some values of DSCP are being standardised at the
IETF, while others will remain unspecified and be use for local operations.
• Flow Conditioning - Besides classification and marking, packets within a traffic
stream also needs to be continuously monitored, regulated and scheduled at the
ingress router. This is done to ensure that the traffic stream will conform to some
predefined properties (e.g. rate and burst size) known as the traffic profile.
In contrast to the complex functions provided by the boundary routers, the core routers handle packets only based on their DSCP and a limited set of packet forwarding treatments called Per-Hop Behaviour (PHB). Based on the current specifications, these
PHBs are expected to be simple and observable externally (e.g. in terms of delay and loss).
However, these specifications do not restrict PHBs to be any specific implementation or queuing discipline. Today, there are only a few PHBs being specified by the IETF and they are:
• Expedited Forwarding (EF) [JAC099] - The expedited forwarding PHB is defined
as a forwarding scheme in which the departure rate of packets from any DiffServ
router must equal or exceed a specified value. In particular, this departure rate
should be independent of the intensity of other traffic forwarded by the same node.
Thus, in order to avoid excessive interruptions to other traffic, any non-conforming
EF traffic must be discarded immediately at the router.
• Assured Forwarding (AF) [HEIN99] - The assured forwarding PHB group provides
packet delivery in four independent AF classes. Each class has a minimum
guarantee of bandwidth and buffering. To offer different service levels within an AF
class, packets are further divided into three levels of drop preferences. If congestion Quality of Service Support in the Network 37
/-v i iTMtUm /-»*-» A Lj r»l nnn n *-»r»/^lrotc o/>/^A»*rlir»rv t /~\ tnair rlt*c\r\ uv^Cuid w i mill an rvi ua3^? mv^ I\juiLi ^nuuiu ui^aiu pa\^i\.Cib acv^ui wing, ikj uiv^n kji ujj
preferences.
When behaviour aggregates leave a DiffServ domain, the egress router needs to
monitor, regulate and schedule the traffic so that they can conform to the traffic profile for
the provisioned service. As a precaution when connecting DiffServ domains, the ingress
router of the next domain may need to perform the above traffic conditioning process again
in order to ensure all incoming traffic is compliant with the traffic profile.
3.3.2.2. Discussion of DiffServ Issues
In a DiffServ framework, PHBs could be considered as the building blocks to construct end-to-end service models. For instance, the EF PHB could be used to provide a so-called “virtual wire” or premium service whereas the AF PHBs could offer Olympic-like gold, silver and bronze services with decreasing quality. Nevertheless, it is unclear at this stage whether the concatenation of PHBs would lead to the desired services. To achieve this goal, recent studies have been focused on the concept of a Per-Domain Behaviour (PDB)
[NICH01]. PDB is mainly used to describe the edge-to-edge behaviour experienced by a traffic aggregate as it crosses a DiffServ domain, and new Internet drafts such as Virtual
Wire PDB [JACOOO] and Bulk Handling PDB [CARP01] are being considered in the IETF.
Another challenge of DiffServ is how to perform efficient admission control and dynamically manage network resources within and between the DiffServ domains. These issues are currently being addressed using the concept of a Bandwidth Broker (BB)
[TEIT99]. As shown in Figure 5, BBs can be used to maintain the information of Service
Level Agreements (SLA) between a DiffServ domain and its customers, or between two
DiffServ domains. Based on this SLA information, the BB can configure local routers and make admission control decisions in an automated fashion. While the development of this Quality of Service Support in the Network 38
concept is still s{ cin Ccirl^ stci^c somo ^0^0(irclicrs cxpccl thcit J3J3s witii p cincl
aggregate RSVP [BERNOO] will play an important role in realising dynamic configuration
of SLAs.
3.4. Relationship between Mobility Support and Current QoS Architecture
The QoS architectures of ATM and IP networks are only concerned with fixed computer systems. Inevitably, they will encounter difficulties when used in mobile wireless environments. The earlier work of Wireless ATM explores the use of a soft QoS model, which relaxes the constraint of strict QoS requirements to make ATM more suitable for wireless connectivity. This is a possible way towards supporting QoS in future wireless mobile networks. However, because of the extra complexity in admission control and possible renegotiation of existing connections, the handover latency can be significantly higher. Moreover, this approach requires significant modifications to current application program interface (API), service model, control signallings and traffic engineering of the
ATM networks. Therefore, it is unlikely that a soft QoS ATM service model would be widely accepted.
Unlike the rigid QoS model in ATM, IntServ with RSVP was originally designed using the concept of soft-state, where PATH and RESV messages are sent periodically to refresh the reservation state in routers along the communication path. This approach can be gracefully integrated into a mobile wireless environment because either the sender or receiver can dynamically change the QoS requirements of an on-going connection to compensate the time- and location-varying conditions of wireless link. Nevertheless, it is likely that this extra burden of resource renegotiation messages would add to the scalability concerns of the IntServ architecture. Quality of Service Support in the Network 39
The DiffServ framework leaves many difficult problems unanswered as well. One
of them is the dynamic configuration of SLAs and local routers using BBs. In a highly
changing environment such as mobile networks, requirements of BBs become even more
demanding. The advantage of BBs is that they manage network resources in two levels:
intra- and inter-domain. When a mobile host is moving within a DiffServ domain, the BB only needs to reconfigure resources at local routers to allow a new path between the ingress and egress routers. Provided that the traffic generated by this mobile host goes to the same egress router, the inter-domain SLAs between the local and the next DiffServ domain need not to be changed. We believe that by deploying BBs in this fashion, it is possible to achieve a flexible and scalable solution for supporting QoS in future mobile networks.
3.5. Summary
The original aim of QoS support was to make computer networks have a more deterministic behaviour. The service model of native ATM is highly predictable, but such rigid QoS guarantees may not be appropriate for wireless networks due to the time- varying and shared nature of wireless links. Today’s Internet, on the other hand, lacks the support of QoS and is technically unsuitable to serve multimedia applications.
In recent years both ATM and IP technologies have been evolving to address the above shortcomings, and new architectures based on Wireless ATM, IntServ and
DiffServ have been proposed. These new frameworks have their strengths and weaknesses, but they are not yet ready for providing mobile multimedia services (see
Figure 6).
We highlighted the function of Wireless ATM which serves as an extension of
ATM technology into the wireless world. Because of the wireless link characteristics, a Quality of Service Support in the Network 40
Mobility
Highly Mobile^-
^ Mobile Multimedia support
Best Strict Guarantee Stationary Effort QoS Fixed
Wireless WATM with soft QoS
Connectivity IntServ DiffServ
Figure 6. New capabilities provided by WATM soft QoS, IntServ and DiffServ frameworks
soft QoS model was introduced to deliver Wireless ATM services. This approach, however, will not be widely accepted due to its extensive modifications to the current
ATM standards.
We also introduced the latest developments of IP QoS by presenting the IntServ and DiffServ frameworks. The IntServ model provides individualised QoS guarantees per-flow. However, the problem of this fine-gained approach is that a large amount of state information needs to be kept inside the core network, and this raises concerns about its scalability. The advantage of IntServ using RSVP is that it handles resource Quality of Service Support in the Network 41 reservation using soft-state, which makes QoS renegotiation of ongoing connections relatively simple.
To overcome the scalability problem of supporting QoS per-flow, the DiffServ framework implements classification and traffic conditioning functions only at the network boundary. Aggregates of traffic are then forwarded inside a DiffServ domain according to some standard PDBs and PHBs. Although the feasibility of BB is still under investigation, we believe that the dual-level approach of BB in configuring network resources makes it a scalable solution to support QoS in future mobile networking environment. 42
CHAPTER 4.
Mobility Support in the Network
As discussed in previous chapter the current ATM and IP QoS frameworks do not completely address the changing environment of wireless mobile networks. In this chapter, we elaborate the second half of the problem associated with providing mobile multimedia services, i.e. why ATM and IP technologies cannot offer mobility support in today’s computer networks. We first study the basic problem of providing mobility support in native ATM and IP protocols. We then introduce some recent developments of mobility management in both ATM and IP networks. Finally, we discuss their readiness and limitations under an emerging QoS capable networking environment.
4.1. Problem Statement
ATM and IP networks have similar problems when trying to support user mobility. The main cause of the problem is the double meaning of ATM and IP addresses, which can be interpreted as both the endpoint identifier and the topological location of a computer host. In connection-oriented ATM networks, the ATM Forum has defined a set of protocols for user-network interfaces (UNI) [ATMF96a] and private network-network interface (PNNI) [ATMF96b]. For the purposes of scaling, these protocols assume that ATM addresses are organised hierarchically and the hierarchical Mobility Support in the Network 43
nature of ATM addresses is used to locate the destination host of a connection during
call setup. In the realm of connectionless IP networks, a multi-level hierarchical
addressing scheme [FORD93] is also deployed to make routing simpler and more manageable. Under such conditions, routers only need to maintain routing information of networks at the same level of granularity.
Although the hierarchical addressing scheme can provide a scalable solution for routing data across large internetworks, a hierarchical address is meaningful only when the end host remains connected to the network defined by its address (i.e. its home network). In mobile environments, however, an end user can freely move from one network to another, and therefore this restriction on address usage is violated. When this happens in ATM networks, call setup protocols cannot establish connections to a mobile host (MH) because its current location may no longer be deduced from its endpoint address. Moreover, once a connection has been established between a MH and another end host, current ATM signalling protocols cannot change the forwarding path of this on-going connection, even though the MH has moved to a new location. A naive solution would be to re-establish every on-going ATM connection end-to-end as a MH moves from one BS to another. However, in doing so, the associated delay may be too long for multimedia applications, and the burden of consequent signalling overheads may impact the performance of ATM switches. Therefore, we do not believe this is a feasible solution.
Similar difficulties also appear in IP networking if a MH moves to a new IP subnet while retaining its old address. In this situation, the MH can transmit packets because IP is a connectionless protocol without the need of connection setup procedures. However, this MH will not be able to receive any packets because its IP Mobility Support in the Network 44
ciudrCSS IS jUSt tGpoIogiCaily inCGITcCt for IliCOiiiillg traffic. One pGSSiblc SOiUiiOn iG thiS
issue is to assign a new IP address to this MH when it arrives at a new subnet. This approach, however, can create problems in the transport- and application-layer, where an IP address serves as part of an endpoint identifier. For instance, a TCP connection is recognised by the source/destination addresses and port numbers. If any one of these four components is altered, the on-going TCP connection will be broken. For a UDP data session destined to a MH, it is possible to update its endpoint address whenever the
MH moves. Despite its feasibility, such an arrangement implies that user applications need to be mobility-aware. Unfortunately, it is unlikely that this global awareness of user mobility will become a reality in the near future.
4.2. Mobility Management for Wireless ATM Networks
While on the move, wireless ATM users should be able to access a wide range of information and services like their counterparts in the fixed network. For compatibility and privacy reasons, the corresponding hosts need not be aware of the mobility and current location of a MH. To provide such roaming support, mobility management in Wireless ATM networks can be divided into two loosely related components: location management and handover (or handoff) management.
4.2.1. Location Management for Wireless ATM
The primary goal of location management is to enable the network to discover the locations of mobile users in order to deliver incoming calls. Since location management mainly deals with issues in signalling and database updates, it can be considered as being less protocol dependent and therefore applicable to various types of Mobility Support in the Network 45
networks. In current mobile communication systems, the network adopts a relatively
simple and static approach to location management. Under such a scheme, the network coverage area is partitioned into a number of location areas (LA). Whenever a MH moves from one LA to another, it needs to update its location to the network. Then upon a call arrival for this MH, the network will get its location by paging all the cells within the last registered LA.
In future wireless networks, it is expected that the number of MHs will largely increase. Consequently, the volume of signalling traffic and the cost of maintaining location information are likely to become very high. Therefore, methods for reducing these network activities become necessary. Current research in this area generally falls into three categories: location update, terminal paging, and management of user location information [WONGOO, AKYI99].
4.2.1.1. Location Update
The rationale behind location update algorithms is to find an optimal procedure for a MH to notify its point of attachment to the network, such that its location uncertainty can be reduced but at the same time its signalling overhead can be kept to a minimum. There have been many proposals in this area, ranging from the simple use of event counters to the sophisticated use of pattern matching algorithms. Among them, there are algorithms based on some thresholds [BARN95]. They are:
• Timer-Based Update schemes - In these schemes, the MH periodically updates its
location at certain time intervals. Mobility Support in the Network 46
5 Movement-Based Update schemes - In these schemes, the MH counts the number
of cell boundary crossings and updates its location when this count exceeds certain
threshold.
• Distance-Based Update schemes - In these schemes, the MH requires some
knowledge of the cell topology to track the distance it has moved. Whenever this
distance exceeds certain threshold, location update is triggered at the MH.
Besides these threshold-based update schemes, there are other adaptive and user movement profile based approaches as follow:
• Selective Location Update scheme [SEN99] - In this scheme, the MH skips the
update process at certain LAs in which the user is expected to stay for very short
periods of time.
• Profile-Based Update scheme [POLL97] - This scheme composes a list of LAs for
each user. This list is generated from the user’s mobility patterns and sorted from
the most to least likely place where the MH can be found. There is no location
update required as long as the MH stays within LAs in the list.
• LeZi-Update scheme [BHAT99] - In this scheme, the MH sends out its recent
movement history (rather than its current location) to the network. In doing so, the
user locations are captured and processed in chunks, thereby reducing the actual
update activities. The network then maintains the movement history using a
dictionary-based compression algorithm and issues selective paging derived from
the history of path patterns upon call arrival. Mobility Support in the Network 47
4.2.1.2. Terminal Paging
The goal of terminal paging is to determine the exact location of a particular MH for call delivery. This process involves polling signals being sent as downstream traffic to all cells where the MH is likely to be present. If this MH does not acknowledge within a specific time interval, the network will time out and page some other areas.
Since scarce radio bandwidth is consumed during the paging process, there is a trade-off between the size of paging area and the time spent on locating the MH. Algorithms that have been proposed can be summarised as follow:
• Cluster Paging scheme [MUNO90] - In this scheme, the network pages the MH
starting from its last updated location, then moving outward to all surroundings in a
shortest-distance-first order. This paging scheme is mostly used in conjunction with
threshold-based update schemes.
• Sequential Paging scheme - In this scheme, the network pages the MH by following
a list of locations where the MH is likely to be found. This searching list can be
derived from the probability distribution of previous user locations [POLL97] or
movement paths [BHAT99].
• Velocity Paging scheme [WAN97] - This scheme does not use movement history
but classifies mobile users into different velocity classes, based on their velocity at
the instant of location update. Upon call arrival, the network dynamically generates
a paging area based on the MH’s last registration time, last location, and the velocity
class. Mobility Support in the Network 48
4.2.I.3. Management of User Location Information
Management of user location information refers to the storage and retrieval techniques of user location data in the network. In essence, there are two broad schemes to support this functionality in Wireless ATM networks: the external and integrated approaches.
In the external approach, location databases are used to store and retrieve the current location of the mobile user. This method requires querying operations and signalling protocols for database manipulations. The architecture of location databases can be implemented in the following schemes:
• Two-tier Database scheme [AKY097] - The traditional method of managing
location information is a two-tier database architecture using the concept of Home
Location Register (HLR) and Visitor Location Register (VLR). In this scheme, the
network is divided into different zones (analogous to an LA) and each zone has a
zone manager controlling the HLR, VLR and connection management functions.
Each mobile user is permanently associated with a HLR that keeps track of the VLR
under which the mobile user was located in the most recent update. The VLR, in
turn, stores the location information of ATM switch to which the MH was connected
during the previous update. If a new location update is triggered, the VLR at the
visiting zone and the HLR at the home zone are updated with the MH’s latest
location information. When a call setup procedure is initiated, the zone manger of
the calling party generates a user location query to the home zone of the targeted
MH. The zone manager of the MH’s home zone replies to the former zone manager
the visiting zone recently registered by the MH. After the zone manager of the
calling party retrieves the MH’s location information, it directs the call setup Mobility Support in the Network 49
procedure to the MH’s visiting zone manager. This zone manager then pages the
MH for its exact location before an ATM connection is established between the
calling party and the MH.
• Location Registers (LR) scheme [VEER97] - In this scheme, the hierarchical
addressing information of the PNNI protocol is discarded when setting up
connections to MHs. Instead, a hierarchy of location registers is deployed
throughout the PNNI peer groups for tracking the locations of mobile users within
each peer group. In particular, this LR hierarchy helps in minimising the costs of
location update and terminal paging. If the MH moves within the peer group, the
location update procedure only occurs at the LR of that peer group. If the MH
moves between peer group, the MH sends a location update to the LR of the new
peer group. This LR in term relays the new location information up the hierarchy
until this message encounters the first common ancestor of the former and current
peer groups, or it reaches a pre-set boundary. In the former case, the chain of LRs
would be updated correctly and no further work is necessary. In the later case,
however, the LR at the MH’s home peer group needs to be notified about its latest
location. When a call setup procedure is initiated, the network may need to trace a
chain of LRs for the exact location of MH. If the called and calling parties are in the
same peer group, its LR can recover the location immediately. Otherwise, this
location query is forwarded upward in the hierarchy until it reaches the pre-set
boundary of location update. If the location of MH is still not found, this query
would be handled by the LR at the MH’s home peer group, which relays this query
to the correct peer group serving the MH. Mobility Support in the Network 50
In the integrated approach, existing ATM signalling protocols such as UNI and
PNNI are modified to cater for the location management of mobile users. Therefore, from the perspective of ATM signalling there is no explicit mobile location query procedure required before the connection establishment. We are going to briefly mention a couple of schemes in this area.
• Mobile PNNI scheme [VEER97] - Instead of relying on external location databases,
the Mobile PNNI scheme attempts to set up connections to mobile users solely
according to the reachability information at the ATM switches. However, since the
native PNNI reachability identifies only the parent peer group of the end hosts, this
procedure of status notification needs to be expanded for tracking the exact location
of the mobile user. In PNNI routing protocol, this flooding of reachability
information can be controlled inside a pre-defined region called the neighbourhood.
Within the neighbourhood of the MH, the switches should have the correct
reachability information about this mobile user, and therefore calls initiating from
these switches can reach this MH without additional signalling load. If the MH
moves to a new switch not belonging to the previous neighbourhood, this MH must
register its latest location with its home switch. In the meantime, the ATM switch
connecting the MH begins to propagate its reachability information through its peer
group and then upwards until it reaches the boundary of its new neighbourhood.
Before this update process is complete, the MH must also inform its previous switch
so that its connections can be forwarded. Upon call arrival, connection setup
signalling will be routed toward the home switch of the MH, and subsequently
forwarded to the current neighbourhood of the MH. Mobility Support in the Network 51
• The Integrated Location Resolution scheme [ACHA97a] - This scheme modifies the
signalling operations of ATM call set up protocol to include location resolution of
mobile users, whereas the PNNI protocol is left unchanged. In this scheme, it is
assumed that some of the ATM switches along the communication path are
mobility-enhanced. These obviously include the home switch of a MH, which keeps
track of this MH’s current location. When the MH moves away from its home
switch, it must first register with the visiting switch. The visiting switch then
notifies the MH’s home switch of its new foreign address. For the call delivery
phase of location management, the call setup messages is routed to the home switch
of the MH. This home switch then replies with a call release message to the
originating switch, along with the MH’s home and current foreign address. If there
is a End-user Mobility supporting ATM Switch (EMAS) upstream of the original
call setup path (at least the one at the call originating switch), this switch will
process the call release message and issue a call setup message using the MH’s
current foreign address.
4.2.I.4. Discussion of Location Management Issues
In brief, the proposed schemes suggest that the performance of location update and paging strategies can generally be improved by predicting the future location of users based on their movement history, velocity, etc. [WONGOO]. In the case of management of user location information, it can be argued that due to the signalling overhead and delay of updating PNNI topology, the integrated approach is more suitable for networks with low mobility users, whereas the external approach is better for networks with highly mobile users [BING99]. Mobility Support in the Network 52
Signalling of location management provides location update and retrieval services for the MH and the ATM network. It can be implemented as an overlay signalling system via some pre-configured ATM connections (e.g. in Two-tier Database and Location Registers schemes), or as an extension to the standard ATM signalling protocol (e.g. in Mobile PNNI, and Integrated Location Resolution schemes). The key advantage of overlay signalling is that the inter-switch connection setup process does not need to be modified. The disadvantage, however, is that the ATM address space needs to be divided into two areas, one for mobiles and the other for fixed users, such that the ATM switch of the calling party can know when to issue a location query before setting up a connection. Because of such a division in ATM address space, an end host in this scheme would be statically labelled as mobile or stationary but not interchangeable. The extended signalling protocol makes no distinction if the called party is a mobile or fixed host, which relieves the work of address allocation. This convenience, however, is based on a bold assumption that a single signalling protocol is used for both wireline and wireless users [ACHA97b].
Currently, the standardisation of location management is still in progress at the
Wireless ATM Working Group of the ATM Forum. In their draft document [ATMFOO], it describes a two-tier database model with some overlay signalling protocols running among the MH, the ATM switch, and the location register. This overlay signalling network includes various messages for database operations, such as location query, location update, location response, location cancel, location failure, location update confirm, and location update reject. Mobility Support in the Network 53
4.2.2. Handover Management for Wireless ATM
After a connection has been successfully established from/to a MH, its on-going maintenance is handled by the handover management procedure. Handover is the mechanism that transfers an existing active connection from one network access point to another as the MH goes through the coverage area of an Wireless ATM network.
When a handover takes place, it has to be co-ordinated between the wireless access and the fixed network segments of the Wireless ATM network. In essence, the
ATM connections have to be re-configured to follow the movement of a MH. The simplest scenario is an intra-switch handover, in which both the old and new BSs belong to the same ATM switch. In this case, the ATM switch controls the rerouting of connections from one BS to another, whereas the BSs co-ordinate the handover procedures at the physical and link layers of the wireless segment.
In an inter-switch handover, the old and new BSs connect to different ATM switches, and this requires VC reconfiguration at various switches depending on the network topology and connection rerouting schemes being used.
4.2.2.I. Typical Connection Rerouting Schemes
In the literature, a number of connection rerouting schemes have been proposed in the past few years. They can be summarised into five types (see Figure 7) as described below:
• Full Connection Rerouting scheme [RAJA96] - This scheme requires the setup of a
completely new connection between the MH and its corresponding host (CH) for
each handover. Since the CH is not necessarily mobility-aware, it is assumed that an
external processor (known as the Interworking Device or IWD) is connected to Mobility Support in the Network 54
every ATM switch at the edge of the network to perform mobility functions. In
doing so, the operation of mobility management can be isolated from the
corresponding hosts as well as the core ATM switches, and every handover can
generate an optimal end-to-end path.
• Path Extension scheme - This scheme achieves minimal handover latency by
modifying the existing connection as little as possible. It can be done by
continuously extending the original connection in a hop-by-hop basis as the MH
moves from one BS to another. This path extension can be performed by the BS
[AGRA96] or the ATM switch [LAP096], depending on whether the BS has
switching capabilities or not. Besides its simplicity, the path extension scheme
requires no changes to signalling protocols in the fixed network except for those
BSs or ATM switches connected by the MH. However, after several handovers the
extended portion of the path may form a loop, which results in inefficiencies of
network resource usage. As proposed in [AGRA96], loop removal algorithms can be
used at the BSs or ATM switches to detect and eliminate looped extensions.
• Crossover Point scheme - This scheme attempts to construct an optimal end-to-end
path by partially re-using as much of an existing connection as possible at every
handover occasion. The crossover switch (COS) is defined as an intermediate node
on the original routing path where a part of the existing connection is removed and a
new sub-path is added to reach the latest location of a MH. In order to obtain
optimal rerouting, the Crossover Point scheme assumes that all ATM switches are
mobility-aware, and a COS discovery algorithm is necessary to locate a crossover
point in the network, with criteria such as partial path with minimum-hop, circuit
reuse efficiency and QoS requirements [TOH96a]. Because of the spatial locality of Mobility Support in the Network 55
user movement, it is argued that only a small portion of the existing connection
needs to be re-configured during handover.
• Anchor Point scheme [PORT95] - In this scheme, an anchor switch is assigned to
each MH in the original routing path. This anchor point can be the initial BS serving
the MH (provided it has switching capability) or an intermediate ATM switch
somewhere along the initial routing. During the lifetime of a connection, its portion
connecting the CH and the anchor switch does not change. When the MH moves
from one BS to another, only the portion of the connection between the anchor point
and the MH needs to be rerouted. As a result of this, the subsequent routing path
may be sub-optimal. However, this scheme is relatively simple to implement, and
requires only the anchor switch and the BSs to be mobility-aware.
• Virtual Connection Tree scheme [ACAM94] - This scheme aims at achieving
minimal interruption and continuous QoS guarantees in the presence of network
handovers. When a new mobile connection is admitted, it triggers the establishment
of a virtual connection tree (VCT) which pre-allocates resources across the entire
network region. A VCT is essentially a set of virtual connections joining an ATM
switch (the root) to all BSs in the region (the leaves). Unlike a multicast tree,
however, this VCT can only have one path in use at any given time, and the
activation of a routing path is set by the upstream traffic arriving at the root. Each
MH is assigned a set of virtual connection numbers that decide the routing path of
upstream traffic from the current BS to its VCT root. The advantage of this scheme
is that no ATM connections need to be established, torn-down, or modified as long
as the MH is roaming within the pre-defined region. However, the initial setup time Mobility Support in the Network 56
of a VCT can be considerable and this scheme may not be efficient in terms of
network bandwidth utilisation.
VC before handover VC after handover
(a) Full Connection Rerouting (b) Path Extension Scheme Scheme
Crossover Switch
(c) Crossover Point Scheme
VC Root ” grouping Switch aa
Anchor Switch VCT Region
(d) Anchor Point Scheme (e) Virtual Connection Tree
Figure 7. Typical connection rerouting schemes of Wireless ATM Mobility Support in the Network 57
4.2.2.2. Maintenance of QoS Agreements
As connection rerouting takes place, user traffic is likely to be disrupted because
of delays in handover, and the end-to-end QoS properties may be altered because of
changes in routing path. Ideally, a connection rerouting algorithm should have minimal
impact on the QoS agreements of on-going connections. At the same time, it should also optimise the use of network resources and keep the burden of associated control signals to a minimum, especially those across the wireless link that has scarce radio bandwidth.
In reality, however, these connection rerouting schemes have to balance various factors, such as lossless and in-sequence cell delivery, handover latency, and path optimisation.
The Full Connection Rerouting scheme needs to negotiate the QoS parameters at every handover in order to generate an end-to-end optimal path. In a connection- oriented environment like ATM, such an approach may require a significant amount of control signalling and resource reservation activities, which in turn greatly increase the handover latency.
The Path Extension scheme provides minimal interruption to user traffic and preserves ATM cell sequence when handovers takes place. However, the end-to-end connection path lengths may increase with the number of handovers. Consequently, it affects the over all QoS properties and some other rerouting schemes need to be invoked occasionally for path optimisation.
The Crossover Point scheme can efficiently utilise network resources and closely match the QoS of re-established paths to their original settings. However, in a large backbone network, the COS discovery process can be time-consuming and non- scalable. This is especially true if a MH has many connections to various corresponding hosts, with each connection demanding its COS discovery process during a handover. Mobility Support in the Network 58
Moreover, in order to preserve cell sequence and minimise cell loss, it is necessary to buffer and sort those mis-routed ATM cells at the old and new basestations, which in turn increases the cost and complexity of BS.
The Anchor Point scheme does not require the complexity of dynamic COS discovery, and hence it should introduce a shorter handover latency. Since all connections of a MH share the same anchor point (see Figure 7(d)), it is possible to aggregate them into a single group (e.g. via the virtual path mechanism) for easy switching among different locations [PORT95]. For lossless and in-sequence cell delivery, this scheme also requires additional effort between the old and new BSs for forwarding and buffering procedures for any mis-routed cells.
Finally, the VCT has an ambitious goal of providing consistent QoS guarantees despite user mobility. Unlike other schemes mentioned previously, the VCT explores the concept of resource pre-allocation, which configures ATM connections in advance to avoid excessive handover delay and connection dropout. However, due to its excessive use of network resources, researchers started to look for some alternative solutions. In Chapter 6, we will have further discussions about this type of approaches.
4.2.2.3. Discussion of Handover Management Issues
In the above mentioned connection rerouting schemes, there is a general trade off between handover latency and efficient use of network resources. For instance, the
Path Extension and Virtual Connection Tree schemes can provide minimal handover delay, but the utilisation of network resources may be sub-optimal. On the other hand, the Full Connection Rerouting and Crossover Point schemes achieve the optimal route at the expense of end-to-end connection reestablishment or complexity of discovering of Mobility Support in the Network 59 the crossover node. As a result, some hybrid solutions [TOH96b, AGRA96, CHAN97] have been proposed which use a low delay scheme for intra-domain handovers and an optimal path scheme for inter-domain handovers.
The ATM Forum has been working on a handover signalling framework
[ATMFOO] to accommodate various connection rerouting mechanisms such as Path
Extension, Anchor Point and Crossover Point schemes. In fact, both the Path Extension and Anchor Point schemes can be considered as special scenarios of the Crossover Point scheme. In their draft document [ATMFOO], the related signalling functions are specified as follow:
• M-UNI signalling - This signalling protocol is specified in terms of some user-plane
messages between the MH and the EMAS to support connection handover and
location management. Running on a VC separate from the normal UNI, these
messages indicate handover events such as handover request, handover response,
handover release, connection activate, and connection active.
• M-PNNI signalling - This is a mobility-enhanced version of the PNNI signalling
which supports the initial routing and subsequent handover operations of a MH
connection. However, M-PNNI should not be confused with Mobile-PNNI as
mentioned in Section 4.2.1.3, which is an approach of managing user location
information. The M-PNNI signalling scheme is backwards compatible to the normal
PNNI feature set but includes new control messages in the enhancement, such as
Handover-Related Setup and Partial Release. Mobility Support in the Network 60
M-UNI HCC M-PNNI EMAS1 ATM Network COS GO" M -
EMAS2
HOREQUEST- HO_REQ_QUERY-
HO_REQ_RESPONSE- HO_RESPONSE- HO_COMMAND------HO_RELATED_SETUP- - ► each - -CONNECT-
HO_COMPLETE- HO_RELEASE -PARTIALRELEASE for Switch to new ATM — extension & release old ATM each Disassociate & extension VC associate radio link RELEASE_COMPLETE-
CONNACTIVATE-
CONN_ACTIVE-
Figure 8. The schematics of handover management in Wireless ATM
• Handover Control Channel (HCC) — This control channel is used between EMASs
to exchange handover related information. This information, such as handover
command, handover failure, handover notify, handover request query, and handover
request response, is exchanged as user-plane messages over a specific VC pre
configured between switches.
Figure 8 is a simple illustration about signalling protocols such as M-UNI, M-
PNNI and HCC being exchanged during a successful handover event. It is mainly based on the recommendation of [ATMFOO]. Mobility Support in the Network 61
4.3. Mobility Management for IP Networks
Due to the extensive deployment of IP networks in the past decade, their enhancement of mobile capability becomes more demanding and rewarding. The IP mobility support mechanisms proposed to date can be categorised into schemes that provide either personal or device mobility.
4.3.1. Personal Mobility
Personal mobility is the ability of users to access network services from any terminal in any location. This function enables the network to identify end users when their access location and method of access change. The Session Initiation Protocol (SIP)
[HAND99] provides one possible signalling framework for personal mobility in Internet environments without changes to the standard IP protocol. In recent years, there have been many research projects that have focused on developing architectures for personal mobility. Some of these are briefly discussed below:
• Mobile People Architecture (MPA) [MANI99] - The key function of MPA is to
communicate with a mobile user, independently of this person’s current location or
the communication applications being used (e.g. telephone, email, and ICQ
messages). By introducing a Person Layer on top of the application layer, this
architecture gives emphasis to a person, instead of a device, as the communication
end-point. The heart of this framework is a Personal Proxy, which is responsible for
tracking the user’s location, relaying information based on the user’s preference and
accessibility, and performing protocol or content conversions upon changes of
working environment. Moreover, the use of a Personal Proxy can achieve location
privacy because the user’s residing network and telecommunications infrastructure Mobility Support in the Network 62
are shielded from any incoming calls. But one drawback is that all communication
to this person has to go via the Personal Proxy, which can result in inefficient routes.
• NetChaser [DISTOO] - This is a mobile-agent based infrastructure for supporting
personal mobility in the Internet environment. NetChaser has four mobile agents,
i.e. User Assistance, HTTP Assistance, Mail Assistance and FTP Assistance, which
form a wrapper layer between the applications and the network, and assist users by
following them as their working environment changes. The advantage of this
framework is that it can co-operate with existing applications and make use of the
intrinsic characteristics of mobile agent for information retrieval. The disadvantage,
however, is that this framework only supports a limited set of web-browser based
applications, and it is still unclear at the moment how the burden of agent migration
would affect the performance of this framework.
• ICEBERG [WANGOO] - The main goal of ICEBERG is to develop an Internet-
based solution for integrating telephony and data services across a diversity of
access networks. In doing so, users can access a wide range of network services
from any network access point, and their communication sessions can be handed
over from one device to another. In essence, the ICEBERG framework is composed
of ICEBERG Points of Presence (iPOPs). These iPOPs are built on top of the Ninja
cluster computing platform [NINJ], and each iPOP consists of Call Agents which
perform call setup and control signalling, an Automatic Path Creation service which
sets up data flow between the service endpoints, a Preference Registry for keeping
the users’ call receiving preference, a Personal Activity Co-ordinator for tracking
user location and activity, and a Name Mapping service which resolves user names
among various networks. Although these functions are similar to the other Mobility Support in the Network 63
frameworks mentioned previously, the ICEBERG architecture attempts to do so at
the core network infrastructure rather than at endpoints via proxies or mobile agents.
4.3.2. Device Mobility
Device (or terminal) mobility refers to the ability of the network to provide support for seamless roaming to mobile devices as their users move. To support device mobility, either the IP forwarding mechanism, which is based on IP addresses with implicit location information, needs to be changed or the addressing scheme has to be modified. There are at least three alternatives to achieve this goal.
• IP Encapsulation (Tunnelling) - This process involves the technique of
encapsulating a packet, as data, inside another packet. Because a topologically
correct IP address is embedded inside the header of the new packet, i.e. the tunnel
header, this encapsulated packet can follow the standard IP routing mechanisms and
reach the IP subnet serving a mobile user. This method has been widely studied and
adopted as the data forwarding mechanism in the IETF Mobile IP [PERK96].
• Loose Source Routing - As an option in the packet header, loose source routing
enables the sender to perform address translation operation. The source generates a
list of addresses of the intermediate routers of which it wishes the packet to traverse,
with the last entry being the current address of the MH. As a contrast to the normal
formation of an IP packet, where the destination field is assigned with the address of
the MH, this field is assigned by the source with the first entry of the address list.
When the first intermediate router receives this packet, it fetches the next entry of
the address list and places it in the destination field of the packet. This process is
repeated until the packet reaches to the MH. This function has been carefully Mobility Support in the Network 64
integrated in IP version 6 (IPv6) using a routing extension header which avoids
current problems in IP version 4 with regards to security and performance
[DEER98].
• Dynamic Per-Host Routing - In this routing scheme, the destination IP address is
used as a MH identifier only, removing its association with the current location of
the MH. Packets are forwarded on a hop-by-hop basis from a gateway over special
dynamically established paths to a MH. The forwarding entries at each router along
the path are refreshed periodically using update messages sent from the MH. This
category of packet forwarding has been proposed lately in some micro-mobility
architectures, which we will discuss later in Chapter 5.
The main difference between these three routing schemes is the way location information is placed. In the case of tunnelling, it is embedded within the packet payload; with loose source routing, it is provided in the packet header; and in dynamic host routing, it is maintained in the forwarding table of each intermediate router.
4.3.3. Mobile IP
Mobile IP [PERK96] is the current IETF standard for supporting device mobility in the Internet. In this approach, a fixed host (corresponding host - CH) which wants to communicate with another host is unaware whether the other host is mobile or fixed.
This transparency is provided by using two network agents, one located at the MH’s home network (home agent - HA) and the other located on the visited network (foreign agent - FA). These mobility agents (i.e. HA and FA) and the MH co-operate with each other and perform mobility management without any modifications to the network. The Mobility Support in the Network 65
functionality of Mobile IP can be roughly divided into three components: location registration, packet forwarding and handover detection.
4.3.3.1. Location Registration
Mobile IP adopts a simplistic approach to location management. For example, a terminal paging algorithm does not exist in Mobile IP and location update is executed every time a MH arrives at a new subnet. In addition, Mobile IP does not use databases to store user location information but performs location updates by creating or modifying a mobility binding at the HA. When a MH moves to a foreign network, it registers with the FA on that network and obtains a care of address (COA). The MH then updates its current COA, possibly via the current FA, by sending a registration request message to its HA. After receiving this message, the HA associates the MH’s home address with its current COA via a binding cache. This mobility binding would be automatically deleted from the HA if the lifetime of the binding expires without receiving any new registration from the MH.
4.3.3.2. Packet Forwarding
The packets destined to a MH are always forwarded to this MH’s home network because the CH is not assumed to be mobility-aware. In the case that the MH is currently away, the HA captures the packets, encapsulates them based on its binding cache, and relays them to the FA currently serving the MH. When these packets arrive at the FA, it decapsulates them and forwards them to the MH via any link-layer technology. Mobility Support in the Network 66
Normal forwarding = ------► IP encapsulation =------► Triangle Routing = a, b, c, d Routing with Reversed Tunnell = a, b, c, e, f
Figure 9. Triangle routing and reverse tunnelling in Mobile IP
It is worth noting that packets in the reverse direction can be delivered in two different ways, depending on the level of security in the foreign network (see Figure 9).
If routing is independent of source address within the foreign network, the MH can directly send packets to the CH. This asymmetry of routing between the corresponding and mobile hosts is known as the “triangle routing.” On the other hand, if source filtering routers are installed in this network, they will drop all packets originating from the MH because its source address is topologically incorrect. One possible solution to this problem is to establish a reverse tunnel from the MH to its HA so that all tunnelled packets bear a correct source address [MONT98]. When these packets arrive at the HA, they will be decapsulated and forwarded to the CH.
4.3.3.3. Handover Detection
With the use of tunnelling mechanism, the HA can easily reroute mobile connections to the current location of a MH provided its binding cache is up-to-date.
Mobile IP specifies some generic mechanisms for MHs to discover FAs without any Mobility Support in the Network 67
assistance from the link-layer. In essence, the FA advertises its availability through
router advertisements that are periodically transmitted. Then the MH can detect that it
has moved from one subnet to another in one of the two ways. In the first method, the
MH uses the lifetime field of the FA advertisement to refresh its association with that
FA. If the lifetime expires without receiving another advertisement, the MH will attempt to register with a new agent. In the second method, the MH compares the subnet prefixes of agent advertisements. If the prefixes differ from its current care-of-address, the MH may assume that it has moved.
It is worth noting that since agent advertisements are either broadcast or multicast in nature, to minimise the radio bandwidth usage they cannot be transmitted too often. To date, the maximum frequency of advertisement is only once per second in the existing specification [PERK96], but this limit will be lifted (i.e. unspecified) in the forthcoming revised version [PERK01].
4.4. Relationships between QoS support and Current Mobility Management Techniques
Both Wireless ATM and Mobile IP are concerned with device mobility.
Wireless ATM mobility management should take into account its impact on QoS guarantees, because ATM services are QoS capable. In contrast, Mobile IP is based on the best effort IP protocol and hence it is not intended to be QoS-aware.
4.4.1. Location Management and QoS Support
Current research on location management has been mainly concerned with the trade-off between location update and terminal paging, and the efficiency of storing and Mobility Support in the Network 68 retrieving user location information. These optimisations are necessary in networks serving a large populations of mobile users, as the activities of tracking and maintaining user location information can become a burden of the network resources.
However, location management generally does not have a direct relationship with QoS support. One exception can be the determination of the initial routing path for an incoming call to a MH, which depends on the availability of mobility-aware network nodes (in the case of Wireless ATM) or mobility-aware end hosts (in the case of Mobile
IP). Provided that an optimal path is established between the corresponding and mobile hosts, it is more likely that the QoS requirements of this connection can be satisfied.
4.4.2. Handover Management and QoS Support
Since the early studies of Wireless ATM handover management, its compliance to QoS support functions has been addressed through the requirements of in-sequence and lossless delivery of ATM cells. In addition, several rerouting schemes have been proposed to cater for different constraints in handover latency and QoS consistency of an ATM connection during and after an handover. Therefore, it may be argued that the handover management of Wireless ATM can operate in an environment which demands
QoS guarantees.
Compared with Wireless ATM, Mobile IP has a considerably simpler framework for handover management. Its simplicity is mainly due to the IP protocol being connectionless in nature thus allowing packets to be rerouted from one place to another by just changing the destination address field on the IP header. To shield such changes from the user application, Mobile IP uses tunnelling to redirect packets from the HA to the FA. Although this approach is simple and scalable, Mobile IP was not Mobility Support in the Network 69
initially designed with considerations for QoS. This is evident from its passive approach
to handover detection and the asymmetry of routing between the CH and MH, which
introduce significant handover latency and incompatibilities with the RSVP protocol.
To complicate the issue further, it has been found that tunnelling cannot be applied directly in the DiffServ environment. In recent years, the Internet community has been trying to make IP mobility more QoS-aware, and this will be the main topic in Chapter
5.
4.4.3. Personal Mobility and QoS Support
As described earlier, personal mobility deals with changes when users move from one access device or technology to another. When this happens, new connection path(s) need to be established between the CH (or its proxy) and the mobile user.
Personal mobility involves processes at the session layer and above, that is, from a network point of view, these processes are indistinguishable from those between two fixed hosts. Consequently, personal mobility should not impose any direct conflicts with the underlying QoS framework.
4.5. Summary
Mobility management supports mobile users, allowing them to roam while delivering incoming connections and maintaining connections already in progress. For scalability and manageability, most routing protocols in today’s packet switching networks assume that network addresses are organised hierarchically. When applying this assumption to mobile environments, however, the usefulness of a network address becomes greatly restricted. First, a network address is valid for routing purposes only if Mobility Support in the Network 70
it is used within the vicinity of its home network. Second, even if a new network
address is obtained every time a user moves to a new network, this change of address still remains unknown to any call initiating hosts and on-going connections may also be interrupted.
Both the ATM and IP communities have come up with solutions that have different scope and complexity. In essence, Wireless ATM follows the tradition of telecommunication networks by putting most of the intelligence of mobility management inside the network switches. In contrast, Mobile IP introduces mobility agents at the network edge to handle device mobility while leaving the core network unchanged. Figure 10 is a 3-D chart to show the enhancements of these frameworks towards the support of mobile multimedia services.
Mobility management in Wireless ATM networks consists of location and handover management. There has been a wide range of location management schemes proposed. While a majority of them comes from cellular network schemes (e.g. two-tier database schemes, location update and terminal paging techniques), some other solutions are more ATM specific (e.g. LR scheme, Mobile PNNI scheme and Integrated
Location Resolution scheme). The aim of these sophisticated schemes is to minimise the effect of location management overheads on network resources when serving a large number of mobile users.
Handover management schemes for Wireless ATM have been concerned with rerouting of active virtual connections and maintenance of their QoS as the mobile device moves from one network access point to another. There are various connection rerouting schemes that have been proposed in this area (e.g. Path Extension, Anchor Mobility Support in the Network 71
Mobility
Highly Mobile^- WATM with Soft QoS & Mob. Mgt.
^ Mobile Multimedia support Best Strict Guarantee Mobile IP Stationary Effort ► QoS Fixed
Wireless WATM with soft QoS
Connectivity IntServ DiffServ
Figure 10. New capabilities provided by the WATM mobility management and Mobile IP
Point, Crossover Point and VCT), each design has its strengths and weaknesses in terms of handover latency and QoS support.
Mobile IP provides a simple solution for device mobility. Its location management scheme is generic and based on the concept of a binding cache, therefore no terminal paging or location databases are included. In a connectionless network like the Internet, it is relatively easy to redirect traffic from one place to another. We discussed several methods for packet rerouting in IP network, which include tunnelling, loose source routing, and dynamic host routing. Mobile IP uses tunnelling to forward packets to the current location of MH, which has the advantage of keeping redirected traffic transparent to network routers along the forwarding path. This approach may be Mobility Support in the Network 72 adequate to handle mobility in a network with only best-effort services. However, there are certain challenges when Mobile IP operates in QoS enabled environments.
We also briefly mentioned the concept of personal mobility and reviewed some of the state-of-the-art frameworks. Personal mobility involves the use of middleware, a proxy or a mobile agent to perform content adaptation and protocol conversion as mobile users move from one access device or technology to another. As mobility management is handled at the session layer and above, it should be easily integrated with any QoS frameworks. 73
CHAPTER 5.
QoS-Aware Device Mobility
In Chapter 4, we reviewed the state-of-the-art for network mobility support. It is clear that the handover management part of device mobility has a close relationship with QoS support. As mentioned, the handover management of Wireless ATM was
QoS-aware but Mobile IP was initially designed without the consideration of QoS (see
Figure 10). Therefore, integrating Mobile IP into both IntServ and DiffServ frameworks is a non-trivial task.
In this chapter, we examine the problems specific to IP environment. We further describe the QoS related problems faced by Mobile IP, followed by some of the current efforts in resolving them. We then introduce our novel solution of QoS-aware mobility management and illustrate its advantages when compared to existing approaches.
5.1. Current Pitfalls and Enhancements of Mobile IP
Although Mobile IP is a simple and scalable solution for IP mobility, it suffers from performance and security problems, and has a number of drawbacks especially when serving users with high mobility and QoS expectations. Currently there are many enhancements being proposed to Mobile IP, and these proposals can be summarised in the following sections. QoS-Aware Device Mobility 74
5.1.1. Route Optimisation
Since all packets destined to a MH have to be routed through its HA, the chosen path can be significantly longer than the direct route. In a QoS supported mobile network, a longer path and the ensuing delay will produce a higher probability of call dropping and service refusal.
To rectify this problem, the extension of route optimisation in Mobile IP
[PERKOO] provides a means for corresponding hosts to cache the actual location of a
MH so that their packets can be tunnelled to the mobile host directly. IP version 6 also integrates this idea into its base specification, but replaces the tunnelling mechanism with loose source routing that incurs less delivery overheads [JOHNOl].
Another approach to this problem is to introduce the concept of a location server. As mentioned in Chapter 4, this approach has been used successfully in cellular systems and Wireless ATM [AKYI99]. Through the location server, the MH can update its current location, and the CH can then query the latest location of a mobile user before transmitting a packet. Since the CH knows the actual location of a MH, both triangle routing and tunnelling can be avoided. The associated call setup and signalling protocols can be implemented by either changing the Mobile IP protocol (like MIP-LR
[JAIN98]), setting up user agents at the application-layers (like the SIP with mobility support [WEDL99] and Session Layer Mobility management [LAND99]), or modifying the upper layer protocol (like the MSOCKS [MALT98] and the end-to-end approach to host mobility [SNOEOO]).
It is worth noting that in order to enable optimal routing, all the above proposals have to introduce mobility-awareness in the corresponding hosts. In particular, it QoS-Aware Device Mobility 75
requires either modifications in the IP protocol stack (binding cache followed by
tunnelling or loose source routing), or the addition of location server and associated
signalling protocols. Unfortunately, a global deployment of these enhancements is not available today nor will it be available in the near future.
5.1.2. Frequent Handover and Fast Location Updates
Mobile IP does not mandate fast handover and location updates, and hence there are several problems when serving users with high mobility.
Each time a mobile host moves from one subnet to another, it needs to register its new location with the HA. Thus if the visited network is some distance away from the home network, the signalling delay for these reregistrations can become large and consequently many packets could be mis-routed.
In addition, Mobile IP does not require a MH to inform its previous FA when it moves. Therefore, the former FA is not able to re-route packets to the current FA. The extension of routing optimisation in Mobile IP [PERKOO] allows the mis-routed packets to be tunnelled from the old to the new foreign agents. However, in doing so the mobility agents need to deal with all the associated security issues.
Another disadvantage is that when inter-subnet handovers occur, the MH obtains a new COA and thus packets destined to the MH will be encapsulated with a different tunnel header. Even if we assume that network resources can be dynamically reallocated across a QoS capable Internet backbone during handovers, such rerouting and resource allocation processes may take a long time when the HA and the FA are far apart (see
Figure 11(a)). QoS-Aware Device Mobility 76
Internet Backbone • ' '
Foreign Administrative Normal forwarding =------► *— Domain / IP encapsulation =------► Re-registration Messages =...... ► Data Path before Handover = a, b Propergation of Location Updates = c, d Data Path after Handover = a, e
(a) Signalling and rerouting without the support of Micro-mobility
Internet Backbone
Domain Gateway
Normal forwarding = ------► Foreign e/ IP encapsulation =------► Administrative / f Micro-mobility signalling = ...... ► } Domain Micro-mobility forwarding = —...— gfe- i FA1 Data Path before Handover = a, b, c Propergation of Location Updates = d, e Data Path after Handover = a, b, f
(b) Signalling and rerouting with the support of Micro-mobility
Figure 11. An illustration of the necessity of micro-mobility management in IP networking QoS-Aware Device Mobility 77
Lately there have been many attempts in the Internet community to resolve these problems. The concept of micro-mobility is a promising approach to manage efficiently user mobility within a single administrative domain (see Figure 11(b)). Firstly, location updates within a domain are handled locally, thus avoiding frequent re-registrations across the Internet to the HA. Secondly, by using a specific packet delivery scheme within the region, it prevents the costly re-establishment of end-to-end routing between the HA and the FA. This regional framework is normally co-ordinated by a domain gateway, which serves as the interchange entity for mobility management within a domain (micro-mobility) and mobility management across different domains (macro mobility). So far, only Mobile IP has been considered as the solution for macro-mobility management. For micro-mobility management, however, many types of regional network architecture have been proposed and they can be divided into four categories:
• Cascade Tunnelling - A logical solution to location registration latency resulting
from distance is to perform registrations locally in the visited domain, which can be
achieved through a hierarchy of foreign agents with tunnelling between them as
described in [GUST01]. This approach reduces the number of signalling messages
to the home network and shortens the signalling latency when moving from one
foreign agent to another. However, in order to facilitate this, it is necessary to
introduce new registration messages for local mobility. Furthermore, a special
gateway entity (gateway foreign agent) is required to handle and transform these
regional registrations, and to dynamically manage regional tunnels for the MH in
both the forward and reverse directions. As a result, changes to Mobile IP entities
(e.g. MH and mobility agents) are necessary. These changes ensure that the HA will
always see this gateway foreign agent as the current location of a MH, regardless of QoS-Aware Device Mobility 78
which FA is serving the MH in the visited domain. This cascade tunnelling approach
can also be found in other proposals such as Regional Aware Foreign Agent
[F0099] and Transparent Hierarchical Mobility Agents [MCCA99]. Instead of
modifying those well-defined mobility agents of Mobile IP, these proposals
introduce several new entities in their frameworks for handling the regional tunnel
management.
• Dynamic Per-Host Routing - As an alternative to the regular IP routing, the concept
of dynamic per-host routing can be deployed in a limited geographical area, i.e.
between different subnets within the same management domain. Because of the
limited scope and single ownership of the management domain, it minimises
problems associated with scalability and compatibility. With this scheme, since the
IP address of a MH has no location significance inside the domain, neither
tunnelling nor address conversion is necessary during packet delivery. For example
in HAWAII [RAMJOO], path refresh messages are used to establish and update
some host specific forwarding entries in those routers between a gateway entity
called the Domain Root Router and the basestation. The role of a basestation in
HAWAII is twofold. Firstly, it emulates a FA for replying to Mobile IP registration
messages, thus making HAWAII entities transparent to mobile hosts that use the
Mobile IP protocol. Secondly, it converts Mobile IP registration updates into
HAWAII refresh messages, which in turn either revives refreshes or creates
forwarding entries in the routers depending on whether a subnet handover has taken
place. A similar approach is used in Cellular IP [CAMPOO]. Cellular IP also requires
special routers that can set up, refresh or modify their host specific forwarding
entries by examining control packets. Besides control packets, routers also utilise QoS-Aware Device Mobility 79
user data packets to refresh forwarding entries. To cater for large-scale deployment,
special paging packets and paging caches are integrated in such a way that the
gateway router can efficiently locate any idle mobile hosts.
• Overlay Routing - To overcome the inadequacies of IP routing for mobile users,
regional overlay routing applies an overlay model where IP packets are either
segmented or encapsulated into another packet format for local delivery. Since the
data forwarding mechanism is no longer IP-based, address conversions need to be
done at the gateway entity and the basestations, and all mobility support issues have
to be resolved by the overlay network. One example of this approach is IP over
Mobile ATM [ACHA98], where IP packets are segmented into ATM cells and
delivered by virtual connections between the gateway and the BS across a mobility-
enabled ATM network. When the MH roams from one BS to another, its on-going
virtual connections need to be re-routed to its latest location. Another example of
overlay routing that can be considered as MPLS for Mobile IP [ZHONOO], where IP
packets are encapsulated with a label that directs the forwarding path to a BS. In
fact, this is very similar to the cascade tunnelling scheme mentioned earlier, except
that the regional IP tunnel is now replaced by a Label-Switched-Path across the
MPLS domain.
5.1.3. Tunnelling across QoS Domains
Though tunnelling has been adopted as the standard mechanism for redirecting packets in Mobile IP, it has certain constraints if used in conjunction with the QoS frameworks currently being developed. In applying RSVP to Mobile IP, it is assumed QoS-Aware Device Mobility 80
that RESV messages follow the inverse path of PATH messages. However, this is not the case for the base specification of Mobile IP which results in triangle routing.
Another incompatibility comes from the IP-in-IP encapsulation. The insertion of a tunnel header offsets the packet payload, which prevents the fields in the transport and higher layers from being accessed normally. Let us consider RSVP, the QoS signalling protocol adopted by the IETF. When RSVP signalling messages enter a tunnel, they are encapsulated with a tunnel header that carries an “IP-in-IP Encapsulation” rather than a
“Router-Alert” option. Consequently, RSVP-capable routers cannot recognise the packets, and resources are not reserved accordingly.
Moreover, even if the required resources could be reserved, those intermediate
RSVP routers will not be able to access port numbers correctly in order to distinguish data packets belonging to different flows. Therefore, it will not be possible to honour the per-flow state resource reservations.
To resolve these problems, a RSVP tunnelling algorithm has been proposed in
[TERZOO]. This scheme passes end-to-end RSVP messages transparently (i.e. without reservations) between tunnel end points, but the tunnel ingress and egress nodes would be responsible for generating additional RSVP signalling to reserve resources between them. When data packets arrive at the tunnel ingress node, they are wrapped with extra
IP and UDP headers such that intermediate routers can apply a standard RSVP filterspec to map a packet to the appropriate reservation. Since the source and destination IP address and the destination UDP port number (being assigned as a constant value of
363) are identical for every flow inside the tunnel, a unique source UDP port number is used to differentiate packets from various flows within the tunnel. However, this approach results in further complicating both the signalling and encapsulation at the QoS-Aware Device Mobility 81
tunnel endpoints. Moreover, it considerably increases the overhead of transferring small
packet payloads like voice data.
RSVP is proposed to be used with, and tightly connected to the IntServ architecture, but it is also considered as the signalling protocol to be used with DiffServ
[BERNOO]. In this case, the same shortcomings of QoS and tunnelling will apply to both IntServ and DiffServ environments. In the case of a DiffServ infrastructure without
RSVP signalling, tunnelling poses fewer problems since the DiffServ codepoint (DSCP) can be copied forwards and backwards between the tunnel header and the original IP header when encapsulation and de-capsulation take place. However, in certain networking scenarios when path- or source-dependent services are desirable, multiple- field (MF) classification has to be invoked at the ingress and/or egress DiffServ routers
[BLACOO]. Similarly to RSVP compliant routers without modifications, these DiffServ edge routers will not be able access the higher layer information in the packet payload due to the extra location offset created by the tunnel header, thus MF classification cannot be performed properly.
5.1.4. Link-Layer Assisted Handover Detection
The base specification of Mobile IP was designed to be independent of the underlying link layer technology. However, because of its passive approach to handover detection, the registration process while moving from one FA to another can be very long, especially for real-time communications and reliable data transfers using TCP
[FIK099, FLAD99].
Recently in the IETF, there have been at least two proposals which couple link layer functionality with Mobile IP to minimise service disruption experienced by a MH QoS-Aware Device Mobility 82 when moving between foreign agents. In the Fast Handoffs draft [ELMAOO], the movement of MH is anticipated from the link layer information and simultaneous bindings are used to send multiple copies data packets to potential foreign agents. In the
FA Assisted Handoff draft [CALHOO], the FA takes a proactive approach to manage handover events. When a FA is aware of a handover occurring at the link layer of its current cell, it sets up a MH’s visitor entry and issues the handover messages on behalf of the MFI to the next FA. As a result of this, packets can be forwarded from the current
FA to the next one prior to receiving a formal registration request at the network layer.
Unfortunately, these handover proposals assume that the identity of the new FA is known to the MH. If there are multiple foreign agents appeared at the link layer, these proposals do not provide a solution to choose one that the MH is about to enter.
5.1.5. Discussion of Mobility Management Issues
Future IP mobility frameworks need to consider the QoS constraints of active connections more closely when handling the usual requests of handover and rerouting.
Several optimisations can be done to improve the overall mobility performance.
First, the handover latency could be improved significantly, by tightly coupling the IP layer with the link layer which gives “hints” of potential new arrivals.
Second, it is beneficial to forward packets directly between the corresponding and mobile hosts, as it enables the resultant path to be optimised for quality of service.
However, it is unclear when all corresponding hosts would become mobility-aware to provide this service.
Third, it would be advantageous to assign a gateway entity near the MH to handle micro-mobility. Thus techniques such as Cascade Tunnelling, Dynamic Per-Host QoS-Aware Device Mobility 83
Routing and Overlay Routing can be realised. Nevertheless, it is still debatable as to
which approach is the most appropriate. The most obvious conclusions is that, if
tunnelling is used to redirect packets in the future wireless Internet environment, its
integration into the IntServ and DiffServ framework demands more attention and new solutions.
5.1.6. Charging and Accounting for Mobile Multimedia Services
Besides the technical perspective of integrating QoS support into IP mobility management, mobile multimedia services also create certain challenges to the current techniques of charging and accounting, which mainly cater for fixed-user access and best-effort data services. It is to be expected that the future infrastructure for charging and accounting will be increasingly complicated when it will be required to support of roaming access and multiple service classes. These complications extend to the areas described below.
5.1.6.1. Authentication and Reconciliation of Roaming Services
As mobile users roam among various ISPs (or administrative domains), they can access as many services as desired through the visited ISP. Inevitably, a degree of trust must exist between the visited and the home administrative domains, such that the visited ISP will not charge the home domain excessively for the provided services.
Similarly, the visited ISP needs to be sure that the home domain will honour the payment for resources that the customer consumed. The current approach of establishing this trust relationship is based on initial strong identity verification, credit history checks, and online authentication at the start of a session [GLASOO]. QoS-Aware Device Mobility 84
Furthermore, because of the liability of paying foreign ISPs for its roaming customers, the home ISP needs to process credit limit checks and fraud detection, and to verify conformance to usage policy and service level agreements. To achieve this, accounting records should be transferred within some defined time interval to the home
ISP for reconciliation [ARKK01]. Depending on the number of ISPs within a consortium, these direct business/trust relationships between ISPs can cause a scalability problem. Consequently, a third-party entity or “broker” [GLASOO] has been proposed which acts as a settlement agent, providing a common point of contact for charging and settlement services for various administrative domains.
5.1.6.2. Pricing and Charging for QoS
Currently the predominant form of Internet retail pricing is based on a flat-rate and/or connection-time fee. Users in such charging schemes are forced to share a single service class that is not guaranteed and prone to variable delay. However, this situation should be greatly improved in the future when the Internet can deliver multiple service classes. In the future Internet, charging policies should be service-dependent, such that users of delay- and bandwidth-sensitive applications will have the option to pay a higher price for the better service quality.
Unfortunately, network services with multiple classes cannot be charged using simple pricing schemes such as flat-rate or per-time basis because users are likely to ask for the best service quality at all times. Therefore, many alternative or complementary pricing schemes [BORE99, FANK99] have been proposed for future Internet services.
They can be usage-based (in terms of volume of traffic), capacity-based (in terms of conformance to a service contract), auction-based (in terms of network congestion QoS-Aware Device Mobility 85
levels), or a combination of them. While these schemes have their attractive properties,
their successful implementation relies on the availability of efficient traffic measurement and network monitoring mechanisms. It is still an open issue to develop a solution that is easy to implement by ISPs and simple enough for the average user to understand.
5.2. A Novel Home-Proxy Based Solution
Similarly to Mobile IP [PERK96], our Home-Proxy (HP) based solution
[CHAN01] aims to provide user mobility management in an IP-based mobile environment. Moreover, this framework has been designed from the beginning to inter operate with a QoS capable Internet backbone and to simplify the cost recovery processes of a roaming service.
Figure 12 is a brief comparison of the mobility management techniques used in our HP based framework and Mobile IP. In both schemes, the CH is not required to be mobility-aware or capable of detecting changes in network conditions. This implies that when a connection is made to a MH, all packets destined to this MH are normally forwarded to its home network. Then the HP or HA intercepts these packets and redirects them to the current subnet of the MH.
However, unlike the HA of Mobile IP, our HP uses a split-connection approach to relay information to the MH. This approach requires the HP to accept the incoming connection on behalf of the MH, and then makes a separate connection to the MH. Once these two connections have been established, the HP connects them to form a complete path between the CH and the MH. When the MH moves to another location, it simply obtains a new COA from the new subnet and informs the HP. The HP then tears down QoS-Aware Device Mobility 86
home proxy
home agent
Internet Backbone
Figure 12. A brief comparison of the rerouting techniques being used in the Home-Proxy based and Mobile IP frameworks the old connection and makes a new connection to MH using its latest COA. When this new connection is established, the HP joins it with the incoming connection such that the path between the CH and the MH can be re-established. The details of this approach will be discussed in following sections.
5.2.1. Advantages of Split-Connection Approach
This split-connection approach has two distinct advantages over the method of redirection used in Mobile IP. Firstly, it avoids the use of tunnelling between the MH's home network and its visiting network. As explained in the previous section, numerous incompatibilities arise when passing tunnelled packets across IntServ or DiffServ domains. Our framework eliminates these problems by replacing tunnelling with a new connection when the MH moves from one subnet to another. This implies that the roaming traffic of a MH is now indistinguishable from other traffic generated by QoS-Aware Device Mobility 87
stationary hosts, and thereby mobility management can be gracefully integrated into any
QoS management architecture.
Secondly, the split-connection approach allows the HP to initiate Internet services on behalf of the MH while it is away at a foreign ISP. That is, instead of directly requesting a service connection at the foreign network, the MH can send out its service requests via a control connection to its HP. The HP then makes two separate connections: one from the HP to the CH, and the other from the HP to the MH. Similar to the service establishment initiated by the CH, once the two connections have been established, the HP merges them to form a complete path between the CH and the MH.
By initiating service connections via the HP, the visited ISP and all intermediate service providers would see the roaming traffic of a MH as if it were originated from a fixed host in the home network. This arrangement has several advantages:
• The visited ISP is not directly dealing with a random roaming user, but only
provides a local IP address and a control connection to each user for service
requests. Therefore, the requirement to establish the user's trustworthiness and
accountability has been removed from the visited ISP, and the complex
authentication and reconciliation requirements mentioned in Section 5.1.6.1 may not
be necessary.
• Although the subscribers are at a foreign ISP, the home network administrators can
easily verify their conformance to usage policy and service level agreements by
monitoring and controlling the HP.
• A fair charging policy can be achieved for roaming services. Just like many
charging schemes in today's telephone networks, the future Internet can charge the QoS-Aware Device Mobility 88
initiating party for the cost of a connection. With such a policy, when a MH in a
foreign domain requests for a connection, the home administrative domain would
pay for the connections to the visited ISP and to the CH. In the case where the CH is
initiating a connection to the MH, the CH would only pay for the connection to the
MH's home network and the home administrative domain would pay for the cost of
redirection from the HP to the visited ISP.
5.2.2. Realisation of Split-Connection Approach
The Home-Proxy based framework is a novel concept for facilitating the integration of mobility support with QoS management mechanisms, and at the same time simplifying the cost recovery processes of roaming services. Nevertheless, the use of proxy or middleware is not a totally new idea in supporting user mobility. For instance, MSOCKS [MALT98] handles mobility management at the transport layer and introduces a proxy in-between the client and server. SLM [LAND99] operates above
TCP and switches TCP streams between the MH and CH. Moreover, SIP mobility support [WEDL99] extends the application layer protocol SIP to switch UDP traffic between the MH and CH. We believe that all the above schemes can be applied, with some modifications to support mobility management between the MH and HP.
However, the IP stack has to be modified in MSOCKS, and mobility support in SIP is relatively slow and has not yet been consolidated. Therefore, we have chosen to expand the SLM approach.
Figure 13 illustrates the basic function of SLM in setting up data sessions. If a data connection is initiated by the MH (Figure 13(a)), a reflector module intercepts and redirects the connection to the SLM module at the MH. The SLM module then QoS-Aware Device Mobility 89
(1) = connect() sys call Home (3) = conn, request Register (4) = conn, command App (2, 5, 6) = socket conn. Client
Server Reflector
(a) Connection initiated by the MH
(1) =.bind() sys call Home (2) = bind request * Register (3) = bind command (4, 5, 6) = socket conn. Server App Client Reflector
(b) Connection initiated by the CH
Figure 13. Basic operations of SLM to establish a connection examines the connection and sends out a control message indicating the session characteristics and destination address to the MH's home register (HR). After verifying the connection request, the HR authorises the SLM module at the HP to make two separate connections that have the requested characteristics: one from the HP to the CH, and the other from the HP via the SLM module to the SLM module of the MH.
Similar procedures are invoked when the MH binds a socket to listen for an incoming connection (Figure 13(b)). The reflector module indicates this socket binding process to the SLM module of the MH, which in turn informs the HR about its readiness to accept the incoming connection. After verifying the binding request, the HR instructs the SLM module at the HP to wait for incoming connections. When the CH initiates a data connection, the HP uses proxy-ARP or similar techniques to accept this connection on behalf of the MH. Then the HP consults the HR about the preferences and policies of QoS-Aware Device Mobility 90
this MH, and makes a separate connection, via its own SLM module, to the SLM
module at the MH. Similar to its peer at the HP, the SLM module at the MH accepts the
incoming connection for the MH, and makes a separate connection to the waiting application.
Like any mobility management framework, this split-connection approach requires proper location management support through which the MH can update its latest location and the connection destined for the MH can be redirected to its current location. However, before this, the MH must obtain a COA from the visited subnet.
This COA can be the IP address of a mobility agent (like Mobile IP) or a unique IP address assigned by a DHCP server. Since our framework does not require tunnelling or a mobility agent at the visited subnet, the second approach is more appropriate.
Figure 14(a) is a simple illustration of the function of the HR to direct a connection to the MH. After obtaining a COA from the DHCP server, the SLM module at the MH is responsible for updating its latest location at the HR. When a connection destined for the MH arrives, the SLM at the HP needs to obtain the authorisation and current COA of the MH from the HR and then establish a new connection to it.
After the establishment phase, the SLM module treats data connections identically regardless of whether the MH or CH establishes the connection. When the
MH moves to another subnet (Figure 14(b)), it obtains a new COA and informs the HR.
Then its HR instructs the HP to tear down and re-establish the inter-SLM connection between the HP and MH. Since the connection state is retained by SLM modules and the original connections are shielded from the details of the network, the movement of the MH is transparent to the applications at both the MH and CH. QoS-Aware Device Mobility 91
(1) = get DHCP addr (2) = location update (4) - COA request DHCP Home (5) = COA response Server Register (3, 6, 7) = socket conn.
App App Server Client
MH HP CH (a) HR instructs HP to relay an in-com ing connection
(1) = get DHCP addr (2) = location update DHCP (3) = COA update Server Home (4) = setup new conn. * Register (5) = delete old conn.
Server App Client
(b) HR instructs HP to re-establish an inter-SLM connection
Figure 14. Basic functions of HR and HP to deliver and redirect a connection
5.2.3. Support of Macro- and Micro-Mobility
In this framework, inter-SLM connections are torn-down and re-established as the MH moves from one subnet to another. Just as in Mobile IP, this approach does not allow frequent handovers and fast location updates, especially when the visited domain is some distance away from the home network. For the provision of mobile multimedia services, the micro-mobility management technique could be used to supplement our split-connection approach that handles macro-mobility. However, unlike the integration of micro-mobility and Mobile IP mentioned in Section 5.1.2, our management of macro- and micro-mobility is simpler because the split-connection approach operates at a higher layer. QoS-Aware Device Mobility 92
We assume that each regional administrative domain is equipped with one or more Wireless Internet Gateways (WIG) which serve as the interchange between conventional IP routing and micro-mobility routing. Therefore, it is important that all
DHCP addresses given to MHs should direct their incoming traffic to pass through the
WIG to which they are allocated. In principle, any kind of the regional network architecture can be used to realise micro-mobility management. However, we have chosen a dynamic per-host routing scheme similar to HAWAII [RAMJOO] or Cellular IP
[CAMPOO] because of its advantages in routing data packets to a MH without tunnelling or address conversion. In this approach, packets are forwarded on a hop-by-hop basis from the WIG over a dynamically established path to the MH, whose IP address is unchanged as long as it stays at the visited domain. Since the IP address has no location significance within the access network, the user's mobility would become transparent to the QoS enabled Internet backbone.
The per-host routing technique in our framework is used in the following manner. To dynamically maintain a routing path from the WIG to its current location, the MH needs to send out control messages such as “path update” and “path delete” to update the forwarding entries at each router along the path. Figure 15 illustrates the basic scenario for rerouting as the MH moves from one subnet router to another within the domain (i.e. from R2 to R3 in the diagram).
Originally data packets were forwarded via HP, WIG, Rl, R2 to MH. As the
MH arrives at a new subnet, it sends out a path update message to R3. After receiving this message, R3 needs to modify its routing table accordingly for the downstream traffic to the MH and propagate this control message to an upstream router (Rl) based on its default gateway setting. Then a similar path-update process is repeated at each QoS-Aware Device Mobility 93
(1) = unchanged macro-mobility path (2) = unchanged micro-mobility path (3, 4) = path update message (5) = path delete message
HP
► SLM MH Internet Backbone
micro-mobility macro-mobility (dynamic per-host routing) (normal routing)
Figure 15. Macro- and micro-mobility management in the Home-Proxy based framework
router between the MH and the WIG until the control message encounters the WIG or a router keeping a forwarding entry for the old path (it happens to be R1 in Figure 15).
Then the WIG or this crossover router would send out a path-delete message to the downstream routers along the old path to eliminate any out-of-date forwarding entries.
At this time, when packets destined for the MH arrive at the WIG, they are routed to the
MH using the per-host forwarding entries newly established. To efficiently manage these dynamic routing paths, the per-host routing entry at each router should be refreshed periodically.
Based on the per-host routing technique, our micro-mobility management system has two specific requirements during its deployment. First, all routers within the access network have to be mobility-aware. This can be achievable because these routers are no different to normal IP routers except being able to process and propagate path update and path delete messages. Second, the IP address of each visiting MH should be unique and remains unchanged throughout its stay at the access network. To achieve this, one possible solution is to deploy a centralised DHCP server per domain with QoS-Aware Device Mobility 94
DHCP relay agent [DROM97] at each subnet. The use of DHCP relay agents eliminates the need to have multiple DHCP servers in a domain and thereby simplifies the process of discovering addresses that are already in use among different subnets.
5.2.4. Support of Macro- and Micro-Reservation
In order to reduce the complexity of resource allocation for MHs, it is assumed that resource bottleneck is likely to be at the Internet backbone or at the wireless link.
This implies that the network paths joining basestations and the WIG should be either well engineered or over provisioned. We believe that this is likely because the network between the BS and WIG will be normally owned by the same administrative authority and will have access to relatively large and inexpensive bandwidth. Based on this assumption, we can divide resource allocation into two levels: macro-reservation and micro-reservation, similar to the mobility management scheme we proposed earlier.
This can be schematically shown in Figure 16.
BS1
HP
SLM
(1) = macro-reservation (2) = micro-reservation before handover (3) = micro-reservation after handover
micro-reservation no-reservation macro-reservation (wireless link) (access network) (Internet backbone)
Figure 16. Macro- and micro-reservation in the Home-Proxy based framework QoS-Aware Device Mobility 95
The WIG plays an important role in the proposed allocation scheme for mobile
users. At the macro-level, it behaves as the first or last hop node of the underlying QoS framework to complete the QoS path across the Internet backbone. For the ease of illustration, we assume this QoS framework to be DiffServ capable. At the macro-level, it is also assumed that network resources can be allocated across the Internet backbone using bandwidth brokers, and the WIG acts as either the ingress or the egress router to complete the QoS path across the Internet backbone.
At the micro-level, the WIG only needs to allocate wireless resources at the BS where the MH is located. When the MH moves to another BS, the WIG simply obtains another micro-reservation at the new location, where as the macro-reservation remains unchanged across the Internet backbone.
5.2.5. Overall Architecture of the Home-Proxy Based Solution
Figure 17 shows the overall architecture of the proposed Home-Proxy based solution. In this solution, the role of the HP is three-fold. Firstly, it shields the movement of the MH from the CH. Secondly, it allows graceful integration of macro mobility and macro-reservation across the Internet backbone. Thirdly, it can initiate
Internet services on behalf of the MH, which greatly simplifies the cost recovery processes of roaming services in foreign administrative domains.
The WIG is another key entity in this architecture. Firstly, it shields the regional movement of the MH from the HP. Secondly, it controls the micro-reservation within the domain. Although we make certain assumptions about the regional access networks
(e.g. mobility-aware, rich in capacity), the overall framework imposes no strict requirement of their presence. The use of micro-mobility and micro-reservation is aimed QoS-Aware Device Mobility 96
micro-mobility + Admin. Domain 2 no reservation
Subnet 3 Subnet 2 WIG 2
\» ( R2
Home Network ^ Internet Backbone , ' macro-mobility + \nacro-reservation
micro-reservation [SLM] MH WIG 1
normal IP traffic
Admin. Domain 1
Subnet 1 SLM = Session Layer Mobility Management WIG = Wireless Internet Gateway HP = Home Proxy HR = Home Register
Figure 17. An overall architecture of the Home-Proxy based framework
at improving the performance of mobility and QoS supports without special
modifications in the Internet backbone.
5.2.6. Value Added Services
In mobile environments, proxy-based systems are commonly used to carry out session customisation (i.e. protocol conversion and/or content adaptation) to react to the various characteristics of access networks and to ensure continuity of network services for mobile users. In our framework, the HP offers a convenient insertion point for session customisation.
In addition, as our macro-mobility management is handled at the session layer, this framework is ready to support both device mobility (e.g. subnet handover) and QoS-Aware Device Mobility 97
personal mobility (e.g. handover between different terminals or different kinds of network).
5.3. Summary
Although Wireless ATM is QoS-aware, Mobile IP was not initially designed for the provision of QoS. In recent years, many enhancements have been proposed to make it more capable of providing QoS. We have classified these research efforts into various areas: route optimisation, fast handover and location updates, tunnelling across QoS domains, and link-layer assisted handover detection. Besides these technical challenges of integrating QoS support into Mobile IP, the future infrastructure for charging and accounting will be increasingly complicated because of its support of roaming access and multiple service classes.
Unlike Mobile IP, our proposed Home-Proxy based solution has been designed from the beginning to inter-operate with QoS capable environments. Thereby, its mobility management is more QoS-aware and can achieve functionality simliar to that provided by Wireless ATM (see Figure 18). To improve the performance of serving mobile multimedia services, our framework introduces two levels in mobility management and resource allocation.
At the macro-mobility level, we have de-coupled mobility management from the underlying QoS framework by means of a Home-Proxy entity. Compared with the base specification of Mobile IP, our approach has several advantages:
• The home network can initiate Internet services on behalf of the MH while it is
away at a foreign ISP. Therefore, the need to verify the user's trust and QoS-Aware Device Mobility 98
Mobility
Highly Mobile^- Home-Proxy Framework WATM with Soft QoS & / y Mob. Mgt,'
s Mobile Multimedia support Best Strict Guarantee IP - Stationary EffortMobile (I\► QoS Fixed
Wireless WATM with soft QoS
Connectivity IntServ DiffServ
Figure 18. The capabilities of Home-Proxy based solution compared with other existing mobility and QoS frameworks
accountability has been removed from the visited ISP, and complex authentication
and reconciliation processes as mentioned in Section 5.1.6.1 may not be necessary.
• The tunnelling mechanism in Mobile IP is replaced by inter-SLM connections when
the MH moves from one domain to another. This implies that the roaming traffic of
a MH is now indistinguishable from other traffic generated by fixed hosts, and
thereby mobility management can be fully de-coupled from any QoS management
architecture at the Internet backbone. QoS-Aware Device Mobility 99
• Since the macro-mobility management is handled via proxy, our framework can
support valued added services such as personal mobility and session customisation,
which are not available from a network-layer mobility solution like Mobile IP.
The micro-mobility management technique has been introduced to improve the performance of frequent handovers within an administrative domain. We have chosen a dynamic per-host routing scheme because of its advantages in routing data packets to a
MH without tunnelling or address conversion.
Based on a realistic assumption about the capacity of regional access networks, we divide the function of resource allocation to be either macro-reservation (i.e. across the Internet backbone) or micro-reservation (i.e. across the wireless link). As mobile users frequently move from one BS to another, their micro-reservation needs to be altered accordingly. Nevertheless, such changes are shielded from the macro reservation, which is considerable more costly and time-consuming to re-establish across the Internet backbone. 100
CHAPTER 6.
Mobility-Aware Network QoS
In Chapter 3, we reviewed some QoS frameworks being developed for both
ATM and IP technologies. Although they can provide deterministic QoS guarantees to the users in a wireline network, it is generally difficult to promise a specified level of
QoS to a mobile user since there may not be enough resources in the part of the network into which the mobile user is moving. Moreover, the on-going traffic is likely to be disrupted during handovers, which can violate some of the previously agreed QoS parameters such as packet delay, jitter and loss.
To date, there are essentially two methods to make QoS support more mobility- aware. The first method focuses on the pre-allocation of network resources in locations where the MH is likely to visit. Pre-allocation can improve the continuity of a connection after move, and reduce packet losses and latency of resource allocation.
However, pre-allocation requests can fail under severe network congestion because there are simply no resources available for reservation. Moreover, even after pre allocation, signal fluctuations of the wireless link can contribute to the failure of QoS guarantees. Under such conditions, it becomes necessary to employ an alternative approach. Mobility-Aware Network QoS 101
The second approach emphasises on the adaptivity of end systems, where their application, middleware or proxy reacts to the changes of network resources caused by wireless channel fading and user mobility. This functionality can be achieved by means of session customisation at various places. In Wireless ATM networks, a soft QoS model is proposed to assist end systems to adapt, but this may deteriorate the handover performance as explained in Section 3.4. In the Internet environment, adaptive end systems have to rely on mechanisms that probe the network in order to avoid congestion. Unfortunately, this action is likely to cause traffic interruptions before congestion can be avoided on a long-term basis.
From the above discussion, we believe that the first method (i.e. advance reservation) is a proactive approach to deliver some level of QoS guarantees (at least statistically) to the mobile users, whereas the second method (i.e. end system adaptivity) is a reactive approach to cope with changes of QoS. Therefore, they are complementary.
In this study, we mainly focus on the proactive approach as advance reservation is more network-centric and follows our primary interest of integrating QoS and mobility support into wireless communication networks. In this chapter, we first review some of the state-of-the-art techniques in pre-allocating network resources. We then validate our proposed scheme, using some real movement traces obtained from live networks, and illustrate two possible integration scenarios with the Home-Proxy based framework and Wireless ATM.
6.1. Current Approaches of Advance Reservation
Advance reservation needs to deal with two non-trivial problems, namely how to configure resources in advance, and where to pre-allocate resources for mobile devices. Mobility-Aware Network QoS 102
6.1.1. How to Configure Resources in Advance when Mobile
Advance reservation was originally considered in Wireless ATM research
[LIU96, LEVI97, OLIV98, LIU98]. Because of the recent interest in providing mobile
QoS in an IP environment, the research community has addressed this issue using a combination of Mobile IP and IntServ models. Based on the topology used for reserved data paths, these proposals can be classified into three categories as shown in Figure 19.
• Pre-Configured Anchor Rerouting - MRSVP protocol [TALU99] is an example of
pre-configured anchor routing. In MRSVP, a MH specifies and dynamically
maintains a set of locations, from which it wishes to make advance reservations to
its HA (i.e. the anchor point). This set of location is known as the MSPEC. Special
routing entities, called RSVP proxy agents, are provided at the locations specified in
the MSPEC to make reservations on behalf of the mobile host. To allow for better
link utilisation, reservations made by these proxy agents are classified as either
active or passive, depending on whether the reserved resources are used for the data
flow or can be temporarily borrowed by other lower priority services. Of all proxy
agents associated with a MSPEC, only the one currently serving the mobile host is
allowed to make active reservations. The others will remain as passive reservations
until the mobile host moves into their wireless region. Similar mechanisms can also
be found in other proposals such as RSVP-A [PAJA99] and Mobile Extensions to
RSVP [AWDU97]. Mobility-Aware Network QoS 103
CH
(a) Pre-Configured Anchor Rerouting
(b) Pre-Configured Path Extensions
(c) Pre-Configured Tunnelling Tree
Figure 19. Various schemes of resource pre-allocation Mobility-Aware Network QoS 104
• Pre-Configured Path Extensions - An example of pre-configured path extensions is
Advanced Reservation Signalling [MAHA00]. This scheme also uses a concept
similar to passive reservation. However, instead of making multiple reservation
paths connecting the HA with other foreign agents, the advance reservation
signalling simply extends the existing RSVP data path from the current position of a
MH to all its adjacent basestations. Depending on whether the adjacent BS shares
the same FA as the current BS, passive reservations can be initiated from either the
current BS or the current FA to the adjacent location. As soon as the MH moves to
one of its neighbours, one of these pre-configured path extensions becomes
activated and all other extensions can be deleted afterwards.
• Pre-Configured Tunnelling Tree - The proposal in [TERZ99] is an example of pre-
configured tunnelling tree schemes. It does not rely on the notion of passive
reservations. Instead, it requires RSVP-capable tunnels [TERZ00] to be established
between the HA and other foreign agents. Unlike ordinary IP encapsulations, these
RSVP tunnels are pre-provisioned with certain levels of resources while
accommodating multiple end-to-end RSVP sessions. When the resources consumed
by mobile hosts visiting a FA exceeds the reserved amount, the FA can request an
incremental block of resources to be added to the RSVP tunnel.
6.1.2. Where to Pre-allocate Network Resources for Mobile Devices
It is difficult to determine where to pre-allocate resources, because of the difficulties of predicting user movements. Despite this, many resource pre-allocation algorithms have been proposed in the literature as an attempt to safeguard the QoS Mobility-Aware Network QoS 105
agreements for mobile services. These algorithms can be classified into three main categories.
• Neighbourhood-Based Allocation - These scheme pre-allocates network resources
between an anchor node and a set of basestations surrounding the MH. The number
of basestations involved in the pre-allocation process depends on how far ahead in
time the network is willing to support a mobile service. For example, Virtual
Connection Tree [ACAM94] configures resources in advance between a root switch
and each BS in the management domain upon the admission of a call. This implies
that the network is willing to support this mobile host as long as it stays within the
domain, but the network may also have low utilisation of resources. Advanced
Reservation Signalling [MAHAOO], in contrast, reserves resources only between the
current location and all adjacent cells. Thus the network guarantees continuity of
services after the next handover, but its further commitments are subject to
successful reservations at the new neighbouring cells.
• History-Based Allocation - Through modelling and simulation, many proposals
have shown that the user mobility history can be helpful in predicting the future
movements of a MH. Depending on the service commitment to mobile users, these
proposals pre-allocate resources at various levels in advance along the predicted
path. For instance, to obtain mobility independent service guarantees, the MRSVP
[TALU99] and other similar protocols attempt to make resource reservations at each
location a MH may visit during the lifetime of a session. The Shadow Cluster
concept [LEVI97], on the other hand, estimates future locations of a MH in the short
term rather than long term. Based on the probabilities of a previous visits and the
current trajectory of a MH, network resources are reserved near its present location Mobility-Aware Network QoS 106
and along its direction of travel. A less ambiguous scheme can be found in the
Profile Based Next-Cell Prediction [BHAR97], where resources are reserved only at
the most likely visiting cell, and further QoS commitments depends on the
reservation process after the next handover. It is noticeable that the further ahead a
scheme tries to predict the movement, the more likely it is to support the lifetime of
a session. However, this is achieved at the expense of overall network utilisation
because of poor prediction accuracy.
• Coarse-Grained Allocation - This scheme does not reserve resources on a per-user
or per-cell basis, but works on a logical model called the Virtual Bottleneck Cell
[JAIN99], which treats a cluster of basestations as an aggregate virtual system. The
authors believe that by controlling the parameters and functions of a virtual
bottleneck cell, the QoS agreements at each BS inside the cluster can be satisfied,
even in environments with heterogeneous demands among basestations. However, it
is not obvious how to decide the boundary of a virtual bottleneck cell, so that it is
large enough for users to stay for a sufficient duration but small enough to
accurately reflect the characteristics of underlying basestations. Moreover, because
of its design philosophy, it is difficult to integrate this aggregated admission control
with a flow-specific mobility protocol such as MRSVP [TALU99] or Advanced
Reservation Signalling [MAHAOO].
6.1.3. Discussion of Advance Reservation Issues
Regardless of the whether the network uses ATM or IP technologies, advance reservation should make a compromise between the continuity of QoS support and the risk of over-reservations in the mobile network. The coarse-grained allocation appears Mobility-Aware Network QoS 107 to be a scalable solution to this problem, but the feasibility of aggregated functions and the scope of a virtual bottleneck cell require further investigation. The neighbourhood- based allocation is the simplest scheme to implement. Nevertheless, resources are likely to be over-subscribed because mobile users are seldom walking randomly in real life.
By applying user mobility patterns, the history-based allocation scheme reserves resources in selective surrounding cells, and thereby attempts to minimise the probability of over-reservation in the mobile network. This view has been supported by simulation results from various studies [LEVI97, OLIV98, RAMA99], but its usefulness in real life cannot be fully verified unless the actual user mobility in wireless networks is better understood.
6.2. User Mobility Prediction
The study of user mobility prediction in realistic environments is our contribution to the issue of “WHERE TO” pre-allocate network resource for mobile devices. In the literature, there is a diversity of user mobility patterns being used for analysing the performance of resource reservation and call admission control. In their simple model, user movements can be simulated as highway traffic in two possible directions at various constant speeds [LEVI97]. In a more generic form, user movements can be classified as purely random, mostly random, purely deterministic, or mostly deterministic [BHAR97]. In yet another proposal [LIU96], user movements consist of regular and random components. The authors believe that the regular components can be matched with circle or track patterns, while the random can be simulated via the Markov chain model. Mobility-Aware Network QoS 108
Among these proposals, a commonly perceived notion is that user movements
have some level of regularity. In particular, it is believed that by logging the user
movements for a sufficiently long time, one can identify the similarities between the
current trajectory and the past movement patterns, so that the future location(s) of a
mobile user can be determined with a higher confidence.
6.2.1. Traces of Realistic Movements
In order to verify the above claim, we obtained and analysed three sets of user
mobility traces in real life under both indoor [CHAN98] and outdoor [CHAN99,
CFLANOO] circumstances. A brief description of these traces is presented in the
following sections.
6.2.1.1. Indoor Movement Traces
The indoor movement traces was conducted at a three-story office building of
ORL (Olivetti and Oracle Research Laboratory, UK) in February 1994, where the daily
movements of its 32 staff members were monitored for a period of 15 days. Logged by
the Active Badge Location System, the traces provide mobility information such as the
sighted location, the badge ID and the time when the user was sighted [WANT92].
An Active Badge is a simple device that emits infrared signalling every 15-
second to a nearby sensor. Hence, the raw data collected cannot be immediately used as
a representation of users roaming in a pico-cell environment. To closely resemble a
futuristic wireless network layout, we have grouped those infrared movement sensors
into 18 regions and each region represents a pico-cell with diameter of 10 to 15 metres.
As shown in Figure 20, most part of this office building is covered by this pico-cell Mobility-Aware Network QoS 109 infrastructure except places such as tea rooms and toilets. Moreover, we eliminated those rapid movements between adjacent cells and inserted some missing steps into movement paths because of the slow location update period.
Our modifications still preserve general movement paths of those Active Badge wearers. To verify this claim, we analysed the number of mobile users and the number of cell crossing as shown in Figure 21. On average, each mobile user generated 10 cell crossings per hour during office hours, but higher rates of up to 16 crossings per hour
Floor 3
Floor 2
Floor 1
Floor G
UG Car Park Exit
Figure 20. Layout of the indoor movement traces at the office of ORL (UK) Mobility-Aware Network QoS 110
oooooo oooo°o o^cocjcboo^t-odcvicbo test duration enlargement (Thu 10/2/94 - Fri 25/2/94) (Mon 14/2/94 - Tue 15/2/94) Figure 21. Behaviour of users in the indoor movement traces were also recorded. The data exhibited behaviour patterns such as working days of the week, and office hours in a working day.
6.2.I.2. Outdoor Movement Traces
The first set of outdoor movement traces was taken from a local GSM network.
In April 1999, we logged the identity of basestations a mobile phone was connected to as a user was travelling by train between the central business district of Sydney and one of its outer suburbs.
This user followed the same railway link for both inbound and outbound journeys, and the train regularly stopped at 14 train stations as shown in Figure 22. This diagram also shows some triangular symbols that represent the locations of BS registered in the traces. We had traced 26 round-trip journeys during the office hours of five consecutive working days and on average, 30 handover events were recorded for each single trip. Mobility-Aware Network QoS 111
<«* ✓'tl /
South TurrvtttL.
•,
WA #•>%&* BRCX ty 'VrY^tt l)*" 1 " «Or»S\ jf N , S«sforth > V
jHAtewood,'
GfrufCtr*^- v Horth ^
snSowbsn* '
* ■tiyvikyr '*■ / viu Cremoma /h'}-.'Vks ' •< ------/ , K-romin Point Y 'V'SEPT -kt-A ^Yl*A '“I* *£**•*fW PVPV'* /a „n -/I ,,-'[rW & /W <* / :>* ’ ;j ^wKjJ^c qfa l j) rl(- / •^fcr,- r^C , * lit? *lf.vp hock -^5^ V •* \ ■'•■ ««, ■/ ^ LgT"T---- / /’V^ rV-V^ Double \ -D BUfiWOOD \ » N '2c& Jh *
' IhwY~‘
Figure 22. Layout of one of the outdoor movement traces in Sydney
Similar to the above trial, the second set of outdoor traces logged the movements of a mobile phone user as this person was travelling on a highway between the central business district of a city to one of its outer suburbs. Due to commercial confidentiality, Mobility-Aware Network QoS 112 we can only reveal that all inbound and outbound trips followed the same route and this journey was continuous for five days during office hours.
6.2.2. Conventional Prediction Algorithms for User Mobility
The movement traces of the above section were used to verify the performance of several conventional mobility prediction algorithms when applying in real-life situations. We will introduce five conventional prediction algorithms based on individual movement patterns, and one extra algorithm based on mobility patterns of nearby users (see Figure 23). These algorithms will be explained as follow:
• Location-Based Scheme — As a MH leaves its present location, it records the next
BS and keeps track of the number of times it visits each of the BSs. This
information from the mobility history forms a probability distribution of next
moves, and we refer to the distribution of each departure as a departure history. The
Location-Based scheme identifies the MH’s current location and uses the departure
history of this location to predict the next move of the MH (see Figure 23(a)). The
BS that is most frequently visited will be predicted as the next BS.
• Direction-Based Scheme - Rather than simply using location, it is possible to
improve the accuracy if the MH’s direction of travel is taken into account, i.e., if its
present and previous locations are known (see Figure 23(b)). The Direction-Based
scheme thus incorporates direction information into the departure history. It
identifies the MH’s current direction of travel and uses the departure history of this
direction to predict the next move of MH. Just like the previous scheme, we predict
the move with the highest departure rate as the next BS. Mobility-Aware Network QoS 113
prediction departure ...... <~ = B (55%) prediction = B (80%) —^ history/ 25% \ :f...... ►(A) • .-•'15% /n\ direction of : j \_y /—\ travel /-A 80% /—v : # 5---- (a) Location-Based Scheme (b) Direction-Based Scheme seg. A-F seg. F-A multiple segments contain the same beginning portion (A, B, C) as the present segment present seg. prediction = I (occurs twice) (c) Segment-Based Scheme /-■. 60% 01 the most likely 50% B1 > >Q step for visit two prediction = B (70%) 40% / / \C2 \ p0pS away ■Q direction of Ai-1 Ai / r 15% Figure 23. Various conventional prediction algorithms for user mobility • Segment-Based Scheme - This scheme extends the Direction-Based scheme further. All previous movements are partitioned into a number of segments and then stored as a pattern in the history. A segment starts with a stationary cell in which the MH stays for a sufficiently long time (e.g. 40 seconds in the indoor environment and 20 Mobility-Aware Network QoS 114 minutes in the outdoor environment). As the MH begins to travel in the wireless network, all cells encountered are appended to the segment. The segment ends with the same or a different stationary cell, which will become the beginning of a new segment (see Figure 23(c)). This algorithm keeps on matching the segment currently under construction with those segments already stored. A match is found if the present segment is identical to the initial portion of a stored segment. Then the cell immediately after the initial portion of the matched segment is predicted to be the next move. If multiple stored segments contain the same beginning portion like the present segment, a match segment is selected if it occurs more often in the previous movements (refer to Figure 23(c) for an illustration). • Bayes’ Rule - Instead of considering the route already taken, it is possible to extend the Direction-Based scheme so that all departure histories along the future direction of travel are considered. Bayes’ Rule [WINS97] is used to calculate the probability distribution of all possible next moves once a reference point further down the direction of travel is given. This reference point, for the ease of our implementation, is taken as the most likely step two hops away from the present location (see Figure 23(d)). The Bayes’ Rule formula can be expressed as: P(A'-iA,B,)*P(Cm \Ai_1AlBx) P(Al_lAlBx |Cj = where Am and Aj are the previous and present locations, Bx is the xth possible next move, Cm is the most likely step for visit two hops away, and n is the total number of possible next moves. Once the conditional Mobility-Aware Network QoS 115 probabilities of all possible next moves are calculated, the one with the highest value is selected as the predicted movement. • Time-Based Scheme - To explore the dependency of user movements on certain time of the day, the Time-Based scheme imposes the time of cell crossing (e.g. accurate to the nearest hour) into the Direction-Based scheme (see Figure 23(e)). With the assumption that people trend to have some regular daily activities, the collected probability should better describe the user movements. • Correlation-Based scheme - Mobility prediction can be performed by observing the movement patterns of other users, similarly to the ideas described in [BHAR97] and [CHAN97]. However, since different people may display different behaviour, a long aggregated history of their movements may only show equal probability for all neighbouring cells. Instead, we argue that a user’s next move tends to follow the movement pattern of other people nearby if they move in the same direction. For each location, the Correlation-Based scheme collects the statistics of all users in last 30 minutes and constructs a departure history for prediction purposes. 6.2.2.I. Performance of Conventional Prediction Algorithms against Realistic Movement Traces We partitioned the three sets of realistic movement traces mentioned earlier into days and randomly selected the days, so that 60 % of the data was used to initialise the system to a normal operating state (i.e. to form initial history files), and the remaining 40 % was used to carry out mobility prediction experiments. Table 1 is a summary of the performance of our conventional prediction algorithms when applying to the realistic movement traces. In general, it is shown that Mobility-Aware Network QoS 116 prediction algorithm and the source of history affect the outcome of prediction accuracy rate. The Direction-Based scheme has the best performance, while Bayes’ Rule and the Location-Based scheme have a less accurate rate, following by Time-Based and Segment-Based schemes. As expected, the Location-Based scheme did not perform well since it did not take the direction of travel into account. In contrast, the performance of the Time-Based scheme was worse than that of the Direction-Based scheme. This is probably due to our early assumption about the users’ regular daily activities not being correct. Another interesting finding is that more complicated algorithms, such as the Segment-Based scheme and Bayes’ Rule, did not guarantee an improvement on the Table 1. The performance of various prediction algorithms on some indoor and outdoor movement traces Prediction Accuracy Ratio for Various Movement Traces Prediction Mobility History Algorithm (min - median - max) % Indoor Outdoor 1 Outdoor 2 individual mobility Location-Based 37-50-66 40-52-62 42 - 53 - 66 profile individual mobility Direction-Based1 62 - 72 - 83 53 - 66 - 77 49 - 63 - 79 profile individual mobility Segment-Based$ 44 - 56 - 67 0-9-31 0-4-7 profile individual mobility Bayes’ Rule 60 - 68 - 82 39-64-82 37 - 61 - 79 profile individual mobility Time-Based 43 - 59 - 77 18-40-53 27 - 47 - 61 profile movements of Correlation-Based 47 - 66 - 78 no data no data nearby users 1 algorithm with the best performance + its poor performance is partly due to the lack of matching sequences in the history Mobility-Aware Network QoS 117 prediction accuracy. The inferior performance of the Segment-Based scheme, especially in the outdoor traces, was caused by the lack of matching sequences in the history. Even though those mismatches were not counted, we had found that the accuracy of the Segment-Based scheme was only similar to that of the Direction-Based scheme. The Correlation-Based scheme could not be applied to the outdoor movement traces because there was only one user being recorded in the traces. But for the indoor movement traces, daily activities of multiple users were captured. Therefore, it is possible to investigate not only the differences of mobility patterns from different users, but also the correlation of user movements between one user and the others moving ahead of this person. Our analysis supports the common assumption that each user has some level of regularity in their movements. For example, using the Direction-Based scheme, the prediction accuracy rate of these users could vary from 62 to 83 percent. However, if the source of history was changed according to the movements of other people in a similar direction (e.g. the Correlation-Based scheme), the prediction accuracy rate fell to between 47 to 78 percent. Hence, we argue that it is worthwhile to use an individual’s movement history to predict the next move, but the correlative history can still be useful if a user arrives at a new place and requires the function of advance resource reservation. 6.2.2.2. Discrepancy between Commonly Used Mobility Models and Realistic Measurements From the results shown above, it appears that realistic mobility patterns displayed a significant amount of variation, and they could not be accurately predicted. We may argue that such poor prediction accuracy rate is due to a high level of statistical randomness in user behaviour. However, if we recall the testing condition of the Mobility-Aware Network QoS 118 outdoor movement traces, there was only a single user travelling forwards and backwards along a fixed route, but the performance of prediction accuracy was significantly below our expectation despite the use of various prediction algorithms. By examining these mobility patterns in details, it was found that most “random components” of the traces came from the Ping-Ponging between adjacent basestations or some temporary handovers to other basestations relatively far apart (i.e. not neighbouring basestations). We can visualise this observation by dividing the route in Figure 22 into six segments, and surrounding those basestations at each segment with an ellipse (identified as region A to F in this diagram). For instance, it can be shown that when the user was travelling in region A, his mobile phone tended to hand over to a lot more basestations than it did in other regions. We believe that the above effects were caused as a result of a combination of signal fluctuations, constraints of the surroundings, congested cells, and moving obstacles. Another common assumption of these outdoor mobility patterns is that the forward and backward movement traces are very similar except their order is reversed. In spite of the presence of some key basestations along the path, our analysis does not strongly support this claim of reverse mapping between forward and backward movements. We believe that this variance was a consequence of the use of hysteresis in handover algorithm. In its presence, handover decisions of forward and backward journey are very likely to take place at different locations within a cell, and thereby the statistics of handover patterns tend to vary. From the above discussion, we can conclude that the large discrepancy between the user mobility models and the actual system measurements is due to incorrect assumptions in the mobility models. Most mobility models focus on the behavioural Mobility-Aware Network QoS 119 patterns (i.e. the physical movements) of users, but pay less attention to user mobility from the perspective of a wireless network. In real-life mobile environments, it is necessary for the mobility prediction algorithms to predict the network access point through which the mobile user will connect to the network. In other words, we should predict the BS to which the user will next connect, rather than the physical location into which the user is moving. 6.2.3. A New Prediction Confidence Parameter for Predicting User Mobility From our previous study of movement traces, it is clear that a useful mobility prediction algorithm needs to incorporate not only user behavioural patterns, but also wireless link characteristics and the handover decision-making mechanism. However, all these are complicated issues, and comprehensive solutions may not be available in the near future. Nevertheless, we believe that a user’s movement history still contains valuable information about this person’s behavioural patterns and some useful hints about the stability of wireless link along the movement path. Moreover, if there are multiple basestations to be chosen during handover, we can select the most appropriate one(s) and avoid unnecessary consequent handovers. As a practical approach to improve the prediction accuracy and the feasibility of resource reservation, we have proposed an adaptive mobility prediction algorithm in [CHAN98]. Because of the uncertainty of estimating a user’s future movements in reality, we have constrained this algorithm to predict only the next move of the user’s present Mobility-Aware Network QoS 120 Current Resource Allocation Advance Resource Reservation (20%) \ (65%) ) (PCR = 75%) Figure 24. A brief illustration of the use of PCR path. A parameter called the Prediction Confidence Ratio (PCR) is used to express the user’s desire of service continuity. This prediction algorithm is defined as follow: A prediction is derived from the probability distribution of all possible next moves from the mobility history. If the first predicted cell does not contain a probability higher than the PCR, one or more extra cells will be added to the group of cells in which resources will be reserved in advance. This process will continue until the sum of their probabilities exceeds the targeted PCR. The motivation of this adaptive mobility prediction algorithm is to avoid predicting the random components of user movements. Instead of selecting the most likely cell but not meeting the user’s expectation of service continuity, this algorithm can adaptively reserve resources in advance at multiple nearby cells according to the Mobility-Aware Network QoS 121 user behavioural patterns and wireless link characteristics. Figure 24 is a pictorial presentation of the use of PCR. If PCR is set to be 75 %, both cell 3 and 4 need to be involved in resource pre-allocation because the probability distribution of cell 3 (65 %) alone does not satisfy the requirement of PCR. Applying this algorithm with different values of PCR into our realistic mobility traces, we can improve their prediction accuracy rate accordingly. Figure 25-27 present the results of this algorithm using a Box Plot notation, in which the median, interquartile range and outliers of every 5 % increments of PCR are shown. 5 10 15 20 25 30 35 40 45 50 55 60 65 80 85 90 95 100 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 Prediction Confidence Ratio (PCR) Figure 25. Applying different values of PCR to improve the prediction accuracy rate in the indoor movement traces Mobility-Aware Network QoS 122 < 70 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 Prediction Confidence Ratio (PCR) Figure 26. Applying different values of PCR to improve the prediction accuracy rate in the first outdoor movement traces 80 5 10 15 20 25 30 35 40 45 50 55 60 65 80 85 90 95 100 2.5 .... 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 Prediction Confidence Ratio (PCR) Figure 27. Applying different values of PCR to improve the prediction accuracy rate in the second outdoor movement traces Mobility-Aware Network QoS 123 Inevitably, there is a compromise between the level of service commitments (in terms of prediction accuracy rate) and the risk of over-subscriptions in the mobile network (in terms of number of cells involved in advance reservation). For example, the prediction accuracy rates of the indoor and outdoor movement traces were initially 72, 62 and 66 percent accordingly. By requesting a PCR of 75 % (shown as the vertical dotted lines in Figure 25-27), the prediction accuracy rates increased to 87, 81 and 80 percent respectively but an average cell participation of 1.6 was required for all cases. 6.3. Advance Resource Reservation This section is our contribution to resolve the problem of “HOW TO” configure resources in advance for mobile users. Since this is a common issue in both IP and ATM environments, we explain how advance resource reservation can be integrated into our Home-Proxy based solution and Wireless ATM networks. In addition, we briefly illustrate how the concept of PCR can be incorporated in such environments. 6.3.1. Integration of Advance Resource Reservation into the Home- Proxy Based Framework In our Home-Proxy based framework, resource allocation is divided into macro- and micro-levels, which in turn establish network resources across the Internet backbone and over the wireless link. Applying a similar approach to the advance resource reservation, we believe it will greatly simplify the actual implementation and minimise the modifications required to the existing QoS frameworks. • Advance Macro-Reservation - If the predicted location of a MH belongs to a different administrative domain, its WIG plays an important role in pre-allocating Mobility-Aware Network QoS 124 resources across the Internet backbone. For instance, it can act as a RSVP proxy agent similar to that described in [TALU99, MAHAOO] for the IntServ architecture, or as an ingress or egress router for the DiffServ architecture. The benefit of our advance macro-reservation approach is that it requires no changes in the existing QoS framework across the Internet backbone. Provided that the regional DHCP server can release a COA in advance upon the request of the HP, the SLM module at the HP can simply establish multiple connections, in advance, to various WIGs belonging to those predicted locations. • Advance Micro-Reservation - QoS support across the Internet backbone is managed by the process of (advance) macro-reservation. Therefore, we argue that by assigning wireless resources for a QoS path at multiple basestations, we are effectively extending the QoS support of this Internet connection in advance into multiple locations. Moreover, as the MH moves from one location to another, the number of cells participating in resource pre-allocation can be different. However, regardless of the user location in the administrative domain, the same QoS path is used to carry traffic across the Internet backbone, and therefore no change is necessary to the (advance) macro-reservation. These different levels of resource pre-allocation, plus their subsequent handover events, are schematically shown in Figure 28. In this diagram, the sequence of events that takes place is according to a network topology previously shown in Figure 17. For the ease of illustration, we do not include any sophisticated location management scheme in the diagram (e.g. no terminal paging or conditional location update when the MH is idle). In addition, we show only one possible prediction of the next move in the diagram, but this pre-allocation process can be repeated multiple times Mobility-Aware Network QoS 125 control message resource allocation new data flow ~ ~ -j&s~ unchanged data flow Subnet 1 V Subnet 2 Subnet 3 HP CH UserApp SLM SLM UserApp subnet adv. | COA = ? ------r------COA = X path-update (micro-mob) location update (macro-mob) (a) Initial CH — MH location updates and location request conection location setup response granted HP ** X (macro-resv) HP *-* X micro-resv ( micro-resv) HP, X HP, X HP, X * ~ f“ — *«*» — «» -q — — —— • •la request for pre-alloc at subnet2 this COA reservation (b) COA process can Advance be repeated macro HP *-» Y granted request r to different reservation ^macro-resv) granted micro-resv locations based on the response of pre-alloc at subnet 2 (COA PCR value. Here, resevation to (c) path-update (micro-mob) subnet 2 is Handover of location update (macro-mob) sufficient. macro :p: mobility HP *-» Y (micro-resv) Z CH, MH HP, Y CH, MH xr. —!► request for pre-alloc at subnet3 (d) this reservation process can Advance granted be repeated to different micro micro-resv locations based on the PCR reservation response of pre-alloc response at subnet3 value. Here, resevation to subnet 3 is sufficient. subnet adv. p (e) path-update (micro-mob) Handover of path-delete (micro-mob) micro mobility HP ♦* Y (micro-resv) CH, MH HP, Y HP, Y HP, Y CH, MH Figure 28. The schematics of advance marco- and micro-reservation in the Home-Proxy based framework using the concept of PCR depending on the desired PCR value as well as the probability distribution of the next move. It is noticeable that reservations do not occur between the WIG and BS because it is assumed that the network paths between the two are congestion free. When the MH moves to a new subnet, it sends out control messages to refresh the routing path for micro-mobility management, and to perform a location update at the Mobility-Aware Network QoS 126 HR for macro-mobility management. Later a connection (say, with a PCR value of 75 %) is initiated by a CH. Following the procedures described in Section 5.2.3, the communication is established between a CH and MH (see Figure 28(a)). Then the MH estimates its next move to be 85 % at Subnet 2, and 15 % at Subnet 3, both located in another administrative domain. After matching this next move probability with the PCR, the MH finds that a resource reservation towards Subnet 2 is sufficient to satisfy the PCR. Therefore, it sends out a control message to the HR requesting pre-allocation of resources to this predicted location. The HR contacts the DHCP server at the expected domain and obtains a pre-assigned IP address, which is required by resource pre-allocation later. Then the HR authorises the SLM at the HP to create a path and reserve the necessary resources to this expected domain. Since WIG 2 is the last hop of this QoS path, it completes the establishment phase of resource reservation and then pre-allocates wireless resources at the expected cell. Then a reply is sent back to the MH about the success of reservation and the pre-assigned IP address (see Figure 28(b)). Assume that the movement prediction is correct and the MH arrives at the expected location. By examining the advertisement on the wireless link, the MH realises that it has arrived at the new domain as expected and changes its IP address to the pre assigned value. Then the MH sends out a control message to refresh the routing path for micro-mobility and to perform location update at the HR for macro-mobility. Because most of the network configuration has already been completed in advance, user data can be re-directed with minimal rerouting latency (see Figure 28(c)). Now assume that the MH continues its journey inside the new domain. This time the MH predicts its next move to be 80 % at Subnet 3 and 20 % at another subnet (not shown in Figure 17 or 28), both located in the same domain. After matching this next Mobility-Aware Network QoS 127 move probability with the PCR, the MH finds that a resource reservation at Subnet 3 is sufficient. Hence, it sends out a control message to WIG 2, which grants extra wireless resources at the predicted location (see Figure 28(d)). Again, we assume that this prediction is correct and the MH arrives at the expected location. As soon as it sends out a path refresh message to WIG 2, user data can be forwarded from WIG 2 to this new location where wireless resources are already available (see Figure 28(e)). 6.3.2. Integration of Advance Resource Reservation into the Wireless ATM Framework Although the concept of advance resource reservation was initially proposed in the study of Wireless ATM, so far most of its work has focused on the performance analysis of resource reservation and call admission control. In our research into Wireless ATM, we are interested in the integration of advance resource reservation into the emerging Wireless ATM standard. In Wireless ATM, both mobility and QoS support are network-centric. In the ATM Forum’s proposal [ATMFOO], the mobility management requires modifications to existing signalling protocol, and some enhanced standards such as M-UNI signalling, M-PNNI signalling and Handover Control Channel (HCC) are being used (see Section 4.2.2.3). In order to support advance resource reservation, we propose to enhance M- UNI and HCC further with some new options. In essence, our newly proposed options have very similar characteristics to those handover commands in M-UNI (e.g. handover request and handover response), HCC (e.g. handover request query, handover request response and handover command and handover complete) and M-PNNI (e.g. handover related setup). However, those End-user Mobility supporting ATM Switches (EMASs) need Mobility-Aware Network QoS 128 to distinguish these new options from the handover commands, such that partial connection segments can be pre-configured to reach multiple locations when necessary. Provided that one of the predicted location is the actual next move, the partial connection segment joining to this location will be activated during handover, whereas the other unused configurations would be deleted accordingly. Because of their relationship with advance resource reservation, these new options are denoted as follows: • Reservation Request and Reservation Response in M-UNI. • Reservation Request Query, Reservation Request Response, Reservation Command and Reservation Complete in HCC. • Reservation Related Setup in M-PNNI. Their operations can be schematically shown in Figure 29. For the ease of illustration, as before, we show only one possible prediction of next move in the diagram. Again, this connection setup process can be repeated multiple times depending on the desired PCR value and the probability distribution of the next move. When the MH arrives at EM AS 1, it has one on-going connection (say, with PCR value of 75 %). This MH estimates its next move to be 85 % at a BS belonging EMAS 2 and 15 % at another BS belonging to a different EMAS not shown in the diagram. After comparing the next-move probability distribution with PCR, the MH decides to pre-configure a connection to the predicted BS. Therefore, it issues a reservation request message to EMAS 1. EMAS 1 invokes some (unspecified) local procedures to determine the ATM switch managing the predicted BS (e.g. EMAS 2). It then sends out a reservation request query message to EMAS2, which in turn considers Mobility-Aware Network QoS 129 M-UNI M-PNNI EMAS1 ATM Network EMAS2 RESV_REQUEST- RESV_REQ_QUERY- RESV_REQ_RESPONSE- RESV_COMMANO - —RESV_RELATED_SETUP— ► -----CONNECT- RESV_COMPLETE- RESV_RESPONSE HO_REQUEST- HO_RELEASE - PARTIAL_RELEASE Switch to new ATM - extension & release old ATM each T Disassociate & extension y associate radio link RELEASE_COMPLETE- CONN_ACTIVATE- CONNACTIVE- Figure 29. The schematics of advance reservation in the WATM framework using the concept of PCR the resource requirement of this pre-allocated connection, and replies a reservation request response message to EM AS 1. EM AS 1 then invokes some crossover switch selection procedures to locate a suitable crossover point, and issues a reservation command message to EMAS 2. EMAS 2 invokes the M-PNNI signalling to establish a partial connection segment towards the crossover switch. This crossover switch sends a reservation complete message to EMAS 1, which then replies to the MH with a reservation response message indicating the success of resource pre-allocation. Assume that the movement prediction is correct and the MH decides to move to the expected BS. Just following the normal handover procedures, this MH issues a handover request message to EMAS 1. Since most of the network configurations have Mobility-Aware Network QoS 130 been completed in advance, EMAS 1 immediately relies to the MH with a handover release message to initiate wireless link handover. At the same time, EMAS 1 also informs the crossover switch to perform a network handover. When the MH arrives at the new BS, it issues a connection activate message to EMAS 2, which then resumes the rerouted ATM connection to the MH. 6.4. Summary The existing QoS frameworks cannot cope with end user mobility. In this chapter, we focused on a proactive approach of using advance resource reservation to make QoS frameworks more mobility-aware. Because this is a relatively complex issue, we have divided this problem into two tasks, namely where to pre-allocate network resources in advance, and how to configure resources in advance when roaming. In general, locations participating in the pre-allocation process will be the neighbours of the current position, the movement history of mobile users, or an aggregate virtual system. Among them, the second approach seems to be the most promising because it only invokes a subset of nearby locations for advance resource allocation. Our research extends this using insights gained by analysing mobility patterns in real-life indoor and outdoor environments. It was found that real mobility patterns displayed a significant amount of variation, and future movements could not be accurately predicted from the history of previous movements. We argued that many user mobility models only focus on the behavioural patterns of users, but ignore the fact that user mobility should be modelled from the perspective of a wireless network, thus making them in accurate and unusable. To develop a usable model, other factors such as wireless link characteristics and handover decisions need to be taken into Mobility-Aware Network QoS 131 considerations. Therefore, we concluded that it would not be possible to obtain a comprehensive and useable solution without significant advances in all the above areas. As a practical approach to the problem of where to pre-allocate resources, we developed a new parameter called Prediction Confidence Ratio (PCR), which essentially avoids predicting the random components of user movements by pre allocating resources at multiple nearby locations. This approach can be considered as a compromise between the level of service commitments and the risk of over subscriptions in the mobile network. Applying this approach with different values of PCR into our realistic mobility traces, we demonstrated that the prediction accuracy rate could be improved accordingly by involving more than one cell during resource pre allocation. In this approach, the number of cells necessary for advance reservation depends on and the behavioural patterns of users as well as the characteristics of wireless link, the handover decision mechanism, and the QoS requirements of user applications. We also investigated the issue of how to pre-allocate resources in both IP and ATM based networks, by revisiting the Home-Proxy based and Wireless ATM frameworks described in Chapter 5 and 4. For the scenario of Home-Proxy based framework, we introduced a novel concept of advance macro- and micro-reservation. The advantage of this concept is its ease of implementation, which requires only minimal changes to the WIG. At the scenario of Wireless ATM, we proposed some minor extensions to the M-UNI, HCC and M-PNNI protocols for supporting advance resource reservation. To conclude this chapter, we use a 3-D chart as shown in Figure 30 to illustrate the enhancements of advance reservation to these frameworks, which are now capable of supporting mobile multimedia applications. Mobility-Aware Network QoS 132 Mobility Highly Mobile Home-Proxy Framework WATM with Hon[ie-Proxy Soft QoS & / Framework Mob. Mgt/'x wi^h PCR WATM with V Soflj QoS, \ Mob. Mgt. Mobile & NCR Best Multimedia | Strict support i Guarantee Mobile IP Stationary Effort ------(T\» QoS Fixed Wireless WATM with soft QoS Connectivity IntServ DiffServ Figure 30. Enhancements of advance reservation to the Home-Proxy based and Wireless ATM frameworks 133 CHAPTER 7. Realisation of QoS and Mobility Support To prove the viability of the designs presented in Chapter 5 and 6, we built prototype systems and tested them in an experimental environment. The first prototype is a proof-of-concept implementation of the Home-Proxy based solution for Internet environments. Its purpose was to determine the performance of a multimedia application under the influence of network congestion as well as macro- and micro mobility. We are also interested in determining the performance improvements achieved by integrating advance resource reservation into this framework. The second prototype is for a hybrid IP-ATM environment, which consisted of an ATM core network and an IP wireless access network. The aim of this prototype was to emulate a Wireless ATM network, especially its mobility extensions such as M-UNI, M-PNNI and HCC. We then integrated the enhancement of advance resource reservation into this prototype to validate its improvement on the handover performance. Realisation of QoS and Mobility Support 134 7.1. A Prototype Implementation of the Home-Proxy Based Solution with Mobile DiffServ Support The first prototype consisted of a home network built at the University of New South Wales (UNSW) and a foreign administrative domain at CSIRO Telecommunications and Industrial Physics (TIP). Both premises are located in Sydney about 25 kilometres apart. Figure 31 shows the organisation of the experimental set up that was used. For ease of development, the functionality of HR, HP, WIG and WSRs (described later) in this prototype were implemented in Java and C running RedHat 6.2 Linux [REDH]. All Linux boxes were off-the-shelf PCs. Most of them were equipped with Pentium III 550 MHz processor and 128 MB RAM, with the exception of WSRs and MHs which only had a Pentium 133 MHz processor and 64 MB RAM. Although most of the components were connected by 100 Mbit s'1 Ethernet links, the link between the UNSW and CSIRO TIP was a two megabits per second ATM link. In addition, the wireless interfaces used the WaveLAN 802.11 cards [WAVE], which had a relatively low bandwidth of 5.5 Mbit s'1. These limitations on network bandwidth validate our earlier assumption that the bottleneck of network resources is at the Internet backbone or at the wireless links. Realisation of QoS and Mobility Support 135 Cisco LS 1010 ATM Switch The University of New South Wales CSIRO Telecommunication & Industrial Physics WIG Cisco 7500 Fore ASX 200 Router ATM Switch WSR2 HR = home register WSR1 HP = home proxy CH = corresponding host WIG = wireless internet gateway / WSR = wireless subnet router /£ MH = mobile host MH2 MH1 Figure 31. Layout of the prototype implementation of the Home-Proxy based framework 7.1.1. Simplification in the Implementation For ease of implementing, several simplifications to the framework proposed in Section 5.2 were made to the prototype. • It was assumed that there were only two types of service available: premium and best effort. These services were made available through a DiffServ architecture, where the incoming traffic was classified and marked only at the ingress router of Realisation of QoS and Mobility Support 136 the home network. Moreover, since the DiffServ framework does not require explicit signalling on a per-flow level, we could avoid the use of proxies to perform advance resource reservation on behalf of a user. In an IntServ architecture, it would have been necessary to deploy RSVP proxy agents. • Network bandwidth was considered as the only QoS parameter in the prototype, and it was assumed that a simple admission control mechanism for premium service was available in both the home network and the foreign administrative domain. This function was emulated by two simplified Bandwidth Broker (BB) modules at the HR and WIG, which kept track of the bandwidth consumed by premium service at the Internet backbone and at the wireless interfaces. These simple BB modules can be easily replaced by a more rigorous admission control mechanism once it becomes available in the DiffServ framework. • The functions of mobility-aware router and basestation (e.g. R2, B3 and B4 in Figure 17) were merged into a new single entity called the Wireless Subnet Router (WSR). In addition, for total separation of network traffic between subnets, the wireless interface at each WSR was configured to operate at a disjoint subband frequency. • The aim of this prototype was not to determine the link layer handover performance. Moreover, the delay in DHCP assignment and the detection of subnet arrival can depend heavily on the software implementation [FIK099, VATN98]. To isolate these effects from the handover performance at network and session layers, we implemented a mobility emulator at the MH that periodically generated DHCP parameters for use in macro- and micro-mobility. Realisation of QoS and Mobility Support 137 • This prototype was also not intended to focus on the efficiency of location management mechanisms. Therefore, even when the MH did not have an active connection, location update process was still triggered with every move of the MH (i.e. no terminal paging or conditional location update implemented). • A QoS capable MAC layer is essential to properly support multiple service classes across the wireless link. Alternatively, a distributed protocol can be used among basestation and mobile hosts within its coverage to manage the parameters of token bucket filters on outgoing IP traffic [HORL97]. In the prototype, however, the WSR could only control the IP downlink traffic by using the Linux DiffServ software [DIFF]. • We placed the CH at the home network to avoid any undesirable network congestion between the CH and HP, as this does not lose any generality. 7.1.2. Components of Prototype Implementation The Home-Proxy based wireless Internet framework consists of various components and modules. As shown in Figure 32, there are five major components (i.e. Mobile Host, Wireless Subnet Router, Wireless Internet Gateway, Home Register, Home Proxy). These components are connected by four control protocols, namely a Micro-Signalling Protocol, a Macro-Signalling Protocol, a Home-Proxy Signalling Protocol and a Bandwidth Broker Signalling Protocol. Each component consists of numerous modules that interact with each other and these relationships are indicated by the dotted lines in the diagram. Realisation of QoS and Mobility Support 138 The majority of these modules were implemented under Java JDK 1.1.8 [JAVA] environment to take advantages of its multi-thread capability. However, due to the lack of support of some specific functions in the Java language, some modules were realised Wireless Internet Gateway MicMob Mgt Routing MicQoS Mgt Config Cisco ingress router BBSig Protocol Linux Kernel MicSig Protocol console Wireless Subnet comnands Router via NetCat Home Register MacQoS Mgt MicQoS Mgt MicMob Mgt Service Authorisation T raffic Routing Home Proxy Control Config Socket HpSig Protocol HP agent MacMob Mgt EF: FIFO queue BE: RED queue Linux Kernel Proxy ARP, IP Alias Linux Kernel MacSig Protocol MicSig Protocol User Interface QoS Mgt User Appl Mob Emulator Service MacMob Mgt MicMob Mgt Request Socket Socket Wnet Config Reflector Relay dynamic link loader ifconfig, iwconfig, route Linux Kernel Mobile Host Figure 32. Software modules and components inside the prototype implementation of Home-Proxy based framework Realisation of QoS and Mobility Support 139 using the Java Native Interface (JNI) and C programs, or directly using Unix shell scripts to interact with the Linux kernel. These kernel functions are shown by dotted boxes in Figure 32. The above mentioned components and protocols are described in the following sections. 7.I.2.I. Mobile Host The MH consists of many modules. While some of these modules interact with users to obtain their preferences in relations to QoS and mobility, the others perform networking tasks such as macro- or micro-mobility management. All modules within a MH will be explained as follow: • QoS Management Module (QoS Mgt) - This module provides two functions. First, a user interface with control buttons that enable the user to upgrade or downgrade the current network services. Second, the procedures for transferring the user’s QoS preferences to the HR or WIG. • Mobility Emulator (Mob Emulator) - This module, as the name suggests, enables the emulation of user mobility. It does not belong to the core function of an MH but is a feature of the prototype. It provides a control panel for the user to change the frequency with which macro- and micro-handovers take place. When a handover event occurs, it passes the relevant information such as DHCP parameters (e.g. default gateway, netmask, IP address) and the value of wireless link subband frequency channel, to the Macro- and Micro-Mobility Management modules. • Macro-Mobility Management Module (MacMob Mgt) - This module contains the logic required for macro-mobility management. When a macro-handover event is triggered, it invokes the Wnet Config module (described below) to update the latest Realisation of QoS and Mobility Support 140 DHCP parameters and wireless subband frequency of the MH. At the same time, it co-ordinates with its counterpart at the HR to tear down and re-establish the inter- SLM connection(s) between the HP and MH. • Micro-Mobility Management Module (MicMob Mgt) - This module contains the logic required for micro-mobility management. When a micro-handover takes place, this module, similarly to the MacMob Mgt module above, invokes the service of Wnet Config module to change the default gateway, netmask and wireless subband frequency of the MH, while leaving the current IP address unchanged. It also sends out a path update message to fresh its routing path between the new WSR and the WIG. • Wireless Network Configuration Module (Wnet Config) - This module modifies the network interface and routing table as macro- or micro-handover requires. Since Java language does not provide such utilities, this was implemented using JNI and C to invoke system calls in Linux kernel. These system calls are equivalent to the role of user commands such as ‘ifconfig’, ‘iwconfig’, and ‘route’. • Socket Reflector Module - This module redirects the sockets calls from user applications. This can be achieved using the LD PRELOAD directive of the dynamic link loader to insert a user-defined library between a user application and the system libraries, such that system calls like bind(), connect() and sendto() in the application would be redirected to a waiting Socket Relay module. At the same time, it passes on the specifications of this socket to the Service Request module described below for further process. Realisation of QoS and Mobility Support 141 • Service Request Module - To enable the home network to initiate services on behalf of the MH, this module collects information about an invoked session (e.g. transport protocol, IP address, and port number) and transfers it into the HR for authorisation clearance. • Socket Relay Module - The core of SLM is a set of socket relays, each of them can join two network sockets by copying user data from one socket to another, and vice versa. During a macro-handover event, one of the sockets need to be replaced (in case of a TCP socket) or modified (in case of a UDP socket) because of the change of destination IP address. When this happens, MacMob Mgt module can instruct this module to pause and resume data copying processes between sockets. 7.I.2.2. Home Register For scalability, a home network can have multiple home registers and each HR can serve multiple mobile hosts. We assume that each mobile user is uniquely assigned to a HR, which contains some user specific information such as service parameters and current location. The HR was completely implemented in Java and consists of the following modules. • Macro-QoS Management Module (MacQoS Mgt) - When this module receives a request for a service upgrade or down grade from the mobile user, it first obtains a permission from the Service Authorisation module described below, and signals the BB module for macro-resource allocation. If a macro-handover event takes place, this module is responsible for asking the BB module to allocate network resources for the new inter-SLM connection(s). Realisation of QoS and Mobility Support 142 • Macro-Mobility Management Module (MacMob Mgt) - When receiving a location update from an MH, this module stores the latest location of the MH and uses it for handling incoming calls. In addition, if an MH has on-going connection(s) and requests a macro-handover, this module will consult the Service Authorisation module described below and instruct the HP to tear down and re-establish inter- SLM connection(s). • Service Authorisation Module - This module takes care of the authorisation of mobile user activities such as service requests, requests for change of QoS and macro-handovers. In addition, it acts as a co-ordinator between the MacQoS Mgt and MacMob Mgt modules for these activities. For instance, if the MH has a service request or macro-handover, this module instructs the MacMob Mgt to set up inter- SLM connection(s) and the MacQoS Mgt to establish associated network resources. • Bandwidth Broker Module (BB) - This is a simplified implementation of the Bandwidth Broker related to the DiffServ framework. It keeps track of the bandwidth consumed by a premium service across the Internet backbone and communicates with its counterpart at the foreign administrative domain. Once a connection with premium service is accepted, this module sends out a configuration script to the ingress router enabling it to mark the packets destined to the MH as high priority. 7.I.2.3. Home Proxy If there is more than one Home Proxy in the home network, the HR can dynamically assign mobile users to one of the Home Proxies when the first service request from the MH arrives. This feature enables Home Proxies to be added to the Realisation of QoS and Mobility Support 143 network depending on the required processing power, traffic loading and number of users. Each HP has the following software modules. • Home-Proxy Agent - This module receives instructions from the HR to initiate or handover connections. All these commands are passed on to the Socket Relay module for appropriate actions. One exception is when the HP needs to accept incoming connection(s) on behalf of the MH. In this case, the HP agent invokes a Unix shell script to intercept the MH’s packets (by means of a Proxy ARP) and passes them to the waiting Socket Relay module (by means of an IP Alias) to complete the end-to-end path. • Socket Relay - This module is identical to the one described in the MH. However, one of the sockets here is connected to the corresponding host, whereas the one in the MH is connected to the user application. 7.I.2.4. Wireless Subnet Router (WSR) WSR is an enhanced router, which is capable of supporting micro-mobility management and QoS across the wireless link. Although not included in our prototype implementation, other mobility-aware routers between the WIG and WSR should have a simpler configuration than a WSR because they do not need to handle the wireless interface. A WSR consists of the following modules: • Micro-QoS Management Module (MicQoS Mgt) - This module interacts with the Traffic Control module to manage service differentiation across the wireless link. In addition, it keeps track of the total bandwidth of the downlink premium service and reports this information to the WIG for the use of admission control across the wireless link. Realisation of QoS and Mobility Support 144 • Traffic Control Module - This module is a Java front-end for the Linux DiffServ software that manipulates the queuing disciplines inside the Linux kernel. For service differentiation across the wireless link, a high priority, low delay First-In- First-Out (FIFO) queue is used for the delivery of premium service, whereas the best-effort traffic is passed through a Random Early Detection (RED) [FLOY93] queue. • Routing Configuration Module (Routing Config) - This module can be used to add or delete a forwarding entry from the routing table. As these functions are not supported in Java, this was realised by using JNI and C programs to invoke system calls in Linux kernel which are equivalent to the user command of ‘route’. 7.1.2.5. Wireless Internet Gateway The WIG is based on a standard configuration of a Linux router and its software modules are very similar to those found in the WSR. For the convenience of implementation, it does not normally have any wireless interface but includes a BB module. The BB module provides an overall picture of the bandwidth consumption of downlink premium services at each WSR. This enables other BB modules (e.g. the one at the HR) to enquire about the network resource allocation towards a certain WSR. 7.1.2.6. Control Protocols There are five control protocols being defined in our prototype. They carry various QoS and mobility management control messages. The five control protocols are: Realisation of QoS and Mobility Support 145 • Macro-Signalling Protocol (MacSig Protocol) - This protocol is between the MH and its HR, and exchanges information about events, such as service requests, location update, macro-handover and change of QoS preferences. • Micro-Signalling Protocol (MicSig Protocol) - This protocol operates between the MH, WSR, and WIG. It exchanges information about path updates and path delete messages for micro-mobility management and about bandwidth consumption for micro-reservation of wireless resources. • Home-Proxy Signalling Protocol (HpSig Protocol) - This protocol operates between the HR and the HP. It is mainly used by the HR to control the operations of HP during a service request or macro-handover. • Bandwidth-Broker Signalling Protocol (BBSig Protocol) - This protocol operates between BB modules to allocate network resources. Due to the lack of support in today’s routers, the communication protocol between the router and our BB module is done by means of issuing console commands via a Telnet session. A simple utility called NetCat [AVIA] is used for reading and writing data across this Telnet connection. 7.1.3. Network Characteristics Before conducting any experiments, we measured the link characteristics of both wide area and wireless networks using network performance tools such as Ping and Iperf [IPER], and the results are summarised in Table 2. Since mobile host is only one hop away from its basestation, the wireless link has small jitters as expected. On the other hand, the wide area network has relatively large jitters because packets have to go through various network devices and protocol conversions. Realisation of QoS and Mobility Support 146 Table 2. Link Characteristics of wide area and wireless networks HP ^ BS BS MH HP ^ MH Effective Bandwidth (Mbit s'1) 1.5 5.2 1.5 Bit Error Ratet 0 0 0 Round Trip Delay (ms)1 4.4 1.9 6.6 Jitter (ms)1 0.3 0.05 0.4 1 Measured at the loading of effective bandwidth. 7.1.4. Testing Scenarios In this experimental environment, we were particularly interested in determining the influence of user mobility and network congestion on multimedia traffic. Thus the testing scenarios were conducted on RTP applications. The RTP application we used to conduct testing consisted of a MP3 player (FreeAmp) at the MH and a MP3 jukebox (Obsequiem) at the CH [OBSE]. The Obsequiem server was slightly modified so that it can perform RTP streaming in unicast instead of broadcast mode. When a mobile user has chosen a song, this request to the MP3 jukebox triggers a MH-initiated connection establishment via the SLM (see Figure 13(a) in Section 5.2.2). From this request, the Obsequiem server learns the home IP address of the mobile user and the port number to be opened by FreeAmp. In the meantime, the FreeAmp application opens a UDP socket at the MH, and its HP is informed and prepares itself for the incoming traffic (see Figure 13(b)). When the Obsequiem server sends the RTP data stream to the home network of the MH, the HP is ready to receive the RTP packets and relay them to the current location of the MH. Although there is only one foreign administrative domain in the prototype, our mobility emulator can explicitly request a macro- or micro-mobility handover when the Realisation of QoS and Mobility Support 147 MH moves between the two WSRs (see Figure 31). In addition, the mobile user can request his/her home network to upgrade or downgrade the current network service at any time. To provide premium service, the Cisco 7200 ingress router first marks the precedence bits of those packets destined to the MH as high priority. Then these packets are queued at the ATM interface, where they are conditioned and sent via a CBR PVC to the foreign administrative domain. Similarly, as high priority packets reach the WSR hosting the mobile user, the Linux DiffServ software sends them to a high priority, low delay, FIFO queue for delivery to the MH. In default best-effort case, the ingress router marks the precedence bits of those packets destined to the MH as low priority, and transfers them via a UBR PVC to the foreign administrative domain. Then when these packets need to get across the wireless link, the Linux DiffServ software at the WSR directs them to a low priority RED queue with 60 Kbytes of buffer size. During the experiment, a subnet handover was generated every 10 seconds at MH1. The handover event was repeated 100 times for each of the following conditions: • Macro-mobility with best effort service • Macro-mobility with premium service • Micro-mobility with best effort service • Micro-mobility with premium service To test the effectiveness of the premium service class, we introduced heavy best effort traffic in the background, i.e., 94 % link capacity from the CH to the WIG, and 91 % link capacity from WSR1 to MH2. In the presence of background traffic, the round- trip time for “pinging” the WIG and CH from MH2 was around 250 ms and 300 ms respectively. Realisation of QoS and Mobility Support 148 7.1.5. Results The results of this experiment can be divided into two parts: the first part is concerned with the performance of macro- and micro-mobility management; and the second part is concerned with the performance of macro- and micro-reservation. 7.I.5.I. Performance of Mobility Management We tested the MP3 application in the above scenarios and recorded the time of interruption and the number of RTP packet losses at MH1 during handover. Table 3 is a summary of the performance, and presents each result in terms of average and standard deviation. Compared to macro-mobility management at the session layer, micro mobility management at the network layer provided a better handover characteristics (i.e. shorter interruption and less packet loss). For example, when an input buffer size of 20 Kbytes was set for the MP3 player, the audio interruption was just a very short skip when there was no background traffic present (i.e. in the case of best effort in Table 3). On the other hand, we noticed a significant degradation in the handover performance for both macro- and micro-mobility when heavy background traffic was present (i.e. in the case of premium service in Table 3). This deterioration was mainly Table 3. Performance of handover in the prototype implementation of Home-Proxy based framework Macro-mobility Handover Micro-mobility Handover Best Effort Premium Best Effort Premium Service Service Time of Interruption (ms)* 159 ± 26 361 ±418 126 ± 45 215 ±132 Number of Loss Packet* 6.3 ± 0.9 19.4 ± 13.8 2.5 ± 0.7 9.7 ±9.6 + Average and standard deviation values are calculated from 100 handover events. Realisation of QoS and Mobility Support 149 due to the lack of multiple service class support in the wireless interface. Consequently, all mobility control protocols in the uplink direction had to compete with the downlink background traffic, and inevitably experience a longer delay. Our view is supported by the earlier observation of poor connectivity to the WIG at MH2. The worst handover characteristics occurred when MH1 was performing macro handover under heavy background-traffic conditions. Beside the lack of multiple service class support in the wireless link, the macro-mobility control protocols had to pass through a congested Internet backbone. Moreover, it was found that the Cisco 7200 ingress router needed a certain time interval before it could activate a new marking scheme for packets destined for the new user location. During this transition period, there were three to five packets being marked as best effort, even though the user required premium service class. Consequently, these packets were either being dropped in the best effort queues, or they arrived out of sequence at the MH. In a rough comparison with other prototypes, the handover performance of our prototype has a slightly low rating. For instance, considering a user space implementation of Mobile IP [RODR] with frequent location re-registration, the handover interruption time can be as low as 123 ms on average [COUDOO]. Another example is Cellular IP which would drop only one packet during a hard handover with a light load condition [CAMP00]. However, since most of the coding in our prototype uses the Java language, the performance values in Table 3 can be significantly improved if our modules were written in a more efficient programming language and optimised. Realisation of QoS and Mobility Support 150 7.I.5.2. Performance of Resource Reservation After a user had selected the premium service, we were able to successfully maintain the MP3 streaming traffic despite heavy network congestion and user mobility. In an ideal seamless mobility environment, we would expect to receive our MP3 traffic at a constant bit rate of 320 kbit s'1. In a practical environment, however, subnet and domain handovers would cause additional jitter in the RTP traffic. Moreover, since our SLM and WSR implementations did not retransmit UDP packets, we would expect some traffic interruption as mentioned in the previous section. In order to observe the effectiveness of our macro- and micro-reservation mechanism, we introduced background traffic separately at the Internet backbone and the wireless link, while the arrival rate of RTP packets was measured at MH1. Figure 33(a) illustrates the arrival rate of RTP packets when the MH was performing macro handovers. Due to the heavily congested Internet backbone, only a small portion of the MP3 traffic managed to get through and arrive at the MH. However, once the user upgraded to premium service, the RTP packets were received at the MH regardless of a congested backbone and frequent user mobility. Figure 33(b) shows a similar result when MH1 moves in and out of some congested and non-congested wireless subnets. Although the MH was performing micro-handovers every 10 seconds, the arrival rate of RTP traffic was maintained as long as premium service was selected. Moreover, it is worth noting that our micro reservation scheme did not require any reconfiguration of the marking scheme at the ingress router of the home network, and therefore was transparent to the macro reservation mechanism at the Internet backbone. Realisation Figure 33. Arrival of 1000 1200 1600 QoS 400 600 800 Bandwidth of Receiving RTP (kbps) 1000 200 300 500 600 700 800 900 - - - and - - T rate ------T A, C B, Mobility A = C B, E D of upgrade = = = = D, RTP start upgrade (b) micro-handover micro-handover (a) E, MP3 Support MP3 F best-effort packets = to macro-handover traffic to premium traffic premium congestion under Elapsed arrival arrival background Elapsed into into service service a a the under under non-congesl congested Time Time into influence traffic micro-mobility macro-mobility (sec) a (sec) new subnet at ed of domain the subnet user backbone mobility and network 151 Realisation of QoS and Mobility Support 152 7.1.6. Improvement of Advance Resource Reservation Advance resource reservation can improve service continuity and reduce handover latency. This function can be easily implemented in this prototype for downlink traffic. For advance macro-reservation, the MacQoS Mgt module at the HR can request the BB module to allocate network resources at more than one location for the MH. In our prototype implementation, the BB module instructed the Cisco ingress router to mark packets destined to the current COA as well as those travelling to the predicted COA. This process is even easier for advance micro-reservation. Since the BB module at WIG had a “full picture” of bandwidth consumed by downlink traffic at each WSR, advance micro-reservation only means that it logically allocated wireless resources to multiple WSRs in its internal lookup table. Because of the fast internal process of advance micro-reservation, we do not expect to see an obvious improvement on the performance of micro-handover, except a better assurance of service continuity. For advance macro-reservation, however, we can achieve significant improvement on the performance of macro-handover. Table 4 is a comparison of the performance of macro-handover with and without advance resource reservation. On average, the handover latency and packet loss were reduced by 43 ms Table 4. Performance of macro-handover with and without advance resource reservation in the Home-Proxy based prototype implementation Premium Service With advance resource Without advance resource reservation reservation Time of Interruption (ms)1 318 ±84 361 ±418 Number of Loss Packet1 12.4 ± 3.4 19.4 ± 13.8 1 Average and standard deviation values are calculated from 100 handover events. Realisation of QoS and Mobility Support 153 (i.e. 12 %) and 7 packets (i.e. 36 %) respectively due to advance resource reservation. In addition, from their small values of standard deviation, it is suggested that their performance was more consistent than before. These findings agree with our earlier observation that the Cisco 7200 router required certain time intervals before it could activate the new marking scheme, which contributed to additional loss of packets and variation in handover latency. 7.1.7. Lessons Learnt from the Implementation During the construction of this prototype, we have learnt several interesting lessons that do not relate to the correctness of our approach but are more implementation specific. • Conversion of TOS Byte and DSCP - To date the Cisco routers only comply with the original standard of type-of-service (TOS) field rather than DSCP in the packet header. As a result, the Linux DiffServ software at the WSR needs to recognise their marking by shifting the value of TOS field 2 bits to the right in order to get the DSCP. For instance, if the Cisco ingress router marked the packets of premium service as a TOS value of 0x20 (i.e. precedence value of 1), the Linux DiffServ software at the WSR recognised these packets with a DSCP value of 0x08. • Update of Routing Cache at WSR and WIG - If dynamic per-host routing is used in micro-mobility management, it is essential that those mobility-aware routers can change their routing tables immediately after receiving a path update message. For efficiency, most routers today (including Cisco and Linux implementations) forward packets based on the routing cache instead of the actual routing table. Unfortunately, there is a minimum time delay (three seconds for Cisco and two seconds for Linux) Realisation of QoS and Mobility Support 154 before the routing cache gets the updates from the actual routing table. This means that if dynamic per-host routing is used, there will be a minimal handover latency of two seconds in a Linux router. To get around this problem, we had to change this value to zero at the ‘route.c’ program of the Linux kernel. • Guaranteed Data Delivery across Wireless Link - Since the wireless link layer in this prototype does not guarantee data delivery, it is prudent to use TCP protocol for carrying control messages between the MH and other network components. One exception is the transport of Path Update message in micro-handover. Since this message is used for setting up per-host routing entry at the WSR, the initial TCP handshaking would fail if this message were carried by TCP protocol. To overcome this problem and avoid the loss of control messages, it is necessary to build a reliable transfer mechanism on top of UDP protocol. 7.2. A Prototype Implementation of a Wireless ATM Network with Advance Resource Reservation The second prototype is based on a Wireless ATM network which had ATM core and access networks as shown in Figure 34. The ATM core network consisted of three off-the-shelf ATM switches from the Fore Systems (one backbone ASX-200BX and two workgroup LE155 switches). The ATM access network consisted of three PCs, each to represent an End-user Mobility supporting ATM Switch (EMAS). These PCs were a fixture of Pentium 90MHz and 133MHz machines, all equipped with 32 MB RAM, a 155 Mbit s'1 ATM card and a two megabits per second WaveLAN card. For ease of development, the functionality of EMAS was implemented in Java and C running Redffat 5.2 Linux [REDH]. Realisation of QoS and Mobility Support 155 MH Figure 34. Layout of the prototype implementation of the WATM framework 7.2.1. Simplifications in the Implementation The objective of a Wireless ATM network is to provide ATM services end-to- end. However, due to the lack of acceptance in both wired and wireless access systems, ATM-based applications or its wireless interfaces are not available today and will not be in the market for the foreseeable future, if ever. In addition, because the work of Wireless ATM specification is still in progress at the ATM Forum, no commercial EMASs are available. Thus to ease the implementation burden, several simplifications were made in the prototype. However, we believe that these simplifications, described Realisation of QoS and Mobility Support 156 below, do not impact the validity of our protocol design presented in the previous chapters. • Due to its lack of support, the wireless ATM interface was emulated by a WaveLAN interface. Since the WaveLAN card was only a wireless LAN interface with IP support, we needed to convert user data between IP and ATM formats when entering and leaving the ATM access network. A typical solution to this issue is the “Classical IP over ATM” approach [LAUB98]. However, this approach lacks the support of QoS (i.e. all data sessions between two endpoints sharing the same UBR connection), and the ATM switches along the path do not have any control of connection rerouting. Therefore, we introduced proxy entities at the boundary of the ATM access network (i.e. the locations of those Linux machines in Figure 34). Each of them acts as an IP-ATM converter that matches real-time IP traffic into the AAL5 CBR service and best-effort IP traffic into the AAL5 UBR service. • Another function of these proxies was to emulate the operation of an EMAS. However, instead of switching user data at the ATM-cell level, these proxies relayed user data at the connection level. The advantage of this approach is that rerouting of ATM connection becomes possible between those Linux machines without modifying the firmware of the ATM switches to accommodate mobility signalling such as M-UNI and HCC (see Section 4.2.2.3). Moreover, since new SVC connection(s) were being set up between proxies during handover, it was not necessary to alter the PNNI protocol between ATM switches to recognise mobility- aware operations such as Handover-Related Setup and Partial Release. • Since this prototype does not focus on IP mobility management, we configured all WaveLAN cards to share the same IP subnet and hence the MH was free to connect Realisation of QoS and Mobility Support 157 to any mobility-aware switches without changing its IP routing table. In addition, we implemented a connection redirection module at the MH which automatically forwarded user data into the mobility-aware switch currently serving this MH. • We only implemented the path extension scheme with loop elimination for rerouting ATM connection among those mobility-aware switches. 7.2.2. Components of Prototype Implementation As shown in Figure 35, there are three major components in the prototype: the MH, the mobility-aware switch, and the CH. Within each component, again several software modules interact with one another, and these relationships are indicated as dotted lines in the diagram. As before, the majority of these modules were implemented under Java JDK 1.1.7 [JAVA] but also incorporated special functions through JNI and C. These modules are described in the following sections. 7.2.2.I. Mobile Host The MH in this prototype was IP- rather than ATM-based. However, it could be handed over from one MAS (described below) to another by using mobility signalling protocol similar to the one currently defined in Wireless ATM. There are three main modules in the MH. • QoS Management Module - Although today’s IP applications do not support QoS guarantees, the QoS Management module can register the user’s service requirement (e.g. premium or best-effort) for future lookup. • Connection Redirector Module - The core of this module is a socket reflector similar to the one described in the previous prototype. When a user application has Realisation of QoS and Mobility Support 158 Mobility-A ware Corresponding Switch Host IP-ATM IP Application Conversion ATM ATM Switch ATM connection connection Mobility Connection (UNI) (UNI) ATM-IP Management Switching Conversion Mobility-A ware PNNI Switch ATM connection Mobility Connection (UNI) Management Switching ATM IP-ATM Switch Conversion M-UNI connection User Interface QoS IP Application Management Mobility Connection Management Redirctor Wireless Signal Quality Linux Kernel Mobile Host Figure 35. Software modules and components inside the prototype implementation of WATM framework initiated a new connection, this connection is reflected by the Connection Redirector module to reach the MAS currently serving the MH. At the same time, this module also obtains the user’s service requirement from the QoS Management module and forwards this information to the MAS for ATM service subscription. Realisation of QoS and Mobility Support 159 • Mobility Management Module - This module sets up an M-UNI signalling to the MAS (described below). Moreover, it invokes JNI and C programs to access the Linux kernel for obtaining the statistics of wireless link quality. To avoid Ping- Ponging between adjacent MASs, a simple hysteresis algorithm is applied during the decision of handover. When handover takes place, the mobility management module requests the present MAS to reroute the on-going ATM connection(s) to the next MAS. Then it instructs the Connection Redirector module to forward IP connection(s) to the new MAS. 7.2.2.2. Mobility-Aware Switch (MAS) A Mobility-Aware Switch (MAS) combines the functions of a connection relay and a basestation. There are three functional elements inside the MAS. • IP-ATM Conversion Module - Since the MH is only IP-capable, user data has to be converted between ATM and IP formats as it arrives from or before it is sent across the wireless interface. This function can be easily achieved in this prototype because a MAS works on the connection level, rather than on ATM-cell or IP- packet levels. • Connection Switching Module - This module copies user data back and forward between two sockets, which is similar to the concept of socket relay as mentioned in the previous prototype. However, since the Java language currently does not support ATM services, we have developed a new set of ATM socket classes in Java which access the functionality of Linux ATM socket [ATML] via JNI and C programming. These classes operate just like the standard IP socket classes, but Realisation of QoS and Mobility Support 160 with additional QoS parameters (e.g. UBR bandwidth, CBR bandwidth with peak cell rate). • Mobility Management Module - This module communicates with the MH via M- UNI protocol and with another MAS via HCC protocol. When a handover occurs, the Mobility Management Module co-operates with its peers at the MH and other MAS(s), and instructs the Connection Switching Module to perform connection rerouting. 7.2.2.3. Corresponding Host The corresponding host in this prototype has an ATM interface but its applications are based on IP services. Therefore, we need an IP-ATM Conversion module, similar to the one at the MAS, which copies user data between the ATM interface and the IP application. 7.2.2.4. Control Protocols Since the backbone network of this prototype consists of only standard ATM switches, their control protocols (e.g. UNI and PNNI) are not mobility-aware. Following the standard proposed for Wireless ATM (see Section 4.2.2.3), we have implemented two control protocols for the purpose of mobility management. • M-UNI - We emulate the Wireless ATM M-UNI signalling by setting up a TCP connection between the MH and the MAS. Although a TCP session takes longer time to establish, it provides the necessary reliability for message delivery across the wireless link. Realisation of QoS and Mobility Support 161 • HCC - This module provides functions proposed in the Wireless ATM HCC signalling, which uses a specific pre-configured VC between the MASs. 7.2.3. Testing Scenarios With this prototype, our first aim was to demonstrate the feasibility of M-UNI and HCC signalling protocols for handling the handover of ATM connection(s). The user applications we used to conduct testing were TCP-based and consisted of an MPEG video player and a waveform audio player. The video player was based on the MPEG player developed in UC Berkeley but with additional modifications to make it operate in a client/server environment [DESI98]. At the beginning of the experiment, the MH requested an audio and/or a video file(s) from the CH. The CH then transferred to the MH the requested file(s), which would then be processed and played out to the mobile user. As the audio and/or video clips were being played out, the mobile user was free to move within the coverage area of the WaveLAN cards. Based on measurements of the strengths of the wireless beacons sent by various MASs, the MH could decide when to hand over from one MAS to another. When a handover occurs, the current MAS was responsible to reroute the on-going ATM connection(s) to the next MAS. At the same time, the MH changed its wireless link association to the selected MAS, which in turn joined the incoming wireless connection(s) to the rerouted ATM connection(s) and formed end-to-end communication. During the experiment, we initiated the download of one (audio) or two (audio and video) data streams. For each scenario, we triggered the handover process 10 times by physically moving the MH from one MAS to another. Realisation of QoS and Mobility Support 162 7.2.4. Results We tested the above scenarios and recorded the duration of interruption occurring during handover. We noticed a short skip on audio and some corrupted pixels on video when handover occurred. Table 5 is a summary of the results presented in terms of averages and standard deviations. The results showed that on average the handover latency was 169 ms for audio traffic, and 209 ms for audio/video traffic. By investigating the time intervals of consecutive events in M-UNI and HCC protocols (see Figure 8), it was found that the majority of this latency came from two sources: the delay of setting up ATM SVC connection(s) and the duration of wireless link disassociation/association. For instance, it took on average 55 ms and 85 ms to set up one and two SVC connections respectively, and out of a total time of 74 ms that took to complete the wireless handover. Because ATM is connection-oriented, all on-going connections have to be rerouted one-by-one. This agrees with our experimental results in which the delay of handing over two connections was 40 ms longer than the value of handing over a single connection. Their difference was mainly from the additional time required to set up a Table 5. Performance of handover in the prototype implementation of WATM framework Premium Service Audio traffic Audio and video traffic Time of Interruption (ms)* 169 ± 10 209 ± 18 * Due to the necessity of physical movement of mobile host during handover, only 10 handover events were used to calculate the average and standard deviation values. Realisation of QoS and Mobility Support 163 second SVC connection (on average 30 ms or more), as well as the extra burden of processing video frames at the MH. 7.2.5. Improvement of Advance Resource Reservation The second aim of this experiment was to demonstrate the feasibility and improvement of incorporating the feature of advance resource reservation into the M- UNI and HCC signalling protocols. We have implemented the modifications as previously illustrated in Figure 29 and repeated the experiment of handovers while downloading the audio traffic from the CH to the MH. Table 6 is a comparison of handover latency with and without advance resource reservation. On average, the handover latency was reduced by 73 ms (i.e. 43 %) when applying advance resource reservation. This saving came from the efforts that the SVC establishment (57 ms on average) and a majority of the HCC signalling were completed in advance before the actual handover started. With this improvement of advance resource reservation, the major component of handover latency only came from the duration of wireless link disassociation/association (84 ms on average). Table 6. Performance of handover with and without advance resource reservation in the prototype implementation of WATM framework Audio traffic Without advance resource With advance resource reservation reservation Time of Interruption (ms)1 169 ± 10 96 ± 10 ^ Due to the necessity of physical movement of mobile host during handover, only 10 handover events were used to calculate the average and standard deviation values. Realisation of QoS and Mobility Support 164 7.2.6. Lessons Learnt from Implementation Although this prototype serves our needs of validating the function of mobility management protocols and the advantages of advance resource reservation, we have found several limitations in such a hybrid IP-ATM implementation. • Flow Control of AAL5 - At the time of prototype implementation in 1998, Linux ATM had AAL5 as the only adaptation scheme, which provided no flow or error control. As a result, the dynamics of end-to-end flow control was lost between the MH and CH. Because of the significant mismatch of bandwidth between the ATM and wireless links, it was likely that the incoming video traffic would overrun the buffers of the ATM socket in the MAS, which in turn caused large packet losses at the MH. To get around this problem, we had to limit the transmission rate of video traffic at the CH, or to constrain the peak cell rate of CBR traffic across the ATM network. • Handover Detection at IP Layer - As in Mobile IP, the MAS used the ICMP packet as a wireless link beacon to signal the MH for handover. For better handover decision, these beacons should be sent as often as possible. However, if too many beacons were being used, they might impose significant burden to the wireless traffic. Another problem of these ICMP beacons was that they became useless if the MASs operated at disjoined subband frequencies. As we discussed earlier in Section 5.1.4, a good handover detection scheme should be assisted by link-layer functionality. • ATM Socket and Java Green Thread - When those Java ATM socket classes were first implemented, their reading and writing operations incurred a long delays (e.g. Realisation of QoS and Mobility Support 165 60 ms for JDK 1.1.6 version 2 and one second for JDK 1.1.6 version 4a). We believe that this was caused by some incompatibility between the Linux ATM implementation and Java thread running at user space (green thread). When the Java thread operated at kernel space (native thread) became available in JDK 1.1.7 and higher versions, this problem was automatically resolved. 7.3. Summary This chapter has presented the hardware and software implementation aspects of our prototypes. We have demonstrated the feasibility of our designs and studied their performance with and without the support of advance resource reservation. In the first prototype, we have shown that the Home-Proxy based solution can be readily realised because it involves only the integration of several existing facilities in a manageable and collaborative manner. The results suggest that our framework can support multimedia user applications with minimal handover latency and packet loss, despite frequency of user mobility and network congestion. We have also demonstrated the ease of integrating advance resource reservation into this framework. Besides a better assurance of service continuity, our results show that the gain in handover performance mainly comes from the avoidance of packet re-marking at the ingress router (i.e. a consequence of macro-reservation via BB). We believe this framework can be used effectively to support mobility and QoS in the emerging wireless Internet environments. As an emulation of Wireless ATM, the second prototype demonstrated a possible way to experiment the Wireless ATM mobility extensions without actually modifying the firmware of ATM switches. We have also enhanced these mobility Realisation of QoS and Mobility Support 166 extensions to support the function of advance resource reservation. It was shown that the improvement of handover performance is mainly gained from avoiding the establishment of ATM SVCs during handover. 167 CHAPTER 8. Conclusion and Future Work This chapter highlights the main features and findings of the research presented in this thesis, and compares our design philosophy with the current trends of networking technology. Then it presents an outline of the future directions of research, which in our opinion are significant. 8.1. Overview and Conclusion of the Research Our research has focused on the integration of QoS and mobility support into the ATM- and IP-based networking environments. In particular we have argued that the existing ATM and IP technologies do not cater for the demands of supporting mobile multimedia applications. We have discussed how ATM and IP technologies have evolved to deal with these issues. Today’s ATM networks do not support user mobility, and Wireless ATM has been proposed as a natural extension of ATM QoS in the wireless mobile world. It has the goal to provide both QoS support and seamless end-to-end VC connectivity to mobile users. Following the traditions of telecommunication network design, Wireless ATM retains most of its intelligence at the network core for handling user mobility management. There is a wide range of location and handover management schemes that Conclusion and Future Work 168 have been proposed in the literature, with a majority of them coming from the ideas of cellular networks. They aim at serving a large population of mobile users and emphasise on minimal handover latency as ATM connections are rerouted. Currently, the related signalling protocols are being standardised in the ATM Forum. Nevertheless, because of the dynamic range of bandwidth variations caused by wireless link characteristics and user mobility, the strict QoS guarantees of ATM service model are not suitable for mobile wireless environments. This can be addressed using two different techniques: a soft QoS model to relax the constraints of QoS requirements, and an advance resource reservation scheme to safeguard the QoS agreements of mobile services. In the Wireless ATM literature, different aspects of the soft QoS model and the advance reservation schemes have been investigated. However, it is still unclear how some of these new ideas will impact the overall ATM service model, and how they can function in a realistic environment. In addition, judging from the acceptance of network technologies in the past few years, it is doubtful that ATM will become an end-to-end solution even for fixed host environments. Thus, if at all, its deployment in wireless mobile networks seems very unlikely. Today’s Internet supports neither QoS nor user mobility. The IntServ and DiffServ models are being proposed as the foundation of the QoS architecture of future IP networks, together with Mobile IP as the standard for supporting user mobility. The IntServ framework resembles ATM in that it provides individualised QoS guarantees per-flow level. As a result, there are scalability concerns about the core routers. However, unlike ATM QoS, the IntServ architecture handles resource reservation using a soft-state approach, which makes QoS renegotiation of ongoing connections relatively Conclusion and Future Work 169 simple. The DiffServ framework attempts to resolve the scalability problem of IntServ by pushing the complexity of packet classification and traffic conditioning to the edge of the network. This allows the core routers to handle aggregated rather than individual flows. Despite the apparent simplicity in service differentiation, it is still unclear as how to construct end-to-end service models based on the proposed Per Hop Behaviour and Per Domain Behaviour. Moreover, it is not clear how to dynamically configure network resources within and between DiffServ domains. Mobile IP employs mobility agents at the network edges to handle device mobility such that the configuration of core network remains unchanged. It does not have a complex location management technique and currently uses a tunnelling mechanism to reroute mobile connections to the mobile host. Although Mobile IP is simple and scalable, it was not initially designed with consideration of QoS. As a result, it is incompatible with the IntServ or DiffServ frameworks. Wireless ATM and IntServ/DiffServ together with Mobile IP have their advantages and disadvantages when supporting mobile multimedia applications. Only recently have researchers started to address this open issue of integrating QoS and user mobility into the underlying network. We believe that this integration process is relatively complex and can be sub-divided into two tasks, namely how to make mobility management more QoS-aware; and how to make QoS support more mobility-aware. In this thesis, we have proposed a feasible solution to integrate QoS and mobility support in the IP environment. The proposed framework follows the design philosophy of the Internet by introducing proxy entities at the network boundaries to provide mobility and other value added services. The major contributions of this work are validation of the following proposals: Conclusion and Future Work 170 • By using proxy entities at the mobile host and its home network, it is possible to effectively de-couple user mobility management from the underlying IP QoS infrastructure, and thereby eliminate the complexities of tunnelling mobile user data across IntServ and/or DiffServ domains. • By operating proxies at the session layer of the OSI reference model, it possible to support both device and personal mobility without modifying the QoS framework. In addition, the Home Proxy provides a convenient insertion point for value added services such as protocol conversion and/or content adaptation. • As the Home-Proxy can initiate network connections on behalf of mobile users, the requirement to establish the user’s trustworthiness and accountability can be removed from the visited domain, and therefore the cost recovery processes of roaming services can be greatly simplified. • Splitting of mobility management into macro- and micro-mobility can be used within the framework to minimise the handover latency. In particular, as the proxies operate at the session layer for macro-mobility whereas the micro-mobility management works at the network layer, the operations of macro- and micro mobility become totally transparent to one another. • The proxy based architecture enables the introduction of the concept of advance resource reservation, which can be used to better support the provision of QoS guarantees in mobile environments. We have demonstrated an effective use of this under a DiffServ environment. • The QoS support in mobile environments can be further enhanced by dividing advance resource reservation into two levels, namely advance macro- and micro- Conclusion and Future Work 171 reservation. By using a proxy entity at the home network, we can eliminate the needs of modifying the Internet backbone to cater for advance macro-reservation. Moreover, without modifying the resource reservation at macro-level, the advance micro-reservation scheme can handle frequent changes of resource allocation at multiple wireless cells. • The use of mobility prediction to generate a Prediction Confidence Ratio (PCR) can be a practical means of deciding which locations should participate in advance resource reservation. From the insight of analysing real-life movement traces, it was found that a useful mobility prediction algorithm needs to incorporate not only user behavioural patterns, but also wireless link characteristics and the handover decision-making mechanism. Despite these difficulties, we have demonstrated that the prediction accuracy rate in real-life situations can be improved accordingly by increasing the value of PCR, which essentially includes more than one location during advance resource reservation. Our research also contributes to the understanding of Wireless ATM environments. The major contributions in this area are the following: • It is possible to emulate the mobility support of Wireless ATM by deploying proxy entities at the mobile host and the ATM network boundary, while leaving ATM switches at the core network to remain unchanged. In this environment, these proxies are mainly used for the ATM/IP protocol conversion, the management of mobility signalling protocols, and the rerouting of ATM connections. Conclusion and Future Work 172 • By following the network-centric design of Wireless ATM, it was shown that the functionality of advance resource reservation can be easily integrated into the currently proposed mobility signalling protocols at the ATM Forum. • The concept of mobility prediction with PCR can be applied equally well in determining the locations of advance reservation in Wireless ATM environment. With this enhancement, the Wireless ATM framework can better support the provision of QoS guarantees in mobile environments. 8.2. Future Research Opportunities Although Wireless ATM is unlikely to be widely deployed , there is still enormous interests in developing a wireless Internet infrastructure to support mobile multimedia and e-commerce services. In this section, we discuss some possible areas of extension to our research in the wireless Internet environments. • Hierarchical Proxy Region - In our Home-Proxy based framework, a proxy entity is introduced at the home network of a mobile host, which is partly used to shield user mobility from the corresponding host and to request network services on behalf of the mobile user. Besides placing proxy entities at the home network, we can try to deploy them in a hierarchical fashion within a large Internet access network. By doing so, a nominated proxy can take care of the roaming, accounting, and charging issues of a small administrative domain within this access network. • Programmable Network Support - Currently, the corresponding host in our framework is not mobility-aware, and thereby all packets destined to a mobile host have to go through its home network, which results in inefficient network resource utilisation. A possible solution is to employ the emerging technology of Conclusion and Future Work 173 programmable networks [JSAC01, CN01]. In a programmable network environment, some of the functionality of a Home-Proxy can be migrated onto a suitable network node near the corresponding host. By doing so, it optimises the end-to-end routing path and provides a trusted environment for accounting and charging purposes. • Implications of IPv6 Protocol - In our research work, we were only concerned with the current standard of IP protocol (IPv4). IPv6 [DEER98] is designed as the successor of IPv4, which intends to remove most of IPv4’s limitations. But despite the similarity in their name, IPv6 and IPv4 are two different protocols with incompatible address size, packet format, etc. Nevertheless, if it can be globally accepted, IPv6 will open a new horizon for inter-networking and have several implications especially with respect to mobility. On one hand, IPv6’s new features can ease the implementation of the proposed framework. For instance Neighbour Discovery [NART98] and Address Autoconfiguration [THOM98] simplify the function of packet capturing at the Home-Proxy and the assignment of COA at the foreign networks. Moreover, IPv6 sockets are bound to IP addresses at the logical level, hence it is easier to support mobility through dynamically changing the socket binding. On the other hand, it overcomes some problems that our framework attempts to resolve. For example, in IPv6 the corresponding host will become mobility-aware and the packet redirection technique will change from IP encapsulation to IPv6 routing header for source routing. Although recently researchers have started to investigate Mobile IPv6 [JOHNOl] and its related enhancements for smooth and fast handover [KOODOO, DOMMOl], their integration into the IP QoS framework and the requirements for accounting and Conclusion and Future Work 174 charging infrastructure have not yet been considered thoroughly. We believe that the Home-Proxy concept in our framework can serve as a centralised point for control signalling and charging processes in the IPv6 environment. • Security Consideration - Another important area which was not covered in this thesis is security. With the real-time constraints of multimedia applications and mission-critical nature of commercial use, the security issues of mobile services is certainly a challenging area for researchers. 175 References [ACAM94] A. Acampora and M. Naghshineh, “An Architecture and Mothodology for Mobile-Executed Handoff in Cellular ATM Networks,” IEEE JACS, 12(8), Oct. 1994. [ACHA97a] A. Acharya, J. Li, B. Rajagopalan, and D. Raychaudhuri, “Mobility Management in Wireless ATM Networks,” IEEE Commun. Mag., Nov. 1997. [ACHA97b] A. Acharya, B. Rajagopalan, and P. Shieh, “Comparison of Location Management Schemes for Mobile ATM,” ATM Forum 97-0161, Feb. 1997. [ACHA98] A. Acharya, J. Li, F. Ansari, and D. Raychaudhuri, “Mobility Support for IP over Wireless ATM,” IEEE Comm. Mag., Apr. 1998. [AGRA96] P. Agrawal, E. Hyden, P. Krzyzanowski, P. Mishra, M. Srivastava, J. Trotter, “SWAN: A Mobile Multimedia Wireless Network,” IEEE Pers. Comm. Mag., Apr. 1996. [AKYI99] I. Akyildiz, J. McNair, J. Ho, H. Uzunalioglu, and W. Wang, “Mobility Management in Next-Generation Wireless Systems,” Proc. IEEE, 87(8), Aug. 1999. [AKY097] B. Akyol and D. Cox, “Signaling Alternatives in a Wireless ATM Network,” IEEE JSAC, 15(1), Jan. 1997. [ARKK01] J. Arkko, P. Calhoun, P. Patel, and G. Zorn, “DIAMETER Accounting Extension,” IETF Internet Draft, Mar. 2001, work in progress. [ATMF96a] ATM Forum, “ATM UNI v4.0 Specifications,” Jul. 1996. [ATMF96b] ATM Forum, “ATM P-NNI vl.O Specifications, ” Mar. 1996. References 176 [ATMFOO] ATM Forum, “Wireless ATM Capability Set 1 Specification - Draft,” BTD-WATM-Ol. 13, Jan. 2000. [ATML] “ATM on Linux”, information available at http://sourceforge.net/ projects/linux-atm/ [AVIA] “Avian Research NetCat version 1.10,” information available at http://www.avian.org [AWDU97] D. Awduche and E. Agu, “Mobile Extensions to RSVP,” in Proc. IEEE ICCN’97, 1997. [AWDUOl] D. Awduche, L. Berger, D-H Gan, T. Li, G. Swallow, and V. Srinivasan, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” IETF Internet Draft, Feb. 2001, work in progress. [BARN95] A. Bar-Noy, I. Kessler, and M. Sidi, “Mobile Users: To Update or Not to Update?” ACM/Baltzer Wireless Network, 1(2), Jul. 1995. [BERNOO] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, “A Framework for Integrated Services Operation over DiffServ Networks,” IETF RFC 2998, Nov. 2000. [BHAR97] V. Bharghavan and J. Mysore, “Profile Based Next-Cell Prediction in Indoor Wireless LANs,” in Proc. IEEE SICON’97, Apr. 1997. [BHAT99] A. Bhattacharya and S. Das, “LeZi-Update: An Information-Theoretic Approach to Track Mobile Users in PCS Networks,” Proc. ACM/IEEE MobiCom’99, Aug. 1999. [BING99] B. Bing, “A Survey on Wireless ATM Technologies and Standardization,” Baltzer Telecommunication Systems, vol. 11, 1999. [BLACOO] D. Black, “Differentiated Services and Tunnels,” IETF RFC 2983, Oct. 2000. References 177 [BLAK98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differential Services,” IETF RFC 2475, Dec. 1998. [BORE99] M. Borella, V. Upadhyay, and I. Sidhu, “Pricing Framework for a Differential Services Internet,” European Tran, on Telecomm., 10(3), May 1999. [BRAD94] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” IETF RFC 1633, Jun. 1994. [CALHOO] P. Calhoun, T. Hiller, J. Kempf, P. McCann, C. Pairla, A. Singh, and S. Thalanany, “Foreign Agent Assisted Hand-off,” IETF Internet Draft, Nov. 2000, work in progress. [CAMPOO] A. Campbell, J. Gomez, S. Kim, A. Valko, C-Y Wan, and Z. Turanyi, “Design, implementation, and evaluation of Cellular IP,” IEEE Pers. Comm. Mag., Aug. 2000. [CARPOl] B. Carpenter and Packet Design, “A Bulk Handling Per-Domain Behavior for Differentiated Services,” IETF Internet Draft, Jan. 2001, work in progress. [CHAN97] J. Chan, S. Zhou and A. Seneviratne, “A Hybrid Handoff Scheme with Prediction Enhancement for Wireless ATM Network,” Proc. APCC’97, Dec. 1997. [CHAN98] J. Chan, S. Zhou and A. Seneviratne, “A QoS Adaptive Mobility Prediction Scheme for Wireless Networks,” in Proc. IEEE GLOBECOM’98, Nov. 1998. [CHAN99] J. Chan and A. Seneviratne, “A Practical User Mobility Prediction Algorithm for Supporting Adaptive QoS in Wireless Networks,” in Proc. IEEE ICON’99, Sep. 1999. References 178 [CHANOO] J. Chan, B. Landfeldt, A. Seneviratne and P. Sookavatana, “Integrating Mobility Prediction and Resource Pre-allocation into a Home-Proxy Based Wireless Internet Framework,” in Proc. IEEE ICON 2000, Sep. 2000. [CHANOl] J. Chan, B. Landfeldt, R. Liu and A. Seneviratne, “A Home-Proxy Based Wireless Internet Framework in Supporting Mobility and Roaming of Real-Time Services,” IEICE Transactions on Communications, E84-B(4), Apr. 2001. [CHAU99] P. Chaudhury, W. Mohr, S. Onoe, “The 3GPP proposal for IMT- 2000,” IEEE Comm. Mag., Dec. 1999. [CHEN97] T-W Chen, P. Krzyzanowski, M. Lyu, C. Sreenan, J. Trotter, “Renegotiable Quality of Service - a new scheme for fault tolerance in wireless networks,” in Proc. FTCS’97, 1997. [CNOl] Elsevier Science Computer Networks, special issue on Active Networks and Services, 36(1), Jun. 2001. [COUDOO] D. Coudeville, “Comparison between two protocols for mobility management in the Internet: Mobile IP and SLM,” Master Thesis, UNSW/ENSICA (Ecole Nationale Superieure des Ingenieurs des Constructions Aeronautiques), Aug. 2000. [DAY83] J. Day and H. Zimmermann, “The OSI Reference Model,” Proc. IEEE, 71(12), Dec. 1983. [DEER98] S. Deering and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” IETF RFC 2460, Dec. 1998. [DESI98] R. De Silva, “PNUT: Protocols configured for Network and User Transmissions,” Ph.D. Thesis, University of Technology, Sydney, 1998. References 179 [DIFF] “Differentiated Services on Linux,” information available at http://diffserv.sourceforge.net/ [DISTOO] A. Di Stefano and C. Santoro, “NetChaser: Agent Support for Personal Mobility,” IEEE Internet Computing Mag., Mar. 2000. [DOMMOl] G. Dommety (ed.), “Fast Handovers for Mobile IPv6,” IETF Internet Draft, Jul. 2001, work in progress. [DROM97] R. Droms, “Dynamic Host Configuration Protocol,” IETF RFC 2131, Mar. 1997. [ELMAOO] K. El Malki and H. Soliman, “Fast Handoffs in Mobile IPv4,” IETF Internet Draft, Sep. 2000, work in progress. [FANK99] G. Fankhauser, B. Stiller, and B. Plattner, “Arrow: A Flexible Architecture for an Accounting and Charging Infrastructure in the Next Generation Internet,” Baltzer Netnomics, 1(2), Feb. 1999. [FIK099] N. Fikouras, K. El Malki, S. Cvetkovic, and C. Smythe, “Performance of TCP and UDP during Mobile IP Handoffs in Single-Agent Subnetworks,” in Proc. IEEE WCNC’99, Sep. 1999. [FLAD99] A. Fladenmuller and R. De Silva, “The Effect of Mobile IP handoffs on the Performance of TCP,” ACM/Baltzer MONET, 4(2), 1999. [FLOY93] S. Floyd, V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance,” IEEE/ACM Trans. Networking. 1(4), 1993. [F0099] S. Foo and K.C. Chua, “Regional Aware Foreign Agent Scheme for Mobile-IP,” in Proc. MoMuC’99, Nov. 1999. [FORD93] P. Ford, Y. Rekhter, and H-W Braun, “Improving the Routing and Addressing of IP,” IEEE Network, May 1993. References 180 [FURU99] A. Furuskar, S. Mazur, F. Muller, and H. Olofsson, “EDGE: Enhanced Data Rates for GSM and TDMA/136 Evolution,” IEEE Pers. Commun. Mag., Jun. 1999. [GLASOO] S. Glass, T. Hiller, S. Jacobs and C. Perkins, “Mobile IP Authentication, Authorization, and Accounting Requirements,” IETF RFC 2977, Oct. 2000. [GUST01] E. Gustafsson, A. Jonsson, and C. Perkins, “Mobile IP Regional Registration,” IETF Internet Draft, Mar. 2001, work in progress. [HAND99] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: session initiation protocol,” IETF RFC 2543, Mar. 1999. [HEIN99] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, “Assured Forwarding PHB Group,” IETF RFC 2597, Jun. 1999. [HORL97] E. Horlait and M. Bouyer, “Precede de gestion de bandes allouees dans les reseaux locaux a acces partages, protocole et filtre de mise en oeuvre,” Patent number 9707667, Jun. 1997. [IPER] A. Tirumala and J. Ferguson, “Iperf Measurement Tool,” information available at http://dast.nlanr.net/Projects/Iperf. [JAC099] V. Jacobson, K. Nichols and K. Poduri, “An Expedited Forwarding PHB,” IETF RFC 2598, Jun. 1999. [JACOOO] V. Jacobson, K. Nichols and K. Poduri, “ The Virtual Wire Per- domain Behavior,” IETF Internet Draft, Jul. 2000, work in progress. [JAIN98] R. Jain, T. Raleigh, C. Graff and M. Bereschinsky, and M. Patel, “Mobile Internet Access and QoS Guarantees Using Mobile IP and RSVP with Location Registers,” in Proc. IEEE ICC’98, Jun. 1998. [JAIN99] R. Jain, B. Sadeghi, and E. Knightly, “Towards Coarse-Gained Mobile QoS,” in Proc. ACM WoWMoM’99, Aug. 1999. References 181 [JAVA] “Java Linux - Java Development Kit”, information available at http://www.blackdown.org/java-linux/ports.html. [JOHNOl] D. Johnson and C. Perkins, “Mobility Support in IPv6,” IETF Internet Draft, Jul. 2001, work in progress. [JSAC01] IEEE JSAC, issue on Active and Programmable Networks, 19(3), Mar. 2001. [KOODOO] R. Koodli and C. Perkins, “A Framework for Smooth Handovers with Mobile IPv6,” IETF Internet Draft, Jul. 2000, work in progress. [LAND99] B. Landfeldt, T. Larsson, Y. Ismailov, and A. Seneviratne, “SLM, A Framework for Session Layer Mobility Management,” in Proc. IEEE ICCCN, Oct. 1999. [LAP096] T. La Porta, “Distributed Processing for Mobility and Service Management in Mobile ATM Networks,” Wireless ATM Networking Workshop, Jun. 1996. [LAUB98] M. Laubach and J. Halpern, “Classical IP and ARP over ATM,” IETF RFC 2225, Apr. 1998. [LEVI97] D. Levine, I. Akyildiz and M. Naghshineh, “A Resource Estimation and Call Admission Algorithm for Wireless Multimedia Networks Using the Shadow Cluster Concept”, IEEE/ACM Trans, on Networking, 5(1), Feb. 1997. [LIU96] G. Liu and G. Maguire Jr., “A Class of Mobile Motion Prediction Algorithms for Wireless Mobile Computing and Communications,” ACM/Baltzer MONET, 1(2), 1996. [LIU98] T. Liu, P Bahl and I. Chlamtac, “Mobility Modeling, Location Tracking, and Trajectory Prediction in Wireless ATM Networks,” IEEE JAC, 16(6), Aug. 1998. References 182 [LUOO] W. Lu, “Compact Multidimensional Broadband Wireless: The Convergence of Wireless Mobile and Access,” IEEE Comm. Mag., Nov. 2000. [MAHAOO] I. Mahadevan and K. Sivalingam, “Architecture and Experimental Results for Quality of Service in Mobile Networks using RSVP and CBQ,” ACM/Baltzer Wireless Network, 6(3), Jul. 2000. [MALT98] D. Maltz and P. Bhagwat, “MSOCKS: An Architecture for Transport Layer Mobility,” in Proc. IEEE INFOCOM'98, Mar. 1998. [MANI99] P. Maniatis, M. Roussopoulos, E. Swierk, K. Lai, G. Appenzeller, X. Zhao and M. Baker, “The Mobile People Architecture”, Mobile Computing and Communications Review, July 1999. [MCCA99] P. McCann, T. Hiller, J. Wang, A. Casati, C. Perkins, and P. Calhoun, “Transparent Hierarchical Mobility Agents (THEMA),” IETF Internet Draft, Mar. 1999 (outdated). [MONT98] G. Montenegro, “Reverse Tunneling for Mobile IP,” IETF RFC 2344, May 1998. [MUNO90] D. Munoz-Rodrguez, “Cluster Paging for Traveling Subscribers,” Proc. IEEE Vehicular Tech. Conf., 1990. [NART98] T. Narten, E. Nordmark, and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” IETF RFC 2461, Dec. 1998. [NICHOl] K. Nichols, B. Carpenter, “Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification,” IETF RFC 3086, Apr. 2001. [NINJ] The Ninja Project, available at http://ninja.cs.berkeley.edu [OBSE] “Obsequieum - The Networked MP3 Jukebox,” information available at http://obs.freeamp.org/ References 183 [OLIV98] C. Oliveira, J. Kim and T. Suda, “An Adaptive Bandwidth Reservation Scheme for High-speed Multimedia Wireless Networks,” IEEE JSAC, 16(6), Aug. 1998. [PAJA99] A. Pajares, N. Nerier, L. Wolf and R. Steinmetz, “An Approach to Support Mobile QoS in an Integrated Services Packet Network,” in Proc. IQWiM Workshop, Apr. 1999. [PERK96] C. Perkins, ed., “IP Mobility Support for IPv4,” IETF RFC 2002, Oct. 1996. [PERKOO] C. Perkins and D. Johnson, “Route Optimization in Mobile IP,” IETF Internet Draft, Nov. 2000, work in progress. [PERKOl] C. Perkins, ed., “IP Mobility Support for IPv4, revised,” IETF Internet Draft, Jun. 2001, work in progress. [POLL97] G. Pollini and C. I, “A Profile-Based Location Strategy and Its Performance,” IEEE JSAC, 15(8), Oct. 1997. [PORT95] J. Porter and A. Hopper, “An overview of the ORL Wireless ATM System,” Proc. IEEE ATM Workshop, Sept. 1995. [RAJA96] B. Rajagopalan, “Mobility Management in Integrated Wireless-ATM Networks,” ACM/Baltzer MONET, 1(3), 1996. [RAMA99] P. Ramanathan, K. Sivalingam, P. Agrawal, and S. Kishore, “Dynamic Resource Allocation Schemes During Handoff for Mobile Multimedia Wireless Networks,” IEEE JSAC, 17(7), Jul. 1999. [RAMJOO] R. Ramjee, T. La Porta, L. Salgarelli, S. Thuel, K. Varadhan, and L. Li, “IP-based Access Network Infrastructure for Next-Generation Wireless Data Networks,” IEEE Pers. Commun. Mag., 7(4), Aug. 2000. [REDH] “RedHat Linux,” information available at http://www.redhat.org/ References 184 [REIN99] D. Reininger, R. Izmailov, B. Rajagopalan, M. Ott, and D. Raychaudhuri, “Soft QoS Control in the WATMnet Broadband Wireless System,” IEEE Pers. Commun. Mag., Feb. 1999. [RODR] M. Rodriguez, “An implementation of Mobile IP under Linux,” information available at http://www.hpl.hp.com/personal/Jean_ Tourrilhes/MobilelP/index.html [SALT84] J. Saltzer, D. Reed and D. Clark, “End-to-end Arguments in System Design,” ACM Trans. Comp. Sys., 2(4), Nov. 1984. [SARIOO] B. Sarikaya, “Packet Mode in Wireless Networks: Overview of Transition to Third Generation,” IEEE Comm. Mag., Sep. 2000. [SCHU96] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 1889, Jan. 1996. [SEN99] S. Sen, A. Bhattacharya, and S. Das, “A Selective Location Update Strategy for PCS Users,” ACM/Baltzer Wireless Networks, 5(5), Sep. 1999. [SHEN97] S. Shenker, C. Partridge and R. Guerin, “Specification of Guaranteed Quality of Service,” IETF RFC 2212, Sep. 1997. [SNOEOO] A. Snoeren and H. Balakrishnan, “An End-to-End Approach to Host Mobility,” ACM/IEEE Mobicom’OO, Aug. 2000. [S098] T. So, “Dynamic Bandwidth Management General Description,” ATM Forum 98-0209, Apr. 1998. [STEI96] S. Steinberg, “Netheads vs Bellheads,” Wired Mag., 4.10, Oct. 1996. [STEV94] W. Stevens, “TCP/IP Illustrated, Volume 1,” Massachusetts, Addison Wesley, 1994. References 185 [TALU99] A. Talukdar, B. Badrinath, and A. Acharya, “MRSVP: A Resource Reservation Protocol for an Integrated Services Network with Mobile Hosts,” to appear in ACM/WINET, May 1999. [TANE96] A. Tanenbaum, “Computer Networks,” Prentice-Hall Inc., Third Edition, 1996. [TEIT99] B. Teitelbaum, S. Hares, L. Dunn, R. Neilson, V. Narayan, and F. Reichmeyer, “Internet2 QBone: Building a Testbed for Differentiated Services,” IEEE Network, Sep. 1999. [TERZ99] A. Terzis, M. Srivastava, and L. Zhang, “A Simple QoS Signaling Protocol for Mobile Hosts in the Integrated Services Internet,” in Proc. IEEE INFOCOM’99, Mar. 1999. [TERZOO] A. Terzis, J. Krawczyk, J. Wroclawski, and L. Zhang, “RSVP operation over IP tunnels,” IETF RFC 2746, Jan. 2000. [THOM98] S. Thomson and T. Narten, “IPv6 Stateless Address Autoconfiguration,” IETF RFC 2462, Dec. 1998. [TOH96a] C-K Toh, “Performance Evaluation of Crossover Switch Discovery Algorithms for Wireless ATM LANs,” Proc. IEEE InfoCom’96, Mar. 1996. [TOH96b] C-K Toh, “A Hybrid Handover Protocol for Local Area Wireless ATM Networks,” Baltzer MONET, 1(3), 1996. [VATN98] J-0 Vatn and G. Maguire Jr., “The Effect of Using Co-Located Care- of-Addresses in Macro Handover Latency,” Fourteenth Nordic Tele traffic Seminar (NTS 14), Aug. 1998. [VEER97] M. Veeraraghavan and G. Dommetry, “Mobile Location Management in ATM Networks,” IEEE JSAC, 15(8), Oct. 1997. References 186 [WAN97] G. Wan and E. Lin, “A Dynamic Paging Scheme for Wireless Communication Systems,” Proc. ACM/IEEE MobiCom’97, Sep. 1997 [WANGOO] H. Wang, B. Raman, C-N Chuah, R. Biswas, R. Gummadi, B. Hohlt, X. Hong, E. Kiciman, Z. Mao, J. Shih, L. Subramanian, B. Zhao, A. Joseph, and R. Katz, “ICEBERG: An Internet Core Network Architecture for Integrated Communications,” IEEE Pers. Comm. Mag., Aug. 2000. [WANT92] R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The Active Badge Location System,” ACM Trans. On Info. Sys., 10(1), Jan. 1992. [WAVE] “Lucent Technologies WaveLAN/IEEE Software for Linux, version 6.00,” information available at http://www.wavelan.com. [WEDL99] E. Wedlund and H. Schulzrinne, “Mobility Support using SIP,” in Proc. ACM WoWMo’99, Aug. 1999. [WINS97] W. Winston, “Operations Research, Applications and Algorithms,” third edition, Duxbury Press, Jan. 1997, pp. 619-621. [WONGOO] V. Wong and V. Leung, “Location Management for Next-Generation Personal Communications Networks,” IEEE Network, Sep. 2000. [WROC97a] J. Wroclawski, “The Use of RSVP with IETF Integrated Services,” IETF RFC 2210, Sep. 1997. [WROC97b] J. Wroclawski, “Specification of the Controlled-Load Network Element Service,” IETF RFC 2211, Sept. 1997. [XIA099] X. Xiao and L. Ni, “Internet QoS: A Big Picture,” IEEE Network, Mar. 1999. [ZHONOO] R. Zhong, C. Tham, C. Foo, C. Ko, “Integration of Mobile IP and MPLS,” IETF Internet Draft, Jun. 2000 (Outdated). 187 List of Tables Table 1. The performance of various prediction algorithms on some indoor and outdoor movement traces...... 116 Table 2. Link Characteristics of wide area and wireless networks...... 146 Table 3. Performance of handover in the prototype implementation of Home-Proxy based framework...... 148 Table 4. Performance of macro-handover with and without advance resource reservation in the Home-Proxy based prototype implementation...... 152 Table 5. Performance of handover in the prototype implementation of WATM framework...... 162 Table 6. Performance of handover with and without advance resource reservation in the prototype implementation of WATM framework...... 163 188 List of Figures Figure 1. Layout of the thesis...... 7 Figure 2. The existing capabilities of ATM and IP networks versus the requirements of supporting mobile multimedia services...... 24 Figure 3. Protocol stack of the proposed WATM network...... 28 Figure 4. Operation of RSVP signalling in the IntServ architecture...... 33 Figure 5. Architecture of DiffServ model with the support of Bandwidth Broker...... 35 Figure 6. New capabilities provided by WATM soft QoS, IntServ and DiffServ frameworks...... 40 Figure 7. Typical connection rerouting schemes of Wireless ATM...... 56 Figure 8. The schematics of handover management in Wireless ATM...... 60 Figure 9. Triangle routing and reverse tunnelling in Mobile IP...... 66 Figure 10. New capabilities provided by the WATM mobility management and Mobile IP...... 71 Figure 11. An illustration of the necessity of micro-mobility management in IP networking...... 76 Figure 12. A brief comparison of the rerouting techniques being used in the Home- Proxy based and Mobile IP frameworks...... 86 Figure 13. Basic operations of SLM to establish a connection...... 89 Figure 14. Basic functions of HR and HP to deliver and redirect a connection...... 91 Figure 15. Macro- and micro-mobility management in the Home-Proxy based framework 93 List of Figures 189 Figure 16. Macro- and micro-reservation in the Home-Proxy based framework...... 94 Figure 17. An overall architecture of the Home-Proxy based framework...... 96 Figure 18. The capabilities of Home-Proxy based solution compared with other existing mobility and QoS frameworks...... 98 Figure 19. Various schemes of resource pre-allocation...... 103 Figure 20. Layout of the indoor movement traces at the office of ORL (UK)...... 109 Figure 21. Behaviour of users in the indoor movement traces 110 796056 Figure 22. Layout of one of the outdoor movement traces in Sydney...... Ill Figure 23. Various conventional prediction algorithms for user mobility...... 113 Figure 24. A brief illustration of the use of PCR...... 120 Figure 25. Applying different values of PCR to improve the prediction accuracy rate in the indoor movement traces...... 121 Figure 26. Applying different values of PCR to improve the prediction accuracy rate in the first outdoor movement traces...... 122 Figure 27. Applying different values of PCR to improve the prediction accuracy rate in the second outdoor movement traces...... 122 Figure 28. The schematics of advance marco- and micro-reservation in the Home-Proxy based framework using the concept of PCR...... 125 Figure 29. The schematics of advance reservation in the WATM framework using the concept of PCR...... 129 Figure 30. Enhancements of advance reservation to the Home-Proxy based and Wireless ATM frameworks...... 132 Figure 31. Layout of the prototype implementation of the Home-Proxy based framework...... 135 List of Figures 190 Figure 32. Software modules and components inside the prototype implementation of Home-Proxy based framework...... 138 Figure 33. Arrival rate of RTP packets under the influence of user mobility and network congestion...... 151 Figure 34. Layout of the prototype implementationof the WATM framework...... 155 Figure 35. Software modules and components inside the prototype implementation of WATM framework...... 158 191 List of Abbreviations 3G wireless The third-generation wireless system 4G mobile The fourth-generation mobile system AAL ATM Adaptation Layer ABR Available Bite Rate AF Assured Forwarding API Application Program Interface ARP Address Resolution Protocol ATM Asynchronous Transfer Mode BB Bandwidth Broker BS Basestation CBR Constant Bit Rate CH Corresponding Host COA Care-of-Address COS Crossover Switch CSIRO TIP CSIRO Telecommunication and Industrial Physics DiffServ Differentiated Services DHCP Dynamic Host Configuration Protocol DSCP DiffServ Code Point List of Abbreviations 192 EDGE Enhanced Data rate for GSM Evolution EF Expedited Forwarding EMAS End-user Mobility supporting ATM Switch FA Foreign Agent FIFO First-In-First-Out GSM Global System for Mobile Communications GPRS General Packet Radio Service HA Home Agent HP Home-Proxy HR Home Register HCC Handover Control Channel HLR Home Location Register IETF The Internet Engineering Task Force ISP Internet Service Provider IWD Interworking Device IMT-2000 International Mobile Telecommunications 2000 standard IntServ Integrated Services IP Internet Protocol iPOP ICEBERG Point of Presence IPv4 Internet Protocol version 4 List of Abbreviations 193 IPv6 Internet Protocol version 6 ITU International Telecommunication Union JNI Java Native Interface LA Location Area LR Location Register MAC Medium Access Control MAS Mobility Aware Switch emulated by Linux machine MH Mobile Host MF Classification Multiple-Field Classification MPA Mobile People Architecture NNI Network-Network Interface NSW RNO New South Wales Regional Network Organisation nrt-VBR Non-Real-Time Variable Bit Rate ORL Olivetti and Oracle Research Laboratory (UK) PCR Prediction Confidence Ratio PDB Per-Domain Behaviour PHB Per-Hop Behaviour PNNI Private Network-Network Interface PVC Permanent Virtual Circuit RED Random Early Detection List of Abbreviations 194 RSVP Resource Reservation Protocol RTP Real-Time Transport Protocol rt-VBR Real-Time Variable Bit Rate SIP Session Initiation Protocol SLA Service-Level Agreement SLM Session Layer Mobility Management SVC Switched Virtual Circuit TCP Transmission Control Protocol TOS Type of Service QoS Quality of Service UBR Unspecified Bit Rate UDP User Datagram Protocol UNI User-Network Interface UNSW The University of New South Wales (Australia) VC Virtual Circuit VCT Virtual Connection Tree VLR Visitor Location Register WATM Wireless ATM WIG Wireless Internet Gateway WSR Wireless Subnet Router