Audio transceiver

<img img-format="tif" img-content="drawing" file="IL115902AD00021.tif" id="idf0001" />

AN AUDIO TRANSCEIVER ^ip no'^pi tito1? ητη· A. Tally Eitan-Zeev Pearl &amp;amp; Co.

Law Offices

P-IAB-595-IL

<img img-format="tif" img-content="drawing" file="IL115902AD00022.tif" id="idf0002" />

AN AUDIO TRANSCEIVER

FIELD OF THE INVENTION

The present invention relates to apparatus for providing real-time or near real-time communication of audio signals via a data network.

BACKGROUND OF THE INVENTION

Data networks transfer data, typically in the form of packets which usually havea fixed number of bytes of data, from one workstation to another. There are many types ofnetwork protocols by which networks setup communication paths. Ethernet and Token Ringare examples of low level network structures for packet data networks.

Regardless of the type of structure used, no network instantaneously providespackets from a source workstation to a destination one. There is a transmission delay whichtypically varies depending on the load on the network (i.e. how many workstations are tryingto send at once) and/or on the configuration of the network (i.e. which path the packet takes)and type of protocol used.

If two, sequential packets take two different paths through the network, it ispossible that they will arrive at the destination workstation after different amounts of timetraveling through the network. They also might possibly arrive in the wrong order. Sincemost data transmitted over a network is transmitted for storage purposes, the delays andmixed up order are not critical, although it is always desirable to reduce them to a minimum.

Audio devices, which convert analog audio signals to digital ones, are known.These devices sample the analog audio signal, at some sampling frequency, to produce adigital datastream and then compress the datastream to reduce the storage or bandwidthrequirements for storing or transmitting the datastream. The datastream can then be dividedinto packets and transmitted along a network, to be reassembled and played by thedestination workstation. The playing involves converting the packets into the datastreamwhich is then converted back into an analog signal. As is known in the art, digital to analogconversion also involves a converting frequency which is typically the same frequency as thesampling frequency of the audio device. 1

\595vocal.IL t

<img img-format="tif" img-content="drawing" file="IL115902AD00023.tif" id="idf0003" />

If the audio signal is to be stored by the destination workstation, then thedelays and changed sequence are not critical. When the audio signal is retrieved fromstorage and played, it will be played smoothly since all of its packets are present in thestorage medium.

However, if a real-time conversation is desired, an “audio packet" should beplayed by the audio device as soon as it arrives. This is difficult when working over a networkfor exactly the reasons described hereinabove; the packet order is not necessarily maintainedduring transmission and there is a network delay which is not of a fixed value. Furthermore,even if the delays are overcome, if the audio device of the source workstation has a samplingfrequency which is different (faster or slower) than the converting frequency of the audiodevice of the destination workstation, the two cards will not be synchronized. If the sourceworkstation samples at a higher frequency, the destination workstation will not be able to playthe packets fast enough. Conversely, if the source workstation samples at a lower frequency,the destination workstation will not have enough packets to play.

The following two articles discuss the issues involved in providing audiocommunication over a packet data network:

Clifford J. Weinstein and James W. Forgie, "Experience with SpeechCommunication in Packet Networks", IEEE Journal on Selected Areas in Communications,Vol. SAC-1, No. 6, December 1983, pp. 963 - 980; and

Warren A. Montgomery, "Techniques for Packet Voice Synchronization", IEEEJournal on Selected Areas in Communications. Vol. SAC-1, No. 6, December 1983, pp. 1022- 1028.

The first article discusses network protocols for transmitting speech. Thesecond article discusses a packet voice receiver unit which chooses a target playout time foreach packet. The playout time is a fixed interval after its production by the sourceworkstation. The packet is played only if it arrives before its target playout time. The secondarticle also discusses a number of methods for determining the delay encountered by apacket due to the network. Since the second article assumes that the two audio devices arealmost synchronized (i.e. their frequencies are very close) and that speechbursts are short,it increases the target playout time to compensate for the lack of synchronization.

The second article also discusses adaptively changing the target playout time,typically during silent periods. It can also change the target playout time during playout,although the article mentions that changing the playout time during playout requires 2

\595vocal.IL G . maintaining the pitch of the speech. Finally, the second article discusses the impact ofsynchronization techniques on network design.

Programs for enabling audio communication over networks of similar types ofworkstations are known. For example, the programs NetFone and Vtalk are designed to send 5 voice signals over a data network; however, these programs work only between workstationsmanufactured by Sun Microsystems, Inc. of USA. A voice communication system over a network running the Ethernet protocolis commercially available from Genisys Comm Inc. of Rome, New York, USA. This systemworks with personal computers (PCs). 3

\595vocal.IL

SUMMARY OF THE PRESENT INVENTION

It is an object of the present invention to provide an audio transceiver betweena personal computer (PC) and a packet data network.

The present invention is an audio transceiver (having an audio receiver anda transmitter) which, on the receiving side, adaptively controls the amount of audio data in thebuffer of a PC audio device, such that the audio device always has something to play. Onthe transmission side, the audio transmitter provides at least sequence numbers to the audiopackets to be sent. The audio receiver receives the audio packets, processes them and playsthem as soon as possible thereafter.

Since the present invention does not measure the amount of time it took forthe audio packets to come, the audio receiver and transmitter can be placed at the ends ofany size network (one with a short delay or one with a long delay).

In addition, the audio receiver is concerned only with the state of the buffer ofthe audio device. Therefore, the audio transmitter does not have to be synchronized with theaudio receiver. Their clocks can be slightly or significantly different: the audio receiver canhandle both situations.

Specifically, in accordance with a preferred embodiment of the presentinvention, the audio transceiver includes, apparatus for sequence-stamping outgoing audiopackets received from the audio device and, on input, apparatus for receiving a stream of thesequence-stamped audio packets from the packet data network, fullness setting apparatusand fullness adjusting apparatus. The fullness setting apparatus transfers a silence buffer toa playback buffer of the audio device whenever the playback buffer is empty. The fullnessadjusting apparatus adaptively controls the fullness of the playback buffer to generally matchthe playout rate of the audio device with the rate at which the audio packets are received.

In addition, in accordance with a preferred embodiment of the presentinvention, the transceiver includes apparatus for sequence- and destination-stamping all ofthe audio packets and apparatus for transmitting the audio packets via the network.

Moreover, in accordance with a preferred embodiment of the present invention,the transceiver includes sound detection apparatus which receives audio packets from the firstaudio device, which determines when the audio packets begin to contain sound and whichsends the audio packets from the beginning of the sound.

Still further, in accordance with a preferred embodiment of the presentinvention, the packet data network is a private or, alternatively, a public network. 4

\595vocal.IL

<img img-format="tif" img-content="drawing" file="IL115902AD00024.tif" id="idf0004" />

Additionally, in accordance with a preferred embodiment of the presentinvention, the fullness setting apparatus includes apparatus for increasing an adjustablefullness level. The adjusting apparatus includes apparatus for decreasing the adjustablefullness level and apparatus for processing audio data within the audio packets in order to fill 5 the playback buffer to the current value of the fullness level.

Moreover, in accordance with a preferred embodiment of the present invention,the apparatus for processing includes apparatus for determining the amount of data in theplayback buffer during a predetermined window of time. The apparatus for processingtypically includes apparatus for adding and removing portions of the audio data as a function 10 whether or not the current amount of data is less or more than the current value of thefullness level.

Further, in accordance with a preferred embodiment of the present invention,the apparatus for adding and removing includes apparatus for maintaining the size of theportions of audio data until the current amount of data reaches the current value of the 15 fullness level.

Finally, the present invention includes a method for processing audio datawhich includes the actions performed by the elements described hereinabove. 5

\59Svocal.lL

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from thefollowing detailed description taken in conjunction with the drawings in which: 5 Fig. 1 is a schematic illustration of a plurality of workstations connected together via a network, wherein each workstation has an audio transceiver constructed andoperative in accordance with a preferred embodiment of the present invention;

Fig. 2 is a block diagram illustration of the elements of the audio transceivershown in Fig. 1; 10 Fig. 3 is a schematic illustration of the transmitter portion of the transceiver of

Fig. 2 in conjunction with the audio device;

Fig. 4 is a block diagram illustration of receiver elements of the audiotransceiver responsible for reassembling the audio packets received from the network suchthat they can be played in real-time; and 15 Fig. 5 is a flow chart illustration of the method performed by the receiver of Fig. 4. 6

\595vocal.IL

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

Reference is now made to Fig. 1 which illustrates a network having audiocommunication via a plurality of audio transceivers, constructed and operative in accordance 5 with a preferred embodiment of the present invention, and to Fig. 2 which illustrates, ingeneral block diagram format, the elements of one audio transceiver of the present invention.

Fig. 1 illustrates a plurality of workstations 10 connected together via a packetdata network 12. The data network 12 can be any type of network, such as a local areanetwork (LAN) or a wide area network (WAN), and it can run any desired network protocol, 10 such as SPX/IPX, TCP/IP, etc. Each workstation 10 is formed of a personal computer (PC)having an audio device 14 and a network device 19. The network device 19 connects itsworkstation 10 to the network 12. The audio device 14 is connected to a speaker 16 and amicrophone 18 and is operative to play digitally recorded sound on the speaker 16 and toconvert sound from the microphone 18 to a digital signal. Typical audio devices 14 have 15 playback buffers 15.

The audio transceivers 20 of the present invention bridge between the audiodevices 14 and the network devices 19 so that two workstations 10 can provide sound toeach other in real- or near real-time, thus enabling the users at the two workstations 10 tohave a reasonable voice conversation with each other. 20 As will be described in more detail hereinbelow, the audio transceiver 20 has an audio receiver and an audio transmitter. On the transmission side, the audio transmitterconverts the audio datastream to packets and provides at least sequence numbers to thepackets. On the receiving side, the audio receiver receives the audio packets and, inaccordance with a preferred embodiment of the present invention, adaptively controls the 25 amount of audio data in the playback buffer 15 of the audio device 14 to maintain a desiredfullness level.

Fig. 2 illustrates the general structure of two audio transceivers 20, a sourcetransceiver 20a and a destination transceiver 20b. The explanation of the general operationof the audio transceiver 20 will be provided herein in the context of a conversation between 30 transceivers 20a and 20b.

Each transceiver comprises a network interface 30, a call manager 32, anaudio manager 34, and a session manager 33, where the elements of the source transceiver20a are labeled with an 'a' suffix and those of the destination transceiver are labeled with a*b' suffix. The network interfaces 30 divide the audio datastream into packets and, via the 7

\595vocal.IL

<img img-format="tif" img-content="drawing" file="IL115902AD00025.tif" id="idf0005" />

network device 19, the network interfaces 30 connect to the network 12. The networkinterfaces 30 know the addresses of the workstations on the network and serve to connecttheir audio transceivers 20 to the desired destination workstation.

Through the source call manager 32a, the operator indicates with whom hewants to talk. The source call manager 32a converts the name of the person to the addressof the workstation at which the person works and prepares a "call initiation" message (a datamessage) to that destination workstation. The source network manager 30a sends the callinitiation message. The destination network manager 30b receives the call initiation messageand provides it to its call manager 32b which, in turn, indicates to its operator that a call isbeing initiated. This indication can be via the display of the destination PC or by making a"call initiation" sound, such as that of a bell, on the destination audio device. Typically, thedestination call manager 32b also indicates to the operator who initiated the call.

The operator, if he wishes to talk to the person who initiated the call, makesan appropriate indication to the destination call manager 32b. In response, the destinationcall manager 32b sends an "OK to talk" message, through its network interface 30b, to thesource audio transceiver 20a. The "OK to talk" message also indicates to the destinationnetwork interface 30b that further messages (which will contain audio data) are to be sent toits audio manager 34b.

The source network interface 30a, upon receipt of the "OK to talk" message,sends it to the source call manager 32a which, in turn, may provide an appropriate indicationto its operator. The indication can be any desired type of indication, such as a sound like atelephone being picked up or some phrase, such as "OK to talk" or "Open", which indicatesthat the call has been successfully initiated. The "OK to talk" message also indicates to thesource network interface 30a that any further messages are to be communicated to and fromthe audio manager 34a.

The call managers 32a and 32b periodically send call control signals indicatingthat their audio transceiver is currently active. The managers 32a and 32b monitor the flowof these control signals and also provide "end of conversation" indications. These can comeas commands from the respective operators or after a predetermined length of time duringwhich no control signal was received from the destination transceiver 20b.

The session managers 33 provide overall control to the elements of each audiotransceiver 20. In particular, they manage the logical level of the session with the remoteparty. 8

\59Svocal.IL 115902/2

The audio managers 34a and 34b process the digital audio data received from theirrespective network interfaces 30 and from their respective audio devices 14. The audio managers Φ 34 are divided into audio transmitters 35 (detailed in Fig. 3) and audio receivers 37 (detailed inFigs. 4 and 5).

During a conversation, the transmitting audio manager 34a receives the audio datastreamfrom its corresponding audio device 14 and processes the datastream to remove any silent parts.The resultant datastream is provided to the network interface 30a which divides the datastream intopackets and adds network information, such as source and destination workstation addresses, toeach packet. The packets are then sent to the network 12.

The receiving network interface 30b receives the packets and strips them of the networkinformation, producing thereby an audio datastream. The receiving audio manager 34b processesthe datastream in order to ensure that the playback buffers, labeled 15a and 15b, of their respectiveaudio devices 14 have enough digital audio data to play, irrespective of a) the rate at which thepackets arrive, b) the sampling rate of the source audio device 14a or c) the time at which thepackets were originally produced.

If desired, the audio manager 34a can compress the audio datastream prior to sending itto the network interface 30a to form into packets. The compression (and decompression on thereception side) can be implemented using any suitable audio compression/decompressiontechnique, such as the Adaptive Delay Pulse Code Modulation (ADPCM) technique described in theCCITT G.721 standard.

Fig. 3, to which reference is now made, illustrate the elements and operation of the audiotransmitter 35 of one audio manager 34. The audio transmitter 35 comprises a generally losslesssound detector, formed of a voice operated transmitter (VOX) 40, a buffer 42 and switch means 44.The sound detector removes any silent periods and enables the users to speak without having toindicate when he is finished speaking (i.e. so that the other person can begin speaking).

It is noted that people do not talk continuously but rather talk in bursts, known as"speechbursts". The sound detector determines when the audio datastream includes a speechburst(as opposed to background noise) and shifts the datastream to account for the processing time ofthe VOX 40. Thus, the datastream which the VOX 40 processes is also stored in the buffer 42whose length is generally related to the processing time of the VOX 40. Once the VOX 40 detects asignificant sound within the datastream (which typically occurs near but not at the beginning of aspeechburst), it indicates to the switch means 44 9 115902/2 to output the data stored in the buffer 42. If no sound was detected, the data stored in buffer 42are overwritten.

In particular, the VOX 40 considers sound to be present as soon as some data within thebuffer 42 is above a typically, but not necessarily, user-adjustable, sound threshold level. Theentire contents of the buffer 42 (the datapoint above the sound threshold level plus all of the databefore it), are output to the network interface 30 for division into packets.

When the buffer has had no datapoints above a silence threshold level, which is typicallylower than the sound threshold level, for a few milliseconds (i.e. the speechburst or conversationhas ended), the VOX 40 indicates to the switch means 44 to disconnect the buffer 42 from thenetwork interface 30.

Reference is now made to Fig. 4 which illustrates the elements of the audio receiver 37 ofone audio manager 34. Audio receiver 37 comprises a packet handler 50, an initial fullness settingunit 51, a fullness adjuster 52, and switching means (noted by switches 54) for switching betweenthe units 51 and 52. The output of audio receiver 37 is provided to the playback buffer 15 of theaudio device 14.

It is noted that, since people speak in speechbursts, once a speechburst has ended, theplayback buffer 15 will have nothing left to play. Thus, the fullness setting unit 51 is activated atthe beginning of each speechburst.

It is also noted that the playback buffer 15 is a first-in, first-out (FIFO) buffer which, whenrequested by the audio device 14, provides the audio device with the oldest audio data storedtherein. There is a minimum level of fullness, which varies with the type of audio device 14 utilized,below which the playback buffer 15 should not go, except if the speechburst has ended.

The packet handler 50 receives the audio datastream and the sequence number of eachpacket from the corresponding network interface 30 and notes the sequence number of the packet.It is noted that each packet stores a plurality of "frames" of audio data and that each frame of audiodata can be of any length and can include compressed or uncompressed data in it.

The packet handler 50 resamples the audio data to match the converting frequency of itscorresponding audio device 14, as described in more detail hereinbelow. Packet handler 50 alsocompensates for missing packets by utilizing the packets before and after the missing packets and,if necessary, by adding frames of silence. Frames of silence are frames with silence sounds inthem. 10

<img img-format="tif" img-content="drawing" file="IL115902AD00026.tif" id="idf0006" />

10 15 20 25 30

Since the network routes each packet separately, the packets do not,necessarily, arrive in order or at a regular rate. At the beginning of a speechburst, this “jitter-in the arrival rate can be extremely problematic. Therefore, the fullness setting unit 51determines a desired fullness level to overcome most of the jitter and provides the playbackbuffer 15 with a block of silence data to fill the playback buffer 15 to the desired fullness level.The fullness unit 51 indicates to the adjuster 52 what the fullness level is, after which, theswitch means 54 switch control to the fullness adjuster 52.

While the audio device 14 is playing the silence block, the fullness adjuster 52handles the incoming audio data and provides them to the playback buffer 15. The fullnessadjuster 52 adds or removes audio data in order to match the playback rate of the audiodevice 14 with the rate at which the converted audio data is present. In other words, thepacket handler 50 generally converts, or scales, the audio datastream to the converting rateof the audio device 14 of the destination workstation and the fullness adjuster 52 performsfine adjustments to the data rate of the incoming datastream to more accurately match theconverting rate of the audio device 14. To do so, the fullness adjuster 52 adjusts the desiredfullness level.

If the audio device 14 plays all the data in its buffer 15, either before or whenthe speechburst ends, typically due to increased jitter on the network, the switch means 54switches control to the fullness setting unit 51 which slightly increases the fullness level tocompensate for the increased jitter and provides another silence block of the size of theincreased fullness level.

Fullness adjuster 52 processes the audio data to ensure that the playbackbuffer 15 is as full as necessary but not overly full, since the more data stored in the playbackbuffer 15, the longer it takes before the operator hears the received data. Fullness adjuster52 adjusts the rate of the audio data so as to generally match the playback rate of the audiodevice 14. Thus, if the playback rate is faster than that of the converted audio data, fullnessadjuster 52 adds extra samples to the audio data every so many samples. Conversely, if theplayback rate is slower than the rate of converted data, fullness adjuster 52 drops every somany audio samples.

It will be appreciated that the packet handler 50 and the fullness adjuster 52not only compensate for mismatches between the playback rate and the rate at which thenetwork transfers packets, but also compensate for differences between the packet creationrate of the source audio device 14a and that of the playback rate of the destination audiodevice 14b. Thus, the audio transceiver of the present invention enables communication 11 \S9Svocal.H. 115902/2 between Pcs having audio devices by different manufacturers, which typically do not have similarsampling and playback rates. Similarly, the present invention enables a single audio devicemanufacturer to produce audio devices whose sampling rates range within a large tolerancerange.

It will further be appreciated that the fullness setting unit 51 and the fullness adjuster 52operate to maintain the playback buffer 15 full, without any knowledge of when the incoming audiodata were originally produced.

Reference is now made to Fig. 5 which illustrates the operation of the receiver 37, for eachincoming packet, in flow chart format.

When a packet arrives (step 100), its datastream is first resampled (step 102) to match theconverting frequency of the destination audio device 14. The resampling procedure can be anyresampling procedure which performs anti-alias filtering, interpolation and decimation. The methodutilized by the CAT audio device, commercially available from the common assignees of thepresent invention, is suitable and is operative on PCs. Other methods of resampling are alsoknown.

Afterwards, the sequence number of the new packet is compared to that of the previouslyreceived packet. If there is a gap between the two sequence numbers (step 104), the gap is filled(step 106). One method for filling the gap is as follows: The frames bordering each side of thegap are duplicated and the remaining frames of the missing packet or packets are filled withsilence. Thus, if the two received packets have frames P1, P2, P3 and P4, P5, P6 in order, andone packet is missing, the resultant series will be: P1, P2, P3, P3, silence, P4, P4, P5, P6. Othermethods of filling the gap are also possible.

Steps 100-106 form the operations of packet handler 50.

Whether or not a packet was missing, in step 108, the receiver 37 determines the currentamount of data DATA_AMOUNT stored in the playback buffer. The current amount of dataDATAAMOUNT indicates the delay between the arrival of an audio sample and the time it isplayed out by the audio device 14 and is defined as the difference between the amount of datasent for use by the playback buffer 15 and the amount of data which the playback buffer 15utilized. In equation format: DATAAMOUNT = AMOUNTSENT - AMOUNT_RETURNED (1) 12

Typically, the amount sent and amount returned are continually calculated over the courseof a speechburst. DATA_AMOUNT is calculated over a moving window of time (of typically2 seconds) and thus, is an average, rather than an instantaneous value.

In step 110, the receiver 37 determines if the current amount of dataDATA_AMOUNT is 0 (i.e. the playback buffer 15 is empty). If it is more than 0, step 114 isperformed. Otherwise, step 112 is performed.

If, despite the operation of the fullness adjuster 52, the playback buffer 15 wasemptied, indicates that the network jitter has gotten worse or that the speechburst has ended.To compensate for the possible increased jitter, the fullness setting unit 51 increases thefullness level by a predefined amount, such as by 10%. At the same time, the fullness settingunit 51, in step 112, sends a silence block of at least the size of the current desired fullnesslevel.

If, alternatively, the playback buffer was not empty, the fullness adjuster 52 isoperative. In step 114, it determines whether or not the current desired fullness level is toolarge and in step 116, it adjusts the data to be sent to the playback buffer 15 in order toachieve the desired fullness level.

The current desired fullness level is increased (in step 112), whenever theplayback buffer 15 approaches empty and is decreased (in step 114) whenever there wereno gaps during the last predetermined length of time, such as for 10 seconds. If the minimumcurrent amount of data DATA_AMOUNT for the last, say 10 seconds, is larger than theminimum allowed for the specific audio device 14, then the desired fullness level is set to themean value between the minimum allowed amount of data (for the specific audio device 14)and the minimum DATA_AMOUNT for the last, say, 10 seconds.

It will be appreciated that any other function to reduce the desired fullness levelwhich reduces the level without causing a gap to occur, is also suitable.

In step 116, the difference between the current amount of dataDATA_AMOUNT and the desired fullness level is determined. The difference can bemeasured in seconds of data or in numbers of blocks of data. The data to be sent to theplayback buffer 15 is then processed to force the difference to be as close to zero aspossible.

The processing involves adding or removing audio samples as a function ofhow large the difference is. A positive difference (i.e. the current amount of data is largerthan the desired fullness level), indicates that the input rate is higher than the playback rate. 13

\595vocal.IL

<img img-format="tif" img-content="drawing" file="IL115902AD00027.tif" id="idf0007" />

Therefore, some of the audio samples should be removed. A negative difference requiresthe addition of audio samples.

For each type of audio device, the receiver 37 has a Lookup Table (LUT)defining the function for adding and removing. The following table is useful for theSoundblaster audio devices:

Difference (in msec) Duplication amount 500 -1 per 20 = -5% 300 -1 per 50 = -2% 150 -1 per 100 = -1% -150 +1 per 100 = +1% -300 +1 per 50 = +2% -500 +1 per 20 = +5% where +1 and -1 indicate addition and removal of a frame and “per X“ indicates for every Xframes.

When there are frames which have been artificially added due to a missingpacket (in step 106), then the artificially added frame is selected as the one to be removed.When a frame is to be added, the frame which is added is a copy of the frame which will benext to it.

Although not shown in Fig. 5, the particular duplication amount is maintaineduntil the difference is close to zero. At that point, the duplication amount can be changed.Furthermore, when duplication or removal is occurring, the window size for determining thecurrent amount of data is reduced, for example to 500 msec.

Once the processing has finished, the data of the packet are sent (step 118)to the playback buffer 15 and the process repeated for the next packet.

The following pseudo code details the operation of the duplication/removalmechanism of step 116:

Pseudocode for Step 116: PDup - Previous Duplication_Amount 14

\595vocaUL

<img img-format="tif" img-content="drawing" file="IL115902AD00028.tif" id="idf0008" />

Duplication_Amount (Duplication_Amount&lt;0, means deletion).(Duplication_Amount&gt;0, means duplication). 5 Data_Amount-(averaged over 2 sec.)

Short_Data_Amount-(averaged over 500 ms.)

Fullness_Level

Difference_in_Amount 10 Init:

Dupiication_Amount=0; PDup=0;

When packet arrives: 15 (Reevaluate Duplication_Amount)

Difference_in_Amount = Data_Amount - Fullness_LevelShort_Difference_in_Amount = Short_Difference_in_Amount - Fullness_LevelDuplication_Amount = find (Difference_in_Amount) in table. 20 (Stop Dup./Del Process)if (PDup! = 0) { 25 if (PDup &lt; 0 &amp;amp;&amp;amp; Short_Difference_in_Amount &lt; 0)PDup = 0; (Stop Deletion)if (PDup &gt; 0 &amp;amp;&amp;amp; Short_Difference_in_Amount &gt; 0)PDup = 0; (Stop Duplication)if (IDuplication_Amountl &gt; IPdupl) PDup = Duplication_Amount;if difference increases then increaseDup./Del.accordingly) 30 if (PDup == 0){

Duplication_Amount = find(Difference_in_Amount) in table.PDup = Duplication_Amount 15

\595vocal.IL

It will be appreciated by persons skilled in the art that the present invention isnot limited to what has been particularly shown and described hereinabove. Rather the scopeof the present invention is defined by the claims which follow: 16

\595vocal.IL