Disconnection protocol support in mobile access

Disconnection protocol support in mobile access

Djamel H. Sadok, Judith Kelner and Carlos de Morais Cordeiro

Departamento de Informática, Brazil

Universidade Federal de Pernambuco

{jamel,jk,cmc}@di.ufpe.br

Abstract

Mobile access remains limited by relatively short battery power lifetime, expensive wireless bandwidth and areas with difficult or no continuous communication coverage. It is believed that as many as 70% of laptop users would operate in planned or non planned disconnected mode. Although existing approaches have led to implementing disconnected mode operation within applications, we chose to introduce changes to a mobile extension of the Internet transport protocol. We show through simulation that this protocol performs better than TCP. In order to evaluate disconnection parameters including disconnection and inter-disconnection times, a performance study of disconnection is presented. Finally we argue that disconnection is an important service and should therefore be considered as a Quality of Service (QoS) parameter to be negotiated among mobile and fixed communication entities.

Keywords: Mobile Computing, Communication Protocols, Planned Disconnection.

1 Introduction

It is believed that as much as 70% of laptop use by mobile users will operate in disconnected mode [12] where mobile users would establish connections to access dedicated LAN services and retrieve information to work on it locally with no need to maintain their LAN connections alive. This mode of operation is primarily justified by the scarce and relatively expensive bandwidth resources available to this emerging new class of users.

In this work, we first review and classify solutions for disconnected operation mode support. Next, we validate through simulation the results of a previous research work reported in [2]. We then describe our own solution taking into consideration performance issues and the nature of mobile hosts in terms of planned necessary disconnection in order to save energy and other resources. A detailed study of disconnection parameters is made next. The paper is finally concluded with some observations on current and related future work in the area.

2 Motivation and definitions

[20] portrays an interesting scenario describing a challenging vision: that of a travelling businessman working onto his report, first at the office then in the limousine, the plane, while maintaining contact with his company’s file system, reading his e-mail and distributing copies of his documents to colleagues for editing and reviewing. Through intermittent conditions, the notebook establishes on demand connections to remote servers. Depending on changing network resources and/or costs, the notebook plans and executes its connections accordingly deciding when to propagate changes made to these documents. Since it is important to avoid having to restart applications every now and then, we expect this to be as transparent as possible to the user or even under his /her control.

Whereas with planned disconnection a mobile host may be able to consciously choose to go into doze off mode to perform some local tasks without the need to break its current network connections or affecting their flow control parameters or discontinue its application, unplanned disconnection at lower (network) levels may also occur and should be treated equally. Since disconnection is the result mostly of the mobile nature of the communications, it is wise to look into its solutions in the mobile part of the network. We will elaborate more on this point later on in the paper.

2.1 Problem Position

In traditionally fixed sub-networks, a host is declared as unreachable if packets do not reach it within a time frame and recovery procedures are initiated in an attempt to recover the link. In low speed wireless networks, such connections should not be considered as failed ones, as the host may have decided to go into doze off mode or that the communication channels are temporarily unavailable at this moment for immediate use. This could be the case if data communication channels are multiplexed through some scheme such as Cellular Digital Packet Data (CDPD) with those of voice for example and where voice transport has higher priority. Link connectivity may also be lost in the case where cells are not overlapped. Link loss due to handoff procedures are known to last few hundred milliseconds in existing cellular systems. Furthermore, system designers may consciously put their mobile computers to sleep now and then, under application control, in order to save on transmission energy and costs. This work does not address aspects of underlying cellular technology used, but concentrates on network and transport issues. In the actual simulation we have adopted the terminology used by the IETF Mobile-IP working group [Perkins, 95].

3 State of the Art

Disconnected mode users represent a sizeable community, and as such, systems developers are actively extending their support to them. A case in the point is Microsoft’s Windows 95/Memphis support for the Advanced Configuration and Power Interface (ACPI) as well as a new feature called "OnNow" design under which a system might seem to be off but would wake up as soon as an event such as an incoming phone call occurs. More recently, a consortium of hardware and software companies initiated the Mobile Network Computer Reference Specification (MNCRS) effort to standardize hardware and software interfaces and services commonly offered by mobile hosts [MNCRS]. The MNCRS specifications state that support for disconnected operation mode must be seen as the rule and not the exception.

Many solutions to disconnection have been put forward by application designers who view the application as the one responsible for managing its mobile users. Since individual adaptation of all existing applications is not simple, some have opted for changes mainly at the client side residing at the mobile Laptop, others pushed the adaptation down to the operating system level with changes made to the file system components. Finally, there are those who also suggest the re-design of application level protocols.

In [1] a proposal is made for the support of disconnected workflow clients where desktop users may connect to a workflow server to download their application and data. A limitation of this system is that two distinct clients may not be allowed to work on the same activities simultaneously as client access to the database server is serialized. Other solutions such as [5] require the workflow designer to specify if a given activity may be downloaded by a disconnected user during the actual design stage.

In [10], a technique for a partially connected file system is introduced. During the connected operation, the Prayer File System (PFS) system accumulates (hoards) or cache files likely to be used by the user. When disconnected, the file system reads and writes the hoarded files. PFS optimizes partial connectivity and offers applications the means to control QoS parameters as well as current storage and consistency check policies.

Similarly [19] describes an extension to the CODA file system, a descendant of the Andrew File System, to support disconnected user access in a mobile environment where both voluntary and non voluntary disconnection are supported. Results from [19] show that the CODA file system is not suited for applications with highly concurrent access and frequent update messages such as on-line transactions.

In the area of database access to storage systems many algorithms have been designed for operation in a partitioned network. These either enforce overly pessimistic locking on replicas, e.g. majority consensus, or else provide few consistency guarantees and little support for resolving conflicts, e.g. epidemic algorithms. Existing replicated data algorithms, such as those based on maintaining strong data consistency by atomically updating a quorum of copies or based on server-initiated callbacks for cached data invalidation, do not work well in a frequently-partitioned network. To overcome this, Xerox’s Bayou adopts the philosophy where the storage system is replicated to provide maximum availability, no locking, weak consistency and read-any/write-any access model. It relies on the application participation in replication and conflict resolution [9].

Sometimes, mobile support is embedded within the underlying platform by the way traditional mechanisms associated to objects and communication protocols work. This is the case with the MIT’s Rover Toolkit described in [14] and MIT’s Thor, a large-scale distributed object oriented database system that provides reliable and highly available persistent storage for objects [11]. Unlike both platforms above, Teleweb is an application with direct built-in support for disconnection [21]. It offers a loosely connected access to the World Wide Web. The new IETF standard for mail store management, the Internet Message Access Protocol (IMPA) includes support disconnected mode, when users work offline and subsequently synchronize with an IMAP server. Details on disconnected operation in IMAP4 may be found the Consortium’s site [8].

3.1 Transport Protocol Support for Disconnection

An apparent problem with the TCP/IP protocols is their lack of adaptability to the underlying subnetwork used. We show in this paper, that transport changes may be made within the wireless part, without loosing compatibility or altering the widely used base of connection oriented transport protocols such as TCP. First, we briefly review existing proposals for mobile transport protocols and show our validation of one of these.

4 Simulation of a Mobile Transport Protocol

A number of mobile IP proposals have addressed the issue of delivering IP packets to and from mobile hosts [17,18,22]. In theory these solutions work to hide all mobility issues from the transport user (or host process). In this context, the mobility problem has so far been seen as one of "routing" which lead to the neglect of other equally important design aspects such as performance. Actually, all the solutions presented at the IP level present a short break in connectivity and therefore require that the TCP handles these properly. Simply put, mobility solutions at the subnetwork level are hardly sufficient on their own. Consequently we look at the next level up, namely connections at the transport level, or TCP in the specific case of the Internet. TCP interprets such packet loss problems as due to link congestion rather than due to host mobility, triggering therefore its usual recovery procedures based on window size control and exponential backoff [7]. The recovery is painfully slow as shown in many studies [2].

Many researchers pointed out this problem and consequently have come up with a number of schemes to improve TCP performance especially over wireless links including those presented in [Cacéres, 95] [16] and [3]. The extensions to TCP may be divided into two distinct groups: those seeking to hide the handoff problem in order to avoid TCP congestion control mechanisms being activated at handoff; and those with solutions at the transport level changing the congestion control algorithm.

In [2] a solution taking into consideration some of these factors has been suggested. It is based on the division of TCP connections into two parts, a normal TCP connection in the fixed subnets and a second connection based on Indirect TCP (I-TCP). Hence the software changes are limited to components of the mobile subnet.

4.1 A Look at Indirect TCP

Indirect TCP splits the connection at the transport level into two interactions: one at the fixed network and the other over the wireless network. This solution separates the flow control between fixed and wireless parts of a TCP connection. It also allows that much of the communication processing is handled by the base station of the MSR (Mobile Support Router). The basics of how I-TCP works are explained in [2]. I-TCP creates an image of the MH on the MSR that talks to the FH. The MSR and the MH talk using Indirect TCP. When an MH moves to a new cell, the communication is handled by a new MSR. The connection end points of both the MH and the FH do not change over handoffs, there is no need to reestablish these connections at the new MSR. Hence the FH is completely unaware of the new location of the new MSR (indirection).

4.2 I-TCP Validation

The reported analysis of I-TCP in [2] was performed using measurements. Our first undertaking was to simulate I-TCP using the BONeSÒ Designerä simulation tool [4] in order to evaluate these results. We also chose the throughput as the main metric for comparing both TCP and I-TCP protocols. The simulated system, depicted in figure 1, consists of three basic structures: a mobile client, the MSR and a fixed server. The client at the MH sends 2 KB requests to the FH server which transmits back data according to a uniform distribution with a minimum and maximum of 4 MB and 8 MB respectively. The decision to use an asymmetric data flow where data is mainly sent from the FH to the MH reflects real typical applications such as E-mail access and Web browsing where feedback is minimal. Application data is fragmented into 512 segment units.

Figure 1:
Simulated Scenario

In addition to the conventional TCP simulation parameters, we considered those related to user mobility and the wireless interface such as the handoff time, time between handoffs, etc, described next:

1. Inter Mobility Time (imt) – Also known as Cell Residence Time, represents the time a user remains within a cell. In [23] It was shown that the cell residence time follows a Gamma distribution. Similarly, we used a Gamma distribution ( G ) with a mean of m = 30s.

2. Handoff Period – Represents the time a mobile host remains in handoff. This parameter has been changed for different simulations to indicate the separation of the cells. Its use will become more clear when we explain the cells configuration we analyzed.

3. Wireless Packet Miss Rate – Represents the error rate of the wireless medium. We used 10^-3 to represent this parameter.

4. Wired Packet Miss Rate – Similarly, this parameter represents the error rate at the fixed link. The value associated to this parameter was valor 10^-9.

5. Wired Delay – Represents the delay in the fixed network. In the Appendix we show that the end-to-end delay may be seen as the sum of a fixed minimum delay and a two stages Erlang distribution with a m = 0.01 mean.

6. Wireless Delay – Represents the delay in the wireless medium. This has also been modeled as the sum of a 30ms constant and a two stages Erlang distribution with a m = 0.02 mean.

7. Max Segment Size – 512 bytes TCP segments were used.

8. MH Max Window Size - Fixed to 16 KB as in [2].

9. FH Max Window Size – Fixed to 64 KB.

The parameters above have been used for both TCP as well as I-TCP simulations and selected to reflect a MH client accessing a remote server over a wide area network. In order to recreate the environment tested in [2], the end-to-end throughput was measured for four different configurations, indicated by the parameter Handoff Period:

• No Moves – The MH remains within the same cell during the entire connection.

• Moves between overlapped cells – The MH changes cell each Inter Mobility Time without loosing its communication with its current MSR during handoff. During the time representing the cell overlap, the MH continues receiving packets from its old MSR.

• Moves between non-overlapped cells with 0s between cells – In this case, the cell boundaries are well established removing any MH communication with its old MSR during handoff. When the MH starts looking for a new beacon to establish a new communication channel with a new MSR, the connection is lost for a while. The rtt (round-trip time) used in [16] is 300 ms and the delay in performing the handoff was chosen to be 0.5 * rtt. In our simulation, we use 1s to represent this delay.

• Moves between non-overlapped cells with 1s between cells – This is similar to the previous case, except that there is the extra delay of 1s representing the distance between consecutive cells.

Our TCP simulation accurately models the TCP protocol in that it implements the dynamic flow algorithm and retransmits timed-out packets according to an estimated round-trip delay and the Van Jacobson’s congestion control algorithm [13] also known as the TCP-Tahoe. Karn’s algorithm is used to set timeout values for retransmitted packets [7].

Table 1 below shows the results we obtained via simulation. There are little differences between both measurement and simulation results hence validating the results announced in [2]. Even when the MH remains within the same cell during its entire connection, we see that I-TCP throughput is roughly twice that of normal TCP. This is due to the fact that the wireless delay varies more than that of the fixed network, forcing TCP to enter into the congestion control algorithm, therefore causing a noticeable decline in end-to-end throughput. When using I-TCP, the MH sees more uniform round trips as compared to regular TCP.

There were no significant changes to TCP performance when the MH remains within the same cell or when it performs handoff to overlapping cells. However, I-TCP performance remained in both scenarios twice as much that of TCP as shown in figures 2 and 3 . As we can see from two figures above, I-TCP is much more regular than TCP. The drops in throughput coincide with the end of the transmission of a complete reply, the MH then makes another request. The figures also show that TCP takes more time to recover from that drop in performance as compared to I-TCP.

Figure 2
: TCP and I-TCP Throughput when user remains in same Cell

Figure 3
: TCP and I-TCP Throughput in Overlapping Cells

When handoffs occur between non-overlapped cells, TCP throughput suffers significantly when compared to when the MH remains within the same cell. More specifically, a 53% fall in throughput has been registered with TCP as compared to 41% in the case of I-TCP. This difference is mainly due to the fact the retransmission of lost packets is confined to the MSR. The MSR has a breathing space during which to recover from the congestion control algorithm since the round-trip delay between the MSR and the MH is shorter than the end-to-end round-trip between the FH and the MH. The benefits of using I-TCP increase over wide area networks as the round trips tend to be longer.

Figure 4 shows the behavior of the throughput in the case of TCP and I-TCP when the cells are non-overlapping with 0s between them. When there are handoffs in most of the cases TCP performance decreases to 4KB/s, and in certain cases to 0 (zero). As for the case of I-TCP the falls are much more regular, therefore leaving the overall throughput higher than TCP as indicated in table 1.

Figure 4
: Non-overlapped Cells with 0s between cells

Figure 5 shows the throughput in the case where the cells are non-overlapping with 1s between them. In this case the TCP throughput reaches zero every time a handoff occurs, making the overall throughput decrease to the value shown in table 1. As for I-TCP the throughput also suffers from a decrease, however the overall throughput is still much better than that of TCP.

Figure 5
: Non-overlapped Cells with 1s between cells

5 Managing Disconnection in I-TCP

The changes made to I-TCP should ensure that the transport disconnection at the wireless segment is transparent to the fixed part of the network. The MH may be able to freeze a connected socket, store its state, continue receiving segments by buffering them and not processing these and advise the MSR of its disconnection. The MSR, on the other hand, buffers incoming segments, and after a while it may signal the end of a given disconnection.

Ideally, the FH should reduce its traffic flow towards the MSR while keeping the fixed (wired) connection alive. This could be achieved by emulating packet loss, the MSR not sending acknowledgements, or reducing its advertised window. The first alternative may generate performance loss by inducing exponential backoff , what the design is trying to avoid in first place, this has not been considered. Currently, we are investigating the effect of reducing the MSR’s advertised window on both buffer management and end-to-end throuput. Without freezing the FH-MSR connection, the memory required grows with the length of the disconnection interval. We will analyze through simulation these requirements in the next section.

Transport users (or applications) should be able to choose among their different applications and disconnect some or all of them. The way applications are to decide on which connections to disconnect and for how long, is outside the scope of this paper and maybe subject of further study. We will show through simulation that disconnection time is a limited resource that applications should negotiate with the transport entities.

5.1 I-TCP Disconnection Messages

Prior to disconnecting the MH must first select which I-TCP connections are subject to be disconnected, signal to the MSR its intention to disconnect as well as when it plans to do so, and at a later time after the conclusions of the some local processing, it then signals its wish to reactivate some of its dormant connections. Both MSR and MH must store the state of the connection for later use when this is reinitiated, see figure 6:

Figure 6
: Disconnection Support Messages

1. The MH first selects which I-TCP connections that are to be frozen, storing their states and freezing their corresponding sockets.

2. The MH continues receiving I-TCP segments but without processing these or returning any acknowledgements;

The MH sends a planned disconnection request (in the form of a DiscPlan message) to the current MSR. This message should include parameters such as which connections are to be disconnected, and optionally an estimate of the planned disconnection time and duration, a possible new MSR, etc. It may be the case that the disconnecting MH may want to anticipate the MSR it would rejoin when it is planned to reactivate its interrupted (frozen) connections. In both situations, the original MSR will continue buffering incoming packets. This design choice has been made in order not to penalize performance in case the MH remains in the same MSR.

As soon as the MSR receives the disconnection request , it performs the following tasks:

1. Immediately stops forwarding packets to the MH on all or specific I-TCP connections and freezes their states taking into consideration disconnection time and optional duration for each of the selected I-TCP connections;

2. In the meantime the MSR should continue receiving packets from the fixed host (FH) addressed to the soliciting MH and internally store these in its buffers. As we will in the next section, the duration of a disconnection is subject to MSR’s buffer availability;

If a forwarding MSR (MSR-2) is included as a parameter in the DiscPlan request message, then the MSR should forward, via the fixed network, all new I-TCP packets to the target MSR. Acknowledgements are sent to the FH accordingly. Note that the MSR continues buffering incoming packets just in case the MH remains nearby. Only the MH may initiate a disconnection request using the DiscPlan message. The FH is not at all aware of the disconnected state of the mobile host. The use of forwarding to anticipate new visited MSRs, as depicted in figure 6, may greatly optimize the end-to-end I-TCP traffic. Although predicting where a disconnected user may reconnect to the fixed network is not a simple task, unless given by the application itself, we believe that such as mechanism may be important specifically in third generation cellular networks where the use of user profiles to predict user movements is going to be an important feature according to [15]. The mobile host may re-initiate a connection by sending a RecPlan message to the nearest MSR using the following algorithm:

1. A disconnected MH examines its frozen sockets and decides the ones it would reinstate. Please note that the decision of which connections to unfreeze is an item for further study. Once a disconnected MH becomes active, it first transmits a request announcing its return to be active by broadcasting to its neighborhood a "RecPlan" message;

2. If the original MSR picks the transmitted request up then they may continue the transmission of data segments where they left using the same parameters. The responding MSR sends back a "RecPlanAck" message as shown in figure 7;

Figure 7:
Transport Reconnection Messages

3. If the nearest response (strongest signal) comes from a different MSR, MSR-2, then this one instructs the original MSR, or MSR1, to perform MH handoff to it using the RecFwdPtr message. The MSR-1 would then hand out all buffered data to MSR-2, which acknowledges the forwarding from MSR-1 sending it "Ack" messages and finally terminates its connection to the MH. This scenario is also depicted bellow in figure 7.

6 A Discussion of the Proposed Disconnection Algorithm

In order to keep our solution as simple as possible, we chose not to allow disconnection during handoff. Please note that this is not to say that once a disconnection has started, the MH must remain within the same cell (controlled by the same MSR that it was talking to when it disconnected). In other words, an effort should be made to defer disconnection when anticipated by a handoff procedure. Hence in all cases, the disconnection procedure may be aborted in the case of a coinciding handoff. This is shown in figure 6 with the use of the DiscAbort Message.

6.1 MSR Initiated Reconnection

It may also be the case that the MSR may want to re-activate one or more frozen connections in the following situations:

1. The announced duration of the planned connection has expired: here the MSR may send a RecPlan message to the target MH, telling this which I-TCP connections it should reactivate.

• The MH may acknowledge the RecPlan message (see figure 10) agreeing therefore to reopen some or all its I-TCP dormant connections. Please note that the MH, under application control, may choose only to reactivate some instead of all of its I-TCP connections that have timed-out;

Figure 8: MSR Initiated Reconnection

Figure 9
: Flow Control Initiated Reconnection

Figure 10
: Unplanned Disconnection Buffer Occupation with a 0.5 and 2.0 Connectivity Factors

• The MH may also ignore the MSR request and choose to continue working in "doze off" mode by sending this a new "DiscCont". The MSR returns a DiscContAck acknowledgement conforming receipt and extension of the disconnection state;

• If the MSR does not receive any of the above replies, namely a RecPlan or DiscCont acknowledgements, it may conclude after a few retransmissions of the RecPlan request that the ITCP connection is no longer valid and would declare it as closed or lost.

2. The MSR has no buffers left and wants to prompt the FH to unloading some of the accumulated traffic at the MSR: here the MSR sends the MH RecOffLoad request telling its wish to forward to it packets it has been collecting in its behalf, see figure 9. Parameters may include the amount of data the MSR has buffered and a priority level (low, normal, or high). The MH response to a RecOffLoad message may be one of the following three scenarios:

• The MH may simply agree to the MSR’s request to offload its traffic and hence sends it back a RecPlan message as shown in figure 9(a). Normal reconnection procedures are then executed as shown earlier;

• Here the MH may agree to the MSR’s request to offload its traffic but returns instead a RecOffLoad acknowledgement therefore saying that it is going to reactivate its connection temporarily in order to offload the agreed upon I-TCP traffic. Once the accumulated information is transmitted to the MH, this one issues a new DiscPlan message in order to return to its initial "doze off" as depicted in figure 9(b);

• Alternatively, the MH may ignore the MSR’s request to allow this to offload some of the traffic it has received on its behalf. Here the MH responds with a NoOffLoad message and optionally with a time estimate of when it may want the MSR to send it a new RecOffLoad request advising it to try again at a later time. This last scenario is shown in figure 9(c) ;

• Similarly the MH may decline the MSR’s request for offloading its information but this time it would send it a Rendez-Vous message as well as the identity of a new "rendez-vous" MSR, see figure 9(d). The MSR would then initiate the transfer of all its I-TCP segments to the new MSR. The MSR would acknowledge transfer of all information to the new one (MSR-2) and send the original MSR a Ack-Forward and terminate its connection with the MH;

6.2 Handoff During Disconnection

According to I-TCP, all active connection states are transferred during handoff as shown in figure 6. Similarly, during handoff non active connection states are transferred to the new MSR using messages such as Mhstate, RecFwdPtr, RecFwdAck, Data and Ack depicted in figure 9.

7 Simulation of Disconnection

The I-TCP disconnection messages introduced earlier have been added to our initial simulation of I-TCP. So far we maintain that protocol modification may only occur at the wireless segment. Next, we sought to study the effect of parameters such as disconnection time and inter-disconnection time over end-to-end throughput. We also gave special interest to MSR buffer overload resulting from disconnection.

The simulation model was adapted, by adding new simulation parameters, in order to examine their relationship as well as allowing the transport level to predict disconnection the time limit it may support under specific conditions. At the end of this time limit, the MSR invites the MH to resume connection. In other words, we examined the relationship between i) cell configuration (with no moves and one second between overlapped cells); ii) disconnection time; iii) inter-disconnection time.

7.1 The New Parameters

The following new parameters have been added to the previous simulation model:

1. Link Capacity – Represents capacity of the fixed link (between the MSR and FH). Fixed connections are more likely to span through WANs, we used 64 kbps.

2. Disconnection Time – Represents the effective duration of a disconnection. On the one hand, unplanned disconnection have been modeled as those resulting from unwanted interference and loss of radio cover. Hence, we characterize these with short disconnection duration and high frequency. A uniform distribution with 10 seconds minimum and a 15 seconds maximum has been used to model disconnection time. On the other hand, planned disconnection are more likely to last considerably longer than unplanned ones and are less frequent. To reflect this, we used a uniform distribution with 180 and 300 seconds disconnection time minimum and maximum respectively.

3. Inter-Disconnection Time – Represents the time between disconnection. This parameter has been modeled as a linear factor of the disconnection time (where time of disconnection = factor * connection time). We look at how this factor influences transport recovery from disconnection. The simulation considers both 0.5 and 2 as average values for inter-disconnection time for both planned and unplanned disconnection. When this factor is 0.5, disconnection time is lower than MH connection time. Consequently, the MSR buffers tend to fill faster than when this factor is equal to 2. We also look at the influence of handoff on buffer occupation within each case.

4. MSR Buffer Size – Represents the space reserved for an MH while this is disconnected or in handoff. This has been fixed to 4.2Mb, corresponding to approximately 8000 buffers.

Two configurations, reflecting two practical scenarios, have been considered to simulate disconnection: in the first one, we assume that the MH remains in the same cell during the whole session (No Moves), whereas in the second scenario we consider cells which are 1 second distant from each others (1s between non-overlapped cells).

7.2 Simulation Results

Table 2 shows the values of disconnection time that can be supported for disconnection factors 0.5 and 2.0 for both the scenarios described earlier. Figure 10 (left) shows MSR buffer occupation for both scenarios when disconnection is unplanned using a 0.5 disconnection factor.

As a result of the high disconnection frequency, we see that MSR buffers tend to fill rapidly. We also see that this process is also speeded up with handoffs as shown by the second curve. Handoff effect is however minimum in this case because of the high frequency of disconnection as is often the case in unplanned disconnection.

Figure 10 (right) shows the same scenarios portrayed in figure 10 (left) with a connectivity factor of 2.0. Here, connection time is twice that of disconnection time, hence, reducing MSR’s buffer occupation rate.

Furthermore, since the MH spends a lot more time connected than disconnected, the effect of handoff on MSR buffer resources is more felt than in the case of a lower connectivity factor such as the one shown in figure 10 (left). This is clearly depicted by the increasing difference between the two graphs in figure 10 (right) where the upper one suffers from handoff causing it to increase each time its MSR buffer occupation.

Next we look at the behavior of planned disconnection which are characterized with a higher disconnection time and a lower disconnection frequency in our simulation. Figure 11 (left) shows that with a 0.5 factor, MSR buffer resources are rapidly consumed. We also see that handoffs result in an increase in buffer occupancy. More specifically, it was observed that the MH may adopt this behavior for a maximum time of approximately 16min and 42 seconds when there is a 1 second time between overlapped cells and 16 minutes and 20 seconds when there are no MH moves (see Table 2). The small difference is justifiable by the little effect of handoff when compared to a larger disconnection time.

Figure 11:
Planned Disconnection Buffer Occupation with a 0.5 and 2.0 Connectivity Factors

Finally, we consider planned disconnection with a higher connectivity factor, see figure 11 (right). The graphs show a considerable difference in terms of MSR buffer occupancy due to handoffs. Whereas in the case of no MH moves, it may remain up 1 hour and 12 seconds, this time drops sharply to a mere 46 minutes and 14 seconds where there is a 1 second between overlapped cells (see Table 2). This is an important result, namely that handoff has a considerable influence over planned disconnection performance.

8 Conclusions and Future Work

In this paper, we have first validated through simulation the I-TCP results presented in [2]. Then an extension of the I-TCP transport protocol has been described with the introduction of new messages for the support of disconnection mode operation. The conducted simulation has shown that whereas in the case of unplanned disconnection handoff effect is minimum, this may be quite considerable when considering planned disconnection. To our knowledge, this is the first detailed study of disconnection time effects.

Finally we suggest that disconnection is an important communication aspect and as such should be included as a QoS parameter for negotiation among communication entities. Currently, we are looking at the effect of reducing the MSR’s TCP reception window during disconnection on buffer occupation and end-to-end throughput. Further work is needed to analyze how applications would determine when to disconnect and for how long, therefore establishing clear disconnection conditions resulting in a tighter integration between existing application disconnection support with our extension to I-TCP.

Apendix

Figure 12 below shows a trace of round-trip delay between the two Internet hosts recife.di.ufpe.br and dcc.ufmg.br located in the north and south east of Brazil respectively with a minimum of 40ms. The data was obtained used the Unix ping command. A statistical analysis shows that the end-to-end delay between the two hosts may be seen as the sum of two items: a constant equal to the minimum delay (40ms) and a random Erlang distribution shown in figure 13. This fits an Erland distribution with two stages and mean of 0.01. In order to represent delay variations on LANs and WANs, we may select different values for the constant (first term representing the delay).

Figure 12
: Round-trip Trace

Figure 13
: Frequency Density of the Modified Data

9 References

[1] G. Alonso, R. Gunthor, M. Kamath, D. Agarwa, E. E. Abbadi and C. Mohan, IBM Amaden Research Center, 650 Harry Road, San Jose, CA 95120 - USA, 1995.

[2] A. Bakre and B. R. Badrinath. I-TCP: Indirect TCP for mobile hosts, Technical Report DCS-TR-314", Rutgers University, October, 1994.

[3] H. Balakrishnan, S. Seshan and R. Katz. Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks, University of California at Berkeley, 1995.

[4] http://www.altagroup.com (Altagroup, Bones Manuals).

[5] C. Bussler. User Mobility in Workflow Management Systems. Proceedings of the Telecommunications Information Networking Conference (TINA’95), Australia, Feb. 1995.

[6] R. Caceres and L. Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Enviroments. IEEE Journal on Selected Areas in Communications, 13(5):850-857, 1995.

[7] D. E. Comer. Internetworking with TCP/IP.,Volume 1, Principles, Protocols, and Architectures. Englewood Cliffs, NJ: Prentice-Hall, 1991.

[8] The Internet Mail Consortium, http://www.imc.org

[9] A. J. Demers, K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer and B. B. Welch. The Bayou Architecture: Support for data sharing among mobile users. Proceedings IEEEWorkShop on Mobile Computing Systems & Applications, Santa Cruz, California, 1994, pages 2-7.

[10] D. Dwyer and V. Bharghavan. A Mobility-Aware File System for Partially Connected Operation. Operating Systems Review, 31(1):24-30, 1997

[11] R. Guber, M. F.Kaashoek, B. Liskov and L. Shira. Disconected operation in the Thor object-oriented database system. In Proceedings of the Workshop on Mobile Computing Systems and Applications, pages 51- 56, Santa Cruz, CA, 1994.

[12] T. Imielinski and B. R. Badrinath. Mobile Wireless Computing: Solutions and Challenges in Data Management. Communications of the ACM, 37(10), October 1994.

[13] V. Jacobson. Congestion Avoidance and Control. Proceedings of the ACM SIGCOMM’88, Stanford, CA, pages 314-329, August, 1988.

[14] A. D. Joseph, A. F. Lespinasse, J. A. Tauber, D. K. Gifford and M. F. Kaashoek. Rover: A Toolkit for Mobile Information Access. In Proceedings of the Fifteenth Symposium on Operating Systems Principles, December 1995.

[15] T. Magedanz. Integration and Evolution of Existing Mobile Telecommunications Systems toward UMTS. IEEE Communications Magazine, September 1996;

[16] P. Manzoni, D. Ghosal and G. Serazzi. Impact of Mobility on TCP/IP: An integrated Performance Study. IEEE Journal on Selected Areas in Communications, 13(5): 858-867, 1995.

[17] A. Myles and D. Skellern. Comparing four IP based mobile host protocols. Computer Networks and {ISDN} Systems, Vol. 26, pages 349-355, 1993.

[18] P. Bhagwat, C. Perkins and S. Tripathi. Network Layer Mobility: An Architecture and Survey, IEEE Personal Communications, 3(3):54-64, June 1996

[19] M. Satyanarayanan, J. James, Kistler, L. B. Mummert, M. R. Ebling, P. Kumar and Q. Lu, Technical Report CMU-CS-93-168, USA, June 1993.

[20] M. Satyanarayanan. Mobile Information Access. IEEE Personal Communications, 3(1): 26-33, 1996.

[21] B. N. Schilit, F. Douglis, D. M. Cristol, P. Krzyzanowski, J. Sienicki, J. A. Trotter. TeleWeb: Loosely Connected Access to the World Wide Web. Journal reference: Computer Networks and ISDN Systems, Volume 28, issues 7-11, p. 1431.

[22] F. Teraoka, K. Uehara, H. Sunahara and J. Murai. VIP: A Protocol Providing Host Mobility. Technical Report, Sony Computer Science Laboratory Inc., 1994.

[23] M. M. Zoonozi and P. Dassanayake. User Mobility Modeling and Characterization of Mobility Patterns. IEEE Journal on Selected Areas in Communications, 15(7), 1997.

Publication Dates

• Publication in this collection
  31 July 2000
• Date of issue
  Feb 1999