By Vijay K. Madisetti, Professor, Georgia Institute of Technology, CEO, SoftNetworks, LLC, Antonios D. Argyriou, Yamacraw Graduate Student Researcher, Yamacraw Project, Georgia Institute of Technology, Atlanta, GA
Future wireless all-IP networks, while offering the promise of exciting broadband applications, are expected to consist of several, potentially incompatible, wireless access technologies that would be offered by a number of competing service providers. Once past the access stage, the Internet is still expected to be the main traffic backbone. The diversity of access technologies, however, may affect the Quality of Service (QoS) . These issues become even more important when the user may possibly want to switch from one access technology to the other that may either is priced differently or provides better service or it is available in a place where another one is not.
Additional problems arise when considering the widely differing types of services that the user may use such as streaming media, real-time communications, interactive communications, VoIP, and multimedia-commerce. Each of these services imposes its distinct QoS requirements. These QoS demands from multimedia traffic are compounded in the case of a wireless network, where new problems arise due to the implied mobility of the users as well as due to the nature of the current IP protocols that support IP-based mobility, combined with a lossy and interrupt/outage-prone nature of the communications channel.
QoS requirements can be achieved by various techniques that span multiple layers of the network OSI hierarchy. However, we believe that transport layer is an oft overlooked area with respect to the promise that it offers for improvement of mobility management, QoS, security, and throughput. Additionally a transport layer-based approach has to be able to interoperate with future QoS-aware backbone networks which will be primarily based on MPLS and DiffServ technologies.
In particular, multimedia transmission over wireless links presents a great challenge for the internet engineering community today especially in the way reliable content can be delivered using the various methods of delivery: streaming, interactive (real-time), or simply non-real-time.
With streaming multimedia, constant transfer rates are of primary importance. This includes applications that are related to audio and video streams. So, brief disruptions in the transfer rate become noticeable by the user, resulting in jittering pictures or stuttering during sound playback. However, some initial delay is acceptable.
Another category is the interactive multimedia. In this case the concern is with real-time data transfers and temporal fluctuations. So, while one may tolerate minor errors during content transfer, long delays and jitter are usually unacceptable from QoS considerations. Voice over IP and video telephony are representative of the applications that belong to this category. New exciting applications such as M-commerce would also fit this category. Non-real-time multimedia traffic such as Video on Demand (VoD), are concerned primarily about throughput and not with delay or jitter.
A number of approaches have been proposed to improve QoS at the network, transport and application layers, primarily related to QoS in the access networks. Of the many proposals most fall into several broad categories, dealing with the issue of QoS at the application, transport, network and data/physical link layers.
At the application layer, there are currently several approaches at the application layer that provide mobility management for media data over wireless links, most of which are based on either SIP (Session Initiation Protocol) and/or Mobile IP standards.
SIP based mobility, thus, offers attractive benefits when used in mobile multimedia applications. However, there are some inherent problems with this approach that make the adoption of this scheme difficult. For example it cannot handle mid-call subnet changes, since it is an application layer solution. This is where it requires the support of a lower level mobility protocol such as Mobile IP. One other important issue is that of inter-operability with Mobile IP. Home Agent and Foreign Agent registrations in mobile IP serve the same purpose with the SIP REGISTER messages and their joint deployment becomes problematic.
Transport layer is a neglected area concerning QoS related research. However, there are a few notable exceptions, but, as in the application and network layers solutions are not without their problems. But there are answers to these drawbacks in the form of enhancements to the Stream Control Transport layer protocol.
While older transport layer protocols, such as TCP and UDP, do not appear to be able to fully meet the stringent QoS requirements for interactive multimedia services, especially in the wireless, mobile environment, there is a new IETF transport level protocols, called Stream Control Transport Protocol (SCTP), that was designed to transfer reliably SS7 signaling messages over IP-based networks. However it soon proved to be not only an "application specific" protocol but it could also overthrow TCP.
SCTP introduces the idea of multi-homing, where a host has multiple interfaces and IP addresses by which it is reachable. An association between two endpoints can exist between any of these addresses. If one of the paths that correspond to one address fails then an alternative can be used without interrupting the connection between the endpoints. The two endpoints can monitor the status of the paths by sending a special kind of SCTP message called the Heartbeat. Primary goal of the above protocol property was error resilience.
Additionally SCTP provides the ability to maintain multiple streams of messages inside a single association. This makes possible to maintain a sequence of messages only per stream basis (partial in-sequence delivery) thus reducing unnecessary head-of-line blocking between streams of messages that are independent.
Another important feature is the distinction between the delivery mechanism and reliable datagram transfer. This provides a more flexible usage of the protocol so that is adapted to the specific needs of the application using it. It is, for example, possible for a scenario where one application requires partial ordering of the delivered datagrams, while another could be satisfied with reliable transfer that does not imply any kind of sequencing.
An SCTP implementation, fully compatible with the RFC, appears to be able to perform better than TCP even in the case of a wireless system. Even though SCTP does not incorporate any novel features particularly suited for wireless systems, it is a powerful new transport technology that has a number of advantages over TCP in this regard.
Multi-homing can greatly improve performance: even a standard SCTP stack operating in a mobile computer with more than one network interface card can significantly increase data transfer reliability. Moreover SCTP supports IPv6 and it can it can operate at the same time by using IPv4-IPv6 addresses. This feature is of importance since IPv6 is expected to soon replace the older IP version.
We have proposed to the IETF an enhancement to the SCTP base protocol, called Voice over Mobile IP (VoMo), that makes it practical in the wireless environment. VoMo is actually a collection of technologies which include: an Intelligent Address Distribution (IAD) mechanism; a Neighborhood Based Mobility (NBM) mechanism and a QoS-aware Transport Layer that has a number of capabilities as relates to multimedia over mobile wireless connections including path quality monitoring, network status estimation, efficient stream and physical path management, rate control and content adaptation mechanisms, and load-balancing and bandwidth aggregation mechanisms
The VoMo platform consists of two distinct phases that are related to mobility management. One is the initialization process phase which is performed at each subnet even when no mobile nodes are inside a cell. The other is the connection process phase which handles all the necessary steps that a mobile node (MN) has to go through in order to connect to the wireless network.
In the VoMo wireless platform, multimedia data sets are distinguished at the transport layer according to the classes these data sets are assigned to by the application layer, creating an opportunity to provide QoS. The classes of data sets are assumed to match those proposed by the Universal Mobile Telephone System (UMTS): conversational class, streaming class, interactive class, and background class. Adopting the application classes as the above is not restrictive for any kind of application layer protocol and may offer the right abstraction for manipulating data at the modified SCTP layer.
The QoS features intelligently route data to outgoing appropriate interfaces based on network status information, available network resources, application layer requirements, and application bit error rate (BER) demands. More details on operation of the QoS features may be found at www.yamacraw.org.
Due to wireless and mobility issues, network bandwidth and noise characteristics of paths between various communications endpoints are expected to vary over time. VoMo offers the ability to adapt the quality of the content being transmitted based on the channel or communications capabilities available to the service.
The VoMo platform implements load balancing at the transport layer. While the foundations rely on the multi-homing technology of SCTP, several new features are provided. The user can use a new Stream Ordering (SO) service where he can specify an ordering in the stream data delivery. This can be useful in the case where the user wants to transfer a single file and wants to split it into streams for transmission across various available interfaces. VoMo handles this case by using the SO service to split data into streams, and to tailor the transmission by sending the streams out according to the available bandwidth at each interface.
The VoMo load-balancing mechanism operates in close cooperation with the QoS features. The QoS module makes decisions that satisfy the application requirements and the Load-Balancing mechanism is invoked when the use of more than one interface is needed.
See related chart