Packettrunk

PacketTrunk
-4
TXC-05870
TDMoIP / MPLS Gateway Device
Feb. 03, 2004

Contents
• TDMoIP: Introduction
• PacketTrunk-4 Functionality
• Clock Recovery & Measurement
• PacketTrunk-4 Demo
TranSwitch Corporation Proprietary & Confidential 2

1. TDMoIP:
Introduction

Pseudowires
Pseudowire (PW): A mechanism that emulates the

essential attributes of a native service while transporting
over a packet switched network (PSN)

Tunneling - interworking
Mating different network protocols is called interworking
The protocol converter goes by various names :

– interworking function (IWF)
– gateway (GW)
Simplest case is network interworking

Easily provided by tunneling
Native network Native

Service Service

Emulating TDM
From PSTN to PSN

Classic Telephony
Access Network Core (Backbone) Network

analog lines
CO SONET/SDH CO P
B
T1/E1 SWITCH NETWORK SWITCH X
P
B
X
extensions Synchronous
Non-packet network
T1/E1
• Circuit switched ensures signal integrity

• Very High Reliability (“five nines”)
• Low Delay and no noticeable echo
• Timing information transported over the network
• Mature Signaling Protocols (over 3000 features)

TDMoPSN
Access Network
analog lines
Packet
P
T1/E1/T3/E3
Switched B
X
extensions
P Network
B
X
Asynchronous network
T1/E1
No timing information transfer
The TDMoIP approach replaces the Network

with a packet (IP or MPLS) network
The access networks and their protocols remain !
TDM Pseudowire
Can G.xxx compliance be maintained?

A few G.XXX sayings …
• G.114 (One-way transmission time)

– delay < 150 ms acceptable
– 150 ms < delay < 400 ms conditionally acceptable
– delay > 400 ms unacceptable
– G.126/G.131 echo control may be needed
• G.823/G.824 (timing)
– Primary vs. secondary clocks
– jitter masks
– wander masks
• G.826 (error performance)

– BER better than 2 * 10-4

TDMoIP vs. VoIP
Two ways to integrate TDM services into PSNs

VoIP
Voice centric!
• Revolution - complete (forklift) CPE replacement
• New signaling protocols (translation needed)
• New functionality (e.g. video-phone, presence)
TDMoIP
Clear channel/ leased line service
• Evolution - CPE unchanged, IWF added at edge
• No change to signaling protocols (network IW)
• No new functionality
• Migration path

TDMoIP as a Migration Path
• VoIP has promising future

– but today’s installed base is still legacy TDM
• PSTN is not going to be replaced overnight

• Voice quality concerns (delay, compression, packet loss)
• TDMoIP can use new infrastructure with legacy CPE
• Maintains functionality of all PBX and Centrex features

TDMoIP Protocol Processing
TDM TDM
IP Packets IP Packets
frames frames
PSN
Steps in TDMoIP
• The synchronous bit stream is segmented
• The TDM segments are adapted
• TDMoIP control word is prepended
• PSN (IP/MPLS) headers are prepended
• Packets are transported over PSN to destination
• PSN headers are utilized and stripped
• Control word is checked, utilized and stripped
• TDM stream is reconstituted and played out
TDMoIP Protocol Processing
TDM TDM
IP Packets IP Packets
frames frames
PSN
Traffic Types:
• Structured (framed)
• Unstructured (unframed)

TDMoIP encap formats
- For Structured Traffic
(TDMoIP: IETF draft-Anavi-tdmoip-06)
encapsulation (encap) : process of adding protocol

control information to data in order to build a
packet for transport across an PSN

Functionality
What needs to be transported from end to end?

• Voice (telephony quality, low delay, echo-less)
• Tones (for dialing, PIN, etc.)
• Fax and modem transmissions
• Signaling (there are 1000s of PSTN features!)
– CCS (comon Channel Signaling), CAS (Channel Associated Signaling)
• Timing
“timeslots”
T1/E1
frame
SYNC TS1 TS2 TS3 … CAS
signaling
bits
… TSn
(1 byte)

Why isn’t it easy
Why don’t we simply encapsulate the T1/E1 frame?
24 or 32 bytes
IP UDP RTP? T1/E1 frame
Because a single lost packet would cause service interruption

 CAS signaling uses a superframe (16/24 frames)
 Superframe integrity must be respected
Because we want to efficiently handle fractional T1/E1
Because we want a latency vs. efficiency trade-off

The basic idea
Those problems can be solved by:

• adding a packet sequence number
• adding a pointer to the next superframe boundary
• only sending timeslots in use
• allowing multiple TDM frames per packet
UDP/IP seqnum ptr T1/E1 frames (only timeslots in use)

(with CRC)
for example 7 @ TS1 TS2 TS5 TS7 TS1 TS2 TS5 TS7
Good idea! This is precisely AAL1 !

why AAL1 – For Static
Structured Traffic
“AAL1” is the simplest method to transport

structured TDM traffic (voice, sync, signaling)
ATM community has done the debugging for us!
Any alternative will either

• fall apart upon packet loss or
• be less efficient or
• mandate high latency (e.g. multiframe per packet) or
• be essentially equivalent (I.e. contain a structure pointer)

Isn’t that enough?
AAL1 is inefficient if the timeslots are not always in use
Although we can configure which timeslots are used

we can not change this configuration in real-time!
To allow dynamic allocation of timeslots

we can use AAL2
AAL2 buffers each timeslot and encapsulates in a “minicell”
Bandwidth conservation comes at a price

– more computation
– less robust

AAL2 for Dynamic BW Traffic
AAL1 is BW inefficient when timeslots are dynamic

Even with GB rates we should consider efficiency considerations
“AAL2” is the simplest method to transport

dynamic structured TDM
Any alternative will either
• fall apart upon packet loss or
• be less efficient (e.g. require renegotiation) or
• be essentially equivalent

Isn’t this just ATM?
AAL1 and AAL2 are adaptation protocols

originally designed to massage data into a format
that can be readily used
As we have shown, they are natural candidates for
any application which needs to multiplex timeslots
For TDMoIP we do not put the AAL1/2 into ATM cells (no 5 byte header)
Rather we put the AAL1/2 directly into a UDP/IP or MPLS packet
So, NO, this is NOT ATM
But it can easily interwork with ATM access networks!

Service Inter-working
TDMoIP is not the first TDM emulation technology

We should also provide service interworking,
existing ATM circuit emulation services (AAL1, AAL2)
E1/T1 ATM-MPLS IWF

E3/T3 TDMoMPLS GW
ATM/
AAL1
PSN
ATM-CES GW
AAL1 AAL2 AAL5

CBR VBR n-rt
E1/T1
E3/T3
ATM layer

One More Payload type: HDLC
• Efficiently transfer CCS traffic (such as SS7

embeded in TDM traffic)
Assume messages shorter than the MTU (no fragmentation)

– monitor flags until frame detected
– test FCS
– if incorrect - discarded
– if correct -
• perform unstuffing
• flags and FCS removed
• send frame

TDMoIP layering structure – Structured
Traffic
PSN / multiplexing
Optional RTP header
TDMoIP Encapsulation
higher layers
AAL1 AAL2 HDLC
AAL1 used for static (and transparent) allocation: NxAAL1 (N=1..31)

AAL2 used for dynamic bandwidth: NxAAL2 (N=1..31)
HDLC used for CCS signaling and data (e.g frame relay)
TDMoIP Control Word
FORMID flags Res Length Sequence Number
For Structured Traffic:

FORMID (4 b)
– indicates TDMoIP mode (AAL1, AAL1 - CAS, AAL2, HDLC)
– ensures differentiation between IP and MPLS PSNs
Flags (2 b)
– L bit (Local failure)
– R bit (Remote failure)
Res (4 b):
Length (6 b) used when packet may be padded
Sequence Number (16 b) used to detect packet loss / miss-ordering
For UnStructured Traffic:

FORMID (4 b): 0000
Res:

- For UnStructured Traffic
(SATOP: Draft-ietf-pwe3-satop)
SATOP: Structue-agnostic TDM over Packet)

Payload Type of UnStructured Traffic
• TDM traffic is treated as RAW data

• TDM bit stream is put into payload field
• The payload size is defined during setup
• Payload size remains the same
• It should support the payload size:
– T1: 192 bytes
– E1: 256 bytes
– T3 and E3: 1024 bytes
• If RTP is used:
– Clock used for time stamp must be an integer of multiple 8Kz

Summary

TDMoIP layering structure
PSN / multiplexing
Optional RTP header
TDMoIP Encapsulation
higher layers
TDM Over IP Payload

TDMoIP Control Word
FORMID flags Res Length Sequence Number
For Structured Traffic:

FORMID (4 b)
– indicates TDMoIP mode (AAL1 w/o CAS, AAL1 w/CAS, AAL2, HDLC)
– ensures differentiation between IP and MPLS PSNs
Flags (2 b)
– L bit (Local failure)
– R bit (Remote failure)
Res (4 b):
Length (6 b) used when packet may be padded
Sequence Number (16 b) used to detect packet loss / miss-ordering
For UnStructured Traffic:

FORMID (4 b): 0000
Res:

TDMoIP packet format
IP header (5*4bytes)
UDP header * (2*4bytes)

Optional RTP header (3*4bytes)
TDMoIP header (4bytes)
TDMoIP payload
Notes * The UDP source port number is used as a bundle identifier

IP/UDP/RTP Encapsulation
32 Bit
IPVER IHL IP TOS Total Length
Identification Flags Fragment Offset

Time to Live Protocol IP Header Checksum IP Header
20 Bytes
Source IP address
Destination IP address
VER Circuit Bundle Number Destination Port Number

CBID 0x 085E or 2142
UDP Length UDP Checksum
UDP Header
8 Bytes
RTV P X CC M PT RTP Sequence Number
Timestamp RTP Header

SSRC Identifier
FORMID L R Z Length Sequence Number Control Word

Payload
IP TDMoIP Payload Adapated
UDPHeader TDMoIP
CRC-32
Ethernet
Header Payload
TOS Src Bundle# Control
Src adr (AAL1,AAL2,
Dst adr Dst= 0x085E Word
HDLC, RAW)
UDP Source Port Number is used as the bundle number designator , UDP Destination port number
set to hex 085E (2142) assigned by IANA for TDMoIP.
TDMoMPLS packet format
outer inner control TDM

label label word Payload
• Inner and outer labels specify TDM routing and multiplexing

• Inner Label contains TDMoMPLS circuit bundle number
• The control word
• enables detection of out-of-order and lost packets
• indicates critical alarm conditions
• The TDM payload may be adapted
• to assist in timing recovery and recovery from packet loss
• to ensure proper transfer of TDM signaling
• to provide an efficiency vs latency trade-off
MPLS Encapsulation
• Example of MPLS Header :
Outer Label EXP S TTL

MPLS Header
Inner Label = CBID EXP S TTL 8 Bytes
FORMID L R Z Length Sequence Number Control Word

Payload
TDMoIP Payload
Adapated
CRC-32
Ethernet
MPLS MPLS TDMoIP

Outer Payload
Inner Control
Labels Label Word (AAL1,AAL2,
HDLC, RAW)

TDM o L2TPv3
IP header (5*4 B)
Session ID (4 B)
Optional cookie (4 or 8 B)
higher layers
TDMoIP header (4 B)
TDMoIP payload
Note : No UDP header

TDMoIP in Ethernet Frame
TDMoIP Frame
EhterNet IP/UDP or Control TDM Payload FCS

Header MPLS header Word
• Structured TDM Payload

• Multiple AAL1: NxAAL1
• Multiple AAL2: NxAAL2
• HDLC
• UnStructured TDM Payload:

• Bit stream, fixed bytes

TDMoIP Frame w QoS Support
TOS -Type of Service
Field (Diffserv) Priority TDMoIP
Control Word
MAC Layer IP Layer UDP TDM AAL1 Payload CRC
Typical 48 Octet Payload AAL1/AAL2

1 Octet Header 47 Octet payload
VLAN Tagging Up to 30 AALn Frames in Payload
Priority Labeling UDP Source & Destination Field
IEEE 802.1p&Q Ports
2142 (Given by IANA)
Level 4 priority
• Header Compression can be used to decrease the header down to a few bytes
• Ethernet Packet Min 64 bytes Max 1536 bytes

TDM Timing Recovery

Introduction
• PSN (e.g. IP) have no clock distribution mechanism
• For TDM over PSN receiver must recover clock

– In Band: timing information is transferred over PSN, (e.g., RTP)
• Required high quality reference clock
– Timing information is provided in some means independend of PSN, (e.g.,
adaptive clock mechanism)
• Recovered clock quality:

– Can not guarantee “Quality traffic” if the recovered clock is not accurate
enough
– E1: G.823
– T1: G.824

Introduction cont.
• Result of RTP can not meet the G.823, G.824

– Due to time stamp quantization error, packet loss, ..
– Use 12 bytes for RTP
– Require reference clock in both side (expensive for high accurate
reference clock)
• Conventional adaptive clock slaves local clock to jitter buffer level

– initial frequency discrepancy is eventually compensated
– jitter buffer level corresponds to frequency offset
• Although highly robust, there are several faults

– entire network jitter transferred to local clock
– unstable and vulnerable to packet loss
– jitter buffer level may settle far from buffer center
– long convergence times

Introduction cont.
TXC PacketTrunk-4 chip's innovative clock recovery scheme

• retains robustness of conventional scheme
• improved capabilities
• Two phases
– acquisition phase
• rapid frequency lock is attained.
– tracking phase
• the achieved frequency lock is sustained
• jitter buffer centering (according to configuration value)
• jitter attenuation standards conformance for large PDV
• packet loss immunity improved.

Frequency Hold-over
Rx buffer starvation (under-run) can be caused by:

• Network congestion
• packet loss
• In dynamic application when there is no activity
• While shifting to an alternate bundle, in redundancy mode
- Last frequency is frozen, until data flow is resumed.

- No need for re-acquisition!
• Long-term recovered clock accuracy:

– E1/T1: better than 0.02 ppm

Standards

2.
PacketTrunk-4

Why TDMoIP?
Complementary to VoIP.
Provides high voice quality with low latency.
Can support all applications that run over E1/T1 circuits, not just
voice.
Can be made transparent to protocols and signaling.
An evolutionary – not revolutionary – approach, so investment
protection is maximized.

Voice Evolution
Circuit Switching Packet Switching
PSTN ATM IP/MPLS
Leased-Line Service Circuit Emulation TDMoIP/MPLS (CBR)

Service
Switched Voice VoATM (ATM LES) TDMoIP/MPLS (VBR)

Service VoIP

PacketTrunk-4: What is it?
• PacketTrunk-4 enables transparent transport of legacy TDM traffic over

IP/MPLS Networks.
• PacketTrunk-4 uses three payload types for TDM transfer over IP/MPLS:
– CBR payload type for circuit emulation -- Constant Bit Rate with static allocation of
TDM timeslots)
– VBR payload type for loop emulation -- Variable Bit Rate with dynamic allocation of
TDM timeslots
– HDLC payload type for efficient transfer or termination of frame based traffic
• PacketTrunk-4 is a highly integrated device for use in a wide variety of
applications. It provides a single-chip solution for 4x T1/E1's or 1x
T3/E3/STS-1 highly scalable to large multi-chip systems.

Press Release
"RAD Data Communications Partners With

TranSwitch Corporation to Develop Innovative
TDM over IP Line for Packet-Switched
Networks"
Advanced Devices Will Enable Efficient Voice and

Data Delivery Over IP/MPLS Carrier and Enterprise Systems
Tel Aviv -- January 7, 2003…

PacketTrunk-4 Block Diagram
TDM SIDE PSN SIDE

+2.5V
Buffer SDRAM
+3.3V
32
Adr/Row/Col Data Ctrl
T1/E1/T3/E3/STS-1 Serial Port 1 10

PacketTrunk-4
19 10/100 Ethernet
Port 2 10
TDMoIP/MPLS Gateway MII/RMII/ SMII/SSMII
T1/E1 Serial Port 3 10 Device

TXC-05870
Port 4 10
24 32 38 5 2
Address Data Ctrl JTAG Clocks
Microprocessor Port

PacketTrunk-4 Block Diagram
SDRAM Bus
32 bits
PacketTrunk-4
Clock SDRAM
Queue
Recovery Controller
Manager
Machines
Jitter
Buffer
10/100 MII/RMII/
Controller
1x T3/E3/STS-1 128 Payload Et MAC
Engine SMII/SSMII
or Channel
4x T1/E1/Serial TSI Packet
Classifier
Tx Sig/ CAS Host Counters &

Rx Sig Signaling I/F Status Regs
Handler
Host Bus
TranSwitch Corporation Proprietary & Confidential 16/32 bits 50
PacketTrunk-4 Key Features
• Interfaces
– PSTN/Serial: 1x T3/E3/STS-1 or 4x T1/E1/Serial (up to 4.64 Mbps/port,
9.3Mbps aggregate)
– Packet: 1x 10/100 802.3 Ethernet MAC I/F
• MII/RMII/SMII/SSMII (half or full duplex)
• VLAN tagging and priority labeling per 802.1p & Q
– CPU:
• 24-bit address, 16- or 32- bit data bus.
• Control/status registers, counters, buffers (for OAM and signaling)
– SDRAM: 32 bit. 8 or 16 MB off-chip
• Resolution of access to SDRAM: 8, 16, or 32 bit
• Controller operates at either 50, 75, or 100 MHz
• Support, examples: 64 Mb Micron MT48LC2M32B2TG-6, 128 Mb Micron
MT48LC4M32B2TG-6
– JTAG

PacketTrunk-4 Key Features -
Continued
• TDM Payload Types over IP/MPLS

– AAL1 un-structured
– AAL1 structured
– AAL1 structured with CAS
– AAL2
– HDLC
• User Ports
– E3/T3/STS-1: AAL1 unstructured
– E1/T1:
• Unframed - E1/T1pass-through: AAL1 unstructured or HDLC payload type
• Nx64 Kbps – Fractional T1/E1: AAL1 unstructured & structured, AAL2, HDLC
• Structured with CAS – Fractional T1/E1 with CAS: AAL1 structured with CAS or AAL2
– Synchronous Serial Data
• Using AAL1 unstructured or HDLC payload type
• For continuous bit stream (ex. V.35) or HDLC-based (ex. Frame Relay) transfer.
• Single port: up to STS-1 rate (51.84 Mbps)
• Four ports: each port can operate at up to 4.64 Mbps with an aggregate rate of 9.3 Mbps
• Gapped clock support.

continued
• Support Multiple Bundles and Time-Slot Interchange (TSI)

– Supporting up to 128 timeslots. Sub-rate channels of 2, 7, or 8 bits,
as well as Nx64 Kbps (N=1 to 32) are supported in HDLC mode.
– Up to 64 independent bundles,
– assignable via TSI to Payload Engine; or to the host interface. Each
bundle has its own:
• Tx and Rx queues
• Rx jitter buffers with configurable depth
– T1: up to 256 ms (unframed T1 up to 340 ms)
– E1: up to 256 ms
– T3: up to 46 ms
– E3: up to 60 ms
– STS-1: up to 40 ms
• (CBR mode only) Optional connection-level redundancy; packet payload
may be Tx'd twice with two different Ethernet, IP/ MPLS headers. Two
different IP addresses may be used for Rx.
• Enable/disable

continued
• Encapsulations:
– TDMoIP via CBR or VBR
– TDMoMPLS via CBR or VBR
– HDLCoIP
– HDLCoMPLS
• Clock Recovery
– Independent TDM clock recovery per TDM interface for end-to-end TDM sync
through an IP/MPLS network. Recovered clock jitter and wander are
standards-compliant (ex. freq accuracy of 1-2 ppm)
– Two major successive phases for CR:
• Acquisition phase: attain rapid frequency lock (e.g., less than 10 seconds for a full
E1/T1 bundle)
• Tracking phase: sustain the achieved freq lock while gradually bringing the jitter-
buffer level back to its center. Jitter is attenuated to comply with relevant
standards
– Conform to G.823/G.824 jitter and wander requirement

continued
• RTOS-independent, abstracted host API source code

– Programming the PacketTrunk-4
• Assigning timeslots to bundles
• Opening bundles
• Closing bundles
• Sending frames
• Receiving frames
• Creation, Configuration, Run time, Status, Deletion…

continued
• Management and Control Plane Functions

– On-chip support of CAS/RBS signaling
• Testing and Loopback

– Boundary scan per IEEE 1149.1
• Physical Characteristics
– Voltage: 2.5v core, 3.3v I/O.
– Size: 27 x 27 mm (1.27 mm pitch)
– Package: 256-pin PBGA
– Power: TBD
– Op temp: -40 to +85 C (industrial)

PacketTrunk-4 Key Product Status
• Data Sheet Available
•TDMoIP O’Head calculator Available
• Clock recovery test results Available
• API Spec Available
• Sales Brochure Available
• Demo Board FPGA T1/E1 Only Available
• Tape-out Nov. 17, 2003
• Customer Samples Jan. 16, 2003
• IBIS Model Available
• BSDL File Available

4x T1/E1 PacketTrunk-4 System
SDRAM
QT1F+
10/100 Et 10/100 Et
T1/E1 : T1/E1 LIU : or : PacketTrunk-4
PHY
QE1F+
MII/
RMII
CPU

1x T3/E3/STS-1 PacketTrunk-4 System
SDRAM
DART
10/100 Et 100 Et
T3/E3/STS-1 or PacketTrunk-4
PHY
ARTE
MII/
RMII
CPU

1x OC-3/STM-1 PacketTrunk-4 System (T3/E3-
Based)
SDRAM
3x
Combus T3/E3
STS-3/
STM-1
10/100 Et 10/100 Et
PHAST-3N TL3M PacketTrunk-4
Switch PHY
MII/
RMII
CPU

1x OC-3/STM-1 PacketTrunk-4 System (T1/E1-
Based)
SDRAM
28x T1/
STS-3/ Combus :
21x E1
STM-1
10/100 Et 10/100 Et
PHAST-3N TEMx28 PacketTrunk-4
Switch PHY
MII/
RMII
CPU

Mixed (TDM + Packet Data) Transport
over POS
SDRAM
: PacketTrunk-4
SMII
T1/E1 POS- POS- STS-12c/
: PHY PHY STM-4c
10/100Et
10/100 Et
: PHY
T1/E1
PHYLIU : TEPro : :
: EStream-8FE
EStream-8FE
Envoy-8FE NPU PHAST-12P
SMII
10/100
Ethernet CPU
: PacketTrunk-4
SDRAM
10/100Et
10/100 Et
10/100
PHYEt
PHY
PHY
 POS is the predominant optical transport mechanism for packet data.

Applications
• Carrier
– TDM services over Ethernet MAN
– TDM services over broadband Wireless Ethernet
– TDM services over Cable Ethernet
– 2G / 2.5G cellular backhaul over IP/MPLS
– HDLC-based traffic (ex. Frame Relay) trunking over IP/MPLS
– T/E carrier grooming (via Ethernet backplane)
– PSTN-IP network bridging
• Enterprise
– Private line/toll bypass via Ethernet MAN
– TDM PBX migration to Ethernet MAN
– MTU/MDU

TDM over GbE MAN
TDM Leased
Lines
CLASS Central
PSTN
Switch Office
TDMoIP GW
TDMoIP
GW
POP
GbE
PBX TDMoIP GW IP Customer

TDMoIP GW PBX
Premise
100 Mbps GbE 100 Mbps
Customer
Premise
Public
INTERNET

TDM Concentration
Features:
TDM concentration (grooming multiple T1/E1 into OC-3/STM-1 trunks)
E3/T3 Carrier Trunking
With:
GbE Network I/F PBX
PBX
OC-3/STM-1 TDM interface
ADM TDMoIP
GW
TDMoIP
GW
SDH/
CLASS SONET IPIP
Switch
TDMoIP
GW
SS7 TDMoIP
GW
ADM
PSTN
PBX

Metro MTU Application
Office Level Building Level Corporate Site A

Integration Integration
PBX
TDMoIP GW PBX
PBX
Corporate Site B
TDMoIP GW PBX
POTS
PBX
PBX
Switch TDMoIP Switch Switch TDMoIP
Switch/Router GW GW
IP/MPLS
Network PSTN
TDMoIP GW

Cellular Backhaul over IP/Ethernet
Fixed Wireless, Coax, or Fiber Access
/Cell sites w
TDMoIP
blade retrofits
/Switch site w
TDMoIP GW
Fiber FT1/T1/n*T1
CMTS
T1/ T3/ E1
100 Mbps Metro
(GbE, IP, RPR, Coax
HFC, EoS)
GW GW
FT1/T1/n*T1
Fixed
Wireless
FT1/T1/n*T1

SS7 over IP
User’s needs: Potential customers:

• Transparent SS7 forwarding over IP • Voice carriers
• Voice transferred as VoIP • Satellite providers
• Cross Connect functionality • Cellular operators
• MAN providers
Intelligent
Network
SS#7
PSTN Server
TDMoIP-based
signaling GW
TDMoIP-based TDMoIP-based
signaling GW signaling GW
GbE
Switch IP Network GbE
Switch
Public Public
Voice VoIP Voice
VoIP
Switch GW Switch
GW

TDMoIP Summary
• IP and Ethernet network technologies will be dominant in the future.

• Revolutionary VoIP may take more time to mature. Evolutionary solutions
that offer a careful migration path are now preferred.
• TDMoIP provides simplicity, transparency, and affordable cost, and that’s
actually what the market is looking for.
• PacketTrunk-4 allows the implementation of multi-T1/E1 TDMoIP
gateways with enhanced cost/performance for a variety of carrier and
enterprise applications across the network.

The PacketTrunk-4 Total Solution
Facilitates a faster time-to-market

Reduces the number of required board level components
Reduces the amount of time spent on design
Reduces development costs
Reduces component costs
PacketTrunk-4

Interoperability Tested:
Carriers Who Tested:

TDM Timing Recovery
& Measurements

Introduction
• PSN (e.g. IP) have no clock distribution mechanism

• For TDM over PSN receiver must recover clock
• Conventional adaptive clock slaves local clock to jitter buffer level
– initial frequency discrepancy is eventually compensated
– jitter buffer level corresponds to frequency offset
• Although highly robust, there are several faults

– entire network jitter transferred to local clock
– unstable and vulnerable to packet loss
– jitter buffer level may settle far from buffer center
– long convergence times

Introduction cont.
TDMoIP chip's innovative clock recovery scheme

• retains robustness of conventional scheme
• improved capabilities
• Two phases
– acquisition phase
• rapid frequency lock is attained.
– tracking phase
• the achieved frequency lock is sustained
• jitter buffer centering (according to configuration value)
• jitter attenuation standards conformance for large PDV
• packet loss immunity improved.

Theory of operation
• During acquisition phase

– direct estimation of frequency discrepancy drives local clock
– band-limited control loop
– rapid frequency acquisition (about 10 seconds for full E1/T1 bundle)
– capture range ±128 ppm for both E1 and T1
• Switch to tracking phase when steady frequency lock detected
• During tracking phase

– jitter buffer level drives local clock
– band-limited control loop

Features
• Fast frequency acquisition time:

– Full E1/T1 bundle (31/24 timeslots): about 10 seconds
– Full E3/T3 bundle: about 1 second
• Time for achieving stable phase lock (controlled wander):

– Full E1/T1 bundle: a few dozens of seconds
– Full E3/T3 bundle: a few seconds
• Long-term recovered clock accuracy:

• Digital frequency synthesizers jitter generation level:
– E1: 0.05 UIpp
– T1: 0.02 UIpp
• Digital frequency synthesis resolution is 1 ppm
• Capture range (E1, T1, E3, T3 rates): ±128 ppm around nominal
• Full compliance with G.823/G.824 jitter and wander (traffic interface)

Frequency Hold-over
Rx buffer starvation (under-run) can be caused by:

• Network congestion
• packet loss
• In dynamic application when there is no activity
• While shifting to an alternate bundle, in redundancy mode
- Last frequency is frozen, until data flow is resumed.

- No need for re-acquisition!

Measurements Setup
ETH NETWORK
IPmux-4
EMULATOR
TDMSOURCE
CLOCK
ETH
E1
ANT-20 RECOVERED
JITTER AND TDM CLOCK TDMoIP CHIP
WANDER EVALUATION
MEASUREMENT E1 BOARD
DEVICE

Measurements Details
Measurement Setup
• ANT-20 (Wandel & Goltermann) jitter / wander measurement device sends and
receives TDM signal from both ends
• RAD IPmux-4 transmit TDMoIP flow
• Network emulator introduces packet loss and PDV (jitter)
• TDMoIP Chip evaluation board recovers the clock and reconstruct the original
TDM flow
Network emulator function:

• Jitter insertion
Every (configurable) number of packets the flow is halted for an uncorrelated and
exponentially distributed random period of time.
• Packet loss
A packet is dropped every (configurable) number of packets

Performance - Wander
Wander MRTIE (Max Relative Time Interval Error)
Bundle configuration: E1, 31 timeslots, 48 bytes payload

Performance - Jitter
Network 20 Hz – 18 kHz – Long-

Peak 100 kHz 100 kHz Term
Delay Bandwid Bandwidt Frequenc
Variation th h y Offset
[UIpp] [UIpp] [µppm/12
[ms]
0 0.04 0.01 hours]
5.5
5 0.07 0.015 3.6
Std. Req. 1.5 0.2

Performance - Wander
Wander MRTIE (Max Relative Time Interval Error)

Performance - Jitter
Network 20 Hz – 18 kHz – Long-

Peak 100 kHz 100 kHz Term
Delay Bandwidt Bandwidt Frequenc
Variation h h y Offset
[ms] [UIpp] [UIpp] [µppm/12
5 0.06 0.015 hours]
0.2

More Measurements
Jitter measurement: E1, 31 Time Slots, 1 cell (48 payload bytes)/packet for
different IPDV levels

More Measurements
Jitter measurement : E1, 31 Time Slots, 1 cell (48 payload bytes)/packet for
the zero IPDV network

More Measurements
Jitter measurement : E1, 31 Time Slots, 5 cells (240 payload bytes)/packet
for different IPDV levels

More Measurements
Jitter measurement : E1, 31 Time Slots, 5 cells (240 payload bytes)/packet
for the zero IPDV network

More Measurements
Acquisition behavior: E1, 31 Time Slots, 1 cell (48 payload bytes)/packet for
different IPDV levels

More Measurements
Acquisition behavior: E1, 31 Time Slots, 1 cell (48 payload bytes)/packet for
zero IPDV levels

More Measurements
Acquisition behavior: E1, 31 Time Slots, 5 cells (240 payload bytes)/packet
for different IPDV levels

More Measurements
Acquisition behavior: E1, 31 Time Slots, 5 cells (240 payload bytes)/packet
for zero IPDV levels

3.
PacketTrunk-4
Demo

PacketTrunk-4 Application Demo
TDMoIP and HDLCoIP
Bundle #1
TDMoIP (AAL2)
Assigned TS:
Voice – 1, 2
FXS
E1
Sniffer IPmux-1 FCD-IP
FXS
Assigned TS:
Voice – 21, 22, CLK Recovery LBT
24, 25
HDLC – 1÷15
Boston
FXS
FXS
FXS
E1 PacketTrunk-4
FCD-IP ETH HUB
FXS Eval-Board
Int CLK LBT IP Network Assigned TS:

Voice – 1, 2
San Jose HDLC – 17÷31
FXS
PacketTrunk-4 E1
FCD-IP FXS
Eval-Board
Bundle #11 CLK Recovery LBT

TDMoIP (AAL1)
New York
Bundle #7
HDLCoIP
ETH ETH
MLB-E
Traffic Generator and Checker

TDMoIP (AAL1, AAL2) and HDLCoIP
• Integrated Service:
• Within one E1 (at center side, San Jose): Four phone lines
(4 DS0) + one HDLC data channel (15 DS0 time slots
grouped together)
• Grooming :
• Using “Bundle” to group multiple DS0 timeslots within the
same E1 to form different “bundles” and then deliver to
different destinations
• Virtual DS0 Cross-connect :

• Any DS0 time slot at the source end can be virtually cross-
connected to the different timeslot at the sink end through
the IP network

TDMoIP (AAL1, AAL2) and HDLCoIP
• VBR v.s. CBR:

• VBR for SVC channel (Bandwidth is only used when the
call is set up; Bandwidth is released when call is
disconnected)
• CBR for PVC channel (Bandwidth is constantly used)
• Frequency hold-over activated at the clock

recovery circuitry when network connection is
broken.
• Clock is recovered instantaneously after network
connection is reinstalled

Packettrunk - 4: Tdmoip / Mpls Gateway Device

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Packettrunk - 4: Tdmoip / Mpls Gateway Device

Uploaded by

Copyright:

Available Formats

TDMoIP / MPLS Gateway Device

Feb. 03, 2004

TranSwitch Corporation Proprietary & Confidential 2

TranSwitch Corporation Proprietary & Confidential 3

Pseudowire (PW): A mechanism that emulates the

TranSwitch Corporation Proprietary & Confidential 4

Mating different network protocols is called interworking

The protocol converter goes by various names :

Simplest case is network interworking

Native network Native

TranSwitch Corporation Proprietary & Confidential 5

From PSTN to PSN

TranSwitch Corporation Proprietary & Confidential 6

Access Network Core (Backbone) Network

• Circuit switched ensures signal integrity

TranSwitch Corporation Proprietary & Confidential 7

The TDMoIP approach replaces the Network

TranSwitch Corporation Proprietary & Confidential 8

• G.114 (One-way transmission time)

• G.826 (error performance)

TranSwitch Corporation Proprietary & Confidential 9

Two ways to integrate TDM services into PSNs

TranSwitch Corporation Proprietary & Confidential 10

• VoIP has promising future

• PSTN is not going to be replaced overnight

TranSwitch Corporation Proprietary & Confidential 11

TranSwitch Corporation Proprietary & Confidential 13

encapsulation (encap) : process of adding protocol

TranSwitch Corporation Proprietary & Confidential 14

What needs to be transported from end to end?

TranSwitch Corporation Proprietary & Confidential 15

Why don’t we simply encapsulate the T1/E1 frame?

IP UDP RTP? T1/E1 frame

Because a single lost packet would cause service interruption

TranSwitch Corporation Proprietary & Confidential 16

Those problems can be solved by:

UDP/IP seqnum ptr T1/E1 frames (only timeslots in use)

Good idea! This is precisely AAL1 !

TranSwitch Corporation Proprietary & Confidential 17

“AAL1” is the simplest method to transport

Any alternative will either

TranSwitch Corporation Proprietary & Confidential 18

AAL1 is inefficient if the timeslots are not always in use

Although we can configure which timeslots are used

To allow dynamic allocation of timeslots

AAL2 buffers each timeslot and encapsulates in a “minicell”

Bandwidth conservation comes at a price

TranSwitch Corporation Proprietary & Confidential 19

AAL1 is BW inefficient when timeslots are dynamic

“AAL2” is the simplest method to transport

TranSwitch Corporation Proprietary & Confidential 20

AAL1 and AAL2 are adaptation protocols

Rather we put the AAL1/2 directly into a UDP/IP or MPLS packet

So, NO, this is NOT ATM

But it can easily interwork with ATM access networks!

TranSwitch Corporation Proprietary & Confidential 21

TDMoIP is not the first TDM emulation technology

E1/T1 ATM-MPLS IWF

AAL1 AAL2 AAL5

TranSwitch Corporation Proprietary & Confidential 22

• Efficiently transfer CCS traffic (such as SS7