Figure 22.1. RSVP router [CHI 98]
Internet protocols as defined by the IETF1 have been designed for fixed networks. Used in mobile or wireless environments, their performance is greatly impacted.
Users expect a flexible access to Internet services which is not only limited to data services, but to multimedia services as well. This brings new problems for Quality of Service (QoS), since it must include terminal mobility. Different QoS architectures have been defined in the mobile networks context but none are considered as the complete solution for offering QoS in a mobile context.
The first efforts for an Internet access system through wireless networks have been developed by the telecommunications community where different systems had been proposed such as the GPRS (General Packet Radio Service) [ETSI 98] and the UMTS (Universal Telecommunication System) [KAA 00] systems. These systems are able to transport IP packets by using a packet switching network in parallel with the circuit switching phone network. These architectures use proprietary protocols and are subjected to strict licensing rules in terms of usage and price.
This chapter will identify interaction requirements between QoS and mobility architectures. To achieve this, a summary of QoS and mobility solutions will be presented, followed by a description of the problems linked with interaction between QoS and mobility. Finally, a few architectures supporting QoS and mobility will be presented.
In order to understand the interaction between QoS and mobility, a summary of these architectures is provided in this section.
since the Internet was not designed to support applications with QoS constraints such as telephony or video, the objective of manufacturers and thus of the IETF must be to attain a global architecture guaranteeing end-to-end QoS. IETF’s studies have arrived mainly at three basic architectures: the IntServ (Integrated Services) architecture, the DiffServ (Differentiated Services) architecture and the RTP (RealTime Protocol) architecture for real-time applications. Other options have been defined around these basic architectures, such as ISSLL (Integrated Service over Specific Link Layer) which defines IntServ architecture over DiffServ. More recently, MPLS (Multipath Label Switching) technology has opened a new approach to QoS control. Below is a brief presentation of the two basic architectures which are IntServ and DiffServ, as they are the ones with the most dependable interaction and mobility offerings.
QoS defines non-functional parameters of a system which affects QoS perceived by results [CHA 99]. In multimedia, it could mean the quality of an image or the speed of a response. Tables 22.1 and 22.2 below summarize the parameters linked to QoS technology and user respectively. The QoS requirements of the user are transformed in QoS technology parameters by QoS management tools. This is defined as a group of functions and mechanisms of supervision and control to ensure that the desired QoS level is in place and especially that it is maintained [CHA 99]. Two types of QoS management functions are identified: static and dynamic, respectively summarized in Tables 22.3 and 22.4 below. Static QoS management functions are applied at system start-up, whereas dynamic functions are applied, as much as possible, during system execution [CHA 99].
In IntServ [BRA 94] architecture, the objective is to provide circuit switching advantages on a packet switching network. In order to do this, the routers reserve resources for data flow. A route with the necessary resources is established between the transmitter and the receiver. These routes are refreshed periodically in order not to block resources indefinitely. New network elements are defined at router level as presented in Figure 22.1 to support the control for this architecture. Three levels of service are defined by IntServ architecture: Guaranteed Service (GS), Controlled Load (CL) and Best Effort (BE). The GS service guarantees that users will benefit from fixed bandwidth, fixed end-to-end delay and no packet loss. The CL service ensures that users will have a level of service close to Best Effort in a network that might be overloaded. And finally, the BE service is characterized by the absence of QoS: the network provides only the level of service that it can.
Table 22.1. Technological parameters of QoS [CHA 99]
| Category | Parameter | Description/Example |
|---|---|---|
Time |
Delay |
Necessary time for a packet to be transmitted |
Response time |
Round Trip Time (RTT), which is the necessary time for sending a packet and receiving confirmation |
|
Jitter |
Variation in the delay or response time |
|
Bandwidth |
System bandwidth |
Required or available bandwidth, which is measured in bit/s |
Application bandwidth |
Required or available bandwidth, which is measured in units specific to the application, e.g.: video sampling bandwidth |
|
Transaction throughput |
Number of operations required or executed per second |
|
Reliability |
Mean failure time (MFT) |
Time between two failures |
Mean repair time (MRT) |
Minimum time from failure to normal function |
|
Mean time between failures (MTBF) |
MTBF = MFT + MRT |
|
Percentage of available time |
MFT/ (MRT +MFT) |
|
Loss or error ratio |
Total proportion of data not received properly, e.g.: network error loss |
Table 22.2. User parameters of QoS [CHA 99]
| Category | Parameter | Description/Example |
|---|---|---|
Importance |
Priority |
An importance factor can be allocated to users, to multimedia traffic, etc. |
Perceived QoS |
Detail of an image |
Resolution in pixels |
Color accuracy |
Color information in pixels |
|
Video ratio |
Sampling ratio |
|
Video quality |
Jitter of samples |
|
Audio quality |
Ratio of audio sampling, number of bits |
|
Video/audio synchronization |
Video and audio flow synchronization; e.g.: synchronization of mouth movements |
|
Cost |
Cost by usage |
Cost of setting up a connection or of access to a resource |
Cost by unit |
Cost by unit of time or by unit of data, e.g.: Cost of a connection on a period basis or by rate of downloaded data |
|
Security |
Confidentiality |
Prevent access to information |
Integrity |
No modification of data sent |
|
Non-repudiation |
Ensure that the sender cannot deny having sent data. Use of signatures |
|
Authentification |
Prove identity of users |
Table 22.3. Static functions of QoS management [CHA 99]
| Function | Definition | Technique examples |
|---|---|---|
Specification |
QoS requirements and capability definition |
Requirements at different levels, user, environment, technology, application, etc. |
Negotiation |
Process to achieve a specification that will be accepted by all parties |
Modification of parameters after failure; these modifications must consider relations established between the parameters and user preferences |
Admission control |
Comparison of QoS requirements and capacity to reach these needs |
Available resources can be estimated according to reservation information and to performance models |
Resource reservation |
Allocation of resources to connections |
Techniques of network resource reservation (e.g.: RSVP) |
Table 22.4. Dynamic functions of QoS management [CHA 99]
| Function | Definition | Technique examples |
|---|---|---|
Supervision |
Measure of actual QoS provided |
Monitoring of the parameter in relation with the specification |
Control |
Ensure that all parties adhere to the QoS agreement |
Control of parameters which are in relation with the agreement |
Maintenance |
Modification of parameters by the system in order to maintain QoS |
Use of filter, queue in order to maintain the delay or throughput parameter |
Renegotiation |
Renegotiation of the agreement |
Necessary when the maintenance functions of the QoS can no longer respect the agreement |
Adaptation |
The application adapts to the system’s QoS changes; probably after a renegotiation |
Adaptation techniques at application level such as reduction of data output throughput if bandwidth decreases |
Synchronization |
Combination of multiple QoS multimedia flows with time constraints requires synchronization |
It is important to link time information of both multimedia flows that we wish to synchronize |
In order to establish this reservation of resources, signaling has been defined, which is based on the RSVP (ReSerVation Protocol) protocol [BRA 97]. Signaling can be used in other architectures apart from IntServ [WRO 93]; it proposes resource reservation by the receiver and it enables a dynamic control of the bandwidth. This protocol sits on top of the IP protocol and it uses unicast or multicast routing protocols to route the messages. Seven types of RSVP messages have been planned: Path, Resv, PathErr, PathTear, ResvTear, ResvConf (Optional). To support this architecture, the routers have been equipped with new mechanisms such as traffic classifier, admission controller and scheduler. The RSVP module in the router processes the RSVP request based on the QoS policy which is configured by the operator and, based on the availability of resources, accepts or rejects this request. Traffic is identified and classified in the corresponding service class. Finally, the scheduler provides the process corresponding to the service class by applying the corresponding scheduling algorithm.
In the resource reservation procedure, the transmitter first sends a PATH message to the receiver, specifying traffic characteristics. The message is updated for each router along the way. The receiver responds with a RESV message and indicates the necessary resources to support the appropriate traffic. A router on the route can reject the reservation request if it does not have enough resources to support the traffic. Reception of the RESV message by the transmitter confirms that the resources are available and have been reserved throughout the route.
The biggest problem with this architecture is scaling. Indeed, it is now important to maintain a data flow state, which can become very significant according to the increase of the number of flows in the network.
The DiffServ [BLA 98] architecture has been designed to deal with the IntServ architecture’s weakness in terms of scaling. The DiffServ architecture is based on flow aggregation and provides QoS by flow class. In this architecture, network routers are classified in two categories: edge routers and core routers. Input and output edge routers define a DiffServ Domain (DS). Processing complexity is pushed back to these edge routers. Three service classes are defined: Expedited Forwarding (EF), which provides a packet delivery guarantee in the assigned time, Assured Forwarding (AF) which defines four sub-classes and which provides a guaranteed service in terms of no loss of packets guarantee and Best Effort (BE) which offers no QoS guarantee. Each IP packet is marked by a DSCP (DiffServ Code Point) field; the packets are conditioned at DS domain input and are processed according to their level of service from core routers. The new functions of DiffServ edge routers are classification and conditioning of traffic as illustrated in Figure 22.2. The internal DiffServ routers to DS domain execute a particular behavior for each service class called Per Hop Behavior (PHB). The DSCP field of each packet determines at internal router level which PHB to apply. In IPv4, the DSCP field is provided by the unused ToS (Type of service) field. In IPv6, it is supplied by a new field in the header called FL (Flow Label). A new SLA (Service Level Agreement) concept has been introduced to describe the service contract between two DS domains or between a client and a DS domain. This SLA contains technical specification (Service Level Specification, SLS) which serves to configure DS routers in order to provide the level of service promised in the contract. The SLA also contains the administrative and legal contract specifications. In order to do this, the IETF has introduced the PDB (Per Domain Behavior) which only contains technical specifications, the PHB and the different necessary configurations to satisfy the SLA.
The high point of this architecture compared to the IntServ architecture is scaling, however, this architecture can only supply approximate QoS. Furthermore, the absence of signaling cannot provide a dynamic QoS.
In order to obtain end-to-end QoS guarantee as well as an architecture that is scalable, an architecture combining IntServ and DiffServ has been proposed by the ISSLL workgroup [BER 00]. The workgroup has proposed the use of IntServ at access network level and DiffServ at core network level. Since the access network can shrink to one node, the goal here is to combine the service guarantee offered by IntServ and scaling enabled by DiffServ in order to provide end-to-end QoS.
MPLS (Multi Path Label Switching) [PUJ 03] technology has brought a breath of fresh air to QoS architectures by enabling the reproduction of the advantages of a circuit switching network over a packet switching network like IP. This technology has been used alone or combined with other architectures such as DiffServ to ensure end-to-end service guarantee. Packets are marked during MPLS domain entry by a label and they are then switched instead of routed due to this labeling plan put in place by an IP control packet, which is itself routed by the IP routing plan.
In this section, we will present the foundation of mobility management in IP networks, as well as a description of architectures and protocols proposed by standardization organizations such as IETF or by academic institutions.
Studies that have been done to resolve the mobility problem in IP networks have resulted in two major directions. Macro mobility support and micro mobility support. Macro mobility is concerned with a shift between two different domains. Macro mobility can happen during an active mobile user session, or when a new session is launched by a domain user through a visited network, which is know as nomadism. Micro mobility means shifting between two points in the same domain. Basic functionalities of mobility management are mainly localization management and handover management. For this the following functions are all, or in part, necessary in the mobility management protocol [MAN 02]:
– authentification and authorization;
– packet transfer;
– route updates;
– handover management;
– inactive mobile device support;
– address management;
– security support.
The criteria of choice for mobility management protocol are mainly duration of handover and the rate of lost packets during handover procedure. We talk of smooth handover if a handover was handled with a minimum packet loss of fast handover if a handover was handled with a minimum delay and finally of seamless handover if a handover was handled with a minimum delay and minimum packet loss. The major problem with handover management in IP networks is that level 3 handover (network layer) happens only at the end of level 2 handover (link layer). This means that the mobile node has disconnected from its previous access router and has connected to a new access router but only at the physical level and it must wait for level 3 handover to happen in order to use the network’s resources. The objective is this time that separates the execution from level 2 to level 3. In order to do this, we must improve movement detection techniques at level 3 and attempt maximum synchronization the start of level 2 and level 3 handovers.
Proposed by the IETF, Mobile IP is the macro mobility support standard in IP networks [PER 97, PER 02] and its goal is to maintain the connection of the mobile node to the network while changing the attachment point. This is done in a transparent way to the higher TCP/IP layers pile as well as to the IP routing plan. In order to do this, it proposes a localization management mechanism and a mechanism for rerouting or packet transfer to the mobile destination.
Mobile IP defines a mobile source domain where there is a mobility agent HA (Home Agent) and a visited domain where this is a mobile agent FA (Foreign Agent).
The HA is responsible for maintaining location information of the mobile node which it updates regularly. It is also responsible for transferring the packets destined for the mobile node through an IP tunnel to the FA or the mobile node if the mobile node has a routable address (co-located CoA, CCoA which can be allocated by DHCP) or non-routable (Care of Address; CoA allocated by the FA). When the mobile node cannot obtain a new address from the HA or the DHCP, the FA will provide a new IP address in the visited domain and will transfer to the HA the registration request of the location sent by the mobile node. The FA is also responsible for the recovery of packets sent to the mobile node in the IP tunnel established by the HA and for transferring them to the mobile node.
The basic operation of Mobile IP is the same as for Mobile IPv4 and Mobile IPv6. However, due to IPv6’s new functionality, Mobile IPv6 has brought solutions to certain problems found in Mobile IPv4, such as triangular routing.
The mobile node, after obtaining its transient address (CoA or CCoA), will send a request to HA to register its new location. The HA keeps a correspondence between the permanent address of the mobile node which is linked to its HA (Home Address) and its CoA. The correspondent nodes of the mobile node send their traffic using its permanent address. The HA intercepts these packets and can redirect them toward the mobile node by constructing an IP tunnel [PER 96]. Encapsulated and redirected packets have an additional IP header which contains the mobile node’s CoA address as a destination address. The IP tunnel is established with the FA if the mobile node contains a CoA. In Mobile IPv4, we call this redirection a triangular routing. An enhancement of this routing has been proposed and called “route optimization” [PER 01], so that the mobile node can inform the corresponding node as well as the HA of its new location. This enables the sending of packets directly to the node corresponding to the mobile node. Unfortunately, this solution has had security problems that have been resolved in Mobile IPv6. Thus, in Mobile IPv6, triangular routing does not exist anymore. Furthermore, the FA is not needed since the mobile node can construct its own address which can be routable with the IPv6 addressing plan.
Mobile IP performance studies concerning moves between two base stations of one domain have revealed its inability to support this type of mobility called micro mobility [CAM 02, REI 03]. For this, other approaches have emerged from different studies such as hierarchic approaches (PAA: Proxy Agents Architectures), or localized routing modification-based approaches (LERS: Localized Enhanced Routing Schemes) [MAN 02]. In the first category we find hierarchical Mobile IP (HMIP) [CAS 00, MAL 00b] and Fast handball (FMIP) [MAL 00a and c] as well as other Mobile IP enhancements [MAL 01]. In the second category we will find Cellular IP [CAM 00b], HAWAII [RAM 00], Multicast-based approaches as well as ad hoc routing methods (MANET) [MAN 02].
This type of architecture introduces the hierarchy notion of mobile agents (FA and/or HA) to locate registration messages and to minimize the necessary time for the handover procedure.
One of the Mobile IP modifications is hierarchical Mobile IP [CAS 00] which proposes the improvement of Mobile IP performance in micro mobility. An FA is installed at the gateway of the visited network thus forming a GFA (Gateway Foreign Agent). This GFA is responsible for the regional registration procedure [GUS 01, MAL 00b] by hiding all movements within the visited network to the HA. The mobile node has a permanent address (home address) and a temporary address named CoA (Care of Address). The CoA is provided by the FA of the visited network. In this way, the HA keeps the correspondence between the permanent address (home address) and the CoA (GFA), the GFA keeps the correspondence between the local CoA and the CoA (GFA). The registration procedure is similar to the one for Mobile IP, the only difference is that the registration with HA is done only if the mobile node changes GFAs, if not, registration within the visited network is done after the GFA, which plays the role of a localized HA. Packets destined for the mobile node are redirected by the HA toward the GFA which then transmits them to the mobile node.
Another Mobile IP improvement is Fast Handoff [MAL 00a and c] which is an attempt to improve the HMIP handover delay even more in micro mobility. To achieve this, it proposes the improvement of movement detection procedure by using information from the link layer concerning the start of handover at level 2 (link layer). This information is used to anticipate level 3 handover and thus utilizes the network resources in the new cell as soon as possible after level 2 handover. For this, the mobile node will start its registration procedure with the new FA through the old FA even before level 2 handover is finished. Furthermore, a tunnel will be established between the old FA and the new FA in order to transmit the packets which continue to arrive to the old FA during handover. This is possible due to the “route optimization” mechanism. This cancels the triangular routing problem. In fact, the mobile node sends its new location to the HA at the same time as the corresponding nodes and in this way the corresponding nodes directly send their packets to the mobile node.
Other proposals have been introduced to improve the quality of handover in Mobile IPs such as Proactive Handover or Telemip [REI 03, TAN 99].
This micro mobility management approach introduces a dynamic routing in certain areas of the network. Three solution categories are identified [MAN 02]. Per host forwarding architectures, such as Cellular IP or HAWAII, Multicast and MANET (Mobile Ad hoc NETwork) based architectures.
Cellular IP [CAM 00b] was designed to replace IP in an access network. A Cellular IP domain is made up of MAs (Mobility Agents) where one is a gateway to the Internet and acts as an FA and executes Mobile IP. Each MA contains a routing cache which contains the next node toward the mobile node and an entrance to reach the gateway. This cache is used by the MA to transfer packets from the gateway to the mobile node or from the mobile node to the gateway. Routes are established and maintained with the transmission of two control packets. A beacon message periodically floods the network by the gateway in order to create the route to the gateway for all MAs. The route update packet is sent by the mobile node to its first connection to the network when it changes adherence point but usually periodically. These packets are transferred hop by hop to the gateway creating or updating the entries in each MA’s routing cache. Cellular IP proposes two types of handover: Hard Handover where the node sends a route update packet to the gateway after level 2 handoff and the semi-soft handoff where the node uses the information of the link layer concerning the advent of a level 2 handoff. In this case the mobile node requires the start of bicasting toward the old and the new cell in order to minimize packet loss. Furthermore, Cellular IP proposes to support passive connectivity (paging) by using a paging cache.
Other proposals based on dynamic routing similar to Cellular IP, such as HAWAII, have been introduced.
Multicast architectures have been designed to support point-to-multipoint connections independently of the location, addressing and routing. This type of architecture has proven to be adequate for mobility support. In the multicast-based architecture proposal for mobility support, the mobile node will have a multicast-CoA address. The mobile node can request to join its multicast group either before or after handover from its neighboring access networks. Dense mode multicast and sparse mode multicast are examples of multicast proposals for mobility support [MAN 02, MYS 97, MIH 00].
Finally, the MANET architectures for mobility management such as MER-TORA [MAN 02] have been proposed. MANET protocols have been designed for ad hoc network support where the mobile node and the routers are mobile. In the case of mobility management, it is considered that the access network part is the ad hoc part that is fixed and only the terminals are mobile. Therefore, the ad hoc approach applies in this case as well.
Figure 22.9 below summarizes the different mobility support proposals in IP networks.
The interaction between QoS management and IP networks mobility is still difficult as these two controls have evolved separately from each other. Indeed, studies done in the maintenance and control of QoS domains have been more involved with cable networks than mobile networks. Major problems that can be encountered by the QoS management process are mainly due to the network topology, to user macro mobility and micro mobility.
Depending on the access points between which the mobile node moves, the type of handover is different and consequently signaling rate in the access network will be different. The deeper the handover in the access network topology, the longer the reestablishment of the end-to-end QoS in the mobile node’s new location. Different handover types are defined whether they are limited to an access router (Intra Access Router), to two access routers in one gateway (Access Network Gateway), to a same domain (Inter Access Router), to different gateways but from a single domain (Inter Access Network Gateway), or still to different domains (Inter Access Domain). Figure 22.10 below illustrates these different handovers.
In the case of IntServ architecture, RSVP has a problem guaranteeing reservation since the reservation, routing and data transmission functions are independent [MAN 02]. During handover, the route changes and the packets can only receive a Best Effort service level until the route is updated by periodic PATH and RESV messages from the RSVP protocol. This problem is much more significant if the handover is deep and requires more time to update QoS, which causes a bigger degradation of the level of service.
In the case of DiffServ architecture, as there is no signaling mechanism, mobile node traffic disrupts the sharing of resources for other mobile devices which are already connected in the cell. It is necessary to have a resource controller (bandwidth broker) in order to regulate resource sharing within DiffServ.
In the case of Intra Access Router handover, the route to ANG does not change since this type of handover, called level 2 or radio handover, only affects radio resource; it is transparent to superior layers. The access control is therefore not necessary. In the case of Inter ANG handover, the ARs change during handover. In this case, the handover affects availability of radio resources as well as those of the access network. Moreover, the new access router must use access control. In the case of Inter ANG handover, mobility has a significant impact on resource coordination. First, the mobile device needs a new IP address. Then, QoS must be affected until route refresh by the RSVP and finally, the most complex handover is the one that requires the change of the administrative domain. In addition to the basic operations linked to mobility (new IP address, packet re-routing), the mobile device needs to authenticate again to be authorized to use the resources of the new domain. This causes signaling traffic overload which can affect the delay of recovery of mobile device resources.
Macro mobility requires a more significant delay of route recovery than micro mobility. In addition to the control operations for localization or rerouting, other operations such as reauthentification or authorization to use resources can be necessary. Recovery and reconfiguration of QoS on the new route also require some time to set up. This is in addition to the necessary time for macro mobility. Other factors such as mobile device speed or the number of active mobile devices in the network cause an overload of the network during control packet traffic. Another problem concerns address management. Indeed, as the mobile device changes IP addresses, end-to-end QoS architectures such as IntServ require that the whole reservation operation over end-to-end route must be redone. This will result in a significant waiting time before QoS recovery, which will affect QoS guarantee.
In such architectures as Mobile IPv4, certain procedures are particularly problematic for QoS recovery. For example, triangular routing causes a problem in most QoS architectures because the arriving packet route (downstream) to the mobile device (by the IP tunnel) is different from the route of packets exiting the mobile device toward the network (upstream). A solution has been proposed, Reverse Tunneling [MON 01], for using the same route for packets entering and exiting the mobile node. In this case, triangular routing is avoided. However, the routers in the IP tunnel are incapable of knowing the QoS parameters specified in the IP header. Indeed, the only information available through the IP tunnel is the IP address. For example, in the case of an encapsulated RSVP message in the IP tunnel, with the Router Alert field used to indicate to the routers that the traffic requires specific QoS, this field unfortunately cannot be picked up by the routers due to the IP tunnel. Multiple solutions have been suggested to solve this problem; however, they increase the complexity of QoS management in the mobile world.
In the case of Mobile IPv6, problems such as triangular routing or Tunneling are resolved with Route Optimization [PER 01] for the former and with Routing Header for the latter [JOH 01]. This last one reduces network overload due to IP Tunneling elimination. In addition, a movement detection mechanism is integrated in order to enable a better performance during handover. In fact, the detection of a movement of mobile device promptly launches the Mobile IP procedure more quickly and minimizes handover time. Despite Mobile IPv6’s willingness to reach transparency and handover support objectives, this protocol remains non-optimized to offer a Seamless Handover control (minimum delay and minimum loss) in a cellular network supporting real-time applications. This is caused by the large number of localization registrations and of the route recovery latency after handover.
Movement of nodes within a same domain (micro mobility) generally affects QoS architectures according to the IP encapsulating, tunneling, multicast or dynamic routing used. In the IntServ architecture, each router keeps a state by flow. In this way, the movement of the mobile device launches routing localized repairs as well as resource reservations in the network.
In a DiffServ architecture that has no signaling mechanism (no state to update), the service level provided varies according to the number of mobile devices arriving or leaving a cell.
The interaction between QoS and micro mobility must consider the following points [MAN 02]:
– the use of IP tunneling hides the header information of the packet which affects the classification of this packet;
– the change of CoA address during the session affects the recovery time of the route and the necessary resources;
– packet multicast over multiple routers consumes a lot of network resources;
– the use of fixed routes using the same gateway to outside networks is not scalable;
– adaptability to route changes is necessary;
– finding an optimal route from gateway to the access routers;
– routing support based on QoS.
Improvements have been proposed in order to better support IP address changes and also to support IP Tunneling in IntServ [TER 00] and in DiffServ [BLA 00] but these proposals do not essentially resolve the problems described earlier.
In this section, we present some solutions recommended by the IETF and by the academic community for the problems regarding the interaction between QoS and mobility. The final goal is to combine management of macro mobility, micro mobility and QoS for end-to-end guarantee of service in mobile device networks. Two methods are possible based on the transport mode of signaling, which can be either separately transported by data packets (out-band signaling) or transported in data packets (in-band signaling).
Interaction between QoS and micro mobility can be handled in different ways depending on whether resource reservation is done at the end of handover, during handover, at the same time as handover or before handover.
In an architecture such as DiffServ, it is possible to put an admission control mechanism in place that will limit Best Effort traffic so that not all leftover resources will be used and also to reserve a part of the resources to support traffic for arriving mobile nodes. In order to do this, it is not necessary to install new devices, admission control rules just need to be applied for network access routers in order to limit traffic in each service class. Furthermore, we must use a priority mechanism to take into account mobile device traffic during handover as well as mobile device traffic which starts a new session in the cell. This technique is applied to cellular networks within telecommunication networks [MAN 02]. The problem is to know the proportion of the bandwidth in order to reserve for priority and non-priority traffic [MAN 02].
The simplest approach for combining QoS and mobility management is to execute them separately. Indeed, during handover, mobility management is executed and after this execution, the QoS management procedure can start to restore resources on the new route established by the mobility management procedure. In the case of RSVP, route changes are taken over by the soft-state character of the reservation. RSVP contains a periodic refresh of the route mechanism which enables the repair of a route or a portion of the route depending on the depth of the handover.
The problem with this approach is that the service may see a degradation of service during the length of time RSVP needs to restore QoS on the new route. If the refresh message is generated before the complete restoration of the new mobile device route, there may be resource reservations on a route that does not correspond to the one for the mobile device. This route unfortunately will not be corrected before the next refresh message. In certain cases, the reservation can be rejected for lack of resources on one of the routers on the new route for the mobile device. Finally, this resource reservation disruption may happen as often as the number of times the mobile node changes access routers, even during a same RSVP session. This solution provides a very poor global QoS in the network.
In this approach, events generated by the mobility management procedure launch the resource reservation process of the QoS management procedure. The RSVP reservation mechanism is launched as soon as the new route is established. It is called Local Path Repair mechanism and is defined in the RSVP specifications; this option minimizes service disruption time between the start of handover until restoration of resources on the new route. It also avoids the execution of resource reservations in the network before information concerning the new mobile device route is available. Restoration delay for the new route can also be minimized by localizing reservation repair where the route has changed, i.e. between the Crossover router shown in Figure 22.11 and the new access router [MAN 02]. However, in the case of a new QoS negotiation, end-to-end signaling process is inevitable. In addition, the old route must be explicitly freed.
One of the problems of this approach is the complexity introduced in the network to intercept the RSVP message in order to limit repair in the area between the Crossover router and the mobile device. Furthermore, the fact that the RSVP mechanism is launched by events linked to mobility generates more significant signaling than what would happen in the case of a reservation independent from mobility where the RSVP procedure is launched only by refresh messages.
In the case of proxy agent-based mobility management, the event that will launch the RSVP procedure is receiving of a new location registration ACK. In the case of MANET-based mobility management, receiving the Route Update message is what will launch the RSVP procedure. Finally, in management based on localized routing modification, as soon as the routing information is distributed in the network, the RSVP procedure is launched.
This approach proposes the use of unified QoS and mobility signaling. This is possible either by extension of existing QoS or mobility signaling or by QoS routing. The goal of this approach is to minimize service disruption time by ensuring that the QoS will be in place as soon as possible since QoS parameters are propagated at the same time as the start of handover. The idea of this approach is to install resource reservations at the same time as route update. Thus, it avoids the execution of reservations before the end of propagation of the new route. It also avoids executing them after the end of the route update procedure as in the approach presented earlier. It also enables the installation of multiple reservations by using the same signaling message. Generated signaling traffic can then be decreased as in previously discussed approaches. Reservation repair may also be located, except in the case where a new end-to-end reservation is required. Resources of the old route should be explicitly freed.
The main problem with this approach is first of all processing the complexity introduced in the network nodes and also the need to transport QoS information by micro mobility management mechanisms. In certain cases, new messages are necessary to ensure this function. New protocols may be necessary to unify QoS and mobility signaling.
In proxy agent approaches, QoS parameters are transported in the localization registration message. An integration attempt of QoS with Mobile IPv6 is proposed in [CHA 01]. A new QoS Object Option is introduced in IPv6 for use in Mobile IPv6 localization registration messages. These are sent to corresponding nodes or to mobility agents. In the approach proposed by the MANET Group, QoS information is transported in the route update messages. In the routing modification approach, QoS information is transported by the path set-up and refresh messages. Finally, knowing QoS needs during handover makes it possible to choose the next cell that responds to these needs.
In order to reach a guarantee of service independent from mobility, the techniques presented previously, such as access control, priority, integration of QoS signaling into mobility signaling are not sufficient. The mobile node needs to execute resource reservation of cells that it can visit during its route. Two approaches are presented next, one applies to the IntServ architecture (MRSVP) and the other applies to the DiffServ approach (ITSUMO).
Mobile RSVP [TAL 98] is a reservation in advance protocol in the IntServ architecture in a network that supports mobile nodes. It proposes three levels of service for mobile users: Mobility Independent Guarantees (MIG), Mobility Independent Predictive (MIP) and Mobility Dependent Predictive (MDP). The MIG services offer guaranteed service to the mobile device, MIP offers a predictive service and MDP is a predictive service with high probability but which can be deteriorated in certain circumstances. Two reservation types are possible: passive and active reservations. Active reservations are launched by the mobile node in the cell where it is located, whereas passive reservations are executed at locations where the mobile node could visit. These are described in the MSPEC (Mobility Specification) object. This localization list can be approximately determined by the network during movement of the mobile device or simply expressed by the mobile device that knows its route. New localizations can be added to MSPEC and passive reservations are also executed. Resources passively reserved by mobile devices can be used by other lower quality traffic such as Best Effort. As soon as the mobile devices become active, resources are recovered which can affect the QoS of the flows using them. A unicast packet is sent by using Mobile IP routing. Reservation is all done through the IP tunnel route established by the Mobile IP.
ITSUMO (Internet Technologies Supporting Universal Mobile Operation) architecture [ITS] is founded on DiffServ. It defines a group of domains. Each domain has a QoS Global Server (QGS) and local QoS servers (QLN, QoS Local Node). Resource reservation is not done by the mobile device but by the QGS server. When it arrives in a domain, the mobile device interacts with QGS by negotiating a Service Level Specification (SLS) in a dynamic manner, by specifying its reservation requirement and by signaling its mobility profile. Based on negotiated service level information (SLS), the QGS calculates the mobility model and the bandwidth to reserve for all cells of the mobile device’s domain. It then sends this configuration to local QoS servers (QLN). The QGS regularly updates the QLNs in order to include mobile device reservations that may be visited. However, this approach could be more efficient if there were passive reservations or a handover guard band mechanism [MAN 02]. The protocol used to put in place this SLS negotiation signaling and reservation request is DSNP (Dynamic Service Negotiation Protocol) [CHE 01]. The difference with the MRSVP approach is that the reservation must not be signaled by the mobile device itself for each access router that is in the mobility profile; it is the responsibility of the QGS to execute this reservation instead of the mobile node.
The goal of resource reservation is to guarantee a level of service to mobile users; however, it is not an optimized use of network resources. In order to solve this problem, a new approach proposes asking neighboring cells for the availability of their resources and informing them of QoS requirements before handover. To do this, a specific architecture is defined, called Context Transfer Framework [SEA]. In this architecture, each access router maintains a context of the mobile node. Within the context, characteristics are defined such as QoS or security. These parameters are linked to the processing of mobile device traffic at access router level, where the mobile device is located. During movement of mobile device from one cell to another, this context is transferred to the new cell during handover in order to prepare QoS in the new cell. No other signaling is necessary for QoS since the process corresponding to mobile device traffic is already in place in the new cell, due to context transfer from the mobile device. Initially, context transfer was designed for the communication between access routers to recover QoS in the new cell. The goal for the extensions of this architecture is the communication between access routers and gateways to recover QoS over the route by sending the context of the mobile device to all routers up to the gateway [MAN 02].
Contrary to out-band signaling which uses specific control packets, the INSIGNIA architecture (INband SIGnaliNg support for QoS In Ad hoc networks) uses data packets to transport QoS signaling, from which we get the name in-band signaling [LEE 02]. In-band signaling is well adapted to support end-to-end QoS and mobility in dynamic environments where network topology and node connectivity are very dynamic. INSIGNA supports reservation, rapid restoration and end-to-end adaptation based on IP robustness and flexibility.
The third generation of mobile systems (3G Mobile Telecommunication Systems) represents the evolution of the mobile telephony system to provide multimedia services over cellular networks [3GPP]. A packet switching network is added as a core network in 3G networks to transport application IP packets. Mobile nodes are connected at the core network by radio interfaces. From the core network, packets can reach the Internet network. Concerning mobility and QoS management, 3G systems propose three types of mobility: terminal mobility, which corresponds to the one defined in IP networks, personal mobility whose goal is to deliver services to users independently from their network or access terminal and finally services mobility. Terminal mobility support, at IP backbone level, Mobile IP is considered an important candidate for mobility management. However, at access network level, proprietary solutions are now recommended. Concerning QoS, four service classes have been defined: conversational, streaming, interactive and background [3GPP].
ISO (International Standard Organization) and ITU (International Telecommunication Union) have a common workgroup whose goal is to define a reference model for ODP (Open Distributed Processing) systems [BLA 97]. This group is working on the design of an architecture for QoS support. However, this architecture is not considering the mobility aspect. The ODP group has developed CORBA (Common Object Request Broker Architecture) architecture which can serve as support for mobility management. Functionalities necessary for QoS have been introduced in version 3.0; the mobility aspect is more difficult to integrate [CHA 99].
Other works deal with adaptability support, which is concerned with application layers. Indeed, adaptability support is critical in wireless and mobile environments. An example for adaptability is proposed by the TCP protocol which uses an adaptability mechanism, slow start, which can react to the state of the network. Another example comes from the RTP (Real-time Protocol) protocol used to support real-time applications. This protocol notifies the application of the state of the network so that the application can adapt to the constraints of the network by reducing generated traffic, for example [SCH 96].
The road toward a definitive and operational end-to-end QoS guarantee architecture in mobile and wireless environments is still long and riddled with challenges. In fact, current studies only partially resolve the problems. Some propose solutions for mobility problems, others resolve QoS problems and more recently some have combined QoS and mobility. Concerning mobility, the biggest challenge is to resolve such problems as localization management or optimal control of handover quickly in order to avoid disruption of the current service. Concerning QoS, the focus has to be on offering a better service to users with a minimum of resources in the network in order to increase profit for network and service operators. In the mobile context, maintaining QoS means recovering its configuration in the new mobile device location as fast as possible. Finally, the goal of the interaction between QoS and mobility is to launch a QoS configuration procedure by events linked to mobility. This can be done in different ways as presented in this chapter. The main idea is to execute resource reservations in advance of the handover, during handover, after handover, or at the same time as handover. Each technique has its advantages and its disadvantages. It is necessary to combine these different techniques and to put a dynamic mechanism in place which can choose the execution of one of them for each type of traffic. The underlying idea is to provide a dynamic QoS control in the network. This should be accompanied by adaptability of services and critical functionality in dynamic areas as is the case in mobile and wireless networks. Finally, good network provisioning, good traffic engineering and dynamic QoS management are necessary for the realization of QoS based mobile networks.
[3GPP] 3GPP Third Generation Partnership Project, http://www.3gpp.org.
[ALW 93] ELWALID A. I., MITRA D. “Effective Bandwidth of General Markovian Traffic Sources and Admisssion Control of High-Speed Networks”, IEEE/ACM Transactions on Networking, vol. 1, no. 3, p. 329-343, June 1993.
[AWD 97] AWDUCHE D. O., AGU E., “Mobile Extensions to RSVP”, proceedings of ICCCN’97, Las Vegas, NV, p.132-136, September 1997.
[BER 00] BERNET Y. et al., “A Framework for Integrated Services Operation over DiffServ Networks”, Internet Engineering Task Force, Request for Comments (RFC) 2998, November 2000.
[BLA 97] BLAIR G., STEFANI J.-B., Open Distributed Processing and Multimedia, Addison-Wesley, 1997.
[BLA 98] BLAKE S., BLACK D., CARLSON M., DAVIES E., WANG Z., WEISS W., “An Architecture for Differentiated Services”, Internet Engineering Task Force, Request for Comments (RFC) RFC 2475, December 1998.
[BLA 00] BLACK D., “Differentiated Services and Tunnels”, Internet Engineering Task Force, Request for Comments (RFC) 2983, October 2000.
[BRA 94] BRADEN R., CLARK D., SHENKER S., “Integrated Services in the Internet Architecture: an Overview”, Internet Engineering Task Force, Request for Comments (RFC) 1633, June 1994.
[BRA 97] BRADEN R., ZHANG L., BERSON S., HERZOG S., JAMIN S., “Resource reSerVation Protocol (RSVP) – Version 1, Functional Specification”, Internet Engineering Task Force, Request for Comments (RFC) 2205, September 1997.
[CAM 00a] CAMPBELL A. T., GOMEZ J., “IP Micromobility Protocols”, ACM Mobile Comp. and Commun. Review, vol. 4, no. 4, October 2000.
[CAM 00b] CAMPBELL A. T. et al., “Cellular IP”, Internet draft, draft-ietfmobileip-cellularip-00.txt, January 2000.
[CAM 02] CAMPBELL A. T. et al., “Comparison of IP Micromobility Protocols”, IEEE Wireless Commun., vol. 9, no. 1, February 2002.
[CAS 00] CASTELLUCCIA C., BELLIER L., “Hierarchical Mobile IPv6”, Internet draft, draft-castelluccia-mobileip-hmipv6-00.txt, July 2000.
[CHA 99] CHALMERS D., SLOMAN M., “A Survey of Quality of Service in Mobile Computing Environment”, IEEE Communication Surveys, second quarter 1999.
[CHA 01] CHASKAR H., KOODLI R., “A Framework for QoS Support in Mobile IPv6: Another In-Band Approach Introducing a QoS Hop-by-Hop Option in Mobile IPv6”, Internet draft, March 2001.
[CHE 01] CHEN J. C. et al., “Dynamic Service Negotiation Protocol (DSNP)”, Internet draft, July 2001.
[CHI 98] CHIMENTO P., “Tutorial on QoS Support for IP”, technical report 23, http://ing.ctit.utwente.nl, 1998.
[ETSI 98] European Telecommunication Standard Institute, “General Packet Radio Service (GPRS), Service description, Stage 2”, Technical Report ETSI, digital cellular telecommunications system (Phase 2+), TS 101 344 v7.7.0, ETSI, June 2001, 3GPP TS 03.60 version 7.7.0 released 1998.
[GUS 01] GUSTAFSSON E., JONSSON A., PERKINS C., “Mobile IP Regional Registration”, Internet draft, draft-ietf-mobileip-reg-tunnel-04.txt, March 2001.
[ITS] ITSUMO Group, “A reference Architecture for All IP Wireless Networks”, 3GPP2, http://www.3gpp2.org.
[JOH 01] JOHNSON D., PERKINS C., “Mobility Support in IPv6”, Internet draft, 2001.
[KAA 00] KAARANEN et al., UMTS Network: Architecture, Mobility and Services, John Wiley, Chichester, UK, 2000.
[LEE 00] LEE et al., “INSIGNIA: An IP-Based Quality of Service Framework for Mobile Ad-Hoc Networks”, Journal of Parallel and Distributed Computing, vol 60, no. 4, p. 374-406, April 2000.
[MAL 00a] EL MALKI K., SOLIMAN H., “Fast Handoffs in Mobile IPv4”, Internet draft, draft-elmalki-mobileip-fasthandoffs-03.txt, September 2000.
[MAL 00b] MALINEN J., PERKINS C., “Mobile IPv6 Regional Registrations”, Internet draft, draft-malinen-mobileip-regreg6-00.txt, July 2000.
[MAL 00c] EL MALKI K., SOLIMAN H., “Hierarchical Mobile IPv4/v6 and Fast Handoffs”, Internet draft, draft-elmalki-solimanhmipv4v6- 00.txt, March 2000.
[MAL 01] EL MALKI K. (Ed.) et al., “Low Latency Handoff in Mobile IPv4”, Internet Draft, draft-ietf-mobileip-lowlatency-handoffsv4-01.txt, May 2001.
[MAN 02] MANNER J., LÓPEZ A., MIHAILOVIC A. et al., “Evaluation of Mobility and QoS Interaction”, Computer Networks, vol. 38, no. 2, p. 137-163, February 2002.
[MIH 00] MIHAILOVIC A., SHABEER M., AGHVAMI A. H., “Multicast for Mobility Protocol (MMP) for Emerging Internet Networks”, in Proceedings of PIMRC2000, London, September 2000.
[MON 01] MONTENEGRO G., “Reverse Tunneling for Mobile IP”, revised, Internet Engineering Task Force, Request for Comments (RFC) 3024, January 2001.
[MYS 97] MYSORE J., BHARGHAVAN V., “A New Multicasting-based Architecture for Internet Host Mobility”, Proceeding of ACM Mobicom, September 1997.
[PER 96] PERKINS C., “IP Encapsulation within IP”, Internet RFC, RFC 2003, October 1996.
[PER 97] PERKINS C. E., “Mobile IP”, IEEE Commun. Mag., vol. 35, no. 5, p. 84-99, May 1997.
[PER 01] PERKINS C., JOHNSON D., “Route Optimization in Mobile IP”, Internet draft, draft-ietf-mobileip-optim-11.txt, September 2001.
[PER 02] PERKINS C. ED., “IP Mobility Support for IPv4”, Internet RFC, RFC 3220, January 2002.
[PUJ 03] PUJOLLE G., Les réseaux, Eyroles, 2003.
[RAM 00] RAMJEE R. et al., “IP Micro-Mobility Support using HAWAII”, Internet draft, draft-ietf-mobileip-hawaii-01.txt, July 2000.
[REI 03] REINBOLD P., BONAVENTURE O., “IP Micro-Mobility Protocols”, IEEE Communication, Surveys, vol. 5, no. 1, 2003.
[SCH 96] SCHULZRINNE H., CASNER S., FREDERICK R., JACOBSON V., “RTP: A Transport Protocol for Real-Time Applications”, Internet Engineering Task Force, Request for Comments (RFC) 1889, January 1996.
[SEA] IETF SEAMOBY WORKING GROUP, http://www.ietf.org/html.charters/seamoby-charter.html.
[TAL 98] TALUKDAR A., BADRINATH B., ACHARYA A., “MRSVP: A Resource Reservation Protocol for an Integrated Services Packet Network with Mobile Hosts”, in Proceedings of ACTS Mobile Summit’98, June 1998.
[TAN 99] TAN C., PINK S., LYE K., “A Fast Handoff Scheme for Wireless Networks”, Proceedings of the 2nd ACM International Workshop on Wireless Mobile Multimedia, ACM, August 1999.
[TER 00] TERZIS A., KRAWCZYCK J., WROCLAWSKI J., ZHANG L., “RSVP Operation Over IP Tunnels”, Internet Engineering Task Force, Request for Comments (RFC) 2746, January 2000.
[WRO 97] WROCLAWSKI J., “The Use of RSVP with IETF Integrated Services”, Internet Engineering Task Force, Request for Comments (RFC) 2210, September 1997.
1 Chapter written by Hakima CHAOUCHI.
1 Internet Engineering Task Force. www.ietf.org.
