Performance Evaluation of SCTP as a Transport Layer Solution for Wireless Multi-access Networks* Jinyang Shi1, Yuehui Jin1, Wei Guo1, Shiduan Cheng1, Hui Huang2, Dajiang Zhang2 1
National Key Lab of Switching Tech. and Telecom. Networks Beijing University of Posts & Telecom., Beijing 100876, P.R.China Tel: +86 10 6228 3761; Email:
[email protected], {yhjin, guowei, chsd}@bupt.edu.cn 2 Nokia China R&D Center, Beijing 100013, P.R.China Tel: +86 10 6539 2828; Email:
[email protected],
[email protected] distribute different traffic flows through different access interfaces in parallel for the best performance. 3) Alternate retransmission: this is also an issue of simultaneous multi-access. As for the reliable transport protocols, when the sender needs retransmission, this indicates that the current access network is enduring link error or congestion, so the retransmission via the alternate access network will bring a better chance of success. Since the different access networks show wide variations in bandwidth, delay and other characteristics, it is a challenge to provide possibly high performance, including connectivity, throughput and robustness, for these multi-access scenarios.
Abstract– Future communication systems might be characterized by an integration of multiple access systems, and people are expecting excellent multi-access solutions for better services. However, currently proposed solutions in different layers are unable to completely fulfill the requirements. In this paper, we put forward the Stream Control Transport Protocol (SCTP) as a transport layer approach for multi-access, and propose an efficient SCTP load-sharing enhancement. The evaluation of performance has been investigated in the key multi-access scenarios with theoretical analyses, simulations in NS and some Linux-kernel experiments. Since SCTP supplies an effective multi-homing mechanism and the transport layer solutions for multi-access can quickly adapt to the fluctuating network conditions, our SCTP approach is able to bring more throughput for the simultaneous multi-access, perform seamless behavior during the vertical handover between heterogeneous access networks, and provide better robustness and connectivity than other solutions in the wireless multi-access scenarios.
B.
Keywords– wireless networks, multi-access; SCTP; load sharing; vertical handover; alternate retransmission
I.
INTRODUCTION
With the explosive growth of Internet and wireless networks, the need for data access has caused the development of different kinds of access systems. Future communication systems might be characterized by an integration of multiple access technologies such as Bluetooth, WLAN systems, cellular GPRS/UMTS, even satellite and wired systems. Users are expecting more connectivity and better services via multi-access networks (e.g. a network with WCDMA and WLAN coverage using multi-mode mobile terminals supporting both technologies). A.
Multi-access Scenarios Multi-access has been discussed in the literature in varying contexts and for different scenarios. In this paper, multi-access is considered as the solution enabling the users to access the IP networks with multiple access technologies [1-2]. The key scenarios in the multi-access networks can be summarized as follows: 1) Vertical handover: A multi-access user should be able to roaming between heterogeneous access networks without breaking any existing connections, e.g. seamlessly handover from WLAN to GPRS. 2) Load sharing: the ability to use several available access paths simultaneously. The main issue is how to
Related Work
In general, the multiple access technologies normally consist of link layer, network layer, transport layer and application layer multi-access [3-9]. Mobile IPv6 has been frequently considered to implement network layer multi-access [2][5][9]. However, compared with transport layer solutions, the network layer solutions know nothing about the congestion or link error factor, and cannot efficiently adapt to the fluctuating access network conditions, thus have their limitations to completely fulfill the multi-access requirements, e.g. seamless handover in section 5. Therefore, we put forward SCTP as a transport layer approach for multi-access. SCTP is a new general-purpose transport layer protocol developed by the IETF [10-14]. SCTP can support multi-homing, and has respective congestion control for each of the multiple transport paths within a connection (association). Fig. 1 gives a typical SCTP multi-homing model. The SCTP multi-homing mechanism can provide a good technology basis for alternate retransmission and transport layer handover, and the load-sharing enhancement we propose can further use all the available access paths to transmit data simultaneously. SCTP host D
SCTP host S Path1
Interface A x.x.x.a Interface C 3ffe:y:y:y::c
Path2
IP Networks
Interface B x.x.x.b Interface D 3ffe:y:y:y::d
Fig. 1. SCTP multi-homing model
*This work is supported by Nokia (China) R&D Center and National Natural Science Foundation of China (No. 90204003).
WCNC 2004 / IEEE Communications Society
453
0-7803-8344-3/04/$20.00 © 2004 IEEE
B.
The main contribution of this work is to investigate the performance advantages of transport layer solutions for multi-access, and will help to find promising applications in wireless networks. Since transport layer can quickly adapt its congestion and flow control parameters to the fluctuating network conditions, the transport layer solutions for wireless multi-access is able to improve the parameter adaptation and gain better performance, and might be the more flexible and effective ways than other layer solutions. Another contribution is the SCTP load sharing, which is still deemed an open issue by the IETF. In this paper, we propose a substantial enhancement to aggregate the available bandwidth on the multiple paths. Moreover, a SCTP sender with our enhancement can communicate with any other SCTP receiver with or without the load-sharing support. This enhancement will help the applications to gain higher throughput, especially in wireless multi-access networks with limited bandwidth and high error rate. This paper will put forward SCTP as a transport layer approach for multi-access, and compare its performance with that of other layer solutions, especially mobile IPv6 as the network layer solution, in the three multi-access scenarios. Throughput, connectivity, and robustness will be considered as the key performance metrics. In the next section, we describe the SCTP approach in detail, and propose a SCTP load-sharing enhancement. Section 3 evaluates the load-sharing throughput with some theoretical analyses and simulations in NS-2. In section 4 and section 5, Linux-kernel experiments are carried out to evaluate the SCTP performance for seamless vertical handover and alternate retransmission respectively. Finally, we present a brief survey of multi-access in different layers, along with the pros and cons in section 6, and section 7 concludes the whole paper. II.
Different from TCP, SCTP has a separate set of congestion control parameters for each of the multiple transport paths within an association. While compared with the application layer solutions, SCTP maintains a single buffer in common for the multiple paths within an association to perform flow control. C.
Access network 1
3ffe:x:x:x::a
Overlap
Access network 2
3ffe:x:x:x::a 3ffe:y:y:y::c
3ffe:y:y:y::c
Fig. 2. SCTP ADDIP model
Fig. 2 gives an illustration. Based on this ADDIP extension that supplies one feasible connection forwarding method, SCTP can provide a possible solution for transport layer handover and mobility in an end-to-end fashion. D.
SCTP Load-sharing Enhancement
Currently SCTP multi-homing is only used to provide fault tolerance, and SCTP load sharing is still deemed a research topic by the IETF [13]. In this section, we try to propose a substantial enhancement to achieve end-to-end load sharing. Other than the traditional methods that distribute the traffic based on the fixed link bandwidth of the paths, load sharing in transport layer can further consider the congestion factor, especially the fluctuating available bandwidth. 1) Congestion Window Based Scheme This enhancement will distribute the traffic according to congestion control window (CWND) parameters of the multiple access paths, which is adjusted by the sender based on observed network conditions and is a rough approximation of the available bandwidth-delay product. When the primary path’s CWND is used up, a next path will be selected and carry on the transmission. If the CWND of the next path is also used up, the sender will continue to choose another eligible path and perform the same procedure. Not all the access paths are suitable for load sharing, the following paragraphs will give some criterions for path selections.
SCTP APPROACH FOR MULTI-ACCESS
SCTP Multi-homing Mechanism
A SCTP multi-homed connection (association) can effectively control and aggregate the multiple IP addresses for sending and receiving data. The mechanism of using multiple addresses can be illustrated as Fig. 1. --- Changeover policy: the sender (host S) will continuously monitor whether the IP addresses of the receiver (host D) are reachable, if the access path1 to the primary transport address (x.x.x.b) fails, the sender can switch to the alternate path2 to another transport address (3ffe:y:y:y::d) of the receiver. --- Retransmission policy: When the sender (host S) needs retransmission, this indicates that the current network path1 is enduring link error or congestion, and the sender will retransmit to a different active transport address (3ffe:y:y:y::d) via path2 than the original transmission.
WCNC 2004 / IEEE Communications Society
Dynamic Address Reconfiguration
The multiple IP addresses of a multi-homed host are originally fixed. A recent SCTP ADDIP extension has been proposed to offer the ability of dynamic addition and deletion of IP addresses at source or destination [11]. Based on this extension, our approach is to let a multi-access SCTP host reconfigure the IP addresses in the existing association dynamically, during the handover when the multiple access networks are available simultaneously.
SCTP is a reliable, message-oriented, multi-homed transport protocol proposed by the IETF [10]. It is at the equivalent layer of TCP and UDP, while it overcomes some limitations of them. A SCTP multi-homed host has more than one IP address, and these multiple IP addresses can be accessible via separate access network paths. A.
SCTP Congestion and Flow Control
2) Path Selection Policy The different paths may differ greatly in data rate, delay, etc. Transmission on different paths may bring the possibility of out-of-order packets at the receiver, and thus result in some
454
0-7803-8344-3/04/$20.00 © 2004 IEEE
1) As for the SCTP load-sharing scheme based on the approximate available bandwidth in transport layer, suppose s1 and s2 are the traffic distribution partitions for path1 and
side effects. Therefore, the transport paths for load sharing should be selected carefully. In our approach, the primary path depending on the use's desire is always the first selection. If its CWND is used up, the next eligible path will be selected from a set of backup paths given as follows: P = {p | (p is active) & (the error count of p = 0)}
path2 respectively, then a1 s1 = iS a1 + a2 Therefore we can get:
(1)
In (1), P is the backup path set and p is the eligible element for selection. Then we consider the round trip time (RTT) as the criteria, and the next path p will be chosen for sharing traffic according to (2). This policy intends to reduce the possibility of loss-of-order and bring better throughput.
p = (p | p ∈ P & p has the minimum RTT)
2 i
2
2 i
t1 = s1 / a1 =
(3)
Where X and Y are two set of sample packet delay values, and E[x] means the average value of the X set. C xy is the correlation coefficient of X and Y. If C xy is equal to zero, this means the two samples show no linear relationship. We use the RTT of the DATA chunks and SCTP HEARTBEAT chunks as the sample packet delays, to calculate the correlation statistically and try to deal with the shared bottleneck problem. In addition, our load-sharing enhancement is only an improvement on the SCTP sender, therefore a SCTP endpoint with our enhancement can communicate with any other SCTP receiver with or without the load-sharing support.
and
t 2 = s 2 / a2 =
S ib2 (b1 + b2 )ia2
therefore the total required transfer time T ′′′ will be: S ib1 T ′′′ = max(t1 , t2 ) = (b1 + b2 )i a1
(6)
3) Finally, we combine the equation (5) and (6): T ′′′ S ib1 S (a + a )ib a ib + a ib / = = 1 2 1= 1 1 2 1 (b1 + b2 )i a1 a1 + a2 (b1 + b2 )ia1 a1 ib1 + a1 ib2 T
Consider the above assumption: b1 / a1 >> b2 / a2 , that is a2 ib1 >> a1 ib2 , therefore: (7) T ′′′ / T = (a1 ib1 + a2 ib1 ) /(a1 ib1 + a1 ib2 ) >> 1 Equation (7) gives the conclusion that the total required transfer time of network layer solutions T ′′′ is much more than that of the SCTP approach T, therefore, the SCTP solution for multi-access with the load-sharing enhancement can bring remarkably better throughput performance in this scenario.
III. PERFORMANCE EVALUATION FOR LOAD SHARING In contrast to other works for multi-access, e.g. network layer solutions, that distribute the traffic according to the fixed link bandwidth, SCTP load sharing in transport layer will be based on the approximate available bandwidth of the multiple paths. This section begins to evaluate the throughput performance of SCTP approach in the load-sharing scenario.
B. Simulation Results We implement the load-sharing enhancement on the SCTP NS simulation [16][17], and compare it with IP-layer solutions that distribute traffic according to the fixed link bandwidth.
A. Analytical model A two-path example is illustrated as Fig. 1. Suppose there are S bytes data in the sender’s buffer, the link bandwidth for path1 and path2 are b1 and b2 respectively, and the current
Path 1 (1.5 Mbps, 10 ms delay)
S
Thus the
R1
1.5 Mbps 10 ms delay
R2
Path 2
D
Path 3
Path 4 (1.5 Mbps, 10 ms delay)
(4)
Fig. 3. Simulation networks topology
Where t1 and t2 are the required transfer time on path1 and path2 respectively.
WCNC 2004 / IEEE Communications Society
S ib1 (b1 + b2 )ia1
Suppose b1 / a1 >> b2 / a2 , then we will get t1 >> t2 ,
( E [ x ] − E [ x i ])( E [ y ] − E [ y i ])
T = max(t1 , t2 )
(5)
2) As for the network layer solutions that distribute the traffic based on the fixed link bandwidth: b2 b1 s1 = iS i S and s2 = b1 + b2 b1 + b2 Since the current available bandwidth for path1 and path2 are a1 and a2 respectively, we can get:
2
available bandwidth are a1 and a2 respectively. total required transfer time T will be:
a2 iS a1 + a2
S = s2 / a2 = t2 a1 + a2 So the total required transfer time T will be: S T = max(t1 , t2 ) = a1 + a2
(2)
E [ x i y i ] − E [ x i ]E [ y i ]
s2 =
t1 = s1 / a1 =
3) Shared Bottleneck Detection If the multiple transport paths share a same bottleneck, load sharing will affect the TCP friendliness and the fairness of the aggregate connections on the bottleneck. Since the delays experienced by the packets passing through the same bottleneck will exhibit some degree of correlation, a general correlation algorithm described in [15], is used to detect the shared bottleneck paths:
C xy =
and
The simulation topology is shown in Fig 3. There are four access paths between Node S and Node D, and 10×100,000
455
0-7803-8344-3/04/$20.00 © 2004 IEEE
bytes data will be transmitted from Node S to Node D. The background traffic will be introduced on the paths, which assumes SCTP traffic as well. Node R1 and Node R2 are
B.
The network layer (layer-3) handover by mobile IPv6 and the transport layer (layer-4) handover by SCTP are compared. The upper application sends 800 messages continuously, with the message size of 1280 bytes, and each message contains a number identification. We observe the received timestamp of every message, and their message number identifications (MNID). Fig.5 gives the results.
designed for shared bottleneck detection. SIMULATION RESULTS
Background Traffic
Link Packet Loss Rate
Transmission Time Span (s)
SCTP
No
1%
IP-layer solution SCTP
No Yes
1%
6.835765
1%
8.668651
IP-layer solution
Yes
1%
15.353833
6.926203
800 700
Received message number ID
TABLE I Load-Sharing Scheme
The simulation results given in Table I show that: 1) If the access paths ideally have no background traffic, SCTP gains similar performance as IP-layer solutions; 2) From the aspect of background traffic, SCTP load-sharing scheme thus gains higher throughput, saving about 43% transmission time over the IP-layer solution that distribute the traffic according to the fixed link bandwidth. Therefore, we can conclude that the SCTP load-sharing enhancement is a feasible scheme, and can bring better throughput performance for the simultaneous multi-access.
Vertical handover
600 500
TCP breaking
400 300 200
SCTP using layer-4 handover TCP using layer-3 handover
100 0 0
Fig. 5:
Authors of this paper have participated in the open source Linux kernel SCTP project [18], which has been integrated into the recently issued Linux 2.5 Kernel, a wide-applied operation system. This section therefore will investigate a multi-access scenario experiment based on the Linux kernel implementation, and evaluate the connectivity performance of SCTP approach for the seamless vertical handover.
10
12
14
rttG . So,
BW × rtt W
(8)
Where cwnd W is the current CWND for the WLAN access path. After the vertical handover to GPRS access network with lower bandwidth, the new bandwidth-delay product for the transport layer connection should be BG × rttG . At the same time, when the terminal moves from WLAN access to GPRS access, the transport layer connection knows nothing about the layer-3 vertical handover by mobile IP, and it will continue with high data rate using cwnd W , However:
GPRS access 40kbps
BW >> BG and rttW
Therefore:
cwnd W
rttG
BW × rttW >> BG × rttG
(9)
Equation (9) shows that current data rate has extremely gone beyond the new access network capacity, this will lead to continuous data loss in GPRS access network with lower bandwidth, and might thus result in connection breaking. To go deep into this layer-3 handover issue, we modify the SCTP Linux kernel stack, and track the congestion control parameters, such as CWND and round trip timeout (RTO), of SCTP connection using layer-3 handover by mobile IP and SCTP using layer-4 handover by itself respectively. Fig. 6 gives some details. After the vertical handover, continuous data loss will reduce the CWND sharply. While the large amount outstanding data have to wait for enough CWND,
50ms delay, negligible loss
Sender Host
Fig.4: Experimental set-up for vertical handover scenario
The NISTNet tool has the ability to imitate the access network by emulating the adjustable bandwidth, packet loss, delays, and so on. The characteristics of the two access networks are configured as shown in Fig. 4. A vertical handover will happen from WLAN access to GPRS access network during the communication.
WCNC 2004 / IEEE Communications Society
8
MNID of vertical handover in layer-4 vs. in layer-3
cwnd W
NISTNet Linux Emulator
6
and BG respectively, and the RTT parameters rttW
The multi-access environment is set up that a multi-homed SCTP terminal accesses the IP networks via both WLAN and GPRS access networks. As shown in Fig. 4, two SCTP hosts are interconnected via a Linux Emulator that runs the NISTNet software [19], and the receiver can connect with emulator via two interfaces with two IP addresses.
WLAN access 2Mbps
4
From the graph, we can find that TCP connection using layer-3 handover is very likely to suffer from breaking, after the vertical handover from an access network with high bandwidth to another with low bandwidth. Suppose the bandwidth for WLAN and GPRS are BW
Experimental Set-up
Receiver Host
2
Received time (sec)
IV. PERFORMANCE EVALUATION FOR VERTICAL HANDOVER
A.
Results and Analysis
456
0-7803-8344-3/04/$20.00 © 2004 IEEE
and the connection will break when waiting. Only the successful retransmission of the large amount lost data will increase the CWND. However, the RTO of SCTP using layer-3 handover by mobile IP has doubled several times: (10) RTO ← RTO × 2 K So the expected retransmission will also stall for a long waiting time. Such layer-3 handover scenario is very likely to cause transport layer connection breaking. 55000
This section further supplies some theoretical analyses for [14]. Suppose l1 and l2 are the loss probability of path1 and path2 respectively, when the sender needs retransmission, this indicates that the current access network path1 is enduring link error or congestion, that is l1 > l2 . If the layer-4 connection is in the congestion-avoidance phase, the mean of CWND after retransmission via path1 is: E ( cwnd 1 ) =
(Vertical handover)
Congestion window (CWND)
cwnd i p i i
= ( cwnd + M TU ) i (1 − l1 ) + M TU il1 = ( cwnd + M TU ) − cwnd i l1 where p is the probability. Therefore, E (cwnd1 ) − E (cwnd 2 ) = cwnd i(l2 − l1 ) < 0
45000 40000 35000 30000
(11)
If the layer-4 connection is in the slow-start phase, we get:
25000 20000
E (cwnd1 ) − E (cwnd 2 ) = cwnd i(l2 − l1 )i(3 / 2) < 0 (12) Equation (11) and (12) show that according to the SCTP retransmission policy, the retransmission via the alternate finer path2 will not only provide a better chance of success, but also bring more throughput without much additional bandwidth.
(Connection breaking)
15000 10000
SCTP using layer-4 handover SCTP using layer-3 handover
5000 0
2
4
6
8
10
12
14 220
Time (sec)
multi-homed SCTP single-homed TCP
200
CWND of vertical handover in layer-4 vs. in layer-3 Received message number ID
Fig. 6:
∑
i = loss
50000
0
success
As for the SCTP using layer-4 handover, when the association makes changeover from one access network to another, it uses the separate set of congestion control parameters for each of the multiple transport paths, e.g. CWND. Thus it can adjust the parameters more sensitive, that is, it can reduce CWND earlier and increase RTO later! Therefore, as shown in Fig. 5, our SCTP approach using layer-4 handover is able to avoid the breaking problem and perform seamless behavior when vertical handover between heterogeneous access networks happens, thus bring better connectivity performance for the multi-access scenario.
180 160
collided or congested period
140 120 100 80 60 40 20 0 0
2
4
6
8
10
12
Received time (sec)
Fig. 8: MNID of alternate retransmission SCTP vs. original TCP
V. PERFORMANCE EVALUATION FOR RETRANSMISSION
We compared the single-homed TCP case over WLAN, with the multi-homed SCTP case over both WLAN and GPRS. Fig. 8 gives the result that the TCP connection suffered from severe losses caused by the certain loss that happened in the data-link layer. While SCTP can make use of the alternate retransmission policy, gain an inspiringly better performance, about nine times throughout over TCP in this wireless access scenario, and recover more quickly from the network accident. For the sake of space limitation, more details can be found in [14]. Since only the SCTP solution in transport layer can provide the ability of alternate retransmission, we can conclude that the SCTP approach is able to provide better robustness performance over other solutions, and bring more throughput without much additional bandwidth in the wireless multi-access scenario.
The performance of WLAN is likely to suffer from the radio frequency interference, or the problems of hidden terminal and multi-hop. In a recent conference, we proposed a SCTP multi-homing scheme, using GPRS for retransmission when WLAN connection is interfered, collided or congested [14]. We also investigated a Linux kernel experiment similar to that in section 4. Fig. 7 gives the experimental set-up. SCTP Peer Host
25ms delay
NISTNet Linux Emulator
WLAN access 11Mbps, 0% loss => 5.5 Mbps, 40% loss
GPRS access 40kbps, 0% loss up, 3% loss down
SCTP Local Host
VI.
Lots of multi-access solutions have been proposed to operate on the data-link layer, such as multi-link PPP [3],
Fig.7: Experimental set-up for alternate retransmission
WCNC 2004 / IEEE Communications Society
COMPARISON WITH RELATED WORK
457
0-7803-8344-3/04/$20.00 © 2004 IEEE
which tries to bundle multiple data-link level access channels into a single logical link. Multi-access in data-link layer can be possibly transparent to upper layers, and will bring faster handover than higher layers. However, it is highly unlikely that the independent ISPs will allow arbitrary users to bundle their links into "one logical link" [4]. Thus, multi-access in link layer has too many limitations, e.g. the vertical handover between different ISPs’ access networks. Mobile IPv6 has been frequently considered to implement network layer multi-access [2][5][9]. Both endpoints of a connection can keep the same IP address during the life of the session, and all the transport layer protocols will benefit. Maybe this is its potential advantage over our SCTP approach. However, as has been investigated in the above sections, since the network layer solutions cannot efficiently adapt to the fluctuating access network conditions, it might result in less throughput or be likely to suffer from breaking. In addition, mobile IPv6 will bring additional "ownership" security problem and routing complexity [6]. Paper [6] introduces a new host identify layer between the IP layer and the upper layers, and proposes a novel solutions: Host Identification Protocol (HIP), which tries to solve the complexity problems of mobile IPv6. But HIP also cannot supply separate congestion control for each access path, and will suffer from the same problem as mobile IPv6. Reference [7] proposes a transport layer approach called parallel-TCP (pTCP), which can use several TCP-v pipes with a data striping mechanisms, and the Reliable Multiplexing Transport Protocol (RMTP) in [8] is a rate-based layer-4 approach for aggregate bandwidth on multi-homed mobile hosts. But all of them do not consider layer-4 handover explicitly, and are short of a mechanism to control the multiple access paths dynamically for handover as SCTP. As for application layer and session layer multi-access, such as multiple sockets, they cannot support mobility and have to break the existing transport layer connection during handover. Moreover, the applications have to perform multiple flow control for the several access networks, while the different data rates of these access networks will eventually lead to the buffer overflowing of the faster access connection, so it has to stall [7]. Such head-of-line blocking will possibly result in worse performance than using a single access network alone. VII. CONCLUSIONS In this paper, we investigate the three key scenarios for multi-access: seamless vertical handover, load sharing and alternate retransmission, and find that currently proposed solutions are unable to completely satisfy the requirements. Therefore, we put forward SCTP as a transport layer approach, and propose a load-sharing enhancement based on the congestion control window. The theoretical analyses and simulation results show that the SCTP load-sharing enhancement can bring more throughput for simultaneous multi-access. Moreover, through the Linux-kernel experiments, we find the SCTP approach is able to avoid the breaking problem and supply more robustness than other solutions. Therefore, we conclude that the proposed SCTP approach can
WCNC 2004 / IEEE Communications Society
458
provide a better solution for multi-access. Our future work will continue the study of Authentication, Authorization and Accounting (AAA) over SCTP, since the wireless multi-access terminals will roam between different ISPs frequently. ACKNOWLEDGMENT We would like to thank the people who supplied their warmhearted advices, especially Ivan Arias Rodriguez in Nokia, and Jon Grimm in IBM Linux Technology Center. REFERENCES [1] [2] [3] [4]
[5]
[6]
[7] [8] [9] [10] [11]
[12] [13] [14]
[15] [16] [17] [18] [19]
Teemu Rinta-aho "Multi-access, go for better life – seminar /HUT", NomadicLab, Ericsson Research, Http://www.cs.hut.fi/Opinnot/T- k2002/ go-multiaccess.pdf, Apr. 2002, Nokia White Paper, "Mobile IPv6 - an enabler for service mobility in a multi-access environment", Apr. 2002, Http://www.nokia.com/downloads/solutions/operators/Nokia_MIPv6.pdf K. Sklower, B. Lloyd, G. McGrego, D. Carr, and T. Coradetti, "The PPP Multilink Protocol (MP)", IETF RFC1990, Aug. 1996, http://www.ietf.org/rfc/rfc1990.txt D. S. Phatak, Tom Goff "A Novel Mechanism for Data Streaming Across Multiple IP Links for Improving Throughput and Reliability in Mobile Environments", Proceedings of IEEE INFOCOM'02, vol.2, pp. 773 –781, New York, Jun. 2002 Tony.Jokikyyny "Session Continuity using Mobile IPv6 in a Multiaccess Network", TEKES Nets 1a Seminar, NomadicLab, Ericsson Research, http://akseli.tekes.fi/Resource.phx/tivi/nets/netsaiheryhma1aseminaarikut su.htx.liite.liitteet.6.ppt, Sep. 2002 Pekka Nikander, Jukka Ylitalo, and Jorma Wall "Integrating Security, Mobility, and Multi-Homing in a HIP Way", Proceedings of Network and Distributed Systems Security Symposium (NDSS'03), pp. 87-99, San Diego, CA, Feb. 2003 H.-Y. Hsieh and R. Sivakumar, "A Transport Layer Approach for Achieving Aggregate Bandwidths on Multi-homed Mobile Hosts." ACM/IEEE MOBICOM’02, Atlanta, GA USA, Sep. 23-28, 2002 L. Magalhaes and R. Kravets "Transport level mechanisms for bandwidth aggregation on mobile hosts." Proceedings of IEEE ICNP’01, pp. 165 –171, Nov. 2001 David B. Johnson, Charles E. Perkins, Jari Arkko "Mobility Support in IPv6", IETF Internet-Draft, work in progress, Jun. 2003, http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. chwarzbauer, T. Taylor, et al. "Stream Control Transmission Protocol", IETF RFC 2960, Oct. 2000, http://www.ietf.org/rfc/rfc2960.txt R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, I. Rytina, M. Belinchon, et al. "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", IETF Internet-Draft, work in progress, Sep. 2003 http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-08.txt M. Riegel, M. Tuexen, Ed. "Mobile SCTP", IETF Internet-Draft, work in progress, Aug. 2003, http://www.ietf.org/internet-drafts/draft-riegel-tuexen-mobile-sctp-03.txt A. Abd El Al, T. Saadawi, M. Lee "Load Sharing in Stream Control Transmission Protocol", IETF Internet-Draft, work in progress, http://www.ietf.org/internet-drafts/draft-ahmed-lssctp-00.txt, May 2003 Jinyang Shi, Yuehui Jin, Hui Huang, Dajiang Zhang "Experimental Performance Studies of SCTP in Wireless Access Networks", Proceedings of IEEE International Conference on Communication Technology (ICCT'03), vol.1, pp.392-395, Apr. 2003 D. Rubenstein, J. Kurose, D. Towsley, "Detecting Shared Congestion of Flows Via End-to-End Measurement", IEEE/ACM Transactions on Networking, Vol. 10, No. 3, pp. 381-395. Jun. 2002 Guo Wei, Jin Yuehui, Le Huihua, Wang Hongtao, Zhang Dongmei "SCTP simulation on NS", Proceedings of IEEE ICII'01, vol.2, pp. 345–350, Oct. 2001 "NS Simulation Tool", Http://mash.cs.berkeley.edu/ns/ La Monte H.P. Yarroll, Karl Knutson "Linux Kernel SCTP: The Third Transport", Http://sourceforge.net/projects/lksctp/ Carson "NIST Network Emulator Tool", Jun. 1998, Http://www.antd.nist.gov/itg/nistnet/
0-7803-8344-3/04/$20.00 © 2004 IEEE
