(12) United States Patent
`Silverman
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,731,649 Bl
`May 4, 2004
`
`I lllll llllllll Ill lllll lllll lllll lllll lllll 111111111111111111111111111111111
`US006731649Bl
`
`(54) TDM OVER IP (IP CIRCUIT EMULATION
`SERVICE)
`
`(75)
`
`Inventor: Hugo Silverman, Tel-Aviv (IL)
`
`(73) Assignee: RAD Data Communication Ltd., Tel
`Aviv (IL)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 711 days.
`
`(21) Appl. No.: 09/626,335
`
`(22)
`
`Filed:
`
`Jul. 26, 2000
`
`(51)
`(52)
`(58)
`
`(56)
`
`Int. Cl.7 ................................................ H04L 12/66
`U.S. Cl. ................ 370/466; 370/395.1; 370/395.52
`Field of Search .............................. 370/466, 395.1,
`370/401, 474, 352, 353, 395.52, 395.5
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,548,646 A
`5,623,605 A *
`5,715,250 A
`5,903,559 A
`5,936,936 A
`5,936,965 A
`
`8/1996 Aziz et al.
`4/1997 Keshav et al.
`2/1998 Watanabe
`5/1999 Acharya
`8/1999 Alexander, Jr. et al.
`8/1999 Doshi et al.
`
`8/1999 Allan et al.
`5,946,313 A
`6,459,708 Bl
`10/2002 Cox et al.
`6,519,261 Bl * 2/2003 Brueckheimer
`et al. ... .. ... ... ... ... ... . 370/395.52
`6,574,224 Bl * 6/2003 Brueckheimer et al.
`. 370/395.6
`6,603,850 Bl * 8/2003 Stahl et al.
`... ... ... ... 379/221.02
`* cited by examiner
`Primary Examiner-Kenneth Vanderpuye
`(74) Attorney, Agent, or Firm-Katten Muchin Zavis
`Rose nm an
`
`(57)
`
`ABSTRACT
`
`A method and system for processing one or more TD Ms for
`communication over IP networks, such as the Internet,
`includes encapsulating ATM cells (packets) using AALl
`cells within UDP over IP frames to provide synchronous bit
`streams into fixed size cells. This allows for an IP header to
`be added to the packets, with such packets forwarded to its
`destination host across the IP network. The destination
`regenerates the clock, decrypts/strips the IP header and
`delivers a synchronous bit stream. Furthermore, an adaptive
`clock is provided for clock transfer across the network. The
`adaptive clock regenerates the far end Tl/El receive clock
`out of the incoming arrival frame rate. Frames arriving from
`the IP network are stored in a buffer and taken out for TDM
`stream assembly.
`
`41 Claims, 4 Drawing Sheets
`
`5
`
`4
`
`3
`
`2
`
`i
`
`E1iT1
`
`~~of~
`·
`by framer w
`
`T
`Build structures I
`according to CES
`2.0 lli
`
`1
`
`:
`
`T
`I
`Segment
`!
`structures into
`i
`i AAL 1 cells with no
`I
`',
`cell header
`.J!?l
`I
`
`I
`T
`j .Packet the cells
`I
`! 'nto UDP over IP I
`I over Ethernet
`frames l.,lil 1
`
`,
`
`i
`
`\ Transmit frames
`
`I
`
`~2. I
`
`2
`
`3
`
`4
`
`5
`
`302.s
`
`EliT1 framer
`
`~22...
`
`:a:
`
`Packet delay
`variation buffer
`compansation
`
`3z...<> •
`
`1
`
`I
`,
`I Calls reassembly I
`into structures
`/ according CES I
`'¥
`
`2.0
`
`from UDP payload
`
`Stnp the cells I
`3l"' •
`/ Receive Ethernet I
`I
`frames
`I
`3.-4
`
`Pet., Exh. 1005, p. 1
`
`

`
`U.S. Patent
`
`May 4, 2004
`
`Sheet 1 of 4
`
`US 6, 731,649 Bl
`
`Site A
`
`lOS
`
`ro=i1 1011
`
`I
`
`I
`
`l 03
`
`1ooeasor
`
`1=-1
`l'---7'~·---L--j
`
`)
`
`i1aoeaser
`
`I
`
`I
`
`II
`
`
`
`\. C>.2_
`
`(
`!
`
`\
`
`\c)s-
`
`I
`
`~ ~ _J 1:_ j~Lo+
`
`10~
`;·"I , -·~-a 1
`?BX ·j
`
`PBX
`
`Pet., Exh. 1005, p. 2
`
`

`
`U.S. Patent
`
`May 4, 2004
`
`Sheet 2 of 4
`
`US 6, 731,649 Bl
`
`1,
`
`'""\
`oc.
`0
`
`.,
`._
`
`!
`
`i
`
`1
`
`I
`I
`ce11s. 1
`f.:i.o3.z
`AAL112.
`,_ ______ _. .. , Segmentation .-+' packetazition
`r---""---.111
`[~unit
`\ \~IPframes J
`I
`
`J
`
`.:2.0&
`Ii -
`I
`
`I
`
`j E1/T1 framer i
`
`i
`I
`1
`
`I
`
`I
`
`[
`
`I
`
`I
`
`ETH PHY
`
`I
`' - - - - . . . J
`
`,
`111~ I
`I
`I
`.3..J.L,
`!
`[
`l
`I
`AALl/Z
`PDVT 1- !
`,.......--,----
`~ ~ Reassembly +---
`I i buffer
`I
`I
`unrt
`! from IP frames /
`
`: Cel~ing LJ
`
`1'
`
`I
`
`i
`
`!
`
`i
`
`I ETH controller H'
`
`Pet., Exh. 1005, p. 3
`
`

`
`U.S. Patent
`
`May 4, 2004
`
`Sheet 3 of 4
`
`US 6,731,649 Bl
`
`1
`
`0.ecoA~
`E1/T1 9Ai&iiliR
`by framer w
`
`2
`
`i
`! Build structures
`I acconJin~ to CES
`
`I
`
`•
`
`1
`
`y
`
`3
`
`Segment
`structures into
`AAL 1 cells with no
`cell header
`
`'f
`j Packet the cells
`I into UDP over IP
`i over E!hemet
`frames l 'O 1
`:
`.,
`
`Transmit frames
`
`4
`
`5
`
`5
`
`E 1IT1 framer
`
`~'22..
`
`4
`
`3
`
`2
`
`Packet delay
`variation buffer
`compansation
`3z....c
`
`I Calls reassembly
`into structures
`according CES
`2.0
`
`1
`
`I
`
`S>\.f t
`
`I Stno the cells
`, from UDP payload
`I
`3l'9
`
`I
`
`-
`
`1 I Receive Ethernet
`frames
`I
`,4
`
`Pet., Exh. 1005, p. 4
`
`

`
`U.S. Patent
`
`May 4, 2004
`
`Sheet 4 of 4
`
`US 6,731,649 Bl
`
`Half fill level
`
`TOM bytes from
`received frames
`1 ,.i
`~ I
`l-----~------1
`
`POVT buffer
`
`'410 i
`Paci<et anival indication
`i
`
`Fifi level
`
`iA07
`
`E1/T1 stream
`
`-4 ..1..0
`
`I 1l
`
`I
`
`•
`
`y
`
`Fill level indication
`
`"76<6
`
`I
`
`I
`
`I +
`
`4(4
`
`+
`
`I
`
`4t~
`
`Filter
`
`l_J "'f-\'i)
`I
`
`vcxo
`
`!
`
`I
`
`Nominal fill
`I level (half
`\~It.fill)
`
`1
`
`Pet., Exh. 1005, p. 5
`
`

`
`US 6,731,649 Bl
`
`1
`TDM OVER IP (IP CIRCUIT EMUIATION
`SERVICE)
`
`BACKGROUND OF THE INVENTION
`
`25
`
`1. Field of Invention
`The present invention relates generally to the field of
`communications. More specifically, the present invention is
`related to a system and method for transferring TDM data
`over packet switched networks, such as IP networks.
`2. Discussion of Prior Art
`T-1 (DSl) trunks are circuit switched data networks
`supporting data rates of 1.544 Mbits per second. A T-1 trunk
`can carry 24 individual 64 Kbits per second channels, each 15
`of which may carry data or telephony quality voice.
`Similarly, El trunks are circuit switched data networks
`supporting data rates of 2.048 Mbps (32 channels at 64
`Kbps). T-3 and E3 trunks support data rates of 44,736 and
`34,368 Kbps, respectively. Together Tl, El, T3, E3 and 20
`similar circuit switched serial networks are known as TDM
`networks.
`TDM, short for Time Division Multiplexing, is a type of
`multiplexing that combines data streams by assigning each
`stream a different time slot in a set. TDM repeatedly
`transmits a fixed sequence of time slots over a single
`transmission channel. Within T-Carrier systems, such as T-1
`and T-3 (DS3), TDM combines Pulse Code Modulated
`(PCM) streams created for each in conversation or data
`stream.
`ATM, short for Asynchronous Transfer Mode, represents
`a network technology based on transferring data in cells of
`a fixed size. The cell used with ATM is relatively small (53
`bytes) compared to units used with older technologies. The
`small, constant cell size allows ATM equipment to transmit
`video, audio, and computer data over the same network, and
`assure that no single type of data hogs the line.
`Current implementations of ATM support data transfer
`rates of from 1.544 (Tl) to 622 Mbps (megabits per second).
`This compares to a maximum of 1000 Mbps (GbETH) for
`Ethernet, the current technology used for most LANs. ATM
`over IP pseudo OSI layers comprise an upper protocol, ATM
`Service Specific Convergence Sublayer (ATM-SSCS), nec(cid:173)
`essary to translate between the ATM layer and RTD/UDP/IP 45
`sublayers. The User Datagram Protocol (UDP) is a connec(cid:173)
`tionless protocol that, like TCP, runs on top of IP networks.
`Unlike TCP/IP, UDP/IP provides very few error recovery
`services, offering instead a direct way to send and receive
`data grams over an IP network. Sub-layers provide the 50
`Ethernet type, MAC header and PHY Ethernet respectively.
`High-speed IP-based networks are the latest innovation in
`the world of communications. The capacity of these net(cid:173)
`works is increasing at a prodigious rate, fueled by the
`popularity of the Internet and decreasing costs associated
`with the technology. Worldwide data traffic volume has
`already surpassed that of the telephone network, and for
`many applications, the pricing of IP traffic has dropped
`below the tariffs associated with traditional TDM service.
`For this reason, significant effort is being expended on VoIP
`technologies. For users who have free, or fixed-price Inter(cid:173)
`net access, Internet telephony software essentially provides
`free telephone calls anywhere in the world. To date,
`however, Internet telephony does not offer the same quality
`of telephone service as direct telephone connections. There 65
`are many Internet telephony applications available. Some
`come bundled with popular Web browsers; others are stand-
`
`2
`alone products. Internet telephony products are sometimes
`called IP telephony, Voice over the Internet (VOi) or Voice
`over IP (VOiP) products.
`Inherent in all forms of VoIP is revolutionary change,
`whereby much of the existing telephony infrastructure will
`be replaced by novel IP-based mechanisms. Despite the
`hype, this effort has been more protracted and less successful
`than initially expected. Today's telephony technology, both
`those portions that VoIP aims to replace and those to which
`10 VoIP must interface, is extremely complex. Revolutionary
`implementations of its hundreds of features and thousands of
`variations cannot be expected to be developed in a short time
`frame.
`The present communications revolution has been focused
`on the Internet and the Internet protocol (IP). The prior art,
`however, has failed to teach a viable solution to handling
`TDM over Internet Protocol (IP). In addition, the use of
`TDM over IP for Voice over IP has not been heretofore
`possible.
`Why Use IP Networks? The existing telephony infrastruc(cid:173)
`ture has an extremely high reliability (99.999%), supports
`reasonable audio quality (Mean Opinion Score, or MOS, 4.0
`on a scale of 1 to 5), has almost universal market
`penetration, and offers a rich feature set. Accordingly,
`extremely potent incentives are required before one should
`consider supplanting it. There are two such incentives, one
`economic and one technological.
`The part of the economic advantage of IP networks is
`30 shared by all packet networks; namely, that multiple pack(cid:173)
`etized data streams can share a circuit, while a TDM timeslot
`occupies a dedicated circuit for the call's duration. Under
`"polite conversation" assumption of each party speaking
`only half of the time, and the "optimal engineering" assump-
`35 tion of minimal overhead, packet networks will, on average,
`double the bandwidth efficiency, thus halving operational
`costs. Taking overhead and peak statistics into account, the
`savings will be somewhat less, but a 30% reduction is
`attainable. However, it is doubtful whether this savings
`40 alone would be a strong enough encouragement to make the
`switch from TDM to IP.
`The added catalyst has to do with the raw rates for data
`traffic as compared to voice traffic. At present, data com(cid:173)
`munications are metered separately from traditional voice
`communications and are offered at substantial savings.
`These savings are partly due to tariffs and access charges
`that increase the cost of traditional voice services, and partly
`due to the attractive pricing of IP traffic. Put another way,
`voice service pricing is still mostly determined by incum(cid:173)
`bent carriers with high overhead costs, while IP traffic costs
`are much more competitive, as the provider incurs lower
`costs and is more focused on increasing market share.
`The technological incentive has come to be called con(cid:173)
`vergence. The reasoning is that technological simplification
`55 and synergy will result from consolidation of the various
`sources into an integrated environment. For example, a
`single residential information source provisioned for
`telephony, IP data and entertainment programming would in
`principle decrease end user prices, result in a single unified
`60 billing package, and eventually enable advanced services,
`such as video-on-demand.
`The Limitations of VoIP
`In principle, it would not seem difficult to carry voice over
`IP networks; a digitized voice signal is simply data and can
`be carried by a packet network just like any other data. The
`major technological achievement of the telephone network,
`that of least cost routing, has its counterpart in IP networks
`
`Pet., Exh. 1005, p. 6
`
`

`
`US 6,731,649 Bl
`
`3
`as well. There are, however, two fundamental problems that
`have to be solved before VoIP can be realistically considered
`to compete with TDM networks; namely, QoS and signaling.
`Quality of Service
`The meaning of Quality of Service is completely different
`for data and voice. Although most data can withstand
`relatively significant delay, low delay and proper time order(cid:173)
`ing of the signal are critical for voice applications, even
`though loss of a few milliseconds of signal is usually not
`noticeable. These requirements are completely at odds with 10
`the basic principles of IP networks (although not necessarily
`with those of other packet networks). To overcome these
`constraints, mechanisms such as tunneling and jitter buffers
`need to be employed. Additional components of voice
`quality such as echo cancellation and voice compression are 15
`not inherent in data-based networks at all, and need to be
`added ad hoc for VoIP.
`Almost all of the massive R&D effort in the field of VoIP
`is directed towards solving these QoS problems, leaving the
`signaling problem largely unsolved. By signaling, we mean
`the exchange of information needed for a telephone call
`other than the speech itself Signaling consists of basic
`features such as the fact that the phone is off-hook or needs
`to ring; more advanced properties required for reaching the
`proper destination and billing; and still more sophisticated
`characteristics, such as caller identification, call forwarding,
`and conference calls; as well as more recent additions
`necessitated by intelligent networking. There are literally
`thousands of such telephony features, with dozens of
`national and local variations. Phone customers are mostly
`unaware of this complexity, at least until you try to deprive
`them of any of the features to which they have become
`accustomed.
`Adding auxiliary information to digital voice on an IP
`network is in principle much simpler than signaling in 35
`telephone networks. One needn't "rob bits" or dedicate CAS
`channels. One need only send the signaling data in some
`appropriate format along with the voice. Indeed, the advan(cid:173)
`tage of VoIP is that it becomes possible to add features that
`could not exist in the classic telephony world, for example
`video and "whiteboards." This is true as long as the two
`sides to the conversation are using special VoIP terminals or
`computers. The problems arise when one must interface
`between the IP network and the standard telephony network,
`a connection that is imperative in light of the universal 45
`availability of standard telephone sets.
`VoIP enthusiasts often emphasize conversations between
`two PC users or a PC user conversing with a telephone user.
`Consider instead a conversation between two telephone
`users, each connected via a standard Local Loop to a central 50
`office, but with an IP-based network replacing the TDM
`network between the central offices. To properly pass the
`requisite signaling, the IP network has to be enhanced to
`handle all the thousands of features and their variations (for
`example, 911 and *67 service). Although not an impossible 55
`task, it is one that VoIP developers have not yet accom(cid:173)
`plished.
`Each of the below described references teach methods for
`communications using differing protocols, such as ATM
`over IP, across various communication standards. However, 60
`none of the references provide or suggest the present inven(cid:173)
`tion method of TDM over IP.
`The patent to Keshav et al. (5,623,605), assigned to
`Lucent Technologies, Inc., provides for Methods and Sys(cid:173)
`tems for Interprocess Communication and Inter-Network 65
`Data Transfer. Disclosed is the transmission of data packets
`between source and destination devices wherein generated
`
`4
`and received data are in ATM-formatted frames and the
`network transmits data in Internet protocol packets. Such
`data transfer is accomplished using encapsulators and decap(cid:173)
`sulators to encapsulate ATM formatted frames in data por(cid:173)
`tions of IP packets for transmission on the network. (See
`Column 2, Line 59-Column 3, Line 25).
`The patent to Allan et al. (5,946,313), assigned to North-
`ern Telecom Limited, provides for a Mechanism for Multi(cid:173)
`plexing ATM AAL5 Virtual Circuits over Ethernet. This
`reference describes a method for encapsulating/segmenting
`ATM cells over Ethernet.
`The patent to Aziz et al. (5,548,646), assigned to Sun
`Microsystems, Inc., provides for a System for Signature less
`Transmission and Reception of Data Packets Between Com(cid:173)
`puter Networks. Aziz et al. disclose a system for automati(cid:173)
`cally encrypting (by adding an IP header) and and decrypt-
`ing a data packet sent from a source host to a destination host
`across a network (See Column 2, Lines 13+).
`The patent to Doshi et al. (5,936,965), assigned to Lucent
`20 Technologies, Inc., provides a Method and Apparatus for
`Transmission of Asynchronous, Synchronous, and Variable
`Length Mode Protocols Multiplexed over a Common
`Bytestream. This reference describes a system for supporting
`the transmission and reception of ATM over a common
`25 bytestream with a common physical layer datalink.
`The patents to Watanabe (5,715,250--ATM-LAN connec(cid:173)
`tion apparatus of a small scale capable of connecting
`terminals of different protocol standards and A TM-LAN
`including the ATM-LAN connection apparatus); Acharya et
`30 al. (5,903,559-Method for Internet protocol switching over
`fast A TM cell transport), and Alexander, Jr. et al. (5,936,
`936-Redundancy mechanisms for classical Internet proto(cid:173)
`col over asynchronous transfer mode networks) provide a
`general teaching of IP over ATM.
`The non-patent literature entitled "Pathbuilder S200 Voice
`Access Switches" http://searchpdg.adobe.com/proxies/l/70/
`33/43.html, provides for TDM-based voice and data traffic
`over frame relay or IP WAN Infrastructures.
`The non-patent literature entitled "Project: Gateway
`40 Application-ATM<->IP," http://www.cse.ucsc.edu/
`-rom/projects/atm_ip/atm_ip.html, describes an ATM
`driver over an IP driver.
`The present invention offers a solution for transferring
`transparently El or Tl (or fractional El/Tl) TDM services
`over widely deployed high speed IP networks. This tech(cid:173)
`nology can be used as a migration path to Voice over IP or
`a complementary solution to VoIP in places where voice
`over IP solution is not suitable. The same TDM over IP
`approach can be adopted to transfer other TDM rates (e.g.,
`E3/T3, STMl etc.) over the IP network. Throughout the
`specification, claims and drawings various TDM rates may
`be substituted without departing from the scope of the
`present invention.
`Whatever the precise merits, features and advantages of
`the above cited references, none of them achieve or fulfills
`the purposes of the present invention. These and other
`objectives are achieved by the detailed description that
`follows.
`
`SUMMARY OF THE INVENTION
`A method and system for processing one or more TDMs
`trunks for communication over IP networks, such as the
`Internet, includes encapsulating ATM cells (packets) using
`AALl cells within UDP over IP frames to provide synchro(cid:173)
`nous bit streams into fixed size cells. This allows for an IP
`header to be added to the packets, with such packets
`forwarded to its destination host across the IP network. The
`
`Pet., Exh. 1005, p. 7
`
`

`
`US 6,731,649 Bl
`
`5
`destination regenerates the clock, decrypts/strips the IP
`header and delivers a synchronous bit stream. Furthermore,
`an adaptive clock is provided for clock transfer across the
`network. The adaptive clock regenerates the far end Tl/El
`receive clock out of the incoming arrival frame rate. Frames
`arriving from the IP network are stored in a buffer and taken
`out for TDM stream assembly.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 illustrates an overall implementation of the present
`invention TDM over IP.
`FIG. 2 illustrates a block diagram of the functional units
`of the present invention.
`FIG. 3 illustrates a flow diagram of receive and transmit
`paths.
`FIG. 4 illustrates an adaptive clock method for TDM over
`IP.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`While this invention is illustrated and described in a
`preferred embodiment, the device may be produced in many
`different configurations, forms and materials. There is
`depicted in the drawings, and will herein be described in
`detail, a preferred embodiment of the invention, with the
`understanding that the present disclosure is to be considered
`as a exemplification of the principles of the invention and the
`associated functional specifications for its construction and
`is not intended to limit the invention to the embodiment
`illustrated. Those skilled in the art will envision many other
`possible variations within the scope of the present invention.
`The present method and apparatus provide an alternative
`method of exploiting IP networks for telephony service that
`is evolutionary rather than revolutionary. This method uses
`IP networks as a drop-in replacement for native TDM
`networks. It seamlessly interfaces to all existing equipment,
`such as legacy PBXs and switches, and inherently provides
`all the hundreds of telephony features and the PSTN quality 40
`to which customers have become accustomed. This alterna(cid:173)
`tive is circuit extension over IP using TDMoIP. Another
`advantage is a simple gateway between ATM CES and TDM
`over IP.
`In order to explain the principles of TD Mo IP we need first 45
`to recall those of TDM. A Tl frame consists of 24 single(cid:173)
`byte timeslots and a single synchronization bit, for a total of
`193 bits. An El frame consists of precisely 32 bytes (256
`bits), one of which is used for synchronization and one
`traditionally reserved for signaling. In both cases, frames are 50
`transmitted 8,000 times per second.
`The following two solutions represent possible, but poten(cid:173)
`tially flawed, alternative approaches to implement TDM
`over IP. The simplest implementation of TDMoIP encapsu(cid:173)
`lates each Tl or El frame in an IP packet by tacking on the
`appropriate header. Since the packets provide the
`segmentation, the synchronization bit/byte need not be
`included. Accordingly, the payload length is 24 or 31 bytes
`for Tl or El, respectively. For reliable connection-oriented
`service one might consider using TCP/IP, which requires a
`20-byte TCP header and a 20-byte IP header, for a total of
`40 overhead bytes per packet. The end-to-end reliability
`offered by TCP, however, is not useful for voice packets
`since re-transmitted voice packets will reach the receiving
`side out of order and be dropped anyway. A more reasonable
`alternative would be the real-time transport protocol RTP,
`with its header of at least 12 bytes, to which one must add
`
`6
`an 8-byte UDP header and the IP header, resulting in the
`same overhead. A 40-byte overhead for a payload of 24 or
`31 bytes is indeed a bit extravagant, but there are two
`solutions to this problem.
`The first solution involves header compression schemes.
`RFCs exist that reduce the average header of both TCP and
`RTP to only three bytes, diminishing the overhead percent(cid:173)
`age to between eight and nine percent.
`The second solution involves grouping together multiple
`10 frames into a super-frame before encapsulation. For
`example, grouping eight Tl (El) frames results in a payload
`of 192 (248) bytes, so that the overhead percentage drops to
`a reasonable 17 (14) percent. Grouping does add a certain
`amount of buffering delay, but since each frame is only 125
`15 m sec in duration, this latency is negligible as compared with
`that of VoIP systems. For example, a super-frame comprised
`of eight successive frames introduces a one millisecond
`one-way delay, about half that of the standard 16 kbps low
`delay encoder used in VoIP, and much lower than the 15
`20 millisecond delay of the 8 kbps encoder.
`Simple encapsulation of the raw frames is not the only
`way of implementing TDMoIP. Alternative approaches first
`encode the TDM data in some other protocol before IP
`25 :~~~~=~l~~~~~· oI11;;~to~;l :e~~ee~d~~~tf~~ t~n~mfh~si~:.
`Intermediate encoding may be employed when the natural
`TDM-induced frame sizes are not appropriate; to provide
`error correction; to enable interoperability with other sys-
`30 terns; and to allow us to compress the speech or to enhance
`QoS.
`Circuit Emulation Service (CES) is already a well(cid:173)
`established standard in ATM and is defined by ATM Forum
`(AF-VTOA-0078)-Circuit Emulation Service Interoper-
`35 ability Specification Version 2.0-CES 2.0-CES 2.0
`(1997); using AALl cells is defined by ITU-T 1.363.1-
`ATM Adaptation Layer Specification: Type 1 AAL (1996).
`These standards already give solutions for CES implemen-
`tation for different modes of operation:
`Unstructured-Full El/Tl transparent service.
`Structured-Fractional El/Tl transparent service.
`Structured with CAS-Fractional El/Tl with CAS trans(cid:173)
`parent service.
`The present invention IP CES is based on ATM CES using
`AALl cells without ATM cell header) encapsulated in IP
`frames; by adopting this strategy only minimal regulatory
`activity is needed to set this service standard. The same
`methods can be equally adopted for DBCES (Dynamic
`bandwidth CES over AALl) or AAL2 encapsulated within
`IP frames without departing from the scope of the present
`invention. ATM cells (stripped from cell header) will be
`encapsulated within UDP over IP frames. Addressing com(cid:173)
`prises use of the UDP source port field to specify the
`destination of the AALl cells termination inter working
`55 function at the receiving device (will define the
`'connection')
`The IP network is not a Synchronous network and a
`common clock is not available at its nodes, while TDM
`services and CES functionality require synchronous timing
`60 at both ends. The present invention substitutes for clock
`transfer across the network an adaptive clock method,
`described hereafter. The adaptive clock is a method to
`regenerate the far end El/Tl receive clock out of the
`incoming arrival frame rate. Frames arriving from the IP
`65 network are stored in a buffer and taken out for TDM stream
`assembly, the fill level of this buffer is monitored and uses
`to adjust a PLL. When the buffer is filling up the regenerated
`
`Pet., Exh. 1005, p. 8
`
`

`
`US 6,731,649 Bl
`
`10
`
`7
`clock rate will be increased and when the buffer is getting
`empty the regenerated clock rate will be decreased.
`FIG. 1 illustrates one embodiment of a communications
`infrastructure using the present invention. This is a typical
`application where a fast IP backbone based Metropolitan
`Area Network (MAN) 100 is used to interconnect several
`sites (102, 103 and 104) to create a private network which
`handles both organization data and voice. One can see that
`the organization PBX's at all 3 locations A,B and C (102,
`103 and 104) are connected by a TDM over IP device 105
`to give transparent TDM links over the MAN IP backbone.
`'TDM' packets can be tagged by a ToS field in the IP header
`to get high priority when going through the IP network. Data
`connectivity is given on the same network (A and C) by
`routers 106 connected to the IP backbone. At all sites the 15
`access to the network is done by an Ethernet switch 107
`connecting both TDM over IP device 105 and organization
`data to the MAN 100.
`FIG. 2 illustrates a block diagram of the present invention
`system with downlink path 200 converting Elffl TDM to IP
`Ethernet compatible protocols and an uplink path 218 con(cid:173)
`verting IP Ethernet to El/Tl TDM compatible protocols.
`Elffl framer 202 decodes incoming TDM signals from line
`and frame alignment. A PCM bus 203 is the output from the
`Elffl framer 202 to the next block, AALl/2 segmentation
`unit 204. The TDM bit stream is packed into AALl/2 cells
`by the segmentation unit. The next block 206 packs the cells
`(with no cell header) into UDP over IP frames. The packets
`are transferred to an Ethernet controller 208 that transmits
`using Ethernet PHY device 210.
`In the uplink path 218, packets received by the Ethernet
`PHY 210 are transferred to the Ethernet controller 208 and
`from it to a unit 212 that strips the cells out of a UDP
`payload. The received cells arrive to the AALl/2 reassembly
`unit 214 that takes out the TDM bytes out of the cells and 35
`store them in a PDVT buffer 216. The PDVT (Packet Delay
`Variation Tolerance) buffer is a unit designed to absorb
`network PDV. Generally the PDVT buffer works as follows.
`TDM bytes are stored into the buffer, the buffer is not being
`emptied to the Elffl stream until reaching it's half full size 40
`(the PDVT required), that way the PDVT buffer ensures the
`packets late or early up to it's half full size will not cause
`buffer overflows or underflows and Elffl traffic will not be
`damaged (the PDVT is described hereafter in greater
`detail-see FIG. 4 and corresponding discussion). The
`Elffl TDM stream is then transferred to the El/Tl framer
`202 and out to the TDM line.
`FIG. 3 illustrates a flow diagram of the down 300 and up
`link 302 paths.
`In the down link path 300, the following steps occur:
`Step 304 -Decode Elffl signals from line and frame
`alignment, the output from this module being a PCM
`bus.
`Step 306-The PCM input is arranged in structures as
`defined in AF-VTOA-0078 CES 2.0 (1997). 3 modes 55
`are available:
`Unstructured-for fully El/Tl transparent mode.
`Structured-for transfer of all or several time slots
`(1-31).
`Structured with CAS-for transfer of time slots with 60
`their CAS bits.
`Step 308-Segmentation of these structures into cells as
`defined in ITU-T 363 .1.
`Step 310-Packetize the cells, without adding ATM
`headers, only AALl headers and payload, into UDP
`over IP frames adding connection information into
`UDP header (beside destination IP specifying the
`
`8
`remote device other addressing is needed to specify
`destination El/Tl port and bundle which is a group of
`time slots). This addressing information can be put in
`the UDP source port.
`Step 312-Frames ready are transmitted to the IP Ether(cid:173)
`net.
`In the down link path 300, the following steps occur:
`Step 314---IP Ethernet Frames are received.
`Step 316-extract cells from the UDP payload.
`Step 318-Structures are reassembled from the cells
`according ITU-T 1.363.1 and AF-VTOA-0078 CES 2.0
`(1997).
`Step 320-absorb network delay variation using a Packet
`delay variation buffer.
`Step 322-TDM data is framed, encoded and transmitted
`over the El/Tl TDM line.
`It is important to note that TDMoIP in unstructured mode
`transparently transports TDM frames without any attempt at
`interpreting the data. It is completely oblivious to such TDM
`internals as time slots, signaling channels, etc. Thus
`TDMoIP can be used to transport arbitrary Tl/El services,
`even if some of the channels are actually used to carry data
`or if the entire frame is an unstructured bit-stream. Similarly,
`the basic TDMoIP concept can be extended to fractional Tl
`or channelized El systems. To reduce traffic, only the
`information carrying bytes need be included in the IP packet.
`How does TDMoIP solve the signaling problem inherent
`in interfacing between IP networks and the telephony net-
`30 work? To answer this question we should differentiate
`between three types of signaling: in-band, CAS and CCS.
`In-band signaling, as its name implies, is transferred in the
`same audio band as the speech. It can take the form of call
`progress tones such as dial tone and ring back, DTMF tones,
`FSK for caller identification, MFRl in North America or
`MFCR2 in Europe, etc. Since these are all audible tones,
`they are encoded in the TDM timeslot and automatically
`forwarded by TDMoIP. Speech compression algorithms
`used by VoIP systems often do not pass these tones well.
`Therefore, VoIP systems need to implement tone relay
`protocols to ensure that in-band signaling functions prop-
`erly.
`The most common CAS, or channel associated signaling,
`is carried in the same Tl or El frame as the voice signals,
`but not in the speech band. Tl robs bits for this purpose
`while El devotes an entire timeslot to carry four bits for each
`of the 30 remaining channels. Since CAS bits are carried in
`the same Tl or El stream, once again they are automatically
`forwarded by TDMoIP. We take the same approach in TDM
`50 over IP as in VoIP by terminating the CAS and forwarding
`it . This is not a problem and does not add much complexity
`because CAS are only 4 b