Data structure providing storage and bandwidth savings for hardware RTCP statistics collection applications

FIELD OF THE INVENTION

[0001] The invention relates to communications monitoring, and in particular methods and apparatus providing hardware statistics collection in support of conveying telephone quality voice data over packet-switched data transport networks.

BACKGROUND OF THE INVENTION

[0002] In the field of telecommunications, telephone quality services such as the Plain Old Telephone Service (POTS) traditionally has been provisioned over circuit-switched signal transmission infrastructure. There is a current need to provision telephone quality streaming data services over packet-switched data transport infrastructure. There is substantial market pressure towards convergent technologies. Convergent technologies concern the merging of voice, data, and video service provisioning over the same transport infrastructure by integrating telecommunication and computer technologies. Moreover, there is a need to provide high density implementations supporting an ever increasing number of telecommunication sessions concurrently.

[0003] Circuit-switched communications and packet-switched communications are based on different operational principles optimizing different operational parameters. A quality-of-service is defined as a combination of operational parameter values. Circuit-switched communication attempts to provide zero-delay and zero-jitter signal transport, while packet-switched communication attempts to achieve bandwidth efficiency. The migration from traditional circuit-switched provisioning to packet-switched provisioning is a matter of intense current research and development. Although packet-switched transport adheres to different operational principles from circuit-switched technologies, there is a need to achieve the quality-of-service, traditionally provisioned over circuit-switched technologies, using packet-switched technologies.

[0004] Exemplary implementations of packet-switched telephone service provisioning solutions employ Voice-over-Internet Protocol (VoIP) technologies. VoIP technologies relate to conveying of VoIP packets in accordance with best-effort service level guarantees. As opposed to circuit-switched technologies, wherein telephone sessions are associated with dedicated end-to-end connections, audio sample groups conveyed by VoIP packets, route independently of each other in a packet-switched network. The aggregate audio sample groups form a data stream to be played back, at a destination end station, using computed playback times referenced to a clock associated with the destination end station.

[0005] As opposed to traditional telephone service provisioning over dedicated circuits ensuring transmission of voice samples at constant rates, VoIP telephone service provisioning is subject to a best-effort bursty conveyance of VoIP packets. Bursty transmission stems from the fact that each VoIP packet conveys a particular number of voice data samples in an audio sample group forming a VoIP packet payload. Early generated voice data samples accumulate in VoIP packet payloads waiting for later generated voice data samples before transmission thereof.

[0006] Other factors related to bursty transmission in packet-switched communications have to do with packet processing at network nodes in packet-switched networks. Packet processing introduces a processing delay in packet transmission. Internet Protocol (IP) packet transmission employs store-and-forward techniques whereby packets are stored pending processing. The storage of packets pending processing is subject to queuing techniques, queuing delays, queue service disciplines, etc. all of which introduce variable delays. The combination of these effects is evidenced in a variable packet interarrival time at destination end stations, referred to in the art as jitter.

[0007] The above factors have been addressed in connection with telephone service provisioning over packet-switched infrastructure and have been subject to improvement between which:

[0008] Co-pending commonly assigned U.S. patent application Ser. No. 10/103,299 filed Mar. 20th, <b>2002</b> entitled “Method of Detecting Drift Between Two Clocks” addresses issues related to dynamic synchronization of source and local clocks, and is incorporated herein by reference. Methods of, and apparatus for detecting drift between two clocks are described. The apparatus comprises a hardware implementation of a clock drift evaluator. The evaluator monitors received packets associated with a data stream, and extracts from each packet a time stamp generated by the source clock. A difference d between the extracted time stamp and the local time is compared against a d_ref value to determine whether the packet was received early or late. On a prescribed schedule, a degree of late or early receipt of packets is compared against a tolerance level to determine whether a relative drift exists between the pacing of the source clock and the pacing of the local clock. The detection of drift between the two clocks provides support for service level guarantees in provisioning data streaming services in packet-switched environments.

[0009] Co-pending commonly assigned U.S. patent application Ser. No. 10/139,644 filed May 7th, <b>2002</b>, entitled “Time-Indexed Multiplexing as an Efficient Method of Scheduling in Hardware” addresses issues related to hardware process scheduling, and is incorporated herein by reference. The presented apparatus includes a table of task lists. Each task list holds specifications of processes requiring handling during a corresponding time interval. Each task list is parsed by a scheduler during a corresponding interval and the processes specified therein are handled. The presented process handling methods also include a determination of a next time interval in which the process requires handling and inserting of process specifications in task lists corresponding to the determined next handling time. Implementations are also presented in which task lists specify work units requiring handling during corresponding time intervals. The entire processing power of the scheduler is used to schedule processes for handling. Advantages are derived from an efficient use of the processing power of the scheduler as the number of processes is increased in support of high density applications.

[0010] Over and above the mentioned improvements, it is necessary to address the facts that best-effort IP packet transport does not guarantee the safe arrival of packets at the destination end, and that a transmitting station may opt to suppress transmission of VoIP packets otherwise conveying voice data samples having a low signal energy. Such silence suppression techniques are beneficial in reducing transmission bandwidth utilization. Nonetheless, at the receiving end station, non-availability of voice sample data for playback regardless of the reason for non-availability thereof results in silent playback. A reduced apparent quality-of-service is perceived when the audio playback is devoid of sound creating an eerie feeling. Comfort noise insertion techniques must be employed to enhance the perceived quality-of-service.

[0011] Having regard to the fact that human speech has an activity factor of about 0.4, about 60% of voice samples generated in digitizing human speech are silent. A substantial amount of development has been undertaken recently in generating comfort noise patterns—subject matter which is described elsewhere. Largely these recent developments have fallen short of providing suitable methods of inserting comfort noise patterns during playback. Comfort noise insertion at the destination end must take into account: silence suppression instances in the absence of received packets, dropped packet instances evidenced by the absence of received packets, late packet arrivals, etc. Having regard to convergent applications, there is a need to develop apparatus and methods for efficiently inserting comfort noise patterns into multiple voice streams concurrently and independently.

[0012] Co-pending commonly assigned U.S. patent application Ser. No. 10/195,657 filed Jul. 15, 2002 entitled “A Hardware Implementation of Voice-over-IP Playback with Support for Comfort Noise Insertion” provides playback scheduling solutions for voice data sample packet payloads conveyed over best-effort packet-switched infrastructure. The presented hardware implementation provides support for concurrent and independent comfort noise insertion and for dynamic clock adjustment for telephone sessions provisioned concurrently without making recourse to signaling. The apparatus and methods support high density solutions scaleing up to large numbers of concurrently provisioned telephone sessions.

[0013] In an attempt to further attempts to provide a high quality-of-service, feedback mechanisms are employed for assessing characteristics of the best-effort conveyance of VoIP packets in support of adaptive VoIP solutions.

[0014] The Real-Time Transport Protocol (RTP) is a session layer protocol that provides end-to-end network transport functions for applications exchanging real-time streaming data, such as but not limited to audio and video streaming, over packet-switched communications networks over multicast or unicast data transport services. The RTP protocol is described in RFC1889 and is incorporated herein by reference.

[0015] In multi-participant, multimedia applications such as video conferencing, the audio or video payload units <b>100</b> are prefixed with an RTP header <b>110</b>, as schematically shown in FIG. 1, which includes a data stream source identifier <b>112</b>, a payload type specifier <b>114</b> that indicates a data format (for example, the type of signal compression used, if any), a sequence number <b>116</b> used for bookkeeping and payload unit reordering, and a timestamp <b>118</b> used for stream re-timing and playback.

[0016] An associated Real-Time Control Protocol (RTCP) is used in conjunction with RTP to monitor in real-time the quality-of-service delivered and to convey information about participants of an ongoing video conferencing session. The RTCP protocol is also described in RFC 1889 and is incorporated herein by reference. For each RTP session, all participants—both sender and receiver stations—must periodically broadcast reporting information about themselves and their status.

[0017] The broadcasted reporting information includes: simple signals serving as an indication of either joining or leaving the conference context; a participant description including, but not limited to: a name, an email address, a phone number, etc.; or a statistics report.

[0018] Exemplary sender <b>200</b> and receiver <b>300</b> statistics reports are schematically shown in FIG. 2 and FIG. 3 respectively. The statistics reports specify for example the number of: packets sent <b>222</b>, packets lost <b>224</b>/<b>324</b>, interarrival jitter <b>226</b>/<b>326</b>, etc.

[0019] In particular, the statistics reports <b>200</b>/<b>300</b> enable devices that assemble payloads, at network nodes in the path traversed by the packets, to trigger a real-time response to communications network conditions. Responses include for example changing signal compression ratio, adjusting video frame rate, adjusting video image size, and/or suppressing low-energy audio payloads (silence suppression).

[0020] Modern convergent devices, such as but not limited to media gateways, support an increasingly larger number of concurrent video/audio content RTP encapsulated streams. At a particular device, the aggregate packet processing rate is proportional to the number of concurrent streams processed. The RTCP statistics collection will need to be performed primarily in hardware to ensure a deterministic performance in processing received statistics information.

[0021] Hardware implementations are preferred in providing support for packet-switched streaming service provisioning. Hardware implementations benefit from a designed response time in processing VoIP packets.

[0022] However, in transmitting statistics information, RTCP packets are sent out infrequently. Typically statistics reports <b>300</b> are generated between once per second and once per minute. Therefore generation of statistics reports <b>300</b> and the formulation of RTCP packets in convergent devices is implemented in software.

[0023] Hardware statistics collection presents difficult problems for high density applications including: the amount of storage resources required to track statistical information; the bandwidth required to update the statistics store per packet transmitted or received; and the communication flow between the hardware collecting and tracking the statistical information, and the software processing and providing the real-time response.

[0024] There therefore is a need to solve the above mentioned issues.

SUMMARY OF THE INVENTION

[0025] In accordance with an aspect of the invention, a hardware device processing Real-Time Control Protocol (RTCP) statistics in support of streaming services provisioned via packet-switched communications networks is provided. A plurality of data structures are used, each data structure tracking summary statistics information regarding a corresponding provisioned streaming service flow. A statistics block inspects, in real time, a Real-Time Protocol (RTP) encapsulated packet to extract RTCP statistics information therefrom to update a corresponding data structure. The statistics block encapsulates a streaming service flow payload with an RTP header updated with statistics information held in a data structure corresponding to the streaming service flow provisioned.

[0026] In accordance with another aspect of the invention, the device further includes a clock updating an address counter. The address counter specifies, on each tick of the clock, a streaming service flow for which the statistics information held in the corresponding data structure is scheduled to be reported to an external processor.

[0027] In accordance with a further aspect of the invention, the device comprises one of a media gateway communications network node, a media gateway component associated with a communications network node, a physical layer device associated with a communications network node, a physical port device, a single-chip physical port controller, a network appliance, and an IP phone.

[0028] In accordance with a further aspect of the invention, a method for tracking RTCP statistics is provided. Field values are extracted from an RTP packet header of a received packet corresponding to a streaming service flow. Statistic information is derived from the extracted field values. And, a statistical information field value of a data structure associated with the streaming service flow is updated with the least significant bits of the derived statistic information to achieve compactness in storing statistic information in support of high density streaming service flow provisioning.

[0029] In accordance with a further aspect of the invention, the method for tracking RTCP statistics includes steps of: generating an interrupt to an external processor, and providing the stored least significant bit values held in the statistic information field values of the data structure to the processor to update corresponding registers associated with the processor, the registers storing, at least, most significant bits corresponding to the derived statistic information.

[0030] In accordance with a further aspect of the invention, the method for tracking RTCP statistics in generating the interrupt, includes a step of: generating the interrupt upon experiencing one of a rollover condition in updating a statistic information field value, a first update instance of a statistic information field value, and a trigger instance.

[0031] In accordance with yet another aspect of the invention, the method for tracking RTCP statistics includes a step of: requesting the stored least significant bit values held in the statistic information field values of the data structure to be provided to the processor to update corresponding registers associated with the processor, the registers storing, at least, most significant bits corresponding to the derived statistic information.

[0032] The advantages are derived from hardware data storage structure and software data storage structure specifications which take into account: the arrival rate of RTCP statistics reports, the rate of generation of RTP packets, expected communication session duration, statistics information processing bandwidth, etc.; to provide a balance between hardware statistics information tracking, timely update of statistics information processed by software, while reducing statistics information update overheads in support of high density data streaming solutions.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The features and advantages of the invention will become more apparent from the following detailed description of the preferred embodiment(s) with reference to the attached diagrams wherein:

[0034]FIG. 1 is a schematic diagram showing a format of an RTP encapsulated payload in accordance with RFC 1889;

[0035]FIG. 2 is a schematic diagram showing a format of a sender's RTCP statistics report packet in accordance with RFC 1889;

[0036]FIG. 3 is a schematic diagram showing a format of a receiver's RTCP statistics report packet in accordance with RFC 1889;

[0037]FIG. 4 is a schematic diagram showing, in accordance with an exemplary embodiment of the invention, elements implementing an exemplary media gateway, and process steps performed in support of VoIP streaming services; and

[0038]FIG. 5 is a schematic diagram showing an exemplary format of a data structure used in tracking statistics information in accordance with the exemplary embodiment of the invention.

[0039] It will be noted that in the attached diagrams like features bear similar labels.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0040]FIG. 4 shows exemplary elements of an exemplary device <b>400</b>, such as a media gateway, processing RTP and RTCP packets in provisioning VoIP streaming services. The media gateway <b>400</b> provides VoIP support to end station <b>406</b>-B. The media gateway <b>400</b> is connected to a communications network <b>402</b> via a physical link <b>404</b> and receives packets from VoIP sources of which the simplest is an end user station <b>406</b>-A. The received packets include, without limiting the invention: RTP packets <b>100</b> carrying voice payloads associated with a conferencing context, RTCP Sender's Report (SR) packets <b>200</b>, and RTCP Receiver's Report (RR) packets <b>300</b>.

[0041] In accordance with an exemplary embodiment of the invention, RTCP statistics processing is provided via a hardware solution <b>410</b> to handle the collection <b>414</b> and storage <b>416</b> of RTCP statistics, and a software solution <b>450</b> to handle the formulation <b>452</b> of RTCP RR packets <b>300</b>. The advantage of this division of tasks is derived from an optimization of hardware and software resource utilization wherein: the RTCP hardware <b>410</b> provides high-rate simple statistics processing, and the RTCP software <b>450</b> provides low-rate complex statistics processing.

[0042] The RTP packets <b>100</b>, the RTCP SR packets <b>200</b>, and the RTCP RR packets <b>300</b> are received via the physical link <b>404</b> by a receiver block <b>412</b>. The receiver block <b>412</b> inspects all received packets.

[0043] Making reference to FIG. 2, particular attention will be given herein to the statistics fields of the sender's RTCP statistics report packet <b>200</b>, including:

[0044] Sender's Packet Count <b>222</b>: The number of RTP data packets transmitted by the sender since connection setup—32 bits;

[0045] Sender's Octet Count <b>232</b>: The number of payload bytes transmitted via RTP data packets since connection setup—32 bits;

[0046] Fraction Lost <b>234</b>: The fraction of RTP data packets from the given source lost in transit since the last RTCP reception statistics packet—8 bits;

[0047] Cumulative Number of Packets Lost <b>224</b>: The number of RTP data packets from the given source lost in transit since connection setup—24 bits;

[0048] Extended Highest Sequence Number Received 228: The highest sequence number received so far (the RTP sequence number is only 16 bits, the upper 16 bits of the 32 bit field reflects the number of rollovers)—32 bits; and

[0049] Interarrival Jitter <b>226</b>: An estimate of the difference in packet spacing at the receiver station compared to the sender station over all packet pairs—32 bits.

[0050] A statistics block <b>416</b>, interacts with the reception block <b>412</b> to extract <b>414</b> the statistical information provided in received RTCP SR packets <b>200</b>, RTCP RR packets <b>300</b> and updated by header information extracted from RTP packets <b>100</b>. The statistics block <b>416</b> keeps track of the extracted statistics information for each provisioned VoIP stream in a local memory storage <b>418</b>.

[0051] The RTCP statistics tracking hardware <b>410</b> may be implemented as a single chip solution associated with a single port <b>408</b> or multiple ports <b>408</b> of an exemplary media gateway <b>400</b>.

[0052] Although only the above six fields are tracked by the RTCP hardware <b>410</b> per VoIP stream, a large amount of memory storage is required for high density VoIP applications. Off-chip (external/device central) memory <b>430</b> can be used to provide ample statistical information storage, however writing a large number of bytes of statistical information employing a data bus <b>432</b> for each packet received utilizes the bandwidth available. Unfortunately, the memory access bandwidth is an overall system bottleneck, as a consequence of high-rate RTP packet payload storage and retrieval in provisioning VoIP services and should be conserved.

[0053] In accordance with the exemplary embodiment of the invention, statistics counters tracking RTCP statistics are implemented partly in hardware and partly in software. The most significant counter bits which change least during a VoIP session are held in software, while the least significant counter bits which change most frequently are maintained in hardware. A compact RTCP statistics data structure <b>500</b> for storage of statistical information in the local memory storage <b>418</b> is provided and has an exemplary format presented in FIG. 5. The invention is not intended to be limited to the RTCP data structure <b>500</b> presented. The exemplary bit mask presented is not intended to preclude other arrangements of the data structure fields, the same fields can be arranged in similar ways without detracting from the overall spirit of compactness.

[0054] In accordance with the exemplary embodiment of the invention, the 192 bits extracted <b>414</b> from each RTCP SR packet <b>200</b>, are used by the statistics block <b>416</b> to update the compact data structure <b>500</b> uses a total of 128 bits which is arranged in four rows of 32 bits.

[0055] In accordance with the exemplary embodiment of the invention, the arrangement of the statistical information fields presented in FIG. 5, enables only two 32 bit rows to be accessed at any time. When an RTP <b>100</b> or RTCP RR <b>300</b> packet is sent for a VoIP stream via the port <b>408</b>, only the first pair of rows needs to be accessed. When an RTP <b>100</b> or RTCP SR <b>200</b> packet is received for the VoIP stream via the port <b>408</b>, only the second pair of rows needs to be accessed. In accordance with an implementation in which the access width between the statistics block <b>416</b> and the local memory storage <b>418</b> is 64 bits, then only a single memory access cycle is needed per packet.

[0056] The fields of the hardware RTCP statistics data structure <b>500</b> are presented as follows:

[0057] Two Transmit <b>514</b> and Receive <b>516</b> Context Enable bits (TCE and RCE) indicate whether a VoIP flow has been designated for statistics collection in the corresponding direction, and consequently, whether the values stored in the corresponding data structure's fields (<b>500</b>) are valid.

[0058] In order to compute packet loss, the number of packets expected is needed to be known. The number of packets expected can be calculated for each VoIP stream provisioned from: the value of the highest sequence number received so far, minus the value of the first sequence number received. The value of the first sequence number is assigned by the transmitter (<b>406</b>-A) at connection setup time. Storing the first observed sequence number value is inefficient since it is seen once only, used once only, and then kept untouched thereafter. The fields “First/Highest Sequence Number” <b>502</b> and “Sequence Number Carry” (SC) <b>504</b> are provided for this purpose.

[0059] In accordance with the exemplary embodiment of the invention, the value of the first sequence number is to stored in the field <b>502</b> only for a short while to report it to a CPU <b>434</b> executing the RTCP statistics software solution <b>450</b>. Once reported to the CPU <b>434</b>, field <b>502</b> is reused to store the value of the highest sequence number encountered so far. The RS (Receive Status) bits <b>506</b> are used to specify whether field <b>502</b> is storing the value of the first or highest sequence number. The strategy is employed because the highest sequence number value (<b>116</b>) is monotonically increasing, no information is lost by neglecting the field <b>502</b> for a while, then later updating it once the first sequence number is reported.

[0060] RTP sequence numbers provided in RTP packets <b>100</b> are 16 bits long, and therefore the field <b>502</b> must be 16 bits. The RTCP statistics packet format specifies an extended sequence number values in fields <b>228</b> and <b>328</b> respectively which are 32 bits long. In accordance with the exemplary embodiment of the invention, the 16 upper most significant bits are maintained by the software <b>450</b>, in order to conserve memory storage in the local memory storage <b>418</b> and conserve bandwidth in conveying <b>436</b> these values via the data bus <b>432</b>. The SC bit field <b>504</b> is set to a high logic value whenever the sequence number tracked rolls over, and is used as a signal to the software <b>450</b> that the extended most significant sequence number bits must be incremented.

[0061] The time interval between software updates <b>436</b> must be chosen so as to ensure that no more than one rollover for the field <b>502</b> may occur between consecutive software updates <b>436</b>. Therefore the update time interval is dependent on the packet arrival rate.

[0062] The two bits of the Receive Status (RS) field <b>506</b> are used to control field <b>502</b> used to specify both First and Highest Sequence Numbers. An exemplary specification for the RS field <b>506</b> includes:

[0063] “00”—Packet flow for the VoIP context is enabled, but the first packet has not been received yet. When the first packet arrives, set the first sequence number field value.

[0064] “01”—Packet flow for the VoIP context is enabled, the first packet has been received, but the CPU <b>434</b> has not yet read the first sequence number field <b>502</b>. Do not update field <b>502</b>.

[0065] “10”—Packet flow for the VoIP context is enabled, the first packet has been received, and the CPU <b>434</b> has completed reading the first sequence number value. Update field <b>502</b> to indicate the highest sequence number value received so far.

[0066] The Sender's Packet Count <b>508</b> and SPC <b>509</b>, and Receiver's Packet Count <b>510</b> and RPC <b>511</b> fields are used to store the cumulative number of packets transmitted and received for a given VoIP context. The SPC <b>509</b> and RPC <b>511</b> bits indicate counter <b>508</b>/<b>510</b> rollovers, and will be used as a signal to the software to update higher order bits as required.

[0067] The maximum number of bits needed for the Sender's Packet Count <b>508</b>, and Receiver's Packet Count <b>510</b> fields is 16, because 16 bit are used in RTP packets <b>100</b> for storing sequence number values as mentioned above with respect to the first/highest sequence number field <b>502</b>. If more than 16 bits were allotted to packet count tracking, we would rollovers would have to be reported to the CPU <b>434</b> every ˜2¹⁶-2¹⁷packets anyway. On the other hand, using many fewer bits than 16 would increase exponentially the required interaction between software <b>450</b> and hardware <b>410</b>, which would overuse the very scarce CPU access bandwidth (<b>432</b>).

[0068] Assuming a worst case scenario in which one packet is generated every 125 μs (the base sampling time unit for VoIP packet-voice applications), per flow, one rollover update interaction between hardware <b>410</b> and software <b>450</b> counter values will be required every 2¹⁷×0.125 ms, or about 16 seconds. This update rate enables even low-end processors <b>434</b> to support hundreds of flows in support of VoIP solutions.

[0069] Cumulative Packet Loss since VoIP connection setup is equal to Highest Sequence Number <b>502</b>−First Sequence Number (<b>502</b>)−Receiver's Packet Count <b>510</b>, and can be easily calculated by the CPU <b>434</b> when required for RTCP packet formulation <b>452</b>. Fraction Lost can similarly calculated, except that the time period of evaluation runs “from the last RTCP reception statistics packet was sent” rather than since connection setup. The software <b>450</b> can access these values by polling the hardware data structures <b>500</b> when needed.

[0070] Fields Sender's Byte Count <b>512</b> and “BC” <b>513</b> are used to store the cumulative number of bytes transmitted so far for a given VoIP flow. The BC <b>513</b> bit indicates counter <b>512</b> rollover, and is used as a signal to the software <b>450</b> to update higher order bits tracked by the software <b>450</b> if required. As a VoIP payload conveyed in an RTP packet <b>100</b> will typically not exceed 128 bytes (or 128×125 μs=16 ms of voice samples), the length of the Sender's Byte count field <b>512</b> to exceed that of the Sender's Packet count field <b>508</b> by more than 7 bits.

[0071] Under ideal operating conditions, each VoIP packet (<b>100</b>) arrives from the transmitting station <b>406</b>-A exactly when “expected,” to be played out immediately by the receiver station <b>406</b>-B. In accordance with the ideal case, even though each VoIP packet (<b>100</b>) may suffer a network delay, the variation in this incurred delay from VoIP packet to VoIP packet is so small that the receiver station <b>406</b>-B or media gateway <b>400</b> can predict with near certainty when the next VoIP packet will arrive. This predictability would make it safe for the receiver station <b>405</b>-B to play out the voice sample packet payload as soon as that VoIP packet (<b>100</b>) arrives, because a new set of voice samples is certain to arrive exactly when the previous set has finished playing out without any discernible audio gaps.

[0072] In practice however, communication networks <b>402</b> do experience some variation in latency from VoIP packet to VoIP packet, otherwise known as network jitter. Jitter effects may be hidden from the listener (<b>406</b>-B) by artificially inserting at the receiver station <b>406</b>-B a short “playback delay” before playing out the next received voice samples. The playback delay introduced, such as comfort noise, may be comparatively so small that the conversation/conference can proceed normally, without either party experiencing delayed responses. However, the inserted playback delay is long enough to compensate for variations in latency incurred in packet network <b>402</b> from one VoIP packet to the next. The artificial insertion of the playback delay also means that the receiver station <b>406</b>-B or a media gateway <b>400</b> associated therewith will need additional memory storage space to queue arriving VoIP packets, prior to playback after the inserted playback delay. The additional memory storage space is referred to as a “jitter buffer”.

[0073] The interarrival jitter is highly variable and must be calculated to monitor the difference in VoIP arrival packet latency from one VoIP packet to the next, also the absolute value of these differences must be tracked over time. Two fields d_j−1<b>524</b> and “Interarrival Jitter+4” <b>526</b> are maintained by the statistics block <b>416</b> for each VoIP flow in a corresponding statistics data structure <b>500</b>.

[0074] In accordance with the exemplary embodiment of the invention, the number of bits required to store estimates of interarrival jitter values <b>526</b> to achieve storage compactness is affected by the receiver station <b>406</b>-B (or media gateway <b>400</b>) compensating for jitter effects by inserting playback delay. Inserting too much playback delay causes the conversation/conference to experience uncomfortable delays. A natural maximum jitter toleration limit to in voice services provisioning. In practice, the maximum tolerated jitter is 128 ms, using 125 μs the “heart beat” unit of measurement in voice services provisioning, 10 bits (i.e. 210×125 μs=128 ms) are sufficient to track the experienced jitter.

[0075] Packet latency can be determined from the difference d_jbetween VoIP packet j's arrival time at the receiver station <b>406</b>-B or the media gateway <b>400</b>, and j's creation time at the transmitter station <b>406</b>-A. A VoIP packet's creation time is contained in the 32-bit timestamp <b>118</b> in the RTP header, see FIG. 1. The arrival time for each VoIP packet is determined by consulting a 32-bit pseudo-time counter (incremented every 125 μs by a local clock) upon arrival. Although it can be assumed that the receiver's and the transmitter's clocks have identical frequencies, the time values reported by each one of the two clocks at any given time are unrelated. There is no restriction on the set of values that d_jcan take on. Reasons for this arrangement are presented in the above mentioned RFC1889 and the above referenced U.S. patent application Ser. No. 10/103,299.

[0076] As indicated earlier, the absolute value of the difference D_jin packet arrival latency must be determined from one VoIP packet to the next, which is given for each j by:

<i>D</i>_j<i>=|d</i>_j<i>−d</i>_j−1|.

[0077] In order to compute D_j, the incurred latency d_j−1<b>524</b> of the previous packet must be stored in the data structure <b>500</b> for each flow.

[0078] Having determined a new data point D_j, corresponding to the difference in packet latency between the current and the previous VoIP packet, D_jis used to compute the running estimate of jitter J given by:

<i>J=J</i>+(<i>D</i>_j<i>−J</i>)/16

[0079] This equation represents a first order recursive low pass filter, which incorporates the new data point D_jinto the running estimate of the jitter J, which provides a relatively good convergence without pronounced oscillations.

[0080] It might first appear that 32 bits will be required for the d_j−1field <b>524</b>, since the set of values that d_j−1can take on cannot be restricted. Because J is essentially a running estimate of D_jfor all j, it becomes apparent that if J is a number value that can be represented using 10 bits, then so can D_j. Therefore, although d_jand d_j−1can each be any arbitrary 32-bit value, their absolute difference D_jcan always be expressed in 10 bits. A proof that a maximum of 11 bits are necessary to express and store d_jin the data structure <b>500</b> is provided in the appendix.

[0081] In practice it was found that 14 bits are more appropriate for storing the value of the jitter estimate J for additional precision. An additional 4 bits correspond to fractional components of the 125 us time unit are used in order for the interarrival jitter field <b>526</b> to be expressed as an integer as stipulated by the standard RTCP packet format (RFC1889).

[0082] The need for the higher precision stems from the “divide by 16” operation used in calculating in the jitter as presented above. In hardware (<b>410</b>), dividing by 2^mis implemented by shifting the binary representation of a number value m bit places to the right. Suppose (in accordance with a critical case), if for all j, the value of D_j=15, the jitter calculation will proceed as follows:

J=0+(15−0)/16=0+15/16=0,

[0083] because the binary representation of decimal “15” is “1111”, which becomes 0 after being shifted 4 bit places to the right. In this case, the value of J will never converge to its proper value of 15. Therefore, the decimal portion of the jitter J must be calculated and stored to a precision of {fraction (1/16)}, therefore the need for the extra 4 bits.

[0084] The CPU <b>434</b> interacts <b>438</b> with the statistics module <b>416</b>. As indicated above that some of the statistics counters will be maintained partly in hardware <b>410</b> via flow specific data structures <b>500</b>, and partly maintained by the CPU <b>434</b> in the central memory storage <b>430</b> in data records <b>440</b>. When a hardware counter rolls over, a mechanism is required to signal the CPU <b>434</b> that the higher order bits stored in the records <b>440</b> must be incremented. As well, the mechanism is required to signal the CPU <b>434</b> the states of the First/Highest Sequence Number field <b>502</b> used to store the first sequence number only for a short while, before it is reported to the CPU <b>434</b> and the field is reused to track the highest sequence number received thereafter.

[0085] There must be a well-defined flow of information between: the hardware statistics collection and maintenance, and the software statistics information processing, statistics report generation, and RTCP packet formulation. Two methods of interaction are proposed, and both can be supported simultaneously and applied in a configuration-dependent fashion.

[0086] Both methods are based on an address counter <b>442</b> incremented by a low frequency clock <b>444</b>. The period of the low frequency clock <b>444</b> is preferably less than the maximum allowable time interval between consecutive hardware/software interactions, divided by the total number of VoIP flows supported (depending on the particular implementation of the exemplary embodiment of the invention, the total number of VoIP flows supported refers to a media gateway <b>400</b> device as shown in dotted representation in FIG. 4, the total number of VoIP flows supported by a physical port <b>408</b> as shown in the solid representation in FIG. 4). For example (with reference to our earlier discussion about packet count rollover), suppose that the maximum allowable interval between consecutive hardware/software interactions is 16 seconds. If the device supports <b>128</b> flows, then the (low) clock frequency must be at least 8 Hz.

[0087] On every clock edge, the address counter <b>442</b> increments, and the VoIP flow referenced by this address will report <b>436</b> its status to the CPU <b>434</b>, in a manner dependent on settings of “I” <b>528</b> and “IOE” 530 bits. If bit <b>1528</b> is set, then the referenced VoIP flow will interrupt the CPU <b>434</b> every time it is selected via the address counter <b>442</b> to report values held in the corresponding data structure <b>500</b>. If bit <b>1528</b> is not set, but bit <b>10</b>E <b>530</b> is set, then the selected VoIP flow will interrupt the CPU and report values held in the corresponding storage structure <b>500</b> only when an “event” has occurred since the last selection. An “event” includes: a rollover of one or more counters for that VoIP flow, the availability of the first sequence number for that VoIP flow, etc.

[0088] The RTCP statistics are tracked by the statistics block <b>416</b> as extracted from RTP packets <b>100</b> between RTCP SR <b>200</b> and RR <b>300</b> packet receipts. The RTCP statistics information held in a flow data structure <b>500</b> may need to be reported to the CPU <b>434</b> every time the flow is scanned to update records <b>440</b> and provide the CPU <b>434</b> with the necessary, up to date information, for the formulation <b>452</b> of RTCP packets <b>200</b>/<b>300</b>.

[0089] From a different point of view, it is RTCP software's <b>450</b> responsibility to retrieve the necessary statistics information held in the local memory storage <b>418</b> in data structures <b>500</b> corresponding to each VoIP flow provisioned, and to incorporate (<b>452</b>) thereof into RTCP packets <b>200</b>/<b>300</b> prior to scheduling the transmission thereof. In accordance with one implementation of the exemplary embodiment of the invention, the low-frequency clock <b>444</b> is synchronized to the desired frequency of transmission of the RTCP packets <b>200</b>/<b>300</b>. The RTCP hardware <b>410</b> will report <b>436</b> the statistics information for each VoIP flow precisely when software <b>450</b> is to formulate <b>452</b> an RTCP packet <b>200</b>/<b>300</b> for that flow. The CPU <b>434</b> is informed every time the VoIP flow is scanned, regardless of whether an “event” has occurred.

[0090] In accordance with another implementation of the exemplary embodiment of the invention, the CPU <b>434</b> polls the hardware data structures <b>500</b> whenever an RTCP packet <b>200</b>/<b>300</b> is formulated. In this case, hardware <b>410</b> does not need to regularly interrupt the CPU <b>434</b>, except on events.

[0091] As the RTCP software <b>450</b> actually formulates <b>452</b> the RTCP packets <b>200</b>/<b>300</b>, fields such as NTP timestamp (wall-clock time) <b>118</b>, Last SR <b>250</b>/<b>350</b> (based on wall-clock time when the last statistics packet was sent), and delay since last SR <b>252</b>/<b>353</b> (time lapsed since the receipt of the last statistics packet from a given source, and sending a statistics packet back to it) can be transparent to hardware <b>410</b>.

[0092] A transmission block <b>460</b>, however, receives VoIP packet payloads shown dashed in FIG. 5, accesses the local memory storage <b>418</b> to derive the necessary information to encapsulate <b>462</b> the VoIP payload into an RTP packet <b>100</b> prior to conveying thereof over the physical link <b>404</b> into the communications network <b>402</b>.

[0093] The embodiments presented are exemplary only and persons skilled in the art would appreciate that variations to the above described embodiments may be made without departing from the spirit of the invention. The scope of the invention is solely defined by the appended claims.

APPENDIX

[0094] Proof Regarding Number of Bits Required to Store d_j−1

[0095] Given two 32-bit integers x and y that differ by no more than 1023, how many bits of x and y must be examined in order to correctly compute |x−y|? It is proven that 11 bits are sufficient.

[0096] Three cases are considered:

[0097] 1) x&gt;y In this case,

|<i>x−y|=x−y</i>=(<i>xmodM−ymodM</i>)<i>modM, </i>

[0098]  where taking the modulus has no effect on the result if M&gt;1024.

[0099] 2) x&lt;y In this case,

|<i>x−y|=y−x</i>=(<i>ymodM−xmodM</i>)<i>modM, </i>

[0100]  where M&gt;1024.

[0101] 3) x=y In this case,

|<i>x−y</i>|=(<i>xmodM−ymodM</i>)<i>modM</i>=(<i>ymodM−xmodM</i>)<i>modM=</i>0.

[0102] It is concluded that x−y is always equal to either (x mod M−y mod M) mod M, or (y mod M−x mod M) mod M, where M≧1024.

[0103] To decide which of the two expressions is correct, observe that if x≠y,

(<i>xmodM−ymodM</i>)<i>modM</i>+(<i>ymodM−xmodM</i>)<i>modM=M. </i>

[0104] Therefore, if M=2048, then exactly one of the following must be true:

0&lt;(<i>xmodM−ymodM</i>)<i>modM</i>&lt;1024  A)

0&lt;(<i>ymodM−xmodM</i>)<i>modM&lt;</i>1024  B)

(<i>xmodM−ymodM</i>)<i>modM</i>=(<i>ymodM−xmodM</i>)<i>modM=</i>0.  C)

[0105] Therefore, cases A-C can always be uniquely mapped to cases 1-3 if M=2048. In other words, 11 bits of x and y are sufficient.