Protocol multiplexing

Example embodiments of protocol multiplexing systems comprise a multiplexer which receives multiplexed packet(s) and which uses contents of the multiplexed packets to form carrying packets which are stored in an output buffer. Some of the multiplexed packets belong to differing ones of plural virtual channels, but the multiplexer uses multiplexed packet(s) belonging to only one virtual channel to form a given carrying packet. The multiplexing systems accommodate transmission on a same virtual path of numerous connections belonging to differing virtual channels, balancing both payload efficiency and delay considerations.

BACKGROUND

1 Field of the Invention

The present invention pertains to the multiplexing of multiplexed packets into carrying packets, such as (for example) the multiplexing of AAL2 packets into ATM cells.

2. Related Art and Other Considerations

Packet multiplexing protocols typically multiplex a packet of a given type (multiplexed packet) into one or more packets of another type (carrying packets). An example of a multiplexing protocol can be AAL2 (ATM Adaptation Layer 2), whose variable-sized packets can be multiplexed into fixed sized ATM cells (ATM cells being the carrying packets). This particular example is described in ITU-T, AAL2 Type 2 Signalling Protocol (Capability Set 1), New ITU-T Recommendation Q.2630.1, December 1999), which is incorporated herein by reference in its entirety. See also U.S. patent application Ser. No. 09/188,102, entitled “ASYNCHRONOUS TRANSFER MODE SYSTEM HANDLING DIFFERING AAL PROTOCOLS,” which is also incorporated herein by reference in its entirety.

For fixed-sized carrying cells, one objective in performing the multiplexing is that the unused payload of a carrying packet should be minimized, i.e., the multiplexer should send out a carrying packet (e.g., an ATM cell in the foregoing example illustration) with as full a payload as possible (most preferably with a full payload). For carrying packets of variable size, the objective is instead to maximize transmission efficiency by multiplexing as many multiplexed packets as possible into a carrying packet. Yet for both type carrying packets there is also the essentially contradictory objective that packet delay on the link transmitting the carrying cells should be minimized. This second objective encourages the multiplexer to send out a carrying packet as early as possible (e.g., without having to wait unduly for the payload to be filled with user data) or for more multiplexed packets to be included.

Multiplexed packets from different sources (different connections) are distinguished by connection identifiers (CIDs). Since the CIDs are coded with a predetermined (and typically standardized) number of bits, the number of connections that can be distinguished by the CIDs is limited in accordance with the number of bits so allotted for the coding. For example, for AAL2 at most two hundred forty eight (248) connections can be multiplexed onto one ATM VC (Virtual Channel), the virtual channel being identified by a VCI (Virtual Channel Identifier).

FIG. 4illustrates a typical state of the art protocol multiplexing situation in which a maximum of two hundred forty eight (248) AAL2 connections can be multiplexed into an ATM VC. InFIG. 4, AAL2 packets from connections conn1through conn248are multiplexed into ATM cells for output on a channel identified as VC400. The ATM channel VC400has a capacity of CVC(cells/sec). Upon arrival, the packets from connections conn1through conn248(having respective connection identifiers CID1through CID248) are stored in queue402. Queue402is an AAL2 level queue for VC400. An AAL2 multiplexer404multiplexes the AAL2 packets stored in queue402into an output buffer406for ATM channel VC400.

In an attempt both to optimize the delay and the unused payload of the carrying packet, state of the art protocol multiplexing systems such as that shown inFIG. 4usually have a single timer408. When an ATM cell (e.g., carrier cell) cannot be fully filled by multiplexer404, the timer408starts counting down from a predetermined maximum value (e.g., 1 millisecond).

If the ATM cell can be filled before timer408expires, the filled ATM cell is sent out on the VC. The timer408is then restarted for the next outgoing ATM cell on the VC. But if the ATM cell cannot be filled before timer408expires, the partially-filled ATM cell is sent to ATM output buffer406(thereby limiting the delay). The timer408is then restarted if a carrying packet (e.g., ATM cell) cannot be filled by multiplexer404, and queue402is devoid of any multiplexed packets (AAL2 packets) for the next outgoing ATM cell from the multiplexer404. By tuning this maximum timer value it is possible to achieve a compromise between the duration of the multiplexing procedure and unused ATM payload.

In many cases it would be advantageous to have a larger number of connections involved in the multiplexing (e.g., a larger than conventional number of CIDs). The advantage is related to the fact that multiplexing more connections over a larger resource increases multiplexing efficiency. But to multiplex more AAL2 connections, for example, there must be more multiplexers identified by different virtual channel identifiers (VCIs). A simplified approach in this regard would be to construct a large FIFO queue from many CID limited (e.g., small) FIFO queues, but in a manner to keep packets of differing AAL2 connections, which are associated with different VCIs, from being multiplexed into the same ATM cell (keeping in mind that an ATM cell should carry only packets of AAL2 connections multiplexed wihtin one VC).

FIG. 5illustrates how state of the art timer mechanisms for protocol multiplexing are problematic (at least from a delay perspective) when multiplexing with a larger than conventional number of connections (e.g., CIDs). The multiplexing protocol system ofFIG. 5outputs ATM cells onto a virtual path VP500. The ATM VP has a capacity of CVP(cells/sec). InFIG. 5, k number of AAL2 level queues502are provided, e.g., queue502, through queue502k. Queue502, is an AAL2 level queue for VC(1); queue5022is an AAL2 level queue for VC2; and so forth up to queue502kwhich is an AAL2 level queue for VC(k). Upon arrival at a node having the multiplexing system, the packets from connections conn1through conn248for VC(1) (having respective connection identifiers CID1through CID248) are stored in queue5021; the packets from connections conn1through conn248for VC(k) (having respective connection identifiers CID1through CID248) are stored in queue502k; and so forth. The multiplexer5041multiplexes AAL2 packets stored in queue5021(for VC(1)) into an output buffer506for ATM VP500when an ATM cell for VC(1)is being assembled in output buffer506. Likewise, multiplexer504kmultiplexes AAL2 packets stored in queue502k(for VC(k)) into output buffer506for ATM VP500when an ATM cell for VC(k) is being assembled in output buffer506. In theFIG. 5system, each multiplexer504has an associated timer508(e.g., multiplexer5041has timer5081; multiplexer504khas timer508k; and so forth).

Thus, in the example scenario ofFIG. 5, k number of VCs are multiplexed into a virtual path (VP500) of capacity CVP. In the particular example situation shown in theFIG. 5scenario, a packet which would fill about 3.25 ATM cells arrived at multiplexer5041. Since the packet can fully fill three ATM cells in output buffer506, three ATM cells from multiplexer5041are stored in output buffer506as indicated by the dotted cells inFIG. 5. But since the packet arriving at multiplexer5041could only partially fill a fourth ATM cell, the remaining packet contents (e.g., the packet contents not corresponding to the three ATM cells stored in output buffer506) are not yet stored in output buffer506. Rather, according to the state of the art practice, timer5081is started. While timer5081is counting down, another packet arrives to multiplexer504k(belonging to VC(k)). The packet which arrives at multiplexer504kfully fills four ATM cells in output buffer506, as indicated by the cross hatched cells inFIG. 5. When timer5081subsequently expires, the last segment of the packet which previously arrived at multiplexer5041is stored in a separate ATM cell in output buffer506. The consequence of this is, that even if originally the dotted packet arrived earlier than the cross hatched packet, the dotted packet will be sent out from the multiplexing system later than the cross hatched packet. Thus, the first-in-first-out principle is violated.

In the example situation ofFIG. 5, from the perspective of the output buffer506the last segment from multiplexer5041was overtaken by four cells formed from the packet which arrived at multiplexer504k. Such a lag (of four ATM cells for VC(k)) between the fourth ATM cell associated with VC(1) and the earlier three ATM cells for VC(1) creates additional delay, because all four cells from multiplexer504kmust be served before the last segment of the packet applied to multiplexer5041can be served.

What is needed therefore, and an object of the present invention, are techniques for better balancing delay and payload optimization in a packet multiplexing protocol system.

BRIEF SUMMARY

Example embodiments of protocol multiplexing systems comprise a multiplexer which receives multiplexed packet(s) and which uses contents of the multiplexed packets to form carrying packets which are stored in an output buffer. Some of the multiplexed packets belong to differing ones of plural virtual channels, but the multiplexer uses multiplexed packet(s) belonging to only one virtual channel to form a given carrying packet.

In a first example embodiment, if receipt by the multiplexer of a multiplexed packet belonging to any of the plural virtual channels would result in formation by the multiplexer of a partially-filled carrying packet, a common timer times a delay interval. Upon occurrence of a predetermined event, a determination is made if the partially-filled carrying packet should be stored in the output buffer in accordance with whether the timer is finished timing the delay interval. When the predetermined event is arrival of another multiplexed packet which belongs to a same virtual channel as the multiplexed packet that would result in formation of the partially-filled packet, the multiplexer also uses at least a portion of the another multiplexed packet to form the carrying packet if the timer is not finished timing the delay interval. When the predetermined event is arrival of another multiplexed packet which belongs to a different virtual channel than the multiplexed packet that would result in formation of the partially-filled packet, the multiplexer stores the partially-filled carrying packet in the output buffer if the timer is not finished timing the delay interval. When the predetermined event is the timer finishing timing the delay interval before arrival in the queue of another multiplexed packet, the multiplexer stores the partially-filled carrying packet in the output buffer.

In the first example embodiment, the queue which receives the multiplexed packets is a common queue, with some of the multiplexed packets which are received into the common queue belonging to differing ones of plural virtual channels. In addition, the queue stores a virtual channel identifier for each multiplexed packet. Each virtual channel accommodates plural connections.

In a second example embodiment protocol multiplexing system, for each of plural virtual channels there is a corresponding queue for receiving multiplexed packets belonging to the respective virtual channel. A common multiplexer uses the multiplexed packets obtained from the plural queues to form carrying packets. The formation of the carrying packets by the multiplexer is performed so that, for a remainder multiplexed packet, any remainder contents of the remainder multiplexed packet is not used to form a carrying packet which is stored in the output buffer until a remainder finalization triggering event. The remainder multiplexed packet is a multiplexed packet having remainder contents; the remainder contents being a portion of the remainder multiplexed packet which would not be utilized in filling of a whole number of carrying packet(s). The second embodiment protocol multiplexing system also has a data counter for each queue (e.g., for each virtual channel). For a specific virtual channel, the associated data counter counts how many carrying packets attributable to virtual channels other than that specific virtual channel are formed and loaded into the output buffer subsequent to the multiplexing of the multiplexed packet belonging to that specific virtual channel. The contents of the data counter are used to at least partially determine the remainder finalization triggering event. For example, the remainder finalization triggering event can be determined to be the contents of the first data counter reaching a predetermined finite number.

The second embodiment protocol multiplexing system can also comprise a timer for each input queue (e.g., a first timer which, upon multiplexing of the remainder multiplexed packet belonging to a first virtual channel, times a first virtual channel delay interval). Thereby a determination regarding the remainder finalization triggering event can also be made in accordance with whether the timer is finished timing the first virtual channel delay interval.

A third example embodiment protocol multiplexing system has a pointer associated with each input queue (e.g., each virtual channel). For example, a first pointer is provided which tracks a payload end location in the buffer occupied by a last-fed-to-buffer carrying packet belonging to a first virtual channel; a second pointer is provided which tracks a payload end location in the buffer occupied by a last-fed-to-buffer carrying packet belonging to a second virtual channel; and so forth. Using the pointers, the multiplexer can augment the last-fed-to-buffer carrying packet belonging to the first virtual channel, at the payload end location tracked by the first pointer, with at least partial contents of a next-received multiplexed packet belonging to the first virtual channel to the buffer, even when the second pointer succeeds the first pointer.

Aspects of the third example embodiment can be carried into other embodiments. For example, the pointers of third embodiment can be utilized in conjunction with the first embodiment wherein a common queue receives multiplexed packets (with some of the multiplexed packets belonging to differing ones of plural virtual channels including the first virtual channel and the second first virtual channel). In such implementation, a common timer is provided. If multiplexing of a multiplexed packet belonging to any of the plural virtual channels results in formation of a partially-filled carrying packet, the timer times a delay interval. As in the first embodiment, upon occurrence of a predetermined event, a determination is made if a partially-filled carrying packet should be stored in the output buffer in accordance with whether the timer is finished timing the delay interval.

The pointers of third embodiment can also be utilized in conjunction with the second embodiment, wherein plural input queues are associated with plural virtual channels and a common multiplexer feeds the output buffer. For a remainder multiplexed packet, any remainder contents of the remainder multiplexed packet is not used to form a carrying packet which is stored in the output buffer until a remainder finalization triggering event has occurred. The contents of a data counter can be utilized to at least partially determine the remainder finalization triggering event. The data counter counts how many carrying packets attributable to virtual channels other than a specific virtual channel are formed and load into the output buffer subsequent to the multiplexing of the multiplexed packet belonging to the specific virtual channel.

In the differing modes and embodiments of the invention, the carrying packet is preferably of a predetermined carrying packet size. Moreover, as an example, the multiplexed packet can be an AAL2 packet and the carrying packet can be an ATM cell.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail. Moreover, individual function blocks are shown in some of the figures.

In the example embodiments of protocol multiplexing systems described herein, a multiplexer uses one or more multiplexed packets to form carrying packets which are stored in an output buffer. Under control of a packet server or the like, the carrying packets stored in the output buffer are transmitted, in accordance with the capacity of the packet server and timing considerations, e.g., link timing considerations, to a physical transmission path or link (which typically leads away from a node or the like at which the protocol multiplexing system is situated).

The multiplexed packets are higher layer packets which can be borne, either in whole or in part, in lower layer packets. As one illustrative example applicable to all embodiments described herein, the multiplexed packets can be AAL2 packets, and the carrying packets can be ATM cells. However, the present invention is not limited to these specific example packet types, as it should be understood that the invention encompasses multiplexer systems where fixed sized carrying packets are utilized, and certain multiplexer systems in which variable sized carrying packets are utilized.

The protocol multiplexing system ofFIG. 1comprises a multiplexer104which obtains multiplexed packets from common queue102, and which uses the multiplexed packets to form carrying packets which are stored in output buffer106prior to transmission of the carrying packets on transmission path100. As shown inFIG. 1, the multiplexer104comprises, e.g., common timer108and multiplexer controller112. As used herein, the multiplexer controller112essentially represents certain supervisory or control logic which governs operation of multiplexer104, it being understood that a controller per se need not be employed. Moreover, there are various ways of implementing or distributing the functionalities of common timer108and multiplexer controller112within multiplexer104, including the example depiction inFIG. 1of these functionalities being separate units within104. Alternatively, one or more of these functionalities may be included in other units of multiplexer104or the same unit, e.g., common timer108may be included in multiplexer controller112.

As shown inFIG. 1, the common queue102receives multiplexed packets belonging to plural virtual channels. As with comparable queues shown in other embodiments, queue102is an AAL2 level common queue, which stores AAL2 CPS (Common Part Sublayer) packets. Each of the plural virtual channels in turn carries packets for plural connections. For example,FIG. 1shows common queue102receiving multiplexed packets for each of k number of virtual channels, e.g., VC(1) through VC(k). Moreover, for each virtual channel the common queue102can receive multiplexed packets for as many as j number of connections. For AAL2, for example, j typically equals 248. Specifically, common queue102receives multiplexed packets for a first connection of VC(1), shown as CONN1,VC(1), a second connection of VC(1), shown as CONN2,VC(1), and so forth up to and including j number of connections for VC(1). Such may also be the case for all k number of VCs, culminating in a last connection of VC(k), shown as CONNj,VC(k).

Thus, some of the multiplexed packets arriving at common queue102belong to differing ones of plural virtual channels (e.g., VC(1)–VC(k)). However, multiplexer104feeds the buffer so that a given carrying packet comprises multiplexed packets belonging to only one virtual channel. In other words, all multiplexed packets forming an given carrying packet belong to the same virtual channel.

The common timer108of multiplexer104serves to time or monitor what is herein known as a delay interval. As mentioned above, the common timer108may be distinct from multiplexer controller112as shown inFIG. 1, or may actually comprise multiplexer controller112, or may be provided or situated in various other manners.

The multiplexer104uses the contents of multiplexed packets stored in common queue102to form carrying packets which are subsequently stored in output buffer106. In the example embodiment ofFIG. 1, if utilization of a multiplexed packet (stored in common queue102and belonging to any of the plural virtual channels) would result in formation of a partially-filled carrying packet, the multiplexer104, e.g., multiplexer controller112, initiates the timing of a delay interval. The timing of the delay interval is timed or monitored by common timer108, which can be a count-down timer, for example. Upon occurrence of a predetermined event, multiplexer controller112determines if the partially-filled carrying packet being formed by the multiplexer should be finalized and stored in output buffer106. In making such determination, the multiplexer controller112may check whether common timer108is finished timing the delay interval. The delay interval can be a predetermined value which is set according operating circumstances. A non-limiting, example predetermined value for the delay interval can be about one millisecond, for example. As a first example scenario for the first embodiment, assume that the common timer108has been started because, using a multiplexed packet from virtual channel VC(x), the multiplexer104is in the process of forming a partially-filled carrying packet. If another multiplexed packet which belongs to the same virtual channel VC(x) subsequently arrives in common queue102, the multiplexer controller112allows the multiplexer104also to include at least a portion of the subsequently arriving multiplexed packet in the carrying packet being formed, provided that common timer108is not finished timing the delay interval. Such utilization results in further filling, perhaps even total filling, of the carrying packet currently being formed by multiplexer104and which previously had been considered (and may still be) as only partially filled.

As a second example scenario for the first embodiment, assume that the common timer108has similarly been started after initial formation by multiplexer104of a partially-filled packet formed using a multiplexed packet from virtual channel VC(x). If another multiplexed packet which belongs to another virtual channel VC (≠x) subsequently arrives in common queue102, multiplexer controller112allows (actually requires) that the partially-filled packet being formed by multiplexer104be stored in buffer106if common timer108is not finished timing the delay interval. Thus, this second example scenario results in completion/finalization and storage of the carrying packet by the multiplexer104.

As a third example scenario for the first embodiment, if the multiplexer104has finished timing the delay interval before arrival in the queue of another multiplexed packet, the multiplexer controller112allows (or requires) that the partially-filled packet being formed by multiplexer104be finalized and stored in buffer106as a result of expiration of the delay interval.

To facilitate operation of the first example embodiment ofFIG. 1, an indicator such as a virtual channel identifier (VCI) is stored with or associated with each multiplexed packet received in common queue102. The indicator (e.g., virtual channel identifier (VCI)) can either be stored in common queue102as a header or the like for the received multiplexed packet, or stored in a table and correlated with the location of an entering multiplexed packet. Such table can be maintained, e.g., by a controller which interacts both with common queue102and multiplexer104.FIG. 1Aparticularly shows the situation in which common queue102stores virtual channel identifiers (VCIs), depicted as VCI, as headers1201,1202, etc, of respective multiplexed packets1221,1222, etc., stored in common queue102.

It should be understood that the indicator utilized for the multiplexed packets stored in common queue102can have other names, e.g., multiplexer ID, but in some sense is related to (e.g., the same as or derived from) the virtual channel to which the multiplexed packets belongs, hence use herein of the generic term virtual channel identifier.

The particular packet production pattern shown inFIG. 1resembles that ofFIG. 4, but with the principles of the protocol multiplexing system ofFIG. 1instead being operative. For example, assume that a multiplexed packet for VC(1) has arrived at common queue102, and would fill three full carrying packets in buffer106, and still have contents left over for forming a portion (but not all) of a fourth carrying packet.FIG. 1shows that, in accordance with all three scenarios of the first embodiment as described above, the multiplexer104has used the contents of the arriving multiplexed packet to form three full carrying packets1301–1303, as well as a partially-filled carrying packet1304. These four carrying packets, all comprised of the multiplexed packet belonging to VC(1), are depicted by dotted fill packets inFIG. 1to reflect association with VC(1).

In the operation that resulted in the packet formation pattern ofFIG. 1, upon receipt of the multiplexed packet for VC(1), multiplexer104formed and stored in output buffer the three full carrying packets1301–1303. Further, upon noting that a partially-filled carrying packet might result from the rest of the contents of the multiplexed packet for VC(1), multiplexer controller112required common timer108to start timing its delay interval. If, prior to the expiration of the delay interval, another multiplexed packet arrives in common queue102, the multiplexer controller112would discern from the VCI or multiplexer ID stored or associated with the more recently received multiplexed packet whether the more recently received multiplexed packet belongs to the same virtual channel as does the multiplexed packet for which the common timer108has been activated. If not, and having noted that the common timer108has not yet expired, the multiplexer controller112finalizes and stores the partially-filled carrying packet1304in output buffer106, in the manner illustrated. As also shown inFIG. 1, the more recently received multiplexed packet has been used by multiplexer104to form four carrying packets1305–1038(depicted by cross hatched fill inFIG. 1).

The first example embodiment ofFIG. 1therefore does not allow the situation ofFIG. 5. While partially-filled carrying packets do exist in the first example embodiment ofFIG. 1, the timer mechanism implemented by common timer108does not hurt the timing of the FIFO scheduling (e.g., the timing of the scheduling for buffer106, which involves first-in-first-out packet handling without one packet overtaking another packet).

The second example embodiment protocol multiplexing system ofFIG. 2is characterized, e.g., in having, for each virtual channel, a corresponding queue202. The queues202receive multiplexed packets belonging to their corresponding virtual channel (e.g., a first queue2021, which receives multiplexed packets belonging to a first virtual channel VC(1); up to and including a last queue202kwhich receives multiplexed packets belonging to a last virtual channel VC(k)).

A common multiplexer204uses the multiplexed packets obtained from the plural queues202to form carrying packets which are eventually stored in output buffer206. In theFIG. 2embodiment, when a queue202receives a multiplexed packet, the common multiplexer204initially forms and stores in output buffer206carrying packets corresponding only to as much of the contents of the multiplexed packet as will fill a whole number of carrying packets. Any remaining content portion of the arriving multiplexed packet which will not fill a full carrying packet, known herein as “remainder contents” of a “remainder multiplexed packet”, is retained for another carrying packet for that virtual channel. That “another” carrying packet (which has not necessarily been completed) is accordingly not yet stored in output buffer206. Rather, the carrying packet containing the remainder contents is completed and stored at a subsequent time, e.g., upon occurrence of a remainder finalization triggering event.

Thus, as used herein, a “remainder multiplexed packet” is a multiplexed packet having “remainder contents”. The remainder contents is a portion of the remainder multiplexed packet which would not be utilized in filling of a whole number of carrying packet(s).

The second embodiment multiplexer204ofFIG. 2comprises multiplexer controller212, as well as a data counter209associated with each corresponding queue202(e.g., for each virtual channel). For example, queue2021has corresponding data counter2091; queue202kcorresponding has data counter209k, and so forth. For a specific virtual channel, e.g., for a specific queue202, the associated data counter209counts how much payload (e.g., how may carrying packets) attributable to virtual channels other than that specific virtual channel is loaded into the buffer206subsequent to the multiplexing of a remainder multiplexed packet belonging to that specific virtual channel. Each of the data counters is incremented when the common multiplexer204is ready to store a new carrying packet in buffer206.

As with the embodiment ofFIG. 1, the elements and functionalities of common multiplexer204may be distributed and packaged in various ways. The separate units shown inFIG. 1are merely for sake of illustrating functionalities performed by common multiplexer204.

The multiplexer controller212of theFIG. 2protocol multiplexing system uses the contents of a data counter209to determine at least partially the remainder finalization triggering event. For example, for remainder multiplexed packet for virtual channel VC(1), the controller212can determine the remainder finalization triggering event as having occurred when the contents of the first data counter209, reaches a predetermined finite number. Optionally, the second embodiment protocol multiplexing system ofFIG. 2can also involve common multiplexer204as comprising a timer208for each corresponding input queue202. For example, first input queue2021has a first timer2081which, upon multiplexing of the remainder multiplexed packet belonging to a first virtual channel, times a first virtual channel delay interval in similar manner as previously described. As described below, the timers208can also be utilized by controller212in determining the remainder finalization triggering event (e.g., whether the timer208is finished timing the first virtual channel delay interval can be a factor in determining the occurrence of the remainder finalization triggering event).

One or more of the timers208and data counters209may be included in or encompassed by multiplexer controller212. Alternatively, the timers208and data counters209may be distinct components as depicted inFIG. 2.

Thus, in theFIG. 2protocol multiplexing system, a partially filled carrying packet is finalized and stored in buffer206whenever the data counter209for its associated virtual channel becomes higher than a predefined limit. In this manner, a trade off or balance between delay and payload optimization can be tuned.

In the particular packet illustration shown inFIG. 2, a remainder finalization triggering event occurs when the data counter associated with a remainder multiplexed packet reaches two carrying packets (e.g., two ATM cells in an implementation wherein the carrying packets are ATM cells). In theFIG. 2illustration, a first multiplexed packet belonging to VC(1) arrives in queue2021and gets segmented into four parts. The first three parts fill three carrying packets, e.g., carrying packets2301through2303inFIG. 3(depicted as dotted filled packets).FIG. 3shows these three carrying packets2301through2303as already having been stored in output buffer206. In view of the fact that fourth part of the multiplexed packet remains and cannot itself fill a carrying packet, it is considered as remainder contents of the multiplexed packet and is retained in an interim (not necessarily completed) carrying packet rather than used to form a finalized carrying packet. Rather, the timer2081for the associated queue202, (e.g., the timer208for the VC to which the remainder multiplexed packets belongs) is commissioned by controller212to begin timing the delay interval, and similarly the data counter2091for the associated queue2021is re-initialized.

Assume, in the foregoing illustration, that while the timer2081is counting down, another multiplexed packet arrives in the another queue202, e.g., another multiplexed packet arrives in queue202k. Assume further that this multiplexed packet which just arrived in queue202kcould fully fill four carrying packets. In such case, the common multiplexer204beings to form carrying packets belonging to VC(k). But after forming these carrying packets and storing two such carrying packets in buffer206(shown as cross-hatch filled carrying packets2304and2305inFIG. 2), the value of data counter2091reaches two, which is the predefined limit. At this point, the controller212declares a remainder finalization triggering event for the partially-filled carrying packet for VC(1) which was withheld by common multiplexer system204. Upon declaration of the remainder finalization triggering event, the common multiplexer system204finalizes the partially-filled carrying packet for VC(1), comprising the fourth part of the multiplexed packet which arrived in queue2021, and stores the carrying packet2306in the output buffer206in the manner shown inFIG. 2. The remaining two carrying packets2307and2308for VC(k) can then be stored by common multiplexer204into buffer206, as also shown inFIG. 2.

Hence, in theFIG. 2embodiment, the data counters209facilitate a limit on the number of overtaking carrying packets in buffer206, e.g., a limit on the delay between carrying packets of the same virtual channel. In theFIG. 2embodiment the data limit for the data counters209is finite. When the data limit is zero, the protocol multiplexing system ofFIG. 2performs similarly to that ofFIG. 1.

FIG. 3Aillustrates certain portions of a third example embodiment protocol multiplexing system. TheFIG. 3Asystem can be employed in context of any of the previously described systems and other system, including but not limited to the systems ofFIG. 1,FIG. 2,FIG. 4, andFIG. 5. Therefore, only portions of theFIG. 3Asystem specific thereto are described herein, it being understood that other components or aspects of the system can be acquired from the overall context system in which it is employed. To this end, inFIG. 3Athe reference numeral302represents a queuing system which can either be a common queue as in the manner of queue102ofFIG. 1, or a series of VC-specific queues such as queues202ofFIG. 2. Moreover, the multiplexer304includes a timer system generically shown as timer system308inFIG. 3A. The generic timer system308can comprise a common timer such as common timer108of theFIG. 1embodiment, or a set of VC-specific timers such as timers208of theFIG. 2embodiment.

In the example embodiment protocol multiplexing system ofFIG. 3A, the multiplexer controller312accesses buffer306to provide a buffer pointer associated with each virtual channel (e.g., each input queue). For example, a first pointer tracks a payload end location in the buffer306occupied by a last-fed-to-buffer carrying packet belonging to a first virtual channel; a second pointer tracks a payload end location in the buffer occupied by a last-fed-to-buffer carrying packet belonging to a second virtual channel; and so forth up to a kthpointer for the kthvirtual channel.

The pointers are maintained in a memory, such as pointer memories3141through314kas shown inFIG. 3A. The pointer memories3141through314kcan be one or more discrete or separate memory units (e.g., RAMs) as shown inFIG. 3A, or can comprise multiplexer controller312, or be realized in any other of several conventional memory allocation techniques. Rather than the pointer memories and/or timer system308being discrete units, some or all may be included in multiplexer controller312.

As illustrated in an example scenario shown in successive stages inFIG. 3AthroughFIG. 3C, using the pointers the controller312can allow the multiplexer304to feed to the output buffer306at least partial contents of a next-received multiplexed packet belonging to the first virtual channel to the buffer, even when the second pointer succeeds the first pointer. In this scenario, if a partially-filed carrying packet is put into the buffer306, then its (payload end) position in buffer306is stored in the associated pointer for VC to which the carrying packet belongs. Thus, each pointer314is assigned to a different lower level identifier (e.g., virtual channel). When a carrying packet leaves the lower level queue (e.g., buffer306), its referring pointer must be cleared. If a new multiplexed packet arrives into the multiplexer and there is a pre-existing buffer pointer for the virtual channel to which the arriving packet belongs which points to a partially-filled carrying packet, then the multiplexer first fills (e.g., augments or modifies) the carrying packet already in the buffer306at the position pointed to by the corresponding buffer pointer. In so doing, the multiplexer304puts the contents of the newly arrived multiplexed packet at the location pointed to by the corresponding buffer pointer, and updates the buffer pointer accordingly.

The example scenario of FIG.3A–FIG. 3Cis similar to that ofFIG. 1, but instead employs the techniques of the third embodiment with its buffer pointers. Again assume, for example, a multiplexed packet for VC(1) has arrived in queuing system302, and that the contents of the arriving multiplexed packet would fill three full carrying packets in buffer306, and still have contents left over for forming a portion (but not all) of a fourth carrying packet. Accordingly, as shown inFIG. 3A, the multiplexer304uses the contents of the arriving multiplexed packet to form three full carrying packets3301–3303in output buffer306, as well as a partially-filled carrying packet3304. These four carrying packets, all comprised of the multiplexed packet belonging to VC(1), are depicted by dotted fill packets inFIG. 3Ato reflect association with VC(1). The multiplexer controller312stores in buffer pointer memory3141the payload end address in buffer306of the partially-filled carrying packet3304, i.e., the last carrying packet for virtual channel VC(1) in buffer306. Such storage is performed essentially immediately in an implementation in which timers are employed, and if the timer for virtual channel VC(1) has a zero value.

Assume further the situation shown inFIG. 3B, e.g., that another multiplexed packet arrives in queuing system302, and that the arriving multiplexed packet belongs to virtual channel VC(k). As shown inFIG. 3B, multiplexer304uses the arriving packet for virtual channel VC(k) to fill four carrying packets, i.e., carrying packets3305through3308(depicted by cross hatched fill inFIG. 3B).

Assume still further that another multiplexed packet arrives for virtual channel VC(1). At this time the pointer3141points to a (payload end) address in buffer306for carrying packet3304, which is only partially filled. The multiplexer304first fills the partially-filled carrying packet (e.g., packet3304) with the contents of the just-arrived multiplexed packet for virtual channel VC(1). If there are any remainder contents for the just-arrived multiplexed packet for virtual channel VC(1), the multiplexer system304puts such remainder contents in a new cell (e.g., new carrying packet3309) at the end of buffer306. The multiplexer controller312then updates the value of the buffer pointer3141accordingly to point to the end of the contents of the new carrying packet (e.g., carrying packet3309), as shown inFIG. 3C.

The third embodiment thus differs from the first and second embodiments in that the third embodiment does not handle the multiplexed packet level (the AAL2 level) and the carrying packet level (the ATM level) independently. In a sense, in the third embodiment AAL2 some multiplexing is performed (when needed) within the output buffer306. Such may be appropriate or convenient in instances in which both the AAL2-level infrastructure and the ATM level infrastructure are owned by the network operator, thereby catering to an possible node-internal solution.

Aspects of the third example embodiment can be carried into other embodiments. For example, the pointers of third embodiment can be utilized in the first embodiment wherein a common queue receives multiplexed packets (with some of the multiplexed packets belonging to differing ones of plural virtual channels including the first virtual channel and the second first virtual channel). In such implementation, a common timer is provided. If multiplexing of a multiplexed packet belonging to any of the plural virtual channels results in formation of a partially-filled carrying packet, the timer times a delay interval. As in the first embodiment, upon occurrence of a predetermined event, a controller determines if a partially-filled carrying packet should be stored in the buffer in accordance with whether the timer is finished timing the delay interval.

For example, the pointers of third embodiment can be utilized in the first embodiment having plural input queues associated with plural virtual channels and a common multiplexer which feeds the output buffer. The common multiplexer forms the carrying packets in a manner so that, for a remainder multiplexed packet, any remainder contents of the remainder multiplexed packet is not is not considered part of a finalized carrying packet until a remainder finalization triggering event. As in the second example embodiment, the contents of a data counter can be utilized to at least partially determine the remainder finalization triggering event. The data counter counts how may carrying packets attributable to virtual channels other than a specific virtual channel are formed and loaded into the buffer subsequent to the multiplexing of the multiplexed packet belonging to the specific virtual channel.

In the differing modes and embodiments of the invention, the carrying packet is preferably of a predetermined carrying packet size. Moreover, as an example, the multiplexed packet can be an AAL2 packet and the carrying packet can be an ATM cell.

Those skilled in the art will appreciate that the functions of various components and functionalities herein described, including but not limited to the multiplexer controllers, may be implemented using individual hardware circuits, using software functioning in conjunction with a suitably programmed digital microprocessor or general purpose computer, using an application specific integrated circuit (ASIC), and/or using one or more digital signal processors (DSPs).