|Publication number||US20050271059 A1|
|Application number||US 11/203,317|
|Publication date||Dec 8, 2005|
|Filing date||Aug 12, 2005|
|Priority date||Jun 2, 2000|
|Also published as||CN1442027A, CN100499872C, EP1305691A2, EP1305691A4, US7042892, US20020034194, WO2001095057A2, WO2001095057A3|
|Publication number||11203317, 203317, US 2005/0271059 A1, US 2005/271059 A1, US 20050271059 A1, US 20050271059A1, US 2005271059 A1, US 2005271059A1, US-A1-20050271059, US-A1-2005271059, US2005/0271059A1, US2005/271059A1, US20050271059 A1, US20050271059A1, US2005271059 A1, US2005271059A1|
|Inventors||Valerie Young, William Kerr, Myron White, Venkataraman Prasannan|
|Original Assignee||Radisys Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (35), Referenced by (20), Classifications (15)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of U.S. application Ser. No. 09/872,478 filed Jun. 1, 2001 which claims priority from U.S. Provisional Application No. 60/209,169 filed Jun. 2, 2000; both incorporated herein by this reference.
© 2004-2005 Radisys Corporation. A portion of the disclosure of this patent document, including but not limited to the drawing figures, contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 37 CFR § 1.71 (d).
This invention is in the field of network communications of digital data, voice, video and other content, and more specifically is directed to a flexible system architecture and methodologies for implementing a variety of network communications functionality at the confluence of computer networks and telecommunications technologies, such as voice-over-Internet (“VOIP”).
A wide variety of computer networking and telecommunications standards and protocols continues to evolve on both fronts even as telecommunication and computer networks converge. What is needed is a single board or SOC product that not only implements a substantial number of channels, for example 4 k simultaneous voice channels; but also supports a variety of protocols and interfaces, fully provisionable under software control.
One aspect of the invention is a novel TDM bridge system for processing real time TDM data, such as sampled (digital) voice data, for transmission over a packet switched network with sufficiently low delay as to obviate the need for echo cancellation. The TDM bridge system is dynamically configurable under software/host control for interfacing to various media and protocols, such as Ethernet, ATM etc.
The present architecture can be configured to implement various types of bridges including ATM SARing (Segmentation And Reassembly) operations; TDM to TDM capabilities; Ethernet to Ethernet; ATM to SONET; IP to ATM; IP to SONET; TDM to packet over Sonet etc. Because particular protocols, packetization etc. are software provisionable, they can be changed dynamically with single-call granularity. For example, one group of TDM channels can be bridged to Ethernet, while other streams are bridged to ATM or IP over SONET. Thus, one product can replace what required several different hardware products in the prior art. In one embodiment, the present invention can be implemented on a single circuit board, such as a compact PCI board (cPCI) board, for convenient interfacing with other components of a communications system.
Another aspect of the invention includes a digital interface system for interfacing a network processor coupled to a parallel data bus so as to generate a continuous stream of serial data. Such a system includes a parallel bus interface to receive bytes of parallel data from a connected network processor. By “bytes of parallel data” we mean two or more bytes transferred “broadside” in a single bus read or write operation. They are effectively concatenated. A specialized “transmit component” is coupled to the parallel bus interface for buffering and arranging the received bytes of parallel data so as to form a stream of serial data, for example TDM data. We arbitrarily define a transmit direction for the present description as generally packet-to-TDM; and conversely receive denotes a TDM-to-packet direction (whatever the particular physical interface or protocol). A TDM output port is provided for transmitting the stream of serial TDM data, the stream comprising a substantially continuous series of time-domain multiplexed time slots synchronized to a frame pulse signal, and each time slot corresponding to a respective virtual channel for carrying digital voice content.
The parallel bus interface mentioned above is coupled to the transmit memory for storing multiple-byte data, for example four or eight bytes (64-bits) in a single, broadside write operation into multiple of the currently non-active memory banks. Each data byte is stored in a corresponding one of the non-active memory banks in natural order, so that a subsequent sequential read of a selected individual memory banks produces a series of bytes for serialization into a frame of TDM data.
A “receive component” implements a similar philosophy for the receive direction, i.e., for interfacing a continuous stream of serial TDM data to a network processor for subsequent packetization. The receive component is charged buffering and assembling received TDM data so as to form bytes of parallel data and present them to the network processor without significant delay. The receive component includes a receive memory comprising a series of memory banks, including at least one “spare” bank for storing incoming data while previously buffered data is transferred in wide-word (parallel) read operations to the network processor. The transmit and receive components are part of an integrated Buffered Interface Component (“BIC”), realized as an FPGA or an ASIC in a present embodiment. The “BIC” also includes logic for directing the buffer memory operations and bus handshaking.
The network processor provides an interface to the host processor, employs RAM for packet processing, maintains active call tables, and provisions the BIC and a time slot interchange chip. The described architecture accommodates a wide variety of protocols and applications. It provides a “multi-access platform” that consolidates many communications requirements onto a single network backbone, leaving only one set of equipment to maintain, and one network management system to operate. The present invention can seamlessly integrate voice, data, and video communications over fiber-optic, hybrid fiber/copper or microwave or other paths.
Additional aspects and advantages of this invention will be apparent from the following detailed description of preferred embodiments thereof, which proceeds with reference to the accompanying drawings.
Background—TDM Data Streams
“T-carrier” is a well-known, dedicated, digital, typically leased-line service that employs time-division multiplexing in order to derive multiple channels from a single four-wire circuit operating in full duplex transmission mode. This service offers the advantages of digital error performance, increased bandwidth, and improved bandwidth utilization. T-carrier is medium independent; in other words, it can be provisioned over various transmission media such as twisted pair, coax, microwave, infrared, or fiber optic cable—at least at the lower transmission rates of DS-0 and T-1.
TABLE 1 Standard Digital Line Speeds-T Carrier and Optical. Copper Cable Based (T Carrier) T1 1.5 Mb/s 24 channels T2 6 Mb/s 96 channels T3 45 Mb/s 672 channels Synchronous Optical Network (SONET) OC1 51 Mb/s ˜800 channels OC3 155 Mb/s ˜1,600 channels OC12 622 Mb/s ˜6,400 channels OC48 2.4 Gb/s ˜25,600 channels
TDM Bridge Hardware Overview
For now, we refer to the system of
As noted, the H.110 bus carries 32 streams times 128 TDM channels, for a total of 4096 voice channels. All 32 streams on the H.110 bus are synchronized to a common frame pulse signal; the /CT_FRAME_A frame sync described above with regard to
The TSI chip (306) outputs each selected time slot via the CHI bus (308) to a buffered interface component (“BIC”) (320). CHI is a serial data interface consisting essentially of a data transport clock, a frame sync pulse, a data transmit and a data receive connection. Sixteen local data stream connections are defined in each direction. In general, in the receive direction, the BIC buffers data received on the CHI bus (308) and assembles the data for output to a network processor bus (326). We arbitrarily defined this as the receive direction. Conversely, the BIC provides a buffering and serialization process in the transmit direction as more fully described later.
The BIC (320) is provisioned over a separate bus (the “slow-port” or “SP-bus” 324), separately from the data path in the illustrated embodiment. Different control and data bus arrangements can be employed as appropriate to interface with the selected network processor while achieving the same functionality. For development work, the BIC can be conveniently implemented as a field-programmable gate array (FPGA) integrated circuit. For production, it can be implemented as an ASIC. As technology progresses, many of the components on the TDM bridge board described herein can be expected to be further integrated into fewer—perhaps even a single—integrated circuit or SOC.
Data provided by the BIC (320) is input via a high-speed network processor bus (“IX-Bus”) (326) to a network processor (340). One example of a suitable network processor is the IXP1200 network processor commercially available from Intel Corporation, Santa Clara, Calif. Another example is the IBM Power Network Processor network processor 4GS3. The present description assumes use of the Intel part by way of illustration and not limitation. The network processor (340) is coupled via a memory bus (342) to a synchronous SRAM data store (344) and an SRAM buffer (346). The network processor assembles one or more bytes of data from each active voice channel (selected by the TSI) and encapsulates the data in accordance with a selected protocol such as the internet protocol. The packets are assembled in the synchronous SDRAM store 345. The resulting data packets are output via the IX bus (326) to an octal MAC (media access controller) (350), for example, as described in further detail below.
MAC refers to well-known IEEE specifications for the data link layer that define topology independent access control protocols. MAC is a media-specific access control protocol within IEEE specifications. For example, it includes variations for token ring, token bus and CSMA/CD. In this example, the MAC is used to control access to a shared medium such as an Ethernet connection. Octal MAC parts are commercially available off-the-shelf; one example currently is the IXF440 Dual-speed Multiport Ethernet MAC from Intel. The output from MAC 350 is coupled via link (352) to a HEX PHY (354) which, as the name implies, implements 16 channels (8 bits in each direction), providing transceivers for physical connection to a network such as Ethernet. HEX PHY transceivers are known and commercially available from various sources. One example is the Intel LXT974 four port PHY fast Ethernet transceivers which support IEEE 802.3 physical layer applications at 10 and 100 MBPS. Thus the MAC 350 and the HEX PHY 354 transmit the data packets to an Ethernet connection (360) such as an RJ45. The RJ45 connector may be part of a rear transition module (“RTM”) in the presently preferred cPCI embodiment. This completes a brief overview of the present architecture and data flow from the H.110 connector (302) to the Ethernet connector (360) to implement a TDM bridge. This basic data path is shown in a heavy solid line in
Time Slot Management
Conversely, in the receive direction, the TSI (306) will receive time slot data on the CHI input bus (308 B). The selection of particular streams and channels (time slots) is configurable through a microprocessor interface (400). The microprocessor interface includes address, data and control signals, collectively identified by reference (307), which in turn is connected to the SP-bus (324) as shown in
Recall that 32 streams of data are defined on the H.110 bus (304)-16 in and 16 out. Each stream is a continuous series of bits, divided into frames, with each frame beginning with a frame pulse and having a length of 125 msec. Each frame is further divided into 128 channels or time slots, each time slot consisting of an 8-bit byte of data. All 32 streams on the bus are synchronized to a single frame pulse. Thus, if we look at the first time slot following a frame pulse, call it channel one, the channel one time slot arrives in parallel (simultaneously) across all 16 streams. Then time slot two, another byte, arrives across all 16 streams, and so on. At the end of 125 msecs, when the next frame pulse arrives, all 128 time slots multiplied by 16 streams have arrived, for a total of 2 K bytes, one byte for each of 2 K voice channels. (And the same is true on the 16 outbound channels for full-duplex operation.) The TSI chip selectively routes the active time slot bytes to the local bus, while ignoring the time slots that are inactive. This data stream output from the TSI on the CHI bus (308) is input to the BIC chip (320) described next.
The Buffered Interface Chip (BIC)
In response to the next frame pulse, the first byte b1 (for all 128 channels or time slots) are shifted into a RAM or FIFO memory (510). Then, the next frame ch0 b2, ch1 b2, ch2 b2 and so on flow into the memory, continuing until the end of that frame, 128 bytes later. At that point, the next frame pulse is received, and the second byte of data (for all 128 channels) is shifted into the FIFO. This process is ongoing continuously as data is clocked into the BIC chip. After a selected number of bytes (or frames) have been received, the data stored in the FIFO (510) is transmitted onto the IX bus (326 in
In a presently preferred embodiment of a TDM bridge application, data is transmitted to the IX bus after 4 bytes are received (by 128 time slots), corresponding to a total of 0.5 msecs of voice content on each channel. This parameter is provisionable and can be adjusted under host control. Transferring the data after buffering 8 bytes per channel (i.e. 8 frames) is convenient as 8 bytes (64 bits) is the width of the network processor bus in this example. So the transfer is optimized in that regard. The BIC receives, stores and transmits every time slot, regardless of which time slots are active at any particular time. The network processor is aware of which time slots are active as noted above.
In a presently preferred commercial embodiment, the TDM bridge product accommodates a full H.110 bus, i.e. 16 full-duplex streams of voice data, within the timing constraints described. An illustrative memory map for buffering 16 streams is shown in
In a presently preferred embodiment the BIC is implemented as an ASIC; it supports 16 TDM streams or “highways” in each direction, buffering each time slot of all of the highways for 8 frames. The BIC operates in a 64-bit IX bus mode, enabling the transfer of 8 frames (i.e. 8 bytes of data) for a single time slot in one bus access. The BIC includes transmit count and receive count registers, for handshaking with the network processor, and allows the network processor software to monitor the locations of BIC buffer pointers. This information can be exchanged, referring to
The BIC further includes packet length registers to allow IX bus accesses to and from the BIC to be of configurable length. This feature gives software the ability to ignore all highways and time slots above a programmable level. A loop back mode for TDM data provides a functional TDM interface with minimal setup. (The loop back is illustrated in
What is key as noted at the outset is to avoid echo cancellation, which requires expensive DSP hardware and software. The BIC queues up 8 frames (or bytes) of data per time slot, which is 8×125 msec or one millisecond of delay at this initial stage. Industry standards (and practical QOS) permit up to 35 milliseconds of total delay before echo cancellation is required. Eight bytes of data makes for a small packet, and hence the number of packets is large, but this traffic is accommodated by the present architecture within the echo time constraints as explained below.
BIC Receive Component Buffer Memory Operation
In operation, TDM data entering the buffer is stored beginning with a first byte in the first RAM column on the right (1724); and continuing with storage of received data one byte at a time, from top to bottom, until the first frame is completed with byte (1726). (Recall that the serial TDM stream is converted to bytes of data by the serial-to-parallel converter 1611 of
Again it should be noted that the “receive” and “transmit” directions are handled by separate modules, as shown in
It is critical, however, that the BIC buffer memory continue to receive and buffer incoming TDM data, even while it is unloading data to the network processor, as the TDM stream is ongoing in real time. This requirement can be achieved as follows.
In one embodiment, there are nine banks of RAM as shown in
In this configuration, when the data is read out, a highway toggle signal indicates which data (upper or lower byte) from a given RAM block is the “active” byte. In general, an active memory bank is available for storing incoming data, while the “inactive” or spare RAM back is available for transferring previously stored data bytes to the parallel bus interface. The designated “active” RAM bank is constantly revolving; as one fills up, the next one is made active. After 8 frames have been collected, a receive ready flag is asserted, and the data from the “non-active” banks is read out during the following network processor read access. The spare RAM bank then becomes active frame 0 during the next 8-frame cycle, and so on, rotating the active designation in “round robin” fashion. RAM in the receive module preferably has registered outputs, to improve timing constraints between RAM output and BIC output registers for IX bus data.
The receive and transmit modules (1610 and 1630 respectively, in
The illustrated architecture can process about 2,000 channels in approximately 64 microseconds, but that data rate is challenging for some Ethernet networks. An alternative arrangement is less demanding on the network connection. It includes an additional buffer or memory pool; this pool can be designated as working or standby. For example, an additional 8 frames worth of memory can be added per channel. This would allow buffering another eight frames while unloading the previously stored data. With double buffering, eight frames times or one full millisecond can be used to unload the inactive memory banks if necessary. The additional memory can be added within the BIC ASIC or SOC.
BIC Transmit Component Buffer Memory Operation
The BIC transmit module (1630) handles the transmit direction transfers, including data buffering and processor bus signaling. Data is sent from the transmit module in serial form, so this module takes parallel RAM bytes and serializes them for output on the TDM bus (1632). With reference again to
Referring now to
Basic data flow between the network processor and the BIC is summarized in the block diagram of
Network Processor Operation and Programming
With regard first to
With reference now to
At the network processor, each microengine has its own registers to receive data from the bus. And each of the microengines can execute four concurrent threads at core speed, currently on the order of 160-200 MHz. One thread can be assigned to receive data, say eight bytes, into its registers. A second thread can move the data into SDRAM. A third thread can build a packet, adding header information, etc. While that is happening, a second microengine can apply a first thread to receive data, a second thread for moving to SDRAM, and so on. Thus the microengines are interleaving fetches from the bus. This parallelism allows data to be processed and packets built very quickly. Additional microengines can similarly be assigned for receiving and analyzing incoming packets, unpacking payload, and writing data to the bus concurrently.
By counting the incoming bytes (or based on memory address) the software determines whether or when a full payload is reached (726) for the indicated protocol. If a full payload is not yet received, it stores the current bytes in SDRAM and continues loops (728). When a full packet payload has been stored (728), it is processed as follows. Referring now to the lower left side of
One example of an outgoing packet is shown in
TABLE 2 IP Packet Header Fields. VERS 1 IP protocol version 0-3 HLEN 2 Header length (in 32-bit words) 4-7 (typ. 5) SERVICE TYPE 3 Precedence, delay, throughput, 8-15 reliability TOTAL LENGTH 4 total length datagram in octets 16-31 (64k) . . . IDENTIFICATION 5 ID number for identifying 32-47 fragments FLAGS 5 fragmentation control 48-51 FRAGMENT OFFSET 6 fragment offset from datagram (etc.) header TIME TO LIVE 7 maximum time of survival of datagram PROTOCOL 8 like type field in a network frame HEADER 9 check integrity of header CHECKSUM SOURCE IP ADDR A 32-bit IP address of sender DESTINATION IP B 32-bit IP address of intended ADDRESS recipient IP OPTIONS C optional; test and debug PADDING D to a defined minimum packet size DATA — aka payload
Referring once again to
As the reader can now appreciate, the present architecture is highly scalable and flexible.
It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiments without departing from the underlying principles of the invention. The scope of the present invention should, therefore, be determined only by the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4542497 *||Mar 28, 1983||Sep 17, 1985||At&T Bell Laboratories||Wideband digital switching network|
|US5099418 *||Jun 14, 1990||Mar 24, 1992||Hughes Aircraft Company||Distributed data driven process|
|US5426635 *||Sep 8, 1993||Jun 20, 1995||At&T Corp.||Method for adaptive control of windows and rates in networks|
|US5533018 *||Dec 21, 1994||Jul 2, 1996||National Semiconductor Corporation||Multi-protocol packet framing over an isochronous network|
|US5867496 *||Nov 18, 1994||Feb 2, 1999||Mitel Corporation||Interface device|
|US5889773 *||Dec 31, 1996||Mar 30, 1999||Alcatel Usa Sourcing, L.P.||Method and apparatus for placing time division multiplexed telephony traffic into an asynchronous transfer mode format|
|US5903559 *||Dec 20, 1996||May 11, 1999||Nec Usa, Inc.||Method for internet protocol switching over fast ATM cell transport|
|US5999539 *||Dec 7, 1998||Dec 7, 1999||At&T Corp.||Apparatus for utilizing spare T1 DSO channels in E1 inverse-multiplexed channels|
|US5999541 *||Feb 28, 1997||Dec 7, 1999||3Com Corporation||Transmission of token-ring packets over ethernet by tunneling|
|US6005873 *||Aug 26, 1998||Dec 21, 1999||Eci Telecom Ltd.||Apparatus and method for concurrent voice and data transmission|
|US6044080 *||Nov 19, 1996||Mar 28, 2000||Pluris, Inc.||Scalable parallel packet router|
|US6058117 *||Oct 27, 1997||May 2, 2000||Cisco Technology, Inc.||Data transfer via pseudo deterministic channel|
|US6067296 *||Mar 28, 1997||May 23, 2000||Adtran, Inc.||Parallel backplane architecture providing asymmetric bus time slot cross-connect capability|
|US6151312 *||Feb 12, 1996||Nov 21, 2000||Stanford Telecommunications, Inc.||Network protocol for wireless broadband-ISDN using ATM|
|US6172973 *||Sep 17, 1997||Jan 9, 2001||Nortel Networks Limited||Apparatus and method for reducing delay for voice over ATM using co-located switches|
|US6195359 *||Oct 16, 1997||Feb 27, 2001||International Business Machines Corporation||Intelligent router for remote internet access|
|US6226687 *||Sep 5, 1996||May 1, 2001||Nortel Networks Limited||Method and apparatus for maintaining an order of data packets|
|US6457080 *||Sep 16, 1998||Sep 24, 2002||Mci Communications Corporation||Virtual bearer high-speed communication channel-to-device interface|
|US6490631 *||Aug 21, 1997||Dec 3, 2002||Advanced Micro Devices Inc.||Multiple processors in a row for protocol acceleration|
|US6628652 *||Mar 25, 1999||Sep 30, 2003||Lucent Technologies Inc.||Flexible telecommunications switching network|
|US6671280 *||Mar 29, 2000||Dec 30, 2003||International Business Machines Corporation||Network processor for multiprotocol data flows|
|US6717910 *||Sep 30, 1998||Apr 6, 2004||Stmicroelectronics, Inc.||Method and apparatus for controlling network data congestion|
|US6775294 *||Jul 10, 2001||Aug 10, 2004||Mitel Corporation||Time slot assigner for communication system|
|US6870837 *||Aug 19, 1999||Mar 22, 2005||Nokia Corporation||Circuit emulation service over an internet protocol network|
|US6920113 *||Mar 28, 2000||Jul 19, 2005||Telsima Inc.||Transport of iscochronous and bursty data on a sonet ring|
|US6947410 *||Nov 16, 1999||Sep 20, 2005||Cisco Technology, Inc.||System and method for communicating data packets using a backplane switch|
|US6954461 *||Dec 22, 1999||Oct 11, 2005||Nortel Networks Limited||Communications network|
|US7028217 *||May 31, 2002||Apr 11, 2006||Lucent Technologies Inc.||System and method of general purpose data replication between mated processors|
|US7046665 *||Oct 26, 1999||May 16, 2006||Extreme Networks, Inc.||Provisional IP-aware virtual paths over networks|
|US7089322 *||Oct 27, 2000||Aug 8, 2006||Motient Communications Inc.||System and method of aggregating data from a plurality of data generating machines|
|US7151770 *||Nov 17, 1999||Dec 19, 2006||British Telecommunications Public Limited Company||Communications network|
|US7243285 *||Jul 10, 2003||Jul 10, 2007||Digital Fountain, Inc.||Systems and methods for broadcasting information additive codes|
|US7346060 *||Feb 18, 2000||Mar 18, 2008||Cisco Technology, Inc.||AAL-2 switched voice wan networking|
|US7403565 *||May 6, 2003||Jul 22, 2008||Akikaze Technologies, Inc.||Region-based information compaction as for digital images|
|US20040101274 *||Jul 10, 2003||May 27, 2004||Digital Fountain, Inc.||Systems and methods for broadcasting information additive codes|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7353362||Jul 25, 2003||Apr 1, 2008||International Business Machines Corporation||Multiprocessor subsystem in SoC with bridge between processor clusters interconnetion and SoC system bus|
|US7412588 *||Jan 30, 2004||Aug 12, 2008||International Business Machines Corporation||Network processor system on chip with bridge coupling protocol converting multiprocessor macro core local bus to peripheral interfaces coupled system bus|
|US7515605 *||Mar 24, 2003||Apr 7, 2009||Corrigent Systems Ltd||Efficient transport of TDM services over packet networks|
|US7643511 *||Dec 3, 2008||Jan 5, 2010||International Business Machines Corporation||Frame alteration logic for network processors|
|US7653770 *||Jan 18, 2007||Jan 26, 2010||Xerox Corporation||Time multiplexed bidirectional bus|
|US7724714 *||Sep 13, 2004||May 25, 2010||Thomson Licensing||Method for processing data packets received via a first interface and device for carrying out the method|
|US7805532||Apr 27, 2007||Sep 28, 2010||724 Software Solutions, Inc.||Platform for interoperability|
|US7941620 *||Sep 12, 2005||May 10, 2011||International Business Machines Corporation||Double-allocation data-replication system|
|US7961755||Mar 16, 2009||Jun 14, 2011||Corrigent Systems Ltd.||Efficient transport of TDM services over packet networks|
|US8036243 *||Aug 11, 2008||Oct 11, 2011||International Business Machines Corporation||Single chip protocol converter|
|US8078153||Apr 27, 2007||Dec 13, 2011||724 Solutions Software, Inc.||System and method for dynamic provisioning of contextual-based identities|
|US8327024||Nov 9, 2007||Dec 4, 2012||724 Solutions Software, Inc.||System and method for SMS/IP interoperability|
|US8780933||Feb 3, 2011||Jul 15, 2014||Hubbell Incorporated||Method and apparatus for automated subscriber-based TDM-IP conversion|
|US8811422||Oct 7, 2011||Aug 19, 2014||Microsoft Corporation||Single chip protocol converter|
|US20040190548 *||Mar 24, 2003||Sep 30, 2004||Corrigent Systems Ltd.||Efficient transport of TDM services over packet networks|
|US20050021871 *||Jul 25, 2003||Jan 27, 2005||International Business Machines Corporation||Self-contained processor subsystem as component for system-on-chip design|
|US20050021874 *||Jan 30, 2004||Jan 27, 2005||Georgiou Christos J.||Single chip protocol converter|
|US20050063405 *||Sep 13, 2004||Mar 24, 2005||Malte Borsum||Method for processing data packets received via a first interface and device for carrying out the method|
|US20050076147 *||Sep 24, 2003||Apr 7, 2005||Blake Michael E.||NMEA 0183 sentence transporter over ethernet|
|WO2007127422A2 *||Apr 27, 2007||Nov 8, 2007||724 Solutions Software Inc||Platform for interoperability|
|U.S. Classification||370/389, 370/466|
|International Classification||H04L12/56, H04Q11/04, H04J3/00, H04L12/66, H04L12/64|
|Cooperative Classification||H04L2012/5653, H04L2012/6481, H04L2012/6472, H04L12/6418, H04L12/64, H04L2012/6459|
|European Classification||H04L12/64, H04L12/64B|