A Robust Method for Soft IP Handover

Transcription

1 A Robust Method for Soft IP Handover The mobile multimedia streaming protocol supports bicasting and forward error correction for end-to-end connections, increasing the quality of wireless multimedia applications. Hosei Matsuoka, Takeshi Yoshimura, and Tomoyuki Ohya NTT DoCoMo Multimedia streaming over wireless networks often called mobile multimedia streaming lets users access music, movie, and news services at any time, regardless of location. Given that multimedia streaming is a key goal of third-generation and future wireless networks, vendors will soon deploy streaming clients in advanced mobile terminals. Current mobile terminals, however, fail to adequately support mobile multimedia communication because wireless networks have high packet-loss rates. Packets passing over wireless links are more susceptible to loss than those passing over wired links for two main reasons: Mobile terminals frequently move between radio access points, requiring a handover between points. If the new access point is associated with a new subnet, changes in the IP address of a mobile terminal might occur and packets destined for that terminal would be undeliverable. Mobile IP tackles this problem by offering IP handover in the network layer level. 1 However, until the sender is notified of the new address, packets can still be dropped during handover. While retransmission can recover missing packets, this is inadequate for some real-time applications because delays can hinder the VCR-like functionalities, such as fast forward and rewind, in interactive streaming applications. The delays are much more grave for bidirectional real-time communications. Most wireless links suffer severe fading, noise, and other interference factors, and so have relatively high biterror rates. Our work addresses both of these problems. To eliminate packet loss during handover, we use a packet path diversity scheme 2 and an end-to-end bicasting mechanism that enables soft IP handover. To offset wireless errors, we use a forward 18 MARCH APRIL 2003 Published by the IEEE Computer Society /03/$ IEEE IEEE INTERNET COMPUTING

2 Soft IP Handover error correction (FEC) scheme 3 and embed it in the bicasting mechanism. Our bicasting method encodes the data stream and then splits it, providing more effective diversity than general bicasting, which sends the same data down both paths. 4 To support our method, we propose the mobile multimedia streaming protocol (MMSP), a new transport-layer protocol that supports multihoming and bicasting in combination with FEC. Our main design goal was to ensure that the existing IP network not be changed, as changes can hinder wide and rapid deployment. Although IPv6 s value and technical potential is clear, its deployment is rather slow. Therefore, we decided not to require alterations to either the existing IPv4 network or the forthcoming IPv6 network. Adding this new protocol to the current transport layer will let future networks support a much wider variety of applications. Problem Overview To realize terminal mobility among IP subnets, the Internet Engineering Task Force proposed Mobile IP, and Mobile IPv6 is now on its way to becoming a standard ( mobileip-charter.html). Mobile IP lets a host transparently change its IP network attachment point. In both IPv4 and IPv6 networks, however, handover causes packet loss of some duration. Until the mobile node notifies the home agent of the change in the mobile node s address (the care-of address), mobile node traffic is sent to the old address and is thus dropped. If the mobile node is some distance from the home agent, it might take upwards of 100 milliseconds to send the binding updates. This routing update latency can drop many packets bound for the mobile node. Mobile IPv6 route optimization allows direct communication between the correspondent node and the mobile node, but the packet-loss duration during handover would increase with the distance between the two nodes. Hierarchical mobile IPv6 5 partially solves this problem, using mobility anchor points in foreign networks to manage routing changes within their domain. Correspondent nodes contain the mobile agent s regional or hierarchical address rather than the mobile node s address. This solution reduces the duration of packet loss. Fast handover 6 also minimizes packet-loss duration. The mobile node obtains a new address for the new access router while still connected to the old access router. The mobile node then sends the binding update to the old access router, which redirects packets to the new Cost of network change FMIPv6 (Fast handover) HMIPv6 (Hierarchical mobile IP) Packet loss duration during handover care-of address. When the mobile node reaches the new link and establishes Layer 2 connectivity, it can restart the packet-receiving process. No extra delay is necessary for establishing Layer 3 connectivity because the old access router is already sending packets to the new address. This mechanism can reduce packet loss duration to the time required by the Layer 2 handover if the mobile node s redirection and actual movement are synchronized. Fast handover with simultaneous bindings and bicasting 4 works well and does not need synchronization. However, these solutions require considerable changes to existing IP networks. End-to-end approaches are another proposed solution. 7 Such methods require no change to the IP substrate, but instead modify the transport layer and end-host applications. The Domain Name Service already provides a host-location service; mobile nodes typically use DNS support of secure dynamic updates 8 to update their location as they change their networks and attachment points. The IP address serves as a routing locator, reflecting the addressee s attachment point in the network topology. In such an architecture, there is no need for an additional third-party agent. However, the packet-loss duration during handover becomes considerable when the mobile node is some distance from the correspondent node. As Figure 1 shows, current solutions to the packet-loss problem create a trade-off between the costs of network change and packet-loss duration during handover. Mobile IP with Fast Handover eliminates handover loss, but requires additional functions in all network access routers, increasing network End-to-end approaches Figure 1. Trade-offs in current solutions to packet loss problems. As the duration of packet loss diminishes, the cost of network changes IEEE INTERNET COMPUTING MARCH APRIL

3 deployment costs. End-to-end approaches require no changes to the existing network, but they suffer considerable packet loss during handover. A New Mobility Architecture The mobility architecture we developed at DoCo- Mo is basically an end-to-end approach that provides multihoming and bicasting mechanisms combined with FEC. Our approach eliminates both packet loss during handover and network changes; the trade-off is that the connection s bandwidth doubles during handover. Multihoming Using multihoming, a single end point can use more than one IP network interface within a connection. Each interface can obtain its own IP address using any address-allocation mechanism, such as the dynamic host configuration protocol (DHCP) or the router advertisement on IPv6. A single connection can involve the IP addresses of multiple interfaces. Multihoming s advantages are load sharing, connection redundancy, and performance improvement. In our system, multihoming s main target is the soft handover between two different IP addresses at the same end point. Multihoming also forces the host to choose the source and destination addresses. TCP makes this choice when the connection is instantiated, while the stream control transmission protocol (SCTP) 9 makes similar choices throughout the connection s lifetime, and the user datagram protocol (UDP) makes the choice either for each packet or at the beginning of an association. In our method, the host assigns a priority to each source and destination address, which lets it choose the addresses with the highest priority. The host can dynamically change address priority based on Layer 2 information, such as the received signal intensity and the available bandwidth. When the host has addresses associated with wideband code division multiple access (W CDMA) and wireless LAN links, for example, the address associated with the wireless LAN link would have higher priority because its wireless bandwidth is wider. When the host has two addresses associated with different wireless LAN links, it would prioritize the address associated with the link offering higher signal strength. Bicasting When the mobile node moves to another network attachment point during a connection, the correspondent node is directly informed of the mobile node s new IP address. We assume that the mobile node passes through a region where two different cells overlap and it can access two different access points simultaneously. When the mobile node enters the overlap region and gets a new IP address, it sends a packet requesting that the correspondent node add the mobile node s new IP address to its destination address list. When the mobile node leaves the overlap region and the old IP address becomes inactive, the mobile node sends a packet requesting that the correspondent node delete the mobile node s stale IP address from the destination address list. Because the communication involves more than one access point, bicasting can offer soft IP handover. When the mobile node is in a cell-overlap region, it might have two different IP addresses; if both links have a weak signal strength, then both addresses have the same low priority. In this situation, the correspondent node copies the packets and sends copies to each destination address. On receipt, the mobile node discards the duplicated packets. If the signal strength of one link exceeds a certain threshold, then its associated address has high priority. In such cases, the mobile node informs the correspondent node of a change in the link s address priority and stops copying and sending packets to the other destination address. The mobile node can move from one cell to another without interrupting packet reception. This bicasting method can manage both soft horizontal handover and soft vertical handover because it is based on the prioritized IP addresses and is independent of network type. Also, even if the mobile node moves into the blackout area, it can start receiving packets again when it reenters the service area. The method s differences in delay and bandwidth, however, demand that the application intelligently adapt. Bicasting and FEC Sending exactly the same packet stream through different paths is inefficient in terms of error resiliency because the duplicate packets received are unnecessary. Our architecture supports a simple way to improve robustness against wireless errors. When the mobile node is in an overlap region, the radio waves from both radio access points are usually weak, and bit-error rates are likely to be high. If the same packet is lost on both wireless links due to bit errors, the packet cannot be received. To improve error resiliency, our architecture uses a Reed-Solomon FEC algorithm to code the original packet stream, and then splits the encoded stream. Although Reed-Solomon codes can overcome both erasures and bit-level corruption, MARCH APRIL IEEE INTERNET COMPUTING

4 Soft IP Handover Application layer Application data Fragmentation Transport layer D1 D2 D3 Create redundant symbols D1 D2 D3 F1 F2 F3 Attach transport layer headers D1 D2 D3 F1 F2 F3 Network layer D1 D3 F2 D2 F1 F3 Attach IP headers for destination 1 Attach IP headers for destination 2 D1 D3 F2 D2 F1 F3 Figure 2. Fragmentation and forward error correction. The transport layer creates an equal number of redundant symbols as data symbols, then splits the symbols into two groups and sends one to each destination address. an IP network requires only erasure codes because the network layer detects and discards corrupted packets. Packet-level Reed-Solomon code 11 requires byte-organized data. By extending each message from k symbols to n symbols through the addition of (n k) redundant symbols, we can detect and recover up to (n k) corrupted symbols within the extended message. Figure 2 shows the fragmentation and FEC encoding process. The transport layer fragments an application message into segments, padding the last segment to align the segment size. It then creates the same number of redundant symbols as data symbols, that is, n = 2k. Next, the transport layer and network layer add each layer header to each data symbol and redundant symbol. Then, the network layer transmits half of them to each destination address. In this case, it can recover any missing packets up to a total of k on both network paths. The data loss probability is therefore much lower than it would be if the data were simply copied. Implementation To support our mobility architecture, we implemented an MMSP stack in the FreeBSD 4.5 kernel. Like UDP, MMSP is a datagram-oriented protocol. Protocol Header Format Figure 3 shows the MMSP header fields. Without options, MMSP s typical header size is 12 bytes. General header Source port number MMSP length Packet type Block sequence Move option Address operation Packet sequence Address family Network address 32 bit Destination port number MMSP checksum Address priority Block length Reserved Figure 3. Mobile multimedia streaming protocol (MMSP) header format. Each line is transmitted in order and equals 4 bytes in the 32-bit value. The Move option is attached in move packets following the MMSP s general header. The port numbers identify the sending and receiving processes. The header also includes: The MMSP length field (16 bits), which is the length, in bytes, of the MMSP header and the data. The MMSP checksum field (16 bits), which covers the MMSP header and the data (as in UDP). The packet type field (3 bits), which specifies the MMSP message as a data packet, FEC packet, move packet, or acknowledgment (ACK) packet. IEEE INTERNET COMPUTING MARCH APRIL

5 The block sequence field (5 bits), which identifies the application message to be reconstructed from the packet and is incremented by one for each application message. The packet-sequence field (8 bits), which identifies either the data packets position within the data block or the redundant packet s calculated multiplier in the infinite field GF(2 8 ), which MMSP uses to calculate Reed-Solomon code. The block-length field (16 bits), which identifies the application message s length. The address-operation field (8 bits), which identifies the request types (add address, delete address, or change priority). The address family field (8 bits), which specifies the address family of the contained address. The address priority field (8 bits), which specifies the priority of the contained address. ACK packets are sent in response to move packets; move packets are retransmitted upon timeout unless the ACK packets return. User Data Fragmentation MMSP uses the path maximum transmission unit (MTU) metric to determine the packet size needed for FEC partitioning. When a packet is larger than the outgoing link s MTU, a router sends an Internet control message protocol (ICMP) message stating that it cannot forward the packet. This message contains the MTU of the next-hop link. The information is then passed to the MMSP stack, which thereby determines the MTU metric. MMSP lets applications specify the FEC partitioning size using an additional application programming interface. Large packets are vulnerable to bit error in wireless links, thus causing relatively high packet losses. While small packets increase the protocol header overhead, they might provide better multimedia streaming quality. Routing Table Searches One of bicasting s big problems is routing table searches. When it sends packets to the correspondent node, the mobile node searches its routing table using the destination address as a search key to select the interface to send the packet out on. Therefore, even if the mobile node has two interfaces for bicasting, it sends all packets through the same interface. To distribute them to each interface, the protocol control blocks (PCBs) maintain, in pairs, the source IP address and the next-hop router s IP address, which they extract from the DHCPOFFER message or, in IPv6, from the router advertisement message. When the mobile node sends packets, it looks up the next-hop router s IP address from the outgoing packets source IP address, and uses the next-hop router s IP address to conduct a routing table search and address resolution protocol (ARP) request or, in IPv6, neighbor discovery. MMSP can decide which interface to send a packet to by filling in the packet header s source IP address field with the selected interface s IP address. Layer 2 Triggers To receive Layer 2 information, we slightly modified the b device driver and the end hosts IP stack. When a new access point becomes available and the b device generates a hardware interrupt, the host sends either a DHCPDISCOVER packet or a router solicitation packet. If either packet contains a new IP address, it is passed to the MMSP stack. The MMSP stack has its own PCBs, which can maintain multiple source and destination IP addresses. The MMSP adds the new IP address to the PCBs. When an access point becomes inaccessible and the device generates a hardware interrupt, the network layer removes the stale IP address and passes it to the MMSP stack. The MMSP removes the stale IP address from the PCBs. When the received signal strength exceeds or falls under some threshold, the driver then informs the upper layers that the priority of the link s associated address has changed. MMSP changes the priority of the address maintained in the PCBs. Performance Measurement We measured our implemented kernel s FEC encoding and decoding time, and evaluated the FEC s impact on the quality of MPEG-4 streaming applications. FEC Encoding and Decoding One of FEC s problems is the amount of calculation required to encode and decode the redundant symbols. We conducted a detailed performance analysis of FEC overhead, taking measurements while the system encoded the correspondent node and decoded the mobile node. Both nodes were IBM PC clones with single Intel Pentium III processors running at 1.2 GHz; the FreeBSD 4.5 system contained our implemented kernel. In the experiment, application message size ranged from 1,000 to 8,000 bytes, and fragmentation size was fixed at 500 bytes. The correspondent node created and sent redundant packets; the system discarded all the data packets at the intermediate router so we could measure the redundant 22 MARCH APRIL IEEE INTERNET COMPUTING

6 Soft IP Handover packet scheme s recovery time. With an application message size of 8,000 bytes, for example, the correspondent node split the application message into 16 data packets and encoded 16 redundant packets. Because the 16 data packets were discarded at the intermediate router, the mobile node received only the 16 redundant packets; it decoded these to recover the 16 data packets. Figure 4 shows the correlation between the application message size and encoding/decoding time. Both times were proportional to the square of the application message size. When the application message size was 8,000 bytes, FEC encoding and decoding took a total of 44.8 milliseconds. This shows that current CPUs can perform FEC encoding and decoding in a reasonable time. Error Resiliency To evaluate the effectiveness of combining bicasting with FEC, we used an MPEG-4 video stream to compare error resiliency in copy bicasting versus FEC bicasting. The video contained a 60-second sequence of CIF size ( ) frames encoded at 384 Kbps, with a frame rate of 15 frames per second and a 5-second I-picture interval (that is, we inserted I-pictures, which are coded with no reference to any other frame, at 5-second intervals during the video sequence). All other frames were P- pictures, which are predicted from the frames that immediately precede them. Each video packet occupied approximately 5,000 bytes, creating a 5,000- byte application message. The fragmentation size was fixed at 500 bytes. For copy bicasting, the MPEG-4 stream sender sent the receiver the exact same packets through two different network paths. For FEC bicasting, the sender sent data packets through one network path and redundant packets through the other. On both paths, we simulated the same wireless bit-error rates, which ranged from 10E-6 to 10E-4 (from to percent). Figure 5 shows the average peak signal noise ratio (PSNR) of all video frames for both bicasting schemes. Missing video packets cause block noise, which can propagate to the next video frame and degrade the video quality. With copy bicasting, the PSNR falls dramatically when the bit-error rates exceed 10E-5. In contrast, FEC bicasting keeps the quality high. Time (ms) Figure 4. FEC encoding and decoding. The time required for encoding and decoding correlates with the square of the message size. 1.0E-06 Encode Copy bicasting 1.0E-05 Bit error rate Decode Application message size (Kbytes) FEC bicasting Figure 5. Error resiliency for copy bicasting and FEC bicasting. Copy bicasting s peak signal noise ratio falls dramatically when the biterror rates exceed 10E-5, while FEC bicasting keeps the quality high. Conclusions The main disadvantage of our architecture is that it doubles connection bandwidth during handover. However, our proposed bicasting mechanism can offset much higher bit-error rates than copy bicasting, thus providing high-quality multimedia applications even under high bit-error rates. This suggests that MMSP will help reduce the energy-perbit requirements of wireless access links. The end-to-end model for path diversity might also assist multiple-description video coding. 12 Although our architecture s FEC encoding causes a slight delay, such a delay is allowable, and using FEC significantly improves multimedia streaming quality. We are currently exploring an end-to-end security mechanism for MMSP that will prevent connection hijacking. We are also planning to conduct wide-area experiments using DoCoMo s public wireless LAN access service. References 1. C. Perkins, IP Mobility Support for IPv4, Internet Eng. Task Force RFC 3220, Jan. 2002; rfc3220.txt E-04 IEEE INTERNET COMPUTING MARCH APRIL

7 2. Y.J. Liang, E.G. Steinbach, and B. Girod, MultiStream Voice over IP Using Packet Path Diversity, Proc. IEEE 4th Workshop Multimedia Signal Processing, IEEE CS Press, Oct. 2001, pp ; mmsp.pdf. 3. J-C. Bolot, S. Fosse-Parisis, and D. Towsle, Adaptive FEC- Based Error Control for Internet Telephony, Proc. Infocom 99, IEEE CS Press, Mar. 1999, pp K. El-Malki and H. Soliman, Simultaneous Bindings for Mobile IPv6 Fast Handoffs, Internet draft, IETF, June 2002; work in progress. 5. H. Soliman et al., Hierarchical MIPv6 Mobility Management (HMIPv6), Internet draft, IETF, July, 2001; work in progress. 6. R. Koodli, Fast Handovers for Mobile IPv6, Internet draft, IETF, Mar. 2002; work in progress. 7. A.C. Snoeren and H. Balakrishnan, An End-to-End Approach to Host Mobility, Proc. 6th ACM/IEEE Int l Conf. Mobile Computing and Networking (Mobicom 00), ACM Press, 2000, pp D. Eastlake, Secure Domain Name System Dynamic Update, IETF RFC 2137, Apr. 1977; rfc2137.txt. 9. R. Stewart et al., Stream Control Transmission Protocol, IETF RFC 2960, Oct. 2000; I.S. Reed and G. Solomon, Polynomial Codes over Certain Finite Fields, SIAM J. Applied Math., vol. 8, no. 2, June 1960, pp J. Plank, A Tutorial on Reed-Solomon Coding for Fault- Tolerance in RAID-like Systems, Software Practice and Experience, vol. 27, no. 9, May 1990, pp J.G. Apostolopoulos, Reliable Video Communication over Lossy Packet Networks Using Multiple State Encoding and Path Diversity, Proc. Visual Comm. and Image Processing (VCIP), ACM Press, 2001, pp Hosei Matsuoka is a research engineer at NTT DoCoMo s Multimedia Laboratories. His research interests are in multimedia streaming technology and QoS architectures for future mobile communications networks. Matsuoka has a BS and an MS in information science from the Tokyo Institute of Technology. Contact him at matsuoka@spg. yrp.nttdocomo.co.jp. Takeshi Yoshimura is a research engineer at NTT DoCoMo s Multimedia Laboratories. His research interests include mobile streaming media technology and content delivery network architecture. Yoshimura has a BE and an ME from the Department of Information and Communication Engineering at the University of Tokyo. Contact him at yoshi@spg.yrp.nttdocomo.co.jp. Tomoyuki Ohya is a research engineer at NTT DoCoMo s Multimedia Laboratories, where he is involved in research and development of digital speech coding technologies for IMT His research interests are in multimedia signal processing and QoS architectures for future mobile communications networks. Ohya has a BE and an ME in electronic engineering from Kyoto University, and an MS in management of technology from the Massachusetts Institute of Technology. Contact him at ohya@spg. yrp.nttdocomo.co.jp. Get access to individual IEEE Computer Society documents online. More than 67,000 articles and conference papers available! US$9 per article for members US$19 for nonmembers 24 MARCH APRIL IEEE INTERNET COMPUTING