Abstract:
The present invention provides a method for detecting the bandwidth and other useful parameters of the network status. With these detected result, especially the upstream bandwidth and the downstream bandwidth, the setting of the on-line service or application, which is usually sensitive to the network status, could be appropriately determined. In other words, the type of Codec, the transfer rate and the RTP packet interval could be perfectly determined for adequately utilizing the network in order to improve the quality of the on-line service or application.

Description:
FILED OF THE INVENTION  
       [0001]     The present invention is related to a method for detecting the bandwidth, particularly to a method for detecting a bandwidth for VoIP or real-time media service.  
       BACKGROUND OF THE INVENTION  
       [0002]     With the prompt development of the network technology and the broadening of the Internet bandwidth, the on-line service spreads widely in our daily life. More and more convenient Internet applications are provided to the users. For example, one could make a phone call to a distant friend through Internet by means of the VoIP service, and probably no additional fee is required. Besides, the on-line TV service is also available additional to the Internet users. With such service, no TV program would be forgotten to watch. As computer technology advances, a great number of applications are performed through the network with digital (or discrete) signals as opposed to analog signals. Digital signals can be manipulated by computer systems for many advantageous applications.  
         [0003]     However, the bandwidth of the network is limited by a certain maximum bandwidth, the more application are performed at the same time through the network, and the less bandwidth is shared by each application. Some types of signals, such as voice or video must have enough bandwidth for transmission.  
         [0004]     Nevertheless, since the broadband Internet service is so popular nowadays, some users still has not to apply this service yet. In this way, the quality of the on-line service may therefore be influenced, and some modification or setting should be made by the service providers or the users.  
         [0005]     Unfortunately, the user is usually unable to know the applied bandwidth, and the practical bandwidth is somewhat lower than the theoretical bandwidth. For the on-line voice or video application, the network bandwidth is especially significant to the quality. Besides, the determination of the Codec, transfer rate or RTP (real-time transport protocol) packet interval mainly relied on the value of bandwidth, so an appropriate approach for detecting the current bandwidth is certainly required.  
       SUMMARY OF THE INVENTION  
       [0006]     In view of the aforementioned problems, the present invention provides the method for detecting the network status including the network bandwidth, the round trip delay, network delay, the packet loss and the Jitter. With the instant information about the bandwidth, the type of Codec, (video) transfer rate as well as the RTP packet interval could be properly determined. In this way, the quality of the on-line service would be therefore highly raised.  
         [0007]     According to one aspect of the present invention, a method for detecting a network status is provided. Initially, plural upstream packets are sent continuously from the client terminal to the server terminal, and each of the upstream packets has a substantially equivalent upstream packet size. After these upstream packets are received by the server terminal, an average upstream time interval of receiving time would be calculated. In the end, an upstream bandwidth is determined by dividing the upstream packet size by the calculated average upstream time interval, and network status mainly includes this upstream bandwidth.  
         [0008]     According to another aspect of the present invention, a method for determining a transferring mode is provided. First, plural upstream packets are sent continuously from a client terminal to a server terminal, and as last upstream packet is received by the server terminal, plural downstream packets would be sent from the server terminal to the client terminal. Each of the upstream and downstream packets has a substantially equivalent downstream packet size. After the upstream packets are received by the server terminal, an average upstream time interval of receiving time is calculated, and then an upstream bandwidth would be determined by dividing the upstream packet size by the calculated average upstream time interval. Similarly, an average downstream time interval of receiving time of the downstream packets is calculated, and a downstream bandwidth would be determined by dividing the downstream packet size by the calculated average downstream time interval. Finally, the transferring mode is determined according to the upstream bandwidth and the downstream bandwidth.  
         [0009]     According to still another aspect of the present invention, a method for detecting a bandwidth is provided. First, plural packets are sent continuously from the client terminal to the server terminal, and each of the packets has a substantially equivalent packet size. After these packets are received by the server terminal, an average time interval of receiving time would be calculated. Finally, the bandwidth is determined by dividing the packet size by the calculated average time interval.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0010]      FIG. 1  illustrates the flow chart according to the present invention.  
         [0011]      FIG. 2  illustrates the diagram showing the relation between the packets and the time according to the present invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0012]     The present invention is described with the preferred embodiments and accompanying drawings. It should be appreciated that all the embodiments are merely used for illustration. Although the present invention has been described in terms of a preferred embodiment, the invention is not limited to this embodiment. The scope of the invention is defined by the claims. Modifications within the spirit of the invention will be apparent to those skilled in the art.  
         [0013]     Please refer to  FIG. 1 , which illustrates a flow chart according to the preferred embodiment of the present invention. Initially, the client terminal would send plural packets to the server terminal continuously in step  11 , and these packets are preferably named as the upstream packets for distinguishing other packets. Theoretically, the greater the number of the upstream packets is, the accuracy of the detected result would be. In this embodiment, there are five upstream packets would be sent, for instance. It should be noted that this number of the upstream packets is merely cited for illustration, instead of limitation. Besides, these upstream packets are UDP or RTP (real-time transferring protocol) packers which have a unique ID to identify that is a bandwidth detecting packet, also have timestamp which record the transmitting time and have substantially identical packet size in the embodiment.  
         [0014]     After the upstream packets are received by the server terminal, the average upstream time interval would be calculated in step  13 . In this embodiment, the server terminal would also send plural downstream packets continuously to the client terminal as the first upstream packet is received, as shown in step  12 . The downstream packets would be further illustrated in following description. Please also refer to  FIG. 2 , which is a block diagram showing the relation between the packets and the time. In the UPSTREAM portion, the TX column presents that five upstream packets P 1 -P 5  are sent by the client terminal. Then the packets P 1 -P 5  would be transferred by the network, and finally received by the server terminal, as shown in Network column and RX column. As we can see, the transferring rate is mainly controlled by the network and is limited by the application on the network, and the upstream bandwidth of such network would be detected in the preferred embodiment. After the bandwidth is detected, the user can select the proper Codec, proper Video transfer rate or RTP packet interval according to the detected network bandwidth. Typically, pluralities of Codec versions are incorporated into the computer system. Thus, based on the detected bandwidth, the computer may select proper Codec to fit the current bandwidth.  
         [0015]     The upstream packets will be consequently received by the server terminal, and the receiving time of each upstream packet is recorded. For example, P 1  is received at T 5 , P 2  is received at T 7 , P 3  is received at T 9 , P 4  is received at T 11  and P 5  is received at T 13 . The average upstream time interval AUTI could be calculated by formula 1.  
             AUTI   =         T   ⁢           ⁢   13     -     T   ⁢           ⁢   5       4             Formula   ⁢           ⁢   1             
 
         [0016]     If only two upstream packets P 1  and P 2  are adopted or sent, the average upstream time interval could be T 7 -T 5 . Nevertheless, the more packets are sent, the higher accuracy is achieved.  
         [0017]     Please refer to  FIG. 1 , in step  14 , after the upstream time interval is obtained, the upstream bandwidth would be determined accordingly. In the preferred embodiment, the packet size of the upstream packet is divided by the calculated average upstream time interval AUTI for determining the upstream bandwidth, as shown in formula 2. It is noted that the packet sizes of all upstream packets are substantially the same in this embodiment, as mentioned above. Since the network delay of the receiving time of every upstream packet is similar, the influence of the network delay could be ignored in the embodiment.  
               Upstream   ⁢           ⁢   Bandwidth     =       Packet   ⁢           ⁢   Size       Average   ⁢           ⁢   Upstream   ⁢           ⁢   Time   ⁢           ⁢   Interval   ⁢           ⁢     (   AUTI   )                 Formula   ⁢           ⁢   2             
 
         [0018]     Besides the upstream bandwidth, other parameters of the network status, such as the downstream bandwidth or the packet loss, are also demanded in certain on-line application for determining the superior transferring mode. With such transferring mode, the performance of the on-line application could therefore be highly promoted. To obtain other useful parameters, plural downstream packets are sent continuously from the server terminal to the client terminal as the first upstream packet P 1  is received, namely at the time T 5 , as shown in step  12 . Similar with the situation of upstream packets, in the DOWNSTREAM portion, the TX column presents that five downstream packets P 6 -P 10  are sent by the server terminal. Then the packets P 6 -P 10  would be transferred by the network, and finally received by the client terminal, as shown in Network column and RX column. After that, the average downstream time interval would be calculated in step  15 , and then the downstream bandwidth is determined accordingly in step  16 . Since the calculation of the average downstream time interval as well as the determination of downstream bandwidth is almost the same with the situation of upstream bandwidth, the related description is omitted herein for preventing unnecessary redundant.  
         [0019]     Finally, after the upstream bandwidth and downstream bandwidth are respectively obtained, the bandwidth information would be exchanged between the client terminal and server terminal, as shown in step  17 . In this way, both terminals could maintained complete bandwidth information for further applications.  
         [0020]     Since this bandwidth calculation need to involve both client and server site, if only one site could be controlled, there have the other way to calculate the network bandwidth. At this situation, the network bandwidth would be calculated by transmitting completed timestamp between two packets to calculate, rather than applying the received packet interval. The formula is similar with those mentioned above, except changing the received packet timestamp to transmitting completed timestamp.  
         [0021]     In the preferred embodiment, the packet sizes of the downstream packets are substantially identical and preferably the same as those of the upstream packets. Besides, the number of the downstream packets is preferably the same as that of the upstream packets.  
         [0022]     In addition to the upstream bandwidth and the downstream bandwidth, other useful parameter could be calculated in the aforementioned process. For example, the round trip delay could be obtained by calculating a difference between the transmitting time of the first upstream packet and the receiving time of first downstream packet. Besides, the network delay is a half of the value of the round trip delay. The packet loss rate could be calculated by dividing the number of the sent packets in one terminal by the number of the actually received packets in another terminal. Moreover, Jitter could be calculated by formula 3 or formula 4. 
 
Jitter= T ( Pi )+ AUTI−T ( Pi +1),  i= 1 to 5   formula 3 
 
Jitter= T ( Pi )+ ADTI−T ( Pi +1),  i= 6 to 10   formula 4 
 
         [0023]     In formula 3, T(Pi) is the receiving time of upstream packet Pi, AUTI represents average upstream time interval. Similarly, in formula 4, T(Pi) is the receiving time of downstream packet Pi, ADTI represents average downstream time interval.  
         [0024]     With the obtained parameters of the network status, especially the upstream bandwidth and the downstream bandwidth, the transferring mode including the proper codec, transfer rate or RTP packet interval could be chosen or determined accordingly. Consequentially, the quality of the on-line service or application could be highly improved by utilizing the network perfectly.  
         [0025]     As is understood by a person skilled in the art, the foregoing preferred embodiments of the present invention are illustrated of the present invention rather than limiting of the present invention. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the appended claims, and the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structure. While preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.