The present invention relates generally to the field of VoIP (Voice over Internet Protocol) speech communication systems and more particularly to a method and apparatus for improving the performance of VoIP systems which use Robust Header Compression (RoHC) techniques.
Voice, video and data over IP networks each require that all information traversing the network be sent using a hierarchy of communication protocols, such as, for example, IP, UDP and RTP, each of which is fully familiar to those of ordinary skill in the art. Each of these protocols adds headers and/or footers, resulting in relatively large amounts of overhead (in comparison to the amount of actual data being transmitted across the network). For wireless voice communication applications in particular, this overhead is typically several times the bandwidth of the voice data itself.
Robust Header Compression (RoHC), a technique familiar to those skilled in the art, is often used, inter alia, over the links of a network connection path to reduce the total bandwidth required for the RTP, UDP and IP communication protocol layers. Typically, when used in wireless VoIP systems, RoHC reduces the total bandwidth from approximately 40 bytes per data packet to an average of 1-2 bytes per packet. This compression is based upon typical regularities which are found in the packet headers. For example, in accordance with the RTP communications protocol, each packet is assigned a 32-bit packet number in sequential order, and this packet number is included in the packet header information. However, just as one can express the four digit year 1999 in many contexts by using only the two digit number 99, RoHC compresses RTP packet numbers in a similar fashion by using only the least significant “digits” (i.e., the least significant bits) of the packet number. In most cases, this is adequate, since the packet numbers are generally increasing sequentially.
However, this “abbreviation” creates a situation similar to the infamous Y2K problem. That is, if a year is given in the abbreviated 2 digit form as 04, does this mean the year 2004 or the year 1904? Without any context, one cannot tell for sure. One common solution to the Y2K problem was to make the assumption that all two digit numbers 50 and higher start with the digits 19, while all two digit numbers lower than 50 start with the digits 20. In other words, the year is simply assumed to be within the range from 1950 through 2049 when only 2 digits have been used to represent it. Then, over time, this window can slide forward, so that eventually the range might be 1960 through 2059, and then 1970 through 2069, etc.
In the case of RoHC, since greater compression is obtained by using a relatively small window, only a few bits are typically used to code the RTP packet number. And as described above, this window slides upward as the sequence of RTP headers, and thus the packet numbers, progresses forward. However, this approach may create a difficulty when out-of-order packets are received—a situation that occurs from time to time as a result, inter alia, of network routing delays. Recall that in the Y2K example where only two digits are used to represent a four digit year, the range limit (i.e., the window) is 100 years. Thus, for example, it is not possible to represent the year 1950 in two digits once the window has moved upward to accommodate the year 2050. In accordance with conventional RoHC techniques, however, when such an event occurs (i.e., when an out-of-order packet whose packet number is outside of the current window is received), a “reset” is triggered (i.e., a “re-sync” is performed), wherein the two sides of the communication link “re-negotiate” (i.e., re-define) the sliding window. In this manner, the newly received packet's number can be properly represented by the abbreviated version thereof.
Unfortunately, however, when RoHC is being used in a VoIP application, such a re-sync often causes a call in progress to be disrupted. In particular, the re-sync may create an unacceptably long gap in the speech heard by the listener, due to the fact that significant additional bandwidth is required. On the other hand, the alternative approach of simply using more bits to encode (i.e., abbreviate) the packet number, thereby providing a larger range, results in a far less efficient use of bandwidth for each and every packet, even though it will reduce the total number of re-syncs that occur.
The present invention makes advantageous use of the inventors' recognition of the fact that, in voice services applications (unlike, for example, in data services applications), severely late packets cannot typically be used at all. Whereas “slightly” late packets can be used, those packets which arrive after temporally subsequent packets have already been played to the listener (at the receiver) cannot be used. In fact, playing the sound represented by the voice data from such severely late packets invariably causes greater quality degradation than discarding the packet altogether. As such, when a VoIP communication system is using conventional RoHC, a packet which is very late would normally trigger a RoHC re-sync, but then, following this costly re-sync, the packet is quite likely to be discarded at the receiver as being too “old” to be used anyway.
Therefore, in accordance with the principles of the present invention, a novel method and apparatus provides for a “RoHC-Guard” that filters out packets that are very late (e.g., those that would require a re-sync), advantageously making it impossible for RoHC to perform the costly re-sync (since it is likely to be an unnecessary waste of time to do so). In accordance with certain illustrative embodiments of the present invention, a RoHC-Guard module may be advantageously implemented as a pre-filter to a RoHC module, and thereby does not require any changes to be made to the RoHC standard or to existing RoHC implementations. More specifically, in accordance with a first illustrative embodiment of the present invention, packets are monitored to determine if they would cause a re-sync by the RoHC module. If they would cause such a re-sync, they are simply discarded.
In accordance with another illustrative embodiment of the present invention, a RoHC-Guard module, operating as a pre-filter, saves, rather than simply drops, late packets (i.e., those that would require a re-sync). Then, if a predetermined number of such packets are consecutively received (and saved), they are all advantageously provided to RoHC module. This establishes an advantageous safety mechanism which allows “necessary” re-syncs to be performed when the saved packets represent a legitimate, albeit unexpected, change in, for example, RTP sequence numbers.
We will refer to the methods and apparatuses in accordance with various illustrative embodiments of the present invention as RoHC-G (an abbreviation of RoHC-Guard) methods and apparatuses.
In accordance with the principles of the present invention, however, once the initial synchronization has been established, the illustrative RoHC-G method of
If the discard counter is greater than the predetermined threshold (e.g., 3), all of the packets which have been stored (i.e., saved) in the discard stack are processed by the conventional RoHC technique (even though doing so will likely require at least one re-sync), and the discard stack is cleared (i.e., emptied) and the discard counter is set equal to zero, all at block 28. All of the resultant header-compressed packets are then transmitted across the communications link at block 29, and flow returns to block 11 to process the next received packet.
If, on the other hand, the packet would not require a re-sync, it is processed by the conventional RoHC technique (i.e., the header is compressed) at block 23. Then, the discard stack is cleared and the discard counter is set equal to zero at block 24. Finally, the header-compressed packet is transmitted at block 25.
Note that, in accordance with the illustrative embodiment of the present invention shown in
It should be noted that all of the preceding discussion merely illustrates the general principles of the invention. It will be appreciated that those skilled in the art will be able to devise various other arrangements, which, although not explicitly described or shown herein, embody the principles of the invention, and are included within its spirit and scope. In addition, all examples and conditional language recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. It is also intended that such equivalents include both currently known equivalents as well as equivalents developed in the future—i.e., any elements developed that perform the same function, regardless of structure.