Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
2002-04-05
2004-10-19
Olms, Douglas (Department: 2661)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S397000
Reexamination Certificate
active
06807174
ABSTRACT:
BACKGROUND
1. Field of Invention
This invention relates to streaming data transmission (e.g. voice) over packet networks, and is particularly concerned with bandwidth-efficient and reliable DS-X transmission within distributed communication systems utilizing a packet network.
2. Description of the Related Art
Transferring streaming media, particularly voice and video, over a packet network presents challenges not faced with traditional time-switched systems. Traditional packet transport technologies and network/application protocols, such as TCP/IP FTP, and Ethernet are optimized for reliable data transfer, rather than the timeliness of the transfer. While such characteristics are great for transferring a data file or an application that will not work even if a small piece of data is corrupt or missing, connection and delivery confirmation delays make the transmission of time-sensitive streaming media less desirable.
Switched-packet Asynchronous Transfer Mode (ATM) does represent a convenient standard for transmitting voice, data, and video signals at very high speeds (25 Mbits/sec and higher) over packet networks. The increasing deployment of ATM-based networks, particularly on customer premises, has created a demand to provide high quality transport, switching, and call processing of voice communications over a packet-oriented network with minimal delay. The delay must not exceed that currently permitted for traditional centralized Private Branch Exchanges (PBXs), and the voice quality must be at least as good as such systems to warrant upgrading distributed ATM voice services.
A known distributed PBX architecture leveraging an ATM-based network is shown in FIG.
1
. This PBX architecture includes several end node devices (e.g. access multiplexors
100
, communications switch
120
) distributed at the edges of a packet network transport. Access multiplexors
100
(access mux) are coupled to the ATM network (or single switch)
180
via links
150
carrying ATM cell traffic at STS-1/OC-1 speeds or higher. These muxes
100
convert locally-originated, digital channels representing e.g. PCM-encoded voice/data traffic at DS-X speeds (i.e. the US plesiochronous digital hierarchy DS-0, DS-1, DS-2, DS-3, DS-4, etc. or the European E-1, E-2, . . . , hereinafter referred to as “DS-X traffic”) into packets, receive and reconstruct remotely-originated voice/data packets back into native DS-X form, and route each to their intended destinations. High speed link
170
(e.g. SONET STS-3c, OC-12) couples the communications switch
120
to the packet network
180
. Logical or virtual connections, known in ATM parlance as virtual channels, are established between the access muxes
100
and the communications switch
120
within the packet network
180
to permit transfer, call processing and switching of the packetized DS-X traffic.
As with the case with traditional centralized PBX systems, synchronous Access Devices (ADs)
110
,
115
and
118
are coupled to these access muxes
100
to collect voice/data information (such as a 64 Kbps DS-0 voice channel) originating from telephony devices such as digital/analog extensions
130
/
132
or videophone
134
, as well as T1/E1 trunks
136
. Once collected using known time division multiplexing techniques, the ADs relay synchronous DS-X traffic to the access mux
100
using signal lines
126
. Of course, ADs
110
,
115
,
118
are also used to distribute outgoing DS-X traffic extracted by the access mux
100
over the signal lines
126
to the appropriate destination telephony device or trunk.
In order to leverage the ATM network for voice communications, each access mux
100
converts DS-X traffic into ATM cells. According to the ATM standard, each cell is a fixed fifty-three bytes or octets long including a forty-eight byte payload and a five byte header. For outgoing calls, each access mux
100
packs the DS-X traffic into the 48-byte payload using conventional methods for multiplexing voice DS0s into ATM virtual channels, such as T1/E1 Circuit Emulation Service (CES) based on ATM Adaptation Layer
1
(AAL
1
) or other ATM adaptation layers for carrying voice. For incoming calls, each access mux determines the destination of the DS-X traffic encapsulated within each received cell based in part on the virtual channel or path information contained in the cell as well as its location within the cell payload. The access mux
100
then converts the packets to the carrier format for the signal line(s)
120
corresponding to the intended destination device.
However, without further refinement, this architecture is prone to cell delay (especially where the customers packet network is complex or geographically diverse), which can seriously degrade the quality of service for voice and streaming data it is slated to carry. To minimize cell-fill delay here, which can form a major component of the overall architecture delay, it has been proposed that each DS-0 channel serviceable by the access mux
100
contributes one byte to the ATM cell(s) and the so-filled cells are transported within a 125 &mgr;sec frame, corresponding to the well-established 8 KHz sampling rate for voice. To reduce communication switching setup, complexity and delay, as well as simplify cell composition/decomposition logic within each access mux
100
, each available DS-0 is statically assigned to a unique octet slot within one of the cells filled and transported within the 125 &mgr;sec frame. To further simplify network complexity, along with minimizing dynamic connection setup and teardown delays associated with ATM switched virtual channels (SVCs), permanent virtual channels (PVCs) are established within the packet network
180
at system configuration through management action to transport the DS-0 packed cells between the access mux
100
and the switch
120
.
In applying these techniques to the architecture of
FIG. 1
, a number of Constant Bit Rate (CBR) PVCs capable of bearing the simultaneous DS-0 capacity of each access mux
100
is established within the packet network
180
. A PVC will be used to bear one ATM cell per 125 &mgr;sec frame, and cell payload will contain a byte of data from each of 48 DS-0 channels statically mapped into its 48 octet slots. Since the placement of the DS-0 byte within a particular PVC and octet slot identifies the DS-0 connection (originating/terminating device), all cells must be broadcast within a given 125 &mgr;sec frame, whether or not traffic actually exists on the connection. Typically, cell octet slots corresponding to DS-0 channels not bearing activity within a given frame are stuffed with pre-established “don't care” data.
In the above-stated combination, these design choices seriously impact bandwidth efficiency. For example, if the access muxes
100
could simultaneously service sixteen (16) ADs, each defining thirty-two (32) DS-0 channels (which is typical for such units), a minimum of 512 DS-0 channel bytes would accordingly need to be transferred every 125 &mgr;sec frame, whether or not traffic actually exists on those channels. Eleven PVCs would be required to fully transport these bytes with padding left over, and accordingly eleven ATM cells would need to be transmitted every frame.
FIG. 3
graphically indicates the DS0 mapping required for the 16 32 DS-0 channel ADs plotted against the payload portions of the cells
330
-
380
to be filled, with “X” representing 16 empty octet slots at the end of the last cell
380
which are padded out in order to complete the payload. Thus, in this example, regardless of the actual DS-0 loading (meaning the number of DS-0 channels actually allocated or reserved for use) or active DS-0 traffic experienced, approximately 37.3 Mbits/sec of bandwidth would be required, exclusive of any control signaling. In view of the fact that this represents almost a quarter of the available bandwidth of an STS-3c link, and that the access mux
100
almost never experiences full loading (and is actually quite sparse in the typical PBX application), this configuration appears to be an undesirable choic
Bernstein Greg M.
Desai Premal
Gullicksen Jeffrey T.
Nortel Networks Limited
Olms Douglas
Pizarro Richard M.
LandOfFree
Method and apparatus for transporting DS-X signals through a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for transporting DS-X signals through a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for transporting DS-X signals through a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3265448