Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Amplifiers/Converters
 
 
Amplifiers/Converters  

Advanced PDV monitoring on MT922x0

Posted: 15 Aug 2003     Print Version  Bookmark and Share

Keywords:Embedded 

/ARTICLES/2003AUG/A/2003AUG15_AMD_NTEK_MPR_AN4.PDF

1

Content

1.0 Scope

2.0 Introduction

2.1 What is PDV

2.2 Timestamp

2.3 Jitter Buffer

2.4 Underrun and Overrun

3.0 MT922x0 Operation

3.1 Normal Scenario

3.2 Underrun

3.3 Overrun

3.4 First Packet

3.5 PDV Monitoring

3.5.1 Static PDV Monitoring

3.5.2 Dynamic PDV Monitoring

3.6 Fixed Delay

3.7 Non RTP

4.0 MT922x0 API

5.0 Summary

1.0 Scope

This application note is applicable to both the

MT92210 and the MT92220 products. Throughout this

document, they will be collectively referred to as the

MT922x0.

2.0 Introduction

This document gives a comprehensive overview on

how PDV is monitored and compensated on the

MT922x0 VoIP/VoATM processors. The MT922x0 has

an advanced PDV monitoring circuitry, allowing the

implementation of various PDV algorithms (simple or

sophisticate) for different applications.

2.1 What is PDV

PDV (Packet Delay Variation) represents the variation

in end-to-end delay that a packet can experience on a

given connection.

Figure 1 shows an example where a TDM sample (X in

the figure) enters the remote MT922x0 at time t0, gets

on to the network at t1, arrives on the local MT922x0 at

t2, and finally appears on local TDM bus at t3.

Therefore, we have:

( t1 - t0 ) = packet assembly time,

( t2 - t1 ) = packet's transport time,

( t2 - t0 ) = packet's actual delay,

( t3 - t2 ) = delay provided by MT922x0's jitter buffer

( t3 - t0 ) = the end-to-end delay for sample X

The arrival time, t2, may vary from packet to packet.

PDV is the variation of t2, or, PDV = t2_max - t2_min.

February 2003

ZLAN-25

Advanced PDV Monitoring on MT922x0

Application Note

Figure 1 - Delays and PDV

Remote

MT922x0

H.110 TDM Bus

Local

MT922x0

H.110 TDM BusPacket Switched Network

RTP Connection

tt0 t2 t3

End_to_End_Delay

X

t0

X

t2

X

t3

Jitter_Buffer_Delay

Transport_Delay

t2_maxt2_min

PDV

X

t1

t1

Assembly

_Delay

Packet_Delay

ZLAN-25 Application Note

2 Zarlink Semiconductor Inc.

As also shown in Figure 1, t2 is made up of two elements, the packet assembly time and the packet transport time.

Similarly, PDV also has two components - (1) the variation of packet assembly time which is a result of dynamic

packet size change, and (2) the variation of packet transport time which is affected by the network condition.

2.2 Timestamp

Both the remote and the local MT922x0 have a counter counting the frame pulse on the TDM bus. That counter

value is called the timestamp. For an error free operation, both the remote and the local TDM bus must be kept

synchronous, thus the two timestamps will increment synchronously. To make our analysis simple, we further

assume that both the remote and the local timestamps have been reset at the same time. This means that at any

time, the remote and the local MT922x0 are generating the same timestamp. It's worth noting that without this

assumptions all the conclusion made in this document sill hold true.

For an RTP connection, the remote MT922x0 will insert its timestamp (Remote_Timestamp) into every RTP packet.

The local MT922x0 will record its timestamp (Lcal_Timestamp) when an RTP packet is received. So, we have

Packet_Delay = t2 - t0 = Local_Timestamp - Remote_Timestamp (1)

2.3 Jitter Buffer

Because of the repetitive nature of the TDM bus, every sample must undertake the same end-to-end delay in order

to maintain the data integrity. This is achieved by adding extra delay to the variable packet delay through the use of

a jitter buffer. From Figure 1 and equation (1), we have

End_to_End_Delay= Packet_Delay + Jitter_Buffer_Delay

= Local_Timestamp - Remote_Timestamp + Jitter_Buffer_Delay.

Or,

Jitter_Buffer_Delay = End_to_End_Delay - Local_Timestamp + Remote_Timestamp. (2)

Obviously, for any desired end-to-end delay, the amount of jitter buffer delay to be added may vary from packet to

packet, and is solely determined by both the remote timestamp and the local timestamp pertaining to that packet.

Typically, a jitter buffer has a pair of read and write pointers. The read pointer reads a byte and places it onto the

TDM bus. Thus, the read pointer advances once every TDM frame. When a packet is received, the samples in the

packet is placed into the jitter buffer at the write pointer position. Thus,

Jitter_Buffer_Delay= Write_Pointer - Read_Pointer.

Or,

Write_Pointer = Read_Pointer + Jitter_Buffer_Delay. (3)

By managing the write pointer position, the MT922x0 can add the right amount of jitter buffer delay for each packet.

However, there is always a limit on the maximum jitter buffer delay that can be provided, which is called the PDV

window. The PDV window is usually user configurable and must not exceed the physical size of the jitter buffer.

2.4 Underrun and Overrun

Underrun is the scenario where a packet arrives later than the end-to-end delay (the X to the right of the PDV

window in Figure 2). Overrun is the scenario where a packet arrives so early that the jitter buffer delay it requires is

more than the PDV window (the X to the left of PDV window in Figure 2).

Application Note ZLAN-25

3Zarlink Semiconductor Inc.

Figure 2 - Underrun and Overrun

In a mathematical way, the underrun and overrun can be defined as:

if ( Jitter_Buffer_Delay < 0 ) Underun_Process;

else if ( Jitter_Buffer_Delay > PDV_Window ) Overrun_Process;

else Normal_Process; (4)

where Jitter_Buffer_Delay is derived by using equation (2).

In both underrun and overrun situations, the required jitter buffer delay can not be satisfied thus the write pointer

has to be re-positioned to a new place, which is called a slip.

3.0 MT922x0 Operation

The MT922x0 provides individual jitter buffer for each single channel or timeslot within a connection. However, all

jitter buffers belonging to the same connection are controlled by one pair of read and write pointers. This

guarantees a synchronous operation for all channels in the same connection. All channels will experience the same

buffer delay and will slip at the same time.

On the MT922x0, the end-to-end delay is composed of two components,

End_to_End_Delay = Desired_End_to_End_Delay + Accumulated_Slip_Offset (5)

where Desired_End_to_End_Delay is the programmable part representing the user's expectation. The

Accumulated_Slip_Offset is controlled by the hardware. This value is always 0 at the beginning, and is recalculated

after each slip.

By combining (2) and (5), we have,

Jitter_Buffer_Delay

= Desired_End_to_End_Delay + Accumulated_Slip_Offset - Local_Timestamp + Remote_Timestamp. (6)

After obtaining Jitter_Buffer_Delay from (6), the MT922x0 then detects underrun or overrun as per (4).

3.1 Normal Scenario

When there is no underrun or overrun detected, the MT922x0 handles the packet in the following way.

Normal_Process :

{

Write_Pointer = Read_Pointer + Jitter_Buffer_Delay;

}

Both Accumulated_Slip_Offset and End_to_End_Delay remain unchanged.

tt0 t2 t3

End_to_End_Delay

Jitter_Buffer_Delay > PDV_Window

t2_maxt2_min

Actual PDV

PDV_Window

UnderrunOverrun

Jitter_Buffer_Delay

ZLAN-25 Application Note

4 Zarlink Semiconductor Inc.

3.2 Underrun

When Jitter_Buffer_Delay is negative, it indicates that the current setting of End_to_End_Delay is smaller than the

actual packet delay (t2 - t0). It also tells by how much the End_to_End_Delay is short off. So the MT922x0 will

automatically increase the End_to_End_Delay to the actual packet delay with some extra margin, by adjusting

Accumulated_Slip_Offset in equation (5). The amount to be adjusted is Slip_Offset, which is given by,

Slip_Offset = ABS( Jitter_Buffer_Delay ) + Underrun_Lead (7)

Underrun_Lead is there to assure that the new End_to_End_Delay will be larger than the actual packet delay by a

programmable margin.

Upon underrun detection, the MT922x0 will first reposition the write pointer to a fixed position (Underrun_Lead)

relative to the read pointer. It then updates Accumulated_Slip_Offset and the End_to_End_Delay. By using a

pseudo C language, the process can be described as below.

Underun_Process :

{

Slip_Offset = ABS( Jitter_Buffer_Delay ) + Underrun_Lead;

Write_Pointer = Read_Pointer + Underrun_Lead;

Accumulated_Slip_Offset = Accumulated_Slip_Offset + Slip_Offset;

End_to_End_Delay = Desired_End_to_End_Delay + Accumulated_Slip_Offset

}

Figure 3 - MT922x0 Underrun Process

Figure 3 is a graphic view of Underrun_Process. After the process, the whole PDV window is right shifted by

Slip_Offset as a result of new End_to_End_Delay value. The new prolonged end-to-end delay will eliminate any

more underruns should the future packets arrive with the same delay time.

tt0 t3

End_to_End_Delay

PDV_Window

Before Underrun

tt0 t3

Underrun

Underrun Detected Underrun

_Lead

Slip_Offset

tt0 t3After Underrun

End_to_End_Delay

PDV_Window

PDV_Window

t2 t4

Application Note ZLAN-25

5Zarlink Semiconductor Inc.

3.3 Overrun

The overrun process is similar to the underrun process but with an opposite effect. The difference between the

Jitter_Buffer_Delay and the PDV_Window has to be subtracted from Accumulated_Slip_Offset with some extra

margin. The margin is controlled by Underrun_Lead. The write pointer is repositioned to Overrun_Lead. The

process is described below.

Overrun_Process :

{

Slip_Offset = Jitter_Buffer_Delay - Overrun_Lead;

Write_Pointer = Read_Pointer + Overrun_Lead;

Accumulated_Slip_Offset = Accumulated_Slip_Offset - Slip_Offset;

End_to_End_Delay = Desired_End_to_End_Delay + Accumulated_Slip_Offset

}

Figure 4 is the graphic view of Overrun_Process. Effectively, the PDV window is left shifted after every overrun so

that all futures packets with the same delay time will be accommodated by the new PDV window.

As underruns and overruns have the opposite effect on the Accumulated_Slip_Offset, they may cancel each other

on the end-to-end delay adjustment.

Figure 4 - MT922x0 Overrun Process

3.4 First Packet

Consider the case of the very first packet after a connection is opened. At that time the Accumulated_Slip_Offset is

always 0, and a slip is almost inevitable unless the actual packet delay is known in advance and is reflected by a

properly chosen Desired_End_to_End_Delay. Such a slip is sometimes undesired because it will cause the write

pointer to start from either the Underrun_Lead or the Overrun_Lead position. The MT922x0 offers a special

treatment for the first packet, allowing the write pointer to start from any place in the jitter buffer regardless of slip.

This is called Init Buffer Mode.

tt0 t3

End_to_End_Delay

PDV_Window

Before Underrun

tt0

Overrun

Overrun Detected

Slip_Offset

tt0 t3After Underrun

End_to_End_Delay

PDV_Window

t2 t3

PDV_Window

Overrun_Lead

ZLAN-25 Application Note

6 Zarlink Semiconductor Inc.

With the Init Buffer Mode enabled, the MT922x0 will apply a fixed jitter buffer delay (Init_Lead) to the first packet,

regardless of the actual packet delay. Then the Accumulated_Slip_Offset and End_to_End_Delay are recalculated

to satisfy equation (5) and (6).

Init Buffer Mode :

{

Jitter_Buffer_Delay = Init_Lead;

Write_Pointer = Read_Pointer + Init_Lead;

Accumulated_Slip_Offset = Init_Lead - Desired_End_to_End_Delay -

Local_Timestamp + Remote_Timestamp;

End_to_End_Delay = Desired_End_to_End_Delay + Accumulated_Slip_Offset;

}

Figure 5 - Init Buffer Mode

From Figure 5, we can see that the Init Buffer Mode places the PDV window only after receiving the first packet. No

slip would ever happen on the first packet.

The Init Buffer Mode only applies to the first packet. All subsequent packets are treated normally.

3.5 PDV Monitoring

On the MT922x0, PDV monitoring is done through the setting of the following control parameters -

7 Desired_End_to_End_Delay

7 PDV_Window

7 Underrun_Lead, Overrun_Lead

7 Init_Lead (Init Buffer mode only)

7 Accumulated_Slip_Offset (reset only)

On the other hand, the MT922x0 also provides the following real-time statistics -

7 Accumulated_Slip_Offset

7 Maximum local/remote timestamp delta (t2_max in Figure 1)

7 Minimum local/remote timestamp delta (t2_min in Figure 1)

7 Maximum PDV monitored (t2_max - t2_min)

7 Number of Underrun and Overrun detected

The ultimate goals of PDV monitoring are (1) keeping overrun or underrun as minimum as possible; and (2) keeping

end-to-end delay as small as possible. However, there are different algorithms that can be implemented to achieve

these goals.

3.5.1 Static PDV Monitoring

Static PDV monitoring sets all the control parameters once at the beginning. Then the MT922x0 would work by

itself. The PDV window will be moved and the end-to-end delay be adjusted as needed.

tt0 t3

First packet

PDV_Window

t2

Jitter_Buffer_Delay

= Init_Lead

End_to_End_Delay

Application Note ZLAN-25

7Zarlink Semiconductor Inc.

3.5.2 Dynamic PDV Monitoring

For those delay critical applications, or for those networks whose PDV characteristic may change dramatically, the

dynamic algorithm would be more appealing. Dynamic PDV monitoring allows users to periodically check the PDV

statistics, and then adjust the PDV window and end-to-end delay accordingly. The following is just one example on

how to implement dynamic PDV monitoring. Suppose the following process is executed once every 10 minutes.

Dynamic PDV Monitoring :

{

Get PDV statistics;

get Accumulated_Slip_Offset from the MT922x0

get t2_max and t2_min from the MT922x0

Set new control parameters;

Desired_End_to_End_Delay = t2_max + some_margin

PDV_Window = (t2_max - t2_min) + some_margin

Update MT922x0

write new control parameters into MT922x0

reset Accumulated_Slip_Offset on MT922x0

reset t2_max and t2_min on MT922x0

}

In the above example, the Desired_End_to_End_Delay is set close to the maximum packet delay recorded during

the past period. The PDV_Window is also set close to the maximum PDV that has been captured.

To further limit the voice effect, algorithms may only change the Desired_End_to_End_Delay by one byte each

time.

3.6 Fixed Delay

The introduction of Accumulated_Slip_Offset allows the MT922x0 to adjust the end-to-end delay automatically

according to the need. On the other hand, it also adds uncertainty to the end-to-end delay because now it may

change with slips. Some applications may want the end-to-end delay to be fixed and unchanged, even in the case

of a slip. The MT922x0 offers a fixed delay mode that, once enabled, would keep Accumulated_Slip_Offsett at 0 all

the time. Effectively, the End_to_End_Delay is now fixed at Desired_End_to_End_Delay without changing.

Moreover, both overrun and underrun detections are disabled in this mode, disabling slips under all circumstances.

The process can be described as below.

Fixed Delay Mode :

{

Write_Pointer = Read_Pointer + Desired_End_to_End_Delay - Local_Timestamp + Remote_Timestamp;

}

This mode must be used with caution. The Desired_End_to_End_Delay has to be set large enough to eliminate any

chance of underrun (any underrun packets are discarded); and the jitter buffer must be physically large enough to

eliminate any chance of overrun. Otherwise, overrun packets will cause jitter buffer overflow resulting in severe

impairment of data integrity.

3.7 Non RTP

The preceeding sections were discussed based on the fact that remote timestamp is carried in the RTP packet, and

therefore is used by the MT922x0 to place the write pointer. For non-RTP connection where no remote timestamp is

available, the MT922x0 will simply advance the write pointer continuously whenever a packet arrives. It will slip to

Underrun_Lead or Overrun_Lead upon detection of underrun or overrun.

ZLAN-25 Application Note

8 Zarlink Semiconductor Inc.

4.0 MT922x0 API

Both static and dynamic PDV monitoring are supported by the MT922x0 API. To help API users, Table 1 is a cross-

reference between the terms used in API and the terms used in this document.

5.0 Summary

The MT922x0 and its API provide several operating modes and features to allow advanced PDV monitoring to be

implemented. Table 2 is a summary of some major modes and their target applications.

Terms used here Equivalent API parameters In which API function

PDV_Window ulMaxPdv Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Desired_End_to_End_Delay ulInitialTimestampDelta Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Init_Lead ulInitialBufDelay Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Underrun_Lead ulUnderrunLead Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Overrun_Lead ulOverrunLead Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Init Buffer mode ulInitializationMode=

cMT922x0_INITIALIZATION_

BUF_DELAY

Mt92210OpenRxUdpRtpXxpcmPdvMonitor

Fixed Delay mode ulInitializationMode=

cMT92210_CONSTANT_TIM

ESTAMP_DELTA

Mt92210OpenRxUdpRtpXxpcmPdvMonitor

reset

Accumulated_Slip_Offsett

fResetTotalSlipOffset=TRUE Mt92210ChangeRxUdpRtpXxpcmPdvConfig

reset t2_max and t2_min fResetPdvMonitor=TRUE Mt92210ChangeRxUdpRtpXxpcmPdvConfig

Accumulated_Slip_Offsett ulTotalSlipOffset Mt92210GetRxUdpRtpXxpcmChanStats

t2_max - t2_min ulMonitoredPdv Mt92210GetRxUdpRtpXxpcmChanStats

Table 1 - API Cross-Reference

Mode End-to-end delay PDV window Main Benefit Applications

Static mode Set at beginning;

automatically adjusted

after each slip;

Fixed No CPU intervention

after initialisation

For most applications

where PDV characteristics

are static

Dynamic

mode

Adaptive Adaptive Both end-to-end delay

and PDV windows are

optimized based on

real-time statistics

Delay critical applications,

or networks with dramatic

PDV change

Init Buffer

mode

Resolved after the first

packet

- Avoid slip on the first

packet.

Network delay is unknown

Fixed delay

mode

Fixed Size of the

jitter buffer

End-to-end delay fixed;

no slip at all

Non delay critical or data

applications

non RTP

mode

Unknown Fixed Applications without

timestamp

Table 2 - Summary of MT922x0 PDV Monitoring

www.zarlink.com

Information relating to products and services furnished herein by Zarlink Semiconductor Inc. trading as Zarlink Semiconductor or its subsidiaries (collectively

"Zarlink") is believed to be reliable. However, Zarlink assumes no liability for errors that may appear in this publication, or for liability otherwise arising from the

application or use of any such information, product or service or for any infringement of patents or other intellectual property rights owned by third parties which may

result from such application or use. Neither the supply of such information or purchase of product or service conveys any license, either express or implied, under

patents or other intellectual property rights owned by Zarlink or licensed from third parties by Zarlink, whatsoever. Purchasers of products are also hereby notified

that the use of product in certain ways or in combination with Zarlink, or non-Zarlink furnished goods or services may infringe patents or other intellectual property

rights owned by Zarlink.

This publication is issued to provide information only and (unless agreed by Zarlink in writing) may not be used, applied or reproduced for any purpose nor form part

of any order or contract nor to be regarded as a representation relating to the products or services concerned. The products, their specifications, services and other

information appearing in this publication are subject to change by Zarlink without notice. No warranty or guarantee express or implied is made regarding the

capability, performance or suitability of any product or service. Information concerning possible methods of use is provided as a guide only and does not constitute

any guarantee that such methods of use will be satisfactory in a specific piece of equipment. It is the user's responsibility to fully determine the performance and

suitability of any equipment using such information and to ensure that any publication or data used is up to date and has not been superseded. Manufacturing does

not necessarily include testing of all functions or parameters. These products are not suitable for use in any medical products whose failure to perform may result in

significant injury or death to the user. All products and materials are sold and services provided subject to Zarlink's conditions of sale which are available on request.

Purchase of Zarlink's I2C components conveys a licence under the Philips I2C Patent rights to use these components in an I2C System, provided that the system

conforms to the I2C Standard Specification as defined by Philips.

Zarlink, ZL and the Zarlink Semiconductor logo are trademarks of Zarlink Semiconductor Inc.

Copyright 2003, Zarlink Semiconductor Inc. All Rights Reserved.

TECHNICAL DOCUMENTATION - NOT FOR RESALE

For more information about all Zarlink products

visit our Web Site at





Comment on "Advanced PDV monitoring on MT922x0"
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top