Chapter 4. WIRELESS INTERNET

4.1 INTRODUCTION

The advent of the Internet has caused a revolutionary change in the use of computers and the search for information. The Internet has affected the traditional way of information exchange and now almost every city, every town, and every street has access to the Internet. Some basic concepts about the Internet and some fundamental issues that are encountered when a transition is made from the wired domain to the wireless domain and the MobileIP framework are discussed. Some of the problems faced during a transition from the wired domain to the wireless domain arise due to the fact that the protocols that work very well in the former may perform poorly in the latter. TCP is a perfect example of this. The key issues involved in TCP for wireless networks and an analysis of the current set of proposals to enhance the performance of TCP in the wireless domain are also presented. The classical wired networks have given rise to a number of application protocols such as TELNET, FTP, and SMTP. The wireless application protocol (WAP) architecture aims at bridging the gap at the application level, between the wireless users and the services offered to them.

4.2 WHAT IS WIRELESS INTERNET?

Wireless Internet refers to the extension of the services offered by the Internet to mobile users, enabling them to access information and data irrespective of their location. The inherent problems associated with wireless domain, mobility of nodes, and the design of existing protocols used in the Internet, require several solutions for making the wireless Internet a reality. An illustration of wireless Internet with its layered protocol stack at wired and wireless parts is shown in Figure 4.1. The major issues that are to be considered for wireless Internet are the following.

• Address mobility

• Inefficiency of transport layer protocols

• Inefficiency of application layer protocols

Figure 4.1. An illustration of wireless Internet.

4.2.1 Address Mobility

The network layer protocol used in the Internet is Internet protocol (IP) which was designed for wired networks with fixed nodes. IP employs a hierarchical addressing with a globally unique 32-bit address¹ which has two parts, network identifier and host identifier, as shown in Figure 4.2 (a). The network identifier refers to the subnet address to which the host is connected. This addressing scheme was used to reduce the routing table size in the core routers of the Internet, which uses only the network part of the IP address for making routing decisions. This addressing scheme may not work directly in the wireless extension of the Internet, as the mobile hosts may move from one subnet to another, but the packets addressed to the mobile host may be delivered to the old subnet to which the node was originally attached, as illustrated in Figures 4.2 (b) and 4.2 (c). Hence the traditional IP addressing is not supportive of address mobility which is essential in wireless Internet. Figure 4.2 shows the mobility of a node (with IP address 10.6.6.1) attached to subnet A (subnet address 10.6.6.x) moving over to another subnet B with address 10.6.15.x. In this case, the packets addressed to the node will be routed to the subnet A instead of the subnet B, as the network part in the mobile node's address is 10.6.6.x (see Figure 4.2 (c)). MobileIP² is a solution that uses an address redirection mechanism for this address mobility issue in wireless Internet.

¹ The recently introduced IP Version 6 has a 128-bit address.

² Throughout this chapter, Mobile IP refers to the mobility aspect of IP address and MobileIP refers to one particular solution for Mobile IP.

Figure 4.2. The address mobility problem.

4.2.2 Inefficiency of Transport Layer Protocols

The transport layer is very important in the Internet as it ensures setting up and maintaining end-to-end connections, reliable end-to-end delivery of data packets, flow control, and congestion control. TCP is the predominant transport layer protocol for wired networks, even though UDP, a connectionless unreliable transport layer protocol, is used by certain applications. Wireless Internet requires efficient operation of the transport layer protocols as the wireless medium is inherently unreliable due to its time-varying and environment-dependent characteristics. Traditional TCP invokes a congestion control algorithm in order to handle congestion in the networks. If a data packet or an ACK packet is lost, then TCP assumes that the loss is due to congestion and reduces the size of the congestion window by half. With every successive packet loss the congestion window is reduced, and hence TCP provides a degraded performance in wireless links. Even in situations where the packet loss is caused by link error or collision, the TCP invokes the congestion control algorithm leading to very low throughput. The identification of the real cause that led to the packet loss is important in improving the performance of the TCP over wireless links. Some of the solutions for the transport layer issues include indirect-TCP (ITCP), snoop TCP, and mobile TCP.

4.2.3 Inefficiency of Application Layer Protocols

Traditional application layer protocols used in the Internet such as HTTP,³ TELNET, simple mail transfer protocol (SMTP), and several markup languages such as HTML were designed and optimized for wired networks. Many of these protocols are not very efficient when used with wireless links. The major issues that prevent HTTP from being used in wireless Internet are its stateless operation, high overhead due to character encoding, redundant information carried in the HTTP requests, and opening of a new TCP connection with every transaction. Wireless bandwidth is limited and much more expensive compared to wired networks. Also, the capabilities of the handheld devices are limited, making it difficult to handle computationally and bandwidth-wise expensive application protocols. Wireless application protocol (WAP) and optimizations over traditional HTTP are some of the solutions for the application layer issues.

³ Some documents mention HTTP as the session layer protocol. Since the TCP/IP stack does not have a session layer, in this, it is considered as part of the application layer.

4.3 MOBILE IP

Each computer connected to the Internet has a unique IP address, which helps not only in identifying the computer on the network but also routing the data to the computer. The problem of locating a mobile host in a mobile domain is now imminent as the IP address assigned can no longer be restricted to a region.

The first conceivable solution to the above problem would be to change the IP address when the host moves from one subnet to another. In this way, its address is consistent with the subnet it is currently in. The problems with changing the IP address as the host moves is that TCP identifies its connection with another terminal based on the IP address. Therefore, if the IP address itself changes, the TCP connection must be reestablished. Another method would be to continue to use the same IP address and add special routing entries for tracking the current location of the user. This solution is practical if the number of mobile users is small. The quick-fix solutions are inadequate, but they give valuable insight into the nature of the mobility problem and offer certain guidelines for the actual solution.

Before providing the solution to the problem, some issues of utmost importance need to be enumerated. These are as follows:

• Compatibility: The existing wired Internet infrastructure is well-established today and it is economically impractical to try to alter the way it is working.

• Scalability: Wireless communication is the technology for the future, so the solution should be scalable to support a large number of users.

• Transparency: The mobility provided should be transparent in the sense that the user should not feel a difference when working in a wireless domain or in a wired one.

In Figure 4.3, mobile node (MN) is a mobile terminal system (end user) or a mobile router. It is the host for which the mobility support is to be provided. At the other end of the network is the system with which MN communicates. This is referred to as the correspondent node (CN), which may be a fixed or a mobile node. In this section, CN is considered to be a fixed, wired node. The node or router to which the MN is connected, which currently enjoys all the network facilities, is known as the foreign agent (FA). The subnet to which the MN's IP address belongs is the home network, and the router or node under whose domain this IP address lies is the home agent (HA).

Figure 4.3. Routing in MobileIP.

Suppose MN is currently in the subnet 130.111.*, hence as shown in the figure, 130.111.111.111 becomes the FA for MN. If CN sends a packet to MN, it reaches the HA of MN (130.103.202.050) along Path I. HA cannot find MN in the home network, but if it knows the location of MN, it can send the packet along Path II by creating a tunnel, as explained later.

4.3.1 MobileIP

The essence of the MobileIP scheme is the use of the old IP address but with a few additional mechanisms, to provide mobility support. MN is assigned another address, the care of address (COA). The COA can be one of the following types:

1. Foreign agent-based COA: The address of the FA to which the MN is connected can be used to locate the MN. The COA of the MN in this case is the address of its current FA.
2. Colocated COA: In this case MN acquires a topologically correct IP address. In effect, each MN now has two IP addresses assigned to it. In this case the CN sends data to the old IP address. The HA receives this packet and tunnels it to the MN using the new IP address.

In the case of FA-based COA, the FA decapsulates the packet and forwards it to MN, while in the case of colocated COA, it is decapsulated at MN. The HA encapsulates the data packet inside another packet addressed to the COA of MN. This is known as encapsulation and the mechanism is known as tunneling. Path II in Figure 4.3 shows the tunnel using the FA-based COA. Though the problem is solved, it has been done with a high degree of inefficiency. The details of the inefficiencies and the strategies adopted to avoid the overheads are discussed in Section 4.3.3.

Registration with the HA

This section discusses how the COA of an MN is communicated to its HA. This is done through the process of registration. When an MN moves to a new location, it tries to find the FA. This is done using the agent advertisement packet or agent solicitation packet. Registration involves authentication and authorization of the MN by the HA. In case of the colocated COA, there is no intermediate FA. MN simply sends the registration request to its HA, which authenticates it and sends back a registration reply.

Reverse Tunneling

It appears that there should not be any problem for the MN in sending a packet to the CN following path III. However, there are other practical constraints that play an important role here.

1. Ingress filtering: There are some routers which filter the packets going out of the network if the source IP address associated with them is not the subnet's IP address. This is known as ingress filtering where the MN's packet may get filtered in the foreign network if it uses its home IP address directly.
2. Firewalls: As a security measure, most firewalls will filter and drop packets that originate from outside the local network, but appear to have a source address of a node that belongs to the local network. Hence if MN uses its home IP address and if these packets are sent to the home network, then they will be filtered.
3. Time to live (TTL): The MN should be able to communicate transparently with all the CNs that it can communicate with while at home. Hence, in case of triangular routing, the TTL for the packets must be reduced only by one, up to the point where the packet is tunneled home.

Firewalls and ingress filtering have made a simple solution complicated. Therefore, to avoid these problems the idea of reverse tunneling is used, that is, MN encapsulates its packets using the source address of the encapsulated packet as its COA and destination as HA. The routing of packets from MN to CN takes place via the non-shortest path (as shown in Figure 4.3), that is, MN to HA to CN or vice versa is called triangular routing. This method, though not efficient, does work in practice.

4.3.2 Simultaneous Bindings

Simultaneous bindings is a feature of MobileIP that allows an MN to register more than one COA at the same time, that is, the HA allows MN to register more than one COA. MN can also deregister a specific COA. In such a situation, the HA must send multiple duplicated encapsulated data packets, one to each COA. The idea behind the use of simultaneous binding is to improve the reliability of data transmission.

4.3.3 Route Optimization

The packets sent to and from the HA are routed on non-optimal paths, hence the need for optimizations [1]. The CN is assumed to be mobility-aware, that is, it has the capability to deencapsulate the packets from the MN and send packets to the MN, bypassing the HA. The following are some of the concepts related to optimization strategies.

• Binding cache: The CN can keep the mapping of MN's IP address and COA in a cache. Such a cache is called a binding cache. Binding cache is used by the CN to find the COA of the MN in order to optimize the path length. Like any other cache, this may follow the update policies such as least recently used and first-in-first-out.

• Binding request and binding update: The CN can find the binding using a binding request message, to which the HA responds with a binding update message.

• Binding warning: In some cases, a handoff may occur, but CN may continue to use the old mapping. In such situations, the old FA sends a binding warning message to HA, which in turn informs the CN about the change, using a binding update message.

4.3.4 MobileIP Variations – The 4 × 4 Approach

As discussed in Section 4.3.1, MobileIP is a general-purpose solution to the mobility problem over IPv4. It uses encapsulation as a primary technique and thus introduces a huge overhead (approximately 20 bytes per packet). In the MobileIP scheme, the MN is dependent on the FA to provide a COA. The presence of the FA in all transactions prevents the MN from being able to perform any kind of optimization, and it is unable to forgo the MobileIP support even when it is not required. The key factors that affect any optimization scheme are the permissiveness of the network and the capabilities of the communicating nodes. In the following strategy presented, it is presumed that the MN does not depend on the FA for any support and it is able to acquire a COA from the subnet that it is present in.

Goals of Optimizations

Any optimization scheme should try to ensure guaranteed delivery, low latency, and low overhead. Deliverability is to be understood in terms of the traditional datagram network that provides only a best-effort service. The latency issue mainly deals with the route that is being followed by the packet from the source to the destination, either in terms of the hop count or the delay. The overhead in the MobileIP scheme is essentially the packet encapsulation overhead.

The 4 × 4 Approach

The strategy presented here provides four options for packets directed from the MN to the CN (OUT approaches) and four more options for packets directed from the CN to the MN (IN approaches). The set of options can be provided as a 4×4 [2] matrix to the hosts, which can decide on the appropriate combination depending on the situation. The IN and OUT strategies are summarized in Tables 4.1 and 4.2, respectively. s and d represent the outer source and destination in the encapsulated packet while S and D represent the inner source and destination of the packet (refer to Figure 4.3). Indirect transmission refers to the routing of packets between the CN and MN involving the HA, whereas direct transmission bypasses the HA. In Table 4.1 the four IN strategies are listed along with the respective source and destination fields, and the assumptions made and restrictions on usage of the strategies. For example, IN-IE uses the traditional MobileIP mechanism and works in all network environments irrespective of security considerations, while IN-DT is applicable for short-term communication wherein the mobility support is compromised. In Table 4.2, the four OUT strategies are listed. For example, OUT-IE uses the traditional MobileIP reverse tunneling mechanism and works in all network scenarios, while OUT-DH avoids encapsulation overhead but can be used only when the MN and CN are in the same IP subnet.

Table 4.1. The IN strategies in 4 × 4 approach

Table 4.2. The OUT strategies in 4×4 approach

Comparison and Evaluation of the Strategies

Having seen the four approaches for each of the two directions of packet transfer, different combinations of these strategies can be considered. Though there seem to be 16 combinations, some of them are inapplicable and some are redundant. There are also restrictions on when the approaches are valid; the characteristics of the situation will determine which approach to choose. The choice of a particular strategy can be made on a per session basis or on a packet-to-packet basis, as desired by the entities involved in the conversation. Tables 4.1 and 4.2 also show the acceptable combinations of the strategies.

4.3.5 Handoffs

A handoff is required when the MN is moving away from the FA it is connected to, and as a result the signals transmitted to and from the current FA become weak. If the MN can receive clearer signals from another FA, it breaks its connection with the current FA and establishes a connection with the new one. The typical phases involved in handoff are measuring the signal strength, decisions regarding where and when to hand off, and the establishment of a new connection breaking the old one.

Classification of Handoffs

The issues in handoffs are on the same lines as those in cellular networks. Handoffs can be classified in three ways [3] based on functionalities of the entities involved, signaling procedure, and number of active connections. Function-based classification is based on the roles of the MN and FA during the handoff. Figure 4.4 shows the MN, BS, FA, and CN in the handoff scenario.

Figure 4.4. Entities in wireless Internet handoff scenario.

Here, handoffs can be classified into four categories as follows:

1. Mobile initiated handoff: In this case, the handoff is managed by the MN. The MN measures the signal strength, decides the target base station (BS), and triggers the handoff.
2. Mobile evaluated handoff: This is similar to the previous case except that the decision on the handoff lies within the network, perhaps with the BS.
3. Network initiated handoff: In this case, the network (BS) decides where the MN should be handed over. Also, only the network measures the signal strength of the uplink and the MN has very little role to play.
4. Mobile assisted handoff: The MN assists the network in the network initiated scenario by measuring the downlink signal strength. This is typically to avoid a black hole scenario. A black hole scenario occurs when the channel properties tend to be asymmetric. (Usually wireless channels are assumed to have the same properties in both uplink and downlink, but in certain circumstances the throughput on one of the directions may be significantly less than the other. This scenario is referred to as a black hole.)

The second kind of classification is based on the number of active connections, where the handoffs are classified into two types: the hard handoff (only one active connection to the new or the old FA) and the soft handoff (has two active connections during the handoff).

Signaling procedure-based handoffs are classified into two types depending on which FA (old FA or new FA) triggers the handoff along with MN.

• Forward handoff: In this case, MN decides the target BS and then requests the target BS to contact the current BS to initiate the handoff procedure.

• Backward handoff: In this case, MN decides the target BS and then requests the current BS to contact the new one.

Fast Handoffs

A typical handoff takes a few seconds to break the old connection and establish the new one. This delay may be split into three components [4]: delay in detection of a need for a handoff, layer2 handoff (a data link connection that needs to be established between the new FA and MN), and layer3 handoff or registration with HA. The first two components cannot be avoided; however, the delay due to the third can be reduced. Also, if the above operations are parallelized, the total delay will be reduced. Two techniques called pre- and post-registration handoffs are employed to perform the above operations. The difference lies in the order in which the operations are performed. In the case of the pre-registration handoff, the registration with the HA takes place before the handoff while the MN is still attached to the old FA, while in the case of the post-registration handoff, registration takes place after the MN is connected to the new FA. In this case, the MN continues to use the old FA, tunneling data via the new FA until the process of registration is completed.

4.3.6 IPv6 Advancements

The various optimizations provided over IPv4 (IP version 4) in order to avoid the inefficiencies in routing MN's data were discussed in Section 4.3.4. IPv6 (IP version 6) has a built-in support for mobility to a great extent. The features [5] are listed below:

• Route optimization is a built-in feature of IPv6.

• IPv6 has fields for specifying both new (COA) and home (IP) address. So problems that lead to reverse tunneling can be avoided.

• The problem of ingress filtering is also solved due to the above.

• Control packets such as those used in route optimization can be piggy-backed onto the data packets.

• Detection of black holes: Sometimes it might happen that the signals of one of the links (uplink or downlink) become weak while the other link has a good signal strength. Such a phenomenon is known as a black hole because data can go in one direction but cannot come out in the other. In such cases, a handoff may be required. IPv6 allows both MN and BS to detect the need for a handoff due to creation of black holes.

• IPv6 avoids overheads due to encapsulation because both the COA and the original IP address are included in the same packet in two different fields.

Apart from these, IPv6 allows 2¹²⁸ addresses, thereby solving the IP address shortage problem, and includes advanced QoS features. It also supports encryption and decryption options to provide authentication and integrity.

4.3.7 IP for Wireless Domains

MobileIP is only a solution to the mobility of IP address problem, it is not a specific solution for wireless, especially cellular domains. The following discussion addresses certain protocols that are IP-based and suited for the wireless domain as well. In particular, we consider an approach which is terminal independent, that is, an approach aimed at giving a uniform service to both hosts that have the MobileIP capability as well as legacy hosts. The terminal independent mobility for IP (TIMIP) [6] strategy is based on two main protocols for the wireless networks, namely, HAWAII [7] and CellularIP [8]. Figure 4.5 gives the hierarchy of routers in the HAWAII, CellularIP, and TIMIP architectures. The access point (AP) is a router that is at the first level of the hierarchy and this is in direct communication with the MN over the wireless interface. Access routers (AR) are interior routers in the tree. The access network gateway (ANG) is the router at the root of the tree that acts as the interface between the wireless (TIMIP) domain and the core wired IP network.

Figure 4.5. Hierarchical routers.

HAWAII

HAWAII stands for handoff aware wireless access Internet infrastructure. The infrastructure identifies two categories of mobility to be handled, micromobility (intra-domain) and macromobility (inter-domain), where domain refers to a part of the network under the control of a single authority, such as AR and ANG. The objective of the infrastructure is to solve the QoS and efficiency issues that are not addressed by MobileIP.

CellularIP

CellularIP offers an alternative to the handoff detection problem by using the MAC layer information based on the received signal strengths to detect handoffs, instead of using the network layer information. The routing nodes maintain both a paging cache and a routing cache; the routing cache is a mapping between an MN's IP address and its current location in the CellularIP domain. The paging cache is preferred for nodes that receive or send packets relatively infrequently, and it is maintained by paging update packets sent by the MN whenever it crosses between two APs. The routing cache will be updated whenever the MN has a packet to send. The MN will send the packet to the closest AP and this will update all routing caches all the way up to the ANG. It is to be noted that during a handoff or just after the handoff, packets meant for the MN will be routed to both the old as well as the current AP in charge of the MN for a time interval equal to the routing cache timeout.

TIMIP

In the terminal independent mobility for IP (TIMIP) approach, the emphasis is on providing a uniform service to both MobileIP-capable MNs as well as the legacy terminals. The MobileIP capability of the legacy terminals will be provided by the ANG. The ANG will keep track of the information regarding each of the MNs in its domain such as the MN's MAC and IP addresses, the MobileIP capabilities, and the authentication parameters.

Whenever an MN arrives in the TIMIP domain, a routing path has to be created in the domain so that all packets intended for this host can be efficiently routed. This will cause a trigger of updates to ensure route reconfiguration in the entire hierarchy. The ARs not involved in the route will be unaware of the new path to the MN. As a result, the default strategy for any packet in the TIMIP domain, that is, for any IP address that is unknown at a particular AP or AR, will be to route it to the ANG.

• Micromobility: Whenever the MN moves within the same TIMIP domain, it is referred to as micromobility. The route updates and the corresponding acknowledgments will propagate up the hierarchy until the crossover AR is reached. The old path needs to be deleted in all the routing tables of the nodes. Now the crossover AR will send a route update packet addressed to the MN, and this packet will propagate down the tree until the old AP in charge of the MN is reached.

• Macromobility: Similar to CellularIP and HAWAII, TIMIP relies purely on MobileIP to support macromobility. The ANG acts as the MobileIP proxy on behalf of the MN that does not have MobileIP capability, and does all the MobileIP signaling that the MN would have normally done. For the normal MobileIP capable MNs, however, the ANG performs the role of a FA.

The TIMIP approach also provides for seamless mobility through the context transfer framework. The context transfer essentially ensures that the data loss during handoff is minimized and this is transparent to the MN and the CN.

4.3.8 Security in MobileIP

The wireless domain is inherently insecure. Any data that needs to be transmitted has to be broadcast and anyone who can hear this can read it irrespective of the destination address.

Security Problems

The common security problems that may arise in wireless networks are as follows:

• Registration request by a malicious node: This is a problem because a malicious node can pose as a legitimate MN and use the MN's IP address for registration, thereby enjoying all the facilities meant for the MN.

• Replay attacks: Many times the above problem is solved by making the registration process encrypted. Though this appears to avoid the first problem, the malicious node may copy the MN's registration packet, which is encrypted when the MN tries to register with the FA. Though this packet cannot be decoded by this malicious node, it can certainly use this packet for registering itself as the MN at a later point of time, and hence enjoy all the facilities at the cost of the MN.

• Tunnel hijacking: In this case, the malicious node uses the tunnel built by the MN to break through the firewalls.

• FA can itself be a malicious node.

The MN and HA share the same security association and use the message digest 5 (MD5) with 128-bit encryption. To circumvent the problem of replay attacks the MN and HA use a shared random number⁴ (called Nonce) and this random number is sent along with the encrypted registration request. On registration, the HA verifies the random number and issues a new random number to be used for the next registration. Hence, even if the packet is copied by the malicious node, it becomes useless for a replay attack, as at the time of the next registration the random number would have changed anyway.

⁴ Note: Time-stamps may also be used, but random number is a better option. Time-stamps may lead to synchronization problems.

4.3.9 MRSVP - Resource Reservation

The following section describes a reservation protocol used to provide real-time services to mobile users. A major problem is that mobility affects the QoS adversely. Hence there is a need for advance reservations to be made on behalf of a mobile host at future locations that it is likely to visit. We notice that the current RSVP⁵ structure is far from adequate and examine the proposed scheme.

⁵ Resource reservation protocol (RSVP) is a resource reservation setup protocol designed for multicast, multimedia data streams or flows (RFC 2205). A flow is specified by attributes such as source-destination pair, average data rate, latency, and QoS (RFC 1363).

Overview

The usual QoS parameters are delay, loss, throughput, and delay jitter. Whenever an MN moves across from one agent to another, there is obviously a change in the data flow path due to the handoff. The delay is likely to change due to the change in the data flow path and also due to the fact that the new location may vary from the old location with respect to congestion characteristics. Again, if the new location is highly congested, the available bandwidth is less, hence the throughput guarantees that were provided earlier may be violated. In addition, under extreme cases there may be temporary disconnections immediately following a handoff, which causes significant data loss during the transit.

Requirements of a Mobility-Aware RSVP

A fundamental requirement is that an MN must be able to make advance reservations along data flow paths to and from locations that it is likely to visit in the lifetime of a particular connection or session. Such a protocol has to have information that we refer to as the MSPEC, which is the set of locations from which the MN requires reservations. The definition of the MSPEC may be either statically done or there may be additional options to update it dynamically while the flow is active. A hypothetical MRSVP [9] has two types of reservations: ACTIVE and PASSIVE. An ACTIVE reservation is a normal RSVP-like reservation that is on the data flow path from the current location of the MN. A PASSIVE reservation is made along all paths to and from other locations in the MSPEC of the MN. The path along which the reservation will be made is the path specified by the MobileIP protocol. Passive reservations become active reservations whenever there is a active sender or receiver involved in that data flow path. The paths along which passive reservations have been made can be used by other flows with weaker QoS guarantees, but appropriate action needs to be taken when the passive flow turns into an active one.

MRSVP - Implementation

In this section, we describe a basic implementation of the MRSVP framework. We have to identify proxy agents (PAs) that will make reservations on behalf of mobile senders and receivers. There are two types of PAs: remote and local. A local proxy agent (LPA) is that to which the MN is currently attached. Every other agent in the MSPEC will be a remote proxy agent (RPA).

The sender periodically generates ACTIVE PATH messages, and for a mobile sender the PAs will send PASSIVE PATH messages along the flow path to the destination. Similarly, the PAs for a mobile receiver send the PASSIVE RESV messages while the receiver itself sends the ACTIVE RESV message.

The framework also defines additional messages such as JoinGroup, RecvSpec, SenderSpec, and SenderMSpec [9]. The key issues in the implementation are as follows:

• The identification of proxy agents (local and remote) that will perform the reservations on behalf of an MN.

• The identification of flow anchors (proxy agents), a Sender Anchor when the MN is a sender and a ReceiverAnchor when the MN is a receiver, that will act as fixed points in the flow path.

• The establishment of both active and passive reservations (by the remote proxy agents) for the MN according to the MSPEC.

• The actual message sequences that lead to the reservation depends on the type of the flow and the strategy adopted. A detailed discussion of the protocol can be found in [9].

The MRSVP scheme is an initial approach to providing QoS guarantees within the MobileIP framework. The scheme considers both unicast as well as multicast traffic for all types of senders and receivers. The significant contribution of the approach is the notion of PASSIVE reservations that exist virtually on future routers that the MN's data flow is likely to use, but will turn into real flows when the MN moves into the new domain.

4.4 TCP IN WIRELESS DOMAIN

The topics discussed so far addressed the network layer modifications that are necessary to make an efficient transition from the wired to the wireless domain. The wireless domain is not only plagued by the mobility problem, but also by high error rates and low bandwidth. Obviously there needs to be a higher layer abstraction that would perform the error recovery and flow control. The traditional TCP, which guarantees in-order and reliable delivery, is the classical wired networks transmission protocol. Since the transition to the wireless domain should be compatible with the existing infrastructure, there is need for modifications of the existing protocols. This is the correct approach rather than resorting to a completely new set of protocols.

4.4.1 Traditional TCP

TCP provides a connection-oriented, reliable, and byte stream service. The term connection-oriented means the two applications using TCP must establish a TCP connection with each other before they can exchange data. It is a full duplex protocol, meaning that each TCP connection supports a pair of byte streams, one flowing in each direction. TCP includes a flow-control mechanism for each of these byte streams that allows the receiver to limit how much data the sender can transmit. TCP also implements a congestion-control mechanism.

TCP divides the data stream to be sent into smaller segments and assigns sequence numbers to them. The sequence number helps the receiver to provide the higher layers with in-order packet delivery, and also detect losses.

The sliding window mechanism employed by TCP guarantees the reliable delivery of data, ensures that the data is delivered in order, and enforces flow control between the sender and the receiver. In the sliding-window process, the sender sends several packets before awaiting acknowledgment of any of them, and the receiver acknowledges several packets at a time by sending to the transmitter the relative byte position of the last byte of the message that it has received successfully. The number of packets to be sent before the wait for acknowledgment (window size) is set dynamically, that is, it can change from time to time depending on network conditions.

Because the major cause of packet loss in the wired domain is congestion, TCP assumes that any loss is due to congestion. The TCP congestion control mechanism works as below. Initially, the TCP sender sets the congestion window to the size of one maximum TCP segment [also known as maximum segment size (MSS)]. The congestion window gets doubled for each successful transmission of the current window. This process continues until the size of the congestion window exceeds the size of the receiver window or the TCP sender notices a timeout for any TCP segment. The TCP sender interprets the timeout event as network congestion, initializes a parameter called slow start threshold to half the current congestion window size, and resets the congestion window size to one MSS. It then continues to double the congestion window on every successful transmission and repeats the process until the congestion window size reaches the slow start window threshold. Once the threshold is reached, the TCP sender increases the congestion window size by one MSS for each successful transmission of the window. This mechanism whereby the congestion window size is brought down to one MSS each time network congestion is detected and then is incremented as described above is referred to as slow start.

Another important characteristic of TCP is fast retransmit and recovery. If the receiver receives packets out of order, it continues to send the acknowledgment for the last packet received in sequence. This indicates to the sender that some intermediate packet was lost and the sender need not invoke the congestion control mechanism. The sender then reduces the window size by half and retransmits the missing packet. This avoids the slow start phase.

4.4.2 TCP Over Wireless

The adaptation of TCP to congestion causes a lot of problems in the wireless domain. The wireless domain has high packet loss and variable latency, which may cause TCP to respond with slow start. Bandwidth utilization is further reduced due to retransmission of lost packets.

One of the earliest suggested alternatives for improving the performance of TCP over wireless networks was to ensure that the link layer corrected all the errors itself over the wireless interface, thereby eliminating the need for error handling at the TCP layer. One of the suggestions in this category is the use of forward error correction (FEC) to correct small errors. FEC is a means of error control coding wherein redundancy is encoded into the sent message or binary stream to allow self-correction at the receiver. The main objective of these techniques is to hide errors from TCP as far as possible. However, FEC incurs overhead even when there are no errors as there must be the redundant parity bits to allow error detection and correction. The alternative is to use adaptive schemes, which are dynamic in the sense that when the error rate or error probability is found to be higher than usual, the redundancy introduced into the transmitted stream is also correspondingly increased. Under normal circumstances, the overhead is kept to a minimum. The other form of link layer recovery is to use retransmissions at the link layer. This incurs the overhead only on error. However, the link level recovery mechanism may cause head-of-the-line blocking, wherein the recovery mechanisms employed for one data stream consume the network resources and prevent others from being able to transmit packets. Some researchers have advocated the use of the retransmit when FEC capability is exceeded.

The most accepted role of the link layer strategy would be one in which the link layer helps TCP error recovery by providing "almost in order delivery" of packets. Not all connections can benefit from link level retransmission as it is dependent on the nature of the applications.

Several alternatives have been proposed to alter the existing TCP protocol to suit the wireless domain. The simplest idea would be to design a new TCP protocol for the wireless domain, but this will be incompatible with the wired domain. The following sections discuss various approaches to improve TCP performance in the wireless domain. Figure 4.6 provides a classification of the existing approaches.

Figure 4.6. Classification of approaches for TCP over wireless.

4.4.3 Snoop TCP

The central idea used in snoop TCP [10] is to buffer the data as close to MN as possible in order to minimize the time for retransmission. The BS just snoops the packets being transmitted in both directions and recognizes the acknowledgments. The BS buffers the packets transmitted but does not acknowledge on behalf of MN. It simply removes the packet from the buffer when it sees an acknowledgment. If BS gets a duplicate acknowledgment (DUPACK) or no acknowledgment for quite some time, then it retransmits from the buffer after discarding the duplicate acknowledgment. This is to avoid unnecessary retransmissions from CN. The BS does not send acknowledgments to the CN on behalf of the MN, in order to retain the end-to-end semantics that traditional TCP provides. When the data transmission is from MN to CN, if the BS detects a gap in the sequence numbers acknowledged by the CN, it sends a NACK or negative acknowledgment to the MN to indicate loss over the wireless link.

4.4.4 TCP-Unaware Link Layer

This strategy particularly aims at simulating the behavior of the snoop-TCP protocol without requiring the link layer at the BS to be TCP-aware (hence the name TCP-unaware link layer even though TCP requires some information from the link layer). The usage of delayed DUPACKs [11] imitates snoop-TCP without requiring the link layer at BS to be TCP-aware. At the BS, as in snoop-TCP, link layer retransmission is used to perform local error recovery. But unlike snoop-TCP, where retransmissions are triggered by TCP DUPACKs, here retransmissions are triggered by link level ACKs. The MN reduces the interaction between the link layer and TCP using delayed DUPACKs. The advantages of this scheme are that the link layer need not be TCP-aware, it can be used even if headers are encrypted, which is not possible in snoop-TCP, which needs to look into the headers to see the sequence numbers, and it works well for small round trip times (RTTs) over the wireless link. The most significant disadvantage of this mechanism is that the optimum value of DUPACK delay is dependent on the wireless link, and this value is crucial in determining the performance.

4.4.5 Indirect TCP

This approach involves splitting of the TCP connection into two distinct connections, one TCP connection between the MN and BS⁶ and another TCP connection between the BS and the CN.

⁶ In this context of TCP over wireless, the terms BS and AP are used interchangeably.

Such a division splits the TCP connection based on the domain, the wireless domain, and the wired domain. The traditional TCP can be used in the wired part of the connection and some optimized version of TCP can be used in the wireless counterpart. In this case, the intermediate agent commonly known as the access point (AP) acts as a proxy for MN.

The indirect TCP (ITCP) mechanism [12] is shown in Figure 4.7. Loss of packets in the wireless domain, which would otherwise cause a retransmission in the wired domain, is now avoided by using a customized transport protocol between the AP and MN which accounts for the vagaries of the wireless medium. The AP acknowledges CN for the data sent to MN and buffers this data until it is successfully transmitted to MN. MN acknowledges the AP alone for the data received. Handoff may take a longer time as all the data acknowledged by AP and not transmitted to MN must be buffered at the new AP.

Figure 4.7. Indirect TCP.

4.4.6 Mobile TCP

The most common problem associated with the wireless domain is that quite often the connection between MN and BS is lost for small intervals of time. This typically happens when MN moves behind a huge building or MN enters offices where the signals are filtered. In such cases, the sender will keep transmitting and times out eventually. In case of ITCP, the data buffered at AP may grow too large in size. It may also lead to slow start.

In such situations the sender needs to be informed. This situation is handled in mobile TCP (M-TCP) [13] by the supervisory host (the node in the wired network that controls a number of APs) which advertises the window size to be one, thus choking the sender and hence avoiding slow start. Connection may be resumed when MN can be contacted again. When the supervisory host receives a TCP packet, it forwards it to the M-TCP client. Upon reception of an ACK from M-TCP client, the supervisory host forwards the ACK to the TCP sender. Hence M-TCP maintains the end-to-end TCP semantics even though the TCP connection is split at the supervisory host. When the M-TCP client undergoes a temporary link break, the supervisory host avoids forwarding the ACK of the last byte to the sender and hence the sender TCP goes to the persist state by setting the window size to zero. This avoids retransmission, closing of the congestion window, and slow start at the sender. For more details on mobile TCP, the reader can refer to [13].

4.4.7 Explicit Loss Notification

Typically, the problem with TCP lies in the fact that it does not know the exact cause for packet loss, and hence has to invariably assume congestion loss. An ideal TCP simply retransmits the lost packets without any congestion control mechanism. The MAC layer, however, can identify the reason for the packet loss. Once the MAC layer detects that either a handoff is about to occur or realizes that the actual cause of the packet loss is not congestion, then it immediately informs the TCP layer of the possibility of a non-congestion loss. The crux of the strategy is to detect loss at MN and send an explicit loss notification (ELN) to the sender. The sender does not reduce window size on receiving the ELN as this message implies that there was an error and not congestion. This technique avoids slow start and can handle encrypted data. However, the protocol layer software at the MAC layer of MN needs to be changed. Further, the information conveyed by the MAC layer may not always be reliable. For more details on ELN, the reader can refer to [14].

4.4.8 WTCP

WTCP [15] aims at revamping the transport protocol for the wireless domain using (a) rate-based transmission at the source, (b) inter-packet separation at the receiver as the congestion metric, (c) mechanisms for detecting the reason for packet loss, and (d) bandwidth estimation, as some of the underlying principles. A unique characteristic of WTCP is the attempt to separate the congestion control and reliability mechanisms. WTCP uses separate sequence numbers for congestion control and reliability mechanisms in order to distinguish the two. The reliability mechanism involves a combination of selective and cumulative acknowledgments, and takes into account the reverse-path characteristics for determining the ACK frequency.

4.4.9 TCP SACK

The selective retransmission strategy [14] is more complex and requires more buffer space at the end-points. Hence TCP traditionally uses cumulative acknowledgments and the go-back-N strategy. Using selective retransmit reduces the overhead of retransmission on errors and therefore cannot be ruled out for use in wireless domains. The TCP with selective ACK scheme (TCP SACK) [16], [17] improves TCP performance by allowing the TCP sender to retransmit packets based on the selective ACKs provided by the receiver.

4.4.10 Transaction-Oriented TCP

The TCP connection setup and connection tear-down phases involve a huge overhead in terms of time and also in terms of the number of packets sent. This overhead is very costly, especially if the size of the data is small. An alternative for such transactions is transaction-oriented TCP (TTCP) [18]. The motivation behind this approach is to integrate the call setup, the call tear-down, and the actual data transfer into a single transaction, thereby avoiding separate packets for connecting and disconnecting. However, the flip side to the strategy is that changes must be made to TCP, which goes against some of the fundamental objectives that the changes to TCP must be transparent and must not affect the existing framework.

Table 4.3 shows a summary of the various approaches discussed so far. The next section briefly describes the impact of mobility on the performance of TCP.

Table 4.3. Summary of proposed protocols to improve the performance of TCP over wireless

4.4.11 Impact of Mobility

Handoffs occur in wireless domains when an MN moves into a new BS's domain (a cell in the cellular context). If the link layer ensures reliable delivery and guarantees zero loss during a handoff, then TCP will be totally unaware of the handoff and no measures need to be taken at the transport layer to support handoff. The only exception to this is when the handoff latency is too large and exceeds the TCP timeout; then the transparency of handoffs to TCP is lost.

Fast Retransmit/Recovery

The usual problem associated with handoffs is that the handoff may lead to packet loss during transit, either as a result of the intermediary routers' failure to allocate adequate buffers or their inability to forward the packets meant for the MN to the new BS. The result of the packet loss during handoff is slow start. The solution involves artificially forcing the sender to go into fast retransmission mode immediately, by sending duplicate acknowledgments after the handoff, instead of going into slow start. The advantage of the strategy is its simplicity and the fact that it requires minimal changes to the existing TCP structure. However, the scheme does not consider the fact that there may be losses over the wireless links.

Using Multicast

Multicast has been suggested to improve the performance of TCP in the presence of handoffs [10]. The idea is similar to the one used in MRSVP [9], where the MN is required to define a group of BSs that it is likely to visit in the near future. These include the current cell (or the current BS) the MN is attached to and also the cells (BSs) likely to be visited by it. These BSs are then directed to join the multicast group, the address being the unique multicast address assigned to the MN. Packets destined for MN will have to be subsequently readdressed to the multicast group. In the implementation, only one BS is actually in contact with the MN and is responsible for transmitting the packets to it. If the rest of the BSs in the multicast group are able to buffer the packets addressed to the multicast address, then the loss of packets during the handoff can be significantly minimized. There is a trade-off between buffer allocation at the BSs and the loss during handoff. In practical situations, the number of buffers allocated can be minimized by buffering only when a handoff is likely to occur.

4.5 WAP

WAP stands for wireless application protocol. This name is a misnomer, because WAP represents a suite of protocols rather than a single protocol. WAP has today become the de facto standard for providing data and voice services to wireless handheld devices. WAP aims at integrating a simple lightweight browser also known as a micro-browser into handheld devices, thus requiring minimal amounts of resources such as memory and CPU at these devices. WAP tries to compensate for the shortfalls of the wireless handheld devices and the wireless link (low bandwidth, low processing capabilities, high bit-error rate, and low storage availability) by incorporating more intelligence into the network nodes such as the routers, Web servers, and BSs. The primary objectives of the WAP protocol suite are independence from the wireless network standards, interoperability among service providers, overcoming the shortfalls of the wireless medium (such as low bandwidth, high latency, low connection stability, and high transmission cost per bit), overcoming the drawbacks of handheld devices (small display, low memory, limited battery power, and limited CPU power), increasing efficiency and reliability, and providing security, scalability, and extensibility.

4.5.1 The WAP Model

WAP adopts a client-server approach. It specifies a proxy server that acts as an interface between the wireless domain and core wired network. This proxy server, also known as a WAP gateway, is responsible for a wide variety of functions such as protocol translation and optimizing data transfer over the wireless medium. Figure 4.8 illustrates the client-server model that WAP employs. The WAP-enabled handset communicates with a Web content server or an origin server [that may provide hypertext markup language (HTML)/common gateway interface (CGI) content] via a WAP gateway. It is at the WAP gateway that the convergence of the wireless and wired domains actually occurs. The gateway receives WAP requests from the handset, and these have to be converted into suitable HTTP requests to be sent to the origin server. If the origin server cannot provide the required information in wireless markup language (WML) form, then there must be an additional filter between the server and the gateway to convert the HTML content into WAP-compatible WML content. The gateway may additionally perform functions such as caching and user agent profiling as part of some optimization measures. This is also known as capability and preference information. By means of user agent profiling, the MN specifies its characteristics such as hardware characteristics, software capabilities, and user preferences, to the server so that the content can be formatted appropriately to be displayed correctly.

Figure 4.8. The WAP client-server model.

4.5.2 The WAP Protocol Stack

The WAP protocol stack is designed in a layered fashion that allows the architecture to provide an environment that is both extensible and scalable for application development. The WAP architecture allows other services to access the WAP stack at well-defined interfaces. Figure 4.9 gives an overview of the different layers in the WAP protocol suite and also their basic functionalities. This section provides a brief description of some of the important layers in the protocol stack.

Figure 4.9. The WAP protocol stack.

The Wireless Application Environment

The wireless application environment (WAE) has a number of components that address specific issues in the application environment. The WAE provides for an addressing model for accessing both the WWW URLs and other resources specific to the wireless domain using uniform resource identifiers (URIs). The WAE uses WML as the standard markup language, which can be construed as an efficient binary encoded form of the traditional HTML. The WAE also provides a compact scripting language analogous to JavaScript. The WAE also provides for a set of telephony applications through the wireless telephony application interface (WTAI).

Wireless Session Protocol

The wireless session protocol (WSP) establishes a reliable session between the client and the server and also ensures that the session is released in an orderly manner. The push mechanism is a fundamental component of the WAP programming model aimed at reducing the number of requests made by the client to the server. A data server will asynchronously push the information to the registered client(s) efficiently using this mechanism. This is especially useful in multicast and broadcast applications. The WSP provides the equivalent of HTTP in the WWW domain. The core of the WSP design is a binary form of HTTP. A session may be suspended to save power at the clients, but the session reestablishment follows only a small procedure that avoids the overhead of starting a full-fledged session afresh.

Wireless Transaction Protocol

The wireless transaction protocol (WTP) can for all practical purposes be viewed as a lightweight version of TCP. A transaction is defined as a request/response cycle. The WTP has no explicit setup and tear-down phases like TCP, as this would cause a tremendous overhead. There are no security options at the transaction layer in the WAP stack. WTP defines three categories or classes of service:

1. Class 0: Unreliable send (push model) with no ACK. There is no retransmission in case the message is lost. This is essentially a connection-less service.
2. Class 1: Reliable push service, where a request is sent and the responder sends the data as an implicit acknowledgment to the request. The responder maintains this state for some time to handle possible retransmissions.
3. Class 2: This is the classical request-data-ACK cycle providing a two-way reliable service.

Wireless Transport Layer Security

The objective of the wireless transport layer security (WTLS) is to provide transport layer security between the WAP client and a WAP server. WTLS is based on the industry standard transport layer security (TLS) protocol with certain features such as datagram support, optimized handshake, and dynamic key refreshing. The primary objectives of WTLS are data integrity, privacy, authentication, and denial of service (DoS) protection. WTLS has capabilities to detect and reject data that is not successfully verified; this protects servers from DoS attacks.

Wireless Datagram Protocol

The wireless datagram protocol (WDP) defines the WAP's transport layer in the protocol suite. The WDP has an adaptation layer that is bearer-specific that helps optimize the data transfer specific to a particular bearer service (such as SMS, USSD, CSD, and CDMA). If the underlying bearer service uses the IP standard user datagram protocol (UDP), then there is no necessity for a separate functionality at the WDP layer as UDP itself is used. The wireless control message protocol (WCMP) is responsible for providing the error-handling mechanisms analogous to Internet control message protocol (ICMP).

4.5.3 WAP 2.0 and i-mode

The i-mode (information-mode) system, developed in Japan and a major competitor to WAP, has three main components: a transmission system, a handset, and a language for designing Web pages. The transmission system consists of the existing mobile phone network (which is circuit-switched) and a new packet-switched network. Voice transmission uses the existing mobile phone network while data transmission uses the packet-switched network and is billed based on the number of packets transmitted as opposed to connection time. i-mode uses a subset of HTML called as cHTML (compact HTML). In contrast, WAP 2.0 was developed by the WAP Forum and is likely to use packet-switched network. WAP 2.0 has new features such as multimedia messaging, pull (request for data, then receive the data) as well as push model (asynchronous data transfer, without requiring explicit request messages, such as stock prices), integrated telephony, interoperability with WAP 1.0, and support for plug-ins in the browser. Unlike i-mode, WAP 2.0 charges the users based on connection time.

4.6 OPTIMIZING WEB OVER WIRELESS

The limitations of wireless networks that provide the motivation for such optimizations are low bandwidth, low reliability, high latency, and high cost per byte transferred. Integrating Web access over wireless devices would have to take into account the drawbacks of the wireless medium and the capabilities of the devices. Systems such as WebExpress [19] are aimed at optimizing routine repetitive browsing; many of the mechanisms suggested may not be suitable for random browsing (i. e., there are no perceivable trends in the Web accesses). Web browsers must offer a good interface for the wireless devices, keeping in mind the network, memory, processing power, and power consumption constraints.

4.6.1 HTTP Drawbacks

The main protocol on which the Web operates today is the hypertext transfer protocol (HTTP), which is optimized mainly for the wired world. It has a lot of overhead, but it is acceptable when the network bandwidth is an inexpensive resource as in typical wired networks compared to wireless networks. HTTP has drawbacks such as high connection overhead (a new TCP socket is opened for every new HTML object), redundant capabilities transmission (information regarding the browser capabilities is included in every HTTP request), and verbosity (HTTP is ASCII-encoded and hence inherently verbose). The WebExpress system suggests that an Intercept model be applied for Web access over wireless interfaces. This allows the number of requests sent over the wireless channel to be optimized, and also avoids the connection setup overhead over the wireless interface. There are two main entities that are introduced into the system: the client side interface (CSI) and the server side interface (SSI). The CSI appears as a local Web proxy co-resident with the Web browser on the wireless rendering device, say, a mobile phone or a PDA. The communication between the CSI and the Web browser takes place through the loopback feature of the TCP/IP suite (wherein the host sends a packet to itself using an IP address like 127.0.0.1). The communication between the CSI and the SSI is the only interaction over the wireless network and this uses a reduced HTTP, as discussed later. The SSI communicates with the Web server over the wired network. The SSI could typically be resident at the network gateway or the FA in MobileIP. The intercept model (Figure 4.10) is transparent to browsers and servers, and is also insensitive to changes in HTTP/HTML technology.

Figure 4.10. The intercept model.

4.6.2 Optimizations

Four main categories of optimizations that can improve the performance of Web access systems over wireless channels can be identified. These are:

• Caching: Current caching technologies are suited for wired applications. Cache objects are either purged at the end of the session or may persist across sessions. But it is advantageous to have cached data persist across browser sessions, as this increases cache hit ratios. Appropriate cache coherency methods are added to detect and change old information.

• Differencing: For transaction processing (involving forms) caching techniques do not help as different replies to the same application server are often different. Still, the fact that these replies tend to be similar can be exploited to reduce the network traffic over the wireless interface. A base object carries fundamental features that do not change across transactions and is created and maintained by both the client and server interfaces. Whenever a new transaction takes place, the server computes the difference stream and only the difference stream is transmitted.

• Protocol reduction: This approach aims at reducing the overhead of repeated setup and tear-down of TCP/IP connections for each Web-object to be transmitted. This can be eliminated by establishing a single TCP/IP connection between the CSI and the SSI that will persist for the entire session. The connection setup/tear-down overhead is on the local and wired connections only.

• Header reduction: HTTP requests are prefixed with headers that indicate to the origin server the rendering capabilities of the browser and also the various content formats handled by it. The alternative to this is that the CSI sends this information in the first request and SSI records this information.

For every subsequent request sent by the CSI, the SSI automatically inserts this capability list into each packet meant for the origin server.

4.7 SUMMARY

This chapter focused on the issues in wireless networks that are pertinent to the higher layers in the protocol stack, the network layer, the transport layer, and the application layer. The various aspects of the wireless Internet, that is, extension of the services offered by the Internet to the wireless domain, were discussed. Mobile IP aims at providing network connectivity to mobile hosts, and it is in a larger sense not restricted to wireless networks. The inefficiencies of MobileIP routing can be tackled in both generic techniques such as the optimizations incorporated in IPv6 and specific techniques as suggested in the 4×4 approach. The network layer also has to address the issues of security, accounting, and handoffs, as these are of great significance in wireless networks; some of the relevant issues were also discussed.

This chapter also discussed the issues in adaptation of TCP to the wireless domains, as it has been shown that the existing transport framework would perform miserably when used in its current form (optimized to work with high bandwidth, low-error wired networks). Most of the solutions involved some capability at the BS to buffer packets and also act on behalf of the MNs to send ACKs/NACKs. The strategies discussed in this chapter were broadly classified into various categories based on the role of the BS. The WAP architecture specified provides for an efficient, interoperable, and scalable framework for developing and using applications in the wireless domain. WAP 2.0 added more features to the previously existing WAP 1.0 protocol.

4.8 PROBLEMS

1. What are the major problems that arise in network and transport layers when an MN accesses the Internet from a different network?
2. Why should MN register with HA?
3. What is triangular routing?
4. Why is reverse tunneling necessary?
5. Why is it necessary to adopt different types of optimization strategies with regard to Mobile IP?
6. State the differences between network-initiated and mobile-initiated handoffs.
7. What are the various steps involved in a handoff?
8. What is post-registration handoff?
9. When do you think a forward handoff is needed as opposed to a backward handoff? What could be some advantages of a backward handoff as opposed to a forward handoff?
10. Can a soft handoff be a forward handoff? Can a forward handoff be a soft handoff?
11. What happens if an MN requests a handoff but then, after the resources are reserved, the MN does not hand off to that FA?
12. What are the two types of mobilities that are applicable in TIMIP domains?
13. What are the effects of mobility on the QoS provisioning for mobile nodes?
14. What do you think are the major drawbacks in the existing RSVP structure compared to MRSVP?
15. Briefly discuss the main goals of WAP.
16. Explain the WAP model and the WAP protocol stack.
17. What is the functionality of the session layer in the WAP stack?
18. What are the advantages of using the intercept model in WebExpress?
19. What are the four major categories of optimizations suggested in the WebExpress system?

BIBLIOGRAPHY

[1] C. E. Perkins, "Route Optimization in Mobile IP," Internet draft (work in progress), draft-ietf-mobileip-optim-ll.txt, September 2001.

[2] S. Cheshire and M. Stuart, "Internet Mobility 4×4," Proceedings of ACM SIG-COMM 1996, pp. 318-329, August 1996.

[3] P. Venkataram, R. Rajavelsamy, and S. Laxmaiah, "A Method of Data Transfer Control During Handoffs in MobileIP-Based Multimedia Networks," ACM Mobile Computing and Communications Review, vol. 5, no. 2, pp. 27-36, April 2001.

[4] K. E. Malki et al., "Low Latency Handoffs in Mobile IPv4," Internet draft (work in progress), draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001.

[5] D. B. Johnson and C. E. Perkins, "Mobility Support in IPv6," Internet draft (work in progress), draft-ietf-mobileip-ipv6-15.txt, November 2001.

[6] A. Grilo, P. Estrela, and M. Nunes, "Terminal Independent Mobility for IP-TIMIP," IEEE Communications Magazine, vol. 39, no. 12, pp. 34-41, December 2001.

[7] R. Ramjee et al., "IP-Based Access Network Infrastructure for Next-Generation Wireless Data Networks," IEEE Personal Communications Magazine, vol. 7, no. 4, pp. 34-41, August 2000.

[8] A. Campbell et al., "Design Evolution and Implementation of Cellular IP," IEEE Personal Communications Magazine, vol. 7, no. 4, pp. 42-49, August 2000.

[9] A. K. Talukdar, B. R. Badrinath, and A. Acharya, "MRSVP: A Resource Reservation Protocol for an Integrated Service Network with Mobile Hosts," ACM/Baltzer Wireless Networks Journal, vol. 7, no. 1, pp. 5-19, January 2001.

[10] H. Balakrishnan, S. Seshan, and R. Katz, "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks," ACM/Baltzer Wireless Networks Journal, vol. 1, no. 4, pp. 469-481, December 1995.

[11] N. H. Vaidya, M. Mehta, C. Perkins, and G. Montenegro, "Delayed Duplicate Acknowledgments: A TCP-Unaware Approach to Improve Performance of TCP over Wireless," Technical Report 99003, Computer Science Department, Texas A&M University, February 1999.

[12] A. Bakre and B. R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," Proceedings of IEEE ICDCS 1995, pp. 136-143, May 1995.

[13] K. Brown and S. Singh, "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communication Review, vol. 27, no. 5, pp. 19-43, October 1997.

[14] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz, "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links," IEEE/ACM Transactions on Networking, vol. 5, no. 6, pp. 756-769, December 1997.

[15] P. Sinha, N. Venkitaraman, R. Sivakumar, and V. Barghavan, "WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks," Proceedings of ACM MOBICOM 1999, pp. 231-241, August 1999.

[16] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective Acknowledgment Options," IETF RFC 2018, July 1997.

[17] M. Mathis, J. Semke, and J. Mahdavi, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," ACM Computer Communications Review, vol. 27, no. 3, pp. 67-82, July 1997.

[18] R. Braden, "T-TCP - TCP Extensions for Transactions Functional Specification," IETF RFC 1644, July 1994.

[19] B. C. Housel and D. B. Lindquist, "WebExpress: A System for Optimizing Web Browsing in a Wireless Environment," Proceedings of ACM/IEEE MOBICOM 1996, pp. 108-116, November 1996.

[20] C. E. Perkins, "Mobile Networking Terminology," Internet draft (work in progress), draft-ietf-manet-term-01.txt, November 1998.

[21] C. E. Perkins, "Mobile IP," IEEE Communications Magazine, vol. 35, no. 5, pp. 84-99, May 1997.

[22] C. E. Perkins, "Mobile Networking Through Mobile IP," IEEE Internet Computing, vol. 2, no. 1, pp. 58-69, January-February 1998.

[23] C. E. Perkins, "Mobile IP Joins Forces with AAA," IEEE Personal Communications Magazine, vol. 7, no. 4, pp. 59-61, August 2000.

[24] S. Glass, T. Hiller, S. Jacobs, and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," IETF RFC 2977, October 2000.

[25] H. Chaskar, "Requirements of a QoS Solution for Mobile IP," Internet draft (work in progress), draft-ietf-mobileip-qos-requirements-01.txt, August 2001.

[26] G. Dommety, "Fast Handovers for Mobile IPv6," Internet draft (work in progress), draft-ietf-mobileip-fast-mipv6-03.txt, November 2001.

[27] B. Jabbari, R. Papneja, and E. Dinan, "Label Switched Packet Transfer for Wireless Cellular Networks," Proceedings of IEEE WCNC 2000, vol. 3, pp. 958-962, September 2000.

[28] H. Yumiba, K. Imai, and M. Yabusaki, "IP-Based IMT Network Platform," IEEE Personal Communications Magazine, vol. 8 no. 5, pp. 18-23, October 2001.

[29] V. Gupta and S. Gupta, "Securing the Wireless Internet," IEEE Communications Magazine, vol. 39, no. 12, pp. 68-74, December 2001.

[30] WAP 2.0 Technical White Paper, WAP Forum Ltd., 2002.

[31] J. Schiller, Mobile Communications, Addison-Wesley, January 2000.

[32] I. Stojmenovic, Ed., Handbook of Wireless Networks and Mobile Computing, Wiley Interscience, New York, February 2002.